On Sun, Feb 07, 2021 at 10:31:32AM -0800, Andy Lutomirski wrote: > > > On Feb 7, 2021, at 10:19 AM, Dave Hansen <dave.han...@intel.com> wrote: > > > > On 2/7/21 9:58 AM, Borislav Petkov wrote: > >>> On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote: > >>> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov <b...@suse.de> wrote: > >>>> - Disable CET instrumentation in the kernel so that gcc doesn't add > >>>> ENDBR64 to kernel code and thus confuse tracing. > >>> So this is clearly the right thing to do for now, but I wonder if > >>> people have a plan for actually enabling CET and endbr at cpl0 at some > >>> point? > >> It probably is an item on some Intel manager's to-enable list. So far, > >> the CET enablement concentrates only on userspace but dhansen might know > >> more about future plans. CCed. > > > > It's definitely on our radar to look at after CET userspace. > > > > The only question for me is whether it will be worth doing with the > > exiting kernel entry/exit architecture. > > I assume you mean: is anyone sufficiently inspired to try to handle > NMI correctly? I have a whole pile of nacks saved up for incorrect > implementations, although I will try to wrap them in polite > explanations of precisely what is wrong :)
Yeah, the IST stack recursion possibilities are 'fun'. But IIRC CET-SS has far more problems than just NMI. It will also run into all the ROP tricks we pull for return tracing, CALL emulation and other lovely things.
