[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
- Date: Tue, 9 Aug 2016 11:48:11 +0100
- Cc: StefanoStabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, GeorgeDunlap <george.dunlap@xxxxxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, dgdegra@xxxxxxxxxxxxx
- Delivery-date: Tue, 09 Aug 2016 10:48:22 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
depriv)"):
> 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.
Could the hypervisor know the difference between user and kernel
memory, in principle ?
Alternatively, would it be possible for the ABI to specify somehow
what parameters are guest handles, so that the privcmd driver could
check them ? (Would it be sufficient to check the starts, or would
the ends need to be checked too?)
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
- References:
- [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
|