On Tue, Jun 25, 2019 at 08:33:30AM +0200, Wolfgang Denk wrote: > Dear Takahiro, > > In message <20190625011039.go6...@linaro.org> you wrote: > > > > > Think about secure boot. It is a bad idea to expose variables in this way. > > > > Actually, we are thinking of disabling U-Boot environment (I mean, > > ENV_IS_NOWHERE) still allowing for UEFI variables for security reason. > > OK. I know of systems that have passed security audits with > U-Boot environment enabled. In those cases it as sufficient to make > a certain set of variables immutable. > > Also, adding the new "volatile" attribute to the environment flags > as I suggested would allow to fine-tune which variables get stored > in the persistent nvironment copy at all. > > > One of the differences between U-Boot env and UEFI variables > > is that the former can and should be saved to backing storage > > only with explicit "saveenv" command, while the latter are > > expected to be saved immediately. > > OK - but this does not conflict in any way with the U-Boot > environment concept. In the same way we can add a "volatile" > property to the flags, we can add something like an "autosave" > property which would cause that aany modification of the variable > value would automatically run "env save". > > Once you think about more generic features of the property flags you > can implement all kinds of clever/useful/fancy things. For example, > one could think of a "protected" property, which would require > password entry to change the value, etc. > > Of course you could also flag variables with an "UEFI" attribute and > add all kinds of wanted behaviour. > > > Preserving respective semantics simultaneously would be possible, but > > it would make the implementation a bit complicated and ugly. > > It does not have to be ugly, and I think it is also not so > complicatred. In any case it seems more attractive to me than > adding a completly separate, new implementation for variable > storage.
Really? Take an example: U-Boot (non-volatile) variable a: value: A U-Boot (non-volatile) variable b: value: B UEFI non-volatile variable c: value: C Then, 1) user changed b's value to B', but didn't want to save it 2) user changed c's value to C' How should U-Boot behave here? 3) - hold B as well as B' and marks b as "modified, but not saved" - search the entire U-Boot environment, create a temporary buffer of {a=A, b=B, c=C'} and save it to backing storage If user does "env save" later, - discard B (and save {a=A, b=B', c=C'}) I said this is ugly and complicated. > > Instead, I believe that it will be a clever idea that we should have > > separate contexts for them as I showed in my non-volatile support patch[1]. > > > > [1] https://lists.denx.de/pipermail/u-boot/2019-June/371601.html > > To be honest: I thinkt his is not really a clever approach. it > would be _much_ easier to add a "volatile" property to the U-Boot > variable flags. Your patch modifies 12 files, and adds more than > 600 lines of code. And since you're modifying env/fat.c I have > the impression that this is not even universally usable - does it > really work only when storing the environment in a FAT file system? > Not with ext4? Or any other storage? And it works only for UEFI, but > "normal" environment variables do not benefit from this? > > Note that my suggested extension of the variable flags would be > completely agnostic of this... > > > One of possible improvements here is to refactor the env code and > > parameterize "contexts" at env_save()/env_load(). > > Contexts, or flags. But this does not require much refactoring. It > should be a straighforward extension. Contexts != flags, I mean, by Context, a separate "env_t" data with interfaces like env_save(&env_efi)/env_load(&env_efi). I don't think that it is a "different implementation." I don't know why you stick to a "single" storage, but if you don't see the implementation above(3) as ugly, that's fine. I can take it since it's is doable anyway. Thanks, -Takahiro Akashi > > > >And I agree on that. But even if it was not the case, having four > > > >different implementations for the same thing is .... sub-optiman. > > > > > > We have a lot of things that can be disabled in U-Boot. Why should we > > > not be able to disable UEFI variables? > > > > To be honest, I'm a bit doubtful about practical meaning of > > disabling UEFI variables for UEFI execution environment. > > This was Heinrich's argument, and I admit that I didn't understandit > either. > > > > UEFI variables should be accessible via the UEFI runtime API and not via > > > some U-Boot specific hack which no other program but U-Boot cares about. > > > > Please notice that one of the reasons that prevents UEFI variables > > from being accessed by OS is a real hardware(device/controller) may be > > shared between firmware(i.e. UEFI runtime) and OS and mutually exclusive > > access must be ensured. > > Again, this was Heinrich's argument. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > There are no data that cannot be plotted on a straight line if the > axis are chosen correctly. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot