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

[Ingo Molnar <mingo@kernel.org>]

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

> On February 25, 2025 12:25:12 PM PST, Ingo Molnar <mingo@kernel.org> wrote:
> >
> >* Roman Kisel <romank@linux.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@linux.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