On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory
> On Thu, 12 Jul 2018 at 16:30, Udit Kumar <udit.ku...@nxp.com> wrote:
> > Hi Mark
> > > -----Original Message-----
> > > From: Mark Brown [mailto:broo...@kernel.org]
> > > Sent: Thursday, July 12, 2018 8:20 PM
> > > To: Udit Kumar <udit.ku...@nxp.com>
> > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Architecture Mailman List
> > > <firstname.lastname@example.org>; nd <n...@arm.com>; arm.ebbr-discuss
> > > <arm.ebbr-disc...@arm.com>
> > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not
> > > working
> > > at runtime
> > >
> > > On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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?
> Don't write a spec to bend another spec that way leads to chaos.
Well, EBBR is such a spec. The chaos is already there and EBBR
attempts to apply some amount of order to the chaos.
boot-architecture mailing list