Re: [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE

Andrew Zaborowski
2024-08-08T00:01:58Z

[Sorry if I'm breaking threading]

Borislav Petkov <bp@alien8.de> wrote:
> On August 6, 2024 7:36:40 AM GMT+03:00, Kees Cook <kees@kernel.org> wrote:
> >> While not explicitly stated, it can be argued that it
> >> should be a SIGBUS, for consistency and for the benefit of the userspace
> >> signal handlers. Even if the process cannot handle the signal, perhaps
> >> the parent process can. This was the case in the scenario that
> >> motivated this patch.
>
> I have no clue what that is trying to tell me.

Documentation/mm/hwpoison.rst#failure-recovery-modes documents the
SIGBUS on memory failure behavior:

Send SIGBUS when the application runs into the corrupted page.

There may be other docs that specify this behavior but I didn't find
them. To me this implies that when userspace code directly accesses
poisoned memory it should receive a SIGBUS but not sure if the wording
also implies a SIGBUS on a kernel access on behalf of userspace, i.e.
in a syscall. Hence why I said "not explicitly stated".

Now I'm not sure it matters. Logically if a program wants to handle
memory errors, or its parent process wants to know the child was
killed because of a HW problem, it probably doesn't care whether the
page was accessed directly or indirectly so it expects a SIGBUS
always. Tony Luck also seemed to agree this was the expected behavior
when commenting on this on a different forum.

Best regards