[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170802043155.GA5455@dora.lan>
Date: Tue, 1 Aug 2017 23:31:55 -0500
From: Bobby Bingham <koorogi@...rogi.info>
To: musl@...ts.openwall.com
Subject: Re: possible bug in setjmp implementation for ppc64
On Tue, Aug 01, 2017 at 11:55:56PM -0400, Rich Felker wrote:
> On Tue, Aug 01, 2017 at 07:28:45PM -0500, Bobby Bingham wrote:
> > On Tue, Aug 01, 2017 at 07:07:59PM -0400, Rich Felker wrote:
> > > On Tue, Aug 01, 2017 at 06:45:33PM -0400, Rich Felker wrote:
> > > > On Tue, Aug 01, 2017 at 08:28:27AM +0300, Alexander Monakov wrote:
> > > > > On Tue, 1 Aug 2017, Bobby Bingham wrote:
> > > > > > I think this either requires having different versions of setjmp/longjmp
> > > > > > for static and dynamic libc,
> > > > >
> > > > > Do you mean for non-pic vs pic objects? As I understand, when libc.a is
> > > > > built with -fpic (so it's suitable for static-pie), setjmp-longjmp need
> > > > > to preserve saved TOC at (r1+24). So presumably source code would need
> > > > > to test #ifdef __PIC__?
> > > > >
> > > > > > or to increase the size of jmpbuf so we can always save/restore both
> > > > > > r2 and the value on the stack, but this would be an ABI change.
> > > > >
> > > > > Would that work for non-pic, i.e. is (r1+24) a reserved location even in
> > > > > non-pic mode? If not, you can't overwrite it from longjmp.
> > > >
> > > > Pretty much certainly so; there is no separate "non-PIC ABI". PIC code
> > > > is just code that doesn't happen to do certain things not permissible
> > > > in PIC. It doesn't have additional permissions to do things that
> > > > otherwise wouldn't be permitted in "non-PIC code".
> > > >
> > > > In any case just saving and restoring both is not an ABI change, since
> > > > there's plenty of free space (896 bits worth of non-existant signals)
> > > > in the jmp_buf due to the "Hurd sigset_t" mess.
> > >
> > > It might also be possible to manually create both the entry points for
> > > setjmp, rather than letting the assembler auto-generate them, in which
> > > case I think the choice of which value to save just depends on which
> > > entry point was used. Thoughts?
> >
> > I like this idea. It's slightly more complicated than that because of
> > the call to setjmp from sigsetjmp, but should still be ok. I'll work on
> > a patch.
>
> Hmm, can you elaborate on the situation with sigsetjmp?
>
sigsetjmp calls setjmp, but I believe this will always use the intra-dso
entry point. Same for the call siglongjmp makes to longjmp. So calls
via sigsetjmp/siglongjmp will always be detected as local calls, even
when the originally caller of jig*jmp is in a different dso.
My plan right now is create a __setjmp_toc function which is identical
to the normal setjmp except that the TOC pointer to save is passed in as
another parameter. setjmp will detect which entry point is used, pull
the TOC pointer from the right place, and call __setjmp_toc. sigsetjmp
will be updated similarly to detect which entry point is used and to
call __setjmp_toc directly instead of going through setjmp.
siglongjmp is current written in C by just calling longjmp. I'm tempted
to just add a "siglongjmp:" label in the asm for longjmp and add an
empty powerpc64/siglongjmp.c file to suppress the default
implementation. I want to ask if there's any reason it wouldn't be
valid for these two functions to have the same address.
> Rich
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.
