[Sorry if I'm breaking threading]
Borislav Petkov <bp@xxxxxxxxx> wrote:
> On August 6, 2024 7:36:40 AM GMT+03:00, Kees Cook <kees@xxxxxxxxxx> 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
