* [PATCH 2/5] xsm: label xen-consumer event channels
2012-02-28 23:27 [PATCH 1/5] build: Export configure variables to hypervisor build Daniel De Graaf
@ 2012-02-28 23:27 ` Daniel De Graaf
2012-02-28 23:27 ` [PATCH 3/5] xsm/flask: clean interdomain event channel hook Daniel De Graaf
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Daniel De Graaf @ 2012-02-28 23:27 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf, keir
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 3/5] xsm/flask: clean interdomain event channel hook
2012-02-28 23:27 [PATCH 1/5] build: Export configure variables to hypervisor build Daniel De Graaf
2012-02-28 23:27 ` [PATCH 2/5] xsm: label xen-consumer event channels Daniel De Graaf
@ 2012-02-28 23:27 ` Daniel De Graaf
2012-02-28 23:27 ` [PATCH 4/5] xsm/flask: buffer AVC messages for output Daniel De Graaf
` (3 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Daniel De Graaf @ 2012-02-28 23:27 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf, keir
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 4/5] xsm/flask: buffer AVC messages for output
2012-02-28 23:27 [PATCH 1/5] build: Export configure variables to hypervisor build Daniel De Graaf
2012-02-28 23:27 ` [PATCH 2/5] xsm: label xen-consumer event channels Daniel De Graaf
2012-02-28 23:27 ` [PATCH 3/5] xsm/flask: clean interdomain event channel hook Daniel De Graaf
@ 2012-02-28 23:27 ` Daniel De Graaf
2012-02-28 23:27 ` [PATCH 5/5] xsm: expose context of event channel peers Daniel De Graaf
` (2 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Daniel De Graaf @ 2012-02-28 23:27 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf, keir
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 5/5] xsm: expose context of event channel peers
2012-02-28 23:27 [PATCH 1/5] build: Export configure variables to hypervisor build Daniel De Graaf
` (2 preceding siblings ...)
2012-02-28 23:27 ` [PATCH 4/5] xsm/flask: buffer AVC messages for output Daniel De Graaf
@ 2012-02-28 23:27 ` Daniel De Graaf
2012-02-29 11:00 ` [PATCH 1/5] build: Export configure variables to hypervisor build Ian Campbell
2012-02-29 11:03 ` [PATCH 1/5] build: Export configure variables to hypervisor build Roger Pau Monné
5 siblings, 0 replies; 14+ messages in thread
From: Daniel De Graaf @ 2012-02-28 23:27 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf, keir
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-28 23:27 [PATCH 1/5] build: Export configure variables to hypervisor build Daniel De Graaf
` (3 preceding siblings ...)
2012-02-28 23:27 ` [PATCH 5/5] xsm: expose context of event channel peers Daniel De Graaf
@ 2012-02-29 11:00 ` Ian Campbell
2012-02-29 11:44 ` Ian Jackson
2012-02-29 11:03 ` [PATCH 1/5] build: Export configure variables to hypervisor build Roger Pau Monné
5 siblings, 1 reply; 14+ messages in thread
From: Ian Campbell @ 2012-02-29 11:00 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Roger Pau Monne, Keir (Xen.org), Ian Jackson, Jan Beulich,
xen-devel@lists.xen.org
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-29 11:00 ` [PATCH 1/5] build: Export configure variables to hypervisor build Ian Campbell
@ 2012-02-29 11:44 ` Ian Jackson
2012-02-29 15:01 ` Jan Beulich
2012-02-29 15:06 ` Daniel De Graaf
0 siblings, 2 replies; 14+ messages in thread
From: Ian Jackson @ 2012-02-29 11:44 UTC (permalink / raw)
To: Ian Campbell
Cc: Roger Pau Monne, Daniel De Graaf, Keir (Xen.org), Jan Beulich,
xen-devel@lists.xen.org
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-29 11:44 ` Ian Jackson
@ 2012-02-29 15:01 ` Jan Beulich
2012-02-29 15:11 ` Jan Beulich
2012-02-29 15:06 ` Daniel De Graaf
1 sibling, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2012-02-29 15:01 UTC (permalink / raw)
To: Ian Campbell, Ian Jackson, Keir Fraser
Cc: Roger Pau Monne, Daniel De Graaf, xen-devel@lists.xen.org
>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-29 15:01 ` Jan Beulich
@ 2012-02-29 15:11 ` Jan Beulich
0 siblings, 0 replies; 14+ messages in thread
From: Jan Beulich @ 2012-02-29 15:11 UTC (permalink / raw)
To: Ian Campbell, Ian Jackson, Keir Fraser
Cc: Roger Pau Monne, Daniel De Graaf, xen-devel@lists.xen.org
>>> 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.)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-29 11:44 ` Ian Jackson
2012-02-29 15:01 ` Jan Beulich
@ 2012-02-29 15:06 ` Daniel De Graaf
2012-02-29 15:09 ` Keir Fraser
1 sibling, 1 reply; 14+ messages in thread
From: Daniel De Graaf @ 2012-02-29 15:06 UTC (permalink / raw)
To: Ian Jackson
Cc: Roger Pau Monne, Keir (Xen.org), Ian Campbell, Jan Beulich,
xen-devel@lists.xen.org
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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-29 15:06 ` Daniel De Graaf
@ 2012-02-29 15:09 ` Keir Fraser
2012-02-29 15:35 ` [PATCH] build: remove hypervisor-only configuration from tools/configure Daniel De Graaf
0 siblings, 1 reply; 14+ messages in thread
From: Keir Fraser @ 2012-02-29 15:09 UTC (permalink / raw)
To: Daniel De Graaf, Ian Jackson
Cc: Roger Pau Monne, Keir (Xen.org), Ian Campbell, Jan Beulich,
xen-devel@lists.xen.org
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH] build: remove hypervisor-only configuration from tools/configure
2012-02-29 15:09 ` Keir Fraser
@ 2012-02-29 15:35 ` Daniel De Graaf
2012-03-01 15:31 ` Ian Jackson
0 siblings, 1 reply; 14+ messages in thread
From: Daniel De Graaf @ 2012-02-29 15:35 UTC (permalink / raw)
To: keir
Cc: Ian Campbell, Ian Jackson, xen-devel, Roger Pau Monne,
Jan Beulich, Daniel De Graaf
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH] build: remove hypervisor-only configuration from tools/configure
2012-02-29 15:35 ` [PATCH] build: remove hypervisor-only configuration from tools/configure Daniel De Graaf
@ 2012-03-01 15:31 ` Ian Jackson
0 siblings, 0 replies; 14+ messages in thread
From: Ian Jackson @ 2012-03-01 15:31 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Roger Pau Monne, keir, Ian Campbell, Jan Beulich, xen-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/5] build: Export configure variables to hypervisor build
2012-02-28 23:27 [PATCH 1/5] build: Export configure variables to hypervisor build Daniel De Graaf
` (4 preceding siblings ...)
2012-02-29 11:00 ` [PATCH 1/5] build: Export configure variables to hypervisor build Ian Campbell
@ 2012-02-29 11:03 ` Roger Pau Monné
5 siblings, 0 replies; 14+ messages in thread
From: Roger Pau Monné @ 2012-02-29 11:03 UTC (permalink / raw)
To: Daniel De Graaf; +Cc: keir, Ian Jackson, xen-devel
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
+
^ permalink raw reply [flat|nested] 14+ messages in thread