Date:	Fri, 31 May 2013 23:20:59 -0500
From:	Russ Anderson <rja@....com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Jiri Kosina <jkosina@...e.cz>, joeyli <jlee@...e.com>,
	Matt Fleming <matt@...sole-pimps.org>, matt.fleming@...el.com,
	linux-efi@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [regression, bisected] x86: efi: Pass boot services variable
	info to runtime code

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@....com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists