Re: [PATCH] kernel: introduce prctl(PR_LOG_UACCESS)
From: Peter Collingbourne <hidden>
Date: 2021-09-22 22:07:03
Also in:
lkml
On Wed, Sep 22, 2021 at 12:56 PM Peter Zijlstra [off-list ref] wrote:
On Wed, Sep 22, 2021 at 03:22:50PM -0400, Steven Rostedt wrote:quoted
On Wed, 22 Sep 2021 19:46:47 +0200 David Hildenbrand [off-list ref] wrote:quoted
quoted
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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel