Re: [Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.

2016-04-05 Thread Fu Wei
Hi Jan,

On 5 April 2016 at 22:16, Jan Beulich  wrote:
 On 05.04.16 at 15:38,  wrote:
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -19,6 +19,8 @@
>>
>>  #ifdef CONFIG_XSM
>>
>> +#include 
>
> This is not a good idea. Note how xsm_policy.c limits this inclusion to
> the CONFIG_HAS_DEVICE_TREE case only, which is the least that
> should be done here too.

OK, good point, thanks , will do.

>
>> @@ -109,6 +111,25 @@ int __init xsm_dt_init(void)
>>
>>  return ret;
>>  }
>> +
>> +/**
>> + * has_xsm_magic - Check XSM Magic of the module header by phy address
>> + * A XSM module has a special header
>> + * 
>> + * uint magic | uint target_len | uchar target[8] |
>> + * 0xf97cff8c |8|"XenFlask"   |
>> + * 
>> + * 0xf97cff8c is policy magic number (XSM_MAGIC).
>> + * Here we only check the "magic" of the module.
>> + */
>> +bool __init has_xsm_magic(paddr_t start)
>> +{
>> +xsm_magic_t magic;
>> +
>> +copy_from_paddr(&magic, start, sizeof(magic) );
>> +
>> +return ( XSM_MAGIC && magic == XSM_MAGIC );
>
> Is XSM_MAGIC == 0 possible here at all? And if it is, wouldn't it be
> better to avoid the copy_from_paddr() in that case?

yes, good idea, will do

>
> 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


Re: [Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.

2016-04-05 Thread Jan Beulich
>>> On 05.04.16 at 15:38,  wrote:
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -19,6 +19,8 @@
>  
>  #ifdef CONFIG_XSM
>  
> +#include 

This is not a good idea. Note how xsm_policy.c limits this inclusion to
the CONFIG_HAS_DEVICE_TREE case only, which is the least that
should be done here too.

> @@ -109,6 +111,25 @@ int __init xsm_dt_init(void)
>  
>  return ret;
>  }
> +
> +/**
> + * has_xsm_magic - Check XSM Magic of the module header by phy address
> + * A XSM module has a special header
> + * 
> + * uint magic | uint target_len | uchar target[8] |
> + * 0xf97cff8c |8|"XenFlask"   |
> + * 
> + * 0xf97cff8c is policy magic number (XSM_MAGIC).
> + * Here we only check the "magic" of the module.
> + */
> +bool __init has_xsm_magic(paddr_t start)
> +{
> +xsm_magic_t magic;
> +
> +copy_from_paddr(&magic, start, sizeof(magic) );
> +
> +return ( XSM_MAGIC && magic == XSM_MAGIC );

Is XSM_MAGIC == 0 possible here at all? And if it is, wouldn't it be
better to avoid the copy_from_paddr() in that case?

Jan


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


[Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.

2016-04-05 Thread fu . wei
From: Fu Wei 

This patch adds a has_xsm_magic helper 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 unknowns respectively:
(1) The first unknown must be kernel.
(2) Detect the XSM Magic from the 2nd unknown:
a. If it's XSM, set the kind as XSM, and that also means we
won't load ramdisk;
b. if it's not XSM, set the kind as ramdisk.
So if user want to load ramdisk, it must be the 2nd unknown.
We also detect the XSM Magic for the following unknowns, then set its kind
according to the return value of has_xsm_magic.

By this way, arm64 behavior can be compatible to x86 and can simplify
multi-arch bootloader such as GRUB.

Signed-off-by: Fu Wei 
---
Changelog:
v4: Fix some code style and comments problems.
Only check the Magic number.
Re-order the code in process_multiboot_node to get the base address
first, then the XSM Magic checking function only need to check if the
Magic number is valid.
Factor the XSM Magic checking code into an helper and re-use it
in xsm_dt_policy_init.

v3: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html
Using memcmp instead of strncmp.
Using "return 0;" instead of panic();
Improve some comments.

v2: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03543.html
Using XEN_MAGIC macro instead of 0xf97cff8c :
uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = XEN_MAGIC;
Comment out the code(return 0 directly), if CONFIG_FLASK is not set.

v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
The first upstream patch to xen-devel mailing lists.

 xen/arch/arm/bootfdt.c | 37 +
 xen/include/xsm/xsm.h  |  8 +++-
 xen/xsm/xsm_core.c | 21 +
 xen/xsm/xsm_policy.c   |  8 ++--
 4 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..d130633 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static bool_t __init device_tree_node_matches(const void *fdt, int node,
@@ -175,6 +176,17 @@ static void __init process_multiboot_node(const void *fdt, 
int node,
 const char *cmdline;
 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);
+
 if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
  fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
 kind = BOOTMOD_KERNEL;
@@ -186,7 +198,17 @@ 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 unknowns respectively:
+ * (1) The first unknown must be kernel.
+ * (2) Detect the XSM Magic from the 2nd unknown:
+ * a. If it's XSM, set the kind as XSM, and that also means we
+ * won't load ramdisk;
+ * b. if it's not XSM, set the kind as ramdisk.
+ * So if user want to load ramdisk, it must be the 2nd unknown.
+ * We also detect the XSM Magic for the following unknowns,
+ * then set its kind according to the return value of has_xsm_magic.
+ */
 if ( kind == BOOTMOD_UNKNOWN )
 {
 switch ( kind_guess++ )
@@ -195,19 +217,10 @@ static void __init process_multiboot_node(const void 
*fdt, int node,
 case 1: kind = BOOTMOD_RAMDISK; break;
 default: break;
 }
+   if ( kind_guess > 1 && has_xsm_magic(start) )
+kind = BOOTMOD_XSM;
 }
 
-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);
-
 prop = fdt_get_property(fdt, node, "bootargs", &len);
 if ( prop )
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3afed70..803c7ea 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -745,6 +745,7 @@ extern int xsm_multiboot_policy_init(unsigned long 
*module_map,
 #ifdef CONFIG_HAS_DEVICE_TREE
 extern int xsm_dt_init(void);
 extern int xsm_dt_policy_init(void);
+extern bool has_xsm_magic(paddr_t);
 #endif
 
 extern int