Nabble - Xen - Security - Dev

How to check for open ports in domU from Dom0

2009-09-13T01:49:12Z

Are there any tools available which enables me to check from dom0 if domU has a particular port open

Thanks

Advantage of using Intel's Trusted Execution Technology

2009-02-12T17:52:42Z

can somebody explain to me in layman's terms:
if i use Xen with Intel's TXT, what advantage will it bring?
is it: 1) the hardware brings extra protection to the isolation between the different guest OS or
2) the hardware ensures in some way the guest OS is isolated from the host OS.
3) or simply TXT makes Xen run faster..?

Re: Managing DomU as non root

2009-02-02T06:43:28Z

PROBLEM SOLVED

I just added apache/or any other user to the sudoers then added the sudo command in front of my cgi script. This seems to have tricked the xend, so there's no need to have the xm command used as root.

It may not be the safest solution but it works.

Thanks,

atatut wrote:

Hi,

OS: Gentoo linux-2.6.26-gentoo-r4
Xen: linux-2.6.18-xen-r12

I'm trying to use cgi shell scripts to allow different untrusted users to manage their own DomU without having root privileges.

The cgi shell script works, but of course whenever I try to run it from the web page I made, I receive the following message inside the apache/error.log:

Traceback (most recent call last):
File "/usr/sbin/xm", line 8, in <module>
from xen.xm import main
File "usr/lib64/python2.5/site-packages/xen/xm/main.py", line 61, in <module>
xen.lowlevel.xc.Error: (1, 'Internal error', 'Could not obtain handle on privileged command interface (13 = Permission denied)')

This, of course, means I have no privilege to use the "xm" command using that specific user. I will have to do it through root, but I cannot add unable users to the root group, which is anyway not enough to allow xm to run, nor have apache running with root.

Is there a way to achieve this in a secure fashion? Here's what I'd like to achieve:

- create one DomU for each of my colleagues
- create one local user for each colleague on the dom0
- create a vhost inside apache using the specific local user for each different vhost
- allow only the specific user to execute cgi script "Restart/Stop/Start or whatever" for his specific domU

But the so-called security limitation of xen, preventing me to allow some other user but root to use the "xm" command is right now forcing me to adopt an unsecure schema by running apache with the root account which is suicidal. Sudo is not an option I think as xen wants specifically root to run the commands, if not mistaken.

Could someone help me clearing this out, I'm pretty sure I'm not the first to try that, but I couldn't find anything close to a solution googling.

Thanks folks!

Managing DomU as non root

2009-02-02T05:58:50Z

Hi,

OS: Gentoo linux-2.6.26-gentoo-r4
Xen: linux-2.6.18-xen-r12

I'm trying to use cgi shell scripts to allow different untrusted users to manage their own DomU without having root privileges.

The cgi shell script works, but of course whenever I try to run it from the web page I made, I receive the following message inside the apache/error.log:

Traceback (most recent call last):
File "/usr/sbin/xm", line 8, in <module>
from xen.xm import main
File "usr/lib64/python2.5/site-packages/xen/xm/main.py", line 61, in <module>
xen.lowlevel.xc.Error: (1, 'Internal error', 'Could not obtain handle on privileged command interface (13 = Permission denied)')

This, of course, means I have no privilege to use the "xm" command using that specific user. I will have to do it through root, but I cannot add unable users to the root group, which is anyway not enough to allow xm to run, nor have apache running with root.

Is there a way to achieve this in a secure fashion? Here's what I'd like to achieve:

- create one DomU for each of my colleagues
- create one local user for each colleague on the dom0
- create a vhost inside apache using the specific local user for each different vhost
- allow only the specific user to execute cgi script "Restart/Stop/Start or whatever" for his specific domU

But the so-called security limitation of xen, preventing me to allow some other user but root to use the "xm" command is right now forcing me to adopt an unsecure schema by running apache with the root account which is suicidal. Sudo is not an option I think as xen wants specifically root to run the commands, if not mistaken.

Could someone help me clearing this out, I'm pretty sure I'm not the first to try that, but I couldn't find anything close to a solution googling.

Thanks folks!

RE: [PATCH v2] txt: 0/5 - Overview

2009-01-29T07:04:49Z

> From: Ross Philipson [mailto:Ross.Philipson@...]
> Sent: Thursday, January 29, 2009 5:58 AM
>
> Joe,
>
> So if I read this correctly, the current tboot.hg repo on bughost does not have the new
> patches and therefore will work with older versions on xen (without your latest patches),
> correct? Are you going to be putting the patches in the main tboot repo or are you going to
> branch it - how will you make tboot available for both cases?
>
> Thanks
> Ross

I will create a new tarball today for the latest pre-change tboot code and then I will check in the changes once the corresponding Xen changes are accepted. The next set of Linux patches will also be based on the new tboot code.

To the best of my knowledge, the only commercial distro with a Xen version >=3.2 is SLES10SP2 and SLES11 and so I'm not intending to support the earlier versions of tboot. Also, the Xen changes are not that large and are mostly independent of anything in Xen that changed since 3.2, so it should not be hard to backport them is there is interest.

Joe

> -----Original Message-----
> From: xen-devel-bounces@... [mailto:xen-devel-bounces@...] On
> Behalf Of Cihula, Joseph
> Sent: Thursday, January 29, 2009 3:55 AM
> To: 'xen-devel@...'; xense-devel@...
> Cc: Wang, Shane; Keir Fraser
> Subject: [Xen-devel] [PATCH v2] txt: 0/5 - Overview
>
> This patch series are changes to Xen to support new functionality, and a changed API, in the
> tboot project (see http://sourceforge.net/projects/tboot for more info about tboot). Some of
> these changes originated from comments received when the first set of Linux tboot/Intel(r) TXT
> patches were posted to LKML.
>
> Attached to this patch is a single patch to be applied to the current tip of the tboot source
> tree (located at http://www.bughost.org/repos.hg/tboot.hg). Due to the API change, for those
> who wish to test the patches, it would be best to apply all of the tboot patch at once and
> test with all of the Xen patches applied to Xen.
>
> Since the API changes are not backwards compatible, the resulting tboot will not work with a
> Xen that does not have the patches applied. Likewise, a Xen with these patches applied will
> not work with the un-patched tboot. To keep backward compatibility would have left the
> interface and code fairly ugly and didn't seem worth the trouble.
>
> The Xen patches are as follows:
>
> xen-txt-01-unified_shutdown_entry.patch - single tboot entry point for shutdown
> xen-txt-02c-acpi_gas_support.patch - ACPI Generic Address Structure for tboot shutdown
> xen-txt-03c-protect_txt_ranges.patch - explicitly protect TXT addr ranges from dom0
> xen-txt-04c-hypervisor_s3_integrity.patch - hypervisor integrity on S3
> xen-txt-05b-use_protected_dmar.patch - use TXT's DMA-protected DMAR table to setup VT-d
>
> We are currently working on a patch that will extend the S3 integrity to domains, as
> configurable via a domain's config file (and always for dom0).
>
> The patches apply cleanly to the latest xen-unstable (c/s 19104:31983c30c460).
>
> Joe and Shane

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

[PATCH v2] txt: 5/5 - use TXT's DMA-protected DMAR table to setup VT-d

2009-01-29T00:56:05Z

The VT-d DMAR ACPI tables may not be DMA protected by tboot. However, SINIT saves a copy of them in the SinitMleData struct in the TXT heap (which is DMA protected). So we should read the DMAR table from that copy if launched by tboot.

Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r 28d9dd8e3a81 -r e9325545f67c xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Wed Jan 28 18:23:38 2009 -0800
+++ b/xen/arch/x86/tboot.c Wed Jan 28 18:42:51 2009 -0800
@@ -20,6 +20,10 @@ static const uuid_t tboot_shared_uuid =

extern char __init_begin[], __per_cpu_start[], __per_cpu_end[], __bss_start[];

+/* used by tboot_protect_mem_regions() and/or tboot_parse_dmar_table() */
+static uint64_t txt_heap_base, txt_heap_size;
+static uint64_t sinit_base, sinit_size;
+
/*
* TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
*/
@@ -37,10 +41,33 @@ extern char __init_begin[], __per_cpu_st
#define TXTCR_HEAP_BASE 0x0300
#define TXTCR_HEAP_SIZE 0x0308

+#define SHA1_SIZE 20
+typedef uint8_t sha1_hash_t[SHA1_SIZE];
+
+typedef struct __packed {
+ uint32_t version; /* currently 6 */
+ sha1_hash_t bios_acm_id;
+ uint32_t edx_senter_flags;
+ uint64_t mseg_valid;
+ sha1_hash_t sinit_hash;
+ sha1_hash_t mle_hash;
+ sha1_hash_t stm_hash;
+ sha1_hash_t lcp_policy_hash;
+ uint32_t lcp_policy_control;
+ uint32_t rlp_wakeup_addr;
+ uint32_t reserved;
+ uint32_t num_mdrs;
+ uint32_t mdrs_off;
+ uint32_t num_vtd_dmars;
+ uint32_t vtd_dmars_off;
+} sinit_mle_data_t;
+
void __init tboot_probe(void)
{
tboot_shared_t *tboot_shared;
unsigned long p_tboot_shared;
+ uint32_t map_base, map_size;
+ unsigned long map_addr;

/* Look for valid page-aligned address for shared page. */
p_tboot_shared = simple_strtoul(opt_tboot, NULL, 0);
@@ -68,6 +95,30 @@ void __init tboot_probe(void)
printk(" shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
printk(" tboot_base: 0x%08x\n", tboot_shared->tboot_base);
printk(" tboot_size: 0x%x\n", tboot_shared->tboot_size);
+
+ /* these will be needed by tboot_protect_mem_regions() and/or
+ tboot_parse_dmar_table(), so get them now */
+
+ map_base = PFN_DOWN(TXT_PUB_CONFIG_REGS_BASE);
+ map_size = PFN_UP(NR_TXT_CONFIG_PAGES * PAGE_SIZE);
+ map_addr = (unsigned long)__va(map_base << PAGE_SHIFT);
+ if ( map_pages_to_xen(map_addr, map_base, map_size, __PAGE_HYPERVISOR) )
+ return;
+
+ /* TXT Heap */
+ txt_heap_base =
+ *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_BASE);
+ txt_heap_size =
+ *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_SIZE);
+
+ /* SINIT */
+ sinit_base =
+ *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
+ sinit_size =
+ *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
+
+ destroy_xen_mappings((unsigned long)__va(map_base << PAGE_SHIFT),
+ (unsigned long)__va((map_base + map_size) << PAGE_SHIFT));
}

void tboot_shutdown(uint32_t shutdown_type)
@@ -125,29 +176,18 @@ int tboot_in_measured_env(void)

int tboot_protect_mem_regions(void)
{
- uint64_t base, size;
- uint32_t map_base, map_size;
- unsigned long map_addr;
-
if ( !tboot_in_measured_env() )
return 1;

- map_base = PFN_DOWN(TXT_PUB_CONFIG_REGS_BASE);
- map_size = PFN_UP(NR_TXT_CONFIG_PAGES * PAGE_SIZE);
- map_addr = (unsigned long)__va(map_base << PAGE_SHIFT);
- if ( map_pages_to_xen(map_addr, map_base, map_size, __PAGE_HYPERVISOR) )
- return 0;
-
/* TXT Heap */
- base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_BASE);
- size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_SIZE);
- if ( !reserve_e820_unusable(&e820, base, base + size) )
+ if ( txt_heap_base == 0 ||
+ !reserve_e820_unusable(&e820, txt_heap_base,
+ txt_heap_base + txt_heap_size) )
return 0;

/* SINIT */
- base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
- size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
- if ( !reserve_e820_unusable(&e820, base, base + size) )
+ if ( sinit_base == 0 ||
+ !reserve_e820_unusable(&e820, sinit_base, sinit_base + sinit_size) )
return 0;

/* TXT Private Space */
@@ -155,10 +195,60 @@ int tboot_protect_mem_regions(void)
TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE) )
return 0;

+ return 1;
+}
+
+int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler)
+{
+ uint32_t map_base, map_size;
+ unsigned long map_vaddr;
+ void *heap_ptr;
+ struct acpi_table_header *dmar_table;
+ int rc;
+
+ if ( !tboot_in_measured_env() )
+ return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);
+
+ /* ACPI tables may not be DMA protected by tboot, so use DMAR copy */
+ /* SINIT saved in SinitMleData in TXT heap (which is DMA protected) */
+
+ if ( txt_heap_base == 0 )
+ return 1;
+
+ /* map TXT heap into Xen addr space */
+ map_base = PFN_DOWN(txt_heap_base);
+ map_size = PFN_UP(txt_heap_size);
+ map_vaddr = (unsigned long)__va(map_base << PAGE_SHIFT);
+ if ( map_pages_to_xen(map_vaddr, map_base, map_size, __PAGE_HYPERVISOR) )
+ return 1;
+
+ /* walk heap to SinitMleData */
+ heap_ptr = __va(txt_heap_base);
+ /* skip BiosData */
+ heap_ptr += *(uint64_t *)heap_ptr;
+ /* skip OsMleData */
+ heap_ptr += *(uint64_t *)heap_ptr;
+ /* skip OsSinitData */
+ heap_ptr += *(uint64_t *)heap_ptr;
+ /* now points to SinitMleDataSize; set to SinitMleData */
+ heap_ptr += sizeof(uint64_t);
+ /* get addr of DMAR table */
+ dmar_table = (struct acpi_table_header *)(heap_ptr +
+ ((sinit_mle_data_t *)heap_ptr)->vtd_dmars_off - sizeof(uint64_t));
+
+ rc = dmar_handler(dmar_table);
+
destroy_xen_mappings((unsigned long)__va(map_base << PAGE_SHIFT),
(unsigned long)__va((map_base + map_size) << PAGE_SHIFT));

- return 1;
+ /* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
+ /* but dom0 will read real table, so must zap it there too */
+ dmar_table = NULL;
+ acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_table);
+ if ( dmar_table != NULL )
+ ((struct acpi_table_dmar *)dmar_table)->header.signature[0] = '\0';
+
+ return rc;
}

/*
diff -r 28d9dd8e3a81 -r e9325545f67c xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Wed Jan 28 18:23:38 2009 -0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Wed Jan 28 18:42:51 2009 -0800
@@ -28,6 +28,7 @@
#include <xen/pci.h>
#include <xen/pci_regs.h>
#include <asm/string.h>
+#include <asm/tboot.h>
#include "dmar.h"
#include "iommu.h"

@@ -519,7 +520,9 @@ int acpi_dmar_init(void)
if ( !iommu_enabled )
goto fail;

- rc = acpi_table_parse(ACPI_SIG_DMAR, acpi_parse_dmar);
+ /* ACPI tables may not be DMA protected by tboot, so use DMAR copy */
+ /* SINIT saved in SinitMleData in TXT heap (which is DMA protected) */
+ rc = tboot_parse_dmar_table(acpi_parse_dmar);
if ( rc )
goto fail;

diff -r 28d9dd8e3a81 -r e9325545f67c xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Wed Jan 28 18:23:38 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Wed Jan 28 18:42:51 2009 -0800
@@ -36,6 +36,8 @@

#ifndef __TBOOT_H__
#define __TBOOT_H__
+
+#include <xen/acpi.h>

#ifndef __packed
#define __packed __attribute__ ((packed))
@@ -110,6 +112,7 @@ void tboot_shutdown(uint32_t shutdown_ty
void tboot_shutdown(uint32_t shutdown_type);
int tboot_in_measured_env(void);
int tboot_protect_mem_regions(void);
+int tboot_parse_dmar_table(acpi_table_handler dmar_handler);

#endif /* __TBOOT_H__ */

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-05b-use_protected_dmar.patch (10K) Download Attachment

[PATCH v2] txt: 4/5 - hypervisor integrity on S3

2009-01-29T00:55:48Z

When launched from tboot, utilise tboot interface to provide integrity protection to the hypervisor during S3

Signed-off-by: Joseph Cihula <joseph.cihula@...>
ACKed-by: Shane Wang <shane.wang@...>

diff -r 196ed4d1e316 -r 664c5cd3827b xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Wed Jan 28 22:12:49 2009 -0800
+++ b/xen/arch/x86/tboot.c Wed Jan 28 22:32:25 2009 -0800
@@ -17,6 +17,8 @@ tboot_shared_t *g_tboot_shared;
tboot_shared_t *g_tboot_shared;

static const uuid_t tboot_shared_uuid = TBOOT_SHARED_UUID;
+
+extern char __init_begin[], __per_cpu_start[], __per_cpu_end[], __bss_start[];

/*
* TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
@@ -76,6 +78,25 @@ void tboot_shutdown(uint32_t shutdown_ty
g_tboot_shared->shutdown_type = shutdown_type;

local_irq_disable();
+
+ /* if this is S3 then set regions to MAC */
+ if ( shutdown_type == TB_SHUTDOWN_S3 ) {
+ g_tboot_shared->num_mac_regions = 4;
+ /* S3 resume code (and other real mode trampoline code) */
+ g_tboot_shared->mac_regions[0].start =
+ (uint64_t)bootsym_phys(trampoline_start);
+ g_tboot_shared->mac_regions[0].end =
+ (uint64_t)bootsym_phys(trampoline_end);
+ /* hypervisor code + data */
+ g_tboot_shared->mac_regions[1].start = (uint64_t)__pa(&_stext);
+ g_tboot_shared->mac_regions[1].end = (uint64_t)__pa(&__init_begin);
+ /* per-cpu data */
+ g_tboot_shared->mac_regions[2].start = (uint64_t)__pa(&__per_cpu_start);
+ g_tboot_shared->mac_regions[2].end = (uint64_t)__pa(&__per_cpu_end);
+ /* bss */
+ g_tboot_shared->mac_regions[3].start = (uint64_t)__pa(&__bss_start);
+ g_tboot_shared->mac_regions[3].end = (uint64_t)__pa(&_end);
+ }

/* Create identity map for tboot shutdown code. */
map_base = PFN_DOWN(g_tboot_shared->tboot_base);
diff -r 196ed4d1e316 -r 664c5cd3827b xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Wed Jan 28 22:12:49 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Wed Jan 28 22:32:25 2009 -0800
@@ -51,6 +51,12 @@ typedef struct __packed {

/* used to communicate between tboot and the launched kernel (i.e. Xen) */

+#define MAX_TB_MAC_REGIONS 32
+typedef struct __packed {
+ uint64_t start;
+ uint64_t end;
+} tboot_mac_region_t;
+
/* GAS - Generic Address Structure (ACPI 2.0+) */
typedef struct __packed {
uint8_t space_id;
@@ -83,6 +89,9 @@ typedef struct __packed {
acpi_sinfo; /* where kernel put acpi sleep info in Sx */
uint32_t tboot_base; /* starting addr for tboot */
uint32_t tboot_size; /* size of tboot */
+ uint8_t num_mac_regions; /* number mem regions to MAC on S3 */
+ /* contig regions memory to MAC on S3 */
+ tboot_mac_region_t mac_regions[MAX_TB_MAC_REGIONS];
} tboot_shared_t;

#define TB_SHUTDOWN_REBOOT 0

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-04c-hypervisor_s3_integrity.patch (4K) Download Attachment

[PATCH v2] txt: 3/5 - explicitly protect TXT addr ranges from dom0

2009-01-29T00:55:32Z

tboot no longer marks the TXT heap/SINIT/private config space as E820_UNUSABLE in the e820 table, so Xen must explicitly disallow those regions from dom0.

Signed-off-by: Shane Wang <shane.wang@...>
Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r 9ba8aecc3a15 -r 196ed4d1e316 xen/arch/x86/e820.c
--- a/xen/arch/x86/e820.c Wed Jan 28 22:09:02 2009 -0800
+++ b/xen/arch/x86/e820.c Wed Jan 28 22:12:49 2009 -0800
@@ -391,11 +391,14 @@ static void __init machine_specific_memo
reserve_dmi_region();
}

-/* Reserve RAM area (@s,@e) in the specified e820 map. */
-int __init reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e)
+static int reserve_e820(struct e820map *e820, uint64_t s, uint64_t e,
+ uint32_t orig_type, uint32_t new_type)
{
uint64_t rs = 0, re = 0;
- int i;
+ int i, remove;
+
+ /* if reserving region, can delete instead */
+ remove = (new_type == E820_RESERVED);

for ( i = 0; i < e820->nr_map; i++ )
{
@@ -406,37 +409,89 @@ int __init reserve_e820_ram(struct e820m
break;
}

- if ( (i == e820->nr_map) || (e820->map[i].type != E820_RAM) )
+ if ( (i == e820->nr_map) || (e820->map[i].type != orig_type) )
return 0;

if ( (s == rs) && (e == re) )
{
/* Complete excision. */
- memmove(&e820->map[i], &e820->map[i+1],
- (e820->nr_map-i-1) * sizeof(e820->map[0]));
- e820->nr_map--;
+ if ( remove )
+ {
+ memmove(&e820->map[i], &e820->map[i+1],
+ (e820->nr_map-i-1) * sizeof(e820->map[0]));
+ e820->nr_map--;
+ }
+ else
+ e820->map[i].type = new_type;
}
else if ( s == rs )
{
- /* Truncate start. */
+ /* Truncate start or split. */
+ if ( !remove )
+ {
+ /* split */
+ if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )
+ {
+ printk("e820 overflow\n");
+ return 0;
+ }
+ memmove(&e820->map[i+1], &e820->map[i],
+ (e820->nr_map-i) * sizeof(e820->map[0]));
+ e820->nr_map++;
+ e820->map[i].addr = s;
+ e820->map[i].size = e - s;
+ e820->map[i].type = new_type;
+ i++;
+ }
e820->map[i].addr += e - s;
e820->map[i].size -= e - s;
}
else if ( e == re )
{
- /* Truncate end. */
+ /* Truncate end or split. */
+ if ( !remove )
+ {
+ if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )
+ {
+ printk("e820 overflow\n");
+ return 0;
+ }
+ memmove(&e820->map[i+1], &e820->map[i],
+ (e820->nr_map-i) * sizeof(e820->map[0]));
+ e820->nr_map++;
+ e820->map[i+1].addr = s;
+ e820->map[i+1].size = e - s;
+ e820->map[i+1].type = new_type;
+ }
e820->map[i].size -= e - s;
}
- else if ( e820->nr_map < ARRAY_SIZE(e820->map) )
+ else if ( e820->nr_map+1 < ARRAY_SIZE(e820->map) )
{
- /* Split in two. */
- memmove(&e820->map[i+1], &e820->map[i],
- (e820->nr_map-i) * sizeof(e820->map[0]));
- e820->nr_map++;
- e820->map[i].size = s - rs;
- i++;
- e820->map[i].addr = e;
- e820->map[i].size = re - e;
+ /* Split in two or three. */
+ if ( !remove )
+ {
+ memmove(&e820->map[i+2], &e820->map[i],
+ (e820->nr_map-i) * sizeof(e820->map[0]));
+ e820->nr_map += 2;
+ e820->map[i].size = s - rs;
+ i++;
+ e820->map[i].addr = s;
+ e820->map[i].size = e - s;
+ e820->map[i].type = new_type;
+ i++;
+ e820->map[i].addr = e;
+ e820->map[i].size = re - e;
+ }
+ else
+ {
+ memmove(&e820->map[i+1], &e820->map[i],
+ (e820->nr_map-i) * sizeof(e820->map[0]));
+ e820->nr_map++;
+ e820->map[i].size = s - rs;
+ i++;
+ e820->map[i].addr = e;
+ e820->map[i].size = re - e;
+ }
}
else
{
@@ -457,6 +512,18 @@ int __init reserve_e820_ram(struct e820m
return 1;
}

+/* Set E820_RAM area (@s,@e) as RESERVED (or delete) in specified e820 map. */
+int __init reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e)
+{
+ return reserve_e820(e820, s, e, E820_RAM, E820_RESERVED);
+}
+
+/* Set E820_RESERVED area (@s, @e) as UNUSABLE in specified e820 map. */
+int reserve_e820_unusable(struct e820map *e820, uint64_t s, uint64_t e)
+{
+ return reserve_e820(e820, s, e, E820_RESERVED, E820_UNUSABLE);
+}
+
unsigned long __init init_e820(
const char *str, struct e820entry *raw, int *raw_nr)
{
diff -r 9ba8aecc3a15 -r 196ed4d1e316 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c Wed Jan 28 22:09:02 2009 -0800
+++ b/xen/arch/x86/setup.c Wed Jan 28 22:12:49 2009 -0800
@@ -1033,6 +1033,9 @@ void __init __start_xen(unsigned long mb
if ( xen_cpuidle )
xen_processor_pmbits |= XEN_PROCESSOR_PM_CX;

+ if ( !tboot_protect_mem_regions() )
+ panic("Could not protect TXT memory regions\n");
+
/*
* We're going to setup domain0 using the module(s) that we stashed safely
* above our heap. The second module, if present, is an initrd ramdisk.
diff -r 9ba8aecc3a15 -r 196ed4d1e316 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Wed Jan 28 22:09:02 2009 -0800
+++ b/xen/arch/x86/tboot.c Wed Jan 28 22:12:49 2009 -0800
@@ -6,6 +6,7 @@
#include <asm/fixmap.h>
#include <asm/page.h>
#include <asm/processor.h>
+#include <asm/e820.h>
#include <asm/tboot.h>

/* tboot=<physical address of shared page> */
@@ -16,6 +17,23 @@ tboot_shared_t *g_tboot_shared;
tboot_shared_t *g_tboot_shared;

static const uuid_t tboot_shared_uuid = TBOOT_SHARED_UUID;
+
+/*
+ * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
+ */
+
+#define TXT_PUB_CONFIG_REGS_BASE 0xfed30000
+#define TXT_PRIV_CONFIG_REGS_BASE 0xfed20000
+
+/* # pages for each config regs space - used by fixmap */
+#define NR_TXT_CONFIG_PAGES ((TXT_PUB_CONFIG_REGS_BASE - \
+ TXT_PRIV_CONFIG_REGS_BASE) >> PAGE_SHIFT)
+
+/* offsets from pub/priv config space */
+#define TXTCR_SINIT_BASE 0x0270
+#define TXTCR_SINIT_SIZE 0x0278
+#define TXTCR_HEAP_BASE 0x0300
+#define TXTCR_HEAP_SIZE 0x0308

void __init tboot_probe(void)
{
@@ -84,6 +102,44 @@ int tboot_in_measured_env(void)
return (g_tboot_shared != NULL);
}

+int tboot_protect_mem_regions(void)
+{
+ uint64_t base, size;
+ uint32_t map_base, map_size;
+ unsigned long map_addr;
+
+ if ( !tboot_in_measured_env() )
+ return 1;
+
+ map_base = PFN_DOWN(TXT_PUB_CONFIG_REGS_BASE);
+ map_size = PFN_UP(NR_TXT_CONFIG_PAGES * PAGE_SIZE);
+ map_addr = (unsigned long)__va(map_base << PAGE_SHIFT);
+ if ( map_pages_to_xen(map_addr, map_base, map_size, __PAGE_HYPERVISOR) )
+ return 0;
+
+ /* TXT Heap */
+ base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_BASE);
+ size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_SIZE);
+ if ( !reserve_e820_unusable(&e820, base, base + size) )
+ return 0;
+
+ /* SINIT */
+ base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
+ size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
+ if ( !reserve_e820_unusable(&e820, base, base + size) )
+ return 0;
+
+ /* TXT Private Space */
+ if ( !reserve_e820_unusable(&e820, TXT_PRIV_CONFIG_REGS_BASE,
+ TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE) )
+ return 0;
+
+ destroy_xen_mappings((unsigned long)__va(map_base << PAGE_SHIFT),
+ (unsigned long)__va((map_base + map_size) << PAGE_SHIFT));
+
+ return 1;
+}
+
/*
* Local variables:
* mode: C
diff -r 9ba8aecc3a15 -r 196ed4d1e316 xen/include/asm-x86/e820.h
--- a/xen/include/asm-x86/e820.h Wed Jan 28 22:09:02 2009 -0800
+++ b/xen/include/asm-x86/e820.h Wed Jan 28 22:12:49 2009 -0800
@@ -24,6 +24,7 @@ struct e820map {
};

extern int reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e);
+extern int reserve_e820_unusable(struct e820map *e820, uint64_t s, uint64_t e);
extern unsigned long init_e820(const char *, struct e820entry *, int *);
extern struct e820map e820;

diff -r 9ba8aecc3a15 -r 196ed4d1e316 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Wed Jan 28 22:09:02 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Wed Jan 28 22:12:49 2009 -0800
@@ -100,6 +100,7 @@ void tboot_probe(void);
void tboot_probe(void);
void tboot_shutdown(uint32_t shutdown_type);
int tboot_in_measured_env(void);
+int tboot_protect_mem_regions(void);

#endif /* __TBOOT_H__ */

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-03c-protect_txt_ranges.patch (12K) Download Attachment

[PATCH v2] txt: 2/5 - ACPI Generic Address Structure for tboot shutdown

2009-01-29T00:55:10Z

New versions of tboot support ACPI GAS (Generic Address Structure) for handling sleep states. This required a change to the tboot_shared_t data structure that is not backwards compatible. This patch requires that new version makes use of GAS when invoking tboot on shutdown.

Signed-off-by: Shane Wang <shane.wang@...>
Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r ecb74962f6f4 -r 9ba8aecc3a15 xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c Wed Jan 28 21:56:22 2009 -0800
+++ b/xen/arch/x86/acpi/power.c Wed Jan 28 22:09:02 2009 -0800
@@ -129,19 +129,13 @@ static void acpi_sleep_prepare(u32 state

wakeup_vector_va = __acpi_map_table(
acpi_sinfo.wakeup_vector, sizeof(uint64_t));
- if ( acpi_sinfo.vector_width == 32 )
- {
- *(uint32_t *)wakeup_vector_va =
- tboot_in_measured_env() ?
- (uint32_t)g_tboot_shared->s3_tb_wakeup_entry :
- (uint32_t)bootsym_phys(wakeup_start);
- }
- else
- {
- *(uint64_t *)wakeup_vector_va =
- tboot_in_measured_env() ?
- (uint64_t)g_tboot_shared->s3_tb_wakeup_entry :
- (uint64_t)bootsym_phys(wakeup_start);
+
+ /* tboot will set resume vector itself (when it is safe to do so) */
+ if ( !tboot_in_measured_env() ) {
+ if ( acpi_sinfo.vector_width == 32 )
+ *(uint32_t *)wakeup_vector_va = (uint32_t)bootsym_phys(wakeup_start);
+ else
+ *(uint64_t *)wakeup_vector_va = (uint64_t)bootsym_phys(wakeup_start);
}
}

@@ -279,37 +273,47 @@ static int acpi_get_wake_status(void)

static void tboot_sleep(u8 sleep_state)
{
- uint32_t shutdown_type;
+ uint32_t shutdown_type;

- g_tboot_shared->acpi_sinfo.pm1a_cnt =
- (uint16_t)acpi_sinfo.pm1a_cnt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1b_cnt =
- (uint16_t)acpi_sinfo.pm1b_cnt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1a_evt =
- (uint16_t)acpi_sinfo.pm1a_evt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1b_evt =
- (uint16_t)acpi_sinfo.pm1b_evt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1a_cnt_val = acpi_sinfo.pm1a_cnt_val;
- g_tboot_shared->acpi_sinfo.pm1b_cnt_val = acpi_sinfo.pm1b_cnt_val;
+#define TB_COPY_GAS(tbg, g) \
+ tbg.space_id = g.space_id; \
+ tbg.bit_width = g.bit_width; \
+ tbg.bit_offset = g.bit_offset; \
+ tbg.access_width = g.access_width; \
+ tbg.address = g.address;

- switch ( sleep_state )
- {
- case ACPI_STATE_S3:
- shutdown_type = TB_SHUTDOWN_S3;
- g_tboot_shared->s3_k_wakeup_entry =
- (uint32_t)bootsym_phys(wakeup_start);
- break;
- case ACPI_STATE_S4:
- shutdown_type = TB_SHUTDOWN_S4;
- break;
- case ACPI_STATE_S5:
- shutdown_type = TB_SHUTDOWN_S5;
- break;
- default:
- return;
- }
+ /* sizes are not same (due to packing) so copy each one */
+ TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1a_cnt_blk,
+ acpi_sinfo.pm1a_cnt_blk);
+ TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1b_cnt_blk,
+ acpi_sinfo.pm1b_cnt_blk);
+ TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1a_evt_blk,
+ acpi_sinfo.pm1a_evt_blk);
+ TB_COPY_GAS(g_tboot_shared->acpi_sinfo.pm1b_evt_blk,
+ acpi_sinfo.pm1b_evt_blk);
+ g_tboot_shared->acpi_sinfo.pm1a_cnt_val = acpi_sinfo.pm1a_cnt_val;
+ g_tboot_shared->acpi_sinfo.pm1b_cnt_val = acpi_sinfo.pm1b_cnt_val;
+ g_tboot_shared->acpi_sinfo.wakeup_vector = acpi_sinfo.wakeup_vector;
+ g_tboot_shared->acpi_sinfo.vector_width = acpi_sinfo.vector_width;
+ g_tboot_shared->acpi_sinfo.kernel_s3_resume_vector =
+ bootsym_phys(wakeup_start);

- tboot_shutdown(shutdown_type);
+ switch ( sleep_state )
+ {
+ case ACPI_STATE_S3:
+ shutdown_type = TB_SHUTDOWN_S3;
+ break;
+ case ACPI_STATE_S4:
+ shutdown_type = TB_SHUTDOWN_S4;
+ break;
+ case ACPI_STATE_S5:
+ shutdown_type = TB_SHUTDOWN_S5;
+ break;
+ default:
+ return;
+ }
+
+ tboot_shutdown(shutdown_type);
}

/* System is really put into sleep state by this stub */
diff -r ecb74962f6f4 -r 9ba8aecc3a15 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Wed Jan 28 21:56:22 2009 -0800
+++ b/xen/arch/x86/tboot.c Wed Jan 28 22:09:02 2009 -0800
@@ -30,23 +30,24 @@ void __init tboot_probe(void)
/* Map and check for tboot UUID. */
set_fixmap(FIX_TBOOT_SHARED_BASE, p_tboot_shared);
tboot_shared = (tboot_shared_t *)fix_to_virt(FIX_TBOOT_SHARED_BASE);
+ if ( tboot_shared == NULL )
+ return;
if ( memcmp(&tboot_shared_uuid, (uuid_t *)tboot_shared, sizeof(uuid_t)) )
return;
+
+ /* new tboot_shared (w/ GAS support) is not backwards compatible */
+ if ( tboot_shared->version < 3 ) {
+ printk("unsupported version of tboot (%u)\n", tboot_shared->version);
+ return;
+ }

g_tboot_shared = tboot_shared;
printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared);
printk(" version: %d\n", tboot_shared->version);
printk(" log_addr: 0x%08x\n", tboot_shared->log_addr);
printk(" shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
- printk(" shutdown_type: %d\n", tboot_shared->shutdown_type);
- printk(" s3_tb_wakeup_entry: 0x%08x\n", tboot_shared->s3_tb_wakeup_entry);
- printk(" s3_k_wakeup_entry: 0x%08x\n", tboot_shared->s3_k_wakeup_entry);
- printk(" &acpi_sinfo: 0x%p\n", &tboot_shared->acpi_sinfo);
- if ( tboot_shared->version >= 0x02 )
- {
- printk(" tboot_base: 0x%08x\n", tboot_shared->tboot_base);
- printk(" tboot_size: 0x%x\n", tboot_shared->tboot_size);
- }
+ printk(" tboot_base: 0x%08x\n", tboot_shared->tboot_base);
+ printk(" tboot_size: 0x%x\n", tboot_shared->tboot_size);
}

void tboot_shutdown(uint32_t shutdown_type)
@@ -59,16 +60,8 @@ void tboot_shutdown(uint32_t shutdown_ty
local_irq_disable();

/* Create identity map for tboot shutdown code. */
- if ( g_tboot_shared->version >= 0x02 )
- {
- map_base = PFN_DOWN(g_tboot_shared->tboot_base);
- map_size = PFN_UP(g_tboot_shared->tboot_size);
- }
- else
- {
- map_base = 0;
- map_size = PFN_UP(0xa0000);
- }
+ map_base = PFN_DOWN(g_tboot_shared->tboot_base);
+ map_size = PFN_UP(g_tboot_shared->tboot_size);

err = map_pages_to_xen(map_base << PAGE_SHIFT, map_base, map_size,
__PAGE_HYPERVISOR);
diff -r ecb74962f6f4 -r 9ba8aecc3a15 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Wed Jan 28 21:56:22 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Wed Jan 28 22:09:02 2009 -0800
@@ -37,7 +37,11 @@
#ifndef __TBOOT_H__
#define __TBOOT_H__

-typedef struct __attribute__ ((__packed__)) {
+#ifndef __packed
+#define __packed __attribute__ ((packed))
+#endif
+
+typedef struct __packed {
uint32_t data1;
uint16_t data2;
uint16_t data3;
@@ -47,28 +51,36 @@ typedef struct __attribute__ ((__packed_

/* used to communicate between tboot and the launched kernel (i.e. Xen) */

-typedef struct __attribute__ ((__packed__)) {
- uint16_t pm1a_cnt;
- uint16_t pm1b_cnt;
- uint16_t pm1a_evt;
- uint16_t pm1b_evt;
+/* GAS - Generic Address Structure (ACPI 2.0+) */
+typedef struct __packed {
+ uint8_t space_id;
+ uint8_t bit_width;
+ uint8_t bit_offset;
+ uint8_t access_width;
+ uint64_t address;
+} tboot_acpi_generic_address_t;
+
+typedef struct __packed {
+ tboot_acpi_generic_address_t pm1a_cnt_blk;
+ tboot_acpi_generic_address_t pm1b_cnt_blk;
+ tboot_acpi_generic_address_t pm1a_evt_blk;
+ tboot_acpi_generic_address_t pm1b_evt_blk;
uint16_t pm1a_cnt_val;
uint16_t pm1b_cnt_val;
-} tboot_acpi_sleep_info;
+ uint64_t wakeup_vector;
+ uint32_t vector_width;
+ uint64_t kernel_s3_resume_vector;
+} tboot_acpi_sleep_info_t;

-typedef struct __attribute__ ((__packed__)) {
- /* version 0x01+ fields: */
+typedef struct __packed {
+ /* version 3+ fields: */
uuid_t uuid; /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
- uint32_t version; /* Version number: 0x01, 0x02, ... */
+ uint32_t version; /* Version number; currently supports 0.3 */
uint32_t log_addr; /* physical addr of tb_log_t log */
uint32_t shutdown_entry; /* entry point for tboot shutdown */
uint32_t shutdown_type; /* type of shutdown (TB_SHUTDOWN_*) */
- uint32_t s3_tb_wakeup_entry;/* entry point for tboot s3 wake up */
- uint32_t s3_k_wakeup_entry; /* entry point for xen s3 wake up */
- tboot_acpi_sleep_info
+ tboot_acpi_sleep_info_t
acpi_sinfo; /* where kernel put acpi sleep info in Sx */
- uint8_t reserved[52]; /* this pad is for compat with old field */
- /* version 0x02+ fields: */
uint32_t tboot_base; /* starting addr for tboot */
uint32_t tboot_size; /* size of tboot */
} tboot_shared_t;

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-02c-acpi_gas_support.patch (12K) Download Attachment

[PATCH v2] txt: 1/5 - single tboot entry point for shutdown

2009-01-29T00:54:56Z

tboot removed the shutdown_entry32 and shutdown_entry64 from tboot_shared_t and now has just a single shutdown_entry field.

Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r af1d9af1a993 -r d4268eed9830 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Wed Jan 21 14:44:43 2009 +0000
+++ b/xen/arch/x86/tboot.c Wed Jan 21 22:04:51 2009 -0800
@@ -37,8 +37,7 @@ void __init tboot_probe(void)
printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared);
printk(" version: %d\n", tboot_shared->version);
printk(" log_addr: 0x%08x\n", tboot_shared->log_addr);
- printk(" shutdown_entry32: 0x%08x\n", tboot_shared->shutdown_entry32);
- printk(" shutdown_entry64: 0x%08x\n", tboot_shared->shutdown_entry64);
+ printk(" shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
printk(" shutdown_type: %d\n", tboot_shared->shutdown_type);
printk(" s3_tb_wakeup_entry: 0x%08x\n", tboot_shared->s3_tb_wakeup_entry);
printk(" s3_k_wakeup_entry: 0x%08x\n", tboot_shared->s3_k_wakeup_entry);
@@ -82,11 +81,7 @@ void tboot_shutdown(uint32_t shutdown_ty

write_ptbase(idle_vcpu[0]);

-#ifdef __x86_64__
- asm volatile ( "call *%%rdi" :: "D" (g_tboot_shared->shutdown_entry64) );
-#else
- asm volatile ( "call *%0" :: "r" (g_tboot_shared->shutdown_entry32) );
-#endif
+ ((void(*)(void))(unsigned long)g_tboot_shared->shutdown_entry)();

BUG(); /* should not reach here */
}
diff -r af1d9af1a993 -r d4268eed9830 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Wed Jan 21 14:44:43 2009 +0000
+++ b/xen/include/asm-x86/tboot.h Wed Jan 21 22:04:51 2009 -0800
@@ -61,8 +61,7 @@ typedef struct __attribute__ ((__packed_
uuid_t uuid; /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
uint32_t version; /* Version number: 0x01, 0x02, ... */
uint32_t log_addr; /* physical addr of tb_log_t log */
- uint32_t shutdown_entry32; /* entry point for tboot shutdown from 32b */
- uint32_t shutdown_entry64; /* entry point for tboot shutdown from 64b */
+ uint32_t shutdown_entry; /* entry point for tboot shutdown */
uint32_t shutdown_type; /* type of shutdown (TB_SHUTDOWN_*) */
uint32_t s3_tb_wakeup_entry;/* entry point for tboot s3 wake up */
uint32_t s3_k_wakeup_entry; /* entry point for xen s3 wake up */

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-01-unified_shutdown_entry.patch (3K) Download Attachment

[PATCH v2] txt: 0/5 - Overview

2009-01-29T00:54:31Z

This patch series are changes to Xen to support new functionality, and a changed API, in the tboot project (see http://sourceforge.net/projects/tboot for more info about tboot). Some of these changes originated from comments received when the first set of Linux tboot/Intel(r) TXT patches were posted to LKML.

Attached to this patch is a single patch to be applied to the current tip of the tboot source tree (located at http://www.bughost.org/repos.hg/tboot.hg). Due to the API change, for those who wish to test the patches, it would be best to apply all of the tboot patch at once and test with all of the Xen patches applied to Xen.

Since the API changes are not backwards compatible, the resulting tboot will not work with a Xen that does not have the patches applied. Likewise, a Xen with these patches applied will not work with the un-patched tboot. To keep backward compatibility would have left the interface and code fairly ugly and didn't seem worth the trouble.

The Xen patches are as follows:

xen-txt-01-unified_shutdown_entry.patch - single tboot entry point for shutdown
xen-txt-02c-acpi_gas_support.patch - ACPI Generic Address Structure for tboot shutdown
xen-txt-03c-protect_txt_ranges.patch - explicitly protect TXT addr ranges from dom0
xen-txt-04c-hypervisor_s3_integrity.patch - hypervisor integrity on S3
xen-txt-05b-use_protected_dmar.patch - use TXT's DMA-protected DMAR table to setup VT-d

We are currently working on a patch that will extend the S3 integrity to domains, as configurable via a domain's config file (and always for dom0).

The patches apply cleanly to the latest xen-unstable (c/s 19104:31983c30c460).

Joe and Shane

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

tboot-combined.patch (71K) Download Attachment

RE: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0

2009-01-20T23:41:02Z

Re: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0

We had an earlier version of our patch that just altered the e820 table, but we were concerned about the code complexity needed to do that (the existing Xen e820 fns aren’t sufficient for this). Here is the change that we would need to add—do you prefer this:

diff -r dbac9ee4d761 xen/arch/x86/e820.c

--- a/xen/arch/x86/e820.c Mon Sep 08 16:02:13 2008 +0100

+++ b/xen/arch/x86/e820.c Sat Nov 22 02:04:51 2008 +0800

@@ -373,11 +373,13 @@ static void __init machine_specific_memo

reserve_dmi_region();

}

-/* Reserve RAM area (@s,@e) in the specified e820 map. */

-int __init reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e)

+static int reserve_e820(uint32_t type, struct e820map *e820,

+ uint64_t s, uint64_t e, uint32_t t)

{

uint64_t rs = 0, re = 0;

- int i;

+ int i, remove;

+ remove = (type == t);

for ( i = 0; i < e820->nr_map; i++ )

{

@@ -388,55 +390,131 @@ int __init reserve_e820_ram(struct e820m

break;

}

- if ( (i == e820->nr_map) || (e820->map[i].type != E820_RAM) )

+ if ( (i == e820->nr_map) || (e820->map[i].type != type) )

return 0;

if ( (s == rs) && (e == re) )

{

/* Complete excision. */

- memmove(&e820->map[i], &e820->map[i+1],

- (e820->nr_map-i-1) * sizeof(e820->map[0]));

- e820->nr_map--;

+ if (remove)

+ {

+ memmove(&e820->map[i], &e820->map[i+1],

+ (e820->nr_map-i-1) * sizeof(e820->map[0]));

+ e820->nr_map--;

+ }

+ else

+ e820->map[i].type = t;

}

else if ( s == rs )

{

- /* Truncate start. */

+ /* If not remove, split it in two, or else, truncate start. */

+ if (!remove)

+ {

+ if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )

+ {

+ printk("e820 overflow\n");

+ return 0;

+ }

+ memmove(&e820->map[i+1], &e820->map[i],

+ (e820->nr_map-i) * sizeof(e820->map[0]));

+ e820->nr_map++;

+ e820->map[i].addr = s;

+ e820->map[i].size = e - s;

+ e820->map[i].type = t;

+ i++;

+ }

e820->map[i].addr += e - s;

e820->map[i].size -= e - s;

}

else if ( e == re )

{

- /* Truncate end. */

- e820->map[i].size -= e - s;

- }

- else if ( e820->nr_map < ARRAY_SIZE(e820->map) )

- {

- /* Split in two. */

- memmove(&e820->map[i+1], &e820->map[i],

- (e820->nr_map-i) * sizeof(e820->map[0]));

- e820->nr_map++;

- e820->map[i].size = s - rs;

- i++;

- e820->map[i].addr = e;

- e820->map[i].size = re - e;

+ /* If not remove, split it in two, or else, truncate end. */

+ if (!remove)

+ {

+ if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )

+ {

+ printk("e820 overflow\n");

+ return 0;

+ }

+ memmove(&e820->map[i+1], &e820->map[i],

+ (e820->nr_map-i) * sizeof(e820->map[0]));

+ e820->nr_map++;

+ e820->map[i].size -= e - s;

+ i++;

+ e820->map[i].addr = s;

+ e820->map[i].size = e - s;

+ e820->map[i].type = t;

+ }

+ else

+ e820->map[i].size -= e - s;

}

else

{

- /* e820map is at maximum size. We have to leak some space. */

- if ( (s - rs) > (re - e) )

+ /* If not remove, split in three, or else, split in two. */

+ if (!remove)

{

- printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n", e, re);

+ if ( e820->nr_map+2 > ARRAY_SIZE(e820->map) )

+ {

+ printk("e820 overflow\n");

+ return 0;

+ }

+ memmove(&e820->map[i+2], &e820->map[i],

+ (e820->nr_map-i) * sizeof(e820->map[0]));

+ e820->nr_map += 2;

e820->map[i].size = s - rs;

+ i++;

+ e820->map[i].addr = s;

+ e820->map[i].size = e - s;

+ e820->map[i].type = t;

+ i++;

+ e820->map[i].addr = e;

+ e820->map[i].size = re - e;

}

else

{

- printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n", rs, s);

- e820->map[i].addr = e;

- e820->map[i].size = re - e;

+ if ( e820->nr_map < ARRAY_SIZE(e820->map) )

+ {

+ memmove(&e820->map[i+1], &e820->map[i],

+ (e820->nr_map-i) * sizeof(e820->map[0]));

+ e820->nr_map++;

+ e820->map[i].size = s - rs;

+ i++;

+ e820->map[i].addr = e;

+ e820->map[i].size = re - e;

+ }

+ else

+ {

+ /* e820map is at maximum size. We have to leak some space. */

+ if ( (s - rs) > (re - e) )

+ {

+ printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n",

+ e, re);

+ e820->map[i].size = s - rs;

+ }

+ else

+ {

+ printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n",

+ rs, s);

+ e820->map[i].addr = e;

+ e820->map[i].size = re - e;

+ }

}

return 1;

+/* Reserve RAM area (@s,@e) in the specified e820 map. */

+int __init reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e)

+ return reserve_e820(E820_RAM, e820, s, e, E820_RAM);

+/* Reserve RESERVE area (@s, @e) as UNUSABLE in the specified e820 map. */

+int reserve_e820_reserved(struct e820map *e820, uint64_t s, uint64_t e)

+ return reserve_e820(E820_RESERVED, e820, s, e, E820_UNUSABLE);

}

unsigned long __init init_e820(

From: Keir Fraser [mailto:keir.fraser@...]
Sent: Tuesday, January 20, 2009 12:57 AM
To: Cihula, Joseph; xen-devel@...; xense-devel@...
Cc: Wang, Shane
Subject: Re: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0

Xen tracks protected memory regions in its private e820 structure. If tboot is no longer marking E820_UNUSABLE in e820, then have Xen manually add the regions to its private e820. Then you won’t need your new ad hoc structure plus needing to process that new structure in various places.

-- Keir

On 20/01/2009 05:49, "Cihula, Joseph" <joseph.cihula@...> wrote:

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Re: Question about XSM-ACM XSM-FLASK differences

2009-01-20T15:52:07Z

ACM and FLASK are security modules under the XSM framework. Only XSM-FLASK
is based on the Flask architecture. Both modules implement type enforcement
but differ in the granularity of the enforcement.

XSM-ACM(sHype) is described in the open literature,

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/5FF6B8DE618BCF30852
570230052518A/$File/rc23629.pdf

and

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/265C8E3A6F95CA8D852
56FA1005CBF0F/$File/rc23511.pdf

XSM-FLASK is based on the same security architecture (Flask) and goals as
SELinux, which is described in the open literature,

http://www.nsa.gov/research/_files/selinux/papers/module.pdf

and

http://www.nsa.gov/research/_files/selinux/papers/slinux.pdf

The scope for XSM-FLASK is limited to Xen. The XSM-FLASK module implements
a separate and distinct security server from SELinux. The subjects,
objects, and permissions described in the XSM-FLASK policy are relevant only
to Xen. There is no functional dependency between XSM-FLASK and SELinux
guests. However, one uses the SELinux tools and policy grammar to construct
and analyze XSM-FLASK policies.

In a system running an SELinux guest and an XSM-FLASK enabled hypervisor,
there are two security servers. One security server is in the SELinux
guest. The other security server is in the XSM-FLASK enabled hypervisor.
Each security server is loaded with a policy that is relevant only to the
SELinux guest or XSM-Flask enabled hypervisor, respectively.

Let me know if this doesn't answer your questions.

On 1/16/09 4:07 AM, "Atsushi SAKAI" <sakaia@...> wrote:

> Hi,
>
> I have a question about XSM-ACM(sHype) and XSM-FLASK difference.
> These two are based on Flask model.
> So I wan to know the difference of these two.
>
> Is this is only a implementation difference?
> (like a policy description format etc.)
>
> Or any other difference exists?
>
> I think XSM-FLASK policy format is same as SELinux one.
> But Security Server is splited between Linux/Xen.
> In this situation,
> it looks same XSM-ACM and XSM-FLASKin a view from Security Server.
>
> If this discussion is already done,
> Please suggest me a pointer.
>
> Thanks
> Atsushi SAKAI
>
>
>
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@...
> http://lists.xensource.com/xense-devel

--
George S. Coker, II <gscoker@...>

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

RE: [PATCH] txt: 0/6 - Overview

2009-01-19T22:23:21Z

Hold off on these patches--there appear to be a few issues when I run them on the current tip.

Joe

> -----Original Message-----
> From: xense-devel-bounces@... [mailto:xense-devel-bounces@...]
> On Behalf Of Cihula, Joseph
> Sent: Monday, January 19, 2009 9:48 PM
> To: xen-devel@...; xense-devel@...
> Cc: Wang, Shane; Keir Fraser
> Subject: [Xense-devel] [PATCH] txt: 0/6 - Overview
>
> This patch series are changes to Xen to support new functionality, and a changed API, in the
> tboot project (see http://sourceforge.net/projects/tboot for more info about tboot). Some of
> these changes originated from comments received when the first set of Linux tboot/Intel(r) TXT
> patches were posted to LKML.
>
> Attached to this patch is a single patch to be applied to the current tip of the tboot source
> tree (located at http://www.bughost.org/repos.hg/tboot.hg). Due to the API change, for those
> who wish to test the patches, it would be best to apply all of the tboot patch at once and
> test with all of the Xen patches applied to Xen.
>
> Since the API changes are not backwards compatible, the resulting tboot will not work with a
> Xen that does not have the patches applied. Likewise, a Xen with these patches applied will
> not work with the un-patched tboot. To keep backward compatibility would have left the
> interface and code fairly ugly and didn't seem worth the trouble.
>
> The Xen patches are as follows:
>
> xen-txt-01-xen_phys_addr_start_fix.patch - "fix" xen_phys_start for 32b builds
> xen-txt-02-protect_txt_ranges.patch - explicitly protect TXT addr ranges from dom0
> xen-txt-03-use_protected_dmar.patch - use TXT's DMA-protected DMAR table to setup VT-d
> xen-txt-04-acpi_gas_support.patch - ACPI Generic Address Structure for tboot shutdown
> xen-txt-05-unified_shutdown_entry.patch - single tboot entry point for shutdown
> xen-txt-06-hypervisor_s3_integrity.patch - hypervisor integrity on S3
>
> We are currently working on a patch that will extend the S3 integrity to domains, as
> configurable via a domain's config file (and always for dom0).
>
> The patches apply cleanly to the latest xen-unstable.
>
> Joe and Shane

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

[PATCH] txt: 6/6 - hypervisor integrity on S3

2009-01-19T21:50:31Z

When launched from tboot, utilise tboot interface to provide integrity protection to the hypervisor during S3

Signed-off-by: Joseph Cihula <joseph.cihula@...>
ACKed-by: Shane Wang <shane.wang@...>

diff -r bc2e19b70b3d -r 6b9033a1e376 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Fri Jan 16 13:45:37 2009 -0800
+++ b/xen/arch/x86/tboot.c Fri Jan 16 13:46:44 2009 -0800
@@ -99,6 +99,19 @@ void tboot_shutdown(uint32_t shutdown_ty

local_irq_disable();

+ /* if this is S3 then set regions to MAC */
+ if ( shutdown_type == TB_SHUTDOWN_S3 ) {
+ g_tboot_shared->num_mac_regions = 2;
+ /* S3 resume code (and other real mode trampoline code) */
+ g_tboot_shared->mac_regions[0].start =
+ (uint64_t)bootsym_phys(trampoline_start);
+ g_tboot_shared->mac_regions[0].end =
+ (uint64_t)bootsym_phys(trampoline_end);
+ /* hypervisor code + data */
+ g_tboot_shared->mac_regions[1].start = (uint64_t)xen_phys_start;
+ g_tboot_shared->mac_regions[1].end = (uint64_t)xenheap_phys_end;
+ }
+
/* Create identity map for tboot shutdown code. */
map_base = PFN_DOWN(g_tboot_shared->tboot_base);
map_size = PFN_UP(g_tboot_shared->tboot_size);
diff -r bc2e19b70b3d -r 6b9033a1e376 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Fri Jan 16 13:45:37 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Fri Jan 16 13:46:44 2009 -0800
@@ -53,6 +53,12 @@ typedef struct __packed {

/* used to communicate between tboot and the launched kernel (i.e. Xen) */

+#define MAX_TB_MAC_REGIONS 32
+typedef struct __packed {
+ uint64_t start;
+ uint64_t end;
+} tboot_mac_region_t;
+
typedef struct acpi_generic_address tboot_acpi_generic_address_t;

typedef struct __packed {
@@ -77,6 +83,9 @@ typedef struct __packed {
acpi_sinfo; /* where kernel put acpi sleep info in Sx */
uint32_t tboot_base; /* starting addr for tboot */
uint32_t tboot_size; /* size of tboot */
+ uint8_t num_mac_regions; /* number mem regions to MAC on S3 */
+ /* contig regions memory to MAC on S3 */
+ tboot_mac_region_t mac_regions[MAX_TB_MAC_REGIONS];
} tboot_shared_t;

#define TB_SHUTDOWN_REBOOT 0

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-06-hypervisor_s3_integrity.patch (3K) Download Attachment

[PATCH] txt: 5/6 - single tboot entry point for shutdown

2009-01-19T21:50:05Z

tboot removed the shutdown_entry32 and shutdown_entry64 from tboot_shared_t and
now has just a single shutdown_entry field.

Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r feb5e3c4a82d -r bc2e19b70b3d xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Fri Jan 16 13:44:38 2009 -0800
+++ b/xen/arch/x86/tboot.c Fri Jan 16 13:45:37 2009 -0800
@@ -52,8 +52,7 @@ void __init tboot_probe(void)
printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared);
printk(" version: %d\n", tboot_shared->version);
printk(" log_addr: 0x%08x\n", tboot_shared->log_addr);
- printk(" shutdown_entry32: 0x%08x\n", tboot_shared->shutdown_entry32);
- printk(" shutdown_entry64: 0x%08x\n", tboot_shared->shutdown_entry64);
+ printk(" shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
printk(" shutdown_type: %d\n", tboot_shared->shutdown_type);
printk(" s3_tb_wakeup_entry: 0x%08x\n", tboot_shared->s3_tb_wakeup_entry);
printk(" s3_k_wakeup_entry: 0x%08x\n", tboot_shared->s3_k_wakeup_entry);
@@ -115,11 +114,7 @@ void tboot_shutdown(uint32_t shutdown_ty

write_ptbase(idle_vcpu[0]);

-#ifdef __x86_64__
- asm volatile ( "call *%%rdi" :: "D" (g_tboot_shared->shutdown_entry64) );
-#else
- asm volatile ( "call *%0" :: "r" (g_tboot_shared->shutdown_entry32) );
-#endif
+ ((void(*)(void))(unsigned long)g_tboot_shared->shutdown_entry)();

BUG(); /* should not reach here */
}
diff -r feb5e3c4a82d -r bc2e19b70b3d xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Fri Jan 16 13:44:38 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Fri Jan 16 13:45:37 2009 -0800
@@ -69,8 +69,7 @@ typedef struct __packed {
uuid_t uuid; /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
uint32_t version; /* Version number; currently supports 0.3 */
uint32_t log_addr; /* physical addr of tb_log_t log */
- uint32_t shutdown_entry32; /* entry point for tboot shutdown from 32b */
- uint32_t shutdown_entry64; /* entry point for tboot shutdown from 64b */
+ uint32_t shutdown_entry; /* entry point for tboot shutdown */
uint32_t shutdown_type; /* type of shutdown (TB_SHUTDOWN_*) */
uint32_t s3_tb_wakeup_entry;/* entry point for tboot s3 wake up */
uint32_t s3_k_wakeup_entry; /* entry point for xen s3 wake up */

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-05-unified_shutdown_entry.patch (3K) Download Attachment

[PATCH] txt: 4/6 - ACPI Generic Address Structure for tboot shutdown

2009-01-19T21:49:43Z

New versions of tboot support ACPI GAS (Generic Address Structure) for handling
sleep states. This required a change to the tboot_shared_t data structure that
is not backwards compatible. This patch requires that new version makes use of
GAS when invoking tboot on shutdown.

Signed-off-by: Shane Wang <shane.wang@...>
Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r a851239c01cb -r feb5e3c4a82d xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c Fri Jan 16 13:43:15 2009 -0800
+++ b/xen/arch/x86/acpi/power.c Fri Jan 16 13:44:38 2009 -0800
@@ -276,39 +276,76 @@ static int acpi_get_wake_status(void)
return val;
}

+static int verify_acpi_ptr(tboot_acpi_generic_address_t blk)
+{
+ struct page_info *pg;
+ struct domain *d;
+ uint64_t addr;
+
+ if ( blk.space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY )
+ return -1;
+
+ ACPI_MOVE_64_TO_64(&addr, &blk.address);
+
+ if ( (addr >= bootsym_phys(trampoline_start))
+ && (addr <= bootsym_phys(trampoline_end)) )
+ {
+ gdprintk(XENLOG_ERR, "ACPI Pointer in trampoline code\n");
+ return 0;
+ }
+
+ pg = maddr_to_page(addr);
+ if ( is_xen_heap_page(pg) )
+ {
+ gdprintk(XENLOG_ERR, "ACPI Pointer in Xen\n");
+ return 0;
+ }
+
+ d = maddr_get_owner(addr);
+ if ( d != NULL )
+ {
+ gdprintk(XENLOG_ERR, "ACPI Pointer in Domain %u\n", d->domain_id);
+ return 0;
+ }
+
+ return -1;
+}
+
static void tboot_sleep(u8 sleep_state)
{
- uint32_t shutdown_type;
+ uint32_t shutdown_type;

- g_tboot_shared->acpi_sinfo.pm1a_cnt =
- (uint16_t)acpi_sinfo.pm1a_cnt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1b_cnt =
- (uint16_t)acpi_sinfo.pm1b_cnt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1a_evt =
- (uint16_t)acpi_sinfo.pm1a_evt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1b_evt =
- (uint16_t)acpi_sinfo.pm1b_evt_blk.address;
- g_tboot_shared->acpi_sinfo.pm1a_cnt_val = acpi_sinfo.pm1a_cnt_val;
- g_tboot_shared->acpi_sinfo.pm1b_cnt_val = acpi_sinfo.pm1b_cnt_val;
+ /* Verify ACPI addresses */
+ if ( !verify_acpi_ptr(acpi_sinfo.pm1a_cnt_blk) )
+ return;
+ if ( !verify_acpi_ptr(acpi_sinfo.pm1b_cnt_blk) )
+ return;
+ if ( !verify_acpi_ptr(acpi_sinfo.pm1a_evt_blk) )
+ return;
+ if ( !verify_acpi_ptr(acpi_sinfo.pm1b_evt_blk) )
+ return;

- switch ( sleep_state )
- {
- case ACPI_STATE_S3:
- shutdown_type = TB_SHUTDOWN_S3;
- g_tboot_shared->s3_k_wakeup_entry =
- (uint32_t)bootsym_phys(wakeup_start);
- break;
- case ACPI_STATE_S4:
- shutdown_type = TB_SHUTDOWN_S4;
- break;
- case ACPI_STATE_S5:
- shutdown_type = TB_SHUTDOWN_S5;
- break;
- default:
- return;
- }
+ memcpy(&g_tboot_shared->acpi_sinfo, &acpi_sinfo,
+ sizeof(tboot_acpi_sleep_info));

- tboot_shutdown(shutdown_type);
+ switch ( sleep_state )
+ {
+ case ACPI_STATE_S3:
+ shutdown_type = TB_SHUTDOWN_S3;
+ g_tboot_shared->s3_k_wakeup_entry =
+ (uint32_t)bootsym_phys(wakeup_start);
+ break;
+ case ACPI_STATE_S4:
+ shutdown_type = TB_SHUTDOWN_S4;
+ break;
+ case ACPI_STATE_S5:
+ shutdown_type = TB_SHUTDOWN_S5;
+ break;
+ default:
+ return;
+ }
+
+ tboot_shutdown(shutdown_type);
}

/* System is really put into sleep state by this stub */
diff -r a851239c01cb -r feb5e3c4a82d xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Fri Jan 16 13:43:15 2009 -0800
+++ b/xen/arch/x86/tboot.c Fri Jan 16 13:44:38 2009 -0800
@@ -42,6 +42,12 @@ void __init tboot_probe(void)
if ( memcmp(&tboot_shared_uuid, (uuid_t *)tboot_shared, sizeof(uuid_t)) )
return;

+ /* new tboot_shared (w/ GAS support) is not backwards compatible */
+ if ( tboot_shared->version < 3 ) {
+ printk("unsupported version of tboot (%u)\n", tboot_shared->version);
+ return;
+ }
+
g_tboot_shared = tboot_shared;
printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared);
printk(" version: %d\n", tboot_shared->version);
@@ -52,11 +58,8 @@ void __init tboot_probe(void)
printk(" s3_tb_wakeup_entry: 0x%08x\n", tboot_shared->s3_tb_wakeup_entry);
printk(" s3_k_wakeup_entry: 0x%08x\n", tboot_shared->s3_k_wakeup_entry);
printk(" &acpi_sinfo: 0x%p\n", &tboot_shared->acpi_sinfo);
- if ( tboot_shared->version >= 0x02 )
- {
- printk(" tboot_base: 0x%08x\n", tboot_shared->tboot_base);
- printk(" tboot_size: 0x%x\n", tboot_shared->tboot_size);
- }
+ printk(" tboot_base: 0x%08x\n", tboot_shared->tboot_base);
+ printk(" tboot_size: 0x%x\n", tboot_shared->tboot_size);

/* Get TXT heaps/SINIT/Private Space addresses. */
map_base = PFN_DOWN(TXT_PUB_CONFIG_REGS_BASE);
@@ -98,16 +101,8 @@ void tboot_shutdown(uint32_t shutdown_ty
local_irq_disable();

/* Create identity map for tboot shutdown code. */
- if ( g_tboot_shared->version >= 0x02 )
- {
- map_base = PFN_DOWN(g_tboot_shared->tboot_base);
- map_size = PFN_UP(g_tboot_shared->tboot_size);
- }
- else
- {
- map_base = 0;
- map_size = PFN_UP(0xa0000);
- }
+ map_base = PFN_DOWN(g_tboot_shared->tboot_base);
+ map_size = PFN_UP(g_tboot_shared->tboot_size);

err = map_pages_to_xen(map_base << PAGE_SHIFT, map_base, map_size,
__PAGE_HYPERVISOR);
@@ -136,7 +131,7 @@ int tboot_in_measured_env(void)

int tboot_in_range(paddr_t start, paddr_t end)
{
- if ( g_tboot_shared == NULL || g_tboot_shared->version < 0x02 )
+ if ( !tboot_in_measured_env() )
return 0;

start = max_t(paddr_t, start, g_tboot_shared->tboot_base);
diff -r a851239c01cb -r feb5e3c4a82d xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Fri Jan 16 13:43:15 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Fri Jan 16 13:44:38 2009 -0800
@@ -53,19 +53,21 @@ typedef struct __packed {

/* used to communicate between tboot and the launched kernel (i.e. Xen) */

+typedef struct acpi_generic_address tboot_acpi_generic_address_t;
+
typedef struct __packed {
- uint16_t pm1a_cnt;
- uint16_t pm1b_cnt;
- uint16_t pm1a_evt;
- uint16_t pm1b_evt;
+ tboot_acpi_generic_address_t pm1a_cnt_blk;
+ tboot_acpi_generic_address_t pm1b_cnt_blk;
+ tboot_acpi_generic_address_t pm1a_evt_blk;
+ tboot_acpi_generic_address_t pm1b_evt_blk;
uint16_t pm1a_cnt_val;
uint16_t pm1b_cnt_val;
} tboot_acpi_sleep_info;

typedef struct __packed {
- /* version 0x01+ fields: */
+ /* version 3+ fields: */
uuid_t uuid; /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
- uint32_t version; /* Version number: 0x01, 0x02, ... */
+ uint32_t version; /* Version number; currently supports 0.3 */
uint32_t log_addr; /* physical addr of tb_log_t log */
uint32_t shutdown_entry32; /* entry point for tboot shutdown from 32b */
uint32_t shutdown_entry64; /* entry point for tboot shutdown from 64b */
@@ -74,8 +76,6 @@ typedef struct __packed {
uint32_t s3_k_wakeup_entry; /* entry point for xen s3 wake up */
tboot_acpi_sleep_info
acpi_sinfo; /* where kernel put acpi sleep info in Sx */
- uint8_t reserved[52]; /* this pad is for compat with old field */
- /* version 0x02+ fields: */
uint32_t tboot_base; /* starting addr for tboot */
uint32_t tboot_size; /* size of tboot */
} tboot_shared_t;

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-04-acpi_gas_support.patch (10K) Download Attachment

[PATCH] txt: 3/6 - use TXT's DMA-protected DMAR table to setup VT-d

2009-01-19T21:49:21Z

The VT-d DMAR ACPI tables may not be DMA protected by tboot. However, SINIT saves a copy of them in the SinitMleData struct in the TXT heap (which is DMA protected). So we should read the DMAR table from that copy if launched by tboot.

Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r bde0fd053306 -r a851239c01cb xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Fri Jan 16 13:34:36 2009 -0800
+++ b/xen/arch/x86/tboot.c Fri Jan 16 13:43:15 2009 -0800
@@ -20,6 +20,9 @@ uint64_t txt_protmem_range_ends[TXT_PROT
uint64_t txt_protmem_range_ends[TXT_PROTMEM_RANGE_MAX];

static const uuid_t tboot_shared_uuid = TBOOT_SHARED_UUID;
+
+/* used by tboot_probe() and tboot_parse_dmar_table() */
+static uint64_t txt_heap_base, txt_heap_size;

void __init tboot_probe(void)
{
@@ -68,6 +71,7 @@ void __init tboot_probe(void)
size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_SIZE);
txt_protmem_range_starts[0] = base;
txt_protmem_range_ends[0] = base + size - 1;
+ txt_heap_base = base; txt_heap_size = size;

/* SINIT */
base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
@@ -142,6 +146,56 @@ int tboot_in_range(paddr_t start, paddr_
return start < end;
}

+int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler)
+{
+ uint32_t map_base, map_size;
+ unsigned long map_vaddr;
+ void *heap_ptr;
+ struct acpi_table_header *dmar_table;
+ int rc;
+
+ if ( !tboot_in_measured_env() )
+ return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);
+
+ /* ACPI tables may not be DMA protected by tboot, so use DMAR copy */
+ /* SINIT saved in SinitMleData in TXT heap (which is DMA protected) */
+
+ /* map TXT heap into Xen addr space */
+ map_base = PFN_DOWN(txt_heap_base);
+ map_size = PFN_UP(txt_heap_size);
+ map_vaddr = (unsigned long)__va(map_base << PAGE_SHIFT);
+ if ( map_pages_to_xen(map_vaddr, map_base, map_size, __PAGE_HYPERVISOR) )
+ return 1;
+
+ /* walk heap to SinitMleData */
+ heap_ptr = __va(txt_heap_base);
+ /* skip BiosData */
+ heap_ptr += *(uint64_t *)heap_ptr;
+ /* skip OsMleData */
+ heap_ptr += *(uint64_t *)heap_ptr;
+ /* skip OsSinitData */
+ heap_ptr += *(uint64_t *)heap_ptr;
+ /* now points to SinitMleDataSize; set to SinitMleData */
+ heap_ptr += sizeof(uint64_t);
+ /* get addr of DMAR table */
+ dmar_table = (struct acpi_table_header *)(heap_ptr +
+ ((sinit_mle_data_t *)heap_ptr)->vtd_dmars_off - sizeof(uint64_t));
+
+ rc = dmar_handler(dmar_table);
+
+ /* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
+ /* but dom0 will read real table, so must zap it there too */
+ dmar_table = NULL;
+ acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_table);
+ if ( dmar_table != NULL )
+ ((struct acpi_table_dmar *)dmar_table)->header.signature[0] = '\0';
+
+ destroy_xen_mappings((unsigned long)__va(map_base << PAGE_SHIFT),
+ (unsigned long)__va((map_base + map_size) << PAGE_SHIFT));
+
+ return rc;
+}
+
/*
* Local variables:
* mode: C
diff -r bde0fd053306 -r a851239c01cb xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Fri Jan 16 13:34:36 2009 -0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Fri Jan 16 13:43:15 2009 -0800
@@ -28,6 +28,7 @@
#include <xen/pci.h>
#include <xen/pci_regs.h>
#include <asm/string.h>
+#include <asm/tboot.h>
#include "dmar.h"

int vtd_enabled = 1;
@@ -516,7 +517,9 @@ int acpi_dmar_init(void)
if ( !iommu_enabled )
goto fail;

- rc = acpi_table_parse(ACPI_SIG_DMAR, acpi_parse_dmar);
+ /* ACPI tables may not be DMA protected by tboot, so use DMAR copy */
+ /* SINIT saved in SinitMleData in TXT heap (which is DMA protected) */
+ rc = tboot_parse_dmar_table(acpi_parse_dmar);
if ( rc )
goto fail;

diff -r bde0fd053306 -r a851239c01cb xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Fri Jan 16 13:34:36 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Fri Jan 16 13:43:15 2009 -0800
@@ -37,7 +37,13 @@
#ifndef __TBOOT_H__
#define __TBOOT_H__

-typedef struct __attribute__ ((__packed__)) {
+#include <xen/acpi.h>
+
+#ifndef __packed
+#define __packed __attribute__ ((packed))
+#endif
+
+typedef struct __packed {
uint32_t data1;
uint16_t data2;
uint16_t data3;
@@ -47,7 +53,7 @@ typedef struct __attribute__ ((__packed_

/* used to communicate between tboot and the launched kernel (i.e. Xen) */

-typedef struct __attribute__ ((__packed__)) {
+typedef struct __packed {
uint16_t pm1a_cnt;
uint16_t pm1b_cnt;
uint16_t pm1a_evt;
@@ -56,7 +62,7 @@ typedef struct __attribute__ ((__packed_
uint16_t pm1b_cnt_val;
} tboot_acpi_sleep_info;

-typedef struct __attribute__ ((__packed__)) {
+typedef struct __packed {
/* version 0x01+ fields: */
uuid_t uuid; /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
uint32_t version; /* Version number: 0x01, 0x02, ... */
@@ -89,6 +95,7 @@ void tboot_probe(void);
void tboot_probe(void);
void tboot_shutdown(uint32_t shutdown_type);
int tboot_in_measured_env(void);
+int tboot_parse_dmar_table(acpi_table_handler dmar_handler);

/*
* TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
@@ -106,6 +113,27 @@ int tboot_in_measured_env(void);
#define TXTCR_HEAP_BASE 0x0300
#define TXTCR_HEAP_SIZE 0x0308

+#define SHA1_SIZE 20
+typedef uint8_t sha1_hash_t[SHA1_SIZE];
+
+typedef struct __packed {
+ uint32_t version; /* currently 6 */
+ sha1_hash_t bios_acm_id;
+ uint32_t edx_senter_flags;
+ uint64_t mseg_valid;
+ sha1_hash_t sinit_hash;
+ sha1_hash_t mle_hash;
+ sha1_hash_t stm_hash;
+ sha1_hash_t lcp_policy_hash;
+ uint32_t lcp_policy_control;
+ uint32_t rlp_wakeup_addr;
+ uint32_t reserved;
+ uint32_t num_mdrs;
+ uint32_t mdrs_off;
+ uint32_t num_vtd_dmars;
+ uint32_t vtd_dmars_off;
+} sinit_mle_data_t;
+
#define TXT_PROTMEM_RANGE_MAX 3
extern uint64_t txt_protmem_range_starts[TXT_PROTMEM_RANGE_MAX];
extern uint64_t txt_protmem_range_ends[TXT_PROTMEM_RANGE_MAX];

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-03-use_protected_dmar.patch (8K) Download Attachment

[PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0

2009-01-19T21:49:03Z

tboot no longer marks the TXT heap/SINIT/private config space as E820_UNUSABLE in the e820 table, so Xen must explicitly disallow those regions from dom0.

Signed-off-by: Shane Wang <shane.wang@...>
Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r 3d294dba4255 -r bde0fd053306 xen/arch/x86/domain_build.c
--- a/xen/arch/x86/domain_build.c Fri Jan 16 13:25:37 2009 -0800
+++ b/xen/arch/x86/domain_build.c Fri Jan 16 13:34:36 2009 -0800
@@ -29,6 +29,7 @@
#include <asm/paging.h>
#include <asm/p2m.h>
#include <asm/e820.h>
+#include <asm/tboot.h>

#include <public/version.h>

@@ -1038,6 +1039,20 @@ int __init construct_dom0(
rc |= iomem_deny_access(dom0, sfn, efn);
}

+ /* Remove access to TXT Heap/SINIT/Private Space. */
+ if ( tboot_in_measured_env() )
+ {
+ unsigned long sfn, efn;
+
+ for ( i = 0; i < ARRAY_SIZE(txt_protmem_range_starts); i++ )
+ {
+ sfn = paddr_to_pfn(txt_protmem_range_starts[i]);
+ efn = paddr_to_pfn(txt_protmem_range_ends[i]);
+ if ( sfn <= efn )
+ rc |= iomem_deny_access(dom0, sfn, efn);
+ }
+ }
+
BUG_ON(rc != 0);

return 0;
diff -r 3d294dba4255 -r bde0fd053306 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c Fri Jan 16 13:25:37 2009 -0800
+++ b/xen/arch/x86/mm.c Fri Jan 16 13:34:36 2009 -0800
@@ -109,6 +109,7 @@
#include <asm/e820.h>
#include <asm/hypercall.h>
#include <asm/shared.h>
+#include <asm/tboot.h>
#include <public/memory.h>
#include <xsm/xsm.h>
#include <xen/trace.h>
@@ -216,7 +217,7 @@ void __init arch_init_memory(void)
{
extern void subarch_init_memory(void);

- unsigned long i, pfn, rstart_pfn, rend_pfn, iostart_pfn, ioend_pfn;
+ unsigned long i, pfn, rstart_pfn, rend_pfn, iostart_pfn, ioend_pfn, j;

/*
* Initialise our DOMID_XEN domain.
@@ -279,6 +280,19 @@ void __init arch_init_memory(void)
for ( ; pfn < rstart_pfn; pfn++ )
{
BUG_ON(!mfn_valid(pfn));
+ /* Ensure the TXT ranges are not marked as I/O since that memory */
+ /* can't be used in dom0. */
+ if ( tboot_in_measured_env() )
+ {
+ for ( j = 0; j < ARRAY_SIZE(txt_protmem_range_starts); j++ )
+ {
+ if ( (PFN_DOWN(txt_protmem_range_starts[j]) <= pfn)
+ && (pfn <= PFN_DOWN(txt_protmem_range_ends[j])) )
+ break;
+ }
+ if ( j != ARRAY_SIZE(txt_protmem_range_starts) )
+ continue;
+ }
share_xen_page_with_guest(
mfn_to_page(pfn), dom_io, XENSHARE_writable);
}
diff -r 3d294dba4255 -r bde0fd053306 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c Fri Jan 16 13:25:37 2009 -0800
+++ b/xen/arch/x86/tboot.c Fri Jan 16 13:34:36 2009 -0800
@@ -15,12 +15,18 @@ string_param("tboot", opt_tboot);
/* Global pointer to shared data; NULL means no measured launch. */
tboot_shared_t *g_tboot_shared;

+/* TXT memory ranges which need to be protected from dom0 */
+uint64_t txt_protmem_range_starts[TXT_PROTMEM_RANGE_MAX];
+uint64_t txt_protmem_range_ends[TXT_PROTMEM_RANGE_MAX];
+
static const uuid_t tboot_shared_uuid = TBOOT_SHARED_UUID;

void __init tboot_probe(void)
{
tboot_shared_t *tboot_shared;
- unsigned long p_tboot_shared;
+ unsigned long p_tboot_shared, map_addr;
+ uint64_t base, size;
+ uint32_t map_base, map_size;

/* Look for valid page-aligned address for shared page. */
p_tboot_shared = simple_strtoul(opt_tboot, NULL, 0);
@@ -48,6 +54,34 @@ void __init tboot_probe(void)
printk(" tboot_base: 0x%08x\n", tboot_shared->tboot_base);
printk(" tboot_size: 0x%x\n", tboot_shared->tboot_size);
}
+
+ /* Get TXT heaps/SINIT/Private Space addresses. */
+ map_base = PFN_DOWN(TXT_PUB_CONFIG_REGS_BASE);
+ map_size = PFN_UP(NR_TXT_CONFIG_PAGES * PAGE_SIZE);
+
+ map_addr = (unsigned long)__va(map_base << PAGE_SHIFT);
+ if ( map_pages_to_xen(map_addr, map_base, map_size, __PAGE_HYPERVISOR) )
+ panic("Could not get TXT heaps/SINIT/Private Space addresses\n");
+
+ /* TXT Heap */
+ base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_BASE);
+ size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_HEAP_SIZE);
+ txt_protmem_range_starts[0] = base;
+ txt_protmem_range_ends[0] = base + size - 1;
+
+ /* SINIT */
+ base = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
+ size = *(uint64_t *)__va(TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
+ txt_protmem_range_starts[1] = base;
+ txt_protmem_range_ends[1] = base + size - 1;
+
+ /* TXT Private Space */
+ txt_protmem_range_starts[2] = TXT_PRIV_CONFIG_REGS_BASE;
+ txt_protmem_range_ends[2] = TXT_PRIV_CONFIG_REGS_BASE
+ + NR_TXT_CONFIG_PAGES * PAGE_SIZE - 1;
+
+ destroy_xen_mappings((unsigned long)__va(map_base << PAGE_SHIFT),
+ (unsigned long)__va((map_base + map_size) << PAGE_SHIFT));
}

void tboot_shutdown(uint32_t shutdown_type)
diff -r 3d294dba4255 -r bde0fd053306 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h Fri Jan 16 13:25:37 2009 -0800
+++ b/xen/include/asm-x86/tboot.h Fri Jan 16 13:34:36 2009 -0800
@@ -2,7 +2,7 @@
* tboot.h: shared data structure with MLE and kernel and functions
* used by kernel for runtime support
*
- * Copyright (c) 2006-2007, Intel Corporation
+ * Copyright (c) 2006-2009, Intel Corporation
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -90,6 +90,26 @@ void tboot_shutdown(uint32_t shutdown_ty
void tboot_shutdown(uint32_t shutdown_type);
int tboot_in_measured_env(void);

+/*
+ * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
+ */
+
+#define TXT_PUB_CONFIG_REGS_BASE 0xfed30000
+#define TXT_PRIV_CONFIG_REGS_BASE 0xfed20000
+
+/* # pages for each config regs space - used by fixmap */
+#define NR_TXT_CONFIG_PAGES ((TXT_PUB_CONFIG_REGS_BASE - \
+ TXT_PRIV_CONFIG_REGS_BASE) >> \
+ PAGE_SHIFT)
+#define TXTCR_SINIT_BASE 0x0270
+#define TXTCR_SINIT_SIZE 0x0278
+#define TXTCR_HEAP_BASE 0x0300
+#define TXTCR_HEAP_SIZE 0x0308
+
+#define TXT_PROTMEM_RANGE_MAX 3
+extern uint64_t txt_protmem_range_starts[TXT_PROTMEM_RANGE_MAX];
+extern uint64_t txt_protmem_range_ends[TXT_PROTMEM_RANGE_MAX];
+
#endif /* __TBOOT_H__ */

/*

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

xen-txt-02-protect_txt_ranges.patch (9K) Download Attachment

[PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

2009-01-19T21:48:46Z

On IA32 (32b/32b PAE) builds, set xen_phys_start (and by extension xenheap_phys_start) to be the start of hypervisor code (instead of 0). This reflects the actual trust/protection boundary of the hypervisor.

Signed-off-by: Joseph Cihula <joseph.cihula@...>

diff -r 8df3c145923f -r f96073a97f5c xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c Mon Jan 19 17:40:28 2009 +0000
+++ b/xen/arch/x86/setup.c Mon Jan 19 20:22:24 2009 -0800
@@ -843,7 +843,7 @@ void __init __start_xen(unsigned long mb
/* Initialise the Xen heap. */
init_xenheap_pages(xenheap_phys_start, xenheap_phys_end);
nr_pages = (xenheap_phys_end - xenheap_phys_start) >> PAGE_SHIFT;
- xenheap_phys_start = xen_phys_start;
+ xenheap_phys_start = xen_phys_start = __pa(&_start);
printk("Xen heap: %luMB (%lukB)\n",
nr_pages >> (20 - PAGE_SHIFT),
nr_pages << (PAGE_SHIFT - 10));

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

[PATCH] txt: 0/6 - Overview

2009-01-19T21:48:25Z

This patch series are changes to Xen to support new functionality, and a changed API, in the tboot project (see http://sourceforge.net/projects/tboot for more info about tboot). Some of these changes originated from comments received when the first set of Linux tboot/Intel(r) TXT patches were posted to LKML.

Attached to this patch is a single patch to be applied to the current tip of the tboot source tree (located at http://www.bughost.org/repos.hg/tboot.hg). Due to the API change, for those who wish to test the patches, it would be best to apply all of the tboot patch at once and test with all of the Xen patches applied to Xen.

Since the API changes are not backwards compatible, the resulting tboot will not work with a Xen that does not have the patches applied. Likewise, a Xen with these patches applied will not work with the un-patched tboot. To keep backward compatibility would have left the interface and code fairly ugly and didn't seem worth the trouble.

The Xen patches are as follows:

xen-txt-01-xen_phys_addr_start_fix.patch - "fix" xen_phys_start for 32b builds
xen-txt-02-protect_txt_ranges.patch - explicitly protect TXT addr ranges from dom0
xen-txt-03-use_protected_dmar.patch - use TXT's DMA-protected DMAR table to setup VT-d
xen-txt-04-acpi_gas_support.patch - ACPI Generic Address Structure for tboot shutdown
xen-txt-05-unified_shutdown_entry.patch - single tboot entry point for shutdown
xen-txt-06-hypervisor_s3_integrity.patch - hypervisor integrity on S3

We are currently working on a patch that will extend the S3 integrity to domains, as configurable via a domain's config file (and always for dom0).

The patches apply cleanly to the latest xen-unstable.

Joe and Shane

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

tboot-latest.patch (251K) Download Attachment

Question about XSM-ACM XSM-FLASK differences

2009-01-16T01:07:56Z

Hi,

I have a question about XSM-ACM(sHype) and XSM-FLASK difference.
These two are based on Flask model.
So I wan to know the difference of these two.

Is this is only a implementation difference?
(like a policy description format etc.)

Or any other difference exists?

I think XSM-FLASK policy format is same as SELinux one.
But Security Server is splited between Linux/Xen.
In this situation,
it looks same XSM-ACM and XSM-FLASKin a view from Security Server.

If this discussion is already done,
Please suggest me a pointer.

Thanks
Atsushi SAKAI

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Intercepting memory operations of a guest

2008-12-07T17:57:26Z

Hi all,

Sorry for any cross posting. I sent this to the xen-devel list and the
xen-research list as well.

I'm wanting to modify some xen source code for the purposes of some
research, exploration, and testing of some security concepts.

I have a few questions after looking through the source.

All of the below applies to 32-bit guests.

#1: Is there anyway possible to trap/insert some code at/hook into, any
modification of a PV guest's page table. Anything like a hypercall handler I
can plugin to, a function or series of functions that always gets called,
something I can provide a call back to, or anything else?

#2: For some research purposes, I plan on replicating portions of the page
table of a guest, only those pages of the guest's kernel. I hope to do this
by the supervisory bit being set; however, I welcome any suggestions of a
better approach to detecting when kernel pages are being modified?

In general, to explain any questions I haven't specifically asked above; I'm
looking for the appropriate place in xen to intercept any writes, reads, and
executes of a guest's memory.

Also, would such activities be easier or more difficult with hvm guests?
Since xen has to provide hvm guests an individual CR3, would such a place be
much easier to hook into because of any abstraction layers that already
exist for such things?

The only reason I picked pv guests was that the semantics of what is a
kernel page and what is not might not be as easy to determine in an hvm
guest, but perhaps this is not the case?

Thanks for any assistance.

Take care,
Sina

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

tboot backwards compatiblity with Xen

2008-10-13T11:24:16Z

Based on some feedback from the recent Linux posting of the tboot/TXT
patches as well as some enhancements that we've been looking at for
tboot, there are some changes that we'd like to make to tboot that would
not be backwards compatible with the existing Xen code. Naturally, we'd
submit patches for Xen, but existing versions (e.g. 3.2, 3.3) would not
work with the new tboot.

The question I pose to those who use tboot with Xen is: how important
is it that new versions of tboot continue to work with older versions of
Xen?

Joe

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

how to log keyboard events of domainU?

2008-09-16T17:02:12Z

hi, Sorry to bother you.
I want to know how to log keyboard events of a domainU.
thanks

PoC of Covert Channel

2008-07-23T10:19:20Z

Hi all,
I created a proof of concept to communicate between guests (inside
dom0 or domU) in a Xen environment. You need to have kernel rights
(hypercalls are needed).
It use the machine-to-physical table to store informations. This table
is readable for all guests and writable for the part's guest. The
principle is simple: write a tag and your data instead of addresses.
Other guests can read what you wrote and extract data. An half-duplex
channel can be created to share information between OS (Linux 2.6
x86-32 for now).

This PoC is not a new idea[1] but a practical issue. This one bypass
the Xen Policy checks as knew by developers[2].

The machine-to-physical table is really good for the performance
mapping but it would be a good idea to have one table for each guest
and protect it. I think it is not a big problem, it can be fast
(memory size and switch time). Another solution is to use a full
shadow page tables, but with a lower speed if it is a software
translation. If it is done like this, my PoC will be unusable. It will
also be good to prevent other guests to read the table and infer (with
Xen interrupts) a (basic) map of the physically mapped memory.

The code is a device driver who create /dev/xencc. The communication
protocol is based on tags. You need a different tag for each guest
(look at the source and change it for the second guest). For now, you
can only communicate between two guests. If you have not udev install
on your system, the device will not be created when you insert the
specific module[3]. In this case you need to create it by hand[4].
You can write[5] and read[6]. If you are risky you can change the
limit buffer size in the source. The channel bandwidth seams to be
good because it use an hypercall (mmu_update) to copy an entire range
of data at the same time. The drawback of this method is the consuming
memory. We are allocating addresses instead of 4 bytes (in x86-32
architecture), so we need to transmit data step-by-step. With a good
scheduling you can have a quick channel.

This is an unstable version, use it with caution!

Best regards,
Mickaël Salaün

1. http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xense-devel&i=003501c63303%245209cbd0%241c02000a%40Myong1
2. http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xen-devel&i=39CC97884CA19A4D8D6296FE94357BCB019EB0B2%40swsmsx404
3. insmod xencc.ko
4. mknod /dev/xencc c `grep misc /proc/devices | awk '{print $1}'`
`grep xencc /proc/misc | awk '{print $1}'`
5. echo your msg > /dev/xencc
6. dd if=/dev/xencc count=1

[xencc.c]

#include <linux/module.h> #include <linux/miscdevice.h> #include <linux/uaccess.h> #include <linux/mm.h> /* XenCC v0.1 (07/2008) Copyright (C) 2008 MickaÃ«l SalaÃ¼n This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ #define DEV_NAME "xencc" MODULE_LICENSE("GPL"); MODULE_AUTHOR ("MickaÃ«l SalaÃ¼n"); MODULE_DESCRIPTION ("Create /dev/" DEV_NAME " to communicate with an other guest through a Xen covert channel."); // comment this for the second guest ! #define XENCC_ME_FIRST // better with @ > PAGE_SHIFT bits (but not tactful) #define XENCC_TAGS_1 {123456, 13641, 1616} #define XENCC_TAGS_2 {151651, 1416, 469564} // same dom (test): //#define XENCC_TAGS_2 XENCC_TAGS_1 #ifdef XENCC_ME_FIRST #define XENCC_TAGS_A XENCC_TAGS_1 #define XENCC_TAGS_B XENCC_TAGS_2 #define XENCC_ME 1 #define XENCC_OTH 2 #else #define XENCC_TAGS_A XENCC_TAGS_2 #define XENCC_TAGS_B XENCC_TAGS_1 #define XENCC_ME 2 #define XENCC_OTH 1 #endif #define XENCC_DATA_SIZE 256 #define XENCC_VALINIT 0 #define MFN_START 0 #define MFN_END 0x00400000 // 4Mo = 2^22 //#define MSG_TYPE_HEXA #if defined(__i386__) #define ADDR_LENGTH sizeof(unsigned long) #else #error "Unsupported architecture" #endif static unsigned char xencc_data[XENCC_DATA_SIZE] = ""; static unsigned int xencc_data_size; static struct page *xencc_pages; static int xencc_pages_nb; static void *mfn_old; static int mfn_old_size; // other's tags static unsigned long pfn_oth_header_tag[] = XENCC_TAGS_A; #define PFN_OTH_HEADER_TAG_SIZE (sizeof(pfn_oth_header_tag) / ADDR_LENGTH) // our's tags static unsigned long pfn_my_header_tag[] = XENCC_TAGS_B; #define PFN_MY_HEADER_TAG_SIZE (sizeof(pfn_my_header_tag) / ADDR_LENGTH) #define PFN_MY_HEADER_SIZE (1 + sizeof(pfn_my_header_tag) / ADDR_LENGTH) #define DBG(...) printk(KERN_DEBUG DEV_NAME " " __VA_ARGS__); static int xencc_open(struct inode *inode, struct file *filp) { DBG("open\n"); return 0; } static int xencc_release(struct inode *inode, struct file *filp) { DBG("release\n"); return 0; } static void *allocate_mfn(unsigned int nb_pages) { int order; void *pt; for(order = 0; nb_pages > 0; order++) nb_pages >>= 1; DBG("order: %d\n", order); pt = (void *)alloc_pages(GFP_KERNEL | __GFP_REPEAT | __GFP_ZERO, order); xencc_pages = (struct page *)pt; xencc_pages_nb = order; DBG("alloc_pages: %p\n", pt); pt = (void *)page_to_pfn((struct page *)pt); if(pt == NULL) // ? { printk(KERN_ALERT DEV_NAME " %s[%d]: page allocation failed\n", __FUNCTION__, __LINE__); return NULL; } DBG("page_to_pfn: %p\n", pt); pt = (void *)pfn_to_mfn((unsigned long)pt); DBG("pfn_to_mfn: %p\n", pt); return pt; } static void mfn_cc_clean(void) { int i, nb_success; mmu_update_t upd[mfn_old_size]; DBG("clean\n"); if(mfn_old_size != 0) { DBG("mfn_old: %p\n", mfn_old); DBG("mfn_old_size: %d\n", mfn_old_size); for(i = 0; i < mfn_old_size; i++) { upd[i].ptr = (((unsigned long)mfn_old + i) << PAGE_SHIFT) | MMU_MACHPHYS_UPDATE; upd[i].val = XENCC_VALINIT; } HYPERVISOR_mmu_update(upd, mfn_old_size, &nb_success, DOMID_SELF); if(nb_success != mfn_old_size) { printk(KERN_ALERT DEV_NAME " %s[%d]: clean failed (%d)\n", __FUNCTION__, __LINE__, nb_success); } mfn_old_size = 0; } if(xencc_pages_nb != 0) { DBG("free %p (%d)\n", xencc_pages, xencc_pages_nb); __free_pages(xencc_pages, xencc_pages_nb); xencc_pages_nb = 0; } } // MFN Cover Channel Write static unsigned long *mfn_cc_write(unsigned char *data, unsigned long size) { int nb_success, i, j, max = PFN_MY_HEADER_SIZE + size / ADDR_LENGTH + ((size % ADDR_LENGTH) ? 1 : 0); mmu_update_t upd[max]; void *mfn; DBG("write to guest %d\n", XENCC_OTH); mfn_cc_clean(); mfn = allocate_mfn(max); DBG("allocate_mfn : %p\n", mfn); for(i = 0; i < max; i++) { upd[i].ptr = (((unsigned long)mfn + i) << PAGE_SHIFT) | MMU_MACHPHYS_UPDATE; if(i < PFN_MY_HEADER_TAG_SIZE) upd[i].val = pfn_my_header_tag[i]; else if(i == PFN_MY_HEADER_TAG_SIZE) upd[i].val = size; else { upd[i].val = 0; /////// for(j = 0; j < ADDR_LENGTH && (i - PFN_MY_HEADER_SIZE) * ADDR_LENGTH + j < size; j++) upd[i].val += (data[(i - PFN_MY_HEADER_SIZE) * ADDR_LENGTH + j]) << (j * 8); // little-endian } DBG("pfn%d: %08x -> %08x\n", i, (unsigned int)upd[i].ptr && !MMU_MACHPHYS_UPDATE, (unsigned int)upd[i].val); } HYPERVISOR_mmu_update(upd, max, &nb_success, DOMID_SELF); mfn_old = mfn; mfn_old_size = nb_success; DBG("nb_success: %d\n", nb_success); if(nb_success != max) return NULL; return mfn; } #define PFN_EXTRACT(pfn, nb) (unsigned char)(pfn >> (nb * 8)) static int pfn_tag_find(start_info_t *si) { char find = 0, i; int ret = 0; unsigned long mfn, pfn, end = MFN_END, size = 0, tag_id = 0; xencc_data_size = 0; for(mfn = MFN_START; mfn < end; mfn++) { pfn = mfn_to_pfn(mfn); if(!find && pfn == pfn_oth_header_tag[tag_id]) { DBG("mfn %p : %p (%d)\n", (void *)mfn, (void *)pfn, (int)tag_id); if(tag_id == PFN_OTH_HEADER_TAG_SIZE - 1) find = 1; else tag_id++; } else { switch(find) { case 0: tag_id = 0; break; case 1: DBG("tag trouvÃ© !\n"); size = pfn; end = mfn + 1 + size / ADDR_LENGTH + ((size % ADDR_LENGTH) ? 1 : 0); find++; break; case 2: ret = 1; if(size >= ADDR_LENGTH) { #ifdef MSG_TYPE_HEXA if(xencc_data_size + ADDR_LENGTH * 4 <= XENCC_DATA_SIZE) { snprintf(xencc_data + xencc_data_size, XENCC_DATA_SIZE - xencc_data_size, "\\x%02x\\x%02x\\x%02x\\x%02x", PFN_EXTRACT(pfn, 0), PFN_EXTRACT(pfn, 1), PFN_EXTRACT(pfn, 2), PFN_EXTRACT(pfn, 3)); xencc_data_size += ADDR_LENGTH * 4; } #else if(xencc_data_size + ADDR_LENGTH <= XENCC_DATA_SIZE) { *(unsigned long *)(xencc_data + xencc_data_size) = pfn; xencc_data_size += ADDR_LENGTH; } #endif size -= ADDR_LENGTH; } else { for(i = 0; size > 0 && i < ADDR_LENGTH; i++, size--) { #ifdef MSG_TYPE_HEXA if(xencc_data_size + 4 <= XENCC_DATA_SIZE) { snprintf(xencc_data + xencc_data_size, XENCC_DATA_SIZE - xencc_data_size, "\\x%02x", PFN_EXTRACT(pfn, i)); xencc_data_size += 4; } #else if(xencc_data_size + 1 <= XENCC_DATA_SIZE) { xencc_data[xencc_data_size] = PFN_EXTRACT(pfn, i); xencc_data_size++; } #endif } } break; } } } return ret; } static ssize_t xencc_read(struct file *filep, char *buff, size_t count, loff_t *offp ) { DBG("read from guest %d\n", XENCC_OTH); pfn_tag_find((start_info_t *)xen_start_info); if(copy_to_user(buff, xencc_data, xencc_data_size) != 0) { printk(KERN_ALERT DEV_NAME " %s[%d]: kernel -> userspace copy failed\n", __FUNCTION__, __LINE__); return -EINVAL; } return xencc_data_size; } static ssize_t xencc_write(struct file *filep, const char *buff, size_t count, loff_t *offp ) { void *mfn; if(count >= sizeof(xencc_data) || copy_from_user(xencc_data, buff, count) != 0) { printk(KERN_ALERT DEV_NAME " %s[%d]: userspace -> kernel copy failed\n", __FUNCTION__, __LINE__); return -EINVAL; } mfn = mfn_cc_write((unsigned char *)xencc_data, count); if(mfn == NULL) { mfn_cc_clean(); // pas forcÃ©ment contigue... printk(KERN_ALERT DEV_NAME " %s[%d]: MFN copy failed\n", __FUNCTION__, __LINE__); return -EINVAL; } DBG("write\n"); return count; } static struct file_operations xencc_fops = { .owner = THIS_MODULE, .read = xencc_read, .write = xencc_write, .open = xencc_open, .release = xencc_release, }; static struct miscdevice xencc_dev = { .minor = MISC_DYNAMIC_MINOR, .name = DEV_NAME, .fops = &xencc_fops, }; static int xencc_init(void) { int ret = 0; xencc_data[XENCC_DATA_SIZE - 1] = 0; ret = misc_register(&xencc_dev); if(ret) { printk(KERN_ALERT DEV_NAME " %s[%d]: unable to register device (%d)\n", __FUNCTION__, __LINE__, ret); return ret; } DBG("loaded guest %d\n", XENCC_ME); xencc_pages_nb = 0; mfn_old_size = 0; return 0; } static void xencc_exit(void) { if(misc_deregister(&xencc_dev)) printk(KERN_ALERT DEV_NAME " %s[%d]: unable to unregister device\n", __FUNCTION__, __LINE__); mfn_cc_clean(); DBG("unloaded\n"); } module_init(xencc_init); module_exit(xencc_exit);

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Makefile (266 bytes) Download Attachment

PoC of Covert Channel

2008-07-23T09:30:00Z

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Makefile (266 bytes) Download Attachment

XSM hooks and privileges

2008-07-15T20:40:02Z

Hi,

What is the relation between the placement of XSM hooks and the macros IS_PRIV and IS_PRIV_FOR? Is there any redundancy?

Thanks,
Hayawardh

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Re: Labeling in XSM/Flask

2008-07-08T14:23:31Z

I¹ve managed to reproduce a problem like the one you describe....I think it
is the same problem that you are having. The patch was missing a critical
file (xsm.py). This file used to be autogenerated and so an entry had been
made in .hgignore to avoid unintended commits of this file. A side effect
of this was that my changes to xsm.py were not picked up by mercurial and
included in the patch. xsm.py is no longer autogenerated but instead relies
on the xsm_module_name option in xend-config. The options for
xsm_module_name are dummy, acm, or flask.

I¹ve attached an updated patch that addresses this issue. To make sure you
don¹t have any cruft in your installation, blow away
/usr/lib/python/xen/util/xsm before performing a make install of the python
tools. Also make sure that your xend-config.sxp contains the following
entry,

(xsm_module_name flask)

The example configs have been updated with this option keyword but it is
commented out and the default is dummy.

Sorry for the broken patch. I¹ve got some policy work to do tomorrow before
I cut this patch loose for submission. Perhaps you can give me insight into
your hardware/system config because I¹ve been unable to reproduce this
issue.

> 4. When dom0 boots, there is a denial :
>>> > (XEN) avc: denied { firmware } for domid=0
>>> > (XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
>>> > (XEN) tclass=xen

George

On 7/7/08 11:24 PM, "Hayawardh V" <hayawardh@...> wrote:

>
>
> On Mon, Jul 7, 2008 at 1:22 PM, George S. Coker, II <gscoker@...>
> wrote:
>>
>>
>>
>> On 7/4/08 5:11 PM, "Hayawardh V" <hayawardh@...> wrote:
>>
>>> Hi George,
>>>
>>> I applied the patch update-xsm-061908-xen-17826.diff to Xen and specified
>>> (xsm_module_name flask)
>>>
>>> in xend-config.
>>>
>>> I am now able to boot into dom0 in enforcing mode.
>>>
>>> However, when I boot a domU, it has not been labeled, and does not create.
>>>
>>> 1. How do I add labels to objects in XSM/Flask? Where will the labels be
>>> stored (like SELinux stores them in extended attributes in the file system)
>>> ?
>>>
>>
>> Labels are managed through the individual domain configuration files. Add
>> the following attribute to a domU config file,
>>
>> access_control = [³policy=,label=system_u:object_r:domU_t²]
>>
>> domU_t is a valid type in the sample policy. You can modify the policy to
>> add new types and use them accordingly.
>>
>> An attribute in the config file is the closest thing that we have today to
>> an extended attribute for domains. This approach has minimized the amount
>> of integration between the guest security and hypervisor security systems
>> but at the cost of reducing the guarantees that can be made over the doamin
>> security attributes. Closer integration with the guest or dom0 security
>> environment would allow the platform security to be independent of domain
>> configuration files and separate protection of the security attributes from
>> the configuration data. There may be other config attributes that can
>> effect the platform security, so my comments here are limited to the scope
>> of the access_control attribute.
>>
>>> 2. The avc denial when I try to boot a domU is:
>>> (XEN) avc: denied { create } for domid=0
>>> (XEN) scontext=system_u:system_r:dom0_t
>>> tcontext=system_u:system_r:unlabeled_t
>>> (XEN) tclass=domain
>>>
>>> (It has type unlabeled_t).
>>>
>>
>> This should be fixed by following my response to item 1. Let me know
>> because this would indicate something else is wrong.
>
> Thanks for this, but my config file has exactly the same line:
> kernel = "/boot/vmlinuz-2.6.18.8-xen"
> ramdisk = "/boot/initrd-2.6.18.8-xen.img"
> ...
> disk = ['file:/xen/fedora/fedora.fc8.img,sda1,w',
> 'file:/xen/fedora/fedora.swap,sda2,w',
> 'file:/xen/fedora/fedora.fc8.additional_disk,sda3,w']
> root = "/dev/sda1 ro"
> access_control = [ 'policy=,label=system_u:object_r:domU_t' ]
>
> However, the denial still shows up. Where else could I be wrong?
>
>
>>
>>> 3. Should the initial context have been system_u:system_r:xen_t? If yes, how
>>> did it transition to system_u:system_r:dom0_t?
>>>
>>
>> This is correct. There currently isn't support for a domain transition ala
>> SELinux, but that functionality will be forthcoming.
>>
>> Because the initial behavior of the hypervisor is hard coded to create Dom0,
>> the system is built on a small collection of initial sids and a few core
>> policy statements designed to support getting Dom0 up and running in working
>> order.
>>
>> The initial sids are xen_t for the hypervisor and dom0_t for the first guest
>> (in this case, Dom0). The setting of the sid for the hypervisor is hard
>> coded in flask_domain_alloc_security and so is the sid for dom0_t through
>> the implicit behavior of hypervisor under xen_t.
>>
>>> 4. When dom0 boots, there is a denial :
>>> (XEN) avc: denied { firmware } for domid=0
>>> (XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
>>> (XEN) tclass=xen
>>>
>>
>> This is probably a platform policy nit and now that I'm back in the office I
>> should be able to sort this out.
>>
>>> Thanks and regards,
>>> Hayawardh
>>>
>>>
>>>
>>> _______________________________________________
>>> Xense-devel mailing list
>>> Xense-devel@...
>>> http://lists.xensource.com/xense-devel
>>
>>
>> --
>> George S. Coker, II <gscoker@...>
>>
>>
>
>

--
George S. Coker, II <gscoker@...>

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

update-xsm-070808-xen-17826.diff (176K) Download Attachment

Re: Labeling in XSM/Flask

2008-07-07T10:22:14Z

On 7/4/08 5:11 PM, "Hayawardh V" <hayawardh@...> wrote:

> Hi George,
>
> I applied the patch update-xsm-061908-xen-17826.diff to Xen and specified
> (xsm_module_name flask)
>
> in xend-config.
>
> I am now able to boot into dom0 in enforcing mode.
>
> However, when I boot a domU, it has not been labeled, and does not create.
>
> 1. How do I add labels to objects in XSM/Flask? Where will the labels be
> stored (like SELinux stores them in extended attributes in the file system) ?
>

Labels are managed through the individual domain configuration files. Add
the following attribute to a domU config file,

access_control = [³policy=,label=system_u:object_r:domU_t²]

domU_t is a valid type in the sample policy. You can modify the policy to
add new types and use them accordingly.

An attribute in the config file is the closest thing that we have today to
an extended attribute for domains. This approach has minimized the amount
of integration between the guest security and hypervisor security systems
but at the cost of reducing the guarantees that can be made over the doamin
security attributes. Closer integration with the guest or dom0 security
environment would allow the platform security to be independent of domain
configuration files and separate protection of the security attributes from
the configuration data. There may be other config attributes that can
effect the platform security, so my comments here are limited to the scope
of the access_control attribute.

> 2. The avc denial when I try to boot a domU is:
> (XEN) avc: denied { create } for domid=0
> (XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:unlabeled_t
> (XEN) tclass=domain
>
> (It has type unlabeled_t).
>

This should be fixed by following my response to item 1. Let me know
because this would indicate something else is wrong.

> 3. Should the initial context have been system_u:system_r:xen_t? If yes, how
> did it transition to system_u:system_r:dom0_t?
>

This is correct. There currently isn't support for a domain transition ala
SELinux, but that functionality will be forthcoming.

Because the initial behavior of the hypervisor is hard coded to create Dom0,
the system is built on a small collection of initial sids and a few core
policy statements designed to support getting Dom0 up and running in working
order.

The initial sids are xen_t for the hypervisor and dom0_t for the first guest
(in this case, Dom0). The setting of the sid for the hypervisor is hard
coded in flask_domain_alloc_security and so is the sid for dom0_t through
the implicit behavior of hypervisor under xen_t.

> 4. When dom0 boots, there is a denial :
> (XEN) avc: denied { firmware } for domid=0
> (XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
> (XEN) tclass=xen
>

This is probably a platform policy nit and now that I'm back in the office I
should be able to sort this out.

> Thanks and regards,
> Hayawardh
>
>
>
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@...
> http://lists.xensource.com/xense-devel

--
George S. Coker, II <gscoker@...>

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Source code release for Xen on ARM and the associated access control (Secure Xen on ARM)

2008-07-07T03:39:32Z

Samsung Enterprise Portal mySingle Dear Xen developers,

Please allow me to introduce myself. I am Sang-bum Suh who is

responsible for Secure Xen on ARM project in Samsung Electronics.

FYI, This is a copy of email sent to xen-community mail subscribers on 4th of July 2008.

I am happy to announce the release of source code for Secure Xen on ARM again by Xen mailing list.

This announcement was officially made in Xen Summit North America 2008 last week in Boston.

Secure Xen on ARM consists of Xen on ARM hypervisor, and the associated access control.

This release includes mini-OS.

I will do my best as the Xen-ARM maintainer and do release para-virtualized Linux by Q4 2008

after cleaning the source code as shown in roadmap.

Welcome Xen developers who are interested in making contributions to Secure Xen on ARM !

Please see at wiki.xensource.com/xenwiki/XenARM.

Cheers,

Sang-bum

------- Original Message -------
Sender : Sang-bum Suh<sbuk.suh@...> R&D Staff Member/Graphics&OS Group/Samsung Electronics
Date : 2008-07-04 00:06 (GMT+09:00)
Title : Source code release for Secure Xen on ARM

Dear Xen community members,

Please allow me to introduce myself. I am Sang-bum Suh who is

responsible for Secure Xen on ARM project in Samsung Electronics.

I am happy to announce the release of source code for Secure Xen on ARM again by Xen mailing list.

This announcement was officially made in Xen Summit North America 2008 last week in Boston.

Secure Xen on ARM consists of Xen on ARM hypervisor, the associated access control. This release

includes mini-OS.

Welcome Xen developers who are interested in making contributions to Secure Xen on ARM !

Please see at wiki.xensource.com/xenwiki/XenARM.

Cheers,

Sang-bum

===============================================================

Sang-bum Suh, PhD

Virtualization Project Lead, Principal Engineer

Graphics & OS Group, Software Lab

SAIT, Samsung Electronics

email: sbuk.suh@...

Mobile: 82-(0)11-1704-5722

===============================================================

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Labeling in XSM/Flask

2008-07-04T14:11:25Z

Hi George,

I applied the patch update-xsm-061908-xen-17826.diff to Xen and specified
(xsm_module_name flask)

in xend-config.

I am now able to boot into dom0 in enforcing mode.

However, when I boot a domU, it has not been labeled, and does not create.

1. How do I add labels to objects in XSM/Flask? Where will the labels be stored (like SELinux stores them in extended attributes in the file system) ?

2. The avc denial when I try to boot a domU is:
(XEN) avc: denied { create } for domid=0
(XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:unlabeled_t
(XEN) tclass=domain

(It has type unlabeled_t).

3. Should the initial context have been system_u:system_r:xen_t? If yes, how did it transition to system_u:system_r:dom0_t?

4. When dom0 boots, there is a denial :
(XEN) avc: denied { firmware } for domid=0
(XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
(XEN) tclass=xen

Thanks and regards,
Hayawardh

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Re: Question about IBM VTPM Commands

2008-06-10T03:55:02Z

Hi, Stefan

Thank you for your quick reply.

I am wondering to see the page in this timing,
since the specification is not marged to the TPM specification.
I hope that vTPM specification is marged in near future.

Thanks
Atsushi SAKAI

Stefan Berger <stefanb@...> wrote:

> xense-devel-bounces@... wrote on 06/10/2008 02:25:50 AM:
>
> > Hi,
> >
> > I am just looking around the VTPM page.(see follows)
> > And I found Virtual TPM migration specification exists.
> > But, I cannot found this TPM specification on TCG(Trusted Computing
> > Group) page.
> > Is this specification is working or not?
>
> It's not an official TCG specification. However, it is working.
>
> Stefan
>
> >
> > http://domino.research.ibm.com/comm/research_projects.
> > nsf/pages/ssd_vtpm.index.html
> >
> > I see around TPM page and Virtualization page.
> > https://www.trustedcomputinggroup.org/
> >
> > Thanks
> > Atsushi SAKAI
> >
> >
> >
> > _______________________________________________
> > Xense-devel mailing list
> > Xense-devel@...
> > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Re: Question about IBM VTPM Commands

2008-06-10T03:15:46Z

xense-devel-bounces@... wrote on 06/10/2008 02:25:50 AM: > Hi, > > I am just looking around the VTPM page.(see follows) > And I found Virtual TPM migration specification exists. > But, I cannot found this TPM specification on TCG(Trusted Computing > Group) page. > Is this specification is working or not?

It's not an official TCG specification. However, it is working.

Stefan
> > http://domino.research.ibm.com/comm/research_projects. > nsf/pages/ssd_vtpm.index.html > > I see around TPM page and Virtualization page. > https://www.trustedcomputinggroup.org/ > > Thanks > Atsushi SAKAI > > > > _______________________________________________ > Xense-devel mailing list > Xense-devel@... > http://lists.xensource.com/xense-devel
_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel

Question about IBM VTPM Commands

2008-06-09T23:25:50Z

Hi,

I am just looking around the VTPM page.(see follows)
And I found Virtual TPM migration specification exists.
But, I cannot found this TPM specification on TCG(Trusted Computing Group) page.
Is this specification is working or not?

http://domino.research.ibm.com/comm/research_projects.nsf/pages/ssd_vtpm.index.html

I see around TPM page and Virtualization page.
https://www.trustedcomputinggroup.org/

Thanks
Atsushi SAKAI

_______________________________________________
Xense-devel mailing list
Xense-devel@...
http://lists.xensource.com/xense-devel