On Tue, 18 Aug 2026 02:02:58 +0200,
Daniel Dickman <didickman@gmail.com> wrote:
> 
> Shouldn't the fix go into OpenBIOS rather than ofwboot getting a 
> work-around?
> 
> Does this bug exist on any real sparc64 hardware?
>

What is a good question and I have no idea about it.

I was able to figure it out because it crashed inside qemu, and here not
that nice way but at least working way to debug such issue.

> 
> On Tue, 18 Aug 2026, Kirill A. Korinsky wrote:
> 
> > tech@,
> > 
> > OpenBIOS's init-program ELF loader claims p_memsz bytes for each
> > segment, but copies only p_filesz bytes and leaves the remaining memory
> > untouched. This lets stale firmware memory appear as initialized BSS.
> > 
> > This became visible after shrinking ofwboot by using not -O2 to build it
> > with LLVM toolchain, tested with -Oz, -Os and -O1.
> > 
> > As result, freelist head moved twelve bytes beyond the file-backed
> > PT_LOAD range and contained an unaligned garbage pointer, causing
> > T_ALIGN in alloc().
> > 
> > Ok?
> > 
> > Index: sys/arch/sparc64/stand/ofwboot/srt0.s
> > ===================================================================
> > RCS file: /home/cvs/src/sys/arch/sparc64/stand/ofwboot/srt0.s,v
> > diff -u -p -r1.8 srt0.s
> > --- sys/arch/sparc64/stand/ofwboot/srt0.s	14 Nov 2025 19:17:13 -0000	1.8
> > +++ sys/arch/sparc64/stand/ofwboot/srt0.s	17 Aug 2026 23:23:37 -0000
> > @@ -92,6 +92,13 @@ _start:
> >  	clr	%g4		! Point %g4 to start of data segment
> >  				! only problem is that apparently the
> >  				! start of the data segment is 0
> > +
> > +	/* OpenBIOS init-program does not clear the ELF BSS. */
> > +	set	__bss_start, %o0
> > +	clr	%o1
> > +	set	_end, %o2
> > +	call	memset
> > +	 sub	%o2, %o0, %o2
> >  	
> >  	/*
> >  	 * XXXXXXXX Need to determine what params are passed
> > 
> > 
> > -- 
> > wbr, Kirill
> > 
> > 
> 

-- 
wbr, Kirill