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 -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot