From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] xen/xsm: Generate the permission in a spec-compliant way Date: Mon, 23 Feb 2015 09:44:38 +0000 Message-ID: <1424684678.27930.11.camel@citrix.com> References: <1424447908-8689-1-git-send-email-julien.grall@linaro.org> <54E7BCAC.5000806@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YPpZM-0005GP-SJ for xen-devel@lists.xenproject.org; Mon, 23 Feb 2015 09:44:52 +0000 In-Reply-To: <54E7BCAC.5000806@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: xen-devel@lists.xenproject.org, Julien Grall , wei.liu2@citrix.com, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Fri, 2015-02-20 at 18:01 -0500, Daniel De Graaf wrote: > On 02/20/2015 10:58 AM, Julien Grall wrote: > > Each class can contains 32 permisions which are encoded on a word (one > > bit per permission). > > > > Currently the awk script will generate an hexadecimal value for each > > permission. This may result to generate an invalid value on some version > > of awk. > > > > For instance debian jessie is using a version of mawk where (1 << 31) > > will result to 0x7fffffff. > > > > This is because the awk specification requires to do the arithmetic with > > float. So the resulting integer may vary following the implementation. > > > > As the generated headers are only used by C code, generate the > > permission define via "1UL << n". > > > > Signed-off-by: Julien Grall > > The fix looks correct. For backporting: this is only a problem since the > auto-generation was moved into the hypervisor build (between 4.2 and 4.3). > Prior to this, the headers were manually generated, and apparently nobody > ran the script on a system with this bug - in part because nobody ran ... truncated sentence? > > Acked-by: Daniel De Graaf > > Wow, that's quite an annoying bug. Thankfully, it's more likely to make a > broken system than an insecure one, since doing an access check on the > permission 0x7fffffff will result in checking for access to all 31 other > permissions instead of the one you intended to check for. For Xen, it > looks like this is unlikely to succeed, and also won't do something like > prevent the system from booting: > > class xen: setscheduler would check kexec & others > > class domain: set_virq_handler would check transition & destroy > - in the example policy, transition is only allowed for *_building -> * > - in any other policy, transition is unlikely to be allowed at the same > time as destroy Thanks for the analysis. > > There are no other uses of permission bit 32. >