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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)



>>> On 04.08.16 at 13:21, <ian.jackson@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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