From: Daniel De Graaf <email@example.com>
To: Fu Wei <firstname.lastname@example.org>, Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <email@example.com>,
Jon Masters <firstname.lastname@example.org>,
Julien Grall <email@example.com>,
Leif Lindholm <firstname.lastname@example.org>,
Linaro UEFI Mailman List <email@example.com>,
Subject: Re: [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
Date: Fri, 25 Mar 2016 17:02:19 -0400 [thread overview]
Message-ID: <56F5A75B.firstname.lastname@example.org> (raw)
On 03/18/2016 05:48 AM, Fu Wei wrote:
> Hi Jan,
> On 18 March 2016 at 16:24, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 18.03.16 at 08:41, <email@example.com> wrote:
>>> --- a/xen/arch/arm/bootfdt.c
>>> +++ b/xen/arch/arm/bootfdt.c
>>> @@ -163,6 +163,36 @@ static void __init process_memory_node(const void *fdt, int node,
>>> +static bool __init check_xsm_signature(const void *fdt, int node,
>>> + const char *name,
>>> + u32 address_cells, u32 size_cells)
>>> + uint32_t selinux_magic = 0xf97cff8c;
>> So this would be the 3rd instance of this literal number in the source
>> base. I would have wanted to suggest using one of the two
>> constants we already have, but I don't know which one to pick.
>> Daniel - why do we have both XSM_MAGIC and FLASK_MAGIC?
I think the intent was that FLASK_MAGIC be the primary source of the
constant with XSM_MAGIC set to that value when FLASK was the chosen
XSM module. With the relative locations of the definitions in Xen,
this ended up duplicating the literal which isn't quite as nice. I
would be fine with consolidating either way; perhaps move FLASK_MAGIC
into xsm.h and conditionally define XSM_MAGIC to reference it?
> Ah, Sorry for that , I didn't know we already have these definition.
> OK, I think we should use XSM_MAGIC,
> and I think FLASK_MAGIC should be "XenFlask".
> Please correct me if I misunderstand something.
These constants are also defined as POLICYDB_MAGIC and POLICYDB_STRING
in xen/xsm/flask/ss/policydb.h (that will probably need to be moved if
you want to use them elsewhere).
The hypervisor also supports loading policies whose magic type declares
them to be SELinux policy, but I think it's fine if ARM requires that
the policy be built targeting Xen - the build has done that for a while,
and the original reason (older versions of checkpolicy didn't support
creating xen-type policy) is no longer an issue.
Daniel De Graaf
National Security Agency
Xen-devel mailing list
prev parent reply other threads:[~2016-03-25 21:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 7:41 [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module fu.wei
2016-03-18 8:24 ` Jan Beulich
2016-03-18 9:48 ` Fu Wei
2016-03-25 21:02 ` Daniel De Graaf [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).