[Xen-devel] x86_64 to i386 boot generation conversion
Hi everyone, I was wondering why when I build an x86_64 xen I got a mkelf32 command converting elf 64 to elf 32. My understanding, looking at git-log, is that that was needed for 32bits bootloaders. Is that the only reason ? Is it still necessary today ? Thanks. Nicolas . ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] flask: sort io{port,mem}con entries
> -Daniel De Graaf wrote: -
> To: xen-devel@lists.xenproject.org, Nicolas Poirot
> From: Daniel De Graaf
> Date: 05/10/2018 18:33
> Cc: George Dunlap , Jan Beulich ,
> Daniel De Graaf
> Subject: [PATCH v2] flask: sort io{port,mem}con entries
>
> These entries are not always sorted by checkpolicy, so sort them during
> policy load (as is already done for later ocontext additions).
>
> Reported-by: Nicolas Poirot
> Signed-off-by: Daniel De Graaf
> ---
> xen/xsm/flask/ss/policydb.c | 35 +--
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
> index 3a12d96ef9..9426164353 100644
> --- a/xen/xsm/flask/ss/policydb.c
> +++ b/xen/xsm/flask/ss/policydb.c
> @@ -1737,7 +1737,7 @@ int policydb_read(struct policydb *p, void *fp)
> {
> struct role_allow *ra, *lra;
> struct role_trans *tr, *ltr;
> -struct ocontext *l, *c /*, *newc*/;
> +struct ocontext *l, *c, **pn;
> int i, j, rc;
> __le32 buf[8];
> u32 len, /*len2,*/ config, nprim, nel /*, nel2*/;
> @@ -1994,6 +1994,7 @@ int policydb_read(struct policydb *p, void *fp)
> if ( rc < 0 )
> goto bad;
> nel = le32_to_cpu(buf[0]);
> +pn = >ocontexts[i];
> l = NULL;
> for ( j = 0; j < nel; j++ )
> {
> @@ -2003,11 +2004,6 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -ENOMEM;
> goto bad;
> }
> -if ( l )
> -l->next = c;
> -else
> -p->ocontexts[i] = c;
> -l = c;
> rc = -EINVAL;
> switch ( i )
> {
> @@ -2050,6 +2046,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> +
> +if ( *pn || ( l && l->u.ioport.high_ioport >=
> c->u.ioport.low_ioport ) )
> +{
> +pn = >ocontexts[i];
> +l = *pn;
> +while ( l && l->u.ioport.high_ioport <
> c->u.ioport.low_ioport ) {
> +pn = >next;
> +l = *pn;
> +}
> +c->next = l;
> +}
> +l = c;
> break;
> case OCON_IOMEM:
> if ( p->target_type != TARGET_XEN )
> @@ -2078,6 +2086,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> +
> +if ( *pn || ( l && l->u.iomem.high_iomem >=
> c->u.iomem.low_iomem ) )
> +{
> +pn = >ocontexts[i];
> +l = *pn;
> +while ( l && l->u.iomem.high_iomem <
> c->u.iomem.low_iomem ) {
> +pn = >next;
> +l = *pn;
> +}
> +c->next = l;
> +}
> +l = c;
> break;
> case OCON_DEVICE:
> if ( p->target_type != TARGET_XEN )
> @@ -2123,6 +2143,9 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -EINVAL;
> goto bad;
> }
> +
> +*pn = c;
> +pn = >next;
> }
> }
>
> --
> 2.14.4
Tested on the same conditions as the previous patch, looks good.
Thank you.
Tested-by: Nicolas Poirot
Reviewed-by: Nicolas Poirot
1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] flask: sort io{port,mem}con entries
> -Daniel De Graaf wrote: -
> To: xen-devel@lists.xenproject.org, Nicolas Poirot
> From: Daniel De Graaf
> Date: 10/05/2018 06:33PM
> Cc: George Dunlap , Jan Beulich ,
> Daniel De Graaf
> Subject: [PATCH v2] flask: sort io{port,mem}con entries
>
> These entries are not always sorted by checkpolicy, so sort them during
> policy load (as is already done for later ocontext additions).
>
> Reported-by: Nicolas Poirot
> Signed-off-by: Daniel De Graaf
> ---
> xen/xsm/flask/ss/policydb.c | 35 +--
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
> index 3a12d96ef9..9426164353 100644
> --- a/xen/xsm/flask/ss/policydb.c
> +++ b/xen/xsm/flask/ss/policydb.c
> @@ -1737,7 +1737,7 @@ int policydb_read(struct policydb *p, void *fp)
> {
> struct role_allow *ra, *lra;
> struct role_trans *tr, *ltr;
> - struct ocontext *l, *c /*, *newc*/;
> + struct ocontext *l, *c, **pn;
> int i, j, rc;
> __le32 buf[8];
> u32 len, /*len2,*/ config, nprim, nel /*, nel2*/;
> @@ -1994,6 +1994,7 @@ int policydb_read(struct policydb *p, void *fp)
> if ( rc < 0 )
> goto bad;
> nel = le32_to_cpu(buf[0]);
> + pn = >ocontexts[i];
> l = NULL;
> for ( j = 0; j < nel; j++ )
> {
> @@ -2003,11 +2004,6 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -ENOMEM;
> goto bad;
> }
> - if ( l )
> - l->next = c;
> - else
> - p->ocontexts[i] = c;
> - l = c;
> rc = -EINVAL;
> switch ( i )
> {
> @@ -2050,6 +2046,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> +
> + if ( *pn || ( l && l->u.ioport.high_ioport >=
> c->u.ioport.low_ioport ) )
> + {
> + pn = >ocontexts[i];
> + l = *pn;
> + while ( l && l->u.ioport.high_ioport <
> c->u.ioport.low_ioport ) {
> + pn = >next;
> + l = *pn;
> + }
> + c->next = l;
> + }
> + l = c;
> break;
> case OCON_IOMEM:
> if ( p->target_type != TARGET_XEN )
> @@ -2078,6 +2086,18 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> +
> + if ( *pn || ( l && l->u.iomem.high_iomem >=
> c->u.iomem.low_iomem ) )
> + {
> + pn = >ocontexts[i];
> + l = *pn;
> + while ( l && l->u.iomem.high_iomem <
> c->u.iomem.low_iomem ) {
> + pn = >next;
> + l = *pn;
> + }
> + c->next = l;
> + }
> + l = c;
> break;
> case OCON_DEVICE:
> if ( p->target_type != TARGET_XEN )
> @@ -2123,6 +2143,9 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -EINVAL;
> goto bad;
> }
> +
> + *pn = c;
> + pn = >next;
> }
> }
>
> --
> 2.14.4
Tested in the same conditions as the previous patch, looks good.
Thank you.
Tested-by: Nicolas Poirot
Reviewed-by: Nicolas Poirot
1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] flask: Add check for io{port, mem}con sorting
> To: xen-devel@lists.xenproject.org
> From: Daniel De Graaf
> Sent by: "Xen-devel"
> Date: 09/28/2018 09:13PM
> Cc: George Dunlap , Daniel De Graaf
> Subject: [Xen-devel] [PATCH] flask: Add check for io{port,mem}con sorting
>
> These entries are not always sorted by checkpolicy. Enforce the sorting
> (which can be done manually if using an unpatched checkpolicy) when
> loading the policy so that later uses by the security server do not
> incorrectly use the initial sid.
>
> Reported-by: Nicolas Poirot
> Signed-off-by: Daniel De Graaf
> ---
> xen/xsm/flask/ss/policydb.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
> index 3a12d96ef9..fcf63693b9 100644
> --- a/xen/xsm/flask/ss/policydb.c
> +++ b/xen/xsm/flask/ss/policydb.c
> @@ -2007,7 +2007,6 @@ int policydb_read(struct policydb *p, void *fp)
> l->next = c;
> else
> p->ocontexts[i] = c;
> - l = c;
> rc = -EINVAL;
> switch ( i )
> {
> @@ -2050,6 +2049,12 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> + if ( l && l->u.ioport.high_ioport > c->u.ioport.low_ioport )
> + {
> + printk(KERN_ERR
> + "Flask: Invalid policy, ioportcon not sorted\n");
> + goto bad;
> + }
> break;
> case OCON_IOMEM:
> if ( p->target_type != TARGET_XEN )
> @@ -2078,6 +2083,12 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> + if ( l && l->u.iomem.high_iomem > c->u.iomem.low_iomem )
> + {
> + printk(KERN_ERR
> + "Flask: Invalid policy, iomemcon not sorted\n");
> + goto bad;
> + }
> break;
> case OCON_DEVICE:
> if ( p->target_type != TARGET_XEN )
> @@ -2123,6 +2134,7 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -EINVAL;
> goto bad;
> }
> + l = c;
> }
> }
>
> --
> 2.14.4
Looks good to me.
Tested on RELEASE-4.11.0 on a juno-r2 platform, with checkpolicy 2.5.
Thank you.
Tested-by: Nicolas Poirot
Reviewed-by: Nicolas Poirot
.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] XSM/Flask iomem
Ok thanks. I didn't suspect checkpolicy to be in charge of this. I used the version 2.5 so far. -Daniel De Graaf a écrit : - A : nicolas.poi...@bertin.fr De : Daniel De Graaf Date : 28/09/2018 21:13 Cc : George Dunlap , xen-devel Objet : Re: [Xen-users] XSM/Flask iomem This is apparently a mismatch between what the checkpolicy compilation does and what it is expected to do. While some parts of checkpolicy do this sorting, the main compilation flow does not, and the policy compilation process does not ensure inputs are sorted. In the future, newer versions of checkpolicy should fix this bug. Newer versions of Xen may also start checking this ordering on policy load (I'll submit a patch to do this). This bug also applies to I/O ports, but not the other types of policy items (IRQs, PCI devices, or devicetree). It will cause non-sorted entries to be skipped in most cases, instead querying the default sid, but larger iomem/ioport ranges might also query the skipped entry (always in addition to the default). Until the fixed version of checkpoicy is released and adopted, policy writers can manually sort their iomem/ioport ranges as a workaround. On 09/27/2018 06:18 AM, George Dunlap wrote: > [Moving to xen-devel] > > Daniel, > > Any comments on this one? > > -George > On Wed, Sep 26, 2018 at 12:41 PM wrote: >> >> Hi, >> >> I just noticed from a bad behaviour of my installation and the >> security_iterate_iomem_sids >> function that the iomem ranges have to be sorted in the device_contexts file. >> The flask load policy takes iomem ranges declaration as it comes but the sid >> attribution >> and check function expects the list of iomem ocontexts to be sorted. >> My file didn't comply with this statement which ended to use the default >> iomem sid instead >> of computing one before checking the permission. >> >> This doesn't seem to be documented anywhere in the xen release 4.11.0. >> >> Thanks. >> >> Nicolas >> 1 >> >> >> ___ >> Xen-users mailing list >> xen-us...@lists.xenproject.org >> https://lists.xenproject.org/mailman/listinfo/xen-users 1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
