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

Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains



>>> On 09.04.15 at 12:55, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/04/15 13:57, Roger Pau Monne wrote:
>> Since a PVH hardware domain has access to the physical hardware create a
>> custom more permissive IO bitmap. The permissions set on the bitmap are
>> populated based on the contents of the ioports rangeset.
>>
>> Also add the IO ports of the serial console used by Xen to the list of not
>> accessible IO ports.
> 
> Thankyou for looking into this.  I think it is the correct general
> direction, but I do have some questions/thoughts about this area.
> 
> I know that the current implementation is that dom0 is whitelisted and
> can play with everything, but is this actually the best API? 
> Conceptually, a better approach would be for dom0 to start with no
> permissions, and explicitly request access (After all, PV and PVH
> domains are expected to know exactly what they are doing under Xen). 

I don't think this would work too well with the AML interpreter. And
it certainly doesn't make sense to have Dom0 request access blindly
for every port an IN or OUT is done against, as that would effectively
be no different from Dom0 being granted access to everything minus
a black list as we do now.

>> @@ -1618,6 +1624,10 @@ int __init construct_dom0(
>>  
>>          pvh_map_all_iomem(d, nr_pages);
>>          pvh_setup_e820(d, nr_pages);
>> +
>> +        for ( i = 0; i < 0x10000; i++ )
>> +            if ( ioports_access_permitted(d, i, i) )
>> +                __clear_bit(i, hvm_hw_io_bitmap);
> 
> (There is surely a more efficient way of doing this?  If there isn't,
> there probably should be)
> 
> There is also a boundary issue between VT-x and SVM.
> 
> For VT-x, the IO bitmap is 2 pages.  For SVM, it is 2 pages and 3 bits. 
> I suspect the difference is to do with the handling of a 4byte write to
> port 0xffff.  I think you might need to check "i < 0x10003" instead.

I don't think we should ever grant access to ports 0x10000...0x10003,
i.e. not clearing those bits seems quite fine to me.

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