linux-kernel - RE: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

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, 17 Apr 2019 17:22:21 +0000
From:   "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        "H. Peter Anvin" <hpa@...or.com>
CC:     Daniel Drake <drake@...lessm.com>, Ingo Molnar <mingo@...nel.org>,
        "Peter Zijlstra" <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jian-Hong Pan <jian-hong@...lessm.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        linux-efi <linux-efi@...r.kernel.org>,
        "Brown, Len" <len.brown@...el.com>,
        "linux-tip-commits@...r.kernel.org" 
        <linux-tip-commits@...r.kernel.org>,
        Endless Linux Upstreaming Team <linux@...lessm.com>
Subject: RE: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent]
 x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

> > >> That seems counter-intuitive to me: if no full ACPI hardware is
> > >> implemented then we should assume reduced ACPI functionality, i.e.
> > >> if
> > >the
> > >> EFI runtime is otherwise available we should default to it.
> > >
> > >It's a bit confusing, but my loose understanding is that previous
> > >versions of the ACPI spec required system implementors to implement
> > >the whole thing; but that's increasingly impractical today, e.g. with
> > >ARM systems coming along, which do not gel well with some of the
> > >historical x86-rooted design aspects that spilled over into ACPI. The
> > >V5 spec introduces reduced mode as an opt-in new feature, but for
> > >compatibility with pre-V5 implementations it needs to consider "full
> > >hardware" mode as the default.
> > >
> > >> Feel free to send a patch that makes EFI reboot the default one
> > >> under these circumstances,
> > >
> > >Just to check, you mean: EFI reboot (and shutdown) become the default
> > >methods when the machine is booted in EFI mode, and EFI stuff has not
> > >been disabled with a kernel parameter?
> > >Even when running in full hardware ACPI mode.
> > >
> > >Thanks
> > >Daniel
> >
> > This, I believe, is known to not work.
> 
> It definitely used to be the case that EFI reboot was unreliable, but I don't know
> the details.

Sorry! Ard.
I don't have the enough historical knowledge to state that EFI reboot is unreliable 
on most of the x86 systems but I did come across two systems that had buggy implementation 
of EFI reboot and hence I have added code to deal with EFI runtime services that cause page faults.

I will ask around internally to check if it is a good idea to make EFI reboot the default method 
when the machine is booted in EFI mode.

> I have added Sai to cc, he may be able to provide a bit more context
> here, since he added the code to deal with page faults during EFI runtime service
> invocations (which was inspired by a EFI reboot issue IIRC). That feature may
> have improved the situation, but I am not confident at all that it fixes all
> systems.

I believe, the code I added should improve the situation but I am hesitant to say that it fixes 
*all* the systems because the code addresses only one type of bug namely EFI Reboot accessing 
illegal memory and I have no idea about other buggy implementations.

Regards,
Sai