Re: [Xen-devel] [PATCH] xen/xsm: Generate the permission in a spec-compliant way

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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 <julien.grall@xxxxxxxxxx>
> 
> 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 <dgdegra@xxxxxxxxxxxxx>
> 
> 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.
> 



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