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
(1) |
Nov
(1) |
Dec
|
|
From: Cihula, J. <jos...@in...> - 2009-04-09 23:37:05
|
If you disable legacy USB in the BIOS, does that fix the hang? Joe > -----Original Message----- > From: Alana Libonati [mailto:al...@cs...] > Sent: Thursday, April 09, 2009 4:26 PM > To: tbo...@li... > Subject: Re: [tboot-devel] stuck on GETSEC[SENTER] > > > On Thu, 9 Apr 2009, Cihula, Joseph wrote: > > > Can you boot into native Linux and post the e820 table. > > > > Joe > > Sure, here it is: > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ac00 (usable) > [ 0.000000] BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000d6000 - 00000000000d8000 (reserved) > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bc1a1000 (usable) > [ 0.000000] BIOS-e820: 00000000bc1a1000 - 00000000bc1a7000 (reserved) > [ 0.000000] BIOS-e820: 00000000bc1a7000 - 00000000bc2b7000 (usable) > [ 0.000000] BIOS-e820: 00000000bc2b7000 - 00000000bc30f000 (reserved) > [ 0.000000] BIOS-e820: 00000000bc30f000 - 00000000bc3c6000 (usable) > [ 0.000000] BIOS-e820: 00000000bc3c6000 - 00000000bc3d1000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bc3d1000 - 00000000bc3d4000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000bc3d4000 - 00000000bc3d8000 (reserved) > [ 0.000000] BIOS-e820: 00000000bc3d8000 - 00000000bc3dc000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bc3dc000 - 00000000bc3df000 (reserved) > [ 0.000000] BIOS-e820: 00000000bc3df000 - 00000000bc406000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bc406000 - 00000000bc408000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000bc408000 - 00000000bc60f000 (reserved) > [ 0.000000] BIOS-e820: 00000000bc60f000 - 00000000bc69f000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bc69f000 - 00000000bc6ff000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000bc6ff000 - 00000000bc700000 (usable) > [ 0.000000] BIOS-e820: 00000000bcc00000 - 00000000bf000000 (reserved) > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > [ 0.000000] BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) > > Thanks, > Alana > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Alana L. <al...@cs...> - 2009-04-09 23:26:16
|
On Thu, 9 Apr 2009, Cihula, Joseph wrote: > Can you boot into native Linux and post the e820 table. > > Joe Sure, here it is: [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ac00 (usable) [ 0.000000] BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000d6000 - 00000000000d8000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bc1a1000 (usable) [ 0.000000] BIOS-e820: 00000000bc1a1000 - 00000000bc1a7000 (reserved) [ 0.000000] BIOS-e820: 00000000bc1a7000 - 00000000bc2b7000 (usable) [ 0.000000] BIOS-e820: 00000000bc2b7000 - 00000000bc30f000 (reserved) [ 0.000000] BIOS-e820: 00000000bc30f000 - 00000000bc3c6000 (usable) [ 0.000000] BIOS-e820: 00000000bc3c6000 - 00000000bc3d1000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bc3d1000 - 00000000bc3d4000 (ACPI data) [ 0.000000] BIOS-e820: 00000000bc3d4000 - 00000000bc3d8000 (reserved) [ 0.000000] BIOS-e820: 00000000bc3d8000 - 00000000bc3dc000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bc3dc000 - 00000000bc3df000 (reserved) [ 0.000000] BIOS-e820: 00000000bc3df000 - 00000000bc406000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bc406000 - 00000000bc408000 (ACPI data) [ 0.000000] BIOS-e820: 00000000bc408000 - 00000000bc60f000 (reserved) [ 0.000000] BIOS-e820: 00000000bc60f000 - 00000000bc69f000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bc69f000 - 00000000bc6ff000 (ACPI data) [ 0.000000] BIOS-e820: 00000000bc6ff000 - 00000000bc700000 (usable) [ 0.000000] BIOS-e820: 00000000bcc00000 - 00000000bf000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved) [ 0.000000] BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) Thanks, Alana |
|
From: Cihula, J. <jos...@in...> - 2009-04-09 22:50:41
|
> From: Alana Libonati [mailto:al...@cs...] > Sent: Thursday, April 09, 2009 12:30 PM > > Hi, > > I've been trying to get tboot working on my Lenovo T400, but it always gets > stuck at the executing GETSEC[SENTER] stage and then I have to power it down. I > can still use the num lock key (the light goes on/off), but not caps lock when > this happens, so I don't know if something is still happening or not at this > point... > > I have TXT, VT-d and VT-x enabled in the BIOS, and the TPM is active. It is the > latest BIOS (version 2.12) from Lenovo. I am using the tboot source from March > 30th and the 2.6.29-tip kernel patched with the tboot patches from the lkml.org > post. However, I've had the exact same behavior with the 2.6.27-11-generic > (unpatched) Ubuntu kernel and also with the previous version of tboot (from > January). > > Any advice is appreciated, I'm posting my complete tboot log below. Can you boot into native Linux and post the e820 table. Joe > > Thanks, > Alana > > TBOOT: ******************* TBOOT ******************* > TBOOT: unavailable > TBOOT: ********************************************* > TBOOT: command line: logging=serial,vga,memory > TBOOT: TPM is ready > TBOOT: TPM nv_locked: TRUE > TBOOT: TPM: get capability, return value = 00000002 > TBOOT: failed to get actual policy size in TPM NV > 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: 2 > 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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = > 00000002 > TBOOT: Error: write TPM error: 0x2. > TBOOT: no policy in TPM NV. > TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff0f > TBOOT: CPU is SMX-capable > TBOOT: CPU is VMX-capable > TBOOT: SMX is enabled > TBOOT: TXT chipset and all needed capabilities present > TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = > 00000002 > TBOOT: Error: write TPM error: 0x2. > TBOOT: LT.ERRORCODE=0 > TBOOT: LT.ESTS=0 > TBOOT: bios_data (@bc920008, 2c): > TBOOT: version: 3 > TBOOT: bios_sinit_size: 0x0 (0) > TBOOT: lcp_pd_base: 0x0 > TBOOT: lcp_pd_size: 0x0 (0) > TBOOT: num_logical_procs: 2 > TBOOT: flags: 0x00000001 > TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = > 00000002 > TBOOT: Error: write TPM error: 0x2.TBOOT: CR0 and EFLAGS OK > TBOOT: no machine check errors > TBOOT: CPU is ready for SENTER > TBOOT: checking previous errors on the last boot. > TPM: read nv index 20000002 offset 00000000, return value = 00000002 > TBOOT: Error: read TPM error: 0x2. > TBOOT: last boot has no error. > TBOOT: user-provided SINIT found: /boot/GM45_PM45_SINIT_19.BIN > TBOOT: chipset ids: vendor=8086, device=9000, revision=7f > TBOOT: 1 ACM chipset id entries: > TBOOT: vendor=8086, device=9000, flags=1, revision=3f, extended=0 > TBOOT: copied SINIT (size=67c0) to bc900000 > 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: length: 0xa1 (161) > TBOOT: version: 0 > TBOOT: chipset_id: 0x2a40 > TBOOT: flags: 0x0 > TBOOT: pre_production: 0 > TBOOT: debug_signed: 0 > TBOOT: vendor: 0x8086 > TBOOT: date: 0x20081017 > TBOOT: size*4: 0x67c0 (26560) > TBOOT: code_control: 0x0 > TBOOT: entry point: 0x00000008:00004120 > 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: 3 > TBOOT: length: 0x28 (40) > TBOOT: chipset_id_list: 0x4e8 > TBOOT: os_sinit_data_ver: 0x4 > TBOOT: min_mle_hdr_ver: 0x00020000 > TBOOT: capabilities: 0x00000002 > TBOOT: rlp_wake_getsec: 0 > TBOOT: rlp_wake_monitor: 1 > TBOOT: acm_ver: 19 > TBOOT: chipset list: > TBOOT: count: 1 > TBOOT: entry 0: > TBOOT: flags: 0x1 > TBOOT: vendor_id: 0x8086 > TBOOT: device_id: 0x9000 > TBOOT: revision_id: 0x3f > TBOOT: extended_id: 0x0 > TBOOT: file addresses: > TBOOT: &_start=00803000 > TBOOT: &_end=0084fc4c > TBOOT: &_mle_start=00803000 > TBOOT: &_mle_end=00822000 > TBOOT: &_post_launch_entry=00803020 > TBOOT: &_txt_wakeup=008031f0 > TBOOT: &g_mle_hdr=00819120 > TBOOT: MLE header: > TBOOT: uuid={0x9082ac5a, 0x476f, 0x74a7, 0x5c0f, > {0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}} > TBOOT: length=34 > TBOOT: version=00020001 > TBOOT: entry_point=00000020 > TBOOT: first_valid_page=00000000 > TBOOT: mle_start_off=0 > TBOOT: mle_end_off=1f000 > TBOOT: capabilities: 0x00000003 > TBOOT: rlp_wake_getsec: 1 > TBOOT: rlp_wake_monitor: 1 > TBOOT: MLE start=803000, end=822000, size=1f000 > TBOOT: ptab_size=3000, ptab_base=00800000 > TBOOT: bios_data (@bc920008, 2c): > TBOOT: version: 3 > TBOOT: bios_sinit_size: 0x0 (0) > TBOOT: lcp_pd_base: 0x0 > TBOOT: lcp_pd_size: 0x0 (0) > TBOOT: num_logical_procs: 2 > TBOOT: flags: 0x00000001 > TBOOT: min_lo_ram: 0x0, max_lo_ram: 0xbc700000 > TBOOT: min_hi_ram: 0x0, max_hi_ram: 0x0 > TBOOT: no LCP manifest found > TBOOT: os_sinit_data (@bc920154, 5c): > TBOOT: version: 4 > TBOOT: mle_ptab: 0x800000 > TBOOT: mle_size: 0x1f000 (126976) > TBOOT: mle_hdr_base: 0x16120 > TBOOT: vtd_pmr_lo_base: 0x0 > TBOOT: vtd_pmr_lo_size: 0xbc600000 > TBOOT: vtd_pmr_hi_base: 0x0 > TBOOT: vtd_pmr_hi_size: 0x0 > TBOOT: lcp_po_base: 0x0 > TBOOT: lcp_po_size: 0x0 (0) > TBOOT: capabilities: 0x00000002 > TBOOT: rlp_wake_getsec: 0 > TBOOT: rlp_wake_monitor: 1 > TBOOT: setting MTRRs for acmod: base=bc900000, size=67c0, num_pages=7 > TBOOT: executing GETSEC[SENTER]... > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Alana L. <al...@cs...> - 2009-04-09 19:29:48
|
Hi, I've been trying to get tboot working on my Lenovo T400, but it always gets stuck at the executing GETSEC[SENTER] stage and then I have to power it down. I can still use the num lock key (the light goes on/off), but not caps lock when this happens, so I don't know if something is still happening or not at this point... I have TXT, VT-d and VT-x enabled in the BIOS, and the TPM is active. It is the latest BIOS (version 2.12) from Lenovo. I am using the tboot source from March 30th and the 2.6.29-tip kernel patched with the tboot patches from the lkml.org post. However, I've had the exact same behavior with the 2.6.27-11-generic (unpatched) Ubuntu kernel and also with the previous version of tboot (from January). Any advice is appreciated, I'm posting my complete tboot log below. Thanks, Alana TBOOT: ******************* TBOOT ******************* TBOOT: unavailable TBOOT: ********************************************* TBOOT: command line: logging=serial,vga,memory TBOOT: TPM is ready TBOOT: TPM nv_locked: TRUE TBOOT: TPM: get capability, return value = 00000002 TBOOT: failed to get actual policy size in TPM NV 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: 2 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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: no policy in TPM NV. TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff0f TBOOT: CPU is SMX-capable TBOOT: CPU is VMX-capable TBOOT: SMX is enabled TBOOT: TXT chipset and all needed capabilities present TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: LT.ERRORCODE=0 TBOOT: LT.ESTS=0 TBOOT: bios_data (@bc920008, 2c): TBOOT: version: 3 TBOOT: bios_sinit_size: 0x0 (0) TBOOT: lcp_pd_base: 0x0 TBOOT: lcp_pd_size: 0x0 (0) TBOOT: num_logical_procs: 2 TBOOT: flags: 0x00000001 TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2.TBOOT: CR0 and EFLAGS OK TBOOT: no machine check errors TBOOT: CPU is ready for SENTER TBOOT: checking previous errors on the last boot. TPM: read nv index 20000002 offset 00000000, return value = 00000002 TBOOT: Error: read TPM error: 0x2. TBOOT: last boot has no error. TBOOT: user-provided SINIT found: /boot/GM45_PM45_SINIT_19.BIN TBOOT: chipset ids: vendor=8086, device=9000, revision=7f TBOOT: 1 ACM chipset id entries: TBOOT: vendor=8086, device=9000, flags=1, revision=3f, extended=0 TBOOT: copied SINIT (size=67c0) to bc900000 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: length: 0xa1 (161) TBOOT: version: 0 TBOOT: chipset_id: 0x2a40 TBOOT: flags: 0x0 TBOOT: pre_production: 0 TBOOT: debug_signed: 0 TBOOT: vendor: 0x8086 TBOOT: date: 0x20081017 TBOOT: size*4: 0x67c0 (26560) TBOOT: code_control: 0x0 TBOOT: entry point: 0x00000008:00004120 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: 3 TBOOT: length: 0x28 (40) TBOOT: chipset_id_list: 0x4e8 TBOOT: os_sinit_data_ver: 0x4 TBOOT: min_mle_hdr_ver: 0x00020000 TBOOT: capabilities: 0x00000002 TBOOT: rlp_wake_getsec: 0 TBOOT: rlp_wake_monitor: 1 TBOOT: acm_ver: 19 TBOOT: chipset list: TBOOT: count: 1 TBOOT: entry 0: TBOOT: flags: 0x1 TBOOT: vendor_id: 0x8086 TBOOT: device_id: 0x9000 TBOOT: revision_id: 0x3f TBOOT: extended_id: 0x0 TBOOT: file addresses: TBOOT: &_start=00803000 TBOOT: &_end=0084fc4c TBOOT: &_mle_start=00803000 TBOOT: &_mle_end=00822000 TBOOT: &_post_launch_entry=00803020 TBOOT: &_txt_wakeup=008031f0 TBOOT: &g_mle_hdr=00819120 TBOOT: MLE header: TBOOT: uuid={0x9082ac5a, 0x476f, 0x74a7, 0x5c0f, {0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}} TBOOT: length=34 TBOOT: version=00020001 TBOOT: entry_point=00000020 TBOOT: first_valid_page=00000000 TBOOT: mle_start_off=0 TBOOT: mle_end_off=1f000 TBOOT: capabilities: 0x00000003 TBOOT: rlp_wake_getsec: 1 TBOOT: rlp_wake_monitor: 1 TBOOT: MLE start=803000, end=822000, size=1f000 TBOOT: ptab_size=3000, ptab_base=00800000 TBOOT: bios_data (@bc920008, 2c): TBOOT: version: 3 TBOOT: bios_sinit_size: 0x0 (0) TBOOT: lcp_pd_base: 0x0 TBOOT: lcp_pd_size: 0x0 (0) TBOOT: num_logical_procs: 2 TBOOT: flags: 0x00000001 TBOOT: min_lo_ram: 0x0, max_lo_ram: 0xbc700000 TBOOT: min_hi_ram: 0x0, max_hi_ram: 0x0 TBOOT: no LCP manifest found TBOOT: os_sinit_data (@bc920154, 5c): TBOOT: version: 4 TBOOT: mle_ptab: 0x800000 TBOOT: mle_size: 0x1f000 (126976) TBOOT: mle_hdr_base: 0x16120 TBOOT: vtd_pmr_lo_base: 0x0 TBOOT: vtd_pmr_lo_size: 0xbc600000 TBOOT: vtd_pmr_hi_base: 0x0 TBOOT: vtd_pmr_hi_size: 0x0 TBOOT: lcp_po_base: 0x0 TBOOT: lcp_po_size: 0x0 (0) TBOOT: capabilities: 0x00000002 TBOOT: rlp_wake_getsec: 0 TBOOT: rlp_wake_monitor: 1 TBOOT: setting MTRRs for acmod: base=bc900000, size=67c0, num_pages=7 TBOOT: executing GETSEC[SENTER]... |
|
From: Cihula, J. <jos...@in...> - 2009-04-06 16:22:15
|
> From: Atanas Filyanov [mailto:ata...@go...] > Sent: Monday, April 06, 2009 8:21 AM > > Cihula, Joseph wrote: > >> From: Atanas Filyanov [mailto:ata...@go...] > >> Sent: Wednesday, March 25, 2009 1:52 PM > >> > >> Hi all, > >> > >> I'm currently doing some experiments with dynamic root of trust. From > >> the tboot boot log I can see that the SENTER instruction is executed and > >> the PCRs 17 and above are set to 0 and that PCRs 17 and 18 are extended. > >> My question, if somebody could help me, is how to set PCR 17 or any > >> other PCR to 0 from the running system and if I understand correctly the > >> PCR value should change if I boot another XEN domain and should change > >> back to the original value if I shut it down? Or am I mistaken? > >> I'd appriciate any help. > >> > >> Best, > >> Atanas > >> > > > > The dynamic PCRs (16-23) are only resettable by the establishment of a hardware root of > trust (e.g. GETSEC[SENTER]). Xen uses TXT via the tboot module that performs SENTER at boot > time. The measurements for TXT are those of tboot, Xen, and dom0. So non-dom0 domains are > not measured as part of the current implementation. Because the SENTER is performed at boot > time, it will require a hard or soft reboot to re-execute tboot and the SENTER instruction. > > > > Non- tboot or Xen uses of TXT could invoke SENTER multiple times within a single boot (after > performing SEXIT) and the PCRs will be reset each time. > > > > Joe > > > > Hi Joe, > > Thank you very much for the reply. Could you also give some hints about > invoking the SEXIT and SENTER instructions in order to reset the dynamic > PCRs without reboot? Since SEXIT is going to end the dynamic environment, you need to first make sure that you've protected any data that you do not want compromised. You should also cap the PCRs, close private space, etc. (see tboot code). If what you're looking for is Linux code that launches a TXT environment for a while then shuts it down and then can do it again, you should look at the Flicker project (http://sparrow.ece.cmu.edu/group/flicker.html). It uses a kernel module to invoke and then tear down a small TXT environment. Joe |
|
From: Atanas F. <ata...@go...> - 2009-04-06 15:21:34
|
Cihula, Joseph wrote: >> From: Atanas Filyanov [mailto:ata...@go...] >> Sent: Wednesday, March 25, 2009 1:52 PM >> >> Hi all, >> >> I'm currently doing some experiments with dynamic root of trust. From >> the tboot boot log I can see that the SENTER instruction is executed and >> the PCRs 17 and above are set to 0 and that PCRs 17 and 18 are extended. >> My question, if somebody could help me, is how to set PCR 17 or any >> other PCR to 0 from the running system and if I understand correctly the >> PCR value should change if I boot another XEN domain and should change >> back to the original value if I shut it down? Or am I mistaken? >> I'd appriciate any help. >> >> Best, >> Atanas >> > > The dynamic PCRs (16-23) are only resettable by the establishment of a hardware root of trust (e.g. GETSEC[SENTER]). Xen uses TXT via the tboot module that performs SENTER at boot time. The measurements for TXT are those of tboot, Xen, and dom0. So non-dom0 domains are not measured as part of the current implementation. Because the SENTER is performed at boot time, it will require a hard or soft reboot to re-execute tboot and the SENTER instruction. > > Non- tboot or Xen uses of TXT could invoke SENTER multiple times within a single boot (after performing SEXIT) and the PCRs will be reset each time. > > Joe > Hi Joe, Thank you very much for the reply. Could you also give some hints about invoking the SEXIT and SENTER instructions in order to reset the dynamic PCRs without reboot? Thanks, Atanas |
|
From: Cihula, J. <jos...@in...> - 2009-03-25 21:48:47
|
> From: Atanas Filyanov [mailto:ata...@go...] > Sent: Wednesday, March 25, 2009 1:52 PM > > Hi all, > > I'm currently doing some experiments with dynamic root of trust. From > the tboot boot log I can see that the SENTER instruction is executed and > the PCRs 17 and above are set to 0 and that PCRs 17 and 18 are extended. > My question, if somebody could help me, is how to set PCR 17 or any > other PCR to 0 from the running system and if I understand correctly the > PCR value should change if I boot another XEN domain and should change > back to the original value if I shut it down? Or am I mistaken? > I'd appriciate any help. > > Best, > Atanas The dynamic PCRs (16-23) are only resettable by the establishment of a hardware root of trust (e.g. GETSEC[SENTER]). Xen uses TXT via the tboot module that performs SENTER at boot time. The measurements for TXT are those of tboot, Xen, and dom0. So non-dom0 domains are not measured as part of the current implementation. Because the SENTER is performed at boot time, it will require a hard or soft reboot to re-execute tboot and the SENTER instruction. Non- tboot or Xen uses of TXT could invoke SENTER multiple times within a single boot (after performing SEXIT) and the PCRs will be reset each time. Joe |
|
From: Atanas F. <ata...@go...> - 2009-03-25 20:51:46
|
Hi all, I'm currently doing some experiments with dynamic root of trust. From the tboot boot log I can see that the SENTER instruction is executed and the PCRs 17 and above are set to 0 and that PCRs 17 and 18 are extended. My question, if somebody could help me, is how to set PCR 17 or any other PCR to 0 from the running system and if I understand correctly the PCR value should change if I boot another XEN domain and should change back to the original value if I shut it down? Or am I mistaken? I'd appriciate any help. Best, Atanas |
|
From: Hal F. <hal...@gm...> - 2009-02-21 00:09:41
|
On Fri, Feb 20, 2009 at 1:48 AM, Courtay Olivier <Oli...@th...> wrote: > Their are available here: > http://theinvisiblethings.blogspot.com/2009/02/attacking-intel-txt-paper-and-slides.html Thanks, that was interesting. They focus on breaking the SMM mode, apparently via BIOS bugs. Just reading BIOS SMM code is actually quite difficult, and they exploited a different BIOS bug to be able to do that. Then they found bugs in the BIOS SMI handling code which could allow further exploits. The PC architecture is such a hack. One wonders sometimes if the idea of making a PC into a "trusted computer" is just a pipe dream. TXT is supposed to be protected against SMM via a SMM Transfer Monitor, STM. None of these exist yet apparently. The authors point out that there will be no guarantee that they work right, when they do come out. I'd suggest that you could say the same thing about the SINIT module which is at least as important. I wish Intel would publish the source code of these modules for review. In any case I believe the STM code is part of what gets hashed into the PCRs on TXT launch, right? So in the future you will be able to tell if a system has implemented an STM, which should add confidence that the TXT mode is secure. Hal Finney |
|
From: Courtay O. <Oli...@th...> - 2009-02-20 09:48:28
|
Their are available here: http://theinvisiblethings.blogspot.com/2009/02/attacking-intel-txt-paper-and-slides.html Olivier |
|
From: Cihula, J. <jos...@in...> - 2009-02-02 17:42:37
|
>From an interview with Joanna (http://www.infoworld.com/article/09/01/06/Researchers_hack_into_Intels_vPro_1.html): The researchers conducted their attack against a program called tboot, used to load trusted versions of Linux or virtual machine modules onto the computer. They chose tboot because it is one of the few programs available that takes advantage of the TXT technology, but they did not find bugs in tboot itself, Rutkowska said. As for specifics of how the attack relates to TXT, you will need to see the presentation. Joe From: Karthik . [mailto:tr...@gm...] Sent: Monday, February 02, 2009 9:08 AM To: tbo...@li... Subject: Re: [tboot-devel] Attack on tboot/TXT to be revealed Hi Joe I am confused as to whether this attack is on the Tboot code or is it on the TXT architecture. Can you please clarify? > From: Hal Finney [mailto:hal.finney@gm.<mailto:hal.finney@gm.>..] > Sent: Wednesday, January 07, 2009 2:49 PM > > >> From: Hal Finney [mailto:hal.finney@gm.<mailto:hal.finney@gm.>..] > >> Sent: Tuesday, January 06, 2009 7:26 PM > >> > >> There is one aspect of tboot security which I always wondered about. > >> Maybe someone could reassure me that it is OK. > >> > >> Shouldn't the MLE check to see that the page tables are/were set up > >> correctly? > > On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <joseph.cihula@in...> wrote: > > > > This has been on my todo list for a while now but I haven't gotten to it yet (it *is* > covered in the MLE Developers Manual, however). Now that I just finished a few patches (and > one more to come that requires Xen support), I should be able to knock this out pretty soon. > > I would like to see a document which lists known security flaws like > this in tboot. It might help to reduce claims that "Intel TXT is > broken" and the like. Do you know of other security loopholes which > are planned for closure in future versions? >>> I'll work on creating a TODO list for tboot, which will include the implications/impact of the items and also will include functional tasks. >>> These are the TODO items that I know of that have security implications: >>> 1. Verification of post-launch physical memory layout (see above). A patch is ready and being reviewed. >>> 2. VT-d protections extended to all of usable memory. The current tboot setting for VT-d (PMR) DMA protection is just the tboot address range, which leaves out Xen, dom0, >>> etc. as well as where they are relocated to before Xen enables VT-d DMA remapping. A patch is ready and being reviewed. >>> 3. S3 memory integrity protection. The non-tboot TCB (and possibly more) needs to have its integrity measured before entering S3 and verified on resume. For Xen, this would >>> be the hypervisor and that would be responsible for doing this for domains (including dom0). A patch is ready and being reviewed. >>> 4. Validation of Sx addresses. We are adding GAS (generic address structure) support to tboot's Sx code. GAS allows for non-port -based Sx triggering (i.e. memory writes). >>> This allows for the possibility that malicious ACPI code (or tampered with before tboot) could reference addresses within Xen or tboot and cause overwrites when a sleep state >>> is entered. So the addresses should be checked against tboot/Xen/domain addr ranges before being used. This is part of the GAS support patch, which is ready and being >>> reviewed. >>> 5. Run tboot code through a static analysis checker. >>> 6. Perform a thorough tboot code and design review on latest code. >>> There are also some things that are not directly related to tboot, but are really only relevant if tboot is being used: >>> 1. Review all Xen code for pre-launch dependencies. This would be things like the GAS issue mentioned above, BIOS calls (which should all be disabled when invoked by >>> tboot), etc. >>> 2. Ensure Xen fails secure. This would include things like the 'iommu=required' and 'ats' command line parameters that we had added. >>> Joe |
|
From: Karthik . <tr...@gm...> - 2009-02-02 17:08:29
|
Hi Joe I am confused as to whether this attack is on the Tboot code or is it on the TXT architecture. Can you please clarify? > From: Hal Finney [mailto:hal.finney@gm...] > Sent: Wednesday, January 07, 2009 2:49 PM > > >> From: Hal Finney [mailto:hal.finney@gm...] > >> Sent: Tuesday, January 06, 2009 7:26 PM > >> > >> There is one aspect of tboot security which I always wondered about. > >> Maybe someone could reassure me that it is OK. > >> > >> Shouldn't the MLE check to see that the page tables are/were set up > >> correctly? > > On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <joseph.cihula@in...> wrote: > > > > This has been on my todo list for a while now but I haven't gotten to it yet (it *is* > covered in the MLE Developers Manual, however). Now that I just finished a few patches (and > one more to come that requires Xen support), I should be able to knock this out pretty soon. > > I would like to see a document which lists known security flaws like > this in tboot. It might help to reduce claims that "Intel TXT is > broken" and the like. Do you know of other security loopholes which > are planned for closure in future versions? >>> I'll work on creating a TODO list for tboot, which will include the implications/impact of the items and also will include functional tasks. >>> These are the TODO items that I know of that have security implications: >>> 1. Verification of post-launch physical memory layout (see above). A patch is ready and being reviewed. >>> 2. VT-d protections extended to all of usable memory. The current tboot setting for VT-d (PMR) DMA protection is just the tboot address range, which leaves out Xen, dom0, >>> etc. as well as where they are relocated to before Xen enables VT-d DMA remapping. A patch is ready and being reviewed. >>> 3. S3 memory integrity protection. The non-tboot TCB (and possibly more) needs to have its integrity measured before entering S3 and verified on resume. For Xen, this would >>> be the hypervisor and that would be responsible for doing this for domains (including dom0). A patch is ready and being reviewed. >>> 4. Validation of Sx addresses. We are adding GAS (generic address structure) support to tboot's Sx code. GAS allows for non-port -based Sx triggering (i.e. memory writes). >>> This allows for the possibility that malicious ACPI code (or tampered with before tboot) could reference addresses within Xen or tboot and cause overwrites when a sleep state >>> is entered. So the addresses should be checked against tboot/Xen/domain addr ranges before being used. This is part of the GAS support patch, which is ready and being >>> reviewed. >>> 5. Run tboot code through a static analysis checker. >>> 6. Perform a thorough tboot code and design review on latest code. >>> There are also some things that are not directly related to tboot, but are really only relevant if tboot is being used: >>> 1. Review all Xen code for pre-launch dependencies. This would be things like the GAS issue mentioned above, BIOS calls (which should all be disabled when invoked by >>> tboot), etc. >>> 2. Ensure Xen fails secure. This would include things like the 'iommu=required' and 'ats' command line parameters that we had added. >>> Joe |
|
From: Cihula, J. <jos...@in...> - 2009-01-28 18:12:14
|
> From: Lil Evil [mailto:Lil...@gm...] > Sent: Wednesday, January 28, 2009 3:41 AM > > Hi there, > > I ve been fiddling around with TXT lately and been receiving SINIT errorcodes, which are not > listed in the sinit_error.txt > For instance 0x80000005 and 0x80000006 which are marked for future use. > Any chance to get a description for those errorcodes or an updated errorcode list? These error codes are processor-generated. Tables 14 and 15 (in Appendix B) describe the overall format of the ERRORCODE register, where if bit 30 is clear then it is a processor-generated error. Error 0x80000005 is #BadACMMType, which indicates that the MTRRs are not programmed correctly. If you are seeing this with the latest tboot code, then it may be an issue with BIOS--we have seen at least one BIOS whose SMI handler mis-set one of the MTRRs that was being used by SMM. If this seems to be the condition, you can see if your BIOS provides a configuration option to disable the BIOS's/SMM's use of the MTRR; otherwise contact your system vendor. Error 0x80000006 is #UnsupportedACM, which indicates some type of corruption of the SINIT ACM in memory. I have not seen this before on any of my systems, so you should check that no code has accidentally trampled over it. Joe |
|
From: Lil E. <Lil...@gm...> - 2009-01-28 12:41:41
|
Hi there, I ve been fiddling around with TXT lately and been receiving SINIT errorcodes, which are not listed in the sinit_error.txt For instance 0x80000005 and 0x80000006 which are marked for future use. Any chance to get a description for those errorcodes or an updated errorcode list? Cheers lIl -- NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a |
|
From: Ross P. <Ros...@ci...> - 2009-01-21 16:15:22
|
Some answers:
1. I don't know how new your tboot is but in earlier versions by default it sent output to the serial port so you need a remote console (defaults to COM1 115200 8n1). In newer versions there are a number of choices for startup logging that are outlined in the file docs/tboot-info.txt including configurable serial logging and vga logging.
2. My guess is that you had to modify the patch to get it to apply but your steps are correct. The "make install" should put tboot.gz in the right place and yes then you add it to grub.conf.
Thanks
Ross
-----Original Message-----
From: Wu Zhou [mailto:woo...@gm...]
Sent: Wednesday, January 21, 2009 10:03 AM
To: tbo...@li...
Subject: Re: [tboot-devel] Problems on tpmnv_defindex
Hello all,
I had a DELL OPTIPLEX 755, and encountered a same question as
described in this thread. I am very happy to see that this thread
provide a workaround.
But because I am very new to tboot. I am not sure if I get it right
and make it correct. Here are some of my questions:
1. how to verify tboot is correctly running? My /etc/grub.conf looks like this:
title Xen-3.3.1 with tBoot
root (hd0,1)
kernel /boot/tboot.gz
module /boot/xen-3.3.1.gz
module /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2
module /boot/initrd-2.6.18.8-xen.img
module /boot/Q35_SINIT_17.BIN
The first few seconds pass by very quickly. I didn't notice any TBOOT
message as below. But the startup is okay.
2. About the workaround process:
> - define the owner index
> - create vl.pol
> - compile with make embed=path_to_vl.pol
> - install tboot
> - create lcp
> - write lcp in owner index
after the above process, I should reboot the system, and try to find
TBOOT message on the console, right?
and "install tboot" simply means cp tboot.gz to /boot directory, and
add the following into grub.conf?
title Xen-3.3.1 with tBoot
root (hd0,1)
kernel /boot/tboot.gz
module /boot/xen-3.3.1.gz
module /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2
module /boot/initrd-2.6.18.8-xen.img
module /boot/Q35_SINIT_17.BIN
Thanks,
Wu
> Hello,
>
> I have applied your patch on the tboot.hg
> The patch work well (I had to manually apply patch for only one line).
>
> And it seems to work:
> ....
> TBOOT: verifying module "/boot/vmlinuz-2.6.28-rc5 root=/dev/sda2 ro console=ttyS0,115200 3"...
> TBOOT: \0x09 OK
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: TPM error code index not present in embedded policy mode.
> TBOOT: verifying module "/boot/initrd.img-2.6.28-rc5"...
> TBOOT: \0x09 OK
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: TPM error code index not present in embedded policy mode.
> TBOOT: all modules are verified
> ......
>
> I will study the error due to attempt to write in undefined index
>
> The step for use your patch:
>
> - define the owner index
> - create vl.pol
> - compile with make embed=path_to_vl.pol
> - install tboot
> - create lcp
> - write lcp in owner index
>
>
> The drawback is that the tboot.gz can be used for only one entry and if policy change , you should compile tboot....
>
> Thank a lot for your patch
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
tboot-devel mailing list
tbo...@li...
https://lists.sourceforge.net/lists/listinfo/tboot-devel
|
|
From: Wu Z. <woo...@gm...> - 2009-01-21 15:02:57
|
Hello all,
I had a DELL OPTIPLEX 755, and encountered a same question as
described in this thread. I am very happy to see that this thread
provide a workaround.
But because I am very new to tboot. I am not sure if I get it right
and make it correct. Here are some of my questions:
1. how to verify tboot is correctly running? My /etc/grub.conf looks like this:
title Xen-3.3.1 with tBoot
root (hd0,1)
kernel /boot/tboot.gz
module /boot/xen-3.3.1.gz
module /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2
module /boot/initrd-2.6.18.8-xen.img
module /boot/Q35_SINIT_17.BIN
The first few seconds pass by very quickly. I didn't notice any TBOOT
message as below. But the startup is okay.
2. About the workaround process:
> - define the owner index
> - create vl.pol
> - compile with make embed=path_to_vl.pol
> - install tboot
> - create lcp
> - write lcp in owner index
after the above process, I should reboot the system, and try to find
TBOOT message on the console, right?
and "install tboot" simply means cp tboot.gz to /boot directory, and
add the following into grub.conf?
title Xen-3.3.1 with tBoot
root (hd0,1)
kernel /boot/tboot.gz
module /boot/xen-3.3.1.gz
module /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2
module /boot/initrd-2.6.18.8-xen.img
module /boot/Q35_SINIT_17.BIN
Thanks,
Wu
> Hello,
>
> I have applied your patch on the tboot.hg
> The patch work well (I had to manually apply patch for only one line).
>
> And it seems to work:
> ....
> TBOOT: verifying module "/boot/vmlinuz-2.6.28-rc5 root=/dev/sda2 ro console=ttyS0,115200 3"...
> TBOOT: \0x09 OK
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: TPM error code index not present in embedded policy mode.
> TBOOT: verifying module "/boot/initrd.img-2.6.28-rc5"...
> TBOOT: \0x09 OK
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: TPM error code index not present in embedded policy mode.
> TBOOT: all modules are verified
> ......
>
> I will study the error due to attempt to write in undefined index
>
> The step for use your patch:
>
> - define the owner index
> - create vl.pol
> - compile with make embed=path_to_vl.pol
> - install tboot
> - create lcp
> - write lcp in owner index
>
>
> The drawback is that the tboot.gz can be used for only one entry and if policy change , you should compile tboot....
>
> Thank a lot for your patch
|
|
From: Cihula, J. <jos...@in...> - 2009-01-12 23:11:37
|
This is a Q35 Express system and the SINIT for this chipset does not enforce the TPM NV lock (and the boot never gets that far). It is a BIOS issue with the version of the BiosData structure being used. You could try putting a workaround in the tboot code that not only sets the version field to 2 but also puts in the appropriate value of the num_logical_procs field for your CPU.
I will forward this to our person who works with Lenovo, but it would be best if you (Jonathan) could contact them as well (or whatever source you purchased the system through).
Joe
From: Karthik . [mailto:tr...@gm...]
Sent: Monday, January 12, 2009 1:19 PM
To: tbo...@li...
Subject: Re: [tboot-devel] Buying a machine that will actually work
Looks like the TPM is not locked and that could be the reason for failure in your case.
From: "Jonathan M. McCune" <jon...@cm...<mailto:jon...@cm...>>
Subject: Re: [tboot-devel] Buying a machine that will actually work
with TXT
To: tbo...@li...<mailto:tbo...@li...>
Message-ID: <496...@cm...<mailto:496...@cm...>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hal Finney wrote:
> When Trusted Execution was announced, 3 models of computers were
> identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755
> PC, and the Lenovo ThinkCentre M57p. I don't know of any others that
> have been added to that list since then.
>
I tried the latest tboot on a Lenovo M57p and it fails to boot. The
relevant errors seem to be that the BIOS data version is 1 and tboot
requires 2 or greater (error log below). I have updated the machine to
the latest BIOS revision "2rj957a" with no luck. Any ideas?
Thanks,
-Jon
TBOOT: ******************* TBOOT *******************
TBOOT: 2009-01-05 16:33 -0500 111:e009b057d5b0
TBOOT: ******************************
***************
TBOOT: command line: logging=vga,serial,memory
TBOOT: TPM is ready
TBOOT: TPM nv_locked: FALSE
TBOOT: TPM: get capability, return value = 00000002
TBOOT: failed to get actual policy size in TPM NV
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: 2
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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000002
TBOOT: Error: write TPM error: 0x2.
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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: LT.ERRORCODE=0
TBOOT: LT.ESTS=0
TBOOT: unsupported BIOS data version (1)
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: TPM: access reg release locality timeout
TBOOT: shutdown_system() called for shutdown_type: TB_SHUTDOWN_HALT
|
|
From: Karthik . <tr...@gm...> - 2009-01-12 21:18:45
|
Looks like the TPM is not locked and that could be the reason for failure in
your case.
From: "Jonathan M. McCune" <jon...@cm...>
Subject: Re: [tboot-devel] Buying a machine that will actually work
with TXT
To: tbo...@li...
Message-ID: <496...@cm...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hal Finney wrote:
> When Trusted Execution was announced, 3 models of computers were
> identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755
> PC, and the Lenovo ThinkCentre M57p. I don't know of any others that
> have been added to that list since then.
>
I tried the latest tboot on a Lenovo M57p and it fails to boot. The
relevant errors seem to be that the BIOS data version is 1 and tboot
requires 2 or greater (error log below). I have updated the machine to
the latest BIOS revision "2rj957a" with no luck. Any ideas?
Thanks,
-Jon
TBOOT: ******************* TBOOT *******************
TBOOT: 2009-01-05 16:33 -0500 111:e009b057d5b0
TBOOT: *********************************************
TBOOT: command line: logging=vga,serial,memory
TBOOT: TPM is ready
TBOOT: TPM nv_locked: FALSE
TBOOT: TPM: get capability, return value = 00000002
TBOOT: failed to get actual policy size in TPM NV
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: 2
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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000002
TBOOT: Error: write TPM error: 0x2.
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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: LT.ERRORCODE=0
TBOOT: LT.ESTS=0
TBOOT: unsupported BIOS data version (1)
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: TPM: access reg release locality timeout
TBOOT: shutdown_system() called for shutdown_type: TB_SHUTDOWN_HALT
|
|
From: Jonathan M. M. <jon...@cm...> - 2009-01-12 21:03:53
|
Hal Finney wrote: > When Trusted Execution was announced, 3 models of computers were > identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 > PC, and the Lenovo ThinkCentre M57p. I don't know of any others that > have been added to that list since then. > I tried the latest tboot on a Lenovo M57p and it fails to boot. The relevant errors seem to be that the BIOS data version is 1 and tboot requires 2 or greater (error log below). I have updated the machine to the latest BIOS revision "2rj957a" with no luck. Any ideas? Thanks, -Jon TBOOT: ******************* TBOOT ******************* TBOOT: 2009-01-05 16:33 -0500 111:e009b057d5b0 TBOOT: ********************************************* TBOOT: command line: logging=vga,serial,memory TBOOT: TPM is ready TBOOT: TPM nv_locked: FALSE TBOOT: TPM: get capability, return value = 00000002 TBOOT: failed to get actual policy size in TPM NV 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: 2 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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. 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: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: LT.ERRORCODE=0 TBOOT: LT.ESTS=0 TBOOT: unsupported BIOS data version (1) TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: TPM: access reg release locality timeout TBOOT: shutdown_system() called for shutdown_type: TB_SHUTDOWN_HALT |
|
From: Cihula, J. <jos...@in...> - 2009-01-12 17:19:30
|
> From: Hal Finney [mailto:hal...@gm...] > Sent: Wednesday, January 07, 2009 2:49 PM > > >> From: Hal Finney [mailto:hal...@gm...] > >> Sent: Tuesday, January 06, 2009 7:26 PM > >> > >> There is one aspect of tboot security which I always wondered about. > >> Maybe someone could reassure me that it is OK. > >> > >> Shouldn't the MLE check to see that the page tables are/were set up > >> correctly? > > On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <jos...@in...> wrote: > > > > This has been on my todo list for a while now but I haven't gotten to it yet (it *is* > covered in the MLE Developers Manual, however). Now that I just finished a few patches (and > one more to come that requires Xen support), I should be able to knock this out pretty soon. > > I would like to see a document which lists known security flaws like > this in tboot. It might help to reduce claims that "Intel TXT is > broken" and the like. Do you know of other security loopholes which > are planned for closure in future versions? I'll work on creating a TODO list for tboot, which will include the implications/impact of the items and also will include functional tasks. These are the TODO items that I know of that have security implications: 1. Verification of post-launch physical memory layout (see above). A patch is ready and being reviewed. 2. VT-d protections extended to all of usable memory. The current tboot setting for VT-d (PMR) DMA protection is just the tboot address range, which leaves out Xen, dom0, etc. as well as where they are relocated to before Xen enables VT-d DMA remapping. A patch is ready and being reviewed. 3. S3 memory integrity protection. The non-tboot TCB (and possibly more) needs to have its integrity measured before entering S3 and verified on resume. For Xen, this would be the hypervisor and that would be responsible for doing this for domains (including dom0). A patch is ready and being reviewed. 4. Validation of Sx addresses. We are adding GAS (generic address structure) support to tboot's Sx code. GAS allows for non-port -based Sx triggering (i.e. memory writes). This allows for the possibility that malicious ACPI code (or tampered with before tboot) could reference addresses within Xen or tboot and cause overwrites when a sleep state is entered. So the addresses should be checked against tboot/Xen/domain addr ranges before being used. This is part of the GAS support patch, which is ready and being reviewed. 5. Run tboot code through a static analysis checker. 6. Perform a thorough tboot code and design review on latest code. There are also some things that are not directly related to tboot, but are really only relevant if tboot is being used: 1. Review all Xen code for pre-launch dependencies. This would be things like the GAS issue mentioned above, BIOS calls (which should all be disabled when invoked by tboot), etc. 2. Ensure Xen fails secure. This would include things like the 'iommu=required' and 'ats' command line parameters that we had added. Joe |
|
From: Hal F. <hal...@gm...> - 2009-01-07 22:49:16
|
>> From: Hal Finney [mailto:hal...@gm...] >> Sent: Tuesday, January 06, 2009 7:26 PM >> >> There is one aspect of tboot security which I always wondered about. >> Maybe someone could reassure me that it is OK. >> >> Shouldn't the MLE check to see that the page tables are/were set up >> correctly? On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <jos...@in...> wrote: > > This has been on my todo list for a while now but I haven't gotten to it yet (it *is* covered in the MLE Developers Manual, however). Now that I just finished a few patches (and one more to come that requires Xen support), I should be able to knock this out pretty soon. I would like to see a document which lists known security flaws like this in tboot. It might help to reduce claims that "Intel TXT is broken" and the like. Do you know of other security loopholes which are planned for closure in future versions? Hal |
|
From: Cihula, J. <jos...@in...> - 2009-01-07 07:25:49
|
> From: Hal Finney [mailto:hal...@gm...] > Sent: Tuesday, January 06, 2009 7:26 PM > > There is one aspect of tboot security which I always wondered about. > Maybe someone could reassure me that it is OK. > > Shouldn't the MLE check to see that the page tables are/were set up > correctly? It seems that TXT envisions that the MLE will turn on > paging, but I don't think tboot does so, it stays in physical memory > mode. However, TXT measures the MLE via the page tables. My concern is > whether a malicious tboot could move pages 2-n of the MLE up one page, > insert malicious code in the 2nd physical page, and set up the page > tables to skip the page with the malicious code. Then TXT, following > the page tables, would measure the same hash value as unmodified > tboot, but when the code executed and crossed over from the 1st page > into the 2nd page, it would start executing malicious code. > > To prevent this, the MLE should check, within page 1, that the page > table used for measurement matches what it was supposed to be. I'm not > certain, but I don't think there is such a check in tboot. Is this an > issue? This has been on my todo list for a while now but I haven't gotten to it yet (it *is* covered in the MLE Developers Manual, however). Now that I just finished a few patches (and one more to come that requires Xen support), I should be able to knock this out pretty soon. Joe |
|
From: Hal F. <hal...@gm...> - 2009-01-07 03:26:04
|
There is one aspect of tboot security which I always wondered about. Maybe someone could reassure me that it is OK. Shouldn't the MLE check to see that the page tables are/were set up correctly? It seems that TXT envisions that the MLE will turn on paging, but I don't think tboot does so, it stays in physical memory mode. However, TXT measures the MLE via the page tables. My concern is whether a malicious tboot could move pages 2-n of the MLE up one page, insert malicious code in the 2nd physical page, and set up the page tables to skip the page with the malicious code. Then TXT, following the page tables, would measure the same hash value as unmodified tboot, but when the code executed and crossed over from the 1st page into the 2nd page, it would start executing malicious code. To prevent this, the MLE should check, within page 1, that the page table used for measurement matches what it was supposed to be. I'm not certain, but I don't think there is such a check in tboot. Is this an issue? Hal Finney |
|
From: Jonathan M. M. <jon...@cm...> - 2009-01-06 13:13:59
|
I wonder if this is related to the TPM driver bug recently posted to the tpmdd-devel list: *** snip *** Please correct me if I am wrong, but this bug DOES mean we are basically doing: if (random memory contents) (random memory contents)(foo); at suspend and resume, isn't it? *** snip *** -Jon Hal Finney wrote: > Ran across this blog posting reporting an attack on the security of > tboot and/or TXT: > > http://theinvisiblethings.blogspot.com/2009/01/attacking-intel-trusted-execution.html > > see also: > > http://invisiblethingslab.com/press/itl-press-2009-01.pdf > > >From the documents: > > "Our attack comprises two stages. The first stage requires an > implementation flaw in a specific system software. The second stage of > the attack is possible thanks to a certain design decision made in the > current TXT release. > > "While evaluating the effectiveness of the Intel(R) TXT technology, as > part of a work done for a customer, we have identified several > implementation flaws in the Intel's system software, which allowed to > conduct the above mentioned stage-one attack. We have provided Intel > with extensive description of the flaws in December 2008, and Intel is > currently working on fixing those vulnerabilities. > > "We have also been in touch with Intel about the possibility of > conducting the second-stage attack since November 2008. In December, > after providing Intel with the details about the first-stage attack, > Intel promised to release, in the coming weeks, an updated TXT > specification for developers that would explain how to design their > TXT-based loaders in such a way that they are immune to our attack. > Intel claims the current Intel(R) TXT release does contain the basic > building blocks that could be used to prevent our second-stage attack > and the release of the additional specification would make it feasible > in practice." > > More details are to be announced at the Black Hat conference in > February, in Washington DC. > > It will be interesting to learn more about this attack scenario over > the next few weeks. Hopefully Intel will be able to release > information to help assure developers that the security potential of > TXT is fully realized. It has sometimes been unclear to me whether > tboot claims to provide full TXT security or is still considered a > work in progress, with known weaknesses which are intended to be > addressed in future versions. > > Hal Finney > > ------------------------------------------------------------------------------ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > |
|
From: Hal F. <hal...@gm...> - 2009-01-06 06:21:38
|
Ran across this blog posting reporting an attack on the security of tboot and/or TXT: http://theinvisiblethings.blogspot.com/2009/01/attacking-intel-trusted-execution.html see also: http://invisiblethingslab.com/press/itl-press-2009-01.pdf >From the documents: "Our attack comprises two stages. The first stage requires an implementation flaw in a specific system software. The second stage of the attack is possible thanks to a certain design decision made in the current TXT release. "While evaluating the effectiveness of the Intel(R) TXT technology, as part of a work done for a customer, we have identified several implementation flaws in the Intel's system software, which allowed to conduct the above mentioned stage-one attack. We have provided Intel with extensive description of the flaws in December 2008, and Intel is currently working on fixing those vulnerabilities. "We have also been in touch with Intel about the possibility of conducting the second-stage attack since November 2008. In December, after providing Intel with the details about the first-stage attack, Intel promised to release, in the coming weeks, an updated TXT specification for developers that would explain how to design their TXT-based loaders in such a way that they are immune to our attack. Intel claims the current Intel(R) TXT release does contain the basic building blocks that could be used to prevent our second-stage attack and the release of the additional specification would make it feasible in practice." More details are to be announced at the Black Hat conference in February, in Washington DC. It will be interesting to learn more about this attack scenario over the next few weeks. Hopefully Intel will be able to release information to help assure developers that the security potential of TXT is fully realized. It has sometimes been unclear to me whether tboot claims to provide full TXT security or is still considered a work in progress, with known weaknesses which are intended to be addressed in future versions. Hal Finney |
15 messages has been excluded from this view by a project administrator.
