thr3ads.net - Xen devel - [PATCH 1/5] build: Export configure variables to hypervisor build [Feb 2012]

If this information is useful, please help other people find it:
Share via:

Daniel De Graaf

2012-Feb-28 23:27 UTC

[PATCH 1/5] build: Export configure variables to hypervisor build

Since the introduction of autoconf, builds with XSM enabled in .config
have been broken unless FLASK_ENABLE was explicitly set. Since the
setting in .config has apparently been deprecated in favor of an
autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
also makes --disable-debug and some paths to be pulled from the
configure process in the hypervisor build.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 .gitignore         |    1 +
 .hgignore          |    1 +
 config/Tools.mk.in |    4 ----
 config/Xen.mk.in   |   19 +++++++++++++++++++
 tools/configure.ac |    1 +
 xen/Rules.mk       |    1 +
 6 files changed, 23 insertions(+), 4 deletions(-)
 create mode 100644 config/Xen.mk.in

diff --git a/.gitignore b/.gitignore
index 8810b35..865505f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -111,6 +111,7 @@ tools/config.log
 tools/config.status
 tools/config.cache
 config/Tools.mk
+config/Xen.mk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/.hgignore b/.hgignore
index 46655ad..7d5ccc1 100644
--- a/.hgignore
+++ b/.hgignore
@@ -309,6 +309,7 @@
 ^tools/config\.status$
 ^tools/config\.cache$
 ^config/Tools\.mk$
+^config/Xen\.mk$
 ^xen/\.banner.*$
 ^xen/BLOG$
 ^xen/System.map$
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 06d5e89..315ced4 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE          := @xsm@
-FLASK_ENABLE        := @xsm@
-
 # Download GIT repositories via HTTP or GIT''s own protocol?
 # GIT''s protocol is faster and more robust, when it works at all
(firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/config/Xen.mk.in b/config/Xen.mk.in
new file mode 100644
index 0000000..e152f39
--- /dev/null
+++ b/config/Xen.mk.in
@@ -0,0 +1,19 @@
+# Prefix and install folder
+PREFIX              := @prefix@
+LIBLEAFDIR_x86_64   := @LIB_PATH@
+
+# A debug build of xen?
+debug               := @debug@
+
+# Tools path
+PYTHON              := @PYTHON@
+
+# Extra folder for libs/includes
+PREPEND_INCLUDES    := @PREPEND_INCLUDES@
+PREPEND_LIB         := @PREPEND_LIB@
+APPEND_INCLUDES     := @APPEND_INCLUDES@
+APPEND_LIB          := @APPEND_LIB@
+
+# Enable XSM security module (by default, Flask).
+XSM_ENABLE          := @xsm@
+FLASK_ENABLE        := @xsm@
diff --git a/tools/configure.ac b/tools/configure.ac
index c5dec9c..5b2815d 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -6,6 +6,7 @@ AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh
../xen/Makefile]),
     [xen-devel@lists.xensource.com])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
 AC_CONFIG_FILES([../config/Tools.mk])
+AC_CONFIG_FILES([../config/Xen.mk])
 AC_CONFIG_HEADERS([config.h])
 AC_PREFIX_DEFAULT([/usr])
 AC_CONFIG_AUX_DIR([.])
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 6123835..6c17a3f 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -12,6 +12,7 @@ frame_pointer ?= n
 lto           ?= n
 
 include $(XEN_ROOT)/Config.mk
+include $(XEN_ROOT)/config/Xen.mk
 
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
-- 
1.7.7.6

Daniel De Graaf

2012-Feb-28 23:27 UTC

head link

[PATCH 2/5] xsm: label xen-consumer event channels

Event channels created during the domain build process for HVM domains
did not call the XSM creation hook. Since these channels are used
internally by Xen, redirect them to DOMAIN_INVAID instead of failing to
create if the XSM hook fails the permissions check.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 989ebae..ce309da 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1106,6 +1106,7 @@ int alloc_unbound_xen_event_channel(
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
     int            port;
+    int            rc;
 
     spin_lock(&d->event_lock);
 
@@ -1113,10 +1114,15 @@ int alloc_unbound_xen_event_channel(
         goto out;
     chn = evtchn_from_port(d, port);
 
+    rc = xsm_evtchn_unbound(d, chn, remote_domid);
+
     chn->state = ECS_UNBOUND;
     chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
-    chn->u.unbound.remote_domid = remote_domid;
+    if ( rc )
+        chn->u.unbound.remote_domid = DOMID_INVALID;
+    else
+        chn->u.unbound.remote_domid = remote_domid;
 
  out:
     spin_unlock(&d->event_lock);
-- 
1.7.7.6

Daniel De Graaf

2012-Feb-28 23:27 UTC

head link

[PATCH 3/5] xsm/flask: clean interdomain event channel hook

Don''t attempt to relabel the already-bound half of the event channel
pair created by an interdomain event channel. This relabeling also
performed an incorrect check that the destination domain is permitted to
create the reverse event channel, which may not be true if the unbound
channel was created by the domain builder (like the xenstore channel).

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   30 ++++++++----------------------
 1 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 649c473..9948fca 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -182,12 +182,12 @@ static int flask_evtchn_unbound(struct domain *d1, struct
evtchn *chn,
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid1;
-    u32 newsid2;
+    u32 newsid;
     int rc;
-    struct domain_security_struct *dsec1, *dsec2;
+    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec1, *esec2;
 
+    dsec = current->domain->ssid;
     dsec1 = d1->ssid;
     dsec2 = d2->ssid;
 
@@ -195,7 +195,7 @@ static int flask_evtchn_interdomain(struct domain *d1,
struct evtchn *chn1,
     esec2 = chn2->ssid;
 
     rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid1);
+                                 SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d
(domain=%d)\n",
@@ -203,33 +203,19 @@ static int flask_evtchn_interdomain(struct domain *d1,
struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec1->sid, newsid1, SECCLASS_EVENT, EVENT__CREATE,
NULL);
-    if ( rc )
-        return rc;
-
-    rc = security_transition_sid(dsec2->sid, dsec1->sid, 
-                                 SECCLASS_EVENT, &newsid2);
+    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE,
NULL);
     if ( rc )
-    {
-        printk("%s: security_transition_sid failed, rc=%d
(domain=%d)\n",
-               __FUNCTION__, -rc, d1->domain_id);
         return rc;
-    }
 
-    rc = avc_has_perm(dsec2->sid, newsid2, SECCLASS_EVENT, EVENT__CREATE,
NULL);
+    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND,
NULL);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid1, dsec2->sid, SECCLASS_EVENT, EVENT__BIND,
NULL);
+    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT,
EVENT__BIND, NULL);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid2, dsec1->sid, SECCLASS_EVENT, EVENT__BIND,
NULL);
-    if ( rc )
-        return rc;    
-
-    esec1->sid = newsid1;
-    esec2->sid = newsid2;
+    esec1->sid = newsid;
 
     return rc;
 }
-- 
1.7.7.6

Daniel De Graaf

2012-Feb-28 23:27 UTC

head link

[PATCH 4/5] xsm/flask: buffer AVC messages for output

When multiple CPUs hit an AVC audit message, the resulting output in the
ring buffer and serial console is garbled due to the audit process using
many separate printk invocations for each message. Change the AVC audit
process to use a temporary buffer and output the contents once the
entire audit message is complete.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c |  107 +++++++++++++++++++++++++++++++++++++++------------
 1 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 74f160d..b5486a3 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -132,12 +132,54 @@ static inline int avc_hash(u32 ssid, u32 tsid, u16 tclass)
     return (ssid ^ (tsid<<2) ^ (tclass<<4)) & (AVC_CACHE_SLOTS
- 1);
 }
 
+/* no use making this larger than the printk buffer */
+#define AVC_BUF_SIZE 1024
+static DEFINE_SPINLOCK(avc_emerg_lock);
+static char avc_emerg_buf[AVC_BUF_SIZE];
+
+struct avc_dump_buf {
+    char *start;
+    char *pos;
+    u32 free;
+};
+
+static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
+{
+    int i;
+    va_list args;
+
+ again:
+    va_start(args, fmt);
+    i = vsnprintf(buf->pos, buf->free, fmt, args);
+    va_end(args);
+    if ( i < buf->free )
+    {
+        buf->pos += i;
+        buf->free -= i;
+    }
+    else if ( buf->free < AVC_BUF_SIZE )
+    {
+        buf->pos[0] = 0;
+        printk("%s", buf->start);
+        buf->pos = buf->start;
+        buf->free = AVC_BUF_SIZE;
+        goto again;
+    }
+    else
+    {
+        printk("%s", buf->start);
+        printk("\navc_printk: overflow\n");
+        buf->pos = buf->start;
+        buf->free = AVC_BUF_SIZE;
+    }
+}
+
 /**
  * avc_dump_av - Display an access vector in human-readable form.
  * @tclass: target security class
  * @av: access vector
  */
-static void avc_dump_av(u16 tclass, u32 av)
+static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
     const char **common_pts = NULL;
     u32 common_base = 0;
@@ -145,7 +187,7 @@ static void avc_dump_av(u16 tclass, u32 av)
 
     if ( av == 0 )
     {
-        printk(" null");
+        avc_printk(buf, " null");
         return;
     }
 
@@ -159,14 +201,14 @@ static void avc_dump_av(u16 tclass, u32 av)
         }
     }
 
-    printk(" {");
+    avc_printk(buf, " {");
     i = 0;
     perm = 1;
     while ( perm < common_base )
     {
         if (perm & av)
         {
-            printk(" %s", common_pts[i]);
+            avc_printk(buf, " %s", common_pts[i]);
             av &= ~perm;
         }
         i++;
@@ -185,7 +227,7 @@ static void avc_dump_av(u16 tclass, u32 av)
             }
             if ( i2 < ARRAY_SIZE(av_perm_to_string) )
             {
-                printk(" %s", av_perm_to_string[i2].name);
+                avc_printk(buf, " %s", av_perm_to_string[i2].name);
                 av &= ~perm;
             }
         }
@@ -194,9 +236,9 @@ static void avc_dump_av(u16 tclass, u32 av)
     }
 
     if ( av )
-        printk(" 0x%x", av);
+        avc_printk(buf, " 0x%x", av);
 
-    printk(" }");
+    avc_printk(buf, " }");
 }
 
 /**
@@ -205,7 +247,7 @@ static void avc_dump_av(u16 tclass, u32 av)
  * @tsid: target security identifier
  * @tclass: target security class
  */
-static void avc_dump_query(u32 ssid, u32 tsid, u16 tclass)
+static void avc_dump_query(struct avc_dump_buf *buf, u32 ssid, u32 tsid, u16
tclass)
 {
     int rc;
     char *scontext;
@@ -213,23 +255,23 @@ static void avc_dump_query(u32 ssid, u32 tsid, u16 tclass)
 
     rc = security_sid_to_context(ssid, &scontext, &scontext_len);
     if ( rc )
-        printk("ssid=%d", ssid);
+        avc_printk(buf, "ssid=%d", ssid);
     else
     {
-        printk("scontext=%s", scontext);
+        avc_printk(buf, "scontext=%s", scontext);
         xfree(scontext);
     }
 
     rc = security_sid_to_context(tsid, &scontext, &scontext_len);
     if ( rc )
-        printk(" tsid=%d", tsid);
+        avc_printk(buf, " tsid=%d", tsid);
     else
     {
-        printk(" tcontext=%s", scontext);
+        avc_printk(buf, " tcontext=%s", scontext);
         xfree(scontext);
     }
 
-    printk(" tclass=%s", class_to_string[tclass]);
+    avc_printk(buf, " tclass=%s", class_to_string[tclass]);
 }
 
 /**
@@ -544,6 +586,7 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32
requested,
 {
     struct domain *cdom = current->domain;
     u32 denied, audited;
+    struct avc_dump_buf buf;
 
     denied = requested & ~avd->allowed;
     if ( denied )
@@ -562,36 +605,50 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32
requested,
         if ( !(audited & avd->auditallow) )
             return;
     }
+    buf.start = xmalloc_bytes(AVC_BUF_SIZE);
+    if ( !buf.start )
+    {
+        spin_lock(&avc_emerg_lock);
+        buf.start = avc_emerg_buf;
+    }
+    buf.pos = buf.start;
+    buf.free = AVC_BUF_SIZE;
 
-    printk("avc:  %s ", denied ? "denied" :
"granted");
-    avc_dump_av(tclass, audited);
-    printk(" for ");
+    avc_printk(&buf, "avc:  %s ", denied ? "denied" :
"granted");
+    avc_dump_av(&buf, tclass, audited);
+    avc_printk(&buf, " for ");
 
     if ( a && (a->sdom || a->tdom) )
     {
         if ( a->sdom && a->tdom && a->sdom !=
a->tdom )
-            printk("domid=%d target=%d ", a->sdom->domain_id,
a->tdom->domain_id);
+            avc_printk(&buf, "domid=%d target=%d ",
a->sdom->domain_id, a->tdom->domain_id);
         else if ( a->sdom )
-            printk("domid=%d ", a->sdom->domain_id);
+            avc_printk(&buf, "domid=%d ",
a->sdom->domain_id);
         else
-            printk("target=%d ", a->tdom->domain_id);
+            avc_printk(&buf, "target=%d ",
a->tdom->domain_id);
     }
     else if ( cdom )
-        printk("domid=%d ", cdom->domain_id);
+        avc_printk(&buf, "domid=%d ", cdom->domain_id);
     switch ( a ? a->type : 0 ) {
     case AVC_AUDIT_DATA_DEV:
-        printk("device=0x%lx ", a->device);
+        avc_printk(&buf, "device=0x%lx ", a->device);
         break;
     case AVC_AUDIT_DATA_IRQ:
-        printk("irq=%d ", a->irq);
+        avc_printk(&buf, "irq=%d ", a->irq);
         break;
     case AVC_AUDIT_DATA_RANGE:
-        printk("range=0x%lx-0x%lx ", a->range.start,
a->range.end);
+        avc_printk(&buf, "range=0x%lx-0x%lx ", a->range.start,
a->range.end);
         break;
     }
 
-    avc_dump_query(ssid, tsid, tclass);
-    printk("\n");
+    avc_dump_query(&buf, ssid, tsid, tclass);
+    avc_printk(&buf, "\n");
+    printk("%s", buf.start);
+
+    if ( buf.start == avc_emerg_buf )
+        spin_unlock(&avc_emerg_lock);
+    else
+        xfree(buf.start);
 }
 
 /**
-- 
1.7.7.6

Daniel De Graaf

2012-Feb-28 23:27 UTC

head link

[PATCH 5/5] xsm: expose context of event channel peers

This hypercall allows a domain to identify the security context of a
domain that it is communicating with using the interdomain event channel
that it is using for the communication. This can be used to augment
Xen''s security permissions with intra-domain security checks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c        |    8 --------
 xen/include/public/xsm/flask_op.h |    9 +++++++++
 xen/include/xen/event.h           |   10 ++++++++++
 xen/xsm/flask/flask_op.c          |   36 ++++++++++++++++++++++++++++++++++++
 4 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index ce309da..38df69d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -32,14 +32,6 @@
 #include <public/event_channel.h>
 #include <xsm/xsm.h>
 
-#define bucket_from_port(d,p) \
-    ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
-#define port_is_valid(d,p)    \
-    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
-     (bucket_from_port(d,p) != NULL))
-#define evtchn_from_port(d,p) \
-    (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
-
 #define ERROR_EXIT(_errno)                                          \
     do {                                                            \
         gdprintk(XENLOG_WARNING,                                    \
diff --git a/xen/include/public/xsm/flask_op.h
b/xen/include/public/xsm/flask_op.h
index 83dcd99..1a251c9 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -135,6 +135,13 @@ struct xen_flask_ocontext {
     uint64_t low, high;
 };
 
+struct xen_flask_peersid {
+    /* IN */
+    evtchn_port_t evtchn;
+    /* OUT */
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -159,6 +166,7 @@ struct xen_flask_op {
 #define FLASK_MEMBER            20
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
+#define FLASK_GET_PEER_SID      23
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -176,6 +184,7 @@ struct xen_flask_op {
         struct xen_flask_cache_stats cache_stats;
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
+        struct xen_flask_peersid peersid;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 22fc6a3..11a639a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -70,6 +70,16 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
 
+/* Internal event channel object accessors */
+#define bucket_from_port(d,p) \
+    ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])
+#define port_is_valid(d,p)    \
+    (((p) >= 0) && ((p) < MAX_EVTCHNS(d)) && \
+     (bucket_from_port(d,p) != NULL))
+#define evtchn_from_port(d,p) \
+    (&(bucket_from_port(d,p))[(p)&(EVTCHNS_PER_BUCKET-1)])
+
+
 /* Wait on a Xen-attached event channel. */
 #define wait_on_xen_event_channel(port, condition)                      \
     do {                                                                \
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 00a0af2..bd4db37 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -9,6 +9,7 @@
  */
 
 #include <xen/errno.h>
+#include <xen/event.h>
 #include <xsm/xsm.h>
 #include <xen/guest_access.h>
 
@@ -44,6 +45,7 @@ integer_param("flask_enabled", flask_enabled);
         1UL<<FLASK_AVC_HASHSTATS | \
         1UL<<FLASK_AVC_CACHESTATS | \
         1UL<<FLASK_MEMBER | \
+        1UL<<FLASK_GET_PEER_SID | \
    0)
 
 static DEFINE_SPINLOCK(sel_sem);
@@ -541,6 +543,36 @@ static int flask_ocontext_add(struct xen_flask_ocontext
*arg)
     return security_ocontext_add(arg->ocon, arg->low, arg->high,
arg->sid);
 }
 
+static int flask_get_peer_sid(struct xen_flask_peersid *arg)
+{
+    int rv = -EINVAL;
+    struct domain *d = current->domain;
+    struct domain *peer;
+    struct evtchn *chn;
+    struct domain_security_struct *dsec;
+
+    spin_lock(&d->event_lock);
+
+    if ( !port_is_valid(d, arg->evtchn) )
+        goto out;
+
+    chn = evtchn_from_port(d, arg->evtchn);
+    if ( chn->state != ECS_INTERDOMAIN )
+        goto out;
+
+    peer = chn->u.interdomain.remote_dom;
+    if ( !peer )
+        goto out;
+
+    dsec = peer->ssid;
+    arg->sid = dsec->sid;
+    rv = 0;
+
+ out:
+    spin_unlock(&d->event_lock);
+    return rv;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -644,6 +676,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_ocontext_del(&op.u.ocontext);
         break;
 
+    case FLASK_GET_PEER_SID:
+        rv = flask_get_peer_sid(&op.u.peersid);
+        break;
+
     default:
         rv = -ENOSYS;
     }
-- 
1.7.7.6

Ian Campbell

2012-Feb-29 11:00 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

On Tue, 2012-02-28 at 23:27 +0000, Daniel De Graaf
wrote:> Since the introduction of autoconf, builds with XSM enabled in .config
> have been broken unless FLASK_ENABLE was explicitly set. Since the
> setting in .config has apparently been deprecated in favor of an
> autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
> also makes --disable-debug and some paths to be pulled from the
> configure process in the hypervisor build.
AIUI the intention was for only the tools to require configure, which is
why it is tools/configure* and not just configure*.

I''m not sure anyone thought about the case of options like FLASK_ENABLE
which have both hypervisor and tools components controlled by a single
option.

It seems like the intention would have been to retain FLASK_ENABLE for
the hypervisor but enable the tools via configure -- but that seems
disconnected in a really odd way to me.

Perhaps we should just move the configure stuff up to the top level and
agree that it can control both tools and hypervisor configuration
options? I''m not sure why we would want to use different mechanisms for
the tools and h/v anyway.

Ian.> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> ---
>  .gitignore         |    1 +
>  .hgignore          |    1 +
>  config/Tools.mk.in |    4 ----
>  config/Xen.mk.in   |   19 +++++++++++++++++++
>  tools/configure.ac |    1 +
>  xen/Rules.mk       |    1 +
>  6 files changed, 23 insertions(+), 4 deletions(-)
>  create mode 100644 config/Xen.mk.in
> 
> diff --git a/.gitignore b/.gitignore
> index 8810b35..865505f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -111,6 +111,7 @@ tools/config.log
>  tools/config.status
>  tools/config.cache
>  config/Tools.mk
> +config/Xen.mk
>  tools/blktap2/daemon/blktapctrl
>  tools/blktap2/drivers/img2qcow
>  tools/blktap2/drivers/lock-util
> diff --git a/.hgignore b/.hgignore
> index 46655ad..7d5ccc1 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -309,6 +309,7 @@
>  ^tools/config\.status$
>  ^tools/config\.cache$
>  ^config/Tools\.mk$
> +^config/Xen\.mk$
>  ^xen/\.banner.*$
>  ^xen/BLOG$
>  ^xen/System.map$
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 06d5e89..315ced4 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
>  APPEND_INCLUDES     := @APPEND_INCLUDES@
>  APPEND_LIB          := @APPEND_LIB@
>  
> -# Enable XSM security module (by default, Flask).
> -XSM_ENABLE          := @xsm@
> -FLASK_ENABLE        := @xsm@
> -
>  # Download GIT repositories via HTTP or GIT''s own protocol?
>  # GIT''s protocol is faster and more robust, when it works at all
(firewalls
>  # may block it). We make it the default, but if your GIT repository
downloads
> diff --git a/config/Xen.mk.in b/config/Xen.mk.in
> new file mode 100644
> index 0000000..e152f39
> --- /dev/null
> +++ b/config/Xen.mk.in
> @@ -0,0 +1,19 @@
> +# Prefix and install folder
> +PREFIX              := @prefix@
> +LIBLEAFDIR_x86_64   := @LIB_PATH@
> +
> +# A debug build of xen?
> +debug               := @debug@
> +
> +# Tools path
> +PYTHON              := @PYTHON@
> +
> +# Extra folder for libs/includes
> +PREPEND_INCLUDES    := @PREPEND_INCLUDES@
> +PREPEND_LIB         := @PREPEND_LIB@
> +APPEND_INCLUDES     := @APPEND_INCLUDES@
> +APPEND_LIB          := @APPEND_LIB@
> +
> +# Enable XSM security module (by default, Flask).
> +XSM_ENABLE          := @xsm@
> +FLASK_ENABLE        := @xsm@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index c5dec9c..5b2815d 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -6,6 +6,7 @@ AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh
../xen/Makefile]),
>      [xen-devel@lists.xensource.com])
>  AC_CONFIG_SRCDIR([libxl/libxl.c])
>  AC_CONFIG_FILES([../config/Tools.mk])
> +AC_CONFIG_FILES([../config/Xen.mk])
>  AC_CONFIG_HEADERS([config.h])
>  AC_PREFIX_DEFAULT([/usr])
>  AC_CONFIG_AUX_DIR([.])
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 6123835..6c17a3f 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -12,6 +12,7 @@ frame_pointer ?= n
>  lto           ?= n
>  
>  include $(XEN_ROOT)/Config.mk
> +include $(XEN_ROOT)/config/Xen.mk
>  
>  # Hardcoded configuration implications and dependencies.
>  # Do this is a neater way if it becomes unwieldy.

Roger Pau Monné

2012-Feb-29 11:03 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

2012/2/29 Daniel De Graaf <dgdegra@tycho.nsa.gov>:> Since the introduction of autoconf, builds with XSM enabled in .config
> have been broken unless FLASK_ENABLE was explicitly set. Since the
> setting in .config has apparently been deprecated in favor of an
> autoconf --enable-xsm, add config/Xen.mk to export this to Xen. This
> also makes --disable-debug and some paths to be pulled from the
> configure process in the hypervisor build.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
> Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
When we started the autoconf stuff we decided to make it a tools only
thing, that''s why configure.ac resides in tools/, if the hypervisor
starts using it too, we should move tools/configure.ac and it''s stuff
to /. Apart from that, I think the patch is ok, provided that the
following is applied after:

8<--------------------------------------------

autoconf: rebuild configure and check for config/Xen.mk

Rebuild configure after Daniel De Graaf patch. Check for
config/Xen.mk when building the hypervisor and delete config/Xen.mk
when doing a distclean.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 9e45c5b8b8f2 tools/configure
--- a/tools/configure	Wed Feb 22 06:38:22 2012 +0100
+++ b/tools/configure	Wed Feb 22 07:19:50 2012 +0100
@@ -2435,6 +2435,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu

 ac_config_files="$ac_config_files ../config/Tools.mk"

+ac_config_files="$ac_config_files ../config/Xen.mk"
+
 ac_config_headers="$ac_config_headers config.h"


@@ -9588,6 +9590,7 @@ for ac_config_target in $ac_config_targe
 do
   case $ac_config_target in
     "../config/Tools.mk") CONFIG_FILES="$CONFIG_FILES
../config/Tools.mk" ;;
+    "../config/Xen.mk") CONFIG_FILES="$CONFIG_FILES
../config/Xen.mk" ;;
     "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h"
;;

   *) as_fn_error $? "invalid argument: \`$ac_config_target''"
"$LINENO" 5 ;;
diff -r 9e45c5b8b8f2 xen/Makefile
--- a/xen/Makefile	Wed Feb 22 06:38:22 2012 +0100
+++ b/xen/Makefile	Wed Feb 22 07:19:50 2012 +0100
@@ -67,7 +67,7 @@ build install debug clean distclean csco

 .PHONY: _distclean
 _distclean: clean
-	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
+	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
../config/Xen.mk

 $(TARGET).gz: $(TARGET)
 	gzip -f -9 < $< > $@.new
diff -r 9e45c5b8b8f2 xen/Rules.mk
--- a/xen/Rules.mk	Wed Feb 22 06:38:22 2012 +0100
+++ b/xen/Rules.mk	Wed Feb 22 07:19:50 2012 +0100
@@ -179,4 +179,8 @@ SPECIAL_DATA_SECTIONS := rodata $(foreac
 %.s: %.S Makefile
 	$(CPP) $(AFLAGS) $< -o $@

+$(XEN_ROOT)/config/Xen.mk:
+	@echo "You have to run ./configure before building or installing the
hypervisor"
+	@exit 1
+

Ian Jackson

2012-Feb-29 11:44 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export configure
variables to hypervisor build"):> Perhaps we should just move the configure stuff up to the top level and
> agree that it can control both tools and hypervisor configuration
> options? I''m not sure why we would want to use different
mechanisms for
> the tools and h/v anyway.
I assume that the concern was that some people might object to the
involvement of autoconf in building the hypervisor.  But no-one seems
to be objecting very much.

If they do then the right thing is for configure to automatically
honour settings like FLASK_ENABLE, not to have two separate options
which cause the build to fail unless you set or clear both.

Ian.

Jan Beulich

2012-Feb-29 15:01 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

>>> On 29.02.12 at 12:44, Ian Jackson <Ian.Jackson@eu.citrix.com>
wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export
configure
> variables to hypervisor build"):
>> Perhaps we should just move the configure stuff up to the top level and
>> agree that it can control both tools and hypervisor configuration
>> options? I''m not sure why we would want to use different
mechanisms for
>> the tools and h/v anyway.
> 
> I assume that the concern was that some people might object to the
> involvement of autoconf in building the hypervisor.  But no-one seems
> to be objecting very much.
> 
> If they do then the right thing is for configure to automatically
> honour settings like FLASK_ENABLE, not to have two separate options
> which cause the build to fail unless you set or clear both.
Yes, please. (I realize that Keir applied the patch here already, but
I really consider it wrong to require a configure step before building
Xen, unless the configure step is exhaustive, i.e. covers everything
that can be controlled, and interactive, like for the Linux kernel. Nor
do I understand what stuff like {PRE,AP}PEND_{INCLUDES,LIB} is
needed for in config/Xen.mk. And finally, with .config being included
[almost] first thing in Config.mk, overriding its settings [like debug] in
config/Xen.mk seems wrong to me too. Or did I miss an announcement
of .config no longer being supported, in which I''d need a hint how to
replace certain settings I''ve been doing there so far? All in all,
Keir,
you may read this as a request to revert that patch.)

And then again, shouldn''t tools and hypervisor _build_ be
independent of one another, in that the set of options enabled in
one would still allow it to work with a different set of options
enabled in the other? Or if not, how is the option sets being in
sync getting enforced (i.e. if mismatched builds from the same c/s
got run by someone)?

Jan

Daniel De Graaf

2012-Feb-29 15:06 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

On 02/29/2012 06:44 AM, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export
configure variables to hypervisor build"):
>> Perhaps we should just move the configure stuff up to the top level and
>> agree that it can control both tools and hypervisor configuration
>> options? I''m not sure why we would want to use different
mechanisms for
>> the tools and h/v anyway.
> 
> I assume that the concern was that some people might object to the
> involvement of autoconf in building the hypervisor.  But no-one seems
> to be objecting very much.
> 
> If they do then the right thing is for configure to automatically
> honour settings like FLASK_ENABLE, not to have two separate options
> which cause the build to fail unless you set or clear both.
> 
> Ian.
> 
Actually, FLASK_ENABLE and XSM_ENABLE are not used in the tools build at all -
they are purely hypervisor build options. If a ./configure dependency
isn''t
wanted for the hypervisor build, reverting the removal of XSM_ENABLE from
Config.mk and eliminating the --enable-xsm option would also work.

-- 
Daniel De Graaf
National Security Agency

Keir Fraser

2012-Feb-29 15:09 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

On 29/02/2012 15:06, "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
wrote:
> On 02/29/2012 06:44 AM, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/5] build: Export
configure
>> variables to hypervisor build"):
>>> Perhaps we should just move the configure stuff up to the top level
and
>>> agree that it can control both tools and hypervisor configuration
>>> options? I''m not sure why we would want to use different
mechanisms for
>>> the tools and h/v anyway.
>> 
>> I assume that the concern was that some people might object to the
>> involvement of autoconf in building the hypervisor.  But no-one seems
>> to be objecting very much.
>> 
>> If they do then the right thing is for configure to automatically
>> honour settings like FLASK_ENABLE, not to have two separate options
>> which cause the build to fail unless you set or clear both.
>> 
>> Ian.
>> 
> 
> Actually, FLASK_ENABLE and XSM_ENABLE are not used in the tools build at
all -
> they are purely hypervisor build options. If a ./configure dependency
isn''t
> wanted for the hypervisor build, reverting the removal of XSM_ENABLE from
> Config.mk and eliminating the --enable-xsm option would also work.
I''ll revert the patch I just applied. Do you want to make another patch
for
this alternative solution?

 -- Keir

Jan Beulich

2012-Feb-29 15:11 UTC

head link

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

>>> On 29.02.12 at 16:01, "Jan Beulich"
<JBeulich@suse.com> wrote:
> Yes, please. (I realize that Keir applied the patch here already, but
> I really consider it wrong to require a configure step before building
> Xen, unless the configure step is exhaustive, i.e. covers everything
> that can be controlled, and interactive, like for the Linux kernel. Nor
Even more so for cross builds: On a 32-bit host, there is no point in
building 64-bit tools, yet building a 64-bit hypervisor is rather useful.
So the current situation iiuc would make it necessary that I run a
tools side configure first, and only then the hypervisor build.

Jan
> do I understand what stuff like {PRE,AP}PEND_{INCLUDES,LIB} is
> needed for in config/Xen.mk. And finally, with .config being included
> [almost] first thing in Config.mk, overriding its settings [like debug] in
> config/Xen.mk seems wrong to me too. Or did I miss an announcement
> of .config no longer being supported, in which I''d need a hint how
to
> replace certain settings I''ve been doing there so far? All in all,
Keir,
> you may read this as a request to revert that patch.)

Daniel De Graaf

2012-Feb-29 15:35 UTC

head link

[PATCH] build: remove hypervisor-only configuration from tools/configure

When adding autoconf support, the configuration options for XSM and
FLASK_ENABLE were incorrectly removed from Config.mk and added to the
tools configuration. Since these are hypervisor configuration options,
they should not depend on running tools configuration.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 Config.mk          |    4 ++++
 config/Tools.mk.in |    4 ----
 tools/configure.ac |    4 +---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Config.mk b/Config.mk
index bc6be65..97bc9be 100644
--- a/Config.mk
+++ b/Config.mk
@@ -175,6 +175,10 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+# Enable XSM security module (by default, Flask).
+XSM_ENABLE ?= n
+FLASK_ENABLE ?= $(XSM_ENABLE)
+
 XEN_EXTFILES_URL=http://xenbits.xensource.com/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 06d5e89..315ced4 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -24,10 +24,6 @@ PREPEND_LIB         := @PREPEND_LIB@
 APPEND_INCLUDES     := @APPEND_INCLUDES@
 APPEND_LIB          := @APPEND_LIB@
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE          := @xsm@
-FLASK_ENABLE        := @xsm@
-
 # Download GIT repositories via HTTP or GIT''s own protocol?
 # GIT''s protocol is faster and more robust, when it works at all
(firewalls
 # may block it). We make it the default, but if your GIT repository downloads
diff --git a/tools/configure.ac b/tools/configure.ac
index c5dec9c..b8f69e6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -36,8 +36,6 @@ m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
 
 # Enable/disable options
-AX_ARG_ENABLE_AND_EXPORT([xsm],
-    [Enable XSM security module (by default, Flask)])
 AX_ARG_ENABLE_AND_EXPORT([githttp], [Download GIT repositories via HTTP])
 AX_ARG_DISABLE_AND_EXPORT([monitors],
     [Disable xenstat and xentop monitoring tools])
@@ -47,7 +45,7 @@ AX_ARG_DISABLE_AND_EXPORT([pythontools], [Disable Python
tools])
 AX_ARG_DISABLE_AND_EXPORT([ocamltools], [Disable Ocaml tools])
 AX_ARG_ENABLE_AND_EXPORT([miniterm], [Enable miniterm])
 AX_ARG_ENABLE_AND_EXPORT([lomount], [Enable lomount])
-AX_ARG_DISABLE_AND_EXPORT([debug], [Disable debug build of Xen and tools])
+AX_ARG_DISABLE_AND_EXPORT([debug], [Disable debug build of tools])
 
 AC_ARG_VAR([PREPEND_INCLUDES],
     [List of include folders to prepend to CFLAGS (without -I)])
-- 
1.7.7.6

Ian Jackson

2012-Mar-01 15:31 UTC

head link

Re: [PATCH] build: remove hypervisor-only configuration from tools/configure

Daniel De Graaf writes ("[Xen-devel] [PATCH] build: remove hypervisor-only
configuration from tools/configure"):> When adding autoconf support, the configuration options for XSM and
> FLASK_ENABLE were incorrectly removed from Config.mk and added to the
> tools configuration. Since these are hypervisor configuration options,
> they should not depend on running tools configuration.
Thanks.  I have applied this.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Xen devel - Feb 2012 - [PATCH 1/5] build: Export configure variables to hypervisor build

[PATCH 1/5] build: Export configure variables to hypervisor build

[PATCH 2/5] xsm: label xen-consumer event channels

[PATCH 3/5] xsm/flask: clean interdomain event channel hook

[PATCH 4/5] xsm/flask: buffer AVC messages for output

[PATCH 5/5] xsm: expose context of event channel peers

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

Re: [PATCH 1/5] build: Export configure variables to hypervisor build

[PATCH] build: remove hypervisor-only configuration from tools/configure

Re: [PATCH] build: remove hypervisor-only configuration from tools/configure