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: <Z74qn-iQDPb3NrXS@gmail.com>
Date: Tue, 25 Feb 2025 21:39:59 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Roman Kisel <romank@...ux.microsoft.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, 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


* H. Peter Anvin <hpa@...or.com> wrote:

> On February 25, 2025 12:25:12 PM PST, Ingo Molnar <mingo@...nel.org> wrote:
> >
> >* Roman Kisel <romank@...ux.microsoft.com> wrote:
> >
> >> native_machine_emergency_restart() writes unconditionally
> >> to the physical address of 0x472 to pass the warm reboot
> >> flags to BIOS. The BIOS reads this on booting to bypass memory
> >> test and do the warm boot. On the non-BIOS systems, other
> >> means have to be employed, and this write is a memory corruption.
> >> 
> >> Fix that by moving the offending write into the case where
> >> the machine is rebooted via BIOS.
> >> 
> >> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> >> ---
> >>  arch/x86/kernel/reboot.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> >> index 615922838c51..6eec8653493f 100644
> >> --- a/arch/x86/kernel/reboot.c
> >> +++ b/arch/x86/kernel/reboot.c
> >> @@ -637,9 +637,8 @@ static void native_machine_emergency_restart(void)
> >>  
> >>  	tboot_shutdown(TB_SHUTDOWN_REBOOT);
> >>  
> >> -	/* Tell the BIOS if we want cold or warm reboot */
> >> +	/* Tell the firmware if we want cold or warm reboot */
> >>  	mode = reboot_mode == REBOOT_WARM ? 0x1234 : 0;
> >> -	*((unsigned short *)__va(0x472)) = mode;
> >>  
> >>  	/*
> >>  	 * If an EFI capsule has been registered with the firmware then
> >> @@ -681,6 +680,7 @@ static void native_machine_emergency_restart(void)
> >>  			break;
> >>  
> >>  		case BOOT_BIOS:
> >> +			*((unsigned short *)__va(0x472)) = mode;
> >>  			machine_real_restart(MRR_BIOS);
> >
> >If the value of 0x472 is only meaningful in the legacy 'BOOT_BIOS' 
> >case, then at minimum the whole block should be moved to that case, not 
> >just the setting.
> >
> >Thanks,
> >
> >	Ingo
> 
> Does the memory corruption actually matter, though?

I presume the issue came up by auditing & reviewing host writes to a 
barebones non-legacy VM?

I'd argue that we shouldn't be writing random values into random legacy 
addresses, especially if that special address doesnt seem to be covered 
by any modern spec? Basic defensive coding practices and such.

Thanks,

	Ingo