On 24/02/2021 23:58, Volodymyr Babchuk wrote: > And I am not mentioning x86 support there...
x86 uses per-pCPU stacks, not per-vCPU stacks. Transcribing from an old thread which happened in private as part of an XSA discussion, concerning the implications of trying to change this. ~Andrew -----8<----- Here is a partial list off the top of my head of the practical problems you're going to have to solve. Introduction of new SpectreRSB vulnerable gadgets. I'm really close to being able to drop RSB stuffing and recover some performance in Xen. CPL0 entrypoints need updating across schedule. SYSCALL entry would need to become a stub per vcpu, rather than the current stub per pcpu. This requires reintroducing a writeable mapping to the TSS (doable) and a shadow stack switch of active stacks (This corner case is so broken it looks to be a blocker for CET-SS support in Linux, and is resulting in some conversation about tweaking Shstk's in future processors). All per-cpu variables stop working. You'd need to rewrite Xen to use %gs for TLS which will have churn in the PV logic, and introduce the x86 architectural corner cases of running with an invalid %gs. Xen has been saved from a large number of privilege escalation vulnerabilities in common with Linux and Windows by the fact that we don't use %gs, so anyone trying to do this is going to have to come up with some concrete way of proving that the corner cases are covered.
