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 for Android: free password hash cracker in your pocket

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

Message-ID: <YQAbTazP4/JB8Aas@zeniv-ca.linux.org.uk>
Date:   Tue, 27 Jul 2021 14:42:21 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Finn Thain <fthain@...ux-m68k.org>
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

On Tue, Jul 27, 2021 at 08:21:52PM +1000, Finn Thain wrote:
> On Sun, 25 Jul 2021, Al Viro wrote:
> 
> > 
> > 	The series is on top of 5.14-rc1; it lives in
> > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #untested.m68k
> > Individual patches in followups...
> > 
> > 	_Very_ lightly tested on aranym; no real hardware to test it on.
> > Any help with review and testing would be very welcome.
> > 
> 
> I can test this branch on a Motorola 68040 machine I have here. Can you 
> advise how to get decent code coverage? Maybe there's a package out there 
> with a signal-heavy test suite? Maybe I need a break point in a signal 
> handler? Or perhaps just send ^C to a process running under strace?

Generally, SIGINT is not the best insertion vector...

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].