>>> 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 nothing really enforces anyone to use the (disconnect
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)
> xen_dmop_foo_entry type. I.e. it
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, wrote:
> > Would this be enough of an improvement, for you, to be worth the
> > additional type name clutter etc. ?
>
>>> On 21.09.16 at 15:24, 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, wrote:
>> > But changes in the contents of the specific struct /wil
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, wrote:
> > But changes in the contents of the specific struct /will/ be spotted.
>
> As long as it is a structure, yes. Wh
>>> On 21.09.16 at 14:23, 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,
>> > So the actual hypercall
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
> > format of th
>>> 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 their own preferred
> meth
>>> On 21.09.16 at 13:21, wrote:
> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP,
> re qemu depriv)"):
>> On 13.09.16 at 18:07, wrote:
>> > This is an direct result of the requirement that the privcmd driver does
>>
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, wrote:
>>> This is an direct result of the requirement that the privcmd driver does
>>> not
Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re
qemu depriv)"):
> On 13.09.16 at 18:07, wrote:
> > This is an direct result of the requirement that the privcmd driver does
> > not know the types of the sub-ops themselves. We can't
>>> 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 len;
>>> } dm_op_buffer_t;
>>
>> This implies that we
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 type safety on the handles passe
>>> 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;
>>> size_t len;
>>> } dm_op_buffer_t;
>>
>> This implies that we
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 type safety on the handles passe
>>> 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 emphasized by the use of raw_copy_
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,
> XEN_GUEST_
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 follow
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, w
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.
>
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 whethe
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
> immediate
>>> 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 number in the calling domain. This would be a problem becau
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 would be nothing to stop qem
>>> 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
https://lists.xen.org/xen-devel
>>> 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 lack of `class 2' bugs - for HVMCTL from the beginning ?
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 so, since ...
>
> > This w
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 looks simpler to me to fix the
>>> 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, wrote:
> That is, a bug of class 2 would allow the unprivileged
>>> 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 think the easiest to use for both the caller and
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 implementation of the hypercall woul
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 unprivileged qemu process in
dom0 to cause damage
>>> 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 range that all pointers must be in? That wouldn't even r
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 user/kernel flag actually; a
>>> 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 auxiliary
>> hypercall for a kerne
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, wrote:
>> Jan Beulich writes ("Re: Device model operation hypercall (
>>> 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: Device model operation hypercall (DMOP, re qemu
> depriv)"):
>> Actua
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)"):
> Actually, having thought about this some more,
>>> 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 some more, and taking this
together with the expec
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 the privcmd driver previously
>>> 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 think this part is problemat
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
>>> 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 cause damage to other parts of dom0.
> ...
>> Ah, okay
>>> 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 the target domain, so would
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 finally understand. [...]
>
> I
>>> 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 declare HVMCTL to have the relevant security property, an
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
> > implement corresponding code in dom
>>> 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. This is because the dom0 pr
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 operations would
> >> need
>>> 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 to be
>> either fixed or remo
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 b
>>> 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 currently available to stubdoms ?
>>
>> That series only m
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 by all the prooposed HVMCTLs
is currently availab
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 course with a clear statement
>>> 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 whole system, nor of the domai
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
> > >
>>> 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 could invent a new hypercall `DMOP' for hypercalls which device
>m
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
models should be able to use, which always
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
>>> 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, which always has the target domain in
>> >a fixe
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
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
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 in the arguments. We have th
>>> 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 this one hypercall number and t
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 at finally making
> this reality (at once allowing to streamline the
65 matches
Mail list logo
