On Thu, 2019-06-06 at 15:08 -0700, Dave Hansen wrote: > > 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. :) For CET user states, we need to restore before making changes. If they are not being changed (i.e. signal handling and syscalls), then they are restored only before going back to user-mode. For CET kernel states, we only need to make small changes in the way similar to the PKRU handling, right? We'll address it when sending CET kernel-mode patches. I will put in more comments as suggested by Dave in earlier emails. Yu-cheng
