linux-kernel - Re: [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1809072200030.1402@nanos.tec.linutronix.de>
Date:   Fri, 7 Sep 2018 22:13:34 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Bhupesh Sharma <bhsharma@...hat.com>
cc:     "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Neri, Ricardo" <ricardo.neri@...el.com>,
        "matt@...eblueprint.co.uk" <matt@...eblueprint.co.uk>,
        Al Stone <astone@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT_HANDLER

On Sat, 8 Sep 2018, Bhupesh Sharma wrote:
> On Sat, Sep 8, 2018 at 12:52 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > If the distro patched their kernel to deal with buggy firmware, then:
> >
> >  1) why did they not upstream it ?
> 
> Because some of the kernel fixes are (for such cases), well to be
> honest, ugly.. and probably not suitable for placement in quirks
> files/common code present upstream as they introduce lots of #ifdef
> jugglery.
> 
> Also the x86 machines with such buggy BIOS firmwares are too old (but
> still used in some production environment) and the OS workarounds are
> suggested by the vendors themselves and they historically had issues
> getting the quirks upstream.

Right, because they did not even try. And the distros just integrated that
mess instead of telling them to fix the crappy firmware. And that can be
fixed. I know for sure because the RT qualification program at RH has made
vendors to fix their crap in order to get the rubber stamp.

> >  2) why should we worry about that ?
> 
> As this allows one to still promote upgrading such machines to
> upstream kernel versions and keep the kernel running on them as close
> as possible to mainline.

If the firmware is buggy and trips faults in the EFI mess then mainline
will just crash and burn.

So how are you going to upgrade these machines to a mainline kernel with
that fault handler disabled? Not at all.

If you need to patch the kernel in order to make it work on mainline, then
still that EFI fault handler has ZERO impact. Because those patches need to
prevent the firmware from faulting in the first place. If they have magic
fault handlers for this crap themself, then the patches will conflict
anyway, config switch or not.

You have to come up with something more convincing.

Thanks,

	tglx