NetBSD Problem Report #59151

From stix@stix.id.au  Fri Mar  7 04:56:46 2025
Return-Path: <stix@stix.id.au>
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 4DCD61A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  7 Mar 2025 04:56:46 +0000 (UTC)
Message-Id: <20250307045636.D358519E85@stix.id.au>
Date: Fri,  7 Mar 2025 15:56:36 +1100 (AEDT)
From: stix@stix.id.au
Reply-To: stix@stix.id.au
To: gnats-bugs@NetBSD.org
Subject: efiboot hangs on new motherboard
X-Send-Pr-Version: 3.95

>Number:         59151
>Category:       misc
>Synopsis:       efiboot hangs on new motherboard
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 07 05:00:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Sun May 24 09:15:02 +0000 2026
>Originator:     Paul Ripke
>Release:        NetBSD 10.1_STABLE
>Organization:
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.
>Environment:
System: NetBSD slave 10.1_STABLE NetBSD 10.1_STABLE (SLAVE) #13: Sun Jan 26 21:19:05 AEDT 2025 stix@slave:/home/netbsd/netbsd-10/obj.amd64/home/netbsd/netbsd-10/src/sys/arch/amd64/compile/SLAVE amd64
Architecture: x86_64
Machine: amd64
>Description:
Booting live image, install image, etc, from USB hangs apparently after
loading efiboot, leaving a blank screen with a text-mode cursor in the top
left.
This is on a new Gigabyte B650M DS3H motherboard with latest BIOS/firmware.

>How-To-Repeat:
Try booting one of these motherboards.
>Fix:
I suspect that this firmware implements memory protection on the efiboot
image. I also assume that the variables written to as defined in the asm
are read-only, generating an exception, resulting in a silent hang.

This patch fixes it for me:

diff --git a/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c b/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c
index feb51595eda2..b34505461bc4 100644
--- a/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c
+++ b/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c
@@ -30,14 +30,14 @@

 #include <sys/bootblock.h>

-void startprog64_start(physaddr_t, physaddr_t, physaddr_t, u_long,
+extern void startprog64_start(physaddr_t, physaddr_t, physaddr_t, u_long,
     void *, physaddr_t);
-extern void (*startprog64)(physaddr_t, physaddr_t, physaddr_t, u_long,
+void (*startprog64)(physaddr_t, physaddr_t, physaddr_t, u_long,
     void *, physaddr_t);
 extern u_int startprog64_size;

-void multiboot64_start(physaddr_t, physaddr_t, uint32_t);
-extern void (*multiboot64)(physaddr_t, physaddr_t, uint32_t);
+extern void multiboot64_start(physaddr_t, physaddr_t, uint32_t);
+void (*multiboot64)(physaddr_t, physaddr_t, uint32_t);
 extern u_int multiboot64_size;

 void
diff --git a/sys/arch/i386/stand/efiboot/bootx64/multiboot64.S b/sys/arch/i386/stand/efiboot/bootx64/multiboot64.S
index 96757aeccc03..cb040d27b86a 100644
--- a/sys/arch/i386/stand/efiboot/bootx64/multiboot64.S
+++ b/sys/arch/i386/stand/efiboot/bootx64/multiboot64.S
@@ -6,10 +6,6 @@
 #define DATA_SEGMENT    0x10

 	.align	16
-	.globl _C_LABEL(multiboot64)
-_C_LABEL(multiboot64):
-	.quad 0
-
 	.globl _C_LABEL(multiboot64_size)
 _C_LABEL(multiboot64_size):
 	.long multiboot64_end - _C_LABEL(multiboot64_start)
diff --git a/sys/arch/i386/stand/efiboot/bootx64/startprog64.S b/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
index 050e3068a243..0c2643a7254d 100644
--- a/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
+++ b/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
@@ -66,10 +66,6 @@ WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 #define	DATA_SEGMENT	0x10

 	.align	16
-	.globl _C_LABEL(startprog64)
-_C_LABEL(startprog64):
-	.quad 0
-
 	.globl _C_LABEL(startprog64_size)
 _C_LABEL(startprog64_size):
 	.long startprog64_end - _C_LABEL(startprog64_start)

>Release-Note:

>Audit-Trail:
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/59151: efiboot hangs on new motherboard
Date: Fri, 7 Mar 2025 10:21:45 +0000 (UTC)

 On Fri, 7 Mar 2025, stix@stix.id.au wrote:

 >> Fix:
 > I suspect that this firmware implements memory protection on the efiboot
 > image. I also assume that the variables written to as defined in the asm
 > are read-only, generating an exception, resulting in a silent hang.
 >

 Yeah, I think this makes sense. Can you see if the patch below also fixes
 this issue?

 ```
 diff -urN a/src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S b/src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
 --- a/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2023-06-24 05:31:04.000000000 +0000
 +++ b/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2025-03-07 10:11:13.394064579 +0000
 @@ -65,6 +65,7 @@
   #define	CODE_SEGMENT	0x08
   #define	DATA_SEGMENT	0x10

 +	.data
   	.align	16
   	.globl _C_LABEL(startprog64)
   _C_LABEL(startprog64):
 ```

 Thx,
 -RVP

From: Paul Ripke <stix@stix.id.au>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, stix@stix.id.au
Subject: Re: misc/59151: efiboot hangs on new motherboard
Date: Fri, 7 Mar 2025 21:56:28 +1100

 On Fri, Mar 07, 2025 at 10:25:01AM +0000, RVP via gnats wrote:
 >  On Fri, 7 Mar 2025, stix@stix.id.au wrote:
 >  
 >  >> Fix:
 >  > I suspect that this firmware implements memory protection on the efiboot
 >  > image. I also assume that the variables written to as defined in the asm
 >  > are read-only, generating an exception, resulting in a silent hang.
 >  >
 >  
 >  Yeah, I think this makes sense. Can you see if the patch below also fixes
 >  this issue?
 >  
 >  ```
 >  diff -urN a/src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S b/src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
 >  --- a/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2023-06-24 05:31:04.000000000 +0000
 >  +++ b/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2025-03-07 10:11:13.394064579 +0000
 >  @@ -65,6 +65,7 @@
 >    #define	CODE_SEGMENT	0x08
 >    #define	DATA_SEGMENT	0x10
 >  
 >  +	.data
 >    	.align	16
 >    	.globl _C_LABEL(startprog64)
 >    _C_LABEL(startprog64):
 >  ```

 Interesting... when I saw what the code was doing, I decided to clean it
 up - afaict, there's no need for writable symbols in the asm.

 Anyway, I expected your very simple patch to work - but it doesn't!
 I get what looks to be the same hang. I've removed all my debug prints
 else I'd confirm if it was hanging at the same point, but it is a pretty
 safe assumption it is.

 -- 
 Paul Ripke
 "Great minds discuss ideas, average minds discuss events, small minds
  discuss people."
 -- Disputed: Often attributed to Eleanor Roosevelt. 1948.

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Paul Ripke <stix@stix.id.au>
Cc: RVP <rvp@SDF.ORG>,
	netbsd-bugs@NetBSD.org, gnats-bugs@NetBSD.org
Subject: Re: misc/59151: efiboot hangs on new motherboard
Date: Thu, 21 May 2026 12:35:37 +0000

 > Date: Fri, 7 Mar 2025 21:56:28 +1100
 > From: Paul Ripke <stix@stix.id.au>
 >=20
 > On Fri, Mar 07, 2025 at 10:25:01AM +0000, RVP via gnats wrote:
 > >  On Fri, 7 Mar 2025, stix%stix.id.au@localhost wrote:
 > > =20
 > >  >> Fix:
 > >  > I suspect that this firmware implements memory protection on the efi=
 boot
 > >  > image. I also assume that the variables written to as defined in the=
  asm
 > >  > are read-only, generating an exception, resulting in a silent hang.
 > >  >
 > > =20
 > >  Yeah, I think this makes sense. Can you see if the patch below also fi=
 xes
 > >  this issue?
 > > =20
 > >  ```
 > >  diff -urN a/src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S b/sr=
 c/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
 > >  --- a/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2023-06-24 05:=
 31:04.000000000 +0000
 > >  +++ b/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2025-03-07 10:=
 11:13.394064579 +0000
 > >  @@ -65,6 +65,7 @@
 > >    #define	CODE_SEGMENT	0x08
 > >    #define	DATA_SEGMENT	0x10
 > > =20
 > >  +	.data
 > >    	.align	16
 > >    	.globl _C_LABEL(startprog64)
 > >    _C_LABEL(startprog64):
 > >  ```
 >=20
 > Interesting... when I saw what the code was doing, I decided to clean it
 > up - afaict, there's no need for writable symbols in the asm.
 >=20
 > Anyway, I expected your very simple patch to work - but it doesn't!
 > I get what looks to be the same hang. I've removed all my debug prints
 > else I'd confirm if it was hanging at the same point, but it is a pretty
 > safe assumption it is.

 Did you also apply the same change to add `.data' to multiboot64.S?

 Because efi_md_init writes to both startprog64 and multiboot64,
 unconditionally, even if the bootloader will only use one or the other
 later on:

      43 void
      44 efi_md_init(void)
      45 {
 ...
      57 	startprog64 =3D (void *)addr;
 ...
      67 	multiboot64 =3D (void *)addr;

 https://nxr.NetBSD.org/xref/src/sys/arch/i386/stand/efiboot/bootx64/efiboot=
 x64.c?r=3D1.6#43

 If so, that would explain the mystery of the difference between those
 two patches.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59151 CVS commit: src/sys/arch/i386/stand/efiboot
Date: Thu, 21 May 2026 16:59:04 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Thu May 21 16:59:04 UTC 2026

 Modified Files:
 	src/sys/arch/i386/stand/efiboot/bootia32: efibootia32.c multiboot32.S
 	    startprog32.S
 	src/sys/arch/i386/stand/efiboot/bootx64: efibootx64.c multiboot64.S
 	    startprog64.S

 Log Message:
 x86/efiboot: Put writable variables in .data, not .text.

 And define them in the .c file where they're used; no need to have
 extra unnecessary .S stuff just to define a global variable.

 Based on patch by Paul Ripke to bootx64.efi, adapted for bootia32.efi
 too.

 PR kern/59151: efiboot hangs on new motherboard


 To generate a diff of this commit:
 cvs rdiff -u -r1.8 -r1.9 \
     src/sys/arch/i386/stand/efiboot/bootia32/efibootia32.c
 cvs rdiff -u -r1.2 -r1.3 \
     src/sys/arch/i386/stand/efiboot/bootia32/multiboot32.S
 cvs rdiff -u -r1.3 -r1.4 \
     src/sys/arch/i386/stand/efiboot/bootia32/startprog32.S
 cvs rdiff -u -r1.6 -r1.7 src/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c
 cvs rdiff -u -r1.1 -r1.2 \
     src/sys/arch/i386/stand/efiboot/bootx64/multiboot64.S
 cvs rdiff -u -r1.5 -r1.6 \
     src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S

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

State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 21 May 2026 17:02:05 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-11, pullup-10, pullup-9


From: Paul Ripke <stix@stix.id.au>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, stix@stix.id.au
Subject: Re: PR/59151 CVS commit: src/sys/arch/i386/stand/efiboot
Date: Sun, 24 May 2026 18:37:34 +1000

 Confirmed - current live image now boots fine on my machine.

 -- 
 Paul Ripke
 "Great minds discuss ideas, average minds discuss events, small minds
  discuss people."
 -- Disputed: Often attributed to Eleanor Roosevelt. 1948.

From: RVP <rvp@SDF.ORG>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Paul Ripke <stix@stix.id.au>, gnats-bugs@NetBSD.org
Subject: Re: misc/59151: efiboot hangs on new motherboard
Date: Sun, 24 May 2026 09:14:11 +0000 (UTC)

 On Thu, 21 May 2026, Taylor R Campbell wrote:

 > Did you also apply the same change to add `.data' to multiboot64.S?
 >
 > Because efi_md_init writes to both startprog64 and multiboot64,
 > unconditionally, even if the bootloader will only use one or the other
 > later on:
 >
 >     43 void
 >     44 efi_md_init(void)
 >     45 {
 > ...
 >     57 	startprog64 = (void *)addr;
 > ...
 >     67 	multiboot64 = (void *)addr;
 >

 Ah... I missed that bit.

 > https://nxr.NetBSD.org/xref/src/sys/arch/i386/stand/efiboot/bootx64/efibootx64.c?r=1.6#43
 >
 > If so, that would explain the mystery of the difference between those
 > two patches.
 >

 Yup, that would account for it.

 -RVP

>Unformatted:

Home	PR Database Search