[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 05.04.16 at 15:38, <fu.wei@xxxxxxxxxx> wrote:
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -19,6 +19,8 @@
>  
>  #ifdef CONFIG_XSM
>  
> +#include <asm/setup.h>

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.