On Fri, Jan 5, 2024 at 9:53 AM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > On Fri, 2024-01-05 at 08:21 -0800, Sean Christopherson wrote: > > No, do not inject #UD or do anything else that deviates from > > architecturally > > defined behavior. > > Here is a, at least partial, list of CET touch points I just created by > searching the SDM: > 1. The emulator SW fetch with TRACKER=1 > 2. CALL, RET, JMP, IRET, INT, SYSCALL, SYSENTER, SYSEXIT, SYSRET > 3. Task switching Sigh. KVM is forced to emulate task switch, because the hardware is incapable of virtualizing it. How hard would it be to make KVM's task-switch emulation CET-aware? > 4. The new CET instructions (which I guess should be handled by > default): CLRSSBSY, INCSSPD, RSTORSSP, SAVEPREVSSP, SETSSBSYY, WRSS, > WRUSS > > Not all of those are security checks, but would have some functional > implications. It's still not clear to me if this could happen naturally > (the TDP shadowing stuff), or only via strange attacker behavior. If we > only care about the attacker case, then we could have a smaller list. > > It also sounds like the instructions in 2 could maybe be filtered by > mode instead of caring about CET being enabled. But maybe it's not good > to mix the CET problem with the bigger emulator issues. Don't know.
