linux-kernel - Re: [PATCH 1/2] Remove EFI memmap quirk for UV

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:	Wed, 18 Nov 2015 09:00:47 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Alex Thorlton <athorlton@....com>
Cc:	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
	Matt Fleming <matt.fleming@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Hedi Berriche <hedi@....com>,
	Dimitri Sivanich <sivanich@....com>, x86@...nel.org,
	linux-efi@...r.kernel.org
Subject: Re: [PATCH 1/2] Remove EFI memmap quirk for UV


* Alex Thorlton <athorlton@....com> wrote:

> On Tue, Nov 17, 2015 at 08:32:59PM +0100, Borislav Petkov wrote:
> > On Mon, Nov 16, 2015 at 11:59:40AM -0600, Alex Thorlton wrote:
> > > Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to
> > > efi_apply_memmap_quirks to force SGI UV systems to fall back to the old
> > > EFI memmap mechanism.  We have a BIOS fix for this issue now, so we no
> > > longer need this quirk in the kernel.
> > 
> > So does that mean that all UV systems out there will get the BIOS update
> > or at least will have a BIOS update available so that we won't need the
> > quirk at all?
> 
> Essentially, yes.  The BIOS fix isn't available on UV1, but that's older
> hardware at this point, and the distro kernels that run on it will
> still have the quirk.  This change is mainly so that we can get the
> un-quirked code pulled in for the next major distro release.

So how about older UV systems that don't want to upgrade the BIOS for whatever 
reason but wants to upgrade to a new distro will have a non-booting kernel?

Also, what about UV systems that compile their own kernels for whatever reason?

> We won't be checking this down into the stable branches.  Mainly just planning 
> ahead here for future UV and distro releases.

But eventually the new kernel will become the stable kernel, and we'll be breaking 
old systems with old BIOSen, which is not good.

We should at least check the BIOS version via a DMI quirk and panic in some nicely 
informative 'upgrade your BIOS!' way to ease the transition ...

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/