xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
@ 2016-03-18  7:41 fu.wei
  2016-03-18  8:24 ` Jan Beulich
  0 siblings, 1 reply; 4+ messages in thread
From: fu.wei @ 2016-03-18  7:41 UTC (permalink / raw)
  To: xen-devel, Ian.Campbell, julien.grall
  Cc: jcm, Fu Wei, leif.lindholm, linaro-uefi

From: Fu Wei <fu.wei@linaro.org>

This patch add a check_xsm_signature static function for detecting XSM
from the second unknown module.

If xen can't get the kind of module from compatible, we guess the kind of
these first two unknown respectively:
    (1) The first unknown must be kernel;
    (2) The second unknown is ramdisk, only if we have ramdisk;
    (3) Start from the 2nd unknown, detect the XSM binary signature;
    (4) If we got XSM in the 2nd unknown, that means we don't load initrd.

Signed-off-by: Fu Wei <fu.wei@linaro.org>
---
ChangeLog:
v1: This patch - the first upstream patch to xen-devel mailing lists.

 xen/arch/arm/bootfdt.c | 41 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..1a74ecf 100644
--- 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;
+    const struct fdt_property *prop;
+    paddr_t start, size;
+    const __be32 *cell;
+    /* 16 == sizeof(uint32_t) * 2 + sizeof("XenFlask") - 1 */
+    char magic[16];
+    int len;
+
+    prop = fdt_get_property(fdt, node, "reg", &len);
+    if ( !prop )
+        panic("node %s missing `reg' property\n", name);
+
+    if ( len < dt_cells_to_size(address_cells + size_cells) )
+        panic("fdt: node `%s': `reg` property length is too short\n", name);
+
+    cell = (const __be32 *)prop->data;
+    device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+
+    copy_from_paddr(magic, start, 16);
+    if (strncmp(magic, (char *) &selinux_magic, sizeof(uint32_t)) ||
+        strncmp(magic + sizeof(uint32_t) * 2, "XenFlask", 8))
+        return 0;
+
+    return 1;
+}
+
 static void __init process_multiboot_node(const void *fdt, int node,
                                           const char *name,
                                           u32 address_cells, u32 size_cells)
@@ -186,7 +216,13 @@ static void __init process_multiboot_node(const void *fdt, int node,
     else
         kind = BOOTMOD_UNKNOWN;
 
-    /* Guess that first two unknown are kernel and ramdisk respectively. */
+    /**
+     * Guess the kind of these first two unknown respectively:
+     * (1) The first unknown must be kernel;
+     * (2) The second unknown is ramdisk, only if we have ramdisk;
+     * (3) Start from the 2nd unknown, detect the XSM binary signature;
+     * (4) If we got XSM in the 2nd unknown, that means we have not initrd.
+     */
     if ( kind == BOOTMOD_UNKNOWN )
     {
         switch ( kind_guess++ )
@@ -195,6 +231,9 @@ static void __init process_multiboot_node(const void *fdt, int node,
         case 1: kind = BOOTMOD_RAMDISK; break;
         default: break;
         }
+        if (kind_guess > 1 && check_xsm_signature(fdt, node, name,
+                                                  address_cells, size_cells))
+            kind = BOOTMOD_XSM;
     }
 
     prop = fdt_get_property(fdt, node, "reg", &len);
-- 
2.5.0


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

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2016-03-18  8:24 UTC (permalink / raw)
  To: Fu Wei, dgdegra
  Cc: Stefano Stabellini, jcm, julien.grall, leif.lindholm,
	linaro-uefi, xen-devel

>>> On 18.03.16 at 08:41, <fu.wei@linaro.org> 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?

Jan


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
  2016-03-18  8:24 ` Jan Beulich
@ 2016-03-18  9:48   ` Fu Wei
  2016-03-25 21:02     ` Daniel De Graaf
  0 siblings, 1 reply; 4+ messages in thread
From: Fu Wei @ 2016-03-18  9:48 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Stefano Stabellini, Jon Masters, Julien Grall, Leif Lindholm,
	Linaro UEFI Mailman List, xen-devel, dgdegra

Hi Jan,

On 18 March 2016 at 16:24, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 18.03.16 at 08:41, <fu.wei@linaro.org> 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?

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.

So maybe I should do :

    uint32_t xen_magic = XEN_MAGIC;

>
> Jan
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
  2016-03-18  9:48   ` Fu Wei
@ 2016-03-25 21:02     ` Daniel De Graaf
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel De Graaf @ 2016-03-25 21:02 UTC (permalink / raw)
  To: Fu Wei, Jan Beulich
  Cc: Stefano Stabellini, Jon Masters, Julien Grall, Leif Lindholm,
	Linaro UEFI Mailman List, xen-devel

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, <fu.wei@linaro.org> 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
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-03-25 21:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).