linux-kernel - Re: [tip:x86/reboot] [PATCH] x86: Try the BIOS reboot method before the PCI reboot method

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 Apr 2014 15:09:14 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Adam Williamson <awilliam@...hat.com>
CC:	"Li, Aubrey" <aubrey.li@...ux.intel.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, rostedt@...dmis.org,
	tglx@...utronix.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/reboot] [PATCH] x86: Try the BIOS reboot method before
 the PCI reboot method

On 04/07/2014 03:04 PM, Adam Williamson wrote:
> 
> So if I'm following correctly, we should be able to sort the methods
> into three buckets:
> 
> 1) known to (almost) always be 'safe'
> 2) may cause system freeze if they fail
> 3) definitely cause system freeze if they fail
> 
> We put the methods from bucket 1) first, in whichever order makes the
> most sense. Then we put any methods from bucket 2), in an order derived
> from some kind of likelihood of success / likelihood of hang on fail
> calculation. And at the end we can put precisely *one* method from
> bucket 3, which should obviously be the one most likely to succeed on
> the most systems which haven't already worked with one of the other
> methods. We can't have more than one bucket 3) method, it just doesn't
> make sense.
> 

Nice idea, but wrong.  The problem is that you have to consider the
probability of success vs failure of the type 2 & 3 methods, and what is
a regression or not.

> It sounds like at least TRIPLE and BIOS are 'bucket 3' methods, so it
> seems like we have to pick which of the two we think is most useful, put
> it last, and not have the other one. Of the new methods it sounds like
> EFI is 'bucket 1', BIOS is 'bucket 3', and CF9 is 'bucket 2'.
> 
> so, it sounds like...
> 
> 1) ACPI
> 2) KEYBOARD
> 3) ACPI
> 4) KEYBOARD
> 5) EFI
> possibly 6) CF9
> 7) TRIPLE *or* BIOS
> 
> is what you would say makes sense, right? And really all there is to
> decide is whether to include CF9, and whether to put TRIPLE or BIOS at
> the end?
> 

Yep.  And it has now been shown again that CF9 just isn't safe.  We do
TRIPLE as the ultimate fallback now.

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