>>> On 15.01.18 at 17:54, <pers...@gmail.com> wrote: > On Jan 12, 2018, at 05:19, Jan Beulich <jbeul...@suse.com> wrote: >> >> This is a very simplistic change limiting the amount of memory a running >> 64-bit PV guest has mapped (and hence available for attacking): Only the >> mappings of stack, IDT, and TSS are being cloned from the direct map >> into per-CPU page tables. Guest controlled parts of the page tables are >> being copied into those per-CPU page tables upon entry into the guest. >> Cross-vCPU synchronization of top level page table entry changes is >> being effected by forcing other active vCPU-s of the guest into the >> hypervisor. >> >> The change to context_switch() isn't strictly necessary, but there's no >> reason to keep switching page tables once a PV guest is being scheduled >> out. >> >> There is certainly much room for improvement, especially of performance, >> here - first and foremost suppressing all the negative effects on AMD >> systems. But in the interest of backportability (including to really old >> hypervisors, which may not even have alternative patching) any such is >> being left out here. > > Thanks for releasing this patch to support use cases not covered by the > previous mitigations. Is there a name or acronym we can use to reference > this patch in the FAQ, XSA and other support documents?
I'm against any such naming, but XPTI-light would come to mind. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
