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: <1396908292.4958.24.camel@adam.happyassassin.net>
Date:	Mon, 07 Apr 2014 15:04:52 -0700
From:	Adam Williamson <awilliam@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.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 Mon, 2014-04-07 at 14:03 -0700, H. Peter Anvin wrote:
> On 04/07/2014 01:00 AM, Li, Aubrey wrote:
> > 
> > EFI is no question. So, Is everybody okay with the following sequence?
> > (1) ACPI
> > (2) KEYBOARD
> > (3) ACPI
> > (4) KEYBOARD
> > (ADD_1) EFI
> > (5) TRIPLE
> > (ADD_2) CF9
> > (ADD_3) BIOS
> > 
> 
> No.  Because after "triple" there is NOTHING.  Putting anything after it
> is a joke.
> 
> How many times do I have to explain this to how many people?  If
> "triple" or "BIOS" doesn't work, there is no trying again... the machine
> is dead.

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.

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?

Again if I'm following correctly, this ought to be fine for Baytrail
devices - the ones we were trying to fix in the first place - because
they'll succeed with EFI. The justification for adding CF9 in the first
place wasn't very strong - it was just thrown in as a 'bonus extra',
more or less:

"These platforms [Baytrail] don't support ACPI reboot, we expect to call
EFI runtime service to handle this case, and CF9 is an alternate after
EFI."

so it doesn't seem unreasonable to remove it. The machine we're
currently trying to 'fix' needed TRIPLE in order to reboot correctly, it
seems. So again if I'm following correctly, that would suggest we should
have:

1) ACPI
2) KEYBOARD
3) ACPI
4) KEYBOARD
5) EFI
6) TRIPLE

I can patch that into reboot.c and confirm baytrails still work, if
that's desired.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ