Menu
▾
▴
tboot-devel — Developer support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
(8) |
Apr
(14) |
May
(8) |
Jun
(10) |
Jul
(14) |
Aug
(3) |
Sep
(13) |
Oct
(27) |
Nov
(39) |
Dec
(24) |
| 2009 |
Jan
(19) |
Feb
(4) |
Mar
(2) |
Apr
(15) |
May
|
Jun
(2) |
Jul
(44) |
Aug
(21) |
Sep
(20) |
Oct
(2) |
Nov
(1) |
Dec
(7) |
| 2010 |
Jan
(7) |
Feb
(10) |
Mar
(2) |
Apr
(12) |
May
(7) |
Jun
(2) |
Jul
(18) |
Aug
(11) |
Sep
(4) |
Oct
(25) |
Nov
(8) |
Dec
(1) |
| 2011 |
Jan
(27) |
Feb
(2) |
Mar
(19) |
Apr
(8) |
May
(16) |
Jun
(11) |
Jul
(9) |
Aug
(9) |
Sep
(35) |
Oct
(9) |
Nov
(8) |
Dec
(32) |
| 2012 |
Jan
(37) |
Feb
(20) |
Mar
(2) |
Apr
(24) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(21) |
Sep
(8) |
Oct
(15) |
Nov
(1) |
Dec
(7) |
| 2013 |
Jan
(4) |
Feb
(8) |
Mar
(38) |
Apr
(9) |
May
(42) |
Jun
(4) |
Jul
(21) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2014 |
Jan
(8) |
Feb
(8) |
Mar
(5) |
Apr
(9) |
May
(19) |
Jun
(1) |
Jul
(10) |
Aug
(25) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(12) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
(5) |
Nov
(3) |
Dec
(1) |
| 2016 |
Jan
(2) |
Feb
(24) |
Mar
|
Apr
(6) |
May
(26) |
Jun
(20) |
Jul
(8) |
Aug
(15) |
Sep
(21) |
Oct
(1) |
Nov
(7) |
Dec
(24) |
| 2017 |
Jan
(12) |
Feb
(2) |
Mar
(6) |
Apr
(8) |
May
(18) |
Jun
(13) |
Jul
(12) |
Aug
(8) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
(12) |
Mar
(8) |
Apr
(5) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
| 2019 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2020 |
Jan
(25) |
Feb
(12) |
Mar
(2) |
Apr
(13) |
May
(44) |
Jun
(9) |
Jul
|
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
|
| 2021 |
Jan
(6) |
Feb
|
Mar
(7) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(16) |
Sep
(4) |
Oct
(6) |
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
(5) |
Feb
(4) |
Mar
(22) |
Apr
(6) |
May
(4) |
Jun
(17) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2023 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christopher C. <chr...@gm...> - 2020-01-24 18:41:06
|
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 |
|
From: Martin G. <omg...@gm...> - 2020-01-24 15:35:02
|
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?
|
|
From: Martin G. <omg...@gm...> - 2020-01-24 14:39:28
|
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. |
|
From: Lukasz H. <luk...@li...> - 2020-01-24 14:34:11
|
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 |
|
From: Martin G. <omg...@gm...> - 2020-01-23 17:41:43
|
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?
|
|
From: Lukasz H. <luk...@li...> - 2020-01-21 08:32:49
|
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
|
|
From: Christopher C. <chr...@gm...> - 2020-01-16 02:36:42
|
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]...
|
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-15 19:54:47
|
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 |
|
From: Lukasz H. <luk...@li...> - 2020-01-15 14:25:39
|
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 |
|
From: Paul M. <pa...@pa...> - 2020-01-14 17:14:52
|
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 |
|
From: Lukasz H. <luk...@li...> - 2020-01-14 15:30:38
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-14 00:18:48
|
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
|
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-13 20:34:15
|
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
|
|
From: Lukasz H. <luk...@li...> - 2020-01-10 13:20:50
|
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
|
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-09 20:38:39
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-03 20:26:26
|
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
|
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-03 20:07:18
|
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
|
|
From: Paul M. (pmoore2) <pm...@ci...> - 2020-01-02 22:27:22
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2019-12-23 21:20:21
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2019-12-21 16:59:39
|
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 |
|
From: Lukasz H. <luk...@li...> - 2019-12-20 09:53:15
|
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 |
|
From: Lukasz H. <luk...@li...> - 2019-12-20 09:51:45
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2019-12-17 20:13:10
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2019-12-17 20:06:28
|
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 |
|
From: Paul M. (pmoore2) <pm...@ci...> - 2019-12-17 16:35:44
|
On Mon, 2019-12-09 at 15:23 +0100, Lukasz Hawrylko wrote: > On Fri, 2019-12-06 at 21:28 +0000, Paul Moore (pmoore2) wrote: > > I know I've said this before, but please consider all of this code > > still > > a very rough prototype. Normally I wouldn't share code of this > > quality, > > but since there are a large number of uncertainties surrounding this > > work (e.g. is this approach reasonable? are the policy changes > > okay? > > etc.) I felt the advantages of sharing this code at such an early > > stage > > outweighed the risks. > > I totally understand that, it's nice that you are sharing your WIP > code, > so we can discuss changes on the fly. If I wrote something that > suggests > that I blame you for that, it's only a result of fact that English > is not my native language :) No worries, no offense was taken, I just wanted to make sure that the expectations were set appropriately. Also, I just wanted to say that your English is just fine, it's *far* better than my Polish ;) -Paul |
15 messages has been excluded from this view by a project administrator.
