Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/01/18 14:27, Jan Beulich wrote:
>>>> On 05.01.18 at 15:11, <dunlapg@xxxxxxxxx> wrote:
>> Here's a question:  What if we didn't try to prevent the guest from
>> reading hypervisor memory at all, but instead just tried to make sure
>> that there was nothing of interest there?
>>
>> If sensitive information pertaining to a given vcpu were only maped on
>> the processor currently running that vcpu, then it would mitigate not
>> only SP3, but also SP2 and SP1.
> Unless there were hypervisor secrets pertaining to this guest.
> Also, while the idea behind your question is certainly nice, fully
> separating memories related to individual guests would come
> at quite significant a price: No direct access to a random
> domain's control structures would be possible anymore, which
> I'd foresee to be a problem in particular when wanting to
> forward interrupts / event channel operations to the right
> destination. But as I've said elsewhere recently: With all the
> workarounds now being put in place, perhaps we don't care
> about performance all that much anymore anyway...

Even if we did manage to isolate the mappings to only domian-pertinant
information (which is hard, because interrupts need to still work), you
still don't protect against a piece of userspace using SP2 to attack a
co-scheduled piece of userspace in the domain.

~Andrew

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