From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen/xsm: Generate the permission in a spec-compliant way Date: Mon, 23 Feb 2015 15:04:08 +0000 Message-ID: <54EB4168.1060808@linaro.org> 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.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YPubX-0007P3-Sc for xen-devel@lists.xenproject.org; Mon, 23 Feb 2015 15:07:27 +0000 Received: by mail-wi0-f170.google.com with SMTP id hi2so20370591wib.1 for ; Mon, 23 Feb 2015 07:04:35 -0800 (PST) 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 , xen-devel@lists.xenproject.org Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org Hi Daniel, On 20/02/15 23:01, 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 > > 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: Actually I think the policy is not even loaded. >>From the log I got (XEN) Flask: Initializing. (XEN) AVC INITIALIZED (XEN) Flask: 128 avtab hash slots, 278 rules. (XEN) Flask: 128 avtab hash slots, 278 rules. (XEN) Flask: 3 users, 3 roles, 39 types, 1 bools (XEN) Flask: 12 classes, 278 rules (XEN) Flask: permission setscheduler in class xen has incorrect value (XEN) Flask: the definition of a class is incorrect (XEN) Flask: Starting in enforcing mode. As the policy is not valid (see validate_classes in security_load_policy), we bail out directly. But I don't understand why we continue to boot and everything is working. Flask is not even correctly initialized... Did I miss something? Regards, -- Julien Grall