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

Message-Id: <20250110205130.49354-1-romank@linux.microsoft.com>
Date: Fri, 10 Jan 2025 12:51:30 -0800
From: Roman Kisel <romank@...ux.microsoft.com>
To: hpa@...or.com
Cc: akpm@...ux-foundation.org,
	apais@...rosoft.com,
	benhill@...rosoft.com,
	bhe@...hat.com,
	bp@...en8.de,
	dave.hansen@...ux.intel.com,
	kai.huang@...el.com,
	kirill.shutemov@...ux.intel.com,
	linux-kernel@...r.kernel.org,
	mingo@...hat.com,
	pbonzini@...hat.com,
	romank@...ux.microsoft.com,
	ssengar@...rosoft.com,
	sunilmut@...rosoft.com,
	tglx@...utronix.de,
	vdso@...bites.dev,
	x86@...nel.org
Subject: Re: [PATCH] x86/reboot: Don't corrupt memory on non-BIOS systems

On Thu, 09 Jan 2025 19:23:31 -0800, H. Peter Anvin <hpa@...or.com> wrote:

[...]

>Which system have you seen where this "corrupts" memory?

These are X86_64 systems that boot off of confguration in DeviceTree,
and neither ACPI, BIOS, nor UEFI are present. The processors start running
in the long mode right off the bat, and the physical memory below 4GiB
is non-RAM or reserved. The systems are virtual machines.

All that makes `*((unsigned short *)__va(0x472)) = mode;` constitue a
stray write and effectively corrupt contents at the address of 0x472
for these virtual systems.

On the physical systems I have had access to, 0x0..0x1000 seems to be
reported as reserved in E820 or UEFI memory map, and that's what the
CPU might need in the 16-bit mode for the brief times it might be used.

Perhaps, `native_machine_emergency_restart` being tailored to the quirks
of the physical hardware cannot absorb some condition around 
`*((unsigned short *)__va(0x472)) = mode;` to make sure it is fine
to write at that address? In the light of that, the callback
`machine_ops.emergency_restart` looks as a safer option.