From: Andrew Zaborowski <andrew.zaborowski@intel.com>
To: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH][RFC] exec: x86: Ensure SIGBUS delivered on MCE
Date: Wed, 1 May 2024 20:52:32 +0200 [thread overview]
Message-ID: <CAOq732JjKpeqQze6VpMDTJSvhzjvZCM+HPfdqEp68PSzeW8L3Q@mail.gmail.com> (raw)
In-Reply-To: <SA1PR11MB69929DBECFE6D8503D214359E7192@SA1PR11MB6992.namprd11.prod.outlook.com>
On Wed, 1 May 2024 at 18:19, Kees Cook <keescook@chromium.org> wrote:
> Why is it needed to have a distinction between SIGBUS and SIGSEGV in
> this case?
So this is mostly to comply with
Documentation/mm/hwpoison.rst#failure-recovery-modes. No doc probably
mentions the execve case but users might expect consistency with the
cases where user memory is accessed from userspace.
In our case it was the parent process that was confused by the SIGSEGV
but it was a validation scenario, not a real use case.
>
> > To ensure it is terminated with a SIGBUS we 1. let pending work run in
> > the bprm_execve error case.
> >
> > And 2. ensure memory_failure() is passed MF_ACTION_REQUIRED so that the
> > SIGBUS is queued. Normally when the MCE is in a syscall, a fixup of
> > return IP and a call to kill_me_never are enough. But in this case
> > it's necessary to queue kill_me_maybe() which will set
> > MF_ACTION_REQUIRED.
> >
> > Reuse current->in_execve to make the decision.
>
> We're actually in the process of trying to remove[1] this flag, so I'd
> like to avoid adding new users of it.
Oh, didn't see that.
> It sounds like it's desirable here
> because a choice is needed about kill_me_never() vs kill_me_maybe()?
Ideally it should be based on bprm->point_of_no_return and
current->in_execve matches that closely enough.
Instead bprm_execve could directly send the SIGBUS based on the return
value from the binary loader (which would have to be changed) or a
flag set by the MCE handler but I couldn't see a good way to do that.
Best regards
[I can't set the In-reply-to header correctly for this message, sorry]
prev parent reply other threads:[~2024-05-01 18:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 1:53 [PATCH][RFC] exec: x86: Ensure SIGBUS delivered on MCE Andrew Zaborowski
2024-05-01 16:19 ` Kees Cook
[not found] ` <SA1PR11MB69929DBECFE6D8503D214359E7192@SA1PR11MB6992.namprd11.prod.outlook.com>
2024-05-01 18:52 ` Andrew Zaborowski [this message]
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=CAOq732JjKpeqQze6VpMDTJSvhzjvZCM+HPfdqEp68PSzeW8L3Q@mail.gmail.com \
--to=andrew.zaborowski@intel.com \
--cc=bp@alien8.de \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-mm@kvack.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).