From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH v5] Merge IS_PRIV checks into XSM hooks Date: Mon, 19 Nov 2012 10:26:47 +0000 Message-ID: <20121119102647.GA31411@ocelot.phlegethon.org> References: <1353090514-18537-1-git-send-email-dgdegra@tycho.nsa.gov> <50AA0DCE02000078000A9972@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50AA0DCE02000078000A9972@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Daniel De Graaf , keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org At 09:45 +0000 on 19 Nov (1353318334), Jan Beulich wrote: > As to getting the series applied, I suppose that'll be a little difficult, > as it mixes changes to various parts of the tree, and hence no > single maintainer would generally be able to apply the whole series > without respective other parts fully acked by the corresponding > maintainers. Is there a way to either indicate eventual fully > standalone patches, or order/split it so that at least tools side and > hypervisor side changes are separated from one another, or mixed > patches all go at the beginning or end of the series? This whole series makes me very uncomfortable. I can see its usefulness, and as a supporter of disaggregations I like the idea of fine-grained control, but it really does obscure the security checks, and makes it less likely that people implementing new operations will get their security checks right. Since there are only a small number of default checks (IS_PRIV, IS_PRIV_FOR, self-only, ???), I wonder whether they could be explicitly included in the xsm invocation (as some sort of 'enum xsm-default-policy' argument), to make it clear what's going on without the reader having to grobble around in xsm files? Cheers, Tim.