On 10/23/23 15:30, Pawan Gupta wrote: >>>>> /* >>>>> * iretq reads the "iret" frame and exits the NMI stack in a >>>>> * single instruction. We are returning to kernel mode, so this >>>> This isn't needed here. This is the NMI return-to-kernel path. >>> Yes, the VERW here can be omitted. But probably need to check if an NMI >>> occuring between VERW and ring transition will still execute VERW after >>> the NMI. >> That window does exist, though I'm not sure it's worth worrying about. > I am in favor of omitting the VERW here, unless someone objects with a > rationale. IMO, precisely timing the NMIs in such a narrow window is > impractical. I'd bet that given the right PMU event you could make this pretty reliable. But normal users can't do that by default. That leaves the NMI watchdog which (I bet) you can still time, but which is pretty low frequency. Are there any other NMI sources that a normal user can cause problems with? Let's at least leave a marker in here that folks can grep for: /* Skip CLEAR_CPU_BUFFERS since it will rarely help */ and some nice logic in the changelog that they can dig out if need be. But, basically it sounds like the logic is: 1. It's rare to get an NMI after VERW but before returning to userspace 2. There is no known way to make that NMI less rare or target it 3. It would take a large number of these precisely-timed NMIs to mount an actual attack. There's presumably not enough bandwidth. Anything else?
