linux-kernel - Re: reboot via bios on X86

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, 10 Apr 2012 10:03:07 -0400
From:	Miles Fidelman <mfidelman@...tinghouse.net>
To:	Matthew Garrett <mjg@...hat.com>
CC:	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, x86@...nel.org, peter.chubb@...ta.com.au,
	michael.d.labriola@...il.com
Subject: Re: reboot via bios on X86_64?

Matthew Garrett wrote:
> On Mon, Apr 09, 2012 at 01:57:46PM -0400, Miles Fidelman wrote:
>> Matthew Garrett wrote:
>>> On Mon, Apr 09, 2012 at 01:26:40PM -0400, Miles Fidelman wrote:
>>>
>>>> No.  Tried all the combinations - w/ and w/o hypervisor, all the
>>>> available kernel options.  Seems
>>>> like the only thing that will reboot this particular hardware/bios
>>>> combo is via the bios.
>>> And this is with 3.3? Interesting. What's the exact behaviour you see,
>>> and what motherboard is this?
>>>
>> No.  2.6.32.5  (the one that currently ships with Debian stable).
> Ok. The reboot code has been reworked since then. It'd be good to try it
> with a new kernel.
>
I just went through the reboot.c code, line-by-line, comparing what I'm 
running (2.6.32.41) with the 3.3 code, and
what I'm seeing is:

- the same huge amount of code excluded by #ifdef CONFIG_X86_32 blocks 
(i.e., still no path to reboot through the bios)

- no new methods for executing a reboot - choices for X86_64 remain 
[warm|cold|triple|kbd|acpi|efi,|pci|force]

- no changes to the actual code that invokes any of those reboot methods

All that seems to have changed is:

- there are some additional quirks handled, but they all translate to 
invoking one of [warm|cold|triple|kbd|acpi|efi,|pci|force]

- if one is trying to do a shutdown (which already works for me), there 
is one section of code that actually changes, specifically:
inside a #ifdef CONFIG_X86_64
    pci_iommu_shutdown();    changes to   x86_platform.iommu_shutdown();

----
So... I don't see that trying a newer kernel is going to have any effect 
vis-a-vis rebooting my particularly piece of hardware under a 64-bit 
kernel - and what with the close coupling of xen versions w/ kernel 
versions, seems like a lot of potential pain points just to test this.  
Sigh...

Miles


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra


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