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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 01/19/2018 04:36 PM, Jan Beulich wrote:
>>>> On 19.01.18 at 16:43, <george.dunlap@xxxxxxxxxx> wrote:
>> On 01/19/2018 02:37 PM, Jan Beulich wrote:
>>> All,
>>>
>>> along the lines of the relatively easy first step submitted yesterday,
>>> I've had some further thoughts in that direction. A fundamental
>>> thing for this is of course to first of all establish what kind of
>>> information we consider safe to expose (in the long run) to guests.
>>>
>>> The current state of things is deemed incomplete, yet despite my
>>> earlier inquiries I haven't heard back any concrete example of
>>> information, exposure of which does any harm. While it seems to be
>>> generally believed that large parts of the Xen image should not be
>>> exposed, it's not all that clear to me why that would be. I could
>>> agree with better hiding writable data parts of it, just to be on the
>>> safe side (I'm unaware of statically allocated data though which
>>> might carry any secrets), but what would be the point of hiding
>>> code and r/o data? Anyone wanting to know their contents can
>>> simply obtain the Xen binary for their platform.
>>
>> This tails into a discussion I think we should have about dealing with
>> SP1, and also future-proofing against future speculative execution attacks.
>>
>> Right now there are "windows" through which people can look using SP1-3,
>> which we are trying to close.  SP1's "window" is the guest -> hypervisor
> 
> I think you mean SP3 here.
> 
>> virtual address space (hence XPTI, separating the address spaces).
>> SP2's "window" is branch-target-poisoned gadgets (hence using retpoline
>> and various techniques to prevent branch target poisoning).  SP1's
>> "window" is array boundary privilege checks, hence Linux's attempts to
>> prevent speculation over privilege checks by using lfence or other
>> tricks[1].
>>
>> But there will surely be more attacks like this (in fact, there may
>> already be some in the works[2]).
>>
>> So what if instead of trying to close the "windows", we made it so that
>> there was nothing through the windows to see?  If no matter what the
>> hypervisor speculatively executed, nothing sensitive was visibile except
>> what a vcpu was already allowed to see,
> 
> I think you didn't finish your sentence here, but I also think I
> can guess the missing part. There's a price to pay for such an
> approach though - iterating over domains, or vCPU-s of a
> domain (just as an example) wouldn't be simple list walks
> anymore. There are certainly other things. IOW - yes, and
> approach like this seems possible, but with all the lost
> performance I think we shouldn't go overboard with further
> hiding.

Right, so the next question: what information *from other guests* are
sensitive?

Obviously the guest registers are sensitive.  But how much of the
information in vcpu struct that we actually need to have "to hand" is
actually sensitive information that we need to hide from other VMs?

 -George

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