>>> On 08.08.16 at 15:46, <ian.jack...@eu.citrix.com> wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 05.08.16 at 18:28, <ian.jack...@eu.citrix.com> wrote: >> > That is, a bug of class 2 would allow the unprivileged qemu process in >> > dom0 to cause damage to other parts of dom0. > ... >> Ah, okay, I think I finally understand. [...] >> >> I'm having, however, a hard time imagining a class 2 bug for any >> of the hvmop-s that are being converted by the hvmctl series: >> These act on the target domain, so would not touch the calling >> ones state other than for copying argument structures to/from >> guest memory (and I don't view mixing up domain pointers as >> a likely source of problems). > > Right. AIUI all the hypercall arguments are passed using > calling-guest-virtual addresses, which the dom0 privcmd arrangements > are capable of ensuring are sane.
Actually, having thought about this some more, and taking this together with the expectations to the privcmd driver previously outlined, I think this part is problematic: If all the driver is to know is the position (within the interface structure) of the target domain ID, then any guest handles embedded in the interface structure (XEN_HVMCTL_track_dirty_vram only for now) couldn't get validated, and hence user mode code would have a way to access or modify kernel memory. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel