On 09/09/19 14:54, Claudius Heine wrote:
Hi Stefano,
On 09/09/2019 13.26, Stefano Babic wrote:
Hi Claudius,
On 02/09/19 16:02, Claudius Heine wrote:
Hi,
I am currently looking into variable flags in order to make some variables read-only for secure boot.
The idea is that the u-boot binary is signed, while the environment file/partition is not. So the built-in default environment of u-boot can be trusted, while the external environment cannot. The assumption is that those flags can be used to customize the validation when the external environment is loaded or scripts/commands are executed.
From the '/README' I gather that the access attributes can be any of "any", "read-only", "write-once" or "change-default".
I first tried to restrict the variables by choosing 'read-only', but apparently this applies to the internal environment as well, and now those variables are not loaded from the internal environment.
Then I tried 'write-once', this worked now as expected from within u-boot, but I could modify the environment from the linux userspace via fw_setenv and those changes appear in u-boot as well. The same for 'change-default'.
Is there another way to fill the internal environment variable hash table, so that 'read-only' works as expected?
Heiko wrote some patches that change the behavior of the environment loading so that the internal environment is loaded first before the external environment.
But I think this is not mainlined.
Correct.
This way 'write-once' should work as expected, but I think 'read-only' should work that way already and we are missing something here.
But '.flags' shoudl also be set as write once, else it is possible to rewrite the .flags variable making all environment read-write.
Heiko's patch is a work-around to get a signed environment. What I had for is to provide a signed environment (outside U-Boot with libubootenv), and U-Boot just verifies as it does for a kernel image - U-Boot does not need a private key, but U-Boot loses "saveenv" and the environment can be changed only from user space.
Interesting, however loosing 'saveenv' from within u-boot would very inconvenient though.
Yes, but saveenv means that the environment must be signed and u-boot must know the private key, with all consequences. I guess it could go just with TPM support.
If the environment signature is invalid, would you end up without one or load the internal one as fallback?
The internal is always the falloback - and because if you need this feature, you have secure boot, U-Boot is signed and then the internal environment is signed, too.
If you load the internal environment, can it query the external environment verification state to handle this case and restore the external environment somehow?
If I understand the question, I think yes. When external environment is loaded, it could be verified with a public key. And if verified, this becomes the environment.
Regards, Stefano