>>> On 04.08.16 at 13:21, <ian.jack...@eu.citrix.com> wrote: > What we cannot do is audit every HVMCTL, fix the class 2 problems, and > then declare HVMCTL to have the relevant security property, and > implement corresponding code in dom0's privcmd drivers which relies on > the security property. This is because the dom0 privcmd driver > doesn't know whether the HVMCTLs it is allowing not-fully-trusted > userspace to make are actually trustworthy (with the specific > hypervisor version in question.)
I continue to not really understand this argumentation: Dom0's privcmd driver doesn't really matter here. If there's a bug in something qemu uses, this is a problem no matter whether that operation gets called though the to-be-added privcmd logic, or straight from a stubdom qemu. Both are less than fully privileged. What do I continue to be missing? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
