[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Fri, Jan 5, 2018 at 2:35 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 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),

I didn't say "only map domain-pertinent information"; I said "only map
*sensitive* information".  We don't need to eliminate all information,
nor even, up front, eliminate all side-channels, to be able to
mitigate a lot of these issues significantly.

"Read the entirety of another VM's memory" and "Can infer that a VM is
running on pcpu N and has received M interrupts to vector X" are
*very* different.

> you
> still don't protect against a piece of userspace using SP2 to attack a
> co-scheduled piece of userspace in the domain.

Yes, if we wanted to mitigate against userspace using SPX to access
guest kernel RAM (or that of another process), we'd need to make sure
to map only exactly what was needed and then unmap it when done.  But
starting with protecting other guests is still worthwhile I think.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.