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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20140301172256.GA29417@srcf.ucam.org>
Date:	Sat, 1 Mar 2014 17:22:56 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	"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 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.

> I know, cf9 is not an architectural way, twice ACPI call has no spec

> (1) ACPI
> (2) keyboard
> (3) ACPI
> (4) keyboard
> (5) FADT sleep register as long as it's valid(!=0)
> (6) FADT sleep registers once again(since we try ACPI twice)

ACPI is the FADT sleep register - there's no separate ACPI reboot call. 
Do you mean try this again even if the valid bit isn't set?

> (7) EFI (interesting, I found it's eventually CF9 on some my
> investigated systems. No need to wait Matt's patch, it gives a chance to
> reboot 32bit kernel on 32bit EFI today)

No. The EFI reboot call jumps into the firmware and executes code. We 
don't want to do that until we ensure that there's an appropriate 
mapping in place because the consequences could be unpleasent. There is 
code to do this, let's just wait until it's merged.

> Also, we should add if a new method is emerged, instead of keeping
> adding those freak/endless reboot dmidecode table. Those quirks were not
> supposed to be in the kernel. We should remove them.

Hey I am absolutely fine with removing DMI lists under almost all 
circumstances.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/