On 6/6/19 3:04 PM, Andy Lutomirski wrote: >> But, that seems broken. If we have supervisor state, we can't >> always defer the load until return to userspace, so we'll never?? >> have TIF_NEED_FPU_LOAD. That would certainly be true for >> cet_kernel_state. > > Ugh. I was sort of imagining that we would treat supervisor state completely separately from user state. But can you maybe give examples of exactly what you mean? > >> It seems like we actually need three classes of XSAVE states: 1. >> User state > > This is FPU, XMM, etc, right? Yep. >> 2. Supervisor state that affects user mode > > User CET? Yep. >> 3. Supervisor state that affects kernel mode > > Like supervisor CET? If we start doing supervisor shadow stack, the > context switches will be real fun. We may need to handle this in > asm. Yeah, that's what I was thinking. I have the feeling Yu-cheng's patches don't comprehend this since Sebastian's patches went in after he started working on shadow stacks. > Where does PKRU fit in? Maybe we can treat it as #3? I thought Sebastian added specific PKRU handling to make it always eager. It's actually user state that affect kernel mode. :)
