Re: qemu-ppc64-linux-user: signal handler endianness in elfv2

[Vincent Fazio]

David,

On 3/16/20 6:20 PM, David Gibson wrote:
> On Mon, Mar 16, 2020 at 04:26:57PM -0500, Vincent Fazio wrote:
> > David,
> >
> > On 3/16/20 3:43 AM, David Gibson wrote:
> > The copy from guest memory should be the case. In the specific scenario i'm
> > testing:
> >
> > https://github.com/openssl/openssl/blob/master/crypto/ppccap.c#L372
> >
> >      memset(&ill_act, 0, sizeof(ill_act));
> >      ill_act.sa_handler = ill_handler;
> >      ill_act.sa_mask = all_masked;
> >
> >      sigprocmask(SIG_SETMASK, &ill_act.sa_mask, &oset);
> >      sigaction(SIGILL, &ill_act, &ill_oact);
> >
> > MUSL's sigaction:
> >
> > http://git.musl-libc.org/cgit/musl/tree/src/signal/sigaction.c#n26
> >
> > When ill_act.sa_handler is set, ill_handler is in little endian
> Uh.. what?  That openssl code is running on the guest/target side,
> yes?  Which is big-endian?  In which case I'd expect ill_handler, and
> therefore .sa_handler to also be big-endian...

I'm an idiot, which should come as no big surprise.

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
`/home/vfazio/development/qemu/ppc64-linux-user/qemu-ppc64' has changed; 
re-reading symbols.
Starting program: 
/home/vfazio/development/qemu/ppc64-linux-user/qemu-ppc64 -E 
LD_LIBRARY_PATH="output/target/lib/:output/target/usr/lib/" -cpu e6500 
output/target/lib/ld-musl-powerpc64.so.1 output/target/usr/bin/openssl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff9700 (LWP 14506)]
00 00 00 40 01 AF 10 14
DEBUG: 4001af1014

act handler: 1410af0140000000
k handler: 4001af1014

Thread 1 "qemu-ppc64" received signal SIGSEGV, Segmentation fault.
0x000000006005ba51 in ldl_he_p (ptr=0x1410af0140000000) at 
/home/vfazio/development/qemu/include/qemu/bswap.h:351
351        __builtin_memcpy(&r, ptr, sizeof(r));

QEMU is already doing the endian swap in do_sigaction

    if (act) {
        __get_user(k->_sa_handler, &act->_sa_handler); //this does the 
endian swap

This obviates the need for the swap of k->_sa_handler in 
setup_rt_frame... so the fix is the same, the reasoning is different.

I would still like to get the HOST vs TARGET terminology straightened 
out however.

> > and is
> > copied that way when running on an x86 machine emulating an E6500 BE CPU.
> >
> > I've added a quick debug statement:
> >
> > vfazio@vfazio1 ~/development/br-xfs $ grep printf
> > output/build/libopenssl-1.1.1d/crypto/ppccap.c
> >      printf("DEBUG: %llx\n", &ill_handler);
> >
> > (gdb) run -E LD_LIBRARY_PATH="output/target/lib/:output/target/usr/lib/"
> > -cpu e6500 output/target/lib/ld-musl-powerpc64.so.1
> > output/target/usr/bin/openssl
> > Starting program: /home/vfazio/development/qemu/ppc64-linux-user/qemu-ppc64
> > -E LD_LIBRARY_PATH="output/target/lib/:output/target/usr/lib/" -cpu e6500
> > output/target/lib/ld-musl-powerpc64.so.1 output/target/usr/bin/openssl
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > [New Thread 0x7ffff7ff9700 (LWP 6135)]
> > DEBUG: 4000af1014
> .. as indeed it appears to be (it's a target-side printf() so it
> should print BE values correctly).
>
> To be really sure, you could change the printf to explicitly print
> ill_handler byte by byte.
>
> > Thread 1 "qemu-ppc64" received signal SIGSEGV, Segmentation fault.
> > 0x00000000600a9257 in ldl_he_p (ptr=0x1410af0040000000) at
> > /home/vfazio/development/qemu/include/qemu/bswap.h:351
> > 351        __builtin_memcpy(&r, ptr, sizeof(r));
> >
> >
> > I suppose there could be a double endian swap, once when handling the
> > sigaction call and back when handling the signal, but is there much of a
> > benefit of doing that?
> Yes, if it means data in itermin structures is in the right
> endiannness for its context.  Plus, the two swaps may be conditional
> on different conditions - they end up cancelling out in your case, but
> with other combinations we may only want one of them to act.
--
Vincent Fazio
Embedded Software Engineer - Linux
Extreme Engineering Solutions, Inc
http://www.xes-inc.com