Re: [Xen-devel] [PATCH v1 1/4] xsm/libxl/xen_version: Add XSM for some of the xen_version commands.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-10-08 at 22:56 -0400, Konrad Rzeszutek Wilk wrote:
> The XENVER_[compile_info|changeset|commandline] are now
> guarded by an XSM check.

I can guess, but please explain/justify why this is the case for these
here.

> The rest: XENVER_[version|extraversion|capabilities|
> parameters|get_features|page_size|guest_handle] behave
> as before (no XSM check).

and correspondingly why these ones to not warrant such a change.

> As such we also modify the toolstack such that if we fail
> to get any data instead of printing (null) we just print "".

Perhaps the hypervisor should instead return "<denied>" or some suitable
string indicating why (<denied-xsm>)?

> @@ -720,4 +720,28 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG
> struct domain *d, unsigned int
>      }
>  }
>  
> +#include <public/version.h>
> +static XSM_INLINE int xsm_version_op (XSM_DEFAULT_ARG uint32_t op)
> +{
> +    XSM_ASSERT_ACTION(XSM_PRIV);
> +    switch ( op )
> +    {
> +    case XENVER_compile_info:
> +    case XENVER_changeset:
> +    case XENVER_commandline:
> +        return xsm_default_action(XSM_PRIV, current->domain, NULL);
> +    case XENVER_version:
> +    case XENVER_extraversion:
> +    case XENVER_capabilities:
> +    case XENVER_platform_parameters:
> +    case XENVER_get_features:
> +    case XENVER_pagesize:
> +    case XENVER_guest_handle:
> +        /* The should _NEVER_ get here, but just in case. */

BUG_ON?

IMHO such a comment should have a "because ..." in it.

Actually, thinking about it, instead of splitting access control between
do_xen_version and here it would be more normal to have this function DTRT
and for it to be called unconditionally.

Ian.


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