From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <kees@kernel.org>
Cc: Andrew Zaborowski <andrew.zaborowski@intel.com>,
linux-edac@vger.kernel.org, linux-mm@kvack.org,
Tony Luck <tony.luck@intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Borislav Petkov <bp@alien8.de>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
oleg@redhat.com
Subject: Re: [RESEND][PATCH 3/3] rseq: Ensure SIGBUS delivered on memory failure
Date: Tue, 6 Aug 2024 09:51:46 +0200 [thread overview]
Message-ID: <20240806075146.GQ39708@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <202408052136.119CD53B@keescook>
On Mon, Aug 05, 2024 at 09:37:48PM -0700, Kees Cook wrote:
> On Tue, Jul 23, 2024 at 04:47:52PM +0200, Andrew Zaborowski wrote:
> > Uncorrected memory errors for user pages are signaled to processes
> > using SIGBUS or, if the error happens in a syscall, an error retval
> > from the syscall. The SIGBUS is documented in
> > Documentation/mm/hwpoison.rst#failure-recovery-modes
> >
> > Once a user task sets t->rseq in the rseq() syscall, if the kernel
> > cannot access the memory pointed to by t->rseq->rseq_cs, that initial
> > rseq() and all future syscalls should return an error so understandably
> > the code just kills the task.
> >
> > To ensure that SIGBUS is used set the new t->kill_on_efault flag and
> > run queued task work on rseq_get_rseq_cs() errors to give memory_failure
> > the chance to run.
> >
> > Note: the rseq checks run inside resume_user_mode_work() so whenever
> > _TIF_NOTIFY_RESUME is set. They do not run on every syscall exit so
> > I'm not concerned that these extra flag operations are in a hot path,
> > except with CONFIG_DEBUG_RSEQ.
> >
> > Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
> > ---
> > kernel/rseq.c | 25 +++++++++++++++++++++----
>
> Can an rseq maintainer please review this? I can carry it via the execve
> tree with the related patches...
*sigh*,.. because get_maintainers just doesn't work or something?
Anyway, I'm confused by the signal code (as always), why isn't the
task_work_run() in get_signal() sufficient?
At some point we're going to run into trouble with sprinkling
task_work_run() around willy nilly :/
>
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/rseq.c b/kernel/rseq.c
> > index 9de6e35fe..c5809cd13 100644
> > --- a/kernel/rseq.c
> > +++ b/kernel/rseq.c
> > @@ -13,6 +13,7 @@
> > #include <linux/syscalls.h>
> > #include <linux/rseq.h>
> > #include <linux/types.h>
> > +#include <linux/task_work.h>
> > #include <asm/ptrace.h>
> >
> > #define CREATE_TRACE_POINTS
> > @@ -320,6 +321,8 @@ void __rseq_handle_notify_resume(struct ksignal *ksig, struct pt_regs *regs)
> > if (unlikely(t->flags & PF_EXITING))
> > return;
> >
> > + t->kill_on_efault = true;
> > +
> > /*
> > * regs is NULL if and only if the caller is in a syscall path. Skip
> > * fixup and leave rseq_cs as is so that rseq_sycall() will detect and
> > @@ -330,13 +333,18 @@ void __rseq_handle_notify_resume(struct ksignal *ksig, struct pt_regs *regs)
> > if (unlikely(ret < 0))
> > goto error;
> > }
> > - if (unlikely(rseq_update_cpu_node_id(t)))
> > - goto error;
> > - return;
> > + if (likely(!rseq_update_cpu_node_id(t)))
> > + goto out;
> >
> > error:
> > + /* Allow task work to override signr */
> > + task_work_run();
> > +
> > sig = ksig ? ksig->sig : 0;
> > force_sigsegv(sig);
> > +
> > +out:
> > + t->kill_on_efault = false;
> > }
> >
> > #ifdef CONFIG_DEBUG_RSEQ
> > @@ -353,8 +361,17 @@ void rseq_syscall(struct pt_regs *regs)
> >
> > if (!t->rseq)
> > return;
> > - if (rseq_get_rseq_cs(t, &rseq_cs) || in_rseq_cs(ip, &rseq_cs))
> > +
> > + t->kill_on_efault = true;
> > +
> > + if (rseq_get_rseq_cs(t, &rseq_cs) || in_rseq_cs(ip, &rseq_cs)) {
> > + /* Allow task work to override signr */
> > + task_work_run();
> > +
> > force_sig(SIGSEGV);
> > + }
> > +
> > + t->kill_on_efault = false;
> > }
> >
> > #endif
> > --
> > 2.43.0
> >
>
> --
> Kees Cook
next prev parent reply other threads:[~2024-08-06 7:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 14:47 [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE Andrew Zaborowski
2024-07-23 14:47 ` [RESEND][PATCH 2/3] execve: Ensure SIGBUS delivered on memory failure Andrew Zaborowski
2024-07-23 14:47 ` [RESEND][PATCH 3/3] rseq: " Andrew Zaborowski
2024-08-06 4:37 ` Kees Cook
2024-08-06 7:51 ` Peter Zijlstra [this message]
2024-08-06 14:19 ` Mathieu Desnoyers
2024-08-06 4:36 ` [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE Kees Cook
2024-08-06 8:35 ` Borislav Petkov
[not found] ` <SA1PR11MB69926BFE8EFDA7B3C3D84560E7B82@SA1PR11MB6992.namprd11.prod.outlook.com>
2024-08-08 0:01 ` Andrew Zaborowski
2024-08-08 14:56 ` Borislav Petkov
2024-08-09 1:22 ` Andrew Zaborowski
2024-08-09 8:34 ` Borislav Petkov
[not found] ` <SA1PR11MB69927AE28B46583DCB5C97DEE7BA2@SA1PR11MB6992.namprd11.prod.outlook.com>
2024-08-10 1:20 ` Andrew Zaborowski
2024-08-10 3:21 ` Borislav Petkov
2024-08-10 3:55 ` Andrew Zaborowski
2024-08-10 9:25 ` Borislav Petkov
-- strict thread matches above, loose matches on Subject: below --
2024-08-08 2:33 [RESEND][PATCH 3/3] rseq: Ensure SIGBUS delivered on memory failure Andrew Zaborowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240806075146.GQ39708@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrew.zaborowski@intel.com \
--cc=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=ebiederm@xmission.com \
--cc=kees@kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=oleg@redhat.com \
--cc=paulmck@kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox