linux-kernel - Re: [patch] x86: Introduce BOOT_EFI and BOOT

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]

Message-ID: <53121496.8060603@linux.intel.com>
Date:	Sun, 02 Mar 2014 01:10:46 +0800
From:	"Li, Aubrey" <aubrey.li@...ux.intel.com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Matthew Garrett <mjg59@...f.ucam.org>
CC:	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Len.Brown@...el.com,
	Adam Williamson <awilliam@...hat.com>
Subject: Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot
 sequence loop

On 2014/3/1 6:11, Li, Aubrey wrote:
> On 2014/3/1 1:47, H. Peter Anvin wrote:
>> On 02/27/2014 10:54 PM, Li, Aubrey wrote:
>>> On 2014/2/28 14:44, Matthew Garrett wrote:
>>>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>>>>
>>>>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
>>>>
>>>> Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
>>>> mapping support has landed. The right place to try it is probably after 
>>>> the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
>>>> about adding cf9 by default.
>>>>
>>>
>>> I'll defer to you if no one on the list supports me to add cf9.
>>>
>>
>> I believe we *had* it in the default list for a while, and it caused
>> hangs on some systems.

Well, keep pressing the power button for 20 seconds to power off my
ASUS-T100 makes me to re-read this thread.

Peter - Can you please clarify writing to cf9 caused some system hang.
If CF9 is the last way to try, that means ACPI, KBD takes no effect,
then if no CF9, the system hangs there in  infinite for() loop. If CF9
is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
system hang, right? If the answer is no, can you please point me which
system hangs by CF9. I'd like to investigate what the ACPI reboot
vectors look like on these systems.

I know, cf9 is not an architectural way, twice ACPI call has no spec
support as well.

Please remember, reboot/power off is the last service Linux kernel can
do for our users, why can't we just make it more robust?

IMHO, we should try all of the way we know. Don't worry, we are in the
shutdown context so we don't have a chance to break any other OS components.

Again, I'd like to suggest we try all of the known methods in the
default list, unless you have a functional reason to object.

(1) ACPI
(2) keyboard
(3) ACPI
(4) keyboard
(5) FADT sleep register as long as it's valid(!=0)
(6) FADT sleep registers once again(since we try ACPI twice)
(7) EFI (interesting, I found it's eventually CF9 on some my
investigated systems. No need to wait Matt's patch, it gives a chance to
reboot 32bit kernel on 32bit EFI today)
(8) CF9
(9) BIOS
(10) TRIPLE

Also, we should add if a new method is emerged, instead of keeping
adding those freak/endless reboot dmidecode table. Those quirks were not
supposed to be in the kernel. We should remove them.

Welcome any comments.

Thanks,
-Aubrey

> 
> So this can be finalized, add EFI after twice ACPI reboot attempt. I'll
> update the bugzilla and the patch.
> 
> Thanks,
> -Aubrey
>>
>> 	-hpa
>>
>>
> 

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