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

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

Date:	Sat, 01 Mar 2014 12:06:39 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>,
	"Li, Aubrey" <aubrey.li@...ux.intel.com>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"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 03/01/2014 09:22 AM, Matthew Garrett wrote:
> On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:
> 
>> 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 think I'm fine with cf9 being in there as long as it comes after the 
> ACPI calls and as long as we're using either conf1 or conf2 access.
> 

Be careful.  This is *exactly* what I tried back in checkin
14d7ca5c575853664d8fe4f225a77b8df1b7de7d.  We had to back that out quite
quickly.

This was before we had the Link: tags pointing back to the LKML
discussion, but the date (2008-11-11) and title of the patch should give
a good hint for finding the discussion I would think.

    x86: attempt reboot via port CF9 if we have standard PCI ports

    Impact: Changes reboot behavior.

    If port CF9 seems to be safe to touch, attempt it before trying the
    keyboard controller.  Port CF9 is not available on all chipsets (a
    significant but decreasing number of modern chipsets don't implement
    it), but port CF9 itself should in general be safe to poke (no ill
    effects if unimplemented) on any system which has PCI Configuration
    Method #1 or #2, as it falls inside the PCI configuration port range
    in both cases.  No chipset without PCI is known to have port CF9,
    either, although an explicit "pci=bios" would mean we miss this and
    therefore don't use port CF9.  An explicit "reboot=pci" can be used to
    force the use of port CF9.

    Signed-off-by: H. Peter Anvin <hpa@...or.com>

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