linux-kernel - Re: [PATCH] x86/reboot: Don't corrupt memory on non-BIOS systems

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] [day] [month] [year] [list]

Message-ID: <b144d36f-9039-48bf-8053-66fec8a27ae1@linux.microsoft.com>
Date: Fri, 10 Jan 2025 13:05:55 -0800
From: Roman Kisel <romank@...ux.microsoft.com>
To: "H. Peter Anvin" <hpa@...or.com>, akpm@...ux-foundation.org,
 bhe@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
 kai.huang@...el.com, kirill.shutemov@...ux.intel.com, mingo@...hat.com,
 pbonzini@...hat.com, tglx@...utronix.de, x86@...nel.org,
 linux-kernel@...r.kernel.org
Cc: apais@...rosoft.com, benhill@...rosoft.com, ssengar@...rosoft.com,
 sunilmut@...rosoft.com, vdso@...bites.dev
Subject: Re: [PATCH] x86/reboot: Don't corrupt memory on non-BIOS systems

On 1/9/2025 7:25 PM, H. Peter Anvin wrote:
> On January 9, 2025 12:43:52 PM PST, Roman Kisel <romank@...ux.microsoft.com> wrote:

[...]

> 
> I should say: this patch is unambiguously *wrong*. It conflates the invocation mechanism with the desired post state, and they are not coupled. Calling the BIOS reboot entry point is not the normal way to reboot even on BIOS systems.

Thank you very much for taking time to review and for the chance to
learn from you!

Would you like me to propose another patch where the line of

*((unsigned short *)__va(0x472)) = mode;

receives a comment for posterity why that it is okay to write at that
address? Perhaps,

/*
  * The common practice for the firmware is to report 0x0..0x1000
  * as reserved in the RAM map. The value written to the address of
  * 0x472 may be used by the firmware to perform the cold or the warm
  * boot.
  */

might be a good addition to the code.

I've looked at the UEFI+ACPI spec and couldn't find any mentions of that
magical address, and the code writes at that address even in the UEFI
case. If you have time to recommend normative documents where that might
be explained, I'd greatly appreciate that!

-- 
Thank you,
Roman