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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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