| 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
| ||
|
Date: Sat, 1 Mar 2014 18:19:51 +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:31:13AM +0800, Li, Aubrey wrote: > On 2014/3/2 1:22, Matthew Garrett wrote: > > No. The EFI reboot call jumps into the firmware and executes code. > > Firmware actually writes CF9. Your firmware writes CF9. Other firmware may hit some other addresses. We don't know what the behaviour of that firmware will be if it takes a fault in the process. By and large the rule when it comes to dealing with firmware interaction is "Copy Windows as closely as possible". Older versions of Windows didn't appear to hit the EFI reset vector, but if they're doing it now then we should do the same - but we should only do so once we have an expectation that it'll work rather than dumping an oops all over someone's screen. And, as I keep saying, the code to handle this case is written. Let's just make sure that your code ends up behind it in the queue. -- 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/
Powered by blists - more mailing lists