Re: Securing the boot flow in U-Boot
On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel wrote: > On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote: > > > ... > > > It depends on what you mean by "OS provided". The DTS files come from > > the Linux Kernel sources, full stop. > > That is the mistake we should try to fix. > > We have DT bindings, which define the contract between the OS on one > side, and the platform on the other side. This means it is the > platform's job to present a DT description that adheres to those > [stable] bindings. > > Today's development model of developing DT bindings in lockstep with > the drivers, and then bundling DT files with the OS is completely > unsustainable, since it doesn't scale, and it demonstrably results in > DT bindings that get modified without any regard for devices that are > already in the field (MacchiatoBin is a good example). > > So it doesn't really matter where the kernel *sources* come from, as > long as the platform provides its own DT, which does not change just > because the kernel changes. > > It is already defined how the platform provides this DT on a UEFI > system, i.e., via a configuration table with a known GUID. How the > firmware popiulates this memory is an implementation detail: if it > wants to load it from a signed file in the file system, that is fine, > as long as it is not the OS providing this file to the firmware. > > I agree, people seem to be conflating where DT is stored in source control over where it should be supplied to OS. Just because the DT is in linux kernel git does not mean you can't build it into the u-boot for your board. In fact I bet u-boot maintainer would love patches for updates ;-) Graeme ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, 12 Jul 2018 at 16:50, Rob Herring wrote: > > On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory > wrote: > > > > On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > > > > > Hi Mark > > > > > > > -Original Message- > > > > From: Mark Brown [mailto:broo...@kernel.org] > > > > Sent: Thursday, July 12, 2018 8:20 PM > > > > To: Udit Kumar > > > > Cc: Ard Biesheuvel ; Architecture Mailman > > > > List > > > > ; nd ; > > > > arm.ebbr-discuss > > > > > > > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() > > > > not working > > > > at runtime > > > > > > > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > > > > > > > Do any existing implementations change variables from non-volatile > > > > > > > to volatile? > > > > > > > > > > The UEFI spec is explicit about which variables are volatile and > > > > > > which are not. > > > > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > > > > seem like a useful approach to me. > > > > > > > > > I believe at boot-time, UEFI specs will be followed for volatile and > > > > > non-volatile > > > > variables. > > > > > Having this in statement EBBR, will help those platform, which cannot > > > > > expose > > > > non-volatile variables at runtime. > > > > > > > > If nothing currently does it the chances that anything will actually > > > > cope well > > > > seem minimal. Like Daniel said it seems more likely to break things - > > > > if the > > > > variables are defined as being non-volatile then the OS is unlikely to > > > > be checking > > > > at runtime if that's the case or not unless it's explicitly written to > > > > work with > > > > EBBR. If an error is generated because a non-volatile variable can't > > > > be set then > > > > that should at least fall into whatever error handling code is there to > > > > cover > > > > normal rutime failures which has some chance of doing something > > > > sensible. > > > > > > Right, > > > There will be some breaks or say diversion from UEFI specs. > > > If we need to follow UEFI specs 'Table 10. Global Variables' on such > > > platform > > > where we cannot write to NV storage at runtime, then in either case > > > 1/ passing OS as no-efi-runtime or > > > 2/ Returning errors/not saving to NV storage > > > is violation of UEFI spec. > > > > > > Which divergence is acceptable ? > > > > > Neither, fix the specs with proper updates to support your use-case. > > > > Or fix your platform to obey the specs you have chosen. > > How do you add firmware storage to existing platforms? > Why can't UEFI spec be updated to handle such reduced functionality platforms if this is important? Its not like appropriate people are unknown to Linaro. Graeme ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > Hi Mark > > > -Original Message- > > From: Mark Brown [mailto:broo...@kernel.org] > > Sent: Thursday, July 12, 2018 8:20 PM > > To: Udit Kumar > > Cc: Ard Biesheuvel ; Architecture Mailman List > > ; nd ; arm.ebbr-discuss > > > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not > > working > > at runtime > > > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > > > Do any existing implementations change variables from non-volatile > > > > > to volatile? > > > > > > The UEFI spec is explicit about which variables are volatile and which > > > > are not. > > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > > seem like a useful approach to me. > > > > > I believe at boot-time, UEFI specs will be followed for volatile and > > > non-volatile > > variables. > > > Having this in statement EBBR, will help those platform, which cannot > > > expose > > non-volatile variables at runtime. > > > > If nothing currently does it the chances that anything will actually cope > > well > > seem minimal. Like Daniel said it seems more likely to break things - if > > the > > variables are defined as being non-volatile then the OS is unlikely to be > > checking > > at runtime if that's the case or not unless it's explicitly written to work > > with > > EBBR. If an error is generated because a non-volatile variable can't be > > set then > > that should at least fall into whatever error handling code is there to > > cover > > normal rutime failures which has some chance of doing something sensible. > > Right, > There will be some breaks or say diversion from UEFI specs. > If we need to follow UEFI specs 'Table 10. Global Variables' on such platform > where we cannot write to NV storage at runtime, then in either case > 1/ passing OS as no-efi-runtime or > 2/ Returning errors/not saving to NV storage > is violation of UEFI spec. > > Which divergence is acceptable ? > Neither, fix the specs with proper updates to support your use-case. Or fix your platform to obey the specs you have chosen. Don't write a spec to bend another spec that way leads to chaos. Graeme ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
