[PATCH] kernel: introduce prctl(PR_LOG_UACCESS)

Peter Collingbourne pcc at google.com
Wed Sep 22 15:05:46 PDT 2021


On Wed, Sep 22, 2021 at 12:56 PM Peter Zijlstra <peterz at infradead.org> wrote:
>
> On Wed, Sep 22, 2021 at 03:22:50PM -0400, Steven Rostedt wrote:
> > On Wed, 22 Sep 2021 19:46:47 +0200
> > David Hildenbrand <david at redhat.com> wrote:
> >
> > > > All signals except SIGKILL and SIGSTOP are masked for the interval
> > > > between the prctl() and the next syscall in order to prevent handlers
> > > > for intervening asynchronous signals from issuing syscalls that may
> > > > cause uaccesses from the wrong syscall to be logged.
> > >
> > > Stupid question: can this be exploited from user space to effectively
> > > disable SIGKILL for a long time ... and do we care?
> >
> > I first misread it too, but then caught my mistake reading it a second
> > time. It says "except SIGKILL". So no, it does not disable SIGKILL.
>
> Disabling SIGINT might already be a giant nuisance. Letting through
> SIGSTOP but not SIGCONT seems awkward. Blocking SIGTRAP seems like a bad
> idea too. Blocking SIGBUS as delivered by #MC will be hillarious.

I'm only blocking the signals that are already blockable from
userspace via rt_sigprocmask (which prevents blocking SIGKILL and
SIGSTOP, but allows blocking the others including SIGBUS, for which
the man page states that the result is undefined if synchronously
generated while blocked). So in terms of blocking signals I don't
think this is exposing any new capabilities.

Per the sigaction man page, SIGKILL and SIGSTOP can't have userspace
signal handlers, so we don't need to block them in order to prevent
intervening asynchronous signal handlers (nor do we want to due to the
DoS potential). I would need to double check the behavior but I
believe that for SIGCONT continuing the process is separate from
signal delivery and unaffected by blocking (see prepare_signal in
kernel/signal.c) -- so the SIGCONT will make it continue and the
handler if any would be called once the syscall returns after the
automatic restoration of the signal mask.

Peter



More information about the linux-arm-kernel mailing list