Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 01/22/2018 05:04 PM, Jan Beulich wrote:
>>>> On 22.01.18 at 16:15, <george.dunlap@xxxxxxxxxx> wrote:
>> On 01/22/2018 01:30 PM, Jan Beulich wrote:
>>>>>> On 22.01.18 at 13:33, <george.dunlap@xxxxxxxxxx> wrote:
>>>> What I'm proposing is something like this:
>>>>
>>>> * We have a "global" region of Xen memory that is mapped by all
>>>> processors.  This will contain everything we consider not sensitive;
>>>> including Xen text segments, and most domain and vcpu data.  But it will
>>>> *not* map all of host memory, nor have access to sensitive data, such as
>>>> vcpu register state.
>>>>
>>>> * We have per-cpu "local" regions.  In this region we will map,
>>>> on-demand, guest memory which is needed to perform current operations.
>>>> (We can consider how strictly we need to unmap memory after using it.)
>>>> We will also map the current vcpu's registers.
>>>>
>>>> * On entry to a 64-bit PV guest, we don't change the mapping at all.
>>>>
>>>> Now, no matter what the speculative attack -- SP1, SP2, or SP3 -- a vcpu
>>>> can only access its own RAM and registers.  There's no extra overhead to
>>>> context switching into or out of the hypervisor.
>>>
>>> And we would open back up the SP3 variant of guest user mode
>>> attacking its own kernel by going through the Xen mappings. I
>>> can't exclude that variants of SP1 (less likely SP2) allowing indirect
>>> guest-user -> guest-kernel attacks couldn't be found.
>>
>> How?  Xen doesn't have the guest kernel memory mapped when it's not
>> using it.
> 
> Oh, so you mean to do away with the direct map altogether?

Yes. :-)  The direct map is *the* core reason why the SP*
vulnerabilities are so dangerous.  If the *only* thing we did was get
rid of the direct map, without doing *anything* else, we would almost
entirely mitigate the effect of all of the attacks.

 -George

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