NetBSD Problem Report #59121

From www@netbsd.org  Mon Mar  3 15:16:23 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 729AE1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  3 Mar 2025 15:16:23 +0000 (UTC)
Message-Id: <20250303151622.0409D1A923D@mollari.NetBSD.org>
Date: Mon,  3 Mar 2025 15:16:22 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: x86 efiboot: bootinfo pointers truncated when mapped >4GB
X-Send-Pr-Version: www-1.0

>Number:         59121
>Category:       port-amd64
>Synopsis:       x86 efiboot: bootinfo pointers truncated when mapped >4GB
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 03 15:20:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetEFI Over4Gdation
>Environment:
>Description:
On certain machines, the efiboot code is loaded into physical addresses >4GB.  But efiboot puts them into a structure with only 32 bits:

     31 struct bootinfo {
     32 	uint32_t nentries;
     33 	uint32_t entry[1];
     34 };

https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/bootinfo.h?r=1.12#31

     49 	bootinfo->entry[bootinfo->nentries++] = vtophys(what);

https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/bootinfo.c?r=1.6#49

The kernel only accepts 32-bit addresses.  And we already migrate the bootinfo to a safe space chosen by the libsa allocator (somewhere below EFI_ALLOCATE_MAX_ADDRESS, default 0x100000000, as returned by UEFI AllocatePages(EfiLoaderData, AllocateMaxAddress, ...) for whatever reason (efiboot program location gets unmapped or reused for something else by system firmware, presumably):

    516 #ifdef EFIBOOT
    517 	/* Copy bootinfo to safe arena. */
    518 	for (i = 0; i < bootinfo->nentries; i++) {
    519 		struct btinfo_common *bi = (void *)(u_long)bootinfo->entry[i];
    520 		char *p = alloc(bi->len);
    521 		memcpy(p, bi, bi->len);
    522 		bootinfo->entry[i] = vtophys(p);
    523 	}

https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c?r=1.81#516

But before then, the bootinfo->entry[i] paddrs are truncated to 32 bits.

[Originally reported by Vladimir `phcoder' Serbinenko: https://mail-index.netbsd.org/tech-kern/2025/03/02/msg030102.html]
>How-To-Repeat:
boot NetBSD on a system that maps the efiboot program into physical addresses >4GB, like the darp10-b
>Fix:
Patch suggested by phcoder at https://mail-index.netbsd.org/tech-kern/2025/03/02/msg030102.html creates separate bootinfo and bootinfo32 structures:

- bootinfo is used internally by efiboot and records paddrs with uintptr_t (XXX do we not have paddr_t in the bootloader?)
- bootinfo32 is used to pass paddrs allocated in the safe arena to the kernel with uint32_t

However, it looks like this patch will break the non-efi bootloaders -- either the mapping from bootinfo to bootinfo32 needs to happen for all of them, or the bootinfo/bootinfo32 split needs to be conditional on EFIBOOT so that for non-EFIBOOT, bootinfo still uses uint32_t.

Home	PR Database Search