NetBSD Problem Report #60992

From www@netbsd.org  Wed Nov 11 13:27:21 2026
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)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CE85A1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 11 Nov 2026 13:27:21 +0000 (UTC)
Message-Id: <20261111132720.DC0601A923C@mollari.NetBSD.org>
Date: Wed, 11 Nov 2026 13:27:20 +0000 (UTC)
From: nao.nonaka@gmail.com
Reply-To: nao.nonaka@gmail.com
To: gnats-bugs@NetBSD.org
Subject: efiboot: multiboot2 MODULE tags all describe the first module
X-Send-Pr-Version: www-1.0
X-From4GNATS: "nao.nonaka@gmail.com via gnats" <gnats-admin@NetBSD.org>

>Number:         60992
>Category:       port-i386
>Synopsis:       efiboot: multiboot2 MODULE tags all describe the first module
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    andvar
>State:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 11 13:30:00 +0000 2026
>Closed-Date:    
>Last-Modified:  Wed Nov 11 22:20:01 +0000 2026
>Originator:     Naomichi Nonaka
>Release:        NetBSD-current
>Organization:
>Environment:
Not a running NetBSD system: the boot loaders were cross-built from
src with the NetBSD tools (build.sh -m amd64 tools, then nbmake-amd64
in sys/arch/i386/stand/efiboot) on Linux 6.8.0 x86_64, and run under
qemu-system-x86_64 with OVMF (both the ia32 and the x64 firmware).
bootia32.efi and bootx64.efi are both affected, the latter being built
from the same source.

>Description:
mbi_modules() in sys/arch/i386/stand/lib/exec_multiboot2.c emits one
MULTIBOOT_TAG_TYPE_MODULE tag per entry of btinfo_modulelist, but never
advances bim:

	bim = (struct bi_modulelist_entry *)(btinfo_modulelist + 1);
	for (i = 0; i < btinfo_modulelist->num; i++) {
		size_t pathlen = strlen(bim->path) + 1;
		...
			mbt->mod_start = bim->base;
			mbt->mod_end = bim->base + bim->len;
			strncpy(mbt->cmdline, bim->path, pathlen);

			mbt = (struct multiboot_tag_module *)
			    ((char *)mbt + mbt_len_align);
		}
	}

Only mbt moves on.  Every tag therefore carries the first module's base,
length and path, repeated btinfo_modulelist->num times, and a multiboot2
kernel started by "multiboot" with more than one module is told that all
of its modules are the first one.

module_init() in exec.c loads the modules correctly, to distinct
addresses, and records them correctly in btinfo_modulelist; it is only
the tags that report them which are wrong.  Nothing warns, and the total
size computed in the first pass is right (it adds up the same path length
num times rather than each path's), so the information structure is
well-formed -- just wrong.

A single-module boot is unaffected, which is presumably why this has
stood: that is the common case for loading one kernel module.
>How-To-Repeat:
With an EFI multiboot2 kernel and two or more modules:

	load /module-a
	load /module-b
	multiboot /kernel

Build efiboot with -DMULTIBOOT2_DEBUG and multiboot2_info_dump() prints
the tag list it is about to pass: the MODULE tags all show the same
mod_start, mod_end and cmdline, those of /module-a.

What I was doing when I found it: booting L4Ka::Pistachio, whose loader
(util/kickstart) takes kernel, sigma0 and root task as its first three
modules.  It ELF-loaded the kernel three times -- the second "module"
overlapping the image it had just written -- and stopped.  With the fix
below, that system boots to its test suite under both bootia32.efi and
bootx64.efi.

>Fix:
Advance bim with i.  Against revision 1.10:

--- sys/arch/i386/stand/lib/exec_multiboot2.c.orig
+++ sys/arch/i386/stand/lib/exec_multiboot2.c
@@ -514,7 +514,7 @@ mbi_modules(struct multiboot_package *mb
 	len = 0;

 	bim = (struct bi_modulelist_entry *)(btinfo_modulelist + 1);
-	for (i = 0; i < btinfo_modulelist->num; i++) {
+	for (i = 0; i < btinfo_modulelist->num; i++, bim++) {
 		size_t pathlen = strlen(bim->path) + 1;
 		size_t mbt_len = sizeof(*mbt) + pathlen;
 		size_t mbt_len_align = roundup(mbt_len, MULTIBOOT_TAG_ALIGN);

>Release-Note:

>Audit-Trail:
From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60992 CVS commit: src/sys/arch/i386/stand/lib
Date: Wed, 11 Nov 2026 21:59:41 +0000

 Module Name:	src
 Committed By:	andvar
 Date:		Wed Nov 11 21:59:41 UTC 2026

 Modified Files:
 	src/sys/arch/i386/stand/lib: exec_multiboot2.c

 Log Message:
 x86/multiboot2: advance `bim' alongside `i' in mbi_modules().

 Without it, every module tag describes the first module.
 Potentially missed while adapting code from exec_multiboot1.c, which advanced
 it at the end of the loop body.

 PR port-i386/60992

 Reported by Naomichi Nonaka.


 To generate a diff of this commit:
 cvs rdiff -u -r1.10 -r1.11 src/sys/arch/i386/stand/lib/exec_multiboot2.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: port-i386-maintainer->andvar
Responsible-Changed-By: andvar@NetBSD.org
Responsible-Changed-When: Wed, 11 Nov 2026 22:01:43 +0000
Responsible-Changed-Why:
take

State-Changed-From-To: open->needs-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Wed, 11 Nov 2026 22:06:28 +0000
State-Changed-Why:
needs pullups to netbsd-10, netbsd-11

From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: nao.nonaka@gmail.com
Subject: Re: port-i386/60992: efiboot: multiboot2 MODULE tags all describe the
 first module
Date: Thu, 12 Nov 2026 00:17:52 +0200

 On Wed, Nov 11, 2026 at 3:30=E2=80=AFPM nao.nonaka@gmail.com via gnats
 <gnats-admin@netbsd.org> wrote:
 >
 > >Number:         60992
 > >Category:       port-i386
 > >Synopsis:       efiboot: multiboot2 MODULE tags all describe the first m=
 odule
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    port-i386-maintainer
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Wed Nov 11 13:30:00 +0000 2026
 > >Originator:     Naomichi Nonaka
 > >Release:        NetBSD-current
 > >Organization:
 > >Environment:
 > Not a running NetBSD system: the boot loaders were cross-built from
 > src with the NetBSD tools (build.sh -m amd64 tools, then nbmake-amd64
 > in sys/arch/i386/stand/efiboot) on Linux 6.8.0 x86_64, and run under
 > qemu-system-x86_64 with OVMF (both the ia32 and the x64 firmware).
 > bootia32.efi and bootx64.efi are both affected, the latter being built
 > from the same source.
 >
 > >Description:
 > mbi_modules() in sys/arch/i386/stand/lib/exec_multiboot2.c emits one
 > MULTIBOOT_TAG_TYPE_MODULE tag per entry of btinfo_modulelist, but never
 > advances bim:
 >
 >         bim =3D (struct bi_modulelist_entry *)(btinfo_modulelist + 1);
 >         for (i =3D 0; i < btinfo_modulelist->num; i++) {
 >                 size_t pathlen =3D strlen(bim->path) + 1;
 >                 ...
 >                         mbt->mod_start =3D bim->base;
 >                         mbt->mod_end =3D bim->base + bim->len;
 >                         strncpy(mbt->cmdline, bim->path, pathlen);
 >
 >                         mbt =3D (struct multiboot_tag_module *)
 >                             ((char *)mbt + mbt_len_align);
 >                 }
 >         }
 >
 > Only mbt moves on.  Every tag therefore carries the first module's base,
 > length and path, repeated btinfo_modulelist->num times, and a multiboot2
 > kernel started by "multiboot" with more than one module is told that all
 > of its modules are the first one.
 >
 > module_init() in exec.c loads the modules correctly, to distinct
 > addresses, and records them correctly in btinfo_modulelist; it is only
 > the tags that report them which are wrong.  Nothing warns, and the total
 > size computed in the first pass is right (it adds up the same path length
 > num times rather than each path's), so the information structure is
 > well-formed -- just wrong.
 >
 > A single-module boot is unaffected, which is presumably why this has
 > stood: that is the common case for loading one kernel module.
 > >How-To-Repeat:
 > With an EFI multiboot2 kernel and two or more modules:
 >
 >         load /module-a
 >         load /module-b
 >         multiboot /kernel
 >
 > Build efiboot with -DMULTIBOOT2_DEBUG and multiboot2_info_dump() prints
 > the tag list it is about to pass: the MODULE tags all show the same
 > mod_start, mod_end and cmdline, those of /module-a.
 >
 > What I was doing when I found it: booting L4Ka::Pistachio, whose loader
 > (util/kickstart) takes kernel, sigma0 and root task as its first three
 > modules.  It ELF-loaded the kernel three times -- the second "module"
 > overlapping the image it had just written -- and stopped.  With the fix
 > below, that system boots to its test suite under both bootia32.efi and
 > bootx64.efi.
 >
 > >Fix:
 > Advance bim with i.  Against revision 1.10:
 >
 > --- sys/arch/i386/stand/lib/exec_multiboot2.c.orig
 > +++ sys/arch/i386/stand/lib/exec_multiboot2.c
 > @@ -514,7 +514,7 @@ mbi_modules(struct multiboot_package *mb
 >         len =3D 0;
 >
 >         bim =3D (struct bi_modulelist_entry *)(btinfo_modulelist + 1);
 > -       for (i =3D 0; i < btinfo_modulelist->num; i++) {
 > +       for (i =3D 0; i < btinfo_modulelist->num; i++, bim++) {
 >                 size_t pathlen =3D strlen(bim->path) + 1;
 >                 size_t mbt_len =3D sizeof(*mbt) + pathlen;
 >                 size_t mbt_len_align =3D roundup(mbt_len, MULTIBOOT_TAG_A=
 LIGN);
 >

 Committed the fix. Thank you for reporting this! Indeed looks like
 just an oversight.

 Regards,
 Andrius V

>Unformatted:

Home	PR Database Search