Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Feb 2024 18:06:46 +0300
From: Valery Ushakov <uwe@...err.spb.ru>
To: musl@...ts.openwall.com, toybox <toybox@...ts.landley.net>
Subject: Re: Re: Not sure how to debug this one.

On Sun, Feb 18, 2024 at 09:33:13 -0500, Rich Felker wrote:

> On Sun, Feb 18, 2024 at 03:55:36PM +0300, Valery Ushakov wrote:
> > On Sat, Feb 17, 2024 at 20:40:50 -0500, Rich Felker wrote:
> > 
> > > due to incorrect base address register when attempting to reload the
> > > saved value of r8, the caller's value of r8 was not preserved.
> > > ---
> > >  src/signal/sh/sigsetjmp.s | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/signal/sh/sigsetjmp.s b/src/signal/sh/sigsetjmp.s
> > > index 1e2270be..f0f604e2 100644
> > > --- a/src/signal/sh/sigsetjmp.s
> > > +++ b/src/signal/sh/sigsetjmp.s
> > > @@ -27,7 +27,7 @@ __sigsetjmp:
> > >  
> > >  	mov.l 3f, r0
> > >  4:	braf r0
> > > -	 mov.l @(4+8,r4), r8
> > > +	 mov.l @(4+8,r6), r8
> > >  
> > >  9:	mov.l 5f, r0
> > >  6:	braf r0
> > 
> > That takes care of restoring caller's r8 for the first return from
> > sigsetjmp, but isn't there still the problem that the jump buffer
> > contains the wrong one, so on the second return from sigsetjmp the
> > caller will have clobbered r8?
> > 
> > Sorry for a drive-by reply.  I'll try to take a closer look in the
> > evening.
> 
> No, that's the return path for both returns.
>
> The whole reason a call-saved register like r8 is used here is so
> that we can return twice into the body of sigsetjmp, in order to
> tailcall __sigsetjmp_tail at both the first return and subsequent
> return.

Doh, right!  Sorry.  A comment to that effect to alert the reader
would certainly have helped :) Neat trick that I missed on the quick
reading.


> This is what makes it possible to restore the signal mask from the
> returned-to frame rather than the returning-from frame (which is why
> the attached doesn't crash with stack overflow on musl like it does
> on glibc).

Restoring the context in siglongjmp should not be a problem per-se.
NetBSD libc does that and the example code doesn't crash there (quick
unscientific test on a ppc that I happen to have a terminal open on).
But then NetBSD libc doesn't bother to carefully factor that code to
minimize the need for MD asm.

Thanks, and sorry for the noise.

-uwe

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.