On Wed, 1 May 2024 at 18:19, Kees Cook <keescook@xxxxxxxxxxxx> 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]
