On Mon, 2024-11-04 at 08:26 -0800, Dave Hansen wrote: > On 11/4/24 08:13, Shah, Amit wrote: > > I want to justify that not setting X86_FEATURE_RSB_CTXSW is still > > doing > > the right thing, albeit in hardware. > > Let's back up a bit. > > In the kernel, we have security concerns if RSB contents remain > across > context switches. If process A's RSB entries are left and then > process > B uses them, there's a problem. > > Today, we mitigate that issue with manual kernel RSB state zapping on > context switches (X86_FEATURE_RSB_CTXSW). > > You're saying that this fancy new ERAPS feature includes a new > mechanism > to zap RSB state. But that only triggers "each time a TLB flush > happens". > > So what you're saying above is that you are concerned about RSB > contents > sticking around across context switches. But instead of using > X86_FEATURE_RSB_CTXSW, you believe that the new TLB-flush-triggered > ERAPS flush can be used instead. > > Are we all on the same page so far? All good so far. > I think you're wrong. We can't depend on ERAPS for this. Linux > doesn't > flush the TLB on context switches when PCIDs are in play. Thus, > ERAPS > won't flush the RSB and will leave bad state in there and will leave > the > system vulnerable. > > Or what am I missing? I just received confirmation from our hardware engineers on this too: 1. the RSB is flushed when CR3 is updated 2. the RSB is flushed when INVPCID is issued (except type 0 - single address). I didn't mention 1. so far, which led to your question, right? Does this now cover all the cases? Amit
