On Sat, Jun 01, 2013 at 01:03:11AM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 05:57:31PM -0500, Russ Anderson wrote:
> > On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> > > If nvram becaomes full, some
> > > systems crash during firmware initialisation. So we can't let nvram
> > > become full. The obvious thing to do here is to look at the values from
> > > QueryVariableInfo, but many systems won't perform any garbage collection
> > > until they're almost out of space and so variables that have been
> > > deleted still show up as used space.
> >
> > OK. I get nvram looks full due to lack of garbage collection
> > on some systems. Does QueryVariableInfo (at runtime) tell you
> > it is full? Is the problem that it says it is full when it
> > is not, or does not tell you it is full when it is?
>
> QueryVariableInfo reports the amount used *including garbage*. This
> makes it useless for determining how much space is available for the
> firmware to use.
So when QueryVariableInfo reports there is space available, the
write works and everything is fine.
And when QueryVariableInfo reports insufficient space, don't write
and everything is fine.
But when QueryVariableInfo reports insufficient space and you
write anyway, the system can get bricked. Is that the problem?
According to the UEFI spec for QueryVariableInfo()
RemainingVariableStorageSize
Returns the remaining size of the storage
space available for EFI variables associated
with the attributes specified.
It also says:
The returned MaximumVariableStorageSize, RemainingVariableStorageSize,
MaximumVariableSize information may change immediately after
the call based on other runtime activities including asynchronous
error events. Also, these values associated with different
attributes are not additive in nature.
Note that "other runtime activities including asynchronous error
events." That means runtime services may be using nvram without
the OS knowing about it.
Some bios implementation may be "*including garbage*", but can
you definitively say ALL do? The spec explicitly says "the
implementation of variable storage is not defined in this
specification". You can't assume any form of garbage collection.
7.2 Variable Services
Although the implementation of variable storage is not defined
in this specification, variables must be persistent in most cases.
This implies that the EFI implementation on a platform must arrange
it so that variables passed in for storage are retained and
available for use each time the system boots, at least until they
are explicitly deleted or overwritten. Provision of this type of
nonvolatile storage may be very limited on some platforms, so
variables should be used sparingly in cases where other means of
communicating information cannot be used.
I don't see anything in here about the OS being free to use
more nvram than QueryVariableInfo() reported as being available.
What happened to following the spec?
> > > We can work around that by adding
> > > up the size of the variables ourselves, but that only gives us the value
> > > for runtime-visible variables. We also need to know how much space is
> > > used by variables that are only visible during boot,
> >
> > Is it valid to assume that only the kernel writes to nvram at
> > runtime? Can bios log error information to nvram on an SMM
> > interrupt (for example)?
>
> There's a limited number of situations where the firmware can write to
> nvram, but they're basically uninteresting. Practically speaking, it's
> always via the kernel once ExitBootServices() has been called.
How can you say "they're basically uninteresting"???
Do you know what EVERY bios implementation does???
> > > hence calling
> > > QueryVariableInfo before ExitBootServices.
> >
> > Correct me if I am wrong, but that is called from EFI stubs,
> > which is only used by some bootloaders (sometimes grub2).
> > Does that mean EFI/grub and EFI/elilo will not hit the problem,
> > or will not have your fix?
>
> Will not have the fix. Boot EFI systems via the EFI stub.
Thanks for that clarification.
> Boot EFI systems via the EFI stub.
Fortunately all our shipping systems are EFI/grub and EFI/elilo
right now, so they boot.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
