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

Date:   Sat, 8 Sep 2018 01:25:01 +0530
From:   Bhupesh Sharma <bhsharma@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
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, Sep 8, 2018 at 12:52 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, 7 Sep 2018, Prakhya, Sai Praneeth wrote:
>> > > So, if Thomas, Ingo, Andy, Ard and Boris are ok.. I will make it as
>> > > default (i.e. without config).
>
> Yes, that's the right thing to do.
>
>> > Also, some distributions already have specific ways to handle buggy
>> > firmwares which can be at times dependent on the underlying hardware
>> > and the firmware versions.
>
> 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.

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

>> > I would suggest that we enable this under a CONFIG for the first round
>> > and once it is tested with wider variety of x86 machines which have
>> > buggy or orphaned firmware and linux (and reboot) works fine with them,
>> > we can drop the CONFIG option in future and enable this by default.
>
> Sure and then nobody enables it and the affected machines still crash or
> hang on reboot. The whole thing is simple enough now to make it
> unconditional.

Instead, why not the make the CONFIG option default to Y. At least it
gives us an opportunity to turn it off if needed for backported/distro
kernels on such broken platforms which might need more testing with
the EFI page fault approach.

That should serve both the purposes. Just my 2 cents.

Thanks,
Bhupesh

>> Sounds fair to me, but, I would like to wait for someone experienced to
>> make the final call.
>
> Please get rid of that config knob. Buggy firmware exists and we better
> deal with it by default.
>
> Thanks,
>
>         tglx
>