>>> On 09.04.15 at 12:55, <andrew.coop...@citrix.com> 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@lists.xen.org http://lists.xen.org/xen-devel
