tboot-devel — Developer support

[tboot-devel] [PATCH 2/2] safestringlib: fix warnings with GCC 6.4.0

[Christopher C. <chr...@gm...>]

Allow compilation with -Werror, which is enabled by default in OpenEmbedded.

 -Wunused-parameter fixes are macro related.

 -Wswitch-default fixes fall-throughs in format parsing that
  would be caught during compilation by GCC (invalid formats).

 -Wdiscarded-qualifiers fixes add missing const around error messages
  which are usually literals.

 -Wincompatible-pointer-types, mem_prim_set32() takes a uint32_t* from
  wwmemset_s() wchar_t input without a cast.

Signed-off-by: Christopher Clark <chr...@gm...>
Patch is by Eric Chanudet for OpenXT:
https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0014-safestringlib-Attend-GCC-warnings.patch

diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/abort_handler_s.c
--- a/safestringlib/safeclib/abort_handler_s.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/abort_handler_s.c	Fri Jan 24 10:10:20 2020 -0800
@@ -67,6 +67,7 @@
 
 void abort_handler_s(const char *msg, void *ptr, errno_t error)
 {
+	(void) ptr;
 	slprintf("ABORT CONSTRAINT HANDLER: (%u) %s\n", error,
 		 (msg) ? msg : "Null message");
 	slabort();
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/ignore_handler_s.c
--- a/safestringlib/safeclib/ignore_handler_s.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/ignore_handler_s.c	Fri Jan 24 10:10:20 2020 -0800
@@ -64,7 +64,9 @@
 
 void ignore_handler_s(const char *msg, void *ptr, errno_t error)
 {
-
+	(void) ptr;
+	(void) error;
+	(void) msg;
 	sldebug_printf("IGNORE CONSTRAINT HANDLER: (%u) %s\n", error,
 		       (msg) ? msg : "Null message");
 	return;
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/safe_str_constraint.h
--- a/safestringlib/safeclib/safe_str_constraint.h	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/safe_str_constraint.h	Fri Jan 24 10:10:20 2020 -0800
@@ -48,12 +48,13 @@
  * Safe C Lib internal string routine to consolidate error handling
  */
 static inline void handle_error(char *orig_dest, rsize_t orig_dmax,
-                                char *err_msg, errno_t err_code)
+                                const char *err_msg, errno_t err_code)
 {
 #ifdef SAFECLIB_STR_NULL_SLACK
     /* null string to eliminate partial copy */
     while (orig_dmax) { *orig_dest = '\0'; orig_dmax--; orig_dest++; }
 #else
+    (void) orig_dmax;
     *orig_dest = '\0';
 #endif
 
@@ -62,12 +63,13 @@
 }
 
 static inline void handle_wc_error(wchar_t *orig_dest, rsize_t orig_dmax,
-                                char *err_msg, errno_t err_code)
+                                   const char *err_msg, errno_t err_code)
 {
 #ifdef SAFECLIB_STR_NULL_SLACK
     /* null string to eliminate partial copy */
     while (orig_dmax) { *orig_dest = L'\0'; orig_dmax--; orig_dest++; }
 #else
+    (void) orig_dmax;
     *orig_dest = L'\0';
 #endif
 
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/snprintf_support.c
--- a/safestringlib/safeclib/snprintf_support.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/snprintf_support.c	Fri Jan 24 10:10:20 2020 -0800
@@ -78,6 +78,7 @@
 			case '+' : // force a sign be used
 				index++; // skip the flag character
 				break;
+			default: break;
 			}
 			// check for and skip the optional field width
 			while ( format[index] != '\0' && format[index] >= '0' && format[index] <= '9') {
@@ -112,6 +113,7 @@
 			case 'z' :
 			case 't' : index++;
 			           break;
+			default: break;
 			}
 
 			// Recognize and record the actual modifier
@@ -212,6 +214,7 @@
 		case FMT_INT   :
 			retValue = 1;
 			break;
+		default: break;
 	}
 	return retValue;
 }
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/wmemset_s.c
--- a/safestringlib/safeclib/wmemset_s.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/wmemset_s.c	Fri Jan 24 10:10:20 2020 -0800
@@ -98,7 +98,7 @@
         return (RCNEGATE(ESLEMAX));
     }
 
-    mem_prim_set32(dest, len, value);
+    mem_prim_set32((void*)dest, len, value);
 
     return (RCNEGATE(EOK));
 }

[tboot-devel] [PATCH 1/1] Config.mk, safestringlib/makefile : allow tool overrides

[Christopher C. <chr...@gm...>]

To simplify integration of tboot into build systems such as
OpenEmbeddded, use softer assignments and appends to define
the build tool and flag variables.

Signed-off-by: Christopher Clark <chr...@gm...>

This patch is based on an OpenXT patch by Eric Chanudet:
https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0001-config-Allow-build-system-integration.patch

diff -r 0db8feeba423 -r dcec96ce7d2c Config.mk
--- a/Config.mk	Thu Dec 12 12:09:20 2019 +0100
+++ b/Config.mk	Fri Jan 24 10:03:42 2020 -0800
@@ -45,22 +45,22 @@
 	            $(call cc-option,$(CC),-Wlogical-op,) \
 	            -Wno-missing-field-initializers
 
-AS         = as
-LD         = ld
-CC         = gcc
-CPP        = cpp
-AR         = ar
-RANLIB     = ranlib
-NM         = nm
-STRIP      = strip
-OBJCOPY    = objcopy
-OBJDUMP    = objdump
+AS         ?= as
+LD         ?= ld
+CC         ?= gcc
+CPP        ?= cpp
+AR         ?= ar
+RANLIB     ?= ranlib
+NM         ?= nm
+STRIP      ?= strip
+OBJCOPY    ?= objcopy
+OBJDUMP    ?= objdump
 
 ifeq ($(debug),n)
-INSTALL_STRIP = -s
+INSTALL_STRIP ?= -s
 endif
 
-INSTALL      = install
+INSTALL      ?= install
 INSTALL_DIR  = $(INSTALL) -d -m0755 -p
 INSTALL_DATA = $(INSTALL) -m0644 -p
 INSTALL_PROG = $(INSTALL) $(INSTALL_STRIP) -m0755 -p
diff -r 0db8feeba423 -r dcec96ce7d2c safestringlib/makefile
--- a/safestringlib/makefile	Thu Dec 12 12:09:20 2019 +0100
+++ b/safestringlib/makefile	Fri Jan 24 10:03:42 2020 -0800
@@ -1,7 +1,7 @@
 IDIR = include
-CC=gcc
-CFLAGS=-I$(IDIR) -fstack-protector-strong -fPIE -fPIC -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -DSTDC_HEADERS
-LDFLAGS=-z noexecstack -z relo -z now
+CC ?= gcc
+CFLAGS += -I$(IDIR) -fstack-protector-strong -fPIE -fPIC -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -DSTDC_HEADERS
+LDFLAGS += -z noexecstack -z relo -z now
 
 ODIR=obj
 OTDIR=objtest

Re: [tboot-devel] Confused about the TXT register values

[Martin G. <omg...@gm...>]

I just ran the same tool on a Supermicro system which I'm positive has
TXT, and am now seeing the following (with TXT disabled):

Intel(r) TXT Configuration Registers:
    STS: 0x00000002
        senter_done: FALSE
        sexit_done: TRUE
        mem_config_lock: FALSE
        private_open: FALSE
        locality_1_open: FALSE
        locality_2_open: FALSE
    ESTS: 0x00
        txt_reset: FALSE
    E2STS: 0x0000000000000004
        secrets: FALSE
    ERRORCODE: 0x00000000
    DIDVID: 0x00000001b0028086
        vendor_id: 0x8086
        device_id: 0xb002
        revision_id: 0x1
    FSBIF: 0xffffffffffffffff
    QPIIF: 0x000000009d003000
    SINIT.BASE: 0x00000000
    SINIT.SIZE: 0B (0x0)
    HEAP.BASE: 0x00000000
    HEAP.SIZE: 0B (0x0)
    DPR: 0x0000000000000000
        lock: FALSE
        top: 0x00000000
        size: 0MB (0B)
    PUBLIC.KEY:
        2d 67 dd d7 5e f9 33 92 66 a5 6f 27 18 95 55 ae
        77 a2 b0 de 77 42 22 e5 de 24 8d be b8 e3 3d d7

***********************************************************
     TXT measured launch: FALSE
     secrets flag set: FALSE
***********************************************************
unable to find TBOOT log

The TXT.STS values make more sense now, though the PCH DID is still
incorrect. Is there a way to check whether TXT is enabled other than
looking at SINIT.BASE and HEAP.BASE?

Re: [tboot-devel] Confused about the TXT register values

[Martin G. <omg...@gm...>]

El vie., 24 ene. 2020 a las 11:34, Lukasz Hawrylko
(<luk...@li...>) escribió:
> I see that your SINIT.BASE and HEAP.BASE registers have all zeros, did
> you enable TXT in BIOS? I guess that txt-stat may not check if TXT is
> enabled before reading TXT related registers, that's why you can have
> strange, random values.

Yes, I realized this :) I don't have TXT enabled on BIOS (in fact,
checking again this isn't even a vPro system), so maybe the values are
just garbage. Still, I find it interesting that the PCH VID is
correct. I'd expect all values to be bogus here, since they're being
read from the TXT registers.

Re: [tboot-devel] Confused about the TXT register values

[Lukasz H. <luk...@li...>]

On Thu, 2020-01-23 at 14:41 -0300, Martin Galvan wrote:
> Hi all,
> 
> I just ran txt-stat on a system which has an IceLake CPU and a 495
> Series PCH, and am seeing the following output:
> 
> Intel(r) TXT Configuration Registers:
>     STS: 0x00000003
>         senter_done: TRUE
>         sexit_done: TRUE
>         mem_config_lock: FALSE
>         private_open: FALSE
>         locality_1_open: FALSE
>         locality_2_open: FALSE
>     ESTS: 0x00
>         txt_reset: FALSE
>     E2STS: 0x0000000000000004
>         secrets: FALSE
>     ERRORCODE: 0x00000000
>     DIDVID: 0x00000001b00a8086
>         vendor_id: 0x8086
>         device_id: 0xb00a
>         revision_id: 0x1
>     FSBIF: 0xffffffffffffffff
>     QPIIF: 0x000000009d003000
>     SINIT.BASE: 0x00000000
>     SINIT.SIZE: 0B (0x0)
>     HEAP.BASE: 0x00000000
>     HEAP.SIZE: 0B (0x0)
>     DPR: 0x0000000000000000
>         lock: FALSE
>         top: 0x00000000
>         size: 0MB (0B)
>     PUBLIC.KEY:
>         87 9a 8f 9c bf 9e 3d 1d 12 dc 9a d7 6d de 34 e6
>         aa 40 36 64 c7 39 db 34 7b 85 8f 0b e0 33 ae 3a
> 
> ***********************************************************
>      TXT measured launch: TRUE
>      secrets flag set: FALSE
> ***********************************************************
> unable to find TBOOT log
> 
> I'm seeing that the SENTER.DONE.STS and SEXIT.DONE.STS bits are both
> set. If I understood right, this doesn't make sense since they signal
> whether all the threads are running the code within the MLE or not
> (I'm not running an MLE here). In addition, the DID reported by
> TXT.DIDVID doesn't match that of my PCH (which is 0x3482). Am I doing
> something wrong here?
> 

Hi Martin

I see that your SINIT.BASE and HEAP.BASE registers have all zeros, did
you enable TXT in BIOS? I guess that txt-stat may not check if TXT is
enabled before reading TXT related registers, that's why you can have
strange, random values.

Thanks,
Lukasz

[tboot-devel] Confused about the TXT register values

[Martin G. <omg...@gm...>]

Hi all,

I just ran txt-stat on a system which has an IceLake CPU and a 495
Series PCH, and am seeing the following output:

Intel(r) TXT Configuration Registers:
    STS: 0x00000003
        senter_done: TRUE
        sexit_done: TRUE
        mem_config_lock: FALSE
        private_open: FALSE
        locality_1_open: FALSE
        locality_2_open: FALSE
    ESTS: 0x00
        txt_reset: FALSE
    E2STS: 0x0000000000000004
        secrets: FALSE
    ERRORCODE: 0x00000000
    DIDVID: 0x00000001b00a8086
        vendor_id: 0x8086
        device_id: 0xb00a
        revision_id: 0x1
    FSBIF: 0xffffffffffffffff
    QPIIF: 0x000000009d003000
    SINIT.BASE: 0x00000000
    SINIT.SIZE: 0B (0x0)
    HEAP.BASE: 0x00000000
    HEAP.SIZE: 0B (0x0)
    DPR: 0x0000000000000000
        lock: FALSE
        top: 0x00000000
        size: 0MB (0B)
    PUBLIC.KEY:
        87 9a 8f 9c bf 9e 3d 1d 12 dc 9a d7 6d de 34 e6
        aa 40 36 64 c7 39 db 34 7b 85 8f 0b e0 33 ae 3a

***********************************************************
     TXT measured launch: TRUE
     secrets flag set: FALSE
***********************************************************
unable to find TBOOT log

I'm seeing that the SENTER.DONE.STS and SEXIT.DONE.STS bits are both
set. If I understood right, this doesn't make sense since they signal
whether all the threads are running the code within the MLE or not
(I'm not running an MLE here). In addition, the DID reported by
TXT.DIDVID doesn't match that of my PCH (which is 0x3482). Am I doing
something wrong here?

Re: [tboot-devel] tboot, TPM 2.0 on Dell PowerEdge R730

[Lukasz H. <luk...@li...>]

On Wed, 2020-01-15 at 18:36 -0800, Christopher Clark wrote:
> Hello
> 
> I am trying to boot with tboot and TPM 2.0 on a Dell PowerEdge R730
> and encountering reboot at SENTER every time with the following:
> 
> TBOOT: TXT.ERRORCODE: 0xc0033451
> TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xd
> 
> which SINIT_Errors-Broadwell-4th-gen.pdf indicates is: Invalid PMR configuration
> I am having difficulty determining how the PMR values could be incorrect
> and so fail the SINIT validation, what values would be accepted, whether
> something critical is outside the ranges, or unwanted within them, or indeed if
> something else is incorrect.
> 
> Can TXT + TPM 2.0 + tboot boot on this system?
> Is there some prior TPM configuration (beyond clearing it) necessary
> to enable boot?
> 
> Advice appreciated, and system details are below.
> thanks,
> 
> Christopher
> 

Hi Christopher

At first point please ensure that you are using latest SINIT, I know
that ACM team was working on similar issue, but I don't know if they
have already released version with the fix.

If problem still exists with latest SINIT, you can try to modify TBOOT
and check if that helps. Please apply following patch over v1.9.11

diff -r 003178d05f52 tboot/txt/txt.c
--- a/tboot/txt/txt.c   Tue Jan 14 11:54:11 2020 +0100
+++ b/tboot/txt/txt.c   Tue Jan 21 09:27:51 2020 +0100
@@ -559,6 +559,12 @@
             if (!vtd_disable_dma_remap(iter)) {
                 printk("    vtd_disable_dma_remap failed!\n");
             }
+            if (!vtd_disable_qie(iter)) {
+                printk("    vtd_disable_qie failed!\n");
+            }
+            if (!vtd_disable_ire(iter)) {
+                printk("    vtd_disable_ire failed!\n");
+            }
         }
     }

Thanks,
Lukasz

[tboot-devel] tboot, TPM 2.0 on Dell PowerEdge R730

[Christopher C. <chr...@gm...>]

Hello

I am trying to boot with tboot and TPM 2.0 on a Dell PowerEdge R730
and encountering reboot at SENTER every time with the following:

TBOOT: TXT.ERRORCODE: 0xc0033451
TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xd

which SINIT_Errors-Broadwell-4th-gen.pdf indicates is: Invalid PMR configuration

I am having difficulty determining how the PMR values could be incorrect
and so fail the SINIT validation, what values would be accepted, whether
something critical is outside the ranges, or unwanted within them, or indeed if
something else is incorrect.

Can TXT + TPM 2.0 + tboot boot on this system?
Is there some prior TPM configuration (beyond clearing it) necessary
to enable boot?

Advice appreciated, and system details are below.
thanks,

Christopher

tboot command line: min_ram=0x2000000 loglvl=all
serial=115200,8n1,0x3f8 logging=serial,memory

>From the log:
TBOOT: original e820 map:
TBOOT:  0000000000000000 - 000000000009c000  (1)
TBOOT:  000000000009c000 - 00000000000a0000  (2)
TBOOT:  00000000000e0000 - 0000000000100000  (2)
TBOOT:  0000000000100000 - 000000007a289000  (1)
TBOOT:  000000007a289000 - 000000007af0b000  (2)
TBOOT:  000000007af0b000 - 000000007b93b000  (4)
TBOOT:  000000007b93b000 - 000000007bab4000  (3)
TBOOT:  000000007bab4000 - 000000007bae9000  (1)
TBOOT:  000000007bae9000 - 000000007baff000  (3)
TBOOT:  000000007baff000 - 000000007bb00000  (1)
TBOOT:  000000007bb00000 - 0000000090000000  (2)
TBOOT:  00000000feda8000 - 00000000fedac000  (2)
TBOOT:  00000000ff310000 - 0000000100000000  (2)
TBOOT:  0000000100000000 - 0000004080000000  (1)
...
TBOOT: no LCP module found
TBOOT: INTEL TXT LOG elt SIZE = 36
TBOOT: os_sinit_data (@0x7bf35154, 0x90):
TBOOT:   version: 7
TBOOT:   flags: 1
TBOOT:   mle_ptab: 0x801000
TBOOT:   mle_size: 0x38000 (229376)
TBOOT:   mle_hdr_base: 0x1b600
TBOOT:   vtd_pmr_lo_base: 0x0
TBOOT:   vtd_pmr_lo_size: 0x7a200000
TBOOT:   vtd_pmr_hi_base: 0x100000000
TBOOT:   vtd_pmr_hi_size: 0x3f80000000
TBOOT:   lcp_po_base: 0x0
TBOOT:   lcp_po_size: 0x0 (0)
TBOOT:   capabilities: 0x00000001
TBOOT:       rlp_wake_getsec: 1
TBOOT:       rlp_wake_monitor: 0
TBOOT:       ecx_pgtbl: 0
TBOOT:       stm: 0
TBOOT:       pcr_map_no_legacy: 0
TBOOT:       pcr_map_da: 0
TBOOT:       platform_type: 0
TBOOT:       max_phy_addr: 0
TBOOT:       tcg_event_log_format: 0
TBOOT:   efi_rsdt_ptr: 0x0
TBOOT:   ext_data_elts[]:
TBOOT:           EVENT_LOG_PTR:
TBOOT:                 size: 36
TBOOT:                count: 1
TBOOT:                   Log Descrption:
TBOOT:                               Alg: 4
TBOOT:                              Size: 4096
TBOOT:                      EventsOffset: [0,0]
TBOOT:                                No Event Log.
TBOOT: setting MTRRs for acmod: base=0x7bf00000, size=0x20000, num_pages=32
TBOOT: The maximum allowed MTRR range size=256 Pages
TBOOT: executing GETSEC[SENTER]...

== BIOS error message after reboot
"UEFI0046: 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.
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."

nb: Boot mode is BIOS, despite the UEFI label in the message.
Following the above and clearing the TPM removes the BIOS warning at boot,
but does not enable tboot to boot correctly when attempted.

== Software

tboot 1.9.11; also tested with 1.9.5, 1.9.6 and 1.9.9 from OpenXT 7.0,
OpenXT 8.0 and current development builds, with and without min_ram values.
All versions report the same errorcode.

I modified tboot to enable configuration of max_lo_ram at the command line, and
so vary vtd_pmr_lo_size, and then tested with a range of values, to no success.
I tested a reduced max_hi_ram, and so lowered vtd_pmr_hi_size to 16GB
to test that.

I have also ported Linux's Intel IOMMU reset PMR logic into tboot, to clear the
PMR in case anything prior to tboot on the system were configuring it, which
also did not change the symptoms.

Tested with both GRUB and isolinux.

== Platform, firmware
Hardware: Dell PowerEdge R730
Chipset: Intel C610
BIOS: 2.11.0 (released 20th Dec 2019)
BIOS SINIT: v3.1.3_20190718
TPM: 2.0 NTC
TPM firmware: 1.3.0.1
Boot mode: BIOS (ie. not UEFI)

All firmware on the host is up to date.
Dell has released a TPM Update utility for some platforms
(Latitude/OptiPlex/Precision/XPS series) to upgrade their TPM firmware
to 1.3.2.8, A02; but that tool will not run on this host (tested with
each of Windows Server 2012 R2, Windows Server 2016 and Windows 10).

== Full tboot log

TBOOT: *********************** TBOOT ***********************
TBOOT:    2019-11-25 16:00 +0200 1.9.11
TBOOT: *****************************************************
TBOOT: command line: min_ram=0x2000000 loglvl=all
serial=115200,8n1,0x3f8 logging=serial,memory
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
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: 0000ff07
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:  0000000000000000 - 000000000009c000  (1)
TBOOT:  000000000009c000 - 00000000000a0000  (2)
TBOOT:  00000000000e0000 - 0000000000100000  (2)
TBOOT:  0000000000100000 - 000000007a289000  (1)
TBOOT:  000000007a289000 - 000000007af0b000  (2)
TBOOT:  000000007af0b000 - 000000007b93b000  (4)
TBOOT:  000000007b93b000 - 000000007bab4000  (3)
TBOOT:  000000007bab4000 - 000000007bae9000  (1)
TBOOT:  000000007bae9000 - 000000007baff000  (3)
TBOOT:  000000007baff000 - 000000007bb00000  (1)
TBOOT:  000000007bb00000 - 0000000090000000  (2)
TBOOT:  00000000feda8000 - 00000000fedac000  (2)
TBOOT:  00000000ff310000 - 0000000100000000  (2)
TBOOT:  0000000100000000 - 0000004080000000  (1)
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size mismatch: acmod_size=f678400, acm_hdr->size*4=c0c0c0c0
TBOOT: checking if module root=/dev/ram rw start_install=new
answerfile=/install/answers/default.ans console=hvc0.
TBOOT:   ACM header size in bytes overflows
TBOOT: no SINIT AC module found
TBOOT: TXT.SINIT.BASE: 0x7bf00000
TBOOT: TXT.SINIT.SIZE: 0x20000 (131072)
TBOOT: BIOS has already loaded an SINIT module
TBOOT:   ACM info_table version mismatch (6)
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb002, revision: 0x1
TBOOT: processor family/model/stepping: 0x306f2
TBOOT: platform id: 0x0
TBOOT:   1 ACM chipset id entries:
TBOOT:       vendor: 0x8086, device: 0xb002, flags: 0x1, revision:
0x1, extended: 0x0
TBOOT:   3 ACM processor id entries:
TBOOT:       fms: 0x306f0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT: no SINIT provided by bootloader; using BIOS SINIT
TBOOT: AC mod base alignment OK
TBOOT: AC mod size OK
TBOOT: AC module header dump for SINIT:
TBOOT:   type: 0x2 (ACM_TYPE_CHIPSET)
TBOOT:   subtype: 0x0
TBOOT:   length: 0xa1 (161)
TBOOT:   version: 0
TBOOT:   chipset_id: 0x1d00
TBOOT:   flags: 0x0
TBOOT:           pre_production: 0
TBOOT:           debug_signed: 0
TBOOT:   vendor: 0x8086
TBOOT:   date: 0x20190718
TBOOT:   size*4: 0x20000 (131072)
TBOOT:   txt_svn: 0x00000001
TBOOT:   se_svn: 0x00000000
TBOOT:   code_control: 0x0
TBOOT:   entry point: 0x00000008:0000a14d
TBOOT:   scratch_size: 0x8f (143)
TBOOT:   info_table:
TBOOT:           uuid: {0x7fc03aaa, 0x46a7, 0x18db, 0xac2e,
                {0x69, 0x8f, 0x8d, 0x41, 0x7f, 0x5a}}
TBOOT:               ACM_UUID_V3
TBOOT:           chipset_acm_type: 0x1 (SINIT)
TBOOT:           version: 6
TBOOT:           length: 0x30 (48)
TBOOT:           chipset_id_list: 0x4f0
TBOOT:           os_sinit_data_ver: 0x7
TBOOT:           min_mle_hdr_ver: 0x00020000
TBOOT:           capabilities: 0x000000a5
TBOOT:               rlp_wake_getsec: 1
TBOOT:               rlp_wake_monitor: 0
TBOOT:               ecx_pgtbl: 1
TBOOT:               stm: 0
TBOOT:               pcr_map_no_legacy: 0
TBOOT:               pcr_map_da: 1
TBOOT:               platform_type: 2
TBOOT:               max_phy_addr: 0
TBOOT:               tcg_event_log_format: 0
TBOOT:           acm_ver: 107
TBOOT:   chipset list:
TBOOT:           count: 1
TBOOT:           entry 0:
TBOOT:               flags: 0x1
TBOOT:               vendor_id: 0x8086
TBOOT:               device_id: 0xb002
TBOOT:               revision_id: 0x1
TBOOT:               extended_id: 0x0
TBOOT:   processor list:
TBOOT:           count: 3
TBOOT:           entry 0:
TBOOT:               fms: 0x306f0
TBOOT:               fms_mask: 0xfff3ff0
TBOOT:               platform_id: 0x0
TBOOT:               platform_mask: 0x0
TBOOT:           entry 1:
TBOOT:               fms: 0x50660
TBOOT:               fms_mask: 0xfff3ff0
TBOOT:               platform_id: 0x0
TBOOT:               platform_mask: 0x0
TBOOT:           entry 2:
TBOOT:               fms: 0x406f0
TBOOT:               fms_mask: 0xfff3ff0
TBOOT:               platform_id: 0x0
TBOOT:               platform_mask: 0x0
TBOOT:   TPM info list:
TBOOT:           TPM capability:
TBOOT:                ext_policy: 0x3
TBOOT:                tpm_family : 0x3
TBOOT:                tpm_nv_index_set : 0x0
TBOOT:           alg count: 3
TBOOT:               alg_id: 0x4
TBOOT:               alg_id: 0xb
TBOOT:               alg_id: 0x14
TBOOT: TPM: TPM 2.0 FIFO interface is active...
TBOOT: TPM: FIFO_INF Locality 0 is open
TBOOT: TPM: discrete TPM2.0 Family 0x1
TBOOT: TPM: supported bank count = 2
TBOOT: TPM: bank alg = 00000004
TBOOT: TPM: bank alg = 0000000b
TBOOT: tboot: supported alg count = 2
TBOOT: tboot: hash alg = 00000004
TBOOT: tboot: hash alg = 0000000B
TBOOT: TPM:CreatePrimary creating hierarchy handle = 40000007
TBOOT: TPM:CreatePrimary created object handle = 80000000
TBOOT: TPM attribute:
TBOOT:   extend policy: 2
TBOOT:   current alg id: 0x4
TBOOT:   timeout values: A: 750, B: 2000, C: 75000, D: 750
TBOOT: SGX:verify_IA32_se_svn_status is called
TBOOT: SGX is not enabled, cpuid.ebx: 0x37ab
TBOOT: reading Verified Launch Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01200001 in TPM NV
TBOOT:  :reading failed
TBOOT: reading Launch Control Policy from TPM NV...
TBOOT:  :32 bytes read
TBOOT:  :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:
TBOOT:   version: 2
TBOOT:   policy_type: TB_POLTYPE_CONT_NON_FATAL
TBOOT:   hash_alg: TB_HALG_SHA1
TBOOT:   policy_control: 00000001 (EXTEND_PCR17)
TBOOT:   num_entries: 3
TBOOT:   policy entry[0]:
TBOOT:           mod_num: 0
TBOOT:           pcr: none
TBOOT:           hash_type: TB_HTYPE_ANY
TBOOT:           num_hashes: 0
TBOOT:   policy entry[1]:
TBOOT:           mod_num: any
TBOOT:           pcr: 19
TBOOT:           hash_type: TB_HTYPE_ANY
TBOOT:           num_hashes: 0
TBOOT:   policy entry[2]:
TBOOT:           mod_num: nv_raw
                 nv_index: 40000010
TBOOT:           pcr: 22
TBOOT:           hash_type: TB_HTYPE_ANY
TBOOT:           num_hashes: 0
TBOOT: no policy in TPM NV.
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: TXT.ERRORCODE: 0xc0033451
TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xd
TBOOT: TXT.ESTS: 0x0
TBOOT: TXT.E2STS: 0x8
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: RSDP (v2, DELL  ) @ 0x0fe3
TBOOT: TXT.HEAP.BASE: 0x7bf20000
TBOOT: TXT.HEAP.SIZE: 0xe0000 (917504)
TBOOT: bios_data (@0x7bf20008, 0x2c):
TBOOT:   version: 3
TBOOT:   bios_sinit_size: 0x20000 (131072)
TBOOT:   lcp_pd_base: 0x0
TBOOT:   lcp_pd_size: 0x0 (0)
TBOOT:   num_logical_procs: 56
TBOOT:   flags: 0x00000000
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: CR0.NE not set
TBOOT: CR0 and EFLAGS OK
TBOOT: supports preserving machine check errors
TBOOT: CPU support processor-based S-CRTM
TBOOT: CPU is ready for SENTER
TBOOT: checking previous errors on the last boot.
        last boot has error.
TBOOT: TPM: TPM 2.0 FIFO interface is active...
TBOOT: file addresses:
TBOOT:   &_start=0x804000
TBOOT:   &_end=0xb58ca0
TBOOT:   &_mle_start=0x804000
TBOOT:   &_mle_end=0x83c000
TBOOT:   &_post_launch_entry=0x804010
TBOOT:   &_txt_wakeup=0x804200
TBOOT:   &g_mle_hdr=0x81f600
TBOOT: MLE header:
TBOOT:   uuid={0x9082ac5a, 0x476f, 0x74a7, 0x5c0f,
                {0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}}
TBOOT:   length=34
TBOOT:   version=00020001
TBOOT:   entry_point=00000010
TBOOT:   first_valid_page=00000000
TBOOT:   mle_start_off=4000
TBOOT:   mle_end_off=3c000
TBOOT:   capabilities: 0x00000227
TBOOT:       rlp_wake_getsec: 1
TBOOT:       rlp_wake_monitor: 1
TBOOT:       ecx_pgtbl: 1
TBOOT:       stm: 0
TBOOT:       pcr_map_no_legacy: 0
TBOOT:       pcr_map_da: 1
TBOOT:       platform_type: 0
TBOOT:       max_phy_addr: 0
TBOOT:       tcg_event_log_format: 1
TBOOT: MLE start=0x804000, end=0x83c000, size=0x38000
TBOOT: ptab_size=3000, ptab_base=0x801000
TBOOT: configuring DMAR remapping
TBOOT:     record passes table end
TBOOT: TXT.HEAP.BASE: 0x7bf20000
TBOOT: TXT.HEAP.SIZE: 0xe0000 (917504)
TBOOT: bios_data (@0x7bf20008, 0x2c):
TBOOT:   version: 3
TBOOT:   bios_sinit_size: 0x20000 (131072)
TBOOT:   lcp_pd_base: 0x0
TBOOT:   lcp_pd_size: 0x0 (0)
TBOOT:   num_logical_procs: 56
TBOOT:   flags: 0x00000000
TBOOT: highest min_ram (0x2000000) region found: base=0x100000, size=0x7a189000
TBOOT: discarding RAM above reserved regions: 0x7bab4000 - 0x7bae9000
TBOOT: discarding RAM above reserved regions: 0x7baff000 - 0x7bb00000
TBOOT: min_lo_ram: 0x0, max_lo_ram: 0x7a289000
TBOOT: min_hi_ram: 0x100000000, max_hi_ram: 0x4080000000
TBOOT: no LCP module found
TBOOT: INTEL TXT LOG elt SIZE = 36
TBOOT: os_sinit_data (@0x7bf35154, 0x90):
TBOOT:   version: 7
TBOOT:   flags: 1
TBOOT:   mle_ptab: 0x801000
TBOOT:   mle_size: 0x38000 (229376)
TBOOT:   mle_hdr_base: 0x1b600
TBOOT:   vtd_pmr_lo_base: 0x0
TBOOT:   vtd_pmr_lo_size: 0x7a200000
TBOOT:   vtd_pmr_hi_base: 0x100000000
TBOOT:   vtd_pmr_hi_size: 0x3f80000000
TBOOT:   lcp_po_base: 0x0
TBOOT:   lcp_po_size: 0x0 (0)
TBOOT:   capabilities: 0x00000001
TBOOT:       rlp_wake_getsec: 1
TBOOT:       rlp_wake_monitor: 0
TBOOT:       ecx_pgtbl: 0
TBOOT:       stm: 0
TBOOT:       pcr_map_no_legacy: 0
TBOOT:       pcr_map_da: 0
TBOOT:       platform_type: 0
TBOOT:       max_phy_addr: 0
TBOOT:       tcg_event_log_format: 0
TBOOT:   efi_rsdt_ptr: 0x0
TBOOT:   ext_data_elts[]:
TBOOT:           EVENT_LOG_PTR:
TBOOT:                 size: 36
TBOOT:                count: 1
TBOOT:                   Log Descrption:
TBOOT:                               Alg: 4
TBOOT:                              Size: 4096
TBOOT:                      EventsOffset: [0,0]
TBOOT:                                No Event Log.
TBOOT: setting MTRRs for acmod: base=0x7bf00000, size=0x20000, num_pages=32
TBOOT: The maximum allowed MTRR range size=256 Pages
TBOOT: executing GETSEC[SENTER]...

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Paul M. (pmoore2) <pm...@ci...>]

On Wed, 2020-01-15 at 15:25 +0100, Lukasz Hawrylko wrote:
> On Tue, 2020-01-14 at 11:47 -0500, Paul Moore wrote:
> > On Tue, Jan 14, 2020 at 10:31 AM Lukasz Hawrylko
> > <
> > luk...@li...
> > > wrote:
> > > On Tue, 2020-01-14 at 00:18 +0000, Paul Moore (pmoore2) wrote:
> > > > On Mon, 2020-01-13 at 20:33 +0000, Paul Moore (pmoore2) via
> > > > tboot-devel wrote:
> > > > > On Thu, 2020-01-09 at 14:59 +0000, Hawrylko, Lukasz wrote:
> > > > > > On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) via
> > > > > > tboot-devel
> > > > > > wrote:
> > > > > > > Lukasz, is there a way to generate PCR hashes for all
> > > > > > > supported
> > > > > > > algorithms like tboot does for PCR17/18?
> > > > > > > 
> > > > > > > -Paul
> > > > > > > 
> > > > > > 
> > > > > > Hello Paul
> > > > > > 
> > > > > > I looks like you can't create policy with different hash
> > > > > > algorithms,
> > > > > > look at tb_policy_t structure in tb_policy.h There is one
> > > > > > field for
> > > > > > setting hash algorithm that is common to all policy entries.
> > > > > 
> > > > > Have you been able to create a VLP which causes tboot to
> > > > > extend the
> > > > > TPM's sha256 PCR bank?
> > > > > 
> > > > 
> > > > After digging through the code some more, it looks like the key
> > > > to
> > > > making this work is to specify the correct "extpol=" parameter
> > > > on the
> > > > tboot command line. It appears to be TPM and ACM dependent (?)
> > > > so I'm
> > > > not sure this will work for everyone, but on my system
> > > > "extpol=embedded" caused tboot to extend all of the TPM PCR
> > > > banks;
> > > > "extpol=agile" on my system caused the ACM to reset the system.
> > > > 
> > > > -Paul
> > > > 
> > > 
> > > As far as I remember I was able to extend SHA256 PCRs, because
> > > this is
> > > the only way to test my changes in tb_polgen. I am not sure, but I
> > > think
> > > that you have to pass "extpol=sha256" in command line and than you
> > > can
> > > work with SHA256 policies. Did you try to do that? I will try
> > > tomorrow
> > > how agile and embedded options work on my platform.
> > 
> > Yes, "extpol=sha256" did work to extend the sha256 PCR bank, but it
> > didn't extend the sha1 bank; ideally I would be able to do both and
> > that is what "extpol=embedded" did for my system.
> > 
> > I have a suspicion that instead of defaulting to sha1, we may be
> > able
> > to query the ACM to get the TPM2 extpol setting, but I haven't done
> > any serious investigation of that yet.
> > 
> > 
> 
> On my platform both "agile" and "embedded" options extends sha1 and
> sha256 banks. When using "agile" whole process is much longer because
> hash computation is done on TPM. In "embedded" hashes are computed
> locally and result is sent to TPM to extend PCRs. The easiest way to
> find out how that mechanism work is to look at hash_module() function
> in
> policy.c file.
> 
> Interesting thing is that on your platform you can't use "agile"
> method.
> If reset is invoked by SINIT ACM there should be error code value in
> TXT.ERRORCODE register, can you check what is there? TBOOT prints its
> value during each boot, so just allow platform to boot once again
> after
> that reset and you will find TXT.ERRORCODE somewhere in logs.

My TXT.ERRORCODE was set to 0xc0002081 when trying to boot with
extpol=agile.  I don't have the Type2 error code decoder spreadsheet/csv
to decode the error (the TXT specification document doesn't seem to
include the Type2 error codes anymore).

In related news, I added a patch to my working-txtsig GH development
branch which adds the "extpol=acm" option that cause tboot to query the
ACM and and set the extpol based on the ACM header information; it gives
the embedded policy priority when the ACM supports both embedded and
agile policies.

-Paul

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Lukasz H. <luk...@li...>]

On Tue, 2020-01-14 at 11:47 -0500, Paul Moore wrote:
> On Tue, Jan 14, 2020 at 10:31 AM Lukasz Hawrylko
> <
> luk...@li...
> > wrote:
> > On Tue, 2020-01-14 at 00:18 +0000, Paul Moore (pmoore2) wrote:
> > > On Mon, 2020-01-13 at 20:33 +0000, Paul Moore (pmoore2) via tboot-devel wrote:
> > > > On Thu, 2020-01-09 at 14:59 +0000, Hawrylko, Lukasz wrote:
> > > > > On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) via tboot-devel
> > > > > wrote:
> > > > > > Lukasz, is there a way to generate PCR hashes for all supported
> > > > > > algorithms like tboot does for PCR17/18?
> > > > > > 
> > > > > > -Paul
> > > > > > 
> > > > > 
> > > > > Hello Paul
> > > > > 
> > > > > I looks like you can't create policy with different hash algorithms,
> > > > > look at tb_policy_t structure in tb_policy.h There is one field for
> > > > > setting hash algorithm that is common to all policy entries.
> > > > 
> > > > Have you been able to create a VLP which causes tboot to extend the
> > > > TPM's sha256 PCR bank?
> > > > 
> > > 
> > > After digging through the code some more, it looks like the key to
> > > making this work is to specify the correct "extpol=" parameter on the
> > > tboot command line. It appears to be TPM and ACM dependent (?) so I'm
> > > not sure this will work for everyone, but on my system
> > > "extpol=embedded" caused tboot to extend all of the TPM PCR banks;
> > > "extpol=agile" on my system caused the ACM to reset the system.
> > > 
> > > -Paul
> > > 
> > 
> > As far as I remember I was able to extend SHA256 PCRs, because this is
> > the only way to test my changes in tb_polgen. I am not sure, but I think
> > that you have to pass "extpol=sha256" in command line and than you can
> > work with SHA256 policies. Did you try to do that? I will try tomorrow
> > how agile and embedded options work on my platform.
> 
> Yes, "extpol=sha256" did work to extend the sha256 PCR bank, but it
> didn't extend the sha1 bank; ideally I would be able to do both and
> that is what "extpol=embedded" did for my system.
> 
> I have a suspicion that instead of defaulting to sha1, we may be able
> to query the ACM to get the TPM2 extpol setting, but I haven't done
> any serious investigation of that yet.
> 
> 

On my platform both "agile" and "embedded" options extends sha1 and
sha256 banks. When using "agile" whole process is much longer because
hash computation is done on TPM. In "embedded" hashes are computed
locally and result is sent to TPM to extend PCRs. The easiest way to
find out how that mechanism work is to look at hash_module() function in
policy.c file.

Interesting thing is that on your platform you can't use "agile" method.
If reset is invoked by SINIT ACM there should be error code value in
TXT.ERRORCODE register, can you check what is there? TBOOT prints its
value during each boot, so just allow platform to boot once again after
that reset and you will find TXT.ERRORCODE somewhere in logs.

Thanks,
Lukasz

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Paul M. <pa...@pa...>]

On Tue, Jan 14, 2020 at 10:31 AM Lukasz Hawrylko
<luk...@li...> wrote:
> On Tue, 2020-01-14 at 00:18 +0000, Paul Moore (pmoore2) wrote:
> > On Mon, 2020-01-13 at 20:33 +0000, Paul Moore (pmoore2) via tboot-devel wrote:
> > > On Thu, 2020-01-09 at 14:59 +0000, Hawrylko, Lukasz wrote:
> > > > On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) via tboot-devel
> > > > wrote:
> > > > >
> > > > > Lukasz, is there a way to generate PCR hashes for all supported
> > > > > algorithms like tboot does for PCR17/18?
> > > > >
> > > > > -Paul
> > > > >
> > > >
> > > > Hello Paul
> > > >
> > > > I looks like you can't create policy with different hash algorithms,
> > > > look at tb_policy_t structure in tb_policy.h There is one field for
> > > > setting hash algorithm that is common to all policy entries.
> > >
> > > Have you been able to create a VLP which causes tboot to extend the
> > > TPM's sha256 PCR bank?
> > >
> >
> > After digging through the code some more, it looks like the key to
> > making this work is to specify the correct "extpol=" parameter on the
> > tboot command line. It appears to be TPM and ACM dependent (?) so I'm
> > not sure this will work for everyone, but on my system
> > "extpol=embedded" caused tboot to extend all of the TPM PCR banks;
> > "extpol=agile" on my system caused the ACM to reset the system.
> >
> > -Paul
> >
>
> As far as I remember I was able to extend SHA256 PCRs, because this is
> the only way to test my changes in tb_polgen. I am not sure, but I think
> that you have to pass "extpol=sha256" in command line and than you can
> work with SHA256 policies. Did you try to do that? I will try tomorrow
> how agile and embedded options work on my platform.

Yes, "extpol=sha256" did work to extend the sha256 PCR bank, but it
didn't extend the sha1 bank; ideally I would be able to do both and
that is what "extpol=embedded" did for my system.

I have a suspicion that instead of defaulting to sha1, we may be able
to query the ACM to get the TPM2 extpol setting, but I haven't done
any serious investigation of that yet.

-- 
paul moore
www.paul-moore.com

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Lukasz H. <luk...@li...>]

On Tue, 2020-01-14 at 00:18 +0000, Paul Moore (pmoore2) wrote:
> On Mon, 2020-01-13 at 20:33 +0000, Paul Moore (pmoore2) via tboot-devel wrote:
> > On Thu, 2020-01-09 at 14:59 +0000, Hawrylko, Lukasz wrote:
> > > On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) via tboot-devel
> > > wrote:
> > > > 
> > > > Lukasz, is there a way to generate PCR hashes for all supported
> > > > algorithms like tboot does for PCR17/18?
> > > > 
> > > > -Paul
> > > > 
> > >  
> > > Hello Paul
> > > 
> > > I looks like you can't create policy with different hash algorithms,
> > > look at tb_policy_t structure in tb_policy.h There is one field for
> > > setting hash algorithm that is common to all policy entries.
> > 
> > Have you been able to create a VLP which causes tboot to extend the
> > TPM's sha256 PCR bank?
> > 
> 
> After digging through the code some more, it looks like the key to
> making this work is to specify the correct "extpol=" parameter on the
> tboot command line. It appears to be TPM and ACM dependent (?) so I'm
> not sure this will work for everyone, but on my system
> "extpol=embedded" caused tboot to extend all of the TPM PCR banks;
> "extpol=agile" on my system caused the ACM to reset the system.
> 
> -Paul
> 

As far as I remember I was able to extend SHA256 PCRs, because this is
the only way to test my changes in tb_polgen. I am not sure, but I think
that you have to pass "extpol=sha256" in command line and than you can
work with SHA256 policies. Did you try to do that? I will try tomorrow
how agile and embedded options work on my platform.

Thanks,
Lukasz

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Paul M. (pmoore2) <pm...@ci...>]

On Mon, 2020-01-13 at 20:33 +0000, Paul Moore (pmoore2) via tboot-devel wrote:
On Thu, 2020-01-09 at 14:59 +0000, Hawrylko, Lukasz wrote:

On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) via tboot-devel

wrote:

On Fri, 2020-01-03 at 20:07 +0000, Paul Moore (pmoore2) via tboot-devel

wrote:

On Thu, 2020-01-02 at 22:27 +0000, Paul Moore (pmoore2) via tboot-

devel

wrote:

I hope everyone had a nice holiday and is enjoying the new year thus

far.


As you've seen in the other thread, I'm playing around with

different

tboot/TXT policies and I have a question regarding tboot/VLP

policies

that can extend PCRs using something other than SHA1: at present

tb_polgen seems limited to using SHA1, does anyone have any patches

to

use SHA256 (or another hash)?


To answer my own question, it appears that Lukasz added suppport in

549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").


Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2

system, would I need to create two rules in the VLP?  For example I do

the following now for the TXT/sig patches and PCR20:


 # tb_polgen --add --num 0 --pcr 20 \

     --hash pecoff pecoff.vlp


... but that only writes the SHA1 hash into PCR20, presumably I could

do

the following to support both hashes?


 # tb_polgen --add --num 0 --pcr 20 --alg sha1 \

     --hash pecoff pecoff.vlp

 # tb_polgen --add --num 0 --pcr 20 --alg sha256 \

     --hash pecoff pecoff.vlp



It appears I didn't look close enough at the patch, the hash algorithm

selection is done at VLP policy creation and applies to all the rules.


Lukasz, is there a way to generate PCR hashes for all supported

algorithms like tboot does for PCR17/18?


-Paul



Hello Paul


I looks like you can't create policy with different hash algorithms,

look at tb_policy_t structure in tb_policy.h There is one field for

setting hash algorithm that is common to all policy entries.

Have you been able to create a VLP which causes tboot to extend the TPM's sha256 PCR bank?


After digging through the code some more, it looks like the key to making this work is to specify the correct "extpol=" parameter on the tboot command line. It appears to be TPM and ACM dependent (?) so I'm not sure this will work for everyone, but on my system "extpol=embedded" caused tboot to extend all of the TPM PCR banks; "extpol=agile" on my system caused the ACM to reset the system.

-Paul

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Paul M. (pmoore2) <pm...@ci...>]

On Thu, 2020-01-09 at 14:59 +0000, Hawrylko, Lukasz wrote:

On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) via tboot-devel

wrote:

On Fri, 2020-01-03 at 20:07 +0000, Paul Moore (pmoore2) via tboot-devel

wrote:

On Thu, 2020-01-02 at 22:27 +0000, Paul Moore (pmoore2) via tboot-

devel

wrote:

I hope everyone had a nice holiday and is enjoying the new year thus

far.


As you've seen in the other thread, I'm playing around with

different

tboot/TXT policies and I have a question regarding tboot/VLP

policies

that can extend PCRs using something other than SHA1: at present

tb_polgen seems limited to using SHA1, does anyone have any patches

to

use SHA256 (or another hash)?


To answer my own question, it appears that Lukasz added suppport in

549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").


Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2

system, would I need to create two rules in the VLP?  For example I do

the following now for the TXT/sig patches and PCR20:


 # tb_polgen --add --num 0 --pcr 20 \

     --hash pecoff pecoff.vlp


... but that only writes the SHA1 hash into PCR20, presumably I could

do

the following to support both hashes?


 # tb_polgen --add --num 0 --pcr 20 --alg sha1 \

     --hash pecoff pecoff.vlp

 # tb_polgen --add --num 0 --pcr 20 --alg sha256 \

     --hash pecoff pecoff.vlp



It appears I didn't look close enough at the patch, the hash algorithm

selection is done at VLP policy creation and applies to all the rules.


Lukasz, is there a way to generate PCR hashes for all supported

algorithms like tboot does for PCR17/18?


-Paul



Hello Paul


I looks like you can't create policy with different hash algorithms,

look at tb_policy_t structure in tb_policy.h There is one field for

setting hash algorithm that is common to all policy entries.

Have you been able to create a VLP which causes tboot to extend the TPM's sha256 PCR bank?

-Paul

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Lukasz H. <luk...@li...>]

On Fri, 2020-01-03 at 20:26 +0000, Paul Moore (pmoore2) wrote:
> On Fri, 2020-01-03 at 20:07 +0000, Paul Moore (pmoore2) via tboot-devel
> wrote:
> > On Thu, 2020-01-02 at 22:27 +0000, Paul Moore (pmoore2) via tboot-
> > devel
> > wrote:
> > > I hope everyone had a nice holiday and is enjoying the new year thus
> > > far.
> > > 
> > > As you've seen in the other thread, I'm playing around with
> > > different
> > > tboot/TXT policies and I have a question regarding tboot/VLP
> > > policies
> > > that can extend PCRs using something other than SHA1: at present
> > > tb_polgen seems limited to using SHA1, does anyone have any patches
> > > to
> > > use SHA256 (or another hash)?
> > 
> > To answer my own question, it appears that Lukasz added suppport in
> > 549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").
> > 
> > Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
> > system, would I need to create two rules in the VLP?  For example I do
> > the following now for the TXT/sig patches and PCR20:
> > 
> >  # tb_polgen --add --num 0 --pcr 20 \
> >      --hash pecoff pecoff.vlp
> > 
> > ... but that only writes the SHA1 hash into PCR20, presumably I could
> > do
> > the following to support both hashes?
> > 
> >  # tb_polgen --add --num 0 --pcr 20 --alg sha1 \
> >      --hash pecoff pecoff.vlp
> >  # tb_polgen --add --num 0 --pcr 20 --alg sha256 \
> >      --hash pecoff pecoff.vlp
> > 
> 
> It appears I didn't look close enough at the patch, the hash algorithm
> selection is done at VLP policy creation and applies to all the rules.
> 
> Lukasz, is there a way to generate PCR hashes for all supported
> algorithms like tboot does for PCR17/18?
> 
> -Paul
> 

Hello Paul

I looks like you can't create policy with different hash algorithms,
look at tb_policy_t structure in tb_policy.h There is one field for
setting hash algorithm that is common to all policy entries.

Thanks,
Lukasz

Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2

[Paul M. (pmoore2) <pm...@ci...>]

On Mon, 2019-12-23 at 21:20 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> It appears that lcptools-v2 doesn't understand the "pconf" type ...

I just added a new "pconf2" policy element type to lcptools-v2 so you
can generate a LCP_PCONF_ELEMENT2 without having to resort to the lcp-
gen2 tools.  As the Intel TXT developers guide isn't as detailed as I
would like, this is based mostly off the lcp-gen2 python code and may
have some bugs.  That said, it is working on my test system tracking
both PCR0 and PCR2.

If you want to play with it, you can find it in my working-txtsig
development branch:

* https://github.com/pcmoore/misc-tboot/tree/working-txtsig

-Paul

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Paul M. (pmoore2) <pm...@ci...>]

On Fri, 2020-01-03 at 20:07 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Thu, 2020-01-02 at 22:27 +0000, Paul Moore (pmoore2) via tboot-
> devel
> wrote:
> > I hope everyone had a nice holiday and is enjoying the new year thus
> > far.
> > 
> > As you've seen in the other thread, I'm playing around with
> > different
> > tboot/TXT policies and I have a question regarding tboot/VLP
> > policies
> > that can extend PCRs using something other than SHA1: at present
> > tb_polgen seems limited to using SHA1, does anyone have any patches
> > to
> > use SHA256 (or another hash)?
> 
> To answer my own question, it appears that Lukasz added suppport in
> 549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").
> 
> Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
> system, would I need to create two rules in the VLP?  For example I do
> the following now for the TXT/sig patches and PCR20:
> 
>  # tb_polgen --add --num 0 --pcr 20 \
>      --hash pecoff pecoff.vlp
> 
> ... but that only writes the SHA1 hash into PCR20, presumably I could
> do
> the following to support both hashes?
> 
>  # tb_polgen --add --num 0 --pcr 20 --alg sha1 \
>      --hash pecoff pecoff.vlp
>  # tb_polgen --add --num 0 --pcr 20 --alg sha256 \
>      --hash pecoff pecoff.vlp
> 

It appears I didn't look close enough at the patch, the hash algorithm
selection is done at VLP policy creation and applies to all the rules.

Lukasz, is there a way to generate PCR hashes for all supported
algorithms like tboot does for PCR17/18?

-Paul

Re: [tboot-devel] VLP policy and TPM2 hash agility

[Paul M. (pmoore2) <pm...@ci...>]

On Thu, 2020-01-02 at 22:27 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> I hope everyone had a nice holiday and is enjoying the new year thus
> far.
> 
> As you've seen in the other thread, I'm playing around with different
> tboot/TXT policies and I have a question regarding tboot/VLP policies
> that can extend PCRs using something other than SHA1: at present
> tb_polgen seems limited to using SHA1, does anyone have any patches to
> use SHA256 (or another hash)?

To answer my own question, it appears that Lukasz added suppport in
549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").

Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
system, would I need to create two rules in the VLP?  For example I do
the following now for the TXT/sig patches and PCR20:

 # tb_polgen --add --num 0 --pcr 20 \
     --hash pecoff pecoff.vlp

... but that only writes the SHA1 hash into PCR20, presumably I could do
the following to support both hashes?

 # tb_polgen --add --num 0 --pcr 20 --alg sha1 \
     --hash pecoff pecoff.vlp
 # tb_polgen --add --num 0 --pcr 20 --alg sha256 \
     --hash pecoff pecoff.vlp

-Paul

[tboot-devel] VLP policy and TPM2 hash agility

[Paul M. (pmoore2) <pm...@ci...>]

I hope everyone had a nice holiday and is enjoying the new year thus
far.

As you've seen in the other thread, I'm playing around with different
tboot/TXT policies and I have a question regarding tboot/VLP policies
that can extend PCRs using something other than SHA1: at present
tb_polgen seems limited to using SHA1, does anyone have any patches to
use SHA256 (or another hash)?

-Paul

Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2

[Paul M. (pmoore2) <pm...@ci...>]

On Wed, 2019-11-06 at 20:12 +0000, Tra...@de... wrote:
> > -----Original Message-----
> > From: Paul Moore (pmoore2) <pm...@ci...>
> > Sent: Tuesday, November 5, 2019 19:28
> > To: Gilbert, Travis
> > Cc: tbo...@li...
> > Subject: Re: Creating a TXT/tboot policy suitable for a modern
> > system with TXT+TPM2

...

> > If you're willing to share your other examples, I'd love to see
> > them, and I'm sure others would as well.
> > 
> > Thanks again.
> 
> I've got about 20 some of which are negative test cases. They're bash
> scripts. I've stripped out the beginning shell line to make it more
> email handler friendly. #9 is actually split into 5 different tests
> signing various other policies that were previously unsigned. They
> were designed to be run in order as some later tests rely on the
> outputs of previous tests. I've included #3 and one of #9. Let me know
> if you have interest in any of the others.

Hi Travis,

I'm sorry it took me a while to get back to this and try out the
scripts, but if you are still willing to share I'd love to see all of
them.

Another question below ...

> TXT - Scenario#1, Single MLE element and Unsigned Policy
> TXT - Scenario#2, Three MLE elements and Unsigned LCP
> TXT - Scenario#3, One PCONF element and Unsigned LCP
> TXT - Scenario#4, Two PCONF elements and Unsigned LCP
> TXT - Scenario#5, MLE, PCONF list Unsigned
> TXT - Scenario#6, SINIT Revocation (Negative Testing)
> TXT - Scenario#7, MLE Mismatch 1 - wrong hash file (Negative Testing)
> TXT - Scenario#8, PCONF mismatch (Negative Testing)
> TXT - Scenario#9, Signed policies with 2048 keys
> TXT - Scenario#10, Signed policy with 1024 key
> TXT - Scenario#11, Signed policy with 3072 key
> TXT - Scenario#12: signed policy with invalid key size (2000)
> TXT - Scenario#13 Input Validation, signed policy with invalid key
> size (512)
> TXT - Scenario#14, signed policy with invalid key size (4096)
> TXT - Scenario#15, MLE Mismatch - change in boot parameters (Negative
> Testing)
> 
> <3>
> cd /boot
> tpm2_takeownership -o new -e new -l new
> tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A
> 
> #TXT - Scenario#3, One PCONF element and Unsigned LCP
> tpm2_listpcrs -g 0x0B -o 1pcrs
> truncate -s 32 1pcrs #only select PCR0 for the policy
> lcp2_crtpolelt --create --type pconf --out 1pconf.elt 1pcrs

It appears that lcptools-v2 doesn't understand the "pconf" type, do you
have a patch/branch/etc. that I could take a look at?  I see that
lcptools seems to have some basic support, and I'm sure if I dug into
Intel's specs I could add it, but I'm guessing you've already done the
hard work :)

Thanks,
-Paul

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Fri, 2019-12-20 at 10:51 +0100, Lukasz Hawrylko wrote:
> On Tue, 2019-12-17 at 20:12 +0000, Paul Moore (pmoore2) wrote:
> > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > > On Thu, 2019-12-05 at 17:20 +0000, Paul Moore (pmoore2) wrote:
> > > > A question for discussion: if the VLP is loaded from it's own
> > > > nvindex,
> > > > and there is also a VLP present inside the LCP, which VLP do we
> > > > want
> > > > to
> > > > use?  I'm assuming it is the VLP we loaded directly, and not
> > > > from
> > > > inside
> > > > the LCP, but thought it was worth checking.
> > > >  
> > > 
> > > In "stock" TBOOT, VLP loaded from its own index has higher
> > > priority
> > > over
> > > one embedded in LCP, so I agree with you that here it should work
> > > like
> > > that.
> > 
> > I was thinking about this some more and I'm now wondering if we
> > should
> > only support the new TB_HTYPE_PECOFF hash type if it is present in a
> > VLP
> > loaded from the LCP.  In order to use the new signature support
> > admins
> > are going to need to generate a new LCP to contain the certificate
> > payload, why not store the VLP in the LCP at that point?
> 
> To be honest I don't like to add any kind of limitation when it is not
> needed. I think that in first approach we should allow to use any of
> possible configurations. If admins prefer to delete VLP index in TPM
> and
> put everything in LCP, they will do it, if, for any reasons, they want
> to keep VLP under its own index and put only certificate in LCP - why
> not, we support that case too :)

Okay, that's fine.  FWIW, it seems to me as if keeping the VLP in it's
own nvindex is a bit of a legacy solution, especially when we consider
the PECOFF signature validation.  In the PECOFF case you *must* have a
LCP to carry the certificates.  Not to mention the benefits of a signed
LCP allowing you to update the policy without updating the values stored
in the TPM nvindex (assuming the same policy signing key).

> > Is there any advantage to storing the VLP directly in the TPM and
> > not in
> > the LCP?
> > 
> > -Paul
> > 
> 
> That's a good question. I don't know if customers prefer to use VLP in
> LCP or directly, I will talk with our application engineers about
> that.

Thanks.

-Paul

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Lukasz H. <luk...@li...>]

On Tue, 2019-12-17 at 20:06 +0000, Paul Moore (pmoore2) wrote:
> On Fri, 2019-12-06 at 21:28 +0000, Paul Moore (pmoore2) via tboot-devel
> wrote:
> > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > > On Wed, 2019-12-04 at 14:33 +0000, Paul Moore (pmoore2) wrote:
> > > > Can you elaborate a bit more on what you mean by "the root of
> > > > certificate"?  Alternatively, could you upload the kernel and
> > > > signing
> > > > certificate somewhere I could grab so I can play with it?
> > > 
> > > Maybe I used wrong words, I am talking about pkcs1_search_signer
> > > function and following lines:
> > > 
> > >   if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
> > >       !asn1_blob_cmp(&entry->cert.ca->subject, subject))
> > > 
> > > If I change them to
> > > 
> > >   if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
> > >       !asn1_blob_cmp(&entry->cert.subject, subject))
> > > 
> > > it will find my certificate.
> > 
> > Thanks, that makes it much more clear.  One of the benefits of sharing
> > code is that it helps remove any uncertainties. :)
> > 
> > > Could you please explain me why are you
> > > using serial from root of entry and subject from sub-element? Is it
> > > connected with certificate chain? What if there is just the simplest
> > > possible certificate that is not signed by anybody?
> > 
> > That does look a little odd, doesn't it?
> 
> It turns out it wasn't quite as odd as originally thought.  While wrong,
> it wasn't far from the truth; the PKCS #7 blob in the signed PECOFF
> kernel image doesn't contain the signer's subject name, but rather the
> issuer's subject name.  This explains why the code worked: in the self-
> signed (Lukasz's test case) and one intermediate CA cases (the Fedora
> test case) using the CA would result in the signer being found, anything
> with more than one intermediate CA would fail.
> 
> I've corrected the code and pushed it to the repo/branch below:
> 
> * 
> https://github.com/pcmoore/misc-tboot/tree/working-txtsig
> 
> 
> 
> > > I have uploaded certificate and key that I have generated here: 
> > > https://cloud.hawrylko.pl/s/ivHd7HZpuLIjQ88
> > >  there is also a signed
> > > bzImage that I am using.
> > 
> > Great, thank you.  I'll take a closer look.
> 
> It turns out this was due to a limitation in libtomfastmath.  Your test
> key/certificate used a 4k RSA key, but libtomfastmath had a restriction
> on keys larger than 2k (it turns out the Fedora keys are 2k).  I
> increased the libtomfastmath number limit to support 4k keys, and
> increased the tboot stack size accordingly.  The updated misc-
> tboot/working-txtsig code should now work for your self-signed test
> case, if not please let me know.
> 
> Thanks,
> -Paul
> 
> 

Great, I will test it after Christmas break.

Thanks,
Lukasz

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Lukasz H. <luk...@li...>]

On Tue, 2019-12-17 at 20:12 +0000, Paul Moore (pmoore2) wrote:
> On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > On Thu, 2019-12-05 at 17:20 +0000, Paul Moore (pmoore2) wrote:
> > > A question for discussion: if the VLP is loaded from it's own
> > > nvindex,
> > > and there is also a VLP present inside the LCP, which VLP do we want
> > > to
> > > use?  I'm assuming it is the VLP we loaded directly, and not from
> > > inside
> > > the LCP, but thought it was worth checking.
> > >  
> > 
> > In "stock" TBOOT, VLP loaded from its own index has higher priority
> > over
> > one embedded in LCP, so I agree with you that here it should work like
> > that.
> 
> I was thinking about this some more and I'm now wondering if we should
> only support the new TB_HTYPE_PECOFF hash type if it is present in a VLP
> loaded from the LCP.  In order to use the new signature support admins
> are going to need to generate a new LCP to contain the certificate
> payload, why not store the VLP in the LCP at that point?

To be honest I don't like to add any kind of limitation when it is not
needed. I think that in first approach we should allow to use any of
possible configurations. If admins prefer to delete VLP index in TPM and
put everything in LCP, they will do it, if, for any reasons, they want
to keep VLP under its own index and put only certificate in LCP - why
not, we support that case too :)

> Is there any advantage to storing the VLP directly in the TPM and not in
> the LCP?
> 
> -Paul
> 

That's a good question. I don't know if customers prefer to use VLP in
LCP or directly, I will talk with our application engineers about that.

Thanks,
Lukasz

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> On Thu, 2019-12-05 at 17:20 +0000, Paul Moore (pmoore2) wrote:
> > A question for discussion: if the VLP is loaded from it's own
> > nvindex,
> > and there is also a VLP present inside the LCP, which VLP do we want
> > to
> > use?  I'm assuming it is the VLP we loaded directly, and not from
> > inside
> > the LCP, but thought it was worth checking.
> >  
> 
> In "stock" TBOOT, VLP loaded from its own index has higher priority
> over
> one embedded in LCP, so I agree with you that here it should work like
> that.

I was thinking about this some more and I'm now wondering if we should
only support the new TB_HTYPE_PECOFF hash type if it is present in a VLP
loaded from the LCP.  In order to use the new signature support admins
are going to need to generate a new LCP to contain the certificate
payload, why not store the VLP in the LCP at that point?

Is there any advantage to storing the VLP directly in the TPM and not in
the LCP?

-Paul

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. (pmoore2) <pm...@ci...>]

On Fri, 2019-12-06 at 21:28 +0000, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > On Wed, 2019-12-04 at 14:33 +0000, Paul Moore (pmoore2) wrote:
> > > Can you elaborate a bit more on what you mean by "the root of
> > > certificate"?  Alternatively, could you upload the kernel and
> > > signing
> > > certificate somewhere I could grab so I can play with it?
> > 
> > Maybe I used wrong words, I am talking about pkcs1_search_signer
> > function and following lines:
> > 
> >   if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
> >       !asn1_blob_cmp(&entry->cert.ca->subject, subject))
> > 
> > If I change them to
> > 
> >   if (!asn1_blob_cmp(&entry->cert.serial, serial) &&
> >       !asn1_blob_cmp(&entry->cert.subject, subject))
> > 
> > it will find my certificate.
> 
> Thanks, that makes it much more clear.  One of the benefits of sharing
> code is that it helps remove any uncertainties. :)
> 
> > Could you please explain me why are you
> > using serial from root of entry and subject from sub-element? Is it
> > connected with certificate chain? What if there is just the simplest
> > possible certificate that is not signed by anybody?
> 
> That does look a little odd, doesn't it?

It turns out it wasn't quite as odd as originally thought.  While wrong,
it wasn't far from the truth; the PKCS #7 blob in the signed PECOFF
kernel image doesn't contain the signer's subject name, but rather the
issuer's subject name.  This explains why the code worked: in the self-
signed (Lukasz's test case) and one intermediate CA cases (the Fedora
test case) using the CA would result in the signer being found, anything
with more than one intermediate CA would fail.

I've corrected the code and pushed it to the repo/branch below:

* https://github.com/pcmoore/misc-tboot/tree/working-txtsig


> > I have uploaded certificate and key that I have generated here: 
> > https://cloud.hawrylko.pl/s/ivHd7HZpuLIjQ88 there is also a signed
> > bzImage that I am using.
> 
> Great, thank you.  I'll take a closer look.

It turns out this was due to a limitation in libtomfastmath.  Your test
key/certificate used a 4k RSA key, but libtomfastmath had a restriction
on keys larger than 2k (it turns out the Fedora keys are 2k).  I
increased the libtomfastmath number limit to support 4k keys, and
increased the tboot stack size accordingly.  The updated misc-
tboot/working-txtsig code should now work for your self-signed test
case, if not please let me know.

Thanks,
-Paul