Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Ian Campbell]

On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:

>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++

domctl is an stable toolstack only hypervisor interface, so the kernel
cannot use it because it would then break.

Ian.

Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[David Vrabel]

On 31/07/14 14:53, Ian Campbell wrote:
> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
> 
>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
> 
> domctl is an stable toolstack only hypervisor interface, so the kernel
> cannot use it because it would then break.

Ok.  I guess we'll have to resurrect the idea to do something with XSM.

David

Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Frediano Ziglio]

On Thu, 2014-07-31 at 15:11 +0100, David Vrabel wrote:
> On 31/07/14 14:53, Ian Campbell wrote:
> > On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
> > 
> >>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
> > 
> > domctl is an stable toolstack only hypervisor interface, so the kernel
> > cannot use it because it would then break.
> 
> Ok.  I guess we'll have to resurrect the idea to do something with XSM.
> 
> David
> 

The code just require that:
- sizeof(struct xen_domctl) does not increase;
- position and size of cmd, domain and interface_version does not
change;
- XEN_DOMCTL_createdomain is 1.

For safety there is a check on interface_version.

Frediano

Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Ian Campbell]

On Thu, 2014-07-31 at 15:43 +0100, Frediano Ziglio wrote:
> The code just require that:
> - sizeof(struct xen_domctl) does not increase;
> - position and size of cmd, domain and interface_version does not
> change;
> - XEN_DOMCTL_createdomain is 1.

This is not a stable interface, so you cannot actually rely on any of
those.

For the first one in particular its not that hard to imagine someone
needing a larger subop struct at some point.

Ian.

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[George Dunlap]

On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
> On 31/07/14 14:53, Ian Campbell wrote:
>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>
>>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
>>
>> domctl is an stable toolstack only hypervisor interface, so the kernel
>> cannot use it because it would then break.
>
> Ok.  I guess we'll have to resurrect the idea to do something with XSM.

What kind of thing did you have in mind for XSM?

In general it seems like allowing a vcpu to switch into an XSM label
(not sure I've got the terminology right here) when it context
switches into a particular process might be the most flexible way for
that to work.

But would that actually be easier than implementing stub domains?

 -George

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[George Dunlap]

On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 31/07/14 14:53, Ian Campbell wrote:
>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>
>>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
>>
>> domctl is an stable toolstack only hypervisor interface, so the kernel
>> cannot use it because it would then break.
>
> Ok.  I guess we'll have to resurrect the idea to do something with XSM.

What kind of thing did you have in mind for XSM?

In general it seems like allowing a vcpu to switch into an XSM label
(not sure I've got the terminology right here) when it context
switches into a particular process might be the most flexible way for
that to work.

But would that actually be easier than implementing stub domains?

 -George

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[David Vrabel]

On 31/07/14 18:49, George Dunlap wrote:
> On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
>> On 31/07/14 14:53, Ian Campbell wrote:
>>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>>
>>>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
>>>
>>> domctl is an stable toolstack only hypervisor interface, so the kernel
>>> cannot use it because it would then break.
>>
>> Ok.  I guess we'll have to resurrect the idea to do something with XSM.
> 
> What kind of thing did you have in mind for XSM?

A multicall-like hypercall that has an additional parameter for a handle
to a XSM context to use for the contained hypercalls.

> In general it seems like allowing a vcpu to switch into an XSM label
> (not sure I've got the terminology right here) when it context
> switches into a particular process might be the most flexible way for
> that to work.

I think we want something than can a different policy on a per-fd basis.

David

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[David Vrabel]

On 31/07/14 18:49, George Dunlap wrote:
> On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 31/07/14 14:53, Ian Campbell wrote:
>>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>>
>>>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
>>>
>>> domctl is an stable toolstack only hypervisor interface, so the kernel
>>> cannot use it because it would then break.
>>
>> Ok.  I guess we'll have to resurrect the idea to do something with XSM.
> 
> What kind of thing did you have in mind for XSM?

A multicall-like hypercall that has an additional parameter for a handle
to a XSM context to use for the contained hypercalls.

> In general it seems like allowing a vcpu to switch into an XSM label
> (not sure I've got the terminology right here) when it context
> switches into a particular process might be the most flexible way for
> that to work.

I think we want something than can a different policy on a per-fd basis.

David

Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[David Vrabel]

On 31/07/14 18:49, George Dunlap wrote:
> On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 31/07/14 14:53, Ian Campbell wrote:
>>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>>
>>>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
>>>
>>> domctl is an stable toolstack only hypervisor interface, so the kernel
>>> cannot use it because it would then break.
>>
>> Ok.  I guess we'll have to resurrect the idea to do something with XSM.
> 
> What kind of thing did you have in mind for XSM?

A multicall-like hypercall that has an additional parameter for a handle
to a XSM context to use for the contained hypercalls.

> In general it seems like allowing a vcpu to switch into an XSM label
> (not sure I've got the terminology right here) when it context
> switches into a particular process might be the most flexible way for
> that to work.

I think we want something than can a different policy on a per-fd basis.

David

Re: [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[George Dunlap]

On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> On 31/07/14 14:53, Ian Campbell wrote:
>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>
>>>  include/xen/interface/domctl.h     | 1090 ++++++++++++++++++++++++++++++++++++
>>
>> domctl is an stable toolstack only hypervisor interface, so the kernel
>> cannot use it because it would then break.
>
> Ok.  I guess we'll have to resurrect the idea to do something with XSM.

What kind of thing did you have in mind for XSM?

In general it seems like allowing a vcpu to switch into an XSM label
(not sure I've got the terminology right here) when it context
switches into a particular process might be the most flexible way for
that to work.

But would that actually be easier than implementing stub domains?

 -George

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Jan Beulich]

>>> On 31.07.14 at 15:16, <frediano.ziglio-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
> Add a RESTRICT ioctl to /dev/xen/privcmd, which allows privileged commands
> file descriptor to be restricted to only working with a particular domain.

The "with" here has been quite confusing, and I realized that you
mean the subject domain rather than the actor one only after
having gone through quite some parts of the patch. For a patch
this size, a little more of a description (and the original motivation)
would have helped.

Wrt motivation: Why does this need enforcing in the kernel at all?
Doesn't XSM_DM_PRIV mode deal specifically with what you're
trying to do here? Or else I guess I really need some better
explanation of what this is about.

Jan

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Jan Beulich]

>>> On 31.07.14 at 15:16, <frediano.ziglio@citrix.com> wrote:
> Add a RESTRICT ioctl to /dev/xen/privcmd, which allows privileged commands
> file descriptor to be restricted to only working with a particular domain.

The "with" here has been quite confusing, and I realized that you
mean the subject domain rather than the actor one only after
having gone through quite some parts of the patch. For a patch
this size, a little more of a description (and the original motivation)
would have helped.

Wrt motivation: Why does this need enforcing in the kernel at all?
Doesn't XSM_DM_PRIV mode deal specifically with what you're
trying to do here? Or else I guess I really need some better
explanation of what this is about.

Jan

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Frediano Ziglio]

On Fri, 2014-08-01 at 09:27 +0100, Jan Beulich wrote:
> >>> On 31.07.14 at 15:16, <frediano.ziglio-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
> > Add a RESTRICT ioctl to /dev/xen/privcmd, which allows privileged commands
> > file descriptor to be restricted to only working with a particular domain.
> 
> The "with" here has been quite confusing, and I realized that you
> mean the subject domain rather than the actor one only after
> having gone through quite some parts of the patch. For a patch
> this size, a little more of a description (and the original motivation)
> would have helped.
> 

Yes, you are right.

> Wrt motivation: Why does this need enforcing in the kernel at all?
> Doesn't XSM_DM_PRIV mode deal specifically with what you're
> trying to do here? Or else I guess I really need some better
> explanation of what this is about.
> 
> Jan
> 

This is quite old for me but you are right, perhaps is not that clear
for other people. In XenServer we have some patches that allow Qemu
running in dom0 but work only for a specific domain. The patches
required changes to libxc, kernel and Qemu. We are reimplementing these
patches as the old implementation has some problems (one is that the
patch for libxc was quite big). This feature was removed as kernel
patches did not work with newer (3.x) kernels.

Now, XSM_DM_PRIV works checking if the domain target is the domain we
are going to handle. However if your dom0 (as in XenServer) has all Qemu
to handle all VMs it cannot be bound to a single target so XSM is not
usable. Xen has no knowledge of process or file descriptor (which are
kernel specific) so there is actually no way it can distinguish which
domain should be restricted to. It would solve if the restriction would
be done for system call (so we can say execute this hypercall(s) with
these policies). However this require to change the target to be at
least CPU specific and handle preemption correctly in order to not mix
policies. This could be quite heavy so we hack the kernel in order to do
the restriction instead (it also was easier to port the patches).

Actually changes in Qemu to handle the privcmd/evtchn restrictions are
quite small, mainly restrict these two handles with an ioctl. Other
parts of the patch (chroot, setuid, groups, resource limits, and mostly
xenstore accesses) are more heavy.

Frediano

Re: [Xen-devel] [PATCH 1/2] xen: Implement ioctl to restrict privcmd to a specific domain

[Frediano Ziglio]

On Fri, 2014-08-01 at 09:27 +0100, Jan Beulich wrote:
> >>> On 31.07.14 at 15:16, <frediano.ziglio@citrix.com> wrote:
> > Add a RESTRICT ioctl to /dev/xen/privcmd, which allows privileged commands
> > file descriptor to be restricted to only working with a particular domain.
> 
> The "with" here has been quite confusing, and I realized that you
> mean the subject domain rather than the actor one only after
> having gone through quite some parts of the patch. For a patch
> this size, a little more of a description (and the original motivation)
> would have helped.
> 

Yes, you are right.

> Wrt motivation: Why does this need enforcing in the kernel at all?
> Doesn't XSM_DM_PRIV mode deal specifically with what you're
> trying to do here? Or else I guess I really need some better
> explanation of what this is about.
> 
> Jan
> 

This is quite old for me but you are right, perhaps is not that clear
for other people. In XenServer we have some patches that allow Qemu
running in dom0 but work only for a specific domain. The patches
required changes to libxc, kernel and Qemu. We are reimplementing these
patches as the old implementation has some problems (one is that the
patch for libxc was quite big). This feature was removed as kernel
patches did not work with newer (3.x) kernels.

Now, XSM_DM_PRIV works checking if the domain target is the domain we
are going to handle. However if your dom0 (as in XenServer) has all Qemu
to handle all VMs it cannot be bound to a single target so XSM is not
usable. Xen has no knowledge of process or file descriptor (which are
kernel specific) so there is actually no way it can distinguish which
domain should be restricted to. It would solve if the restriction would
be done for system call (so we can say execute this hypercall(s) with
these policies). However this require to change the target to be at
least CPU specific and handle preemption correctly in order to not mix
policies. This could be quite heavy so we hack the kernel in order to do
the restriction instead (it also was easier to port the patches).

Actually changes in Qemu to handle the privcmd/evtchn restrictions are
quite small, mainly restrict these two handles with an ioctl. Other
parts of the patch (chroot, setuid, groups, resource limits, and mostly
xenstore accesses) are more heavy.

Frediano