[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
- To: "George Dunlap" <george.dunlap@xxxxxxxxxx>
- From: "Jan Beulich" <JBeulich@xxxxxxxx>
- Date: Mon, 15 Aug 2016 05:20:39 -0600
- Cc: StefanoStabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, dgdegra@xxxxxxxxxxxxx
- Delivery-date: Mon, 15 Aug 2016 11:20:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
>>> On 15.08.16 at 12:47, <george.dunlap@xxxxxxxxxx> wrote:
> On 15/08/16 11:19, Jan Beulich wrote:
>> Well, none of the options considered so far are really nice or
>> readily available. I think the easiest to use for both the caller and
>> the implementation of the hypercall would be the auxiliary
>> hypercall for a kernel to indicate user/kernel boundaries plus a
>> flag on the DMOP one for the kernel mode driver to indicate its
>> user mode origin. The main (purely theoretical afaict) downside
>> of this is the difficulty to use it in OSes with variable user/kernel
>> boundaries.
>
> 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.
Jan
_______________________________________________
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)
|