On Fri, Dec 02, 2022 at 04:35:34PM -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. Refactor this fault handler into sparate user and kernel handlers, > like the page fault handler. Add a control-protection handler for usermode. > > 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 > !cpu_feature_enabled(). 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> > Co-developed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > Signed-off-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> This looks nice cleaner to me. Thanks! Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook