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

Re: [Xen-devel] [PATCH] VMX: allocate APIC access page from domain heap



>>> On 18.12.15 at 07:29, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, December 16, 2015 3:58 PM
>> 
>> ... since we don't need its virtual address anywhere (it's a
>> placeholder page only after all). For this wo work (and possibly be
>> done elsewhere too) share_xen_page_with_guest() needs to mark pages
>> handed to it as Xen heap ones.
>> 
>> To be on the safe side, also explicitly clear the page (not having done
>> so was okay due to the XSA-100 fix, but is still a latent bug since we
>> don't formally guarantee allocations to come out zeroed, and in fact
>> this property may disappear again as soon as the asynchronous runtime
>> scrubbing patches arrive).
> 
> Do you mean that asynchronous scrubbing may scrub page after they
> are re-allocated? It's unrelated but a bit risky to me.

No, the issue would have been exposure of hypervisor or foreign VM
data, i.e. an information leak.

>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Alternatives might be to use a
>> - global (or perhaps per-node) page across VMs (on the basis that VMs
>>   shouldn't be writing into that page anyway)
>> - fake MFN pointing into nowhere (would need to ensure no side effects
>>   can occur, like PCIe errors or NMIs)
> 
> one page per VM should be fine. We don't need go that route.
> 
> the patch overall looks OK to me:

Except that it's broken - it turns out that I only thought I've tested
this, while in fact I had tested a stale binary. v2 on its way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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