Re: [tboot-devel] Add support for TPM2 TCG log format

[Sun, Ning]

Thanks for the patch, it was validated and merged…

Br.
-Ning

From: Sahil Rihan [mailto:sri...@fb.com]
Sent: Monday, May 14, 2018 3:37 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Add support for TPM2 TCG log format

Tboot didn’t have support for appending to a TPM2 TCG style event log. As a 
result it would crash with a “generic fatal error” when it ran with an SINIT 
that supports the TCG log format.

This change addresses that by adding code to handle the new log format.

Testing done: Verify tboot crashes on Skylake system without patch, and 
successfully boots kernel with the patch.

Signed-off-by: Sahil Rihan >

diff -r 57c7d147daec -r 8bcaa41a5769 tboot/txt/txt.c
--- a/tboot/txt/txt.c   Fri May 04 17:10:58 2018 -0700
+++ b/tboot/txt/txt.c   Mon May 14 15:26:18 2018 -0700
@@ -69,6 +69,12 @@
/* counter timeout for waiting for all APs to enter wait-for-sipi */
#define AP_WFS_TIMEOUT 0x1000

+/* TPM event log types */
+#define EVTLOG_UNKNOWN   0
+#define EVTLOG_TPM12 1
+#define EVTLOG_TPM2_LEGACY   2
+#define EVTLOG_TPM2_TCG  3
+
__data struct acpi_rsdp g_rsdp;
extern char _start[]; /* start of module */
extern char _end[];   /* end of module */
@@ -87,6 +93,7 @@
extern void cpu_wakeup(uint32_t cpuid, uint32_t sipi_vec);
extern void print_event(const tpm12_pcr_event_t *evt);
extern void print_event_2(void *evt, uint16_t alg);
+extern uint32_t print_event_2_1(void *evt);


/*
@@ -282,6 +289,26 @@
 }
}

+int get_evtlog_type(void)
+{
+struct tpm_if *tpm = get_tpm();
+
+if (tpm->major == TPM12_VER_MAJOR) {
+return EVTLOG_TPM12;
+} else if (tpm->major == TPM20_VER_MAJOR) {
+if (g_sinit) {
+txt_caps_t sinit_caps = get_sinit_capabilities(g_sinit);
+return sinit_caps.tcg_event_log_format ? EVTLOG_TPM2_TCG : 
EVTLOG_TPM2_LEGACY;
+} else {
+printk(TBOOT_ERR"SINIT not found\n");
+}
+} else {
+printk(TBOOT_ERR"Unknown TPM major version: %d\n", tpm->major);
+}
+printk(TBOOT_ERR"Unable to determine log type\n");
+return EVTLOG_UNKNOWN;
+}
+
static void init_os_sinit_ext_data(heap_ext_data_element_t* elts)
{
 heap_ext_data_element_t* elt = elts;
@@ -391,7 +418,7 @@
 }
}

-bool evtlog_append_tpm20(uint8_t pcr, uint16_t alg, tb_hash_t *hash, uint32_t 
type)
+bool evtlog_append_tpm2_legacy(uint8_t pcr, uint16_t alg, tb_hash_t *hash, 
uint32_t type)
{
 heap_event_log_descr_t *cur_desc = NULL;
 uint32_t hash_size;
@@ -428,21 +455,79 @@
 return true;
}

+bool evtlog_append_tpm2_tcg(uint8_t pcr, uint32_t type, hash_list_t *hl)
+{
+uint32_t i, event_size;
+unsigned int hash_size;
+tcg_pcr_event2 *event;
+uint8_t *hash_entry;
+tcg_pcr_event2 dummy;
+
+/*
+ * Dont't use sizeof(tcg_pcr_event2) since that has 
TPML_DIGESTV_VALUES_1.digests
+ * set to 5. Compute the static size as pcr_index + event_type +
+ * digest.count + event_size. Then add the space taken up by the hashes.
+ */
+event_size = sizeof(dummy.pcr_index) + sizeof(dummy.event_type) +
+sizeof(dummy.digest.count) + sizeof(dummy.event_size);
+
+for (i = 0; i < hl->count; i++) {
+hash_size = get_hash_size(hl->entries[i].alg);
+if (hash_size == 0) {
+return false;
+}
+event_size += sizeof(uint16_t); // hash_alg field
+event_size += hash_size;
+}
+
+// Check if event will fit in buffer.
+if (event_size + g_elog_2_1->next_record_offset >
+g_elog_2_1->allcoated_event_container_size) {
+return false;
+}
+
+event = (tcg_pcr_event2*)(void *)(unsigned long)g_elog_2_1->phys_addr +
+g_elog_2_1->next_record_offset;
+event->pcr_index = pcr;
+event->event_type = type;
+event->event_size = 0;  // No event data passed by tboot.
+event->digest.count = hl->count;
+
+hash_entry = (uint8_t *)>digest.digests[0];
+for (i = 0; i < hl->count; i++) {
+// Populate individual TPMT_HA_1 structs.
+*((uint16_t *)hash_entry) = hl->entries[i].alg; // TPMT_HA_1.hash_alg
+hash_entry += sizeof(uint16_t);
+hash_size = get_hash_size(hl->entries[i].alg);  // already checked 
above
+memcpy(hash_entry, &(hl->entries[i].hash), hash_size);
+hash_entry += hash_size;
+}
+
+g_elog_2_1->next_record_offset += event_size;
+print_event_2_1(event);
+return true;
+}
+
+
bool evtlog_append(uint8_t pcr, hash_list_t *hl, uint32_t type)
{
-struct tpm_if *tpm = get_tpm();
-switch (tpm->major) {
-case TPM12_VER_MAJOR:
+int log_type = get_evtlog_type();
+switch (log_type) {
+case EVTLOG_TPM12:
 if ( !evtlog_append_tpm12(pcr, >entries[0].hash, type) )
 return false;
 break;
-case TPM20_VER_MAJOR:
+case EVTLOG_TPM2_LEGACY:
 for (unsigned int i=0; icount; i++) {
-if ( 

Re: [tboot-devel] Ensure tboot log is available even when measured launch is skipped

[Sun, Ning]

Thanks very much for the patch, it was validated and merged…

-Ning


From: Sahil Rihan [mailto:sri...@fb.com]
Sent: Thursday, May 03, 2018 3:26 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Ensure tboot log is available even when measured launch 
is skipped

Tboot only protects the log area in the e820 map in post_launch i.e. only if a 
measured launch has successfully been performed. This means that in cases where 
measured launch is skipped, tboot log’s memory is not reserved in the e820 map 
and can be reused by the kernel. This can make it hard to figure out why 
measured launch was skipped.

This change moves the code to reserve the tboot log in the E820 map to the 
start of launch_kernel, which is called regardless of whether measured launch 
succeeded or not.

Testing:  Disable TXT. Boot host. Verify no log is displayed without fix, and 
tboot log is displayed with fix.

Signed-off-by: Sahil Rihan >

diff --git a/tboot/common/loader.c b/tboot/common/loader.c
--- a/tboot/common/loader.c
+++ b/tboot/common/loader.c
@@ -76,6 +76,7 @@
extern bool jump_linux_image(const void *entry_point);
extern bool is_sinit_acmod(const void *acmod_base, uint32_t acmod_size,
bool quiet);
+extern void apply_policy(tb_error_t error);

extern uint32_t g_mb_orig_size;

@@ -1368,6 +1369,20 @@
 printk(TBOOT_ERR"CRB workaround failed \n");
 }

+/* if using memory logging, reserve log area */
+if ( g_log_targets & TBOOT_LOG_TARGET_MEMORY ) {
+uint64_t base = TBOOT_SERIAL_LOG_ADDR;
+uint64_t size = TBOOT_SERIAL_LOG_SIZE;
+printk(TBOOT_INFO"reserving tboot memory log (%Lx - %Lx) in e820 
table\n", base, (base + size - 1));
+if ( !e820_protect_region(base, size, E820_RESERVED) )
+apply_policy(TB_ERR_FATAL);
+}
+
+/* replace map in loader context with copy */
+replace_e820_map(g_ldr_ctx);
+printk(TBOOT_DETA"adjusted e820 map:\n");
+print_e820_map();
+
 if ( !verify_loader_context(g_ldr_ctx) )
 return false;


diff --git a/tboot/common/tboot.c b/tboot/common/tboot.c
--- a/tboot/common/tboot.c
+++ b/tboot/common/tboot.c
@@ -207,21 +207,6 @@
 if ( !e820_protect_region(base, size, mem_type) )
 apply_policy(TB_ERR_FATAL);

-/* if using memory logging, reserve log area */
-if ( g_log_targets & TBOOT_LOG_TARGET_MEMORY ) {
-base = TBOOT_SERIAL_LOG_ADDR;
-size = TBOOT_SERIAL_LOG_SIZE;
-printk(TBOOT_INFO"reserving tboot memory log (%Lx - %Lx) in e820 
table\n", base, (base + size - 1));
-if ( !e820_protect_region(base, size, E820_RESERVED) )
-apply_policy(TB_ERR_FATAL);
-}
-
-/* replace map in loader context with copy */
-replace_e820_map(g_ldr_ctx);
-
-printk(TBOOT_DETA"adjusted e820 map:\n");
-print_e820_map();
-
 /*
  * verify modules against policy
  */

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] grub hangs after loading tboot and kernel

[Sun, Ning]

Hi Peter,

Did you see this hang with more recent Kernel versions, for example, kernel 4.x?

-Ning
From: Scheie, Peter M [mailto:petre.sch...@gd-ms.com]
Sent: Thursday, March 29, 2018 9:08 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] grub hangs after loading tboot and kernel

In grub, I'm loading the tboot module with no problem using the multiboot 
command.  But then when I load the kernel, grub just hangs.  My kernel is 3.10 
and I'm using tboot 1.9.6, and grub2.  Here's my grub.cfg:

load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
multiboot /tboot.gz /tboot.gz logging=vga,memory,serial
module /bzImage /bzImage ro console=tty0 console=ttyS0,115200
module /rootfs.cpio.gz /rootfs.cpio.gz
module /7th_gen_i5_i7-SINIT_74.bin /7th_gen_i5_i7-SINIT_74.bin

Also, is it the version of grub that determines whether I need to pass the 
arguments to multiboot & module once or twice?

(BTW, I know this is a dev list, but I didn't see a user list for tboot.  If 
there's a more appropriate list to ask this question, let me know).

Peter
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TXT SINIT ACM failure on power-cycling node

[Sun, Ning]

If those messages were from the platform itself, it is better to follow the 
instructions to restart the system, as the BIOS detected something wrong with 
the platform to do a TXT boot.

No modifications are needed from TXT SINIT, TPM, tboot for this situation.

This issue is vendor specific, just try to avoid non-graceful powercycle.

Hope this helps...

-Ning

From: Nasim, Kam [mailto:kam.na...@windriver.com]
Sent: Thursday, February 22, 2018 12:54 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] TXT SINIT ACM failure on power-cycling node

Hi folks,

We've been trying to integrate Tboot in our Boot sequence and have it working 
fine for the most part. We specify a default ANY Launch Control Policy (LCP) as 
main intention is to capture boot measurements in TPM PCRs and not really 
enforce a boot halt action.

I noticed that when I power cycle the node or any other kind of non-graceful 
restart, it stops at the Boot menu with the following Error:

Message
An issue is observed in the previous invocation of TXT SINIT Authenticated Code 
Module (ACM) because the TXT information stored in the TPM chip may be 
corrupted.
Detailed Description
An issue in observed in the previous invocation of TXT SINIT Authenticated Code 
Module (ACM) because the TXT information stored in the TPM chip may be 
corrupted.
Recommended Response Action
Do one of the following: 1) Update the BIOS firmware. 2) Go to System Setup > 
System Security page, click the "Clear" option under TPM command. Restart the 
system, go to System Setup > System Security page, click the "Activate" option 
under TPM command, and then enable TXT.


I am able to continue past this but was wondering if there is any way to 
disable this. We don't want to be manually doing this for all of our servers 
after a Power Cycle event.

Have others seen this? Is this a form of corruption in the ACM? How do I flush 
that state on a power cycle?


Thanks,
Kam
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] null pointer dereference

[Sun, Ning]

We fully understood this patch now, will merge it shortly after several runs on 
our TXT servers and clients.

Thanks,
-Ning

From: Bo Adler [mailto:thum...@fb.com]
Sent: Wednesday, February 07, 2018 2:46 PM
To: tboot-devel@lists.sourceforge.nettSubject: Re: [tboot-devel] null pointer 
dereference

Hi Ning,

Oops, you’re right – the “generic fatal error” is a different problem I’m 
tracking down.  I’ll send a separate email about that.

For this case, tboot goes into an infinite loop when TXT is off.  To answer 
your question – yes, tboot will complete but with “measured launch: FALSE”.

--Bo


Here’s the repeating section of the TBOOT output:

TBOOT: CPU is SMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: *** TBOOT ***
TBOOT:2017-07-11 12:00 -0800 1.9.6
TBOOT: *
TBOOT: command line: logging=memory,serial serial=57600,8n1,0x2f8 
ignore_prev_err=false
TBOOT: IA32_FEATURE_CONTROL_MSR: ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: IA32_FEATURE_CONTROL_MSR: ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: BSP is cpu 0
TBOOT: original e820 map:
TBOOT:   - 000a  (1)
TBOOT:  0010 - 79592000  (1)
TBOOT:  79592000 - 79b58000  (2)
TBOOT:  79b58000 - 79ba9000  (3)
TBOOT:  79ba9000 - 7a169000  (4)
TBOOT:  7a169000 - 7bcf6000  (2)
TBOOT:  7bcf6000 - 7bd51000  (20)
TBOOT:  7bd51000 - 7bd52000  (1)
TBOOT:  7bd52000 - 7bdd8000  (2)
TBOOT:  7bdd8000 - 7c00  (1)
TBOOT:  7c00 - 9000  (2)
TBOOT:  fed1c000 - fed2  (2)
TBOOT:  ff00 - 0001  (2)
TBOOT:  0001 - 00208000  (1)
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=1010c39, acm_hdr->size*4=c0c0c0c0
TBOOT: no SINIT AC module found
TBOOT: TXT.SINIT.BASE: 0x0
TBOOT: TXT.SINIT.SIZE: 0x0 (0)
TBOOT: IA32_FEATURE_CONTROL_MSR: ff07


From: "Sun, Ning" <ning@intel.com<mailto:ning@intel.com>>
Date: Wednesday, February 7, 2018 at 2:13 PM
To: Bo Adler <thum...@fb.com<mailto:thum...@fb.com>>, 
"tboot-devel@lists.sourceforge.net<mailto:tboot-devel@lists.sourceforge.net>" 
<tboot-devel@lists.sourceforge.net<mailto:tboot-devel@lists.sourceforge.net>>
Subject: RE: null pointer dereference

Hi Bo,

Do you mean that your patch will allow a TPM 1.2 machine with Intel TXT turned 
off to boot into Linux successfully with tboot but not into a trusted TXT 
environment?
Was there any tboot logs for the “generic fatal error”?

Thanks,
-Ning




From: Bo Adler [mailto:thum...@fb.com]
Sent: Tuesday, February 06, 2018 3:18 PM
To: tboot-devel@lists.sourceforge.net<mailto:tboot-devel@lists.sourceforge.net>
Subject: [tboot-devel] null pointer dereference

I was trying to test more recent versions of tboot, and have run into a couple 
of problems.  Here’s the first one, which occurs if TXT is disabled in the 
firmware.  Is there any continuous testing plan for this project that could 
catch errors like this?
--Bo
Test plan: found a machine running with tpm-1.2, turned off TXT.  Verified that 
my older 1.9.5 version would do a measured launch, and that the most recent 
1.9.6 would report “generic fatal error”. A gazillion printk’s later, and I 
discovered the problem was in the line below.  Applying the patch allows the 
machine to boot with a measured launch.


---
tboot/common/tb_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tboot/common/tb_error.c b/tboot/common/tb_error.c
index e9e8244..5880620 100644
--- a/tboot/common/tb_error.c
+++ b/tboot/common/tb_error.c
@@ -168,7 +168,7 @@ bool write_tb_error_code(tb_error_t error)
 struct tpm_if *tpm = get_tpm();
 const struct tpm_if_fp *tpm_fp = get_tpm_fp();

-if ( !tpm || no_err_idx )
+if ( !tpm || !tpm_fp || no_err_idx )
 return false;

 if ( !tpm_fp->nv_write(tpm, tpm->cur_loc, tpm->tb_err_index, 0,
--
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] null pointer dereference

[Sun, Ning]

Hi Bo,

Do you mean that your patch will allow a TPM 1.2 machine with Intel TXT turned 
off to boot into Linux successfully with tboot but not into a trusted TXT 
environment?
Was there any tboot logs for the “generic fatal error”?

Thanks,
-Ning




From: Bo Adler [mailto:thum...@fb.com]
Sent: Tuesday, February 06, 2018 3:18 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] null pointer dereference

I was trying to test more recent versions of tboot, and have run into a couple 
of problems.  Here’s the first one, which occurs if TXT is disabled in the 
firmware.  Is there any continuous testing plan for this project that could 
catch errors like this?
--Bo
Test plan: found a machine running with tpm-1.2, turned off TXT.  Verified that 
my older 1.9.5 version would do a measured launch, and that the most recent 
1.9.6 would report “generic fatal error”. A gazillion printk’s later, and I 
discovered the problem was in the line below.  Applying the patch allows the 
machine to boot with a measured launch.


---
tboot/common/tb_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tboot/common/tb_error.c b/tboot/common/tb_error.c
index e9e8244..5880620 100644
--- a/tboot/common/tb_error.c
+++ b/tboot/common/tb_error.c
@@ -168,7 +168,7 @@ bool write_tb_error_code(tb_error_t error)
 struct tpm_if *tpm = get_tpm();
 const struct tpm_if_fp *tpm_fp = get_tpm_fp();

-if ( !tpm || no_err_idx )
+if ( !tpm || !tpm_fp || no_err_idx )
 return false;

 if ( !tpm_fp->nv_write(tpm, tpm->cur_loc, tpm->tb_err_index, 0,
--
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[Sun, Ning]

It looks like tboot_wait_for_aps(...) is not called in atomic context .

mdelay(1) delays exactly 1msecs, I understand udelay(...) may not be  
appropriate, as it is used for delay around 20usecs.
In terms of reducing busy wait, how can we determine the range in 
usleep_range(...) is 1000 to 2000, not from 20 to 1000?

Thanks,
-ning 


-Original Message-
From: Jia-Ju Bai [mailto:baijiaju1...@gmail.com] 
Sent: Wednesday, January 24, 2018 5:38 AM
To: Thomas Gleixner <t...@linutronix.de>
Cc: Sun, Ning <ning@intel.com>; mi...@redhat.com; h...@zytor.com; 
x...@kernel.org; tboot-devel@lists.sourceforge.net; linux-ker...@vger.kernel.org
Subject: Re: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in 
tboot_wait_for_aps


On 2018/1/24 19:47, Thomas Gleixner wrote:
> On Wed, 24 Jan 2018, Jia-Ju Bai wrote:
>
>> The function tboot_wait_for_aps is not called in atomic context.
>> Thus mdelay can be replaced with usleep_range, to reduce busy wait.
> And how did you establish that it's not called in atomic context?
>
> Thanks,
>
>   tglx

It is reported by a static analysis tool written by myself.
This tool finds that mdelay in tboot_wait_for_aps is not called by holding a 
spinlock or in an interrupt handler, thus mdelay can be replaced.


Thanks,
Jia-Ju Bai
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Correctly calculate EFI memory map size

[Sun, Ning]

Thanks for the patch, it was applied...

-Ning 

-Original Message-
From: Sahil Rihan [mailto:sri...@fb.com] 
Sent: Saturday, September 30, 2017 1:38 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Correctly calculate EFI memory map size

The size field of the MB2 tag is the size of the tag header + the size of the 
memmap entries. So we need to subtract the size of the header before returning 
the memmap size.

Test Plan: Boot with 4.11 kernel. Verify system boots correctly and "Invalid 
EFI memory map entries" message is not present in dmesg.

Signed-off-by: Sahil Rihan 

tboot/common/loader.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tboot/common/loader.c b/tboot/common/loader.c index 
88d6d30..dec80d8 100644
--- a/tboot/common/loader.c
+++ b/tboot/common/loader.c
@@ -1915,8 +1915,12 @@ find_efi_memmap(loader_ctx *lctx, uint32_t *descr_size,
 efi_mmap = (struct mb2_tag_efi_mmap *)hit;
 *descr_size = efi_mmap->descr_size;
 *descr_vers = efi_mmap->descr_vers;
-*mmap_size = efi_mmap->size;
-return (uint32_t)(_mmap->efi_mmap);
+*mmap_size = efi_mmap->size - sizeof(struct mb2_tag_efi_mmap);
+if (*mmap_size % *descr_size) {
+printk(TBOOT_WARN "EFI memmmap (0x%x) should be a multiple of 
descriptor size (0x%x)\n",
+ *mmap_size, *descr_size);
+}
+return (uint32_t)(_mmap->efi_mmap);
 }

 bool


--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] version 1.9.5, lcp2_crtpolelt with type mle

[Sun, Ning]

This was perhaps, more likely, a typo, anyway, the patch was merged...

Thanks,
-Ning

-Original Message-
From: Curt Brune [mailto:c...@cumulusnetworks.com] 
Sent: Friday, September 01, 2017 8:34 AM
To: Trusted Boot List 
Subject: Re: [tboot-devel] version 1.9.5, lcp2_crtpolelt with type mle

Hello -

Attached is a patch against version 1.9.6 that fixes this problem.
The stm_elt now registers itself as "stm" instead of the conflicting "mle".

Cheers,
Curt

On Wed Aug 30 08:35, Curt Brune wrote:
> Hello,
> 
> I am using version 1.9.5 and working my way through the documentation 
> in tboot-1.9.5/lcptools-v2/lcptools.txt.
> 
> I am hitting a snag trying to follow the instructions there, creating 
> a mle policy element.
> 
> The first step works fine:
> 
>   linux:~$ lcp2_mlehash --create --cmdline "$TBOOT_CMDLINE" --alg sha1 
> /boot/tboot.gz > mle_hash
> 
> Creating the policy element fails:
> 
>   linux:~$ lcp2_crtpolelt --create --type mle --ctrl 0x00 --minver 17 --alg 
> sha1 --out mle.elt mle_hash
>   Error: unknown option for mle type
> 
> Looking at the help I see that two different policy element plugins 
> are using the same type string "mle":
> 
>   linux:~$ lcp2_crtpolelt --help
> [snip]
>   types :
> mle
>  [--alg ]  hash alg of element
>   [FILE2] ...  one or more files containing STM
> hash(es); each file can contain
>   multiple hashes [snip]
>   mle
>[--minver ]minimum version of SINIT
>[--alg ]hash alg of element
> [FILE2] ... one or more files containing MLE
>  hash(es); each file can contain
>  multiple hashes
> 
> Looking at the code I see that tboot-1.9.5/lcptools-v2/mle_elt.c and 
> tboot-1.9.5/lcptools-v2/stm_elt.c both define a plugin of type "mle".
> That seems to be the problem.
> 
> Looking at version 1.9.6 has the same problem.
> 
> Am I missing something?
> 
> Cheers,
> Curt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Double free bugs introducted by commit 487:4e7bfa7aaa00

[Sun, Ning]

Good catch, the patch was merged.

Thanks,
-Ning 



-Original Message-
From: Curt Brune [mailto:c...@cumulusnetworks.com] 
Sent: Friday, September 01, 2017 8:38 AM
To: Trusted Boot List 
Subject: [tboot-devel] Double free bugs introducted by commit 487:4e7bfa7aaa00

Hello,

Trying to use version 1.9.6 lcp utilities, which contains a patchset that 
updates the openssl usage, always segfaulted for me.

The problem is the patchset introduced double free bugs, which depending on 
your compiler, linker, libc, etc could go unnoticed or segfault.  I got lucky, 
it segfaulted :)

Attached is a patch that fixes the double frees.  After this patch no more 
segfaults.

Cheers,
Curt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] [patch]

[Sun, Ning]

Thanks for the patch, it was applied.

-ning

-Original Message-
From: travis.gilb...@dell.com [mailto:travis.gilb...@dell.com] 
Sent: Monday, July 03, 2017 12:27 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] [patch]

Housekeeping patch to ignore TPM 2.0 LCP tool binaries.

Signed-off-by: Travis Gilbert 

--- a/.hgignore Tue Jun 20 10:03:48 2017 -0700
+++ b/.hgignore Mon Jul 03 14:17:19 2017 -0500
@@ -44,6 +44,11 @@
 ^lcptools/lcp_crtpolelt$
 ^lcptools/lcp_crtpollist$
 ^lcptools/trousers_dep$
+^lcptools-v2/lcp2_crtpol$
+^lcptools-v2/lcp2_crtpolelt$
+^lcptools-v2/lcp2_crtpollist$
+^lcptools-v2/lcp2_mlehash$
+^lcptools-v2/trousers_dep$
 ^tb_polgen/tb_polgen$
 ^utils/acminfo$
 ^utils/txt-stat$

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] [patch] grub2 20_linux_*tboot config files

[Sun, Ning]

It is fine, so far as we know the patch does not break any tboot installation 
logic.

Thanks,
-Ning

-Original Message-
From: travis.gilb...@dell.com [mailto:travis.gilb...@dell.com] 
Sent: Monday, July 03, 2017 2:59 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] [patch] grub2 20_linux_*tboot config files

This patch adds a check for the grub2 location of grub-mkconfig_lib. I'm not 
sure this is the best place to be patching this based on my perusing of grub2's 
files, but I couldn't see a better way. At least for a default Xen SLES 12 SP2 
this fixes errors with grub2-mkconfig after a "make install" of tboot.

Signed-off-by: Travis Gilbert 

==
diff -r e1bd4146a911 tboot/20_linux_tboot
--- a/tboot/20_linux_tboot  Tue Jun 20 10:03:48 2017 -0700
+++ b/tboot/20_linux_tboot  Mon Jul 03 16:52:26 2017 -0500
@@ -26,6 +26,8 @@
   . /usr/share/grub/grub-mkconfig_lib
 elif test -e ${libdir}/grub/grub-mkconfig_lib; then
   . ${libdir}/grub/grub-mkconfig_lib
+elif test -e /usr/share/grub2/grub-mkconfig_lib; then
+  . /usr/share/grub2/grub-mkconfig_lib
 fi
 
 if test -e ${sysconfdir}/default/grub-tboot; then diff -r e1bd4146a911 
tboot/20_linux_xen_tboot
--- a/tboot/20_linux_xen_tboot  Tue Jun 20 10:03:48 2017 -0700
+++ b/tboot/20_linux_xen_tboot  Mon Jul 03 16:52:26 2017 -0500
@@ -26,6 +26,8 @@
   . /usr/share/grub/grub-mkconfig_lib
 elif test -e ${libdir}/grub/grub-mkconfig_lib; then
   . ${libdir}/grub/grub-mkconfig_lib
+elif test -e /usr/share/grub2/grub-mkconfig_lib; then
+  . /usr/share/grub2/grub-mkconfig_lib
 fi
 
 if test -e ${sysconfdir}/default/grub-tboot; then


--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] gcc7 fix

[Sun, Ning]

Thanks for the patch, it was merged.

-ning

-Original Message-
From: Marcus Meissner [mailto:meiss...@suse.de] 
Sent: Sunday, June 11, 2017 3:24 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] gcc7 fix


Hi,

This patch adds some generic FALLTHROUGH notations to avoid warnings appearing 
on gcc7. It also initialized some structures completely to avoid uninitialized 
warnings.

Signed-off-by: Marcus Meissner 

Ciao, Marcus
Index: tboot-1.9.5/tboot/common/tboot.c
===
--- tboot-1.9.5.orig/tboot/common/tboot.c
+++ tboot-1.9.5/tboot/common/tboot.c
@@ -501,11 +501,13 @@ static void shutdown_system(uint32_t shu
 /* write our S3 resume vector to ACPI resume addr */
 set_s3_resume_vector(&_tboot_shared.acpi_sinfo,  
TBOOT_S3_WAKEUP_ADDR);
 /* fall through for rest of Sx handling */
+   /* FALLTHROUGH */
 case TB_SHUTDOWN_S4:
 case TB_SHUTDOWN_S5:
 machine_sleep(&_tboot_shared.acpi_sinfo);
 /* if machine_sleep() fails, fall through to reset */
 
+   /* FALLTHROUGH */
 case TB_SHUTDOWN_REBOOT:
 if ( txt_is_powercycle_required() ) {
 /* powercycle by writing 0x0a+0x0e to port 0xcf9 */ @@ -524,6 
+526,7 @@ static void shutdown_system(uint32_t shu
 outb(0xcf9, 0x06);
 }
 
+   /* FALLTHROUGH */
 case TB_SHUTDOWN_HALT:
 default:
 while ( true )
Index: tboot-1.9.5/tboot/common/vsprintf.c
===
--- tboot-1.9.5.orig/tboot/common/vsprintf.c
+++ tboot-1.9.5/tboot/common/vsprintf.c
@@ -404,6 +404,7 @@ handle_width:
 case 'p':
 mods.flag |= PREFIX;/* print prefix 0x for %p */
 mods.flag_long = LONG;
+   /* FALLTHROUGH */
 case 'x':
 mods.base = 16;
 buf_pos = write_number_to_buffer(buf, size, buf_pos, mods);
Index: tboot-1.9.5/tboot/common/tpm.c
===
--- tboot-1.9.5.orig/tboot/common/tpm.c
+++ tboot-1.9.5/tboot/common/tpm.c
@@ -117,14 +117,14 @@ static bool tpm_send_cmd_ready_status_cr  #endif
 
if ( reg_ctrl_sts.tpmidle== 1) {
-   reg_ctrl_request._raw[0] = 0;
+  memset(_ctrl_request,0,sizeof(reg_ctrl_request));
reg_ctrl_request.cmdReady = 1;
write_tpm_reg(locality, TPM_CRB_CTRL_REQ, _ctrl_request);
 
return true;
}
 
-  reg_ctrl_request._raw[0] = 0;
+  memset(_ctrl_request,0,sizeof(reg_ctrl_request));
   reg_ctrl_request.goIdle = 1;
   write_tpm_reg(locality, TPM_CRB_CTRL_REQ, _ctrl_request);
  
@@ -158,7 +158,7 @@ static bool tpm_send_cmd_ready_status_cr
printk(TBOOT_INFO"2. reg_ctrl_sts.tpmsts: 0x%x\n", 
reg_ctrl_sts.tpmsts);
 #endif
 
-   reg_ctrl_request._raw[0] = 0;
+  memset(_ctrl_request,0,sizeof(reg_ctrl_request));
reg_ctrl_request.cmdReady = 1;
write_tpm_reg(locality, TPM_CRB_CTRL_REQ, _ctrl_request);
 
@@ -724,7 +724,7 @@ bool tpm_relinquish_locality_crb(uint32_
 if ( reg_loc_state.loc_assigned == 0 )return true;
 
 /* make inactive by writing a 1 */
-reg_loc_ctrl._raw[0] = 0;
+memset(_loc_ctrl,0,sizeof(reg_loc_ctrl));
 reg_loc_ctrl.relinquish = 1;
 write_tpm_reg(locality, TPM_REG_LOC_CTRL, _loc_ctrl);
 
@@ -778,7 +778,7 @@ bool tpm_request_locality_crb(uint32_t l
 tpm_reg_loc_state_t  reg_loc_state;
 tpm_reg_loc_ctrl_treg_loc_ctrl;
 /* request access to the TPM from locality N */
-reg_loc_ctrl._raw[0] = 0;
+memset(_loc_ctrl,0,sizeof(reg_loc_ctrl));
 reg_loc_ctrl.requestAccess = 1;
 write_tpm_reg(locality, TPM_REG_LOC_CTRL, _loc_ctrl);
 

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] tboot-loader patch

[Sun, Ning]

Thanks for the patch, it was merged.

-ning


-Original Message-
From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com] 
Sent: Monday, June 05, 2017 8:36 AM
To: TBoot Dev List (tboot-devel@lists.sourceforge.net) 

Cc: Smith, William D (GE Global Research, US) 
Subject: Re: [tboot-devel] tboot-loader patch

I apologize for the previous email. The correct patch is attached.

Signed-off-by: Safayet Ahmed 

Safayet

From: Ahmed, Safayet (GE Global Research, US)
Sent: Monday, June 05, 2017 10:36 AM
To: TBoot Dev List (tboot-devel@lists.sourceforge.net)
Cc: Smith, William D (GE Global Research, US)
Subject: EXT: [tboot-devel] tboot-loader patch

Hello

Attached is a patch to address multiboot-loading problems that may have 
security implications.

Before unpacking module 0 as an ELF binary, TBoot moves all modules to a 
"ceiling" computed from the E820 map. This move is meant to ensure that the 
module images aren't corrupted in the process of unpacking the ELF binary. 
Then, after unpacking the ELF binary, TBoot moves all the modules back down to 
just above the highest end address of the ELF binary.

The problem with this approach is that TBoot can overwrite one module with 
another module. We have seen this happen with a specific boot configuration. 
This is a possible vulnerability because this process of moving modules occurs 
after the modules have been measured and the PCRs have been extended with the 
measurements.

Further, an adversary may control the corruption of the modules because the 
placement of modules in memory and the E820 map come from the pre-launch 
environment and the pre-launch environment is not trusted.
1) The Multiboot specification does not impose restrictions on the order of 
modules in memory. For example, module 0 can occur at a higher address in 
physical memory than module 1.
2) Even though the E820 map is verified to ensure that unusable memory is 
not marked as valid RAM (verify_e820_map), valid RAM may still be marked as 
unusable memory. There is no way to check for this latter form of corruption.

To prevent TBoot from overwriting one module with another, the following 
restrictions are imposed:
1) Always move modules in the same direction.
For example, when moving modules up to the "ceiling", only move modules up 
in memory, never down. More specifically, only move those modules that occur 
below the computed ceiling. In the case of modules that straddle the ceiling, 
move the ceiling down.
2) Move modules in order of their occurance in memory (not in order of 
their index).
For example, when moving modules up, first move the module with the highest 
base/end address.

The above changes should ensure that Tboot never overwrites one module with 
another in the process of moving them.

Signed-off-by: Safayet Ahmed 

thanks,

Safayet

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Check for initrd image before moving

[Sun, Ning]

Thanks for the patch, it was merged.
The format is reasonable, it made the patch easy to understand...

-Ning 



-Original Message-
From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com] 
Sent: Thursday, June 01, 2017 9:52 AM
To: TBoot Dev List (tboot-devel@lists.sourceforge.net) 

Subject: [tboot-devel] Check for initrd image before moving

Currently, TBoot attempts to move the initrd image without checking if an 
initrd image is present. If no initrd image is present, Linux expects the base 
address of the initrd image to be set to zero in the Linux header.

The following patch modifies the Linux loading code such that the initrd image 
is only moved if the size is greater than zero. I apologize for the poor 
formatting, but I left the block without the additional indentation to make the 
change clear.

Signed-off-by: Safayet Ahmed 

--- a/tboot/common/linux.cMon May 29 20:11:40 2017 -0700
+++ b/tboot/common/linux.cThu Jun 01 12:21:45 2017 -0400
@@ -161,6 +161,7 @@
 hdr->loadflags |= FLAG_CAN_USE_HEAP; /* can use heap */
 hdr->heap_end_ptr = KERNEL_CMDLINE_OFFSET - BOOT_SECTOR_OFFSET;
 
+if( initrd_size > 0 ){
 /* load initrd and set ramdisk_image and ramdisk_size */
 /* The initrd should typically be located as high in memory as
possible, as it may otherwise get overwritten by the early @@ -221,6 
+222,8 @@
 printk(TBOOT_DETA"Initrd from 0x%lx to 0x%lx\n",
(unsigned long)initrd_base,
(unsigned long)(initrd_base + initrd_size));
+}else
+initrd_base = (uint32_t)initrd_image;
 
 hdr->ramdisk_image = initrd_base;
 hdr->ramdisk_size = initrd_size;


--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] reproducible build patch

[Sun, Ning]

This patch has been applied: 
https://sourceforge.net/p/tboot/code/ci/0887b59c5b4d16cfa91f886800755da6f4e10076/

-ning

-Original Message-
From: Marcus Meissner [mailto:meiss...@suse.de] 
Sent: Sunday, June 04, 2017 1:52 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] reproducible build patch

Hi,

Bernhard Wiedemann of SUSE currently is fixing various reproducible build 
issues throughout SUSE. 

The -n option for gzip suppresses storing a timestamp during compression, this 
would change in builds usually and make it non-reproducible.

Ciao, Marcus
--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 
3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Questions about Launch Control Policies

[Sun, Ning]

Hi Marco,

Thanks for the write-up, you got most of the answers correct for your questions.

Both lcptools and lcptools-v2 folders (in tboot source package) are for LCP V2 
on TPM 1.2 platforms

Folder lcp-gen2 is for LCP V3 creation on TPM 2.0 platform, so far tboot does 
not provide tpm 2.0 tools to write the LCP to TPM nv index, there are TPM 2.0 
TSS and tools from Intel as well, see below.

For tboot VLP, there is a default VLP in tboot source code, if there is no VLP 
found from TPM NV index, tboot will apply the default VLCP.

For TPM 2.0 TSS and tools, here are the website for your reference:

https://github.com/01org/TPM2.0-TSS

https://github.com/01org/tpm2.0-tools

-Ning

From: Marco Vanotti [mailto:mvano...@google.com]
Sent: Tuesday, May 23, 2017 1:32 PM
To: tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] Questions about Launch Control Policies

Hi All!

After reading a lot of documentation [*], I think I figured out the answers to 
some of the questions. I would like to confirm if what I think is correct.

TBOOT sets up an environment and executes GETSEC[SENTER], which handles control 
over to the SINIT ACM. The SINIT ACM will measure the MLE and execute the 
policy engine, which validates the LCPs. The ACM will extend the MLE hash to 
PCR17 among other things.  After that, the ACM will handle control back to 
TBOOT, which will execute the post_launch mechanism. There, it will look for 
VLCPs, first in a special NV Index (0x0121 or 0x01c10131), or as a 
LCP_CUSTOM_ELEMENT in the policy data file, and then validates it.

For remote attestation, you would want to get PCR17 and PCR18, maybe PCR0 to 
make sure that BIOS is still the same? What I find unclear is how one should 
handle updates, BIOS, Kernel and TBOOT. It seems like the best way is to have a 
replicated setup for testing the updates and do all the measurements there.

---

The problem with the NV Indices that I had (index 0x141 was being deleted 
on every reboot) was a BIOS issue. I contacted the platform supplier and asked 
for a BIOS update.

The way to check which set of indices are used by your ACM is by checking the 
tpm_nv_index_set under the TPM capabilities in the loaded SINIT ACM (tables A-8 
and A-9 from the intel txt guide, in Appendix A). The NVRAM Indices and 
attributes can be found in the Table J-2 (Appendix J TPM NV). For example, it 
says that the LCP PO index is 0x141 or 0x1c10106 (depending on the 
tpm_nv_index_set).

I have more questions, but I will try to write another email for them, as they 
are not related to this problem.

Thank you all for your time :)

Best Regards,
Marco

[*]:
Intel TXT Software Development Guide: 
http://www.intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html
TPM 2.0 Spec: https://trustedcomputinggroup.org/tpm-library-specification/
A practical guide to TPM 2.0: http://www.apress.com/us/book/9781430265832
Intel Trusted Execution for Server Platforms: 
http://www.apress.com/us/book/9781430261483
TPM 2.0 registry of reserved handles: 
https://trustedcomputinggroup.org/registry-reserved-tpm-2-0-handles-localities/

On Thu, May 4, 2017 at 7:19 PM, Marco Vanotti 
> wrote:
Hi All!

I hope you are having a wonderful day today :). I am trying to get tboot to 
work in my machine. My computer has a TPM 2.0 and I am trying to understand 
some of the available features.

The Intel TXT Software Development Guide defines Launch Control Policies.  
Given that I have TPM 2.0, I believe I should use version 3.0 or 3.1, there 
seem to be some utilities to write these files in the lcp-gen2 folder.

Looking at the source code, I found that there's also TBOOT Control Policies, 
which seem to be referred as Verified Launch Control Policies. What is the 
difference between them? When should I use each of them? Are they also executed 
by the ACM? if not, when?

It seems that VLCPs don't support policy data files, is that so?

Regarding LCPs, where should I define them in NVRAM? I've tried using 
0x141, but that index gets deleted every time I reboot the system, 
regardless of using TXT. I'm defining the space with attr 0xF00F, and size 102 
bytes, which is the size of the lcp_policy_2 struct. There's another index to 
use that doesn't get deleted: 0x01c10106, but I am not sure how to tell TXT to 
use it.

My original goal was to install a policy with POLTYPE_ANY, just to test, but I 
can't see anything related to it in txt-stat, should it be logged somehow?

Any help with these issues would be really appreciated :)

Best Regards,
Marco

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net

Re: [tboot-devel] [PATCH 0/4] Make code compatible with OpenSSL 1.1.0+

[Sun, Ning]

Hi,

Thanks for the patches, we got them applied after review and validation.

-ning

-Original Message-
From: b...@skyportsystems.com [mailto:b...@skyportsystems.com] 
Sent: Monday, May 15, 2017 1:47 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] [PATCH 0/4] Make code compatible with OpenSSL 1.1.0+

From: Ben Warren 

One major change with OpenSSL 1.1.0 is that access to many raw data structures 
is removed.  This patch set does version checking where necessary to use the 
appropriate API.

Compile-tested against OpenSSL v1.0.2d and v1.1.0e

ben-skyportsystems (4):
  Manage OpenSSL EVP_MD_CTX objects as pointers
  Remove unnecessary public key modulus size check
  Support OpenSSL 1.1.0+ for RSA key manipulation
  Support OpenSSL 1.1.0+ for ECDSA signature verification

 lcptools-v2/crtpollist.c | 26 +++---
 lcptools-v2/hash.c   | 36 
 lcptools-v2/lcputils.c   | 30 +++---
 lcptools/crtpollist.c| 18 +++---
 lcptools/hash.c  | 18 ++
 lcptools/lcputils2.c | 21 ++---
 lcptools/mlehash.c   | 10 ++
 tb_polgen/commands.c | 26 --
 tb_polgen/hash.c | 18 ++
 9 files changed, 137 insertions(+), 66 deletions(-)

--
2.6.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Additional checks moving initrd image

[Sun, Ning]

Thanks for the patch, it passed review and validation, now it got merged.

-ning

-Original Message-
From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com] 
Sent: Sunday, April 23, 2017 1:13 PM
To: TBoot Dev List (tboot-devel@lists.sourceforge.net) 

Subject: [tboot-devel] Additional checks moving initrd image


Before expanding the Linux image in "expand_linux_image" function, TBoot moves 
the inintrd image as high in memory as possible. If the kernel image is located 
high in memory, currently, TBoot writes over the kernel image.
The following patch adds additional checks to prevent the kernel image from 
being overwritten.

Signed-off-by: Safayet Ahmed 

diff --git a/tboot/common/linux.c b/tboot/common/linux.c index 26d653a..dfc2c54 
100644
--- a/tboot/common/linux.c
+++ b/tboot/common/linux.c
@@ -204,6 +204,19 @@ bool expand_linux_image(const void *linux_image, size_t 
linux_size,
 initrd_base = initrd_base & PAGE_MASK;
 }
 
+/* check for overlap with a kernel image placed high in memory */
+if( (initrd_base < ((uint32_t)linux_image + linux_size))
+&& ((uint32_t)linux_image < (initrd_base+initrd_size)) ){
+/* set the starting address just below the image */
+initrd_base = (uint32_t)linux_image - initrd_size;
+initrd_base = initrd_base & PAGE_MASK;
+/* make sure we're still in usable RAM and above tboot end address*/
+if( initrd_base < max_ram_base ){
+printk(TBOOT_ERR"no available memory for initrd\n");
+return false;
+}
+}
+

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Fixed an expression and output format problem

[Sun, Ning]

Thanks for the patch.
AFAIK, there are some TPM 2.0 support 2 banks, some TPM 2.0 support 3 banks.
Do you mean tboot just print out 2 banks on a TPM 2.0 with 3 banks?

-ning

From: shiwan...@gohighsec.com [mailto:shiwan...@gohighsec.com]
Sent: Monday, April 03, 2017 5:36 AM
To: tboot-devel 
Subject: [tboot-devel] Fixed an expression and output format problem

Hi,

There is an expression and output format problem.
Firstly,number of algorithms should be %d instead of %08X,it will be more 
readable.
Secondly,log expression is not accurate.Tpm2.0 supports three algorithms,as 
follows:
TBOOT: TPM: supported bank count = 3
TBOOT: TPM: bank alg = 0004
TBOOT: TPM: bank alg = 000b
TBOOT: TPM: bank alg = 0012
But tboot code supports two algorithms at present. So "printk(TBOOT_INFO"TPM: 
supported alg count = %08X\n", ti->alg_count);"
should be changed to "printk(TBOOT_INFO"tboot: supported alg count = %d\n", 
ti->alg_count);".

Signed-off-by: Shi 
Wangyi>

diff -r 2ec88c2dd07b -r c79d9a0558c0 tboot/common/tpm_20.c
--- a/tboot/common/tpm_20.c Fri Feb 17 03:55:19 2017 -0800
+++ b/tboot/common/tpm_20.c Sun Apr 02 09:58:00 2017 -0400
@@ -2319,9 +2319,9 @@
 ti->alg_count++;
 }
 }
-printk(TBOOT_INFO"TPM: supported alg count = %08X\n", ti->alg_count);
+printk(TBOOT_INFO"tboot: supported alg count = %d\n", ti->alg_count);
 for (unsigned int i=0; ialg_count; i++)
-printk(TBOOT_INFO"\t\t %08X\n", ti->algs[i]);
+printk(TBOOT_INFO"tboot: hash alg = %08X\n", ti->algs[i]);

 if (handle2048 != 0)
 goto out;


Thanks,
Wangyi
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Detect if Vt-D is enabled

[Sun, Ning]

Generally, when VT-d is disabled in the BIOS, Intel TXT  is also in disabled 
state, tboot will boot into kernel directly without triggering Getsec[senter].
Meanwhile, it looks like the testing method below is not sufficient to verify 
your patch, as current tboot can achieve your testing goal without the patch.
What kind of issue this patch tries to fix?

-Ning

-Original Message-
From: Sahil Rihan [mailto:sri...@fb.com] 
Sent: Thursday, March 23, 2017 5:15 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Detect if Vt-D is enabled

If Vt-D is disabled in the BIOS, the DMAR table is not present.
We can look for this and skip trying to perform a measured launch. This 
behavior of a missing DMAR table may not be true for all platforms, but in any 
case if the DMAR table is not present the kernel will not be able to 
detect/reprogram the IOMMU along the tboot_force_iommu path. So either way this 
change should be helpful.

Testing:  Disable Vt-D, verify that measured launch is skipped. Enable Vt-D, 
verify that measured launch is performed.


Signed-off-by: Sahil Rihan  


diff --git a/include/tb_error.h b/include/tb_error.h
--- a/include/tb_error.h
+++ b/include/tb_error.h
@@ -45,6 +45,7 @@
 TB_ERR_TPM_NOT_READY,   /* tpm not ready */
 TB_ERR_SMX_NOT_SUPPORTED,   /* smx not supported */
 TB_ERR_VMX_NOT_SUPPORTED,   /* vmx not supported */
+TB_ERR_VTD_NOT_SUPPORTED,   /* Vt-D not enabled in BIOS */
 TB_ERR_TXT_NOT_SUPPORTED,   /* txt not supported */
 
 TB_ERR_MODULE_VERIFICATION_FAILED,  /* module failed to verify against
diff --git a/tboot/common/acpi.c b/tboot/common/acpi.c
--- a/tboot/common/acpi.c
+++ b/tboot/common/acpi.c
@@ -212,7 +212,7 @@
 }
 }
 
-printk(TBOOT_ERR"cann't find %s table.\n", table_name);
+printk(TBOOT_ERR"can't find %s table.\n", table_name);
 return NULL;
 }
 
@@ -221,6 +221,11 @@
 return (struct acpi_dmar *)find_table(DMAR_SIG);  }
 
+bool vtd_bios_enabled(void)
+{
+return find_table(DMAR_SIG) != NULL; }
+
 bool save_vtd_dmar_table(void)
 {
 /* find DMAR table and save it */
diff --git a/tboot/common/policy.c b/tboot/common/policy.c
--- a/tboot/common/policy.c
+++ b/tboot/common/policy.c
@@ -101,6 +101,7 @@
   {TB_ERR_TPM_NOT_READY,   TB_POLACT_UNMEASURED_LAUNCH},
   {TB_ERR_SMX_NOT_SUPPORTED,   TB_POLACT_UNMEASURED_LAUNCH},
   {TB_ERR_VMX_NOT_SUPPORTED,   TB_POLACT_UNMEASURED_LAUNCH},
+  {TB_ERR_VTD_NOT_SUPPORTED,   TB_POLACT_UNMEASURED_LAUNCH},
   {TB_ERR_TXT_NOT_SUPPORTED,   TB_POLACT_UNMEASURED_LAUNCH},
   {TB_ERR_SINIT_NOT_PRESENT,   TB_POLACT_UNMEASURED_LAUNCH},
   {TB_ERR_ACMOD_VERIFY_FAILED, TB_POLACT_UNMEASURED_LAUNCH},
diff --git a/tboot/common/tb_error.c b/tboot/common/tb_error.c
--- a/tboot/common/tb_error.c
+++ b/tboot/common/tb_error.c
@@ -81,6 +81,9 @@
 case TB_ERR_VMX_NOT_SUPPORTED:
 printk(TBOOT_ERR"VMX not supported.\n");
 break;
+case TB_ERR_VTD_NOT_SUPPORTED:
+printk(TBOOT_ERR"DMAR table not found. Check if Vt-D is enabled in 
BIOS.\n");
+break;
 case TB_ERR_TXT_NOT_SUPPORTED:
 printk(TBOOT_ERR"TXT not supported.\n");
 break;
diff --git a/tboot/include/acpi.h b/tboot/include/acpi.h
--- a/tboot/include/acpi.h
+++ b/tboot/include/acpi.h
@@ -492,6 +492,7 @@
 
 #endif
 
+extern bool vtd_bios_enabled(void);
 extern bool save_vtd_dmar_table(void);
 extern bool restore_vtd_dmar_table(void);  extern bool 
remove_vtd_dmar_table(void); diff --git a/tboot/txt/verify.c 
b/tboot/txt/verify.c
--- a/tboot/txt/verify.c
+++ b/tboot/txt/verify.c
@@ -372,6 +372,10 @@
 if ( err != TB_ERR_NONE )
 return err;
 
+if ( !vtd_bios_enabled() ) {
+return TB_ERR_VTD_NOT_SUPPORTED;
+}
+
 /* check is TXT_RESET.STS is set, since if it is SENTER will fail */
 txt_ests_t ests = (txt_ests_t)read_pub_config_reg(TXTCR_ESTS);
 if ( ests.txt_reset_sts ) {




--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Fix EFI memory map handling

[Sun, Ning]

Thanks you for the patch, it passed review and validation, we got it merged.

-Ning


-Original Message-
From: Sahil Rihan [mailto:sri...@fb.com] 
Sent: Friday, February 10, 2017 5:01 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Fix EFI memory map handling

Pass through the EFI memory map that's provided by grub2. Also remove the 
get_efi_memmap code which was buggy to start with (it was using the struct size 
instead of the descriptor size while creating the efi memmap). 

If no memmap is provided the kernel will panic early since it tries to compute 
the number of entries in the memmap by dividing memmap size by mempap descr 
size. Fixing the div by 0 lets the kernel make further progress, so it panics 
at a point where the panic is visible without needing earlyprintk.

Note that booting *without* noefi is a security risk since the EFI runtime is 
not part of the trust base after a dynamic launch. This can be addressed by 
extending the chain of trust from the bootloader to tboot.

Testing: Remove noefi kernel param, verify efibootmgr works. Boot with noefi 
kernel param, verify tboot works, but efibootmgr fails. Halt from inside 
kernel, verify tboot shutdown is called.

Signed-off-by: Sahil Rihan 

 tboot/common/e820.c   |  70 
--
 tboot/common/linux.c  |  39 ++-
 tboot/common/loader.c |  20 
 tboot/include/e820.h  |   3 ---
 tboot/include/loader.h|   2 ++
 tboot/include/multiboot.h |  11 +++
 6 files changed, 55 insertions(+), 90 deletions(-)

diff --git a/tboot/common/e820.c b/tboot/common/e820.c
--- a/tboot/common/e820.c
+++ b/tboot/common/e820.c
@@ -60,9 +60,6 @@
 static unsigned int g_nr_map;
 static memory_map_t *g_copy_e820_map = (memory_map_t *)TBOOT_E820_COPY_ADDR;
 
-static efi_memory_desc_t *efi_memmap_addr = NULL; -static uint32_t 
efi_memmap_size = 0;
-
 static inline void split64b(uint64_t val, uint32_t *val_lo, uint32_t *val_hi)  
{
 *val_lo = (uint32_t)(val & 0x); @@ -691,73 +688,6 @@
 *ram_size = last_fit_size;
 }
 
-#define PAGE_4K (1 << 12)
-
-efi_memory_desc_t
-*get_efi_memmap(uint32_t *memmap_size)
-{
-unsigned int i;
-memory_map_t *mp;
-efi_memory_desc_t *ep;
-uint32_t space_required;
-
-if (efi_memmap_addr == NULL){
-/* we haven't done the conversion yet--is there room? */
-space_required = sizeof(memory_map_t) * g_nr_map +
-sizeof(efi_memory_desc_t) * g_nr_map + 0xf;
-if (space_required >= TBOOT_E820_COPY_SIZE){
-printk(TBOOT_ERR
-   "Insufficient space to make EFI copy of E820 [%d => %d]\n",
-   space_required, TBOOT_E820_COPY_SIZE);
-return NULL;
-}
-/* for fun, we'll align the entries to 0x10 */
-ep = efi_memmap_addr = (efi_memory_desc_t *)
-((TBOOT_E820_COPY_ADDR + sizeof(memory_map_t) * g_nr_map + 0xf)
- & ~0xf);
-/* printk(TBOOT_INFO"efi memmap base now at %p\n", ep); */
-mp = g_copy_e820_map;
-for (i = 0; i < g_nr_map; i++){
-uint64_t length;
-ep[i].phys_addr = ep[i].virt_addr = e820_base_64(mp + i);
-ep[i].pad = 0;
-length = e820_length_64(mp + i);
-length += PAGE_4K - 1;
-length &= ~(PAGE_4K - 1);
-ep[i].num_pages = length / PAGE_4K;
-switch (mp[i].type){
-case E820_RAM:
-ep[i].type = EFI_CONVENTIONAL_MEMORY;
-ep[i].attribute |= EFI_MEMORY_WB;
-break;
-case E820_ACPI:
-ep[i].type = EFI_ACPI_RECLAIM_MEMORY;
-break;
-case E820_NVS:
-ep[i].type = EFI_ACPI_MEMORY_NVS;
-break;
-case E820_UNUSABLE:
-ep[i].type = EFI_UNUSABLE_MEMORY;
-break;
-case E820_GAP:
-case E820_MIXED:
-case E820_RESERVED:
-default:
-ep[i].type = EFI_RESERVED_TYPE;
-break;
-}
-/*
-  printk(TBOOT_INFO
-  "EFI entry %d at %016Lx type %d with %Lx pages\n",
-  i, ep[i].phys_addr, ep[i].type, ep[i].num_pages);
-*/
-efi_memmap_size += sizeof(efi_memory_desc_t);
-}
-}
-*memmap_size = efi_memmap_size;
-return efi_memmap_addr;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tboot/common/linux.c b/tboot/common/linux.c
--- a/tboot/common/linux.c
+++ b/tboot/common/linux.c
@@ -327,6 +327,7 @@
 (struct screen_info_t *)(boot_params->screen_info);
 uint32_t address = 0;
 uint64_t long_address = 0UL;
+uint32_t descr_size = 0, descr_vers = 0, mmap_size = 0, 
+ efi_mmap_addr = 0;
 
 /* loader signature */
 

Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

[Sun, Ning]

Hi Brian,

Do you have other TXT capable server or vPro brand client machine, any 
commercial laptops or desktops are OK, I have HP EliteDesk SFF 800 to run tboot.
Maybe your 2600 server needs a BIOS update or so, I guess.

Regards,
-ning

-Original Message-
From: Brian Luckau [mailto:brian.luc...@hpe.com] 
Sent: Tuesday, January 24, 2017 8:35 AM
To: g...@enjellic.com; Sun, Ning <ning@intel.com>; 
'tboot-devel@lists.sourceforge.net' <tboot-devel@lists.sourceforge.net>
Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

The error code comes from the console output when we boot with UEFI enabled, 
and Intel TXT enabled. It happens sometime before the reset happens.

We are loading the AC module via the bios as far as I can tell. I went to try 
to download a new one so that I could try to specify it in the
grub2 modules but for our processor there did not seem to be a match listed. 
This was a few weeks ago, but I remember concluding that for this board and 
processor, it was expected for it to be loaded from the BIOS and no download 
was available.


On 01/22/2017 11:18 AM, Dr. Greg Wettstein wrote:
> On Jan 17,  3:24pm, Brian Luckau wrote:
> } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat 
> platforms
>
> Good Brian, et.al., I hope the weekend has gone well for everyone.
>
>> Thanks for your responses. I did not forget, just had to juggle some 
>> priorities.
> No problem, everyone is swamped.
>
>> The board we have is Intel s2600KP. I believe the board is custom I'm 
>> told it is not a custom bios implementation.
>>
>> I can tell you the TPM version is currently 1.2.
>>
>> For the  TXT machine Model -- How do we find this out?) Is this a 
>> technical specification of the TPM chip or something more general 
>> like saying "what kind of machine is this? Sorry about the confusion.
>>
>> The micro-architercture is Haswell (Intel(R) Xeon(R) CPU E5-2660 v3).
> So it is an Intel 2600 series server board.
>
> The server class motherboards should have their Authenticated Code 
> Module (ACM) loaded from BIOS.  Is this correct or are you specifying 
> an ACM module in your boot configuration?
>
> If you are not specifying the ACM in the boot stack you may want to 
> try downloading the ACM for this platform class, presumably a 4th 
> generation module and trying that to see if there is any difference in 
> behavior.
>
> If the board is indeed 'custom' this may be the root of the problem as 
> the ACM carries out platform verification checks which may not succeed 
> in the presence of a 'custom' hardware configuration.
>
>> Here is the information that was near the beginning of boot.message:
>>
>> [0.00] ACPI: RSDP 7b7d6014 00024 (v02 INTEL )
> So this is the Root System Description Pointer (RSD) message from a 
> standard boot.  Where did the following message come from which you 
> previously quoted?
>
>>>>>> .00] ACPI BIOS Error (bug): A valid RSDP was not found
>>>>>> (20150930/tbxfroot-243)
> As I noted previously the error code which you posted decodes as
> follows:
>
> Class-C/Major-8/Minor-0  - 'Invalid RSDP'
>
> This in combination with the above 'ACPI BIOS Error' message indicates 
> the ACM is probably resetting the board because it believes there is 
> something wrong with the ACPI implementation on the board.
>
> Ning, any reflections from Intel?
>
> Dr. Greg
>
> }-- End of excerpt from Brian Luckau
>
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.   Specializing in information infra-structure
> Fargo, ND  58102development.
> PH: 701-281-1686
> FAX: 701-281-3949   EMAIL: g...@enjellic.com
> --
>  "We trained hard..but every time we were beginning to 
> form up into
>   teams, we would be reorganised. I was to learn later in life that we
>   tend to meet any new situations by reorganising...  and a
>   wonderful process it can be for creating the illusion of progress,
>   while producing inefficiency and demoralisation."
>  -- Petronius (6 AD)


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] null pointer dereference bug

[Sun, Ning]

Thanks for reporting the bug and providing a fix, the patch passed review and 
validation, we got it upstreamed.

-Ning



From: shiwan...@gohighsec.com [mailto:shiwan...@gohighsec.com]
Sent: Thursday, January 19, 2017 6:32 PM
To: tboot-devel 
Subject: [tboot-devel] null pointer dereference bug

Hi,
There is a null pointer dereference bug when Intel TXT disable within BIOS.
The variable sinit_region_base is used in the function (get_bios_sinit),but it 
is a null pointer dereference when Intel TXT disable within BIOS.
The detail of this prosess can be described as follows:
begin_launch
  copy_sinit
  get_bios_sinit(sinit_region_base)//sinit_region_base is a null 
pointer.

Here is a patch against 1.9.5 which corrects the problem:
---
diff -r 3eccbcd22ef1 -r 836fdebabdb4 tboot/txt/acmod.c
--- a/tboot/txt/acmod.c Wed Jan 18 18:14:32 2017 -0800
+++ b/tboot/txt/acmod.c Fri Jan 20 10:27:18 2017 +0800
@@ -650,6 +650,8 @@
 #ifndef IS_INCLUDED
 acm_hdr_t *get_bios_sinit(const void *sinit_region_base)
 {
+if ( sinit_region_base == NULL )
+   return NULL;
 txt_heap_t *txt_heap = get_txt_heap();
 bios_data_t *bios_data = get_bios_data_start(txt_heap);

@@ -737,6 +739,9 @@
 return NULL;
 }

+if ( sinit_region_base == NULL )
+   return NULL;
+
 /* copy it there */
 memcpy(sinit_region_base, sinit, sinit->size*4);

Thanks,
Wangyi


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] an issue in function (was_last_boot_error(void))

[Sun, Ning]

This is good catch, can you please sign off your patch?

Thanks,
-ning

From: shiwan...@gohighsec.com [mailto:shiwan...@gohighsec.com]
Sent: Sunday, January 15, 2017 10:08 PM
To: tboot-devel 
Subject: [tboot-devel] an issue in function (was_last_boot_error(void))

Hi,

There is an issue in function (was_last_boot_error(void)).
In begin_launch() , there is a was_last_boot_error().In was_last_boot_error() , 
there is a read_tb_error_code().
When read_tb_error_code() runs successfully and the value of parameter error is 
TB_ERR_NONE,the was_last_boot_error()
will return true.This results in displaying "TBOOT: last boot has error" in 
tboot log.

Here is a patch against 1.9.5 which corrects the problem:
---
diff -urNp a/tboot/common/tb_error.c b/tboot/common/tb_error.c
--- a/tboot/common/tb_error.c   2017-01-12 22:20:13.0 -0500
+++ b/tboot/common/tb_error.c   2017-01-16 00:39:14.0 -0500
@@ -193,7 +193,7 @@ bool was_last_boot_error(void)

 /* check TB_LAUNCH_ERR_IDX */
 if ( read_tb_error_code() ) {
-if ( error != TB_ERR_FIXED )
+if ( error != TB_ERR_FIXED && error != TB_ERR_NONE )
 return true;
 }


Thanks
Wangyi
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] null pointer dereference bug

[Sun, Ning]

Thanks for reporting the bug and providing the fix.

Actually, if tpm_detect() were put after verify_acmod() as your patch 
indicated, there would generate another issue of SGX status verification 
failure.
In verify_acmod() , there is a verify_IA32_se_svn_status() which will consume 
some initialized TPM data to do SGX status verification.

Moving verify_IA32_se_svn_status() to end of your patch may resolve the SGX 
issue, but we need more tests on it...

-ning

From: shiwan...@gohighsec.com [mailto:shiwan...@gohighsec.com]
Sent: Saturday, January 14, 2017 1:37 AM
To: tboot-devel 
Subject: [tboot-devel] null pointer dereference bug

Hi,
There is a null pointer dereference bug in the latest version of tboot-1.9.5.
The g_sinit of global variable is used in the function (tpm_detect()),but the 
g_sinit is a null pointer at this time.
The detail of this prosess can be described as follows:
tpm_detect()
  return g_tpm->init(g_tpm);
 tpm_info_list_t *info_list = get_tpm_info_list(g_sinit);//g_sinit 
is a null pointer

Here is a patch against 1.9.5 which corrects the problem:
---
diff -urNp a/tboot/common/tboot.c b/tboot/common/tboot.c
---  a/tboot/common/tboot.c  2017-01-12 22:24:08.0 -0500
+++ b/tboot/common/tboot.c  2017-01-14 12:06:35.816986990 -0500
@@ -384,10 +384,6 @@ void begin_launch(void *addr, uint32_t m
 if ( !copy_e820_map(g_ldr_ctx) )  apply_policy(TB_ERR_FATAL);
 }

-/* make TPM ready for measured launch */
-if (!tpm_detect())
-   apply_policy(TB_ERR_TPM_NOT_READY);
-
 /* we need to make sure this is a (TXT-) capable platform before using */
 /* any of the features, incl. those required to check if the environment */
 /* has already been launched */
@@ -401,6 +397,10 @@ void begin_launch(void *addr, uint32_t m
if (!verify_acmod(g_sinit))
apply_policy(TB_ERR_ACMOD_VERIFY_FAILED);
 }
+
+/* make TPM ready for measured launch */
+if (!tpm_detect())
+   apply_policy(TB_ERR_TPM_NOT_READY);


Thanks
Wangyi
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Real-mode Linux command line buffer overflow

[Sun, Ning]

Hi Ed,

Thanks for reporting this issue, we will root cause and fix the issue as soon 
as we can.
As we do not have an Intel S2600GL machine at hand, to root cause completely 
your issue, can you try this by modifying the config.h file and build the 
tboot.gz:
//#define TBOOT_KERNEL_CMDLINE_SIZE0x0400
#define TBOOT_KERNEL_CMDLINE_SIZE0x0100

This modification will redefine the TBOOT_KERNEL_CMDLINE_SIZE to 256 bytes, if 
this works for your Intel S2600GL system, we need to figure out a way to move 
the tboot kernel command line to other address below 1M.

Thanks,
-ning


-Original Message-
From: Ed Swierk [mailto:eswi...@skyportsystems.com] 
Sent: Tuesday, December 27, 2016 8:01 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Real-mode Linux command line buffer overflow

Current tboot fails to boot a Linux 4.4 kernel on an Intel S2600GL (Xeon 
E5-2600 v2) system, hanging after printing "TBOOT: transfering control to 
kernel @0x100...".

I isolated the problem to the change "Initiaize kernel header comdline buffer 
before copying kernel cmdline arguments to the buffer"
(https://sourceforge.net/p/tboot/code/ci/356ad4b1d363c70d7b25907f812bd411a28eecd3/).
This change tries to avoid leaving trailing garbage on the kernel command line 
by zeroing a 1024-byte buffer.

However, the command line buffer resides in the real-mode boot header, which if 
tboot/include/linux_defns.h is to be believed, leaves only
0x9100 - 0x9000 = 256 bytes for the command line. With this change, tboot ends 
up zeroing another 768 bytes in the "Do not use. Reserved for BIOS EBDA" region.

Also, tboot assumes fixed boundaries for the EBDA (real_mode_base +
0x99100 to real_mode_base + 0xa), while according to 
https://www.kernel.org/doc/Documentation/x86/boot.txt the BIOS decides how much 
space it needs and reports it via int 12h. At least tboot should fail 
gracefully if the BIOS expects more space than tboot reserves.

Finally, there doesn't appear to be any bounds checking on the kernel_cmdline 
string; whatever get_cmdline() returns is blindly memcpyed into the buffer up 
to the first null, possibly overwriting part of the BIOS EBDA with 
user-provided data.

I can hack around the problem on my system by changing LEGACY_REAL_START to 
0x8, but I think a proper fix needs to address the above issues.

--Ed

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, SlashDot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] null pointer dereference bug in tboot Linux loader

[Sun, Ning]

Thanks Dr. Greg Wettstein, the patch was reviewed and merged into tboot source 
code tree.

-ning

-Original Message-
From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] 
Sent: Wednesday, December 14, 2016 12:00 PM
To: Sun, Ning <ning@intel.com>; Brian E Luckau <bluc...@sgi.com>
Cc: tboot-devel@lists.sourceforge.net
Subject: RE: [tboot-devel] null pointer dereference bug in tboot Linux loader

On Dec 14,  5:18pm, "Sun, Ning" wrote:
} Subject: RE: [tboot-devel] null pointer dereference bug in tboot Linux loa

Good afternoon, I hope the day is going well for everyone.

> Is this patch completely from Dr. Wettstein or you made changes as 
> well?  We need to have someone sign off the patch so that we can 
> validate and merge it to tboot tree.

It is all from our development group, here is a patch against virgin
1.9.4 and a signoff.  I was going to send it earlier this week but we have been 
swamped.

---
There is a pointer dereference regression in the tboot native Linux loader 
which manifests itself as a system reset after the following is displayed on 
systems which are not using an initial ramdisk or initramfs image.

TBOOT: transferring control to kernel @0x10

The native linux loader does not check the multiboot module count when 
initializing the initrd/initramfs image size and pointer value.  This causes 
the loader setup code to pass an invalid pointer along with an arbitrary size 
count to the loader which then attempts to copy the contents of whatever memory 
the pointer is referencing into the kernel image that is being built.

The fix is straight forward.  If the remaining multiboot module count is zero 
the initrd image pointer and size value are explicitly set to zero.  This 
condition is interpreted properly by the loader as an indication that an initrd 
image is not to be loaded.

Signed-off-by: Dr. Greg Wettstein <g...@enjellic.com>

diff -urNp v1.9.4/tboot-1.9.4/tboot/common/loader.c 
tboot-1.9.4/tboot/common/loader.c
--- v1.9.4/tboot-1.9.4/tboot/common/loader.cWed May 18 12:20:26 2016
+++ tboot-1.9.4/tboot/common/loader.c   Sat Sep  3 08:45:55 2016
@@ -1272,10 +1272,19 @@ bool launch_kernel(bool is_measured_laun
   MB_MAGIC : MB2_LOADER_MAGIC);
 }
 else if ( kernel_type == LINUX ) {
-m = get_module(g_ldr_ctx,0);
-void *initrd_image = (void *)m->mod_start;
-size_t initrd_size = m->mod_end - m->mod_start;
+void *initrd_image;
+size_t initrd_size;
 
+if ( get_module_count(g_ldr_ctx) == 0 ) {
+initrd_size = 0;
+initrd_image = 0;
+}
+else {
+m = get_module(g_ldr_ctx,0);
+initrd_image = (void *)m->mod_start;
+initrd_size = m->mod_end - m->mod_start;
+}
+
 expand_linux_image(kernel_image, kernel_size,
initrd_image, initrd_size,
_entry_point, is_measured_launch);

---

> Thanks,
> -ning

Have a good remainder of the day.

Greg

}-- End of excerpt from "Sun, Ning"

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"I created a hack to make the division come out right ... I was  relieved 
because I thought I was coding wrong.

 Did you?  It took a guy (Thomas Nicely) with a Ph.D. doing heavy  research in 
computational number theory to find it, yet you found it  while working on a 
game in QuickBasic?"
-- Slashdot

-- 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] tboot release v1.9.5

[Sun, Ning]

Hi,

We are going to have next tboot release v1.9.5 this week, so far planned 
release date is 16 Dec., 2016.
If there are any patches or bug fixes want to be included in this new release, 
please feel free to let us know.

Thanks,
-ning


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] null pointer dereference bug in tboot Linux loader

[Sun, Ning]

We welcome all the patches and bug fixes from tboot community, tboot is a BSD 
licensed open source project, everyone can contribute to it.

All patches will be reviewed and validated before being upstreamed to tboot 
code tree at Sourceforge https://sourceforge.net/projects/tboot/

For this specific patch in this email thread, we did not find it in tboot code 
tree so far. 

It will be good if the patch is signed off when being submitted...

Thanks,
-Ning 

-Original Message-
From: Brian E Luckau [mailto:bluc...@sgi.com] 
Sent: Monday, December 12, 2016 9:55 AM
To: 'tboot-devel@lists.sourceforge.net' 
Subject: [tboot-devel] null pointer dereference bug in tboot Linux loader

In a previous thread, I was given this patch by Dr. Wettstein.  I was trying to 
integrate it into our test build of tboot, but we like to leave a commment that 
shows a trail with regards to where it came from. (we want to make it clear why 
a patch is being done, where it came from, how official it is, etc.)

I can't seem to find this in the tboot code tree.  Is it there and I'm missing 
it?  If it is not there, does the trunk need to be updated with this patch?

=
"There is a null-pointer dereference bug in the tboot Linux loader which 
manifests itself as a system reset after the following is
displayed:

TBOOT: transferring control to kernel @0x10

We picked up on this issue since our embedded systems boot without an external 
initramfs.  The loader doesn't check the multiboot module count and as a result 
uses the value of an uninitialized variable to copy a random amount of material 
into kernel memory.

Here is a patch against 1.9.4 which corrects the problem:

---
diff -urNp v1.9.4/tboot-1.9.4/tboot/common/loader.c 
tboot-1.9.4/tboot/common/loader.c
--- v1.9.4/tboot-1.9.4/tboot/common/loader.cWed May 18 12:20:26 2016
+++ tboot-1.9.4/tboot/common/loader.c   Sat Sep  3 08:45:55 2016
@@ -1272,10 +1272,19 @@ bool launch_kernel(bool is_measured_laun
MB_MAGIC : MB2_LOADER_MAGIC);
  }
  else if ( kernel_type == LINUX ) {
-m = get_module(g_ldr_ctx,0);
-void *initrd_image = (void *)m->mod_start;
-size_t initrd_size = m->mod_end - m->mod_start;
+void *initrd_image;
+size_t initrd_size;
  
+if ( get_module_count(g_ldr_ctx) == 0 ) {
+initrd_size = 0;
+initrd_image = 0;
+}
+else {
+m = get_module(g_ldr_ctx,0);
+initrd_image = (void *)m->mod_start;
+initrd_size = m->mod_end - m->mod_start;
+}
+
  expand_linux_image(kernel_image, kernel_size,
 initrd_image, initrd_size,
 _entry_point, is_measured_launch);"


--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, SlashDot.org! http://sdm.link/slashdot 
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot

[Sun, Ning]

In grub.cfg, find the line "multiboot2  /boot/tboot.gz logging=serial,memory",  
add extpol=sha256 at end of the line.


From: travis.gilb...@dell.com [mailto:travis.gilb...@dell.com]
Sent: Thursday, December 08, 2016 2:23 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] TPM 2.0 + TXT + EFI tboot

I am trying to perform a simple trusted boot on SLES 12 SP2 with TPM 2.0 and 
EFI mode. I can verify that TXT works using getsec64.efi and performing SENTER, 
setting the secrets flag, rebooting and doing SENTER then SEXIT. When I select 
the "tboot 1.9.4" entry in grub2, my server pauses for a bit after the loading 
initial RAM disk step and then reboots. I then get an SINIT error notification 
from BIOS that points to a log error (ERR_BAD_LOG_POINTER_PTR2_MATCH).

I am working with a freshly provisioned TPM and a new install of SLES 12 SP2. I 
added the tboot and tpm2.0-tools packages to that install and modified grub2 to 
give me a tboot prompt (I think I added a file grub-tboot to /etc/default/ to 
accomplish this).

Am I missing anything?

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] SINIT ACM not present on a Workstation-class computer?

[Sun, Ning]

BIOS-based SINIT ACM is a server TXT requirement, not a vPro requirement.
We contacting HP to find the reason why SINIT ACM is not embedded in BIOS for 
their workstation SKU Z240

Regards,
-ning

From: Jan Schermer [mailto:j...@schermer.cz]
Sent: Friday, November 18, 2016 9:52 AM
To: Justin King-Lacroix 
Cc: tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] SINIT ACM not present on a Workstation-class 
computer?

Ah!
I thought BIOS ACM = SINIT ACM embedded in BIOS...
Now I see it's a pre-BIOS code actually.

In any case, TXT works on this system when I load the SINIT module manually, 
but I was hoping it would have it embedded in BIOS like the M900...
It's PITA because I use those systems to test server deployment (where SINIT is 
always provided by the platform AFAIK), it's gonna be hard to make it universal.

Any tips how to best handle SINIT provisioning? Should I detect the platform 
and guess the right SINIT? Or should I simply load few of them and hope it 
works with one of them?

Thanks
Jan

On 18 Nov 2016, at 18:39, Justin King-Lacroix 
> wrote:

IIRC aren't the BIOS ACM and SINIT ACM separate? (And the BIOS may or may not 
contain an SINIT ACM.)

Of course, there might also be a bug in HP's BIOS, in which whatever 
pointer/register needs to be initialised isn't. Wouldn't be the first.

On 18 November 2016 at 12:27, Jan Schermer 
> wrote:
Hi,
I just got HP Z240 workstation (i7-6700 cpu) and it seems to lack SINIT ACM 
embedded in the BIOS
I see this in one of the BIOS changelogs:
• Updates Intel TXT BIOS ACM to v1.3.
^ shouldn't this mean it is there?

tboot says:
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=30c, sizeof(acm_hdr)=4
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=15, sizeof(acm_hdr)=4
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size is too small: acmod_size=66c5200, acm_hdr->size*4=c0c0c0c0
TBOOT: no SINIT AC module found
TBOOT: TXT.SINIT.BASE: 0xb1ed
TBOOT: TXT.SINIT.SIZE: 0x5 (327680)
TBOOT: SINIT ACM not provided.


Is there really no embedded AC module here? I know I can sideload it, but I was 
expecting it to be there (it is there on my other Workstation - Lenovo M900, 
more-or-less the same specs and the same CPU).
It claims to support vPro and I thought one of the requirements was embedded 
SINIT AC module, but maybe I am wrong here...


Thanks
Jan


--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel


--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Cannot boot kernels > 4.6.x (bisected)

[Sun, Ning]

Thanks very much for update.

-ning

-Original Message-
From: N0T3P4D [mailto:n0t3p4d.opensou...@gmail.com] 
Sent: Saturday, October 01, 2016 5:39 AM
To: Sun, Ning <ning@intel.com>
Cc: hubert <hubert1...@qq.com>
Subject: Re: [tboot-devel] Cannot boot kernels > 4.6.x (bisected)

Hi,

I was able to boot kernel 4.7.5 without problems. Thanks a lot for the quick 
fix!

N0T3P4D

On 10/01/16 02:54, Sun, Ning wrote:
> Hi,
> 
> Latest tboot from master:tip can resolve this issue, but I did not have an 
> intensive test yet.
> 
> Thanks,
> -ning
> 
> -Original Message-
> From: N0T3P4D [mailto:n0t3p4d.opensou...@gmail.com] 
> Sent: Thursday, September 22, 2016 12:46 AM
> To: Sun, Ning <ning@intel.com>; tboot-devel@lists.sourceforge.net
> Subject: Re: [tboot-devel] Cannot boot kernels > 4.6.x (bisected)
> 
> Hi,
> 
> Linux 4.6.5 works as expected.
> 
> Thanks
> N0T3P4D
> 
> 
> On 09/22/16 03:19, Sun, Ning wrote:
>> Hi,
>>
>> Thanks for sharing the info, we will look into it, did you find the same 
>> issue with kernel 4.6.x or not?
>>
>> -ning
>>
>> -Original Message-
>> From: N0T3P4D [mailto:n0t3p4d.opensou...@gmail.com]
>> Sent: Wednesday, September 21, 2016 5:01 PM
>> To: tboot-devel@lists.sourceforge.net
>> Subject: [tboot-devel] Cannot boot kernels > 4.6.x (bisected)
>>
>> Hi,
>>
>> when trying to boot Linux kernels > 4.6.x (namely 4.7.x), my system 
>> immediately reboots after tboot hands over to the kernel. No additional 
>> output is shown on the serial console.
>>
>> Bisecting turns up the following Linux commit: 
>> 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda: x86/boot: Move compressed kernel 
>> to the end of the decompression buffer.
>>
>> I've tried both tboot 1.9.4 and the most recent version in the repository 
>> without success.
>>
>> Thanks
>> N0T3P4D
>>
>>
>>
>> --
>>  ___
>> tboot-devel mailing list
>> tboot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
> 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Cannot boot kernels > 4.6.x (bisected)

[Sun, Ning]

Hi,

Thanks for sharing the info, we will look into it, did you find the same issue 
with kernel 4.6.x or not?

-ning

-Original Message-
From: N0T3P4D [mailto:n0t3p4d.opensou...@gmail.com] 
Sent: Wednesday, September 21, 2016 5:01 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Cannot boot kernels > 4.6.x (bisected)

Hi,

when trying to boot Linux kernels > 4.6.x (namely 4.7.x), my system immediately 
reboots after tboot hands over to the kernel. No additional output is shown on 
the serial console.

Bisecting turns up the following Linux commit: 
974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda: x86/boot: Move compressed kernel to 
the end of the decompression buffer.

I've tried both tboot 1.9.4 and the most recent version in the repository 
without success.

Thanks
N0T3P4D



--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] user-provided AC modules

[Sun, Ning]

Hi,

For Intel TXT client platform there is no SINIT ACM embedded in BIOS, user has 
to install client platform specific SINIT ACM to make tboot work on the 
platform.
For Intel TXT server platform, there always has a SINIT ACM in BIOS by default, 
but user have the chance to install a newer version of server specific SINIT 
ACM on your platform storage, like hard drive, tboot will check and use the 
newer version SINIT ACM among those loaded from hard drive and BIOS.

On the same page of TXT dev. Guide, there is also a line says “BIOSes that 
support this element type should report all ACMs that they carry; both BIOS 
ACMs and SINIT ACMs.”
BIOS ACM here refers to another kind of ACM from Intel, which is transparent to 
end user.

-Ning
From: Daniel Mueller [mailto:danielmul...@vmware.com]
Sent: Tuesday, September 20, 2016 9:38 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] user-provided AC modules


Hi,

Looking at the tboot source code it seems to support finding and installing a 
user-provided AC module. Is this feature actually used with recent systems or 
do all systems ship with an ACM installed?

I found the following line in the TXT development 
guide:

Since the TXT architecture requires that BIOS provide at least one BIOS ACM, 
NumAcms must always be greater than 0.

So it appears an ACM must be installed. Are there any known systems violating 
this constraint?

Thanks,
Daniel
​
--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

[Sun, Ning]

*Intel: https://github.com/01org/TPM2.0-TSS
*TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools
*IBM: http://sourceforge.net/projects/ibmtpm20tss/


Regards,
-NIng

-Original Message-
From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] 
Sent: Friday, September 02, 2016 6:51 AM
To: Brian E Luckau ; 'tboot-devel@lists.sourceforge.net' 

Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

On Sep 1,  5:11pm, Brian E Luckau wrote:
} Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms

> Hi,

Good morning Brian, I hope your day is starting out well.

Also greetings to Safayet from GE who I see responded downthread as well.  I 
will integrate his comments below.

> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or 
> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly 
> and the last thing we see before the reboot is:
>
> TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, 
> num_pages=32
> TBOOT: The maximum allowed MTRR range size=256 Pages
> TBOOT: executing GETSEC[SENTER]...
>
> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS 
> is able to boot to completion.
>
> Is this a known issue?

Welcome to SMX development and debugging... :-)

As Safayet commented, the last line is the tboot hypervisor issueing the SENTER 
leaf instruction to initiate execution of the Authenticated Code Model.  Since 
the ACM is specifically designed to prevent it from being debugged or examined, 
the only information available is if the ACM deigns to place an errorcode in 
the TXT.ERRCODE SMX register.

Unfortunately we are tracking a similar problem (ACM platform reset on
GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which gives 
one virtually nothing to go on.  It would be very helpful if you could get the 
TXT.ERRCODE value for everyone to look at if it is other then zero, if it is 
zero that would be a significant finding in and of itself.

Secondly, could you provide a full description of the platform you are 
attempting to implement your MLE on?  Hardware vendor, processor family 
(Broadwell, Skylake, other et.al), chipset and whether or not the hardware has 
a TPM1.2 or a TPM2 chip.  It would also be helpful to know the exact name of 
the ACM module which you are loading.

Thirdly, it would be helpful to know if you are implementing a Platform Owner 
(PO) Launch Control Policy (LCP) and what version and type of the policy you 
are implementing.  Based on our reading of the TXT/SDM, the lcp2_crtpol utility 
provided with the tboot distribution is not capable of generating a valid LCPv3 
control policy if the ACM is processing it as we believe it should be.

If you would like to proceed forward independently on debugging this, check to 
see whether the Platform Supplier (PS) and AUX NVRAM index locations are 
defined.  If you are on a TPM1.2 based system the PS index should be at 
0x5001 and the AUX will be at 0x5002 on platforms which are Ivy Bridge 
and older and 0x5003 on platforms after that.  If you are on a TPM2 based 
system we will be really interested in chatting with you.

If you have PS and AUX registers defined, delete your PO NVram location and try 
booting the system only with the PS and AUX indexes/registers.  I believe the 
standard practice is for OEM board manufacturers to configure an ANY policy in 
the PS index, which doesn't convey any practical security guarantees but will 
usually result in a successful MLE.

Just for the record we have been working for nine months to get a TXT/MLE 
working on TPM2 based Broadwell platforms.  To spare everyone some anguish 
there is no support for manipulating or managing TPM2 based NVram indexes in 
the tboot package.  We built tooling on top of a library which we created from 
the TSE utilities which Ken Goldman's lab at IBM has released.

We are currently seeing the same system reset on GETSEC[SENTER] which Brian is 
reporting.  The reset only occurs if a PO policy is supplied, which is leading 
us to believe that the ACM processing of an LCPv3 PO policy is flawed.  As I 
noted above the tboot utilities are not capable of producing a valid policy, at 
least according to our read of the documentation.

> --Brian Luckau

I hope the above information is useful.  Be glad that you are not trying to do 
SGX development as that is a completely different can of worms :-)(

We will be interested in your findings.

Have a good holiday wekeend.

Greg

}-- End of excerpt from Brian E Luckau

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"Those who will not study history are 

Re: [tboot-devel] no console will be available to OS

[Sun, Ning]

There is an Intel TXT enabling guide from Intel website: 
https://software.intel.com/en-us/articles/intel-trusted-execution-technology-intel-txt-enabling-guide#_Toc383534400.

-ning


-Original Message-
From: Jason Zaman [mailto:ja...@perfinion.com] 
Sent: Wednesday, August 10, 2016 10:36 PM
To: Brian E Luckau <bluc...@sgi.com>
Cc: 'tboot-devel@lists.sourceforge.net' <tboot-devel@lists.sourceforge.net>
Subject: Re: [tboot-devel] no console will be available to OS

On Wed, Aug 10, 2016 at 07:51:16PM -0600, Brian E Luckau wrote:
> Hey, 1.9.4 worked a lot better for me! I had tried a similar exercise 
> ca few weeks ago with whatever was the latest build at the time, but 
> could have been doing something else wrong for all I know.
> 
> This time, I took the same configuration that I mentioned from 30 
> minutes ago but with tboot 1.9.4 and now it is booting. Hopefully I 
> can move on to the next steps in using Trusted Boot.

The documentation for this all is a bit all over the place. I tried to document 
it all in the gentoo wiki when I got things working from help from this ML.
https://wiki.gentoo.org/wiki/Trusted_Boot

> On 08/10/2016 07:26 PM, Brian E Luckau wrote:
> > Thank you for the tips.  I had indeed been trying to get output on 
> > serial as well but not getting anything.
> > I got serial output to happen successfully this time; this is my 
> > current line in grub.cfg:
> >
> > multiboot2  /tboot.gz /tboot.gz logging=serial,memory,vga 
> > loglvl=all serial=115200,8n1,0x2f8
> >
> > Now I'm able to get more information on serial (after adding that 
> > serial= entry)
> >
> > It turns out it is hanging at
> >
> > TBOOT: transfering control to kernel @0x100...
> >
> > SO... I would venture to say people who write in with the "no 
> > console will be available to OS" problem are barking up the wrong 
> > tree, like I was. If you can get the serial output then more might 
> > come to light about what is really happening.
> >
> > We may need to try this on better TXT-enabled hardware with the 
> > right BIOS. However, I'm confused at the fact that it hangs here if 
> > we are using UEFI but not if we are using legacy grub.

Tboot isnt a UEFI aware thing, so you still need to have some compat stuff 
turned on. In my Thinkpad T440s, I have to enable "CSM" otherwise it just dies. 
With CSM enabled, UEFI+grub2+multiboot2 works fine tho.
https://wiki.gentoo.org/wiki/Trusted_Boot#BIOS_configuration

Another thing you can try, if it is resetting and you want to be sure that its 
happening after tboot, put a while(1) {} in tboot right before the jump to the 
kernel and see if it hangs.

You can also boot into the UEFI shell after a reset and run "mem fed30030 4" 
and see what the error code was set to when it died.

-- Jason

> >
> > I'm accustomed to the system booting regardless of whether you have 
> > the hardware, bios, etc. for it. You just would not get a measured 
> > boot.  So, still scratching my head here.
> >
> >
> > -- Brian
> >
> > On 07/31/2016 01:54 PM, Brian Luckau wrote:
> >> Re: [tboot-devel] no console will be available to OS Will try that 
> >> when I Wade back onto it again. Last week tried we could get it to 
> >> work with legacy bios but not EFI
> >>
> >> -Original Message-
> >> *From: *Jason Zaman [ja...@perfinion.com 
> >> <mailto:ja...@perfinion.com>]
> >> *Sent: *Sunday, July 31, 2016 09:51 AM Central Standard Time
> >> *To: *Justin King-Lacroix
> >> *Cc: *tboot-devel@lists.sourceforge.net
> >> *Subject: *Re: [tboot-devel] no console will be available to OS
> >>
> >> On Fri, Jul 29, 2016 at 01:01:46PM -0700, Justin King-Lacroix wrote:
> >> > Nope, doesn't work on (at least) recent Lenovo laptops. Tried it 
> >> > a few weeks back.
> >> >
> >> > Getting the same "WARNING: no console will be available to OS" on
> >> 1.9.4,
> >> > too.
> >> >
> >> > On 29 July 2016 at 09:26, Sun, Ning <ning@intel.com> wrote:
> >> >
> >> > > There is a latest tboot 1.9.4 to download on sourceforge 
> >> > > https://sourceforge.net/projects/tboot/
> >> > > You can collect tboot output through serial port in a UEFI boot.
> >> > > For install and run tboot in UEFI, you also can follow the wiki 
> >> > > here https://sourceforge.net/p/tboot/wiki/Home/.
> >> > > README in tboot source code tree is very helpful as well.
> >> > > Hope this helps.
> >> > >
> >> &

Re: [tboot-devel] Crash/system reset with linux 4.4

[Sun, Ning]

Just got .hg removed from the tboot-1.9.4.tar.gz to reduce the tarball size, 
other things remains same as tagged for v1.9.4 release.
There has been many changes since 1.8.3, so we made the latest release version 
1.9.4 by skipping many internal release updates.


Thanks,
-Ning

-Original Message-
From: Marek Marczykowski-Górecki [mailto:marma...@invisiblethingslab.com] 
Sent: Saturday, August 06, 2016 3:03 AM
To: Chris Laprise <tas...@openmailbox.org>
Cc: Jan Schermer <j...@schermer.cz>; Sun, Ning <ning@intel.com>; 
tboot-devel@lists.sourceforge.net; Andrew David Wong <a...@qubes-os.org>
Subject: Re: [tboot-devel] Crash/system reset with linux 4.4

On Sat, Aug 06, 2016 at 05:24:45AM -0400, Chris Laprise wrote:
> On 08/05/2016 02:57 PM, Jan Schermer wrote:
> > Newest compiled from git current (that is about 1 month ago, haven't 
> > touched that since).
> > I hit other problems, but nothing that min_ram would fix.
> > But that was Ubuntu distribution kernel - no idea what Qubes kernel has 
> > inside in terms of patches etc...
> > I can maybe try Qubes kernel on Monday for you, to see if it boots on my hw 
> > and with my tboot.
> > Tboot 1.8.2 is old and there are vulnerabilities that make it worthless in 
> > terms of security anyway (unless they backported the patches of course).
>
> Thanks. I don't know why Fedora (Qubes dom0) hasn't updated tboot in 
> their repo; I'll try a newer version as your feedback suggests.

Where I can find *signed* tboot source code? Also, why 1.9.4 tarball is four 
times bigger than previous? Is it because inclusion of ".hg"?
Sounds like a mistake...
Also having 1.9.4 just after 1.8.3 sounds suspicious.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] memory-logging buffer-overflow issues

[Sun, Ning]

Good catch Safayet, your patch passed review and validation, I corrected a typo 
in comment line in lz.c .  the patch was merged.


Thanks,
-Ning

From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com]
Sent: Tuesday, July 05, 2016 8:08 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] memory-logging buffer-overflow issues

The attached patch addresses minor buffer-overflow issues and potential 
buffer-overflow issues in the memory-logging code.

1) The LZ-compress function have been modified to accept an output-buffer size. 
The header file and the memory-logging function that invokes the compress 
function have been modified accordingly.

2) A number of buffer overflow issues have been fixed in the memlog_write 
function in tboot/common/printk.c. The issues are mentioned below. In addition, 
comments have been added and the code modified to improve readability:

a) At the start of the function, g_log->zip_count may be ZIP_COUNT_MAX. Line 
105 reads (g_log->zip_pos[g_log->zip_count]) without checking g_log->zip_count. 
Line 106 reads (g_log->zip_pos[g_log->zip_count]) before checking 
g_log->zip_count.

b) Line 109 increments g_log->zip_count. After this point, g_log->zip_count may 
be ZIP_COUNT_MAX.  Lines 111, 112, 113, and 115 read and write to 
(g_log->zip_pos[g_log->zip_count]) without checking g_log->zip_count.

c) Line 99 compares (count) against (g_log->max_size). Line 103 compares 
(g_log->curr_pos + count) to (g_log->max_size). Line 105 compares 
(g_log->zip_pos[g_log->zip_count] + zip_size + count) to (g_log->max_size). 
However, line 131 can potentially write a single NULL-terminator past the end 
of the space that the previously mentioned lines check for (checking for 
"count" but potentially writing "count+1").

Signed-off-by: Safayet Ahmed >

thanks,

Safayet
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Questions about LCP x VLP

[Sun, Ning]

Hi Jason,

Did you try the S3 resume with VLP policy "continue"? 
Is the result same with VLP policy "nonfatal"?

Generally "nonfatal" and "continue " are not completed same, just like 
addressed in tboot README file.

-ning

-Original Message-
From: Jason Zaman [mailto:ja...@perfinion.com] 
Sent: Thursday, June 23, 2016 8:57 AM
To: Sun, Ning <ning@intel.com>
Cc: tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] Questions about LCP x VLP

On Mon, Jun 20, 2016 at 04:08:14PM +, Sun, Ning wrote:
> 
> This is what I got from the Readme, not sure if you already take into 
> consideration of it within your patch:
> 
> tboot will attempt to seal the module measurements using the TPM so that if 
> it is put into S3 it can restore the correct PCR values on resume.  In order 
> for this to work, the TPM must be owned and the SRK auth must be set to all 
> 0s.  This can be done using the '-z' flag to tpm_takeownership.  If the tboot 
> policy being used is 'nonfatal' and the seal operation fails, tboot will 
> continue the boot.  However, for 'continue' or 'halt' policy types, tboot 
> will halt the boot.

Hey Ning,

I believe that should not be an issue. My patch just adds the hash of 0x12, 34, 
56 into VL_ENTRIES(NUM_VL_ENTRIES) which is the same place all the other hashes 
are added and during the verification time. Sealing into the TPM happens after 
that verification so should not have any issues. My patch does not touch the 
TPM directly at all, it only adds to that hash list which tboot later extends 
into the actual TPM.

I tried using g_tpm->cap_pcrs( , 18) before but that did not work which 
must be for the reason you stated.

Also, the 0x123456 is completely arbitrary and can be changed if another value 
makes more sense.

-- Jason


> Thanks,
> -ning
> 
> -Original Message-
> From: Jason Zaman [mailto:ja...@perfinion.com]
> Sent: Saturday, June 18, 2016 9:10 PM
> To: Jan Schermer <j...@schermer.cz>
> Cc: tboot-devel@lists.sourceforge.net
> Subject: Re: [tboot-devel] Questions about LCP x VLP
> 
> On Mon, May 09, 2016 at 12:58:48PM +0200, Jan Schermer wrote:
> > > On 09 May 2016, at 12:50, martin.wi...@ts.fujitsu.com wrote:
> > >> I sort_of_assumed that PCR-18 would only be present if the policy 
> > >> verification passed, and would be different different (or all 0s) when 
> > >> the verification failed.
> > >> This is a bit dangerous if anyone uses it.
> > > 
> > > You need to use "halt" policy.
> > > 
> > >> I think something simple like hashing "1" into it when it fails 
> > >> verification would make it useful
> > > 
> > > If your system is compromised, how do you ensure that this 
> > > actually happens? If you use "halt" policy, the system won't boot 
> > > with a tampered kernel/initrd unless TXT is off. If  TXT is off, PCR 18 
> > > will be invalid.
> > > 
> > > So my recommendation is: "halt" policy, pcr_map=da, and protect 
> > > sensitive data by sealing it against PCR 18. Unless I am 
> > > overlooking something, that should be reasonably safe.
> > Yes, I get it and for me this is fine.
> > 
> > But if anyone wants to use it with "nonfatal" policy (which could be a 
> > valid scenario) then this would make it useful - the system will still boot 
> > but any secrets won't unseal because of invalid PCR. One can then possibly 
> > fix whatever went wrong (like not generating a new policy on kernel upgrade 
> > by mistake) without having to powercycle the server, revert the policy etc.
> > In other words, sysadmins usually prefer a booting system they can 
> > fix to one that just halts :-)
> > 
> > Jan
> > > Martin
> 
> Hi All,
> 
> First off, I wanted to thank you guys, this thread helped me a ton finally 
> understanding and getting it fully working on my laptop. It'd been on the 
> backburner for ages.
> 
> I agree with the preference for a system that actually boots. I made a proof 
> of concept that caps PCR18 on a verification failure. I dont really see why 
> we would need both nonfatal(for testing) and continue(not that useful) so I 
> repurposed continue. Making a brand new policy type too would also be easy 
> from the looks of it. Is continue used for something else that I am not aware 
> of that a patch like this would break?
> 
> What do you think of an approach like this? Can you give it a whirl? I have 
> only tested it on my laptop so more testing is needed. It only extends the 
> value once so calculating the good and failed values is easy.
> 
> -- Jason
&g

Re: [tboot-devel] Loading multiboot(2) images

[Sun, Ning]

This patch was merged, and tboot is an open source project, anyone can 
contribute to it, we encourage more and more patches and bug fixes from tboot 
community.

Thanks,
-Ning

-Original Message-
From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com] 
Sent: Thursday, June 16, 2016 8:14 AM
To: Jan Schermer <j...@schermer.cz>
Cc: tboot-devel@lists.sourceforge.net; Sun, Ning <ning@intel.com>
Subject: [tboot-devel] Loading multiboot(2) images

Thanks Jan,

Giving this another shot as an attachment this time.

Safayet

-Original Message-
From: Jan Schermer [mailto:j...@schermer.cz]
Sent: Thursday, June 16, 2016 11:07 AM
To: Ahmed, Safayet (GE Global Research, US)
Cc: tboot-devel@lists.sourceforge.net; Sun, Ning [ning@intel.com]
Subject: EXT: Re: [tboot-devel] Loading multiboot(2) images

The problem is you didn't attach it but pasted it inline (or so it appears).
When I copy it, it lacked space indentations on some lines and patch 
complained. I had to copy it in Textedit I think...

Jan

> On 16 Jun 2016, at 15:53, Ahmed, Safayet (GE Global Research, US) 
> <safayet.ah...@ge.com> wrote:
> 
> I'm sorry, Ning. I'm not sure what went wrong.
> 
> I've attached the patch again below. It applies to Changeset 451 
> (356ad4b1d363).
> 
> I generated the patch using the command "hg diff -apU 3 > 
> ../tboot-16-06-2016.patch".
> 
> I was able to apply the patch from the tboot source directory using the 
> command "patch -p 1 < ../tboot-16-06-2016.patch".
> 
> Please let me know if this works
> 
>  PATCH STARTS BELOW THIS LINE
> ** diff -r 356ad4b1d363 tboot/common/elf.c
> --- a/tboot/common/elf.c  Thu Jun 09 10:53:29 2016 -0700
> +++ b/tboot/common/elf.c  Thu Jun 16 09:07:21 2016 -0400
> @@ -145,9 +145,7 @@ bool is_elf_image(const void *image, siz
> return false;
> }
> 
> -#if 0
> -static bool get_elf_image_range(const elf_header_t *elf, void **start,
> -void **end)
> +bool get_elf_image_range(const elf_header_t *elf, void **start, void
> +**end)
> {
> uint32_t u_start, u_end;
> 
> @@ -188,7 +186,6 @@ static bool get_elf_image_range(const el
> return true;
> }
> }
> -#endif
> 
> bool expand_elf_image(const void *image, void **entry_point) { diff -r
> 356ad4b1d363 tboot/common/loader.c
> --- a/tboot/common/loader.c   Thu Jun 09 10:53:29 2016 -0700
> +++ b/tboot/common/loader.c   Thu Jun 16 09:07:21 2016 -0400
> @@ -3,6 +3,7 @@
>  *   binaries
>  *
>  * Copyright (c) 2006-2013, Intel Corporation
> + * Copyright (c) 2016 Real-Time Systems GmbH
>  * All rights reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without 
> @@ -64,7 +65,7 @@ extern tboot_shared_t _tboot_shared;
> 
> /* multiboot struct saved so that post_launch() can use it (in
> tboot.c) */ extern loader_ctx *g_ldr_ctx;
> -
> +extern bool get_elf_image_range(const elf_header_t *elf, void 
> +**start, void **end);
> extern bool is_elf_image(const void *image, size_t size); extern bool 
> expand_elf_image(const elf_header_t *elf, void **entry_point); extern 
> bool expand_linux_image(const void *linux_image, size_t linux_size, @@
> -769,6 +770,98 @@ unsigned long get_mbi_mem_end_mb1(const
> return PAGE_UP(end);
> }
> 
> +/*
> + * Move all mbi components/modules/mbi to end of memory  */ static 
> +bool move_modules_to_high_memory(loader_ctx *lctx) {
> +uint64_t max_ram_base = 0,
> + max_ram_size = 0;
> +uint32_t memRequired = 0;
> +
> +uint32_t module_count = get_module_count(lctx);
> +
> +for ( unsigned int i = 0; i < module_count; i++ )
> +{
> +module_t *m = get_module(lctx,i);
> +memRequired += PAGE_UP(m->mod_end - m->mod_start);
> +}
> +
> +get_highest_sized_ram(memRequired, 0x1ULL, _ram_base, 
> _ram_size);
> +if(!max_ram_base || !max_ram_size)
> +{
> +printk(TBOOT_INFO"ERROR No suitable memory area found for image 
> relocation!\n");
> + printk(TBOOT_INFO"required 0x%X\n", memRequired);
> +return false;
> +}
> +
> +printk(TBOOT_INFO"highest suitable area @ 0x%llX (size 
> + 0x%llX)\n", max_ram_base, max_ram_size);
> +
> +unsigned long target_addr =  PAGE_DOWN(max_ram_base + 
> + max_ram_size);
> +
> +for ( unsigned int i = 0; i < module_count; i++ )
> +{
> +unsigned long base, size;
> +module_t *m = get_module(lctx,i);
> +base = m->mod_start;
> +size = m->mod_end - m->mod_start;
> +printk(TBOOT_INFO"moving module 

Re: [tboot-devel] Loading multiboot(2) images

[Sun, Ning]

Looks like the patches were corrupted, can you send again?


Thanks,
-ning

-Original Message-
From: Ahmed, Safayet (GE Global Research, US) [mailto:safayet.ah...@ge.com] 
Sent: Monday, June 13, 2016 7:53 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] Loading multiboot(2) images

We have been experimenting with measured launch of environments other than 
Linux and Xen, such as the RTS hypervisor and some real-time operating systems. 

We have seen a recurring issue in some cases with the way TBoot launches 
multiboot/multiboot2 environments. Namely, when loading the ELF image, TBoot 
overwrites the kernel ELF image and modules.

Developers at RTS have made changes to "tboot/common/loader.c" and 
"tboot/common/elf.c" that addresses this issue:
When the follow-on kernel is a multiboot or multiboot2 kernel, move the modules 
to the top of memory as reported in the E820 map. Then, after loading the 
kernel ELF binary into its final location in memory, move the modules to a 
location just above the kernel.

The patches for these changes are below.

thanks,

Safayet

Signed-off-by: Raphael Baum  
Signed-off-by: Safayet Ahmed 

diff -r 6531a0eaf369 tboot/common/elf.c
--- a/tboot/common/elf.cWed May 18 10:13:24 2016 -0700
+++ b/tboot/common/elf.cMon Jun 13 10:19:02 2016 -0400
@@ -146,7 +146,5 @@
 }
 
-#if 0
-static bool get_elf_image_range(const elf_header_t *elf, void **start,
-void **end)
+bool get_elf_image_range(const elf_header_t *elf, void **start, void 
+**end)
 {
 uint32_t u_start, u_end;
@@ -189,5 +187,4 @@
 }
 }
-#endif
 
 bool expand_elf_image(const void *image, void **entry_point) diff -r 
6531a0eaf369 tboot/common/loader.c
--- a/tboot/common/loader.cWed May 18 10:13:24 2016 -0700
+++ b/tboot/common/loader.cMon Jun 13 10:19:02 2016 -0400
@@ -4,4 +4,5 @@
  *
  * Copyright (c) 2006-2013, Intel Corporation
+ * Copyright (c) 2016 Real-Time Systems GmbH
  * All rights reserved.
  *
@@ -65,5 +66,5 @@
 /* multiboot struct saved so that post_launch() can use it (in tboot.c) */  
extern loader_ctx *g_ldr_ctx;
-
+extern bool get_elf_image_range(const elf_header_t *elf, void **start, 
+void **end);
 extern bool is_elf_image(const void *image, size_t size);  extern bool 
expand_elf_image(const elf_header_t *elf, void **entry_point); @@ -770,4 
+771,96 @@  }
 
+/*
+ * Move all mbi components/modules/mbi to end of memory  */ static bool 
+move_modules_to_high_memory(loader_ctx *lctx) {
+uint64_t max_ram_base = 0,
+ max_ram_size = 0;
+uint32_t memRequired = 0;
+
+uint32_t module_count = get_module_count(lctx);
+
+for ( unsigned int i = 0; i < module_count; i++ )
+{
+module_t *m = get_module(lctx,i);
+memRequired += PAGE_UP(m->mod_end - m->mod_start);
+}
+
+get_highest_sized_ram(memRequired, 0x1ULL, _ram_base, 
_ram_size);
+if(!max_ram_base || !max_ram_size)
+{
+printk(TBOOT_INFO"ERROR No suitable memory area found for image 
relocation!\n");
+printk(TBOOT_INFO"required 0x%X\n", memRequired);
+return false;
+}
+
+printk(TBOOT_INFO"highest suitable area @ 0x%llX (size 0x%llX)\n", 
+ max_ram_base, max_ram_size);
+
+unsigned long target_addr =  PAGE_DOWN(max_ram_base + 
+ max_ram_size);
+
+for ( unsigned int i = 0; i < module_count; i++ )
+{
+unsigned long base, size;
+module_t *m = get_module(lctx,i);
+base = m->mod_start;
+size = m->mod_end - m->mod_start;
+printk(TBOOT_INFO"moving module %u (%lu bytes) from 0x%08X ", 
+ i, size, (uint32_t)base);
+
+//calculate target addresses
+target_addr = PAGE_DOWN(target_addr - size);
+printk(TBOOT_INFO"to 0x%08X\n", (uint32_t)target_addr);
+
+memcpy((void *)target_addr, (void *)base, size);
+m->mod_start = target_addr;
+m->mod_end = target_addr + size;
+}
+
+return true;
+}
+
+/*
+ * Move any mbi components/modules/mbi that just above the kernel  */ 
+static bool move_modules_above_elf_kernel(loader_ctx *lctx, 
+elf_header_t *kernel_image) {
+if (LOADER_CTX_BAD(lctx))
+return false;
+
+/* get end address of loaded elf image */
+void *elf_start=NULL, *elf_end=NULL;
+if ( !get_elf_image_range(kernel_image, _start, _end) )
+{
+printk(TBOOT_INFO"ERROR: failed tget elf image range\n");
+}
+
+printk(TBOOT_INFO"ELF kernel top is at 0x%X\n", (uint32_t)elf_end);
+
+/* keep modules page aligned */
+uint32_t target_addr = PAGE_UP((uint32_t)elf_end);
+
+uint32_t module_count = get_module_count(lctx);
+
+for ( unsigned int i = 0; i < module_count; i++ )
+{
+unsigned long base, size;
+module_t *m = get_module(lctx,i);
+base = m->mod_start;
+size = m->mod_end - m->mod_start;
+printk(TBOOT_INFO"moving module %u (%lu bytes) from 0x%08X ", 
+ i, size, 

Re: [tboot-devel] [PATCH] Check for VMX support before reading feature control MSR

[Sun, Ning]

> Is this the only supported hardware to run tboot ? I thought it's expected to 
> just run like a regular bootloader if it was not able to use txt.
Yes, tboot is for Intel TXT platform.

> I believe the impact is low for real hardware. The way this would happen on 
> real hardware would be to run an old enough processor that didn't support 
> vmx/smx. Then hardware would emit the same GP and would crash tboot.

You are right, let Tony validate your updated patch and send back to me with 
your signed-off signatures: 

+/* read feature control msr if processor supports VMX or SMX instructions 
*/
+if ( (g_cpuid_ext_feat_info & CPUID_X86_FEATURE_VMX) ||
+ (g_cpuid_ext_feat_info & CPUID_X86_FEATURE_SMX) ) {
+g_feat_ctrl_msr = rdmsr(MSR_IA32_FEATURE_CONTROL);
+printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n", g_feat_ctrl_msr);
+}



-Original Message-
From: Bandan Das [mailto:b...@redhat.com] 
Sent: Tuesday, May 10, 2016 3:03 PM
To: Sun, Ning <ning@intel.com>
Cc: Tony Camuso <tcam...@redhat.com>; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] [PATCH] Check for VMX support before reading feature 
control MSR

"Sun, Ning" <ning@intel.com> writes:

> Was there any failure caused by reading this MSR when you run current 
> tboot on a bare-metal machine TXT enabled machine?

Is this the only supported hardware to run tboot ? I thought it's expected to 
just run like a regular bootloader if it was not able to use txt.

> Or you just found this issue when running tboot in KVM guest?

That is correct, this was identified when running as a KVM guest because it 
does not expose this msr by default.

> This is very helpful for us to identify the impact of this issue.

I believe the impact is low for real hardware. The way this would happen on 
real hardware would be to run an old enough processor that didn't support 
vmx/smx. Then hardware would emit the same GP and would crash tboot.

>
> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
> Sent: Tuesday, May 10, 2016 2:37 PM To: Sun, Ning <ning@intel.com>
> Cc: Tony Camuso <tcam...@redhat.com>;
> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
> Check for VMX support before reading feature control MSR
>
> "Sun, Ning" <ning@intel.com> writes:
>
>> Tboot should run on bare-metal TXT enabled platform, it is not 
>> supposed to run in a virtual machine environment.
>
> Umm... how is that got anything to do with following the spec ?
>
>> -ning
>> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
>> Sent: Tuesday, May 10, 2016 12:24 PM To: Sun, Ning 
>> <ning@intel.com> Cc: Tony Camuso <tcam...@redhat.com>; 
>> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
>> Check for VMX support before reading feature control MSR "Sun, Ning" 
>> <ning@intel.com> writes:
>>
>>>> BTW, table 35-2 in the spec says the msr is present if 
>>>> cpuid.01h.ecx(bit 5 or 6) is 1. I think we should check for both 
>>>> vmx and smx before trying the read ?
>>> "msr is present if cpuid.01h.ecx(bit 5 or 6) is 1" , that means you 
>>> can check one of those bits to determine presence of the MSR.  As 
>>> you want to see VMX register is exposed to KVM in Kernel and Guest 
>>> VM, it
>> The bug is that KVM isn't exposing feature control msr unless
>> nested=1 and if tboot tries to read it, gets injected with a GP.
>> However, with real hardware, feature control msr is valid if either 
>> bit 5 or 6 is 1.
>> So, your patch should be: + /* read feature control msr if processor 
>> supports VMX or SMX instructions */ + if ( (g_cpuid_ext_feat_info &
>> CPUID_X86_FEATURE_VMX) || + (g_cpuid_ext_feat_info &
>> CPUID_X86_FEATURE_SMX) ) { + g_feat_ctrl_msr = 
>> rdmsr(MSR_IA32_FEATURE_CONTROL); +
>> printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n", 
>> g_feat_ctrl_msr); + }
>>
>>> is enough to check vmx in tboot.
>>> -Ning
>>> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
>>> Sent: Tuesday, May 10, 2016 10:53 AM To: Sun, Ning 
>>> <ning@intel.com> Cc: Tony Camuso <tcam...@redhat.com>; 
>>> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
>>> Check for VMX support before reading feature control MSR "Sun, Ning" 
>>> <ning@intel.com> writes:
>>>
>>>> BanDan, Tony, We tried out your patch, unfortunately it did not 
>>>> work on our machines, did you test your patch 

Re: [tboot-devel] [PATCH] Check for VMX support before reading feature control MSR

[Sun, Ning]

Was there any failure caused by reading this MSR when you run current tboot on 
a bare-metal machine TXT enabled machine?

Or you just found this issue when running tboot in KVM guest?

This is very helpful for us to identify the impact of this issue.


-Original Message-
From: Bandan Das [mailto:b...@redhat.com] 
Sent: Tuesday, May 10, 2016 2:37 PM
To: Sun, Ning <ning@intel.com>
Cc: Tony Camuso <tcam...@redhat.com>; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] [PATCH] Check for VMX support before reading feature 
control MSR

"Sun, Ning" <ning@intel.com> writes:

> Tboot should run on bare-metal TXT enabled platform, it is not supposed to 
> run in a virtual machine environment.

Umm... how is that got anything to do with following the spec ?

> -ning
>
> -Original Message-
> From: Bandan Das [mailto:b...@redhat.com]
> Sent: Tuesday, May 10, 2016 12:24 PM
> To: Sun, Ning <ning@intel.com>
> Cc: Tony Camuso <tcam...@redhat.com>; 
> tboot-devel@lists.sourceforge.net
> Subject: Re: [tboot-devel] [PATCH] Check for VMX support before 
> reading feature control MSR
>
> "Sun, Ning" <ning@intel.com> writes:
>
>>> BTW, table 35-2 in the spec says the msr is present if 
>>> cpuid.01h.ecx(bit 5 or 6) is 1. I think we should check for both vmx 
>>> and smx before trying the read ?
>>
>> "msr is present if cpuid.01h.ecx(bit 5 or 6) is 1" , that means you 
>> can check one of those bits to determine presence of the MSR.  As you 
>> want to see VMX register is exposed to KVM in Kernel and Guest VM, it
>
> The bug is that KVM isn't exposing feature control msr unless nested=1 and if 
> tboot tries to read it, gets injected with a GP.
>
> However, with real hardware, feature control msr is valid if either bit 5 or 
> 6 is 1.
>
> So, your patch should be:
> +/* read feature control msr if processor supports VMX or SMX 
> instructions */
> +if ( (g_cpuid_ext_feat_info & CPUID_X86_FEATURE_VMX) ||
> + (g_cpuid_ext_feat_info & CPUID_X86_FEATURE_SMX) ) {
> +g_feat_ctrl_msr = rdmsr(MSR_IA32_FEATURE_CONTROL);
> +printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n", 
> g_feat_ctrl_msr);
> +}
>
>> is enough to check vmx in tboot.
>>
>> -Ning
>>
>> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
>> Sent: Tuesday, May 10, 2016 10:53 AM To: Sun, Ning 
>> <ning@intel.com> Cc: Tony Camuso <tcam...@redhat.com>; 
>> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
>> Check for VMX support before reading feature control MSR
>>
>> "Sun, Ning" <ning@intel.com> writes:
>>
>>> BanDan, Tony,
>>> We tried out your patch, unfortunately it did not work on our 
>>> machines, did you test your patch before submitting it?
>>
>> Sorry, my bad! I didn't realize we need the msr read even before we
>>> get to checking for vmx.
>>
>> BTW, table 35-2 in the spec says the msr is present if
>>> cpuid.01h.ecx(bit 5 or 6) is 1. I think we should check for both vmx 
>>> and smx before trying the read ?
>>
>> Bandan
>>
>>> -ning
>>> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
>>> Sent: Thursday, May 05, 2016 10:02 AM To: Sun, Ning 
>>> <ning@intel.com> Cc: Tony Camuso <tcam...@redhat.com>; 
>>> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
>>> Check for VMX support before reading feature control MSR "Sun, Ning"
>>> <ning@intel.com> writes:
>>>
>>>> Hi Tony, Bandan, Thanks very much for pointing out the bug and 
>>>> providing the fix.  Here is an alternative patch, in which just one 
>>>> function was modified, let me know if there is any question about
>>>> it:
>>> I still prefer the first version because we already have a function
>>> supports_vmx() to check for support and this check below results in
>>>> duplicate code. Or probably just fold supports_vmx() in here if you 
>>>> want to go with this version.
>>> Thanks for the review!  Bandan
>>>
>>>> diff -r 1ed81e157733 tboot/txt/verify.c --- a/tboot/txt/verify.c 
>>>> Wed Apr 20 16:31:18 2016 -0700 +++ b/tboot/txt/verify.c Wed May 04
>>>> 17:46:30 2016 -0700 @@ -109,8 +109,13 @@ } g_cpuid_ext_feat_info = 
>>>> cpuid_ecx(1); - g_feat_ctrl_msr = rdmsr(MSR_IA32_FEATURE_CONTROL);
>>>> - printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n

Re: [tboot-devel] [PATCH] Check for VMX support before reading feature control MSR

[Sun, Ning]

Tboot should run on bare-metal TXT enabled platform, it is not supposed to run 
in a virtual machine environment.

-ning

-Original Message-
From: Bandan Das [mailto:b...@redhat.com] 
Sent: Tuesday, May 10, 2016 12:24 PM
To: Sun, Ning <ning@intel.com>
Cc: Tony Camuso <tcam...@redhat.com>; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] [PATCH] Check for VMX support before reading feature 
control MSR

"Sun, Ning" <ning@intel.com> writes:

>> BTW, table 35-2 in the spec says the msr is present if 
>> cpuid.01h.ecx(bit 5 or 6) is 1. I think we should check for both vmx 
>> and smx before trying the read ?
>
> "msr is present if cpuid.01h.ecx(bit 5 or 6) is 1" , that means you 
> can check one of those bits to determine presence of the MSR.  As you 
> want to see VMX register is exposed to KVM in Kernel and Guest VM, it

The bug is that KVM isn't exposing feature control msr unless nested=1 and if 
tboot tries to read it, gets injected with a GP.

However, with real hardware, feature control msr is valid if either bit 5 or 6 
is 1.

So, your patch should be:
+/* read feature control msr if processor supports VMX or SMX instructions 
*/
+if ( (g_cpuid_ext_feat_info & CPUID_X86_FEATURE_VMX) ||
+ (g_cpuid_ext_feat_info & CPUID_X86_FEATURE_SMX) ) {
+g_feat_ctrl_msr = rdmsr(MSR_IA32_FEATURE_CONTROL);
+printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n", g_feat_ctrl_msr);
+}

> is enough to check vmx in tboot.
>
> -Ning
>
> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
> Sent: Tuesday, May 10, 2016 10:53 AM To: Sun, Ning 
> <ning@intel.com> Cc: Tony Camuso <tcam...@redhat.com>; 
> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
> Check for VMX support before reading feature control MSR
>
> "Sun, Ning" <ning@intel.com> writes:
>
>> BanDan, Tony,
>> We tried out your patch, unfortunately it did not work on our 
>> machines, did you test your patch before submitting it?
>
> Sorry, my bad! I didn't realize we need the msr read even before we
>> get to checking for vmx.
>
> BTW, table 35-2 in the spec says the msr is present if
>> cpuid.01h.ecx(bit 5 or 6) is 1. I think we should check for both vmx 
>> and smx before trying the read ?
>
> Bandan
>
>> -ning
>> -Original Message- From: Bandan Das [mailto:b...@redhat.com]
>> Sent: Thursday, May 05, 2016 10:02 AM To: Sun, Ning 
>> <ning@intel.com> Cc: Tony Camuso <tcam...@redhat.com>; 
>> tboot-devel@lists.sourceforge.net Subject: Re: [tboot-devel] [PATCH] 
>> Check for VMX support before reading feature control MSR "Sun, Ning" 
>> <ning@intel.com> writes:
>>
>>> Hi Tony, Bandan, Thanks very much for pointing out the bug and 
>>> providing the fix.  Here is an alternative patch, in which just one 
>>> function was modified, let me know if there is any question about
>>> it:
>> I still prefer the first version because we already have a function
>> supports_vmx() to check for support and this check below results in
>>> duplicate code. Or probably just fold supports_vmx() in here if you 
>>> want to go with this version.
>> Thanks for the review!  Bandan
>>
>>> diff -r 1ed81e157733 tboot/txt/verify.c --- a/tboot/txt/verify.c Wed 
>>> Apr 20 16:31:18 2016 -0700 +++ b/tboot/txt/verify.c Wed May 04
>>> 17:46:30 2016 -0700 @@ -109,8 +109,13 @@ } g_cpuid_ext_feat_info = 
>>> cpuid_ecx(1); - g_feat_ctrl_msr = rdmsr(MSR_IA32_FEATURE_CONTROL);
>>> - printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n", 
>>> g_feat_ctrl_msr); + /* read feature control msr if processor 
>>> supports VMX instructions */ + if ( (g_cpuid_ext_feat_info &
>>> CPUID_X86_FEATURE_VMX) ) { + g_feat_ctrl_msr = 
>>> rdmsr(MSR_IA32_FEATURE_CONTROL); +
>>> printk(TBOOT_DETA"IA32_FEATURE_CONTROL_MSR: %08lx\n", 
>>> g_feat_ctrl_msr); + } + else + printk(TBOOT_DETA"CPU does not 
>>> support VMX, + IA32_FEATURE_CONTROL_MSR is non-existent.\n"); return 
>>> true; } Regards, -Ning
>>>
>>> -Original Message- From: Tony Camuso 
>>> [mailto:tcam...@redhat.com] Sent: Wednesday, May 04, 2016 10:32 AM
>>> To: tboot-devel@lists.sourceforge.net Cc: Bandan Das 
>>> <b...@redhat.com> Subject: [tboot-devel] [PATCH] Check for VMX 
>>> support before reading feature control MSR We found this problem 
>>> when booting a KVM guest through tboot from a host OS where the VMX 
>>> register is not exposed to 

Re: [tboot-devel] booting tboot directly as EFI STUB?

[Sun, Ning]

Hi Jan,

Thanks for your email, currently tboot works with grub on both UEFI and legacy 
platforms.
Meanwhile, we are working on a PoC of UEFI 64 bit tboot, which will support 
multiple usages including what you mentioned in your email.
As this work is non-trivial, any suggestions/proposals are welcome!

Thanks,
-Ning

-Original Message-
From: Jan Schermer [mailto:j...@schermer.cz] 
Sent: Monday, April 18, 2016 4:59 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] booting tboot directly as EFI STUB?

Hello,
is it possible to add support for loading tboot directly instead of using GRUB, 
in the same way Linux kernel supports it?
https://www.kernel.org/doc/Documentation/efi-stub.txt

This would greatly simplify the setup of tboot and remove one unnecessary 
component (grub) which presents a quite large attack surface.

This way tboot would get measured by BIOS directly into CRTM, and we could 
immediately follow DRTM from here...
And I could maybe sign the tboot binary for Secure Boot instead of using 
poorly-documented GRUB :-)

Thanks

Jan



--
Find and fix application performance issues faster with Applications Manager 
Applications Manager provides deep performance insights into multiple tiers of 
your business applications. It resolves application problems quickly and 
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] PATCH: Fix linux command line after 429:664e69

[Sun, Ning]

Hi Martin,

Thanks for the patch, we will go through some validation before upstreaming 
your patch...

Regards,
-Ning  

-Original Message-
From: Wilck, Martin [mailto:martin.wi...@ts.fujitsu.com] 
Sent: Tuesday, February 23, 2016 6:00 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] PATCH: Fix linux command line after 429:664e69

Don't skip first argument in Linux kernel command line

Since 429:664e696da669, tboot doesn't skip the first argument of a given 
command line any more. Consequently, it shouldn't be skipped either when passed 
to the kernel in expand_linux_image().


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] LCP policy with two signed policy lists

[Sun, Ning]

Hi Martin,

Generally speaking, it is not allow to sign multiple policy lists with same 
key, it is by design for security reasons.

Regards,
-Ning


-Original Message-
From: Wilck, Martin [mailto:martin.wi...@ts.fujitsu.com] 
Sent: Tuesday, February 16, 2016 6:01 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] LCP policy with two signed policy lists

Hello,

is it forbidden to use a PO policy with two policy lists signed by the same 
key? I was experimenting with LCP and consistently encountering errors (TXT 
reset) with this configuration.

I am attaching a dump of the policy data and a corresponding tboot log.
The same policy works fine if I don't sign the lists. It also works if I put 
both elements into a single list and use that either unsigned, signed, or both 
combined. But whenever I use two signed policy lists, AC SINIT resets.

Any ideas?

Regards
Martin

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] New bug fix release for tboot?

[Sun, Ning]

We are going to have a new tboot release very soon, stay tuned...

Thanks,
-Ning

-Original Message-
From: Ross Philipson [mailto:ross.philip...@gmail.com] 
Sent: Tuesday, February 16, 2016 5:56 AM
To: Wilck, Martin ; 
tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] New bug fix release for tboot?

On 02/16/2016 06:09 AM, Wilck, Martin wrote:
> Hello,
> 
> I'd like to know if a new tboot release is scheduled for anytime soon; 
> at least a bug fix release with the latest fixes might be in order. I 
> recently pulled my hair because of recurring TXT resets that 
> eventually turned out to be fixed by the yet unreleased commit a21e91 
> (and, FTR, caused by 9040e0).

I would like to second that request. There are a number of issues that I found 
like the compression slowness on S3 resume and the logging buffer overflow that 
we really would like to get into production (and drop our workarounds).

Thanks
Ross Philipson

> 
> Without a release, it will be hard to push these fixes into 
> distributions.
> 
> Thanks,
> Martin Wilck
> 
> --
> 
> Site24x7 APM Insight: Get Deep Visibility into Application Performance 
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month 
> Monitor end-to-end web transactions and take corrective actions now 
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 


--
Ross Philipson

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + 
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end 
web transactions and take corrective actions now Troubleshoot faster and 
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] console input while TBooting...

[Sun, Ning]

Interrupt is disabled during tboot boot.

Sent from my iPhone

> On Jan 5, 2016, at 3:42 AM, mipsan.K  wrote:
> 
> I posted this issue on the discussion as well.
> In short, I want to stop TBooting process when something wrong,
> and then wait user's confirmation to go forward or not. 
> 
> To enable console input, I added getchar function as freeBSD.
> But it does not read keyboard(USB) at all.
> 
> anyone tried this? 
> --
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] tboot in Debian

[Sun, Ning]

Hi,

What are your questions? 

Thanks,
-ning

-Original Message-
From: Paulo [mailto:kretc...@gmail.com] 
Sent: Tuesday, October 27, 2015 7:46 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] tboot in Debian

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Tboot developers,

I'm trying to put Trusted Boot in Debian. I'm a maintainer of packages there.
 
I made a ITP (Intent to Package) and built a package of 1.8.3 version.
I have some doubts, and contributions.

Any of you wants do work with me to do this?

Thanks.

[]'s
kretcheu
:x
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWMDb3AAoJEDnxel9a775z30cP/3n6zhWxWFaUteBCfcDyPixS
MfvnbbV4criknJktXtpQuHW7RzBcNYKObJtSSuWyZifY/Is69llmKFWfSU7qWvVg
rUgvhpPPNB5kwMkw0g7ywPC6SdRp39u0ZC9pxACKV4YaL8Kqtj0C+dWO9p/KsmaD
OQR+SmMBPTLvb2Yl/RO3nASFVtInJHQxA+6zodttfbcSCCKi8CY4uAPgDGIzvU7g
pptDbF/aPTsI+0J3T6ppYdoS5qdYDXw87M6UzUD3IzY5WGydlLy6dTjABMuzDEA0
PgNZ1uYBgEFQCMxQMRrtiQvnOPc7BY4UsJvIRbb/7+HWTklkgnnKrB3w9s1RlSqe
Og3x0AjbGtuvdAfVQc028p8QzOq0Z2Wm+rVc1FjNEnEA9eq8+tnTTr3ip1MXYpVs
ZCFT/KFybinNEGXUAvcvCCb38qCuG7zb0vT7+Ec5HSFaEXUTA7Pld3sKMt6FP9br
KpiupmKcac4EQOBX0FYI/f0PaH26bE1uMkhDZnL+t4quZaLsR9zaqpAkP6dRx8GU
6gkSrc7DjDOg1pGrBgOUvfmKZmiqWgVPBiz8l8mQ2gR/breviU5urZtKE33KJSQp
ss6805o2bk/sNjS8s+MK4FT19tO32zq5Pd3b/UxmTxjgY0531n82wLHgKGgh/ZQL
nlu0LJdX0Y0k7joJ8mEc
=NhZD
-END PGP SIGNATURE-

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3

[Sun, Ning]

Did you try the tboot + linux kernel? 

-Original Message-
From: Ross Philipson [mailto:ross.philip...@gmail.com] 
Sent: Tuesday, September 15, 2015 8:02 AM
To: Sun, Ning; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3

On 09/14/2015 03:54 PM, Sun, Ning wrote:
> Try these commands in a script, and check the print-out after resumed from S3:
> date
> sudo rtcwake -u -s 20 -m mem
> date
>
>
> Thanks,
> -ning
>

I started another thread where I explain what the actual problems are in the 
log compression code. But in order to not ignore this response, I ran the above:

root@xenclient-dom0:/storage# ./do-s3.sh Tue Sep 15 14:37:17 UTC 2015 wakeup 
from "mem" at Tue Sep 15 14:37:38 2015 Tue Sep 15 14:38:57 UTC 2015

It is taking 1m and 40s to come back. 20s are the delay for rtcwake but the 1m 
20s remaining is spent in LZ_Compress.

[snip]


--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3

[Sun, Ning]

Try these commands in a script, and check the print-out after resumed from S3:
date
sudo rtcwake -u -s 20 -m mem
date


Thanks,
-ning

-Original Message-
From: Ross Philipson [mailto:ross.philip...@gmail.com] 
Sent: Sunday, September 13, 2015 11:55 AM
To: Sun, Ning; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3

On 09/11/2015 08:20 PM, Sun, Ning wrote:
> Actually system resumes from S3 timely in tboot, but I/O (keyboard, mouse, 
> video) looks blocked for seconds in kernel, need more investigations...

When S3 works, it is very timely but that is not the issue. I noted in another 
reply to this thread that when I remove these 2 change sets, the hang and 
subsequent system reset do not happen:

http://hg.code.sf.net/p/tboot/code/rev/9040e000ccc4
http://hg.code.sf.net/p/tboot/code/rev/78713e04bdd9

It is very clearly related to these. I also stated that our suspicion is a 
buffer overflow in or related to this code:

http://hg.code.sf.net/p/tboot/code/rev/9040e000ccc4#l3.62

We do have the logging level set to "all".

Thanks
Ross

>
> Thanks,
> -ning
>
> -Original Message-
> From: Ross Philipson [mailto:ross.philip...@gmail.com]
> Sent: Thursday, September 10, 2015 12:36 PM
> To: tboot-devel@lists.sourceforge.net
> Subject: [tboot-devel] TBOOT 1.8.3 fails to resume from S3
>
> I have been working on moving our project from TBOOT 1.7.0 to 1.8.3. I have 
> discovered that while our 1.7.0 version of TBOOT resumes from S3 just fine, 
> 1.8.3 does not.
>
> The most common symptom seems to be a hang just after TBOOT enters SMX mode. 
> The hang happens at different places so I don't think it is one specific 
> thing that TBOOT is doing to cause the hang. The hang can be short (on the 
> order of seconds) or longs (several minutes). Then suddenly the platform will 
> "unhang". It looks like the platform restarts quickly and goes right back in 
> to TBOOT but it is a little hard to tell exactly what happens right around 
> this point. We see this on every system we have tried it on.
>
> I have backed all our patches out and I still see the problem with a clean 
> 1.8.3 code base. I have also tried using TBOOT with a Debian Jessie install 
> and I get similar problems there. I have been comparing the code between the 
> version and have so far not found anything that makes a difference.
>
> Any help in this matter is appreciated.
> Thanks
> --
> Ross Philipson
>
> --
>  Monitor Your Dynamic Infrastructure at Any Scale With 
> Datadog!
> Get real-time metrics from all of your servers, apps and tools in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>


--
Ross Philipson

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3

[Sun, Ning]

Actually system resumes from S3 timely in tboot, but I/O (keyboard, mouse, 
video) looks blocked for seconds in kernel, need more investigations...

Thanks,
-ning

-Original Message-
From: Ross Philipson [mailto:ross.philip...@gmail.com] 
Sent: Thursday, September 10, 2015 12:36 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] TBOOT 1.8.3 fails to resume from S3

I have been working on moving our project from TBOOT 1.7.0 to 1.8.3. I have 
discovered that while our 1.7.0 version of TBOOT resumes from S3 just fine, 
1.8.3 does not.

The most common symptom seems to be a hang just after TBOOT enters SMX mode. 
The hang happens at different places so I don't think it is one specific thing 
that TBOOT is doing to cause the hang. The hang can be short (on the order of 
seconds) or longs (several minutes). Then suddenly the platform will "unhang". 
It looks like the platform restarts quickly and goes right back in to TBOOT but 
it is a little hard to tell exactly what happens right around this point. We 
see this on every system we have tried it on.

I have backed all our patches out and I still see the problem with a clean 
1.8.3 code base. I have also tried using TBOOT with a Debian Jessie install and 
I get similar problems there. I have been comparing the code between the 
version and have so far not found anything that makes a difference.

Any help in this matter is appreciated.
Thanks
--
Ross Philipson

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] GRUB 2 LCP data file module

[Sun, Ning]

Hi David,

Thanks for your interest in trusted boot open source project.
Do you have patch to submit? 
You can send out your patch to this mail list, your patch will be reviewed and 
validated and then merged to main stream.

-Ning Sun

-Original Message-
From: David Esler [mailto:drumandst...@gmail.com] 
Sent: Friday, July 24, 2015 8:59 AM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] GRUB 2 LCP data file module

Hello,

I've noticed that the grub-mkconfig helper scripts (20_linux_tboot 
20_linux_xen_tboot) do not contain any logic for automatically including the 
LCP data file module (unlike the SINIT AC module), and was wondering if there 
was some particular reason for this?

Also, I was wondering if anyone could point me to any guidelines for 
contributing patches to the project. I've read the sign-off blurb in the 
README, but am still unsure of the accepted process for contribution.
Thanks in advance!

- David Esler

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] noefi kernel argument

[Sun, Ning]

Hi Sahil,

You are right, noefi kernel argument here is to make sure kernel doesn't use 
EFI runtime services after measured launch.

Regards,
-Ning

Intel Open Source Technology Center
Intel Corporation
3621 Juliette Lane
Santa Clara, CA  95054
www.intel.comhttp://www.intel.com


From: Sahil Rihan [mailto:sri...@fb.com]
Sent: Tuesday, May 26, 2015 2:30 PM
To: tboot-devel@lists.sourceforge.net
Subject: [tboot-devel] noefi kernel argument

Hi,

I noticed that tboot grub2 scripts add the noefi kernel argument when 
generating a grub2 config. There doesn't seem to be anything in the tboot 
change logs explaining the need for this argument.

I suspect that this was added to ensure the kernel doesn't make use of EFI 
runtime services after dynamic launch, since EFI code isn't being measured. 
Would be great if someone can confirm.

Thanks,
Sahil
--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] [PATCH] Disable fstack-check during build

[Sun, Ning]

By default tboot does not enforce -fstack-check in Config.mk file, so 
mainstream linux distributions do not have the issue you encountered in Gentoo 
Linux.
However for compatibility with more Linux distributions, we will accept your 
patch for tboot. You can get the latest tboot snapshot to test on your Gentoo 
Linux.

Thanks very much!
-ning

-Original Message-
From: Jason Zaman [mailto:ja...@perfinion.com] 
Sent: Thursday, May 07, 2015 11:21 AM
To: Sun, Ning
Cc: Wei, Gang; tboot-devel@lists.sourceforge.net
Subject: Re: [tboot-devel] [PATCH] Disable fstack-check during build

Hi Ning,

I was packaging tboot for Gentoo Linux and it would never actually manage to 
load linux. It managed to SENTER fine but once it tried to jump to the linux 
entry point it would fail and reboot. Gentoo Hardened adds fstack-check by 
default (among other things) to the gcc specs.

After a lot of trial and error disabling SSP with -fstack-check=no made it 
work. tboot already disables fstack-protector and fstack-protector-all which 
are similar so it makes sense that fstack-check must also be disabled.
There is no comment explaining why fstack-protector is disabled in the makefile 
unfortunately.

I do not have a very good way of debugging since it wouldnt work in an emulator 
so I do not know *exactly* where it broke but the assembly generated by my gcc 
and the objdump'd one from fedora were quite different at the last stages of 
tboot. I saw the jumping to Linux @0xxx message on the console and then it 
would reboot so it was very late in the initialization.

I was using Gcc 4.8.4 from Gentoo Hardened[1]. If you are on a different 
distro, add -fstack-check to the CFLAGs and you will probably be able to 
replicate.

Thanks,
Jason

[1]: 
https://wiki.gentoo.org/wiki/Hardened/Toolchain#Default_addition_of_the_Stack_Smashing_Protector_.28SSP.29

On Thu, May 07, 2015 at 05:51:53PM +, Sun, Ning wrote:
 Hi Zaman,
 
 Thanks for your patch, for us to better understand the purpose of your 
 patch, can you explain in which scenario fstack-check will break tboot?
 
 Thanks very much!
 -ning
 
 
 
 -Original Message-
 From: Jason Zaman [mailto:ja...@perfinion.com]
 Sent: Thursday, May 07, 2015 8:55 AM
 To: tboot-devel@lists.sourceforge.net
 Subject: [tboot-devel] [PATCH] Disable fstack-check during build
 
 fstack-check breaks tboot this disables it in CFLAGS.
 
 Signed-off-by: Jason Zaman ja...@perfinion.com

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] tboot 1.8.3 released

[Sun, Ning]

This release is to add SGX support for Intel Skylake platform and verified 
launch control policy user guide, along with several significant bugs fix from 
1.8.2, like using the primary object in NULL Hierarchy instead of Platform 
Hierarchy for seal/unseal usage for TPM 2.0, Optimizing tboot log processing 
flow to avoid log buffer overflow by adopting lz Compress/Uncompress algorithms 
etc..



Source package tboot-1.8.3.tar.gz can be downloaded from sourceforge.net.

Major changes since 1.8.2 (20140728):

Added verified launch control policy user guide

Fixed a bug about var MTRR settings to follow the rule that each VAR 
MTRR base must be a multiple of that MTRR's size.

Access tpm sts reg with 3-byte width in v1.2 case and 4-byte width in 
v2.0 case

Bugfix: lcp2_mlehash get wrong hash if the cmdline string length  7

Optimized tboot log processing flow to avoid log buffer overflow by 
adopting lz Compress/Uncompress algorithms

Added SGX support for Skylake platform

tpm2: use the primary object in NULL Hierarchy instead of Platform 
Hierarchy for seal/unseal usage

Fixed a bug for lcp2_mlehash tool

Fixed system hang issue caused by TXT disable, TPM disable or SINIT ACM 
not correctly provided in EFI booting mode

Fixed bug for wrong assumption on the way how GRUB2 load modules

Fixed MB2 tags mess issue caused by moving shorter module cmdline to 
head
Fixed compile issue when debug=y

You are encouraged to install, run and test it, and enjoy it.



Thanks,
Ning Sun
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Tboot Installation Issues

[Sun, Ning]

Hi Michael,

TXT/VT-x/VT-d need to be enabled, can you check your machine to make sure they 
are enabled?

Regards,
Sun Ning


 Original message 
From: Michael Perng mpe...@us.ibm.com
Date:11/18/2014 4:07 PM (GMT-08:00)
To: tboot-devel@lists.sourceforge.net
Cc: Nikhil Gupta nikhil.gu...@us.ibm.com
Subject: [tboot-devel] Tboot Installation Issues

 Original message 
From: Michael Perng mpe...@us.ibm.com
Date:11/18/2014 4:07 PM (GMT-08:00)
To: tboot-devel@lists.sourceforge.net
Cc: Nikhil Gupta nikhil.gu...@us.ibm.com
Subject: [tboot-devel] Tboot Installation Issues

Hello,

I am trying to install tboot on 2 systems - one running RHEL 6.5 and one 
running Ubuntu. I did the following steps, to no success:

#tpm_takeownership -z

# yum install trousers-devel tpm-tools tboot

modify /boot/grub/grub.conf so that the first line looks like this:

title tboot Red Hat Enterprise Linux Server (...)
root (hd0,0)
kernel /tboot.gz loglvl=all logging=serial,vga,memory vga_delay=1
module /vmlinuz ... (kernel)
module /initramfs ... (initrd)
(Both systems are equipped with SINIT in the BIOS, so there was no need to add 
it as a module in the configuration above.)

I did equivalent steps on the Ubuntu machine.

Neither machine showed any signs of having successfully run tboot:

- txt-stat shows that 'TXT measured launch' is FALSE
- TPMs are owned, enabled, and active
- pcr values are as follows:
PCR-00 to PCR-07 contain values as expected
...
PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-21: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-22: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


The following errors were given by txt-stat as well:

...
TBOOT: TPM: fail to get public data of 0x2001 in TPM NV
TBOOT:  :reading failed
...
TBOOT: TPM: fail to get public data of 0x4001 in TPM NV
TBOOT:  :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:
...
TBOOT: Error: write TPM error: 0x2.
TBOOT: no policy in TPM NV.
TBOOT: IA32_FEATURE_CONTROL_MSR: 0007
TBOOT: CPU is SMX-capable
TBOOT: ERR: SENTER disabled by feature control MSThR (7)
TBOOT: SMX not supported.
TBOOT: no LCP module found
TBOOT: Error: ELF magic number is not matched.
...

Both machines have similar output for txt-stat with the exception that the 
'ERR: SENTER disabled by feature control...'  error only showed up on the RHEL 
machine.
One interesting thing that I noticed that might be connected to the problem is 
that the 'tpm_tis.ko' module does not exist on either machine.

Does anyone have an idea of why tboot is not successfully activating the DRTMs 
and what I could do to solve the problem?


Thanks,

Michael
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel