linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Russ Anderson <rja@sgi.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Jiri Kosina <jkosina@suse.cz>, joeyli <jlee@suse.com>,
	Matt Fleming <matt@console-pimps.org>,
	matt.fleming@intel.com, linux-efi@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code
Date: Sat, 1 Jun 2013 05:41:00 +0100	[thread overview]
Message-ID: <20130601044100.GA18453@srcf.ucam.org> (raw)
In-Reply-To: <20130601042058.GB15199@sgi.com>

On Fri, May 31, 2013 at 11:20:59PM -0500, Russ Anderson wrote:

> And when QueryVariableInfo reports insufficient space, don't write
> and everything is fine.

And then installs fail, which is why we implemented this additional 
code.

> But when QueryVariableInfo reports insufficient space and you
> write anyway, the system can get bricked.  Is that the problem?

No.

> 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.

No. We can't assume that. But nor can we rely upon the spec, because 
behaving according to the spec results in dead computers. So we're 
forced to write code that behaves according to reality rather than 
paper, which is unfortunate, but if *your* firmware behaved according to 
the specification then you wouldn't be seeing any problems with the 
current code, so I think there's a lesson for us all here.

> 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?

That would be the same spec that tells you not to use physical addresses 
after SetVirtualAddressMap() has been called, right? Regardless, we 
don't use more space than QueryVariableInfo() reports as being 
available. We would expect that any attempt to do so would fail. But nor 
can we assume that we're free to use as much space as 
QueryVariableInfo() *does* report, because doing so results in dead 
computers. So instead we're forced to rely on workarounds that happen to 
break your broken firmware, so now we're going to have to find a 
different set of workarounds and hope that they don't break someone 
else's computer instead.

> > 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???

We have to assume that firmware doesn't behave in a pathological manner, 
because the alternative is to give up entirely and declare that Linux 
doesn't run on UEFI systems. I suspect that that would be problematic 
for your employers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2013-06-01  4:41 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22 16:27 [regression, bisected] x86: efi: Pass boot services variable info to runtime code Russ Anderson
2013-05-23 11:58 ` Matt Fleming
2013-05-23 20:32   ` Russ Anderson
2013-05-24  7:43     ` Matt Fleming
2013-05-24 11:09       ` Borislav Petkov
2013-05-24 11:40         ` Matt Fleming
2013-05-24 16:11       ` Robin Holt
2013-05-24 17:02         ` Russ Anderson
2013-05-24 21:05           ` Dave Jones
2013-05-27  4:27             ` joeyli
2013-05-27  4:32               ` joeyli
2013-05-28  2:43               ` Russ Anderson
2013-05-24 20:05       ` Russ Anderson
2013-05-24 20:11         ` Matthew Garrett
2013-05-24 20:49           ` Russ Anderson
2013-05-28 10:50             ` Matt Fleming
2013-05-28 10:53         ` Matt Fleming
2013-05-28  8:35       ` Ingo Molnar
2013-05-29 21:01       ` Russ Anderson
2013-05-29 22:22         ` Jiri Kosina
2013-05-29 22:46           ` Russ Anderson
2013-05-29 22:53             ` Jiri Kosina
2013-05-30  2:16               ` joeyli
2013-05-30 22:17                 ` Russ Anderson
2013-05-30 22:21                   ` Matthew Garrett
2013-05-30 22:28                     ` Russ Anderson
2013-05-30 22:30                       ` Jiri Kosina
2013-05-31  2:17                         ` Russ Anderson
2013-05-31  3:28                           ` joeyli
2013-05-30 22:32                       ` Matthew Garrett
2013-05-31  2:54                         ` Russ Anderson
2013-05-31 10:06                           ` Ingo Molnar
2013-05-30 22:25                   ` Jiri Kosina
2013-05-31 10:12                     ` Ingo Molnar
2013-05-31 11:06                       ` Jiri Kosina
2013-05-31 11:40                         ` Ingo Molnar
2013-05-31 11:54                           ` Josh Boyer
2013-05-31 12:30                         ` Borislav Petkov
2013-05-31 12:43                           ` Ingo Molnar
2013-05-31 14:34                             ` Matthew Garrett
2013-05-31 14:42                               ` James Bottomley
2013-05-31 14:45                                 ` H. Peter Anvin
2013-05-31 14:48                                 ` Matthew Garrett
2013-05-31 15:43                                   ` Russ Anderson
2013-05-31 16:28                                     ` Matthew Garrett
2013-05-31 17:35                                       ` James Bottomley
2013-05-31 22:57                                       ` Russ Anderson
2013-05-31 22:59                                         ` H. Peter Anvin
2013-05-31 23:30                                         ` Jiri Kosina
2013-06-01  0:03                                         ` Matthew Garrett
2013-06-01  4:20                                           ` Russ Anderson
2013-06-01  4:41                                             ` Matthew Garrett [this message]
2013-06-01 11:01                               ` Linus Torvalds
2013-06-01 14:40                                 ` Matthew Garrett
2013-05-30  2:38             ` joeyli
2013-05-23 22:23   ` Russ Anderson
2013-05-24  7:45     ` Matt Fleming
2013-05-29 20:16       ` Russ Anderson
2013-05-31 14:41         ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130601044100.GA18453@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hpa@linux.intel.com \
    --cc=jkosina@suse.cz \
    --cc=jlee@suse.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@console-pimps.org \
    --cc=mingo@kernel.org \
    --cc=rja@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).