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

>>> On 21.09.16 at 19:09, wrote: > On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich wrote: >> Again this looks like much clutter with little benefit to me, i.e. I'd >> then rather go with the unmodified original proposal. That's largely >> because

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

On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich wrote: > Again this looks like much clutter with little benefit to me, i.e. I'd > then rather go with the unmodified original proposal. That's largely > because nothing really enforces anyone to use the (disconnected) >

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

Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]"): > On 21.09.16 at 15:24, <ian.jack...@eu.citrix.com> wrote: > > Would this be enough of an improvement, for you, to be worth the > > additional type

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

>>> On 21.09.16 at 15:24, <ian.jack...@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, > re qemu depriv) [and 1 more messages]"): >> On 21.09.16 at 14:23, <ian.jack...@eu.citrix.com> wrote: >&

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

Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]"): > On 21.09.16 at 14:23, <ian.jack...@eu.citrix.com> wrote: > > But changes in the contents of the specific struct /will/ be spotted. > > As long

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

>>> On 21.09.16 at 14:23, <ian.jack...@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, > re qemu depriv)"): >> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, >> >

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

Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)"): > Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, > > So the actual hypercall call sites are all in-tree, in libxc. If the > > for

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

>>> On 21.09.16 at 13:28, wrote: > I think the other slight bit of information missing from Jan at least > (and perhaps also David) is the difference between their preference / > recommendation and their requirement. > > That is, if David and Jan each strongly recommend

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

>>> On 21.09.16 at 13:21, <ian.jack...@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, > re qemu depriv)"): >> On 13.09.16 at 18:07, <david.vra...@citrix.com> wrote: >> > This is an direct re

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

On 21/09/16 12:21, Ian Jackson wrote: > Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, > re qemu depriv)"): >> On 13.09.16 at 18:07, <david.vra...@citrix.com> wrote: >>> This is an direct result of the requirement that the privc

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

Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)"): > On 13.09.16 at 18:07, <david.vra...@citrix.com> wrote: > > This is an direct result of the requirement that the privcmd driver does > > not know the types of the sub

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

>>> On 13.09.16 at 18:07, wrote: > On 12/09/16 15:32, Jan Beulich wrote: > On 09.09.16 at 17:16, wrote: >>> The following code illustrates this idea: >>> >>> typedef struct dm_op_buffer { >>> XEN_GUEST_HANDLE(void) h; >>> size_t

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

On 12/09/16 15:32, Jan Beulich wrote: On 09.09.16 at 17:16, wrote: >> The following code illustrates this idea: >> >> typedef struct dm_op_buffer { >> XEN_GUEST_HANDLE(void) h; >> size_t len; >> } dm_op_buffer_t; > > This implies that we'll lose all

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

>>> On 13.09.16 at 12:37, wrote: > On 12/09/16 15:32, Jan Beulich wrote: > On 09.09.16 at 17:16, wrote: >>> The following code illustrates this idea: >>> >>> typedef struct dm_op_buffer { >>> XEN_GUEST_HANDLE(void) h; >>>

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

On 12/09/16 15:32, Jan Beulich wrote: On 09.09.16 at 17:16, wrote: >> The following code illustrates this idea: >> >> typedef struct dm_op_buffer { >> XEN_GUEST_HANDLE(void) h; >> size_t len; >> } dm_op_buffer_t; > > This implies that we'll lose all

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

>>> On 09.09.16 at 17:16, wrote: > The following code illustrates this idea: > > typedef struct dm_op_buffer { > XEN_GUEST_HANDLE(void) h; > size_t len; > } dm_op_buffer_t; This implies that we'll lose all type safety on the handles passed, as is also

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

On 09/09/16 16:16, Jennifer Herbert wrote: > The following code illustrates this idea: > > typedef struct dm_op_buffer { > XEN_GUEST_HANDLE(void) h; > size_t len; > } dm_op_buffer_t; > > int > HYPERVISOR_device_model_op( > domid_t domid, > unsigned int nr_buffers, >

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

On 09/09/16 16:16, Jennifer Herbert wrote: > On 01/08/16 12:32, Ian Jackson wrote: >> I think we need to introduce a new hypercall (which I will call DMOP >> for now) which may augment or replace some of HVMCTL. Let me explain: >> > > I believe the new 'DMOP' hypercall is a good idea, but

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

On 01/08/16 12:32, Ian Jackson wrote: I think we need to introduce a new hypercall (which I will call DMOP for now) which may augment or replace some of HVMCTL. Let me explain: I believe the new 'DMOP' hypercall is a good idea, but following on from discussions, I propose a revised design,

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

On Tue, Aug 30, 2016 at 12:02:26PM +0100, Ian Jackson wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): > > Well, in a way. And then not: Initially I had thought no issue would > > arise, until I came to realize the kernel memory corruption potential.

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

On Tue, 30 Aug 2016, Ian Jackson wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): > > Well, in a way. And then not: Initially I had thought no issue would > > arise, until I came to realize the kernel memory corruption potential. > > Question is

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > Well, in a way. And then not: Initially I had thought no issue would > arise, until I came to realize the kernel memory corruption potential. > Question is whether now we're overlooking some other not >

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

>>> On 26.08.16 at 16:35, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 26.08.16 at 13:38, wrote: >> > Another example would be a DMOP that takes (or returns) an event >> > channel

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 26.08.16 at 13:38, wrote: > > Another example would be a DMOP that takes (or returns) an event > > channel number in the calling domain. This would be a problem because > > there

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

>>> On 26.08.16 at 13:29, wrote: > Is this plan a good one for everyone ? Sounds reasonable to me; just needs settling on a few of the actual details. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org

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

>>> On 26.08.16 at 13:38, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 08.08.16 at 15:46, wrote: >> > So would it therefore be OK to introduce the enhanced security promise >> > - the

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 08.08.16 at 15:46, wrote: > > So would it therefore be OK to introduce the enhanced security promise > > - the lack of `class 2' bugs - for HVMCTL from the beginning ? > > I think

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 15.08.16 at 16:50, wrote: > > It seems simpler to me to have in the privcmd driver: > > > > if (op == HVMCTL_track_dirty_vram) > > ret = access_ok(...); > > > > It

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

>>> On 15.08.16 at 16:50, wrote: > On 09/08/16 11:29, Jan Beulich wrote: > On 08.08.16 at 15:46, wrote: >>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >>> depriv)"): On 05.08.16 at 18:28,

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

>>> On 15.08.16 at 16:57, wrote: > On 15/08/16 12:20, Jan Beulich wrote: > On 15.08.16 at 12:47, 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

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

On 15/08/16 12:20, Jan Beulich wrote: On 15.08.16 at 12:47, 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

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

On 09/08/16 11:29, Jan Beulich wrote: On 08.08.16 at 15:46, wrote: >> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >> depriv)"): >>> On 05.08.16 at 18:28, wrote: That is, a bug of class 2 would allow the

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

>>> On 15.08.16 at 14:07, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 15.08.16 at 12:47, wrote: >> > What about including in the "fixed" part of the hypercall a virtual >> > address

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 15.08.16 at 12:47, 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

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

>>> On 15.08.16 at 12:47, 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

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

On 15/08/16 11:19, Jan Beulich wrote: On 15.08.16 at 11:39, wrote: >> On 12/08/16 12:50, Jan Beulich wrote: >> On 12.08.16 at 11:44, wrote: On 09/08/16 12:30, Jan Beulich wrote: On 09.08.16 at 12:48,

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

>>> On 15.08.16 at 11:39, wrote: > On 12/08/16 12:50, Jan Beulich wrote: > On 12.08.16 at 11:44, wrote: >>> On 09/08/16 12:30, Jan Beulich wrote: >>> On 09.08.16 at 12:48, wrote: > Jan Beulich writes

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

On 12/08/16 12:50, Jan Beulich wrote: On 12.08.16 at 11:44, wrote: >> On 09/08/16 12:30, Jan Beulich wrote: >> On 09.08.16 at 12:48, wrote: Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"):

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

>>> On 12.08.16 at 11:44, wrote: > On 09/08/16 12:30, Jan Beulich wrote: > On 09.08.16 at 12:48, wrote: >>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >>> depriv)"): Actually, having thought about this

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

On 09/08/16 12:30, Jan Beulich wrote: On 09.08.16 at 12:48, wrote: >> 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

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

>>> On 09.08.16 at 12:48, wrote: > 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

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

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

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

>>> On 08.08.16 at 15:46, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 05.08.16 at 18:28, wrote: >> > That is, a bug of class 2 would allow the unprivileged qemu process in >> > dom0 to

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

>>> On 08.08.16 at 15:46, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> 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

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 05.08.16 at 18:28, 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

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

>>> On 05.08.16 at 18:28, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 04.08.16 at 13:21, wrote: >> > What we cannot do is audit every HVMCTL, fix the class 2 problems, and >> > then

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 04.08.16 at 13:21, wrote: > > What we cannot do is audit every HVMCTL, fix the class 2 problems, and > > then declare HVMCTL to have the relevant security property, and > >

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

>>> On 04.08.16 at 13:21, wrote: > What we cannot do is audit every HVMCTL, fix the class 2 problems, and > then declare HVMCTL to have the relevant security property, and > implement corresponding code in dom0's privcmd drivers which relies on > the security property.

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 03.08.16 at 18:10, wrote: > > George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu > > depriv)"): > >> So before qemu devpriv can be usable, *all* the HVMCTL

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

>>> On 03.08.16 at 18:10, wrote: > George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> So before qemu devpriv can be usable, *all* the HVMCTL operations would >> need to be audited, and those that were deemed insecure would need

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

George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > So before qemu devpriv can be usable, *all* the HVMCTL operations would > need to be audited, and those that were deemed insecure would need to be > either fixed or removed. Even worse, the bad HVMCTLs would

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

>>> On 03.08.16 at 15:37, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 03.08.16 at 12:29, wrote: >> > Does that mean that functionality exposed by all the prooposed HVMCTLs >> > is

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

On 03/08/16 15:16, Jan Beulich wrote: On 03.08.16 at 15:37, wrote: >> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >> depriv)"): >>> On 03.08.16 at 12:29, wrote: Does that mean that functionality exposed

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 03.08.16 at 12:29, wrote: > > I thought it useful to set out the DMOP proposal from first > > principles, with clear motivation, discussion of not-chosen > > alternatives, and of

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

>>> On 03.08.16 at 12:29, wrote: > Wei Liu writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: >> > > A DMOP is defined to never put at risk the stability or security of >> > > the

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

Wei Liu writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: > > > A DMOP is defined to never put at risk the stability or security of > > > the whole system, nor of the domain which calls DMOP. However, a DMOP > >

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

>>> On 02.08.16 at 15:02, wrote: > On 02/08/16 12:58, Jan Beulich wrote: > On 02.08.16 at 13:38, wrote: >>> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: >>> On 01.08.16 at 13:32, wrote: > 4. We

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

On 02/08/16 12:58, Jan Beulich wrote: On 02.08.16 at 13:38, wrote: >> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: >> On 01.08.16 at 13:32, wrote: 4. We could invent a new hypercall `DMOP' for hypercalls which device

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

On Tue, Aug 02, 2016 at 12:42:36PM +0100, George Dunlap wrote: > On 02/08/16 12:37, Wei Liu wrote: > > On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote: > >> Introducing HVMCTL, Jan wrote: > >>> A long while back separating out all control kind operations (intended > >>> for use by only

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

>>> On 02.08.16 at 13:38, wrote: > On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: >> >>> On 01.08.16 at 13:32, wrote: >> > 4. We could invent a new hypercall `DMOP' for hypercalls which device >> >models should be able to use,

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

On 02/08/16 12:37, Wei Liu wrote: > On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote: >> Introducing HVMCTL, Jan wrote: >>> A long while back separating out all control kind operations (intended >>> for use by only the control domain or device model) from the currect >>> hvmop hypercall

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

On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote: > Introducing HVMCTL, Jan wrote: > > A long while back separating out all control kind operations (intended > > for use by only the control domain or device model) from the currect > > hvmop hypercall has been discussed. This series aims

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

On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: > >>> On 01.08.16 at 13:32, wrote: > > 4. We could invent a new hypercall `DMOP' for hypercalls which device > >models should be able to use, which always has the target domain in > >a fixed location

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

>>> On 01.08.16 at 13:32, wrote: > 4. We could invent a new hypercall `DMOP' for hypercalls which device >models should be able to use, which always has the target domain in >a fixed location in the arguments. We have the dom0 privcmd driver >know about