[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.