linux-kernel - Re: [PATCH] x86: default to reboot via ACPI

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:	Tue, 26 Aug 2008 12:36:34 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Avi Kivity <avi@...ranet.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] x86: default to reboot via ACPI

* Pavel Machek <pavel@...e.cz> wrote:

> On Mon 2008-08-25 13:11:27, Avi Kivity wrote:
> > Triple-fault and keyboard reset may assert INIT instead of RESET; however
> > INIT is blocked when Intel VT is enabled.  This leads to a partially reset
> > machine when invoking emergency_restart via sysrq-b: the processor is still
> > working but other parts of the system are dead.
> > 
> > Default to rebooting via ACPI, which correctly asserts RESET and reboots the
> > machine.
> > 
> > This is safe since we will fall back to keyboard reset and triple fault if
> > acpi is not enabled or if the reset is not successful.
> > 
> > Signed-off-by: Avi Kivity <avi@...ranet.com>
> 
> "ACPI" and "safe" in one sentence. /me bets this will break lot of 
> machines.

maybe. OTOH, it's just about PIO accesses and those tend to be pretty 
safe. I would not be surprised if Windows used the ACPI reboot sequence 
too by default.

PIO access cannot really fail or fault (other than locking up in SMM 
mode) - it can in practice be at most non-effective (the box wont 
reboot) - in which case we'll still cycle through all the other current 
reboot methods.

So i think we are on the safe side. Not for v2.6.27 obviously, but maybe 
for v2.6.28, if all testing is a success. (which it is on a healthy 
range of x86 hardware we test -tip on)

> What about only doing that when enabling VT?

hm, i'd much rather have consistent behavior, so that we have less 
variables. If this breaks anywhere, we want to know about it ASAP and it 
should be pretty debuggable. ('box hangs/crashes during reboot')

In fact this change might unbreak some systems - we have a ton of DMI 
driven reboot quirks and i dont think they are anywhere close to 
complete. It's also very easy to revert, if it were to cause any 
trouble.

What do you think?

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