[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: Mon, 15 Aug 2016 13:07:39 +0100
- Cc: StefanoStabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, dgdegra@xxxxxxxxxxxxx
- Delivery-date: Mon, 15 Aug 2016 12:08:10 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
depriv)"):
> On 15.08.16 at 12:47, <george.dunlap@xxxxxxxxxx> wrote:
> > What about including in the "fixed" part of the hypercall a virtual
> > address range that all pointers must be in? That wouldn't even require
> > a user/kernel flag actually; and could conceivably be used by the caller
> > (either userspace or kernel space) to thwart certain kinds of potential
> > attacks.
>
> That's definitely an option, if we're sufficiently certain that no OSes
> will ever require two or more ranges.
How hard would it be to allow the caller to specify several allowable
ranges ?
Note that the hypercall argument construction code in libxc already
has to handle all hypercall argument memory specially, so libxc could
automatically build a list of the arguments' memory addresses.
What would be needed is some kind of restriction on (or variant of)
copy_* which double-checked against the list provided in the
non-op-specific part of the hypercall.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
- References:
- 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)
- 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)
|