port-amd64/59121: x86 efiboot: bootinfo pointers truncated when mapped >4GB

[campbell+netbsd%mumble.net@localhost]

>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.