Re: [Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.01.16 at 17:01, <konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
>> >>> On 08.01.16 at 18:31, <konrad.wilk@xxxxxxxxxx> wrote:
>> >> >> > The rest: XENVER_[version|capabilities|
>> >> >> > parameters|get_features|page_size|guest_handle] behave
>> >> >> > as before - allowed by default for all guests.
>> >> >> > 
>> >> >> > This is with the XSM default policy and with the dummy ones.
>> >> >> 
>> >> >> And with a non-default policy you now ignore one of the latter
>> >> >> ops to also get denied.
>> >> > 
>> >> > No, but that is due to the 'deny' being only checked for certain subops.
>> >> 
>> >> To me this reply seems contradictory in itself: The "no" doesn't
>> >> seem to match up with the rest.
>> >> 
>> >> > I think what you are saying is that for XENVER_[version|capabilities|
>> >> > parameters|get_features|page_size|guest_handle] we should not have any
>> >> > XSM checks as they serve no purpose (which is what I had in the earlier
>> >> > versions of this patch). However Andrew mentioned that he would
>> >> > like _ALL_ of the sub-ops to be checked for.
>> >> 
>> >> And I agree with Andrew, hence my earlier comment above (with
>> >> the reply I can't really make sense of).
>> > 
>> > I am all confused now.
>> > 
>> > There are two parts here:
>> >  a) The XSM checks - which allow the XENVER_version..XENVER_guest_handle
>> >    without any hinderance. For XENVER_commandline and XENVER_buildid
>> >    they are evaluated.
>> > 
>> >  b) Acting on the XSM check. For most of them we cannot actually return
>> >    -EFAULT and MUST return either an valid value or some form of a string.
>> >    
>> >    The ones for which we could return '<denied>' were changeset, 
>> > compile_info,
>> >    commandline, extraversion. To make it simpler we only do it for
>> >    commandline.
>> > 
>> > In essence we have an XSM check which is ignored by all XENVER_ subops
>> > except commandline (and build_id in later patch).
>> > 
>> > I think both of you are OK with that?
>> 
>> Iirc Andrew's request was to honor XSM denies on any sub-op
>> when a non-default policy is in place. Whereas in default mode
>> only command line and build id are the ones clearly needing
>> restricting. Which won't be possible if you ignore the return
>> value of the XSM check in some of the cases.
> 
> That means we need two (as earlier patches had it) version labels.
> One for the command_line and build_id (version_priv) and one for
> the rest (version_use). By default version_use would be available
> to every guest. If a non-default policy wants to mess with it - that is OK.

That would seem a little too coarse grained. Why can't we keep it
at the sub-op level, just that the default is "OK" for everything
except the two?

> Now comes the big question - for the XENVER_[version|capabilities|
> parameters|get_features|page_size|guest_handle] - if it is denied
> (so non-default version_use policy) - what should we return?

"<denied>" just like for the others that return strings; page_size
and other numeric ones may need to return zero.

> I can return '<denied>' for the strings, but what should we do
> for the page_size, capabilities and guest_handle ? -EPERM?

guest_handle is particularly interesting: It seems to make very
little sense to deny a guest access to its own handle.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel