On Thu, Jan 19, 2023 at 01:22:45PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> > > A control-protection fault is triggered when a control-flow transfer > attempt violates Shadow Stack or Indirect Branch Tracking constraints. > For example, the return address for a RET instruction differs from the copy > on the shadow stack. > > There already exists a control-protection fault handler for handling kernel > IBT faults. Refactor this fault handler into separate user and kernel > handlers, like the page fault handler. Add a control-protection handler > for usermode. To avoid ifdeffery, put them both in a new file cet.c, which > is compiled in the case of either of the two CET features supported in the > kernel: kernel IBT or user mode shadow stack. Move some static inline > functions from traps.c into a header so they can be used in cet.c. > > Opportunistically fix a comment in the kernel IBT part of the fault > handler that is on the end of the line instead of preceding it. > > Keep the same behavior for the kernel side of the fault handler, except for > converting a BUG to a WARN in the case of a #CP happening when the feature > is missing. This unifies the behavior with the new shadow stack code, and > also prevents the kernel from crashing under this situation which is > potentially recoverable. > > The control-protection fault handler works in a similar way as the general > protection fault handler. It provides the si_code SEGV_CPERR to the signal > handler. > > Tested-by: Pengfei Xu <pengfei.xu@xxxxxxxxx> > Tested-by: John Allen <john.allen@xxxxxxx> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> This diff would have been a bit easier to review if the file move was separate from the addition of the handler, but regardless: Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook
