linux-kernel - Re: [RFC][CFT] signal handling fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Aug 2021 11:42:12 +1000 (AEST)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     Al Viro <viro@...iv.linux.org.uk>
cc:     linux-m68k@...ts.linux-m68k.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Greg Ungerer <gerg@...ux-m68k.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][CFT] signal handling fixes

Hi Al,

On Tue, 27 Jul 2021, Al Viro wrote:

> Set a handler of e.g. SIGALRM with sigaction(), with a couple of other 
> signals in sa_mask (e.g. SIGUSR1 and SIGUSR2).  With raise() on those 
> inside the SIGALRM handler - then they will become deliverable on return 
> from handler. And have SIGUSR1 and SIGUSR2 handlers print siginfo and 
> ucontext contents (have them set with SA_SIGINFO in sa_flags, look at 
> the second and third arguments of sighandler).
> 
> Use alarm(2) to arrange for SIGALRM and sit in a tight loop - that'll 
> give you delivery on return from interrupt.  Alternatively, 
> raise(SIGALRM) will give you delivery on return from trap.  And making 
> that a SIGBUS handler instead, mmapping a file, truncating it to 0 and 
> dereferencing something in mmapped area will give you delivery on return 
> from access error trap.  Division by zero (and insertion handler on 
> SIGFPE) ought to give you a type 2 exception stack frame (4 bytes of aux 
> data, that makes shifted exception frame bugger format and vector fields 
> of the original).
> 
> FWIW, the third argument of handler points to
> struct ucontext {
>         unsigned long     uc_flags;
>         struct ucontext  *uc_link;
>         stack_t           uc_stack;
>         struct mcontext   uc_mcontext;
>         unsigned long     uc_filler[80];
>         sigset_t          uc_sigmask;   /* mask last for extensibility */
> };
> and type/vector is stored in uc_filler[54] (216 bytes into the array), 
> with aux data from exception stack frame starting from uc_filler[55].
> 

I wrote the attached program to implement those tests. I linked it 
statically and ran it under "setarch m68k --addr-no-randomize" on three 
systems: Aranym, Qemu and Quadra 630. On each system I tested two builds, 
1) stock 5.14.0-rc4 and 2) your "untested.m68k" branch rebased onto same.

Everything appears to work normally. I didn't see differences in ucontext 
data between mainline build and patched builds, that is, after omitting 
"random" differences that always occur from one test run to the next.

(Despite my attempt to avoid random addresses, repeating any test produced 
some "random" values in uc_filler. I didn't try to find out what these 
values represent. They appear in both builds.)

Do I need to run the program under gdb or strace to see the effect of your 
changes?

BTW, I did see some differences between the Motorola 68040 and the 
emulated 68040 CPUs.

On the Motorola CPU, uc_filler[54] is 0x00000078 for the signals delivered 
on return from interrupt, but Qemu has 0x00000064 and Aranym has either 
0x00000070 or 0x00000114.

Another discrepancy is uc_filler[55..67] for the SIGBUS case:

Motorola:
000000d0    ffffffff ffffffff 00007008 effffc90    ..........p.....
000000e0    05210001 00210001 c0000000 00985fec    .!...!........_.
000000f0    0000001e 8006aeae 80000e94 0000001e    ................
00000100    00000004 00000000 00008001 574c0080    ............WL..

Aranym:
000000d0    ffffffff ffffffff 00007008 c0000000    ..........p.....
000000e0    05210000 00000000 c0000000 c0000000    .!..............
000000f0    8000817c 00000000 00000000 00000000    ...|............
00000100    00000000 00000000 00000000 00000000    ................

Qemu:
000000d0    ffffffff ffffffff 00007008 c0000000    ..........p.....
000000e0    05210000 00000000 c0000000 c0000000    .!..............
000000f0    00000000 00000000 00000000 00000000    ................
00000100    00000000 00000000 00000000 00000000    ................

The other signals don't show discrepancies in uc_filler across CPU types 
(that is, after omitting "random" values).

I wonder whether the deviation in emulator behaviour could have 
consequences. E.g. I have heard a bug report relating to gdb under 
qemu-system-m68k. Perhaps there's a connection.
Download attachment "nohup.out-5.14.0-rc4-multi-00003-g420aec9e726e-aranym" of type "application/octet-stream" (16732 bytes)

Download attachment "nohup.out-5.14.0-rc4-multi-00003-g420aec9e726e-q630" of type "application/octet-stream" (17702 bytes)

Download attachment "nohup.out-5.14.0-rc4-multi-00003-g420aec9e726e-qemu" of type "application/octet-stream" (17754 bytes)

Download attachment "nohup.out-5.14.0-rc4-multi-aranym" of type "application/octet-stream" (16712 bytes)

Download attachment "nohup.out-5.14.0-rc4-multi-q630" of type "application/octet-stream" (17682 bytes)

Download attachment "nohup.out-5.14.0-rc4-multi-qemu" of type "application/octet-stream" (17734 bytes)

View attachment "sig.c" of type "text/x-c" (2678 bytes)