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

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

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@linaro.org>

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 <dgdegra@tycho.nsa.gov>

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

There are no other uses of permission bit 32.

-- 
Daniel De Graaf
National Security Agency