kern/59235: efi(8) panics

[mlelstv%netbsd.org@localhost]

>Number:         59235
>Category:       kern
>Synopsis:       efi(8) panics
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 30 08:55:00 +0000 2025
>Originator:     Michael van Elst
>Release:        NetBSD 10.99.12
>Organization:
>Environment:
	
	
System: NetBSD tazz 10.99.12 NetBSD 10.99.12 (TAZZ) #7: Sat Mar 29 20:45:44 UTC 2025 mlelstv@slowpoke:/scratch2/obj.amd64/scratch/netbsd-current/src/sys/arch/amd64/compile/TAZZ amd64
Architecture: x86_64
Machine: amd64
>Description:
Running efi without arguments causes a kernel panic.

With a LOCKDEBUG kernel you get this:

[ 39236.0798177] Mutex error: rw_vector_enter,304: spin lock held

[ 39236.0798177] lock address : netbsd:efi_runtime_lock
[ 39236.0798177] type         : spin
[ 39236.0798177] initialized  : netbsd:efi_init+0x2e6
[ 39236.0798177] shared holds :                  0 exclusive:                  1

[ 39236.0798177] shares wanted:                  0 exclusive:                  0

[ 39236.0798177] relevant cpu :                  0 last held:                  0

[ 39236.0798177] relevant lwp : 0xffff8723827b9800 last held: 0xffff8723827b9800

[ 39236.0798177] last locked* : netbsd:efi_runtime_enter+0x22
[ 39236.0798177] unlocked     : 0
[ 39236.0798177] owner field  : 0x0000000000010600 wait/spin:                0/1


[ 39236.0820692] panic: LOCKDEBUG: Mutex error: rw_vector_enter,304: spin lock h
eld
[ 39236.0820692] cpu0: Begin traceback...
[ 39236.0820692] vpanic() at netbsd:vpanic+0x171
[ 39236.0820692] panic() at netbsd:panic+0x3c
[ 39236.0820692] lockdebug_abort1() at netbsd:lockdebug_abort1+0xe4
[ 39236.0820692] rw_enter() at netbsd:rw_enter+0x80
[ 39236.0820692] uvm_fault_internal() at netbsd:uvm_fault_internal+0x12b
[ 39236.0820692] trap() at netbsd:trap+0x3a7
[ 39236.0820692] --- trap (number 6) ---
[ 39236.0820692] ?() at dab1bd08
[ 39236.0820692] cpu0: End traceback...
[ 39236.0820692] fatal breakpoint trap in supervisor mode
[ 39236.0820692] trap type 1 code 0 rip 0xffffffff8023541d cs 0x8 rflags 0x202 c
r2 0xd6202288 ilevel 0x8 rsp 0xffff8f82b1f675e0
[ 39236.0820692] curlwp 0xffff8723827b9800 pid 5708.5708 lowest kstack 0xffff8f8
2b1f632c0
Stopped in pid 5708.5708 (efi) at       netbsd:breakpoint+0x5:  leave
db{0}>


However, this seems to be a consequence of generating a trap while holding
a spinlock.


gdb shows more stack frames:

...
#11 0xffffffff809c32b8 in panic (
    fmt=fmt@entry=0xffffffff80eb3828 "LOCKDEBUG: %s error: %s,%zu: %s")
    at /scratch/netbsd-current/src/sys/kern/subr_prf.c:209
#12 0xffffffff809b6c8b in lockdebug_abort1 (dopanic=true, 
    msg=0xffffffff80e2bee8 "spin lock held", s=6, ld=0xffff8f800fc07240, 
    line=304, func=0xffffffff80db9680 <__func__.6> "rw_vector_enter")
    at /scratch/netbsd-current/src/sys/kern/subr_lockdebug.c:818
#13 lockdebug_abort1 (func=0xffffffff80db9680 <__func__.6> "rw_vector_enter", 
    line=304, ld=0xffff8f800fc07240, s=6, 
    msg=0xffffffff80e2bee8 "spin lock held", dopanic=<optimized out>)
    at /scratch/netbsd-current/src/sys/kern/subr_lockdebug.c:796
#14 0xffffffff80980386 in rw_vector_enter (rw=0xffff872377e3a3c8, op=RW_READER)
    at /scratch/netbsd-current/src/sys/kern/kern_rwlock.c:304
#15 0xffffffff8091708e in vm_map_lock_read (map=<optimized out>)
    at /scratch/netbsd-current/src/sys/uvm/uvm_map.c:726
#16 0xffffffff8090f92b in uvmfault_lookup (write_lock=false, 
    ufi=0xffff8f82b1f67800)
    at /scratch/netbsd-current/src/sys/uvm/uvm_fault_i.h:122
#17 uvm_fault_check (maxprot=false, ranons=<synthetic pointer>, 
    flt=0xffff8f82b1f67838, ufi=0xffff8f82b1f67800)
    at /scratch/netbsd-current/src/sys/uvm/uvm_fault.c:992
#18 uvm_fault_internal (orig_map=orig_map@entry=0xffff872377e3a3c0, 
    vaddr=vaddr@entry=3592429568, access_type=access_type@entry=1, 
    fault_flag=fault_flag@entry=0)
    at /scratch/netbsd-current/src/sys/uvm/uvm_fault.c:902
#19 0xffffffff8023c180 in trap (frame=0xffff8f82b1f67aa0)
    at /scratch/netbsd-current/src/sys/arch/amd64/amd64/trap.c:519
#20 0xffffffff80234ad4 in alltraps ()
#21 0x00000000dab1bd08 in ?? ()
#22 0xffff8f82b1f67c08 in ?? ()
#23 0xffff8f82b1f67c50 in ?? ()
#24 0xffff87236d797000 in ?? ()
#25 0xffff8f82b1f67ef0 in ?? ()
#26 0x0000000000000100 in ?? ()
#27 0xffff8f82b1f67ef0 in ?? ()
#28 0xffff87236d797000 in ?? ()
#29 0xffff8f82b1f67c50 in ?? ()
#30 0xffff87247411c000 in ?? ()
#31 0xffffffff8058fb25 in efi_runtime_nextvar (namesize=0x0, 
    name=0xffff87236d797000, vendor=0xffff8f82b1f67ef0)
    at /scratch/netbsd-current/src/sys/arch/x86/x86/efi_machdep.c:948
#32 0xffff87230d781080 in ?? ()
#33 0x0000000000000000 in ?? ()


Calling efi_runtime_nextvar with namesize==NULL might be reason. Also,
name points to just NUL-Bytes. But the arguments are questionable, there
is only one place where efi_nextvar() is called (in sys/dev/efi.c), and
the namesize argument is the pointer to a local variable &namesize that
cannot possibly be NULL.


>How-To-Repeat:
Run efi(8) without arguments as root or member of wheel.
>Fix:
	

>Unformatted: