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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.08.16 at 15:46, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
>> On 05.08.16 at 18:28, <ian.jackson@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel