linux-kernel - Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 31 May 2013 14:43:56 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Jiri Kosina <jkosina@...e.cz>, Russ Anderson <rja@....com>,
	joeyli <jlee@...e.com>, Matt Fleming <matt@...sole-pimps.org>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	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

* Borislav Petkov <bp@...en8.de> wrote:

> On Fri, May 31, 2013 at 01:06:09PM +0200, Jiri Kosina wrote:
> >
> > (*) If one would be naive enough, he'd believe that the pressure 
> > should be put on the BIOS writers instead of OS to fix the bug :)
> 
> Oh, definitely pressure on BIOS dudes. If they're in violation of the 
> spec and they still can fix it in time, they better. I'm sick and tired 
> of having to deal with BIOS idiocy in kernel code.

I'm all for some BIOS quality bashing, but the reality is:

1) It's not just about SGI/UV systems but apparently about several 
   different types of x86 laptops produce the same boot crash pattern: 
   most of which come from manufacturers that simply don't care about 
   Linux all that much.

   So by not reverting we'd screw our users, not put any recognizable 
   pressure on any BIOS writers or manufacturers.

2) Obviously Windows does not crash, and that's what most laptops test.
   So our realistic 'spec target' is not some sort of pure 'EFI spec',
   but EFI implementations _tested under Windows_. Consider it an 
   'extended EFI compatibility spec'.

3) There's a better, more robust firmware environment approach being 
   worked on (by you?) that avoids such 1:1 physical mapping assumption 
   crashes. That's something worth doing anyway, so why not delay the 
   early QueryVariableInfo() call change to when that enviroment is 
   properly implemented?

4) The revert is easy, and the functionality the original patch provided
   was a marginal increase in debug output to begin with...

So to me the right approach seems to be:

 A: revert now for v3.10
 B: implement 1:1 mappings environment for firmware, for v3.11
 C: reintroduce the early QueryVariableInfo() call again, in v3.11

Thanks,

	Ingo
--
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/