Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 01/16/2018 07:12 AM, Jan Beulich wrote:
>>>> On 15.01.18 at 17:54, <persaur@xxxxxxxxx> wrote:
>> On Jan 12, 2018, at 05:19, Jan Beulich <JBeulich@xxxxxxxx> 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.

Rich, I'm afraid we tend to be a pedestrian bunch when it comes to
naming. :-)

I personally much prefer labels that contain enough information to hint
as to what the thing being referred to is.  One of the things I really
dislike about, say, OpenStack, is the hundreds of projects they have,
each with a cute name that people throw around, that as an outsider you
have no idea what they're talking about, and no real way to find out
rather than brute-force memorization.

Vixen / Comet thing was a special case.  First of all, Amazon had
already named Vixen; but even so, I initially referred to the two shims
as "the HVM shim" and "the PVH shim".  But when "the HVM shim" began to
get PVH support, and "the PVH shim" successfully got HVM support, those
names started to be inaccurate.  They really were just different
versions of the same thing (even sharing a lot of the same code).  Under
those circumstances, there's not much choice but to give "meaningless"
names.

Hopefully we'll never be in a position of discussing which of two
nearly-identical XPTI patches to start future development from, nor of
presenting two nearly-identical XPTI patchsets to our downstreams.

Since it seems like we may have several iterations of an SP3 solution,
each of which adds more protection / improves performance on previous
iterations, what about adding a number?  Say, "XPTI stage 1"?

Then we can discuss which technical mitigations will be in each 'stage'
that we release.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel