From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v2 1/3] xsm/xen_version: Add XSM for the
 xen_version hypercall.
Date: Mon, 11 Jan 2016 11:01:46 -0500
Message-ID: <20160111160146.GC10641@char.us.oracle.com>
References: <1446838577-7563-1-git-send-email-konrad.wilk@oracle.com>
	<1446838577-7563-2-git-send-email-konrad.wilk@oracle.com>
	<5641F13F02000078000B35D3@prv-mh.provo.novell.com>
	<20160106174138.GB8633@char.us.oracle.com>
	<568E235702000078000C437E@prv-mh.provo.novell.com>
	<20160108173137.GA12321@char.us.oracle.com>
	<56937DCE02000078000C5516@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad@char.us.oracle.com>) id 1aIeuu-000395-KD
	for xen-devel@lists.xenproject.org; Mon, 11 Jan 2016 16:02:00 +0000
Content-Disposition: inline
In-Reply-To: <56937DCE02000078000C5516@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, mpohlack@amazon.de, xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
List-Id: xen-devel@lists.xenproject.org

On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
> >>> On 08.01.16 at 18:31, <konrad.wilk@oracle.com> 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.

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?

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

Or leave those out of the version_use check? (so do not act on
XSM check on those?)
> 
> Jan
>