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
(3) |
|
From: René K. <it...@co...> - 2010-04-21 12:44:20
|
Am 19.04.2010 um 02:49 schrieb Cihula, Joseph: >> From: René Korthaus [mailto:it...@co...] >> Sent: Sunday, April 18, 2010 9:56 AM >> >> Hi, >> >> is there any [preferably] paper, wiki or design document available that explains, at least >> roughly, what TBoot does? I know the Intel Dynamics of a Trusted Platform book, but this is >> not helpful for me. >> I need something that I can use for a review and to be scientifically citable. >> >> Thanks, René > > tboot is an implementation of an Intel(R) TXT MLE (Measured Launched Environment). The "Intel® Trusted Execution Technology Software Development Guide" at http://www.intel.com/technology/security/ describes how an MLE works and how to write one--tboot follows this documentation (with the caveat that the doc describes writing an MLE for a late launch whereas tboot is early launch and this a little less complicated with regards to handling APs and existing state). Thank you, I will have a look if it is sufficient for my purposes. René > > Joe --- B.Sc. René Korthaus eMail: it...@co... This mail automatically signed with S/MIME Get my public PGP key from keyserver, KeyId: 0x67B7E40A Fingerprint 67E9 64CD 1A61 5211 C9E1 5EBF 0904 84CA 67B7 E40A |
|
From: Martin P. <Mar...@ia...> - 2010-04-21 12:01:51
|
Hi list.... Now that the Core i5/i7 notebook generation is available, can anyone confirm certain notebook models to be known-working with TBoot? By spending a lot of money on a new notebook I'd rather buy a known-working one instead of a model which should work, but turns to a brick upon TXT init (see list archive for stories). Thanks for any recommendations! (or private mail if you don't want to do public endorsement) Martin |
|
From: Cihula, J. <jos...@in...> - 2010-04-19 22:03:08
|
The 0xC0000001 code from SINIT is actually the success code from SINIT (see Note 1 on Table 14 in the latest MLE Developers Guide). Joe From: Yusuf UZUNAY [mailto:yu...@gm...] Sent: Monday, April 19, 2010 1:56 PM To: tbo...@li... Subject: [tboot-devel] LT.ERRORCODE=c0000001 on DC7800 Hi All, I am receiving LT.ERRORCODE=c0000001 and AC module error : acm_type=1, progress=00, error=0 We guess that this means a "SINIT Exit Point" error. However we could not figure out what caused this error. The log file is attached. My SINIT is Q35_SINIT_18.BIN. My machine is HP DC7800 (with BIOS version 1.28 the latest I guess) and an intel Q35 Express chipset. Any help is really really appreciated. Thanks in advance. Yusuf Uzunay |
|
From: Yusuf U. <yu...@gm...> - 2010-04-19 20:55:53
|
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=c0000001
TBOOT: AC module error : acm_type=1, progress=00, error=0
TBOOT: LT.ESTS=0
TBOOT: bios_data (@7d520008, 24):
TBOOT: version: 2
TBOOT: bios_sinit_size: 0x0 (0)
TBOOT: lcp_pd_base: 0x0
TBOOT: lcp_pd_size: 0x0 (0)
TBOOT: num_logical_procs: 4
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: measured launch succeeded
TBOOT: bios_data (@7d520008, 24):
TBOOT: version: 2
TBOOT: bios_sinit_size: 0x0 (0)
TBOOT: lcp_pd_base: 0x0
TBOOT: lcp_pd_size: 0x0 (0)
TBOOT: num_logical_procs: 4
TBOOT: os_mle_data (@7d52002c, 120):
TBOOT: version: 1
TBOOT: mbi: 0x0002efdc
TBOOT: os_sinit_data (@7d52014c, 5c):
TBOOT: version: 4
TBOOT: mle_ptab: 0x800000
TBOOT: mle_size: 0x2e000 (188416)
TBOOT: mle_hdr_base: 0x214e0
TBOOT: vtd_pmr_lo_base: 0x0
TBOOT: vtd_pmr_lo_size: 0x7d200000
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: sinit_mle_data (@7d5201a8, 2d8):
TBOOT: version: 6
TBOOT: bios_acm_id:
80 00 00 00 20 07 09 10 ff ff ff ff ff ff ff ff ff ff ff ff
TBOOT: edx_senter_flags: 0x00000000
TBOOT: mseg_valid: 0x0
TBOOT: sinit_hash:
46 72 51 d0 4a cd a7 a0 31 5c 01 6b 7b 99 78 98 61 69 73 89
TBOOT: mle_hash:
f4 9b 2c 4f ce 09 e1 ca a0 b6 c8 c0 3e 45 2d e0 ae 44 a2 e2
TBOOT: stm_hash:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
TBOOT: lcp_policy_hash:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
TBOOT: lcp_policy_control: 0x00000000
TBOOT: rlp_wakeup_addr: 0x7d501a60
TBOOT: num_mdrs: 7
TBOOT: mdrs_off: 0x98
TBOOT: num_vtd_dmars: 408
TBOOT: vtd_dmars_off: 0x140
TBOOT: sinit_mdrs:
TBOOT: 0000000000000000 - 00000000000a0000 (GOOD)
TBOOT: 0000000000100000 - 0000000001000000 (GOOD)
TBOOT: 0000000001000000 - 000000007d500000 (GOOD)
TBOOT: 0000000000000000 - 0000000000000000 (GOOD)
TBOOT: 0000000000000000 - 0000000000000000 (GOOD)
TBOOT: 00000000feda0000 - 00000000fedc0000 (SMRAM NON-OVERLAY)
TBOOT: 00000000f4000000 - 00000000f8000000 (PCIE EXTENDED CONFIG)
TBOOT: RSDP (v000 COMPAQ) @ 0x000e5c10
TBOOT: Seek in RSDT...
TBOOT: entry[0] sig = FACP @ 0x7d2c1ee8
TBOOT: entry[1] sig = APIC @ 0x7d2c1f5c
TBOOT: acpi_table_ioapic @ 7d2c1fa8, .address = fec00000
TBOOT: RSDP (v000 COMPAQ) @ 0x000e5c10
TBOOT: Seek in RSDT...
TBOOT: entry[0] sig = FACP @ 0x7d2c1ee8
TBOOT: entry[1] sig = APIC @ 0x7d2c1f5c
TBOOT: entry[2] sig = ASF! @ 0x7d2c1fe0
TBOOT: entry[3] sig = MCFG @ 0x7d2c2043
TBOOT: acpi_table_mcfg @ 7d2c2043, .base_address = f4000000
TBOOT: mtrr_def_type: e = 1, fe = 1, type = 0
TBOOT: mtrrs:
TBOOT: base mask type v
TBOOT: 000000 f80000 06 1
TBOOT: 07d600 fffe00 00 1
TBOOT: 07d800 fff800 00 1
TBOOT: 07e000 ffe000 00 1
TBOOT: 000000 000000 00 0
TBOOT: 000000 000000 00 0
TBOOT: 000000 000000 00 0
TBOOT: 000000 000000 00 0
TBOOT: min_lo_ram: 0x0, max_lo_ram: 0x7d2afe00
TBOOT: min_hi_ram: 0x0, max_hi_ram: 0x0
TBOOT: mle_join.entry_point = 8031f0
TBOOT: mle_join.seg_sel = 8
TBOOT: mle_join.gdt_base = 804000
TBOOT: mle_join.gdt_limit = 3f
TBOOT: joining RLPs to MLE with MONITOR wakeup
TBOOT: rlp_wakeup_addr = 0x7d501a60
TBOOT: cpu 2 waking up from TXT sleep
TBOOT: cpu 1 waking up from TXT sleep
TBOOT: cpu 3 waking up from TXT sleep
TBOOT: enabling SMIs on cpu 1
TBOOT: enabling SMIs on cpu 2
TBOOT: VMXON done for cpu 1
TBOOT: VMXON done for cpu 2
TBOOT: launching mini-guest for cpu 1
TBOOT: launching mini-guest for cpu 2
TBOOT: enabling SMIs on cpu 3
TBOOT: waiting for all APs (3) to enter wait-for-sipi...
TBOOT: VMXON done for cpu 3
TBOOT: .launching mini-guest for cpu 3
TBOOT:
TBOOT:
TBOOT: all APs in wait-for-sipi
TBOOT: enabling SMIs on BSP
TBOOT: saved IA32_MISC_ENABLE = 0x62972489
TBOOT: set LT.CMD.SECRETS flag
TBOOT: opened TPM locality 1
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: RSDP (v000 COMPAQ) @ 0x000e5c10
TBOOT: Seek in RSDT...
TBOOT: entry[0] sig = FACP @ 0x7d2c1ee8
TBOOT: entry[1] sig = APIC @ 0x7d2c1f5c
TBOOT: entry[2] sig = ASF! @ 0x7d2c1fe0
TBOOT: entry[3] sig = MCFG @ 0x7d2c2043
TBOOT: entry[4] sig = TCPA @ 0x7d2c207f
TBOOT: entry[5] sig = SLIC @ 0x7d2c20b1
TBOOT: entry[6] sig = HPET @ 0x7d2c2227
TBOOT: entry[7] sig = DMAR @ 0x7d2c225f
TBOOT: DMAR table @ 0x7d2c225f saved.
TBOOT: original e820 map:
TBOOT: 0000000000000000 - 000000000009fc00 (1)
TBOOT: 000000000009fc00 - 00000000000a0000 (2)
TBOOT: 00000000000e8000 - 0000000000100000 (2)
TBOOT: 0000000000100000 - 000000007d2afe00 (1)
TBOOT: 000000007d2afe00 - 000000007d2b1e00 (4)
TBOOT: 000000007d2b1e00 - 000000007d2b1ea0 (4)
TBOOT: 000000007d2b1ea0 - 000000007e000000 (2)
TBOOT: 00000000f4000000 - 00000000f8000000 (2)
TBOOT: 00000000fec00000 - 00000000fed40000 (2)
TBOOT: 00000000fed45000 - 0000000100000000 (2)
TBOOT: verifying module 0 of mbi (860000 - 95e6a7) in e820 table
(range from 0000000000860000 to 000000000095e6a8 is in E820_RAM)
TBOOT: : succeeded.
TBOOT: verifying module 1 of mbi (95f000 - 10042fb) in e820 table
(range from 000000000095f000 to 00000000010042fc is in E820_RAM)
TBOOT: : succeeded.
TBOOT: verifying module 2 of mbi (1005000 - 1d565ff) in e820 table
(range from 0000000001005000 to 0000000001d56600 is in E820_RAM)
TBOOT: : succeeded.
TBOOT: protecting TXT heap (7d520000 - 7d5fffff) in e820 table
TBOOT: protecting SINIT (7d500000 - 7d51ffff) in e820 table
TBOOT: protecting TXT Private Space (fed20000 - fed2ffff) in e820 table
TBOOT: verifying e820 table against SINIT MDRs: verification succeeded.
TBOOT: reserving 0x7d200000 - 0x7d2afe00, which was truncated for VT-d
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: verifying tboot and its page table (800000 - 85ec4b) in e820 table
(range from 0000000000800000 to 000000000085ec4c is in E820_RAM)
TBOOT: : succeeded.
TBOOT: protecting tboot (800000 - 9fffff) in e820 table
TBOOT: reserving tboot memory log (60000 - 67fff) in e820 table
TBOOT: adjusted e820 map:
TBOOT: 0000000000000000 - 0000000000060000 (1)
TBOOT: 0000000000060000 - 0000000000068000 (2)
TBOOT: 0000000000068000 - 000000000009fc00 (1)
TBOOT: 000000000009fc00 - 00000000000a0000 (2)
TBOOT: 00000000000e8000 - 0000000000100000 (2)
TBOOT: 0000000000100000 - 0000000000800000 (1)
TBOOT: 0000000000800000 - 0000000000a00000 (5)
TBOOT: 0000000000a00000 - 000000007d200000 (1)
TBOOT: 000000007d200000 - 000000007d2afe00 (2)
TBOOT: 000000007d2afe00 - 000000007d2b1e00 (4)
TBOOT: 000000007d2b1e00 - 000000007d2b1ea0 (4)
TBOOT: 000000007d2b1ea0 - 000000007d500000 (2)
TBOOT: 000000007d500000 - 000000007d520000 (2)
TBOOT: 000000007d520000 - 000000007d600000 (2)
TBOOT: 000000007d600000 - 000000007e000000 (2)
TBOOT: 00000000f4000000 - 00000000f8000000 (2)
TBOOT: 00000000fec00000 - 00000000fed20000 (2)
TBOOT: 00000000fed20000 - 00000000fed30000 (2)
TBOOT: 00000000fed30000 - 00000000fed40000 (2)
TBOOT: 00000000fed45000 - 0000000100000000 (2)
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: verifying module "/boot/xen.gz iommu=required dom0_mem=524288 com1=115200,8n1"...
TBOOT: OK : 11 ab f0 ff 36 7c cd fc 6e d9 54 14 fc c2 17 bc 64 09 d5 09
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: verifying module "/boot/vmlinuz-2.6.31.12-0.2-xen "...
TBOOT: OK : 58 5f 2e 65 10 b9 c1 32 02 a3 40 f3 28 61 fa 78 15 ad 45 19
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: verifying module "/boot/initrd-2.6.31.12-0.2-xen"...
TBOOT: OK : a1 cf 41 81 70 62 ae 73 b4 b8 00 97 72 56 8c 28 3d b5 3f 07
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
TBOOT: Error: write TPM error: 0x2.
TBOOT: all modules are verified
TBOOT: pre_k_s3_state:
TBOOT: vtd_pmr_lo_base: 0x0
TBOOT: vtd_pmr_lo_size: 0x7d200000
TBOOT: vtd_pmr_hi_base: 0x0
TBOOT: vtd_pmr_hi_size: 0x0
TBOOT: pol_hash: ab 41 62 4e 7d 71 f0 68 d4 8e 1c 2f 43 e6 16 bf 40 67 1c 39
TBOOT: VL measurements:
TBOOT: PCR 17: 97 04 35 36 30 67 4b fe 21 b8 6b 64 a7 b0 f9 9c 29 7c f9 02
TBOOT: PCR 18: 11 ab f0 ff 36 7c cd fc 6e d9 54 14 fc c2 17 bc 64 09 d5 09
TBOOT: PCR 19: 58 5f 2e 65 10 b9 c1 32 02 a3 40 f3 28 61 fa 78 15 ad 45 19
TBOOT: PCR 19: a1 cf 41 81 70 62 ae 73 b4 b8 00 97 72 56 8c 28 3d b5 3f 07
TBOOT: PCRs before extending:
TBOOT: PCR 17: 85 0c 39 2b 88 40 89 c8 63 48 46 c4 2b d9 2b af de 46 59 70
TBOOT: PCR 18: 3d e1 7f d3 a4 2a 6d 67 22 1b 4c 7f 6e 72 31 b5 6a 1f 25 d2
TBOOT: PCRs after extending:
TBOOT: PCR 17: e2 f9 46 04 7d 35 b8 79 92 e5 81 b7 f0 ac 60 97 a1 51 6b 6b
TBOOT: PCR 18: 47 54 ea ad 68 f8 82 5b 9c 6d 31 99 7a 30 7b b7 29 aa d1 79
TBOOT: tboot_shared data:
TBOOT: version: 5
TBOOT: log_addr: 0x00060000
TBOOT: shutdown_entry: 0x008031b0
TBOOT: shutdown_type: 0
TBOOT: tboot_base: 0x00803000
TBOOT: tboot_size: 0x5bc4c
TBOOT: num_in_wfs: 3
TBOOT: kernel is ELF format
TBOOT: transfering control to kernel @0x00100000...M
|
|
From: Martin P. <Mar...@ia...> - 2010-04-19 11:17:03
|
Cihula, Joseph wrote: > The work around is to disable legacy USB support. Meanwhile, I will > be fixing tboot to not DMA protect these regions when it finds such a > case (the current code will not DMA protect reserved regions as long as > there is no RAM after them). This is a non-trivial fix, so it may > take a little while. Any news on this? Thanks, Martin |
|
From: Cihula, J. <jos...@in...> - 2010-04-19 00:49:52
|
> From: René Korthaus [mailto:it...@co...] > Sent: Sunday, April 18, 2010 9:56 AM > > Hi, > > is there any [preferably] paper, wiki or design document available that explains, at least > roughly, what TBoot does? I know the Intel Dynamics of a Trusted Platform book, but this is > not helpful for me. > I need something that I can use for a review and to be scientifically citable. > > Thanks, René tboot is an implementation of an Intel(R) TXT MLE (Measured Launched Environment). The "Intel® Trusted Execution Technology Software Development Guide" at http://www.intel.com/technology/security/ describes how an MLE works and how to write one--tboot follows this documentation (with the caveat that the doc describes writing an MLE for a late launch whereas tboot is early launch and this a little less complicated with regards to handling APs and existing state). Joe |
|
From: René K. <it...@co...> - 2010-04-18 17:13:48
|
Hi, is there any [preferably] paper, wiki or design document available that explains, at least roughly, what TBoot does? I know the Intel Dynamics of a Trusted Platform book, but this is not helpful for me. I need something that I can use for a review and to be scientifically citable. Thanks, René --- B.Sc. René Korthaus eMail: it...@co... This mail automatically signed with S/MIME Get my public PGP key from keyserver, KeyId: 0x67B7E40A Fingerprint 67E9 64CD 1A61 5211 C9E1 5EBF 0904 84CA 67B7 E40A |
|
From: Cihula, J. <jos...@in...> - 2010-03-27 02:02:19
|
I have posted a new version of the Q45/Q43 SINIT ACM (see its CHANGELOG for info). I have also fixed a typo in the SINIT-guide.txt file for the PCI host bridge ID for the Q45/Q43 chipset (thanks to Martin Pirker for pointing it out). Joe |
|
From: Cihula, J. <jos...@in...> - 2010-03-19 00:40:27
|
I have uploaded the SINIT ACM for the Intel(R) Core(TM) i5-600 Desktop Processor Series, i7-600 & i5-500 Mobile Processor Series (Arrandale & Clarkdale) (platform codename Calpella/Piketon). It is available as i5_i7_DUAL-SINIT.tar.gz. Joe |
|
From: Martin P. <Mar...@ia...> - 2010-02-18 10:30:49
|
Any news on the release date of the SINIT binary blobs for Series 5 chipsets? :-) Martin |
|
From: Ahmed M A. <am...@nc...> - 2010-02-10 23:23:19
|
Hi, Does anyone know how to get the AC module for Intel x58 host controllers? Thanks, Ahmed |
|
From: Cihula, J. <jos...@in...> - 2010-02-09 19:50:13
|
> From: Michael Gissing [mailto:m.g...@tu...] > Sent: Thursday, January 07, 2010 3:21 AM > > Hi all! > > I just found a new version of Intel's MLE Developer's Guide at > http://www.intel.com/technology/security/ > Version December 2009 > > An official release announcement on this list of such updates would be great. > > btw: there are some annoying unresolved references in the text... > > Michael Sorry for the delay in responding, but thank you for pointing this out. As you might imagine, there is a process for putting content on our Web sites and during this process, when the document was converted to a PDF, some of the references and formatting were lost. This has been corrected for the new version posted there. Also unfortunate, I do not get notified when the new version actually gets posted to the site so that I may note it here; but I'll try to check it more regularly when I'm expecting the posting to occur. Joe |
|
From: Ross P. <Ros...@ci...> - 2010-02-08 20:48:17
|
No, I haven’t gotten any feedback. I am not currently working on tboot but I will see where things stand.
Thanks
Ross
From: Cihula, Joseph [mailto:jos...@in...]
Sent: Monday, February 08, 2010 3:26 PM
To: Cihula, Joseph; Christian Limpach; Wang, Shane; Ross Philipson; tbo...@li...
Subject: Re: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
I pushed this patch since I was able to get confirmation of it working on a system we have here.
Ross, do you have any feedback on the previous policy patch with the warning message and 5sec delay?
Joe
From: Cihula, Joseph
Sent: Saturday, February 06, 2010 2:11 PM
To: Christian Limpach; Wang, Shane; Ross Philipson; tbo...@li...
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
As Christian points out, the best approach is to “round up” any timeouts that are less than the defaults. Here is such a patch-please verify it on your TPM with the incorrect timeouts.
Joe
diff -r 0d7b5f56f26a tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 26 13:44:35 2010 -0800
+++ b/tboot/common/tpm.c Sat Feb 06 12:20:25 2010 -0800
@@ -1951,6 +1951,14 @@ bool is_tpm_ready(uint32_t locality)
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
+ /*
+ * if any timeout values are less than default values, set to default
+ * value (due to bug with some TPMs)
+ */
+ if ( g_timeout.timeout_a < TIMEOUT_A ) g_timeout.timeout_a = TIMEOUT_A;
+ if ( g_timeout.timeout_b < TIMEOUT_B ) g_timeout.timeout_b = TIMEOUT_B;
+ if ( g_timeout.timeout_c < TIMEOUT_C ) g_timeout.timeout_c = TIMEOUT_C;
+ if ( g_timeout.timeout_d < TIMEOUT_D ) g_timeout.timeout_d = TIMEOUT_D;
}
return true;
From: Christian Limpach [mailto:Chr...@eu...]
Sent: Monday, February 01, 2010 12:27 PM
To: Wang, Shane; Ross Philipson; tbo...@li...
Subject: Re: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
I was wondering about that. The values returned from the TPM in the hp6930p are definitely milliseconds, they are in fact equal to the default values.
A possible solution would be to always use the minimum of the value returned from the TPM and the default value. Presumably the reason for allowing the tpm to specify the timeout is to allow a slow TPM to specify longer timeouts.
christian
From: Wang, Shane [mailto:sha...@in...]
Sent: Sunday, January 31, 2010 10:33 PM
To: Ross Philipson; tbo...@li...
Cc: Christian Limpach
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Hi, Ross and Christian,
According to TCG PC Client Sepcific TPM Interface Specification (TIS), calling the TPM_GetCapability command with the capability TPM_CAP_PROP_TIS_TIMEOUTS return an array of uint32 values each representing the number of microseconds for the associated timeout. And the structure we used represents the number of milliseconds. I also tested the code with some TPMs. I guess maybe your hp6930p doesn't conform to the spec.
Thanks.
Shane
________________________________
From: Ross Philipson [mailto:Ros...@ci...]
Sent: 2010年1月29日 18:45
To: tbo...@li...
Cc: Christian Limpach
Subject: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Patch to fix timeout bug introduced by tboot.hg changeset 176. Either the TPM in the hp6930p doesn't operate to spec or the code was never tested. With the patch, the values read from the tpm are equal to the default values used before tpm timeout code was added in changesets 163 and 176.
Signed-off-by: Christian Limpach chr...@eu...<mailto:chr...@eu...>
Acked-by: Ross Philipson ros...@ci...<mailto:ros...@ci...>
diff -r 75e242a56344 tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 05 23:05:07 2010 -0800
+++ b/tboot/common/tpm.c Fri Jan 29 00:59:05 2010 +0000
@@ -1944,10 +1944,10 @@
* timeout_x represents the number of milliseconds for the timeout
* and timeout[x] represents the number of microseconds.
*/
- g_timeout.timeout_a = timeout[0]/1000;
- g_timeout.timeout_b = timeout[1]/1000;
- g_timeout.timeout_c = timeout[2]/1000;
- g_timeout.timeout_d = timeout[3]/1000;
+ g_timeout.timeout_a = timeout[0];
+ g_timeout.timeout_b = timeout[1];
+ g_timeout.timeout_c = timeout[2];
+ g_timeout.timeout_d = timeout[3];
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
|
|
From: Cihula, J. <jos...@in...> - 2010-02-08 20:25:46
|
I pushed this patch since I was able to get confirmation of it working on a system we have here.
Ross, do you have any feedback on the previous policy patch with the warning message and 5sec delay?
Joe
From: Cihula, Joseph
Sent: Saturday, February 06, 2010 2:11 PM
To: Christian Limpach; Wang, Shane; Ross Philipson; tbo...@li...
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
As Christian points out, the best approach is to “round up” any timeouts that are less than the defaults. Here is such a patch-please verify it on your TPM with the incorrect timeouts.
Joe
diff -r 0d7b5f56f26a tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 26 13:44:35 2010 -0800
+++ b/tboot/common/tpm.c Sat Feb 06 12:20:25 2010 -0800
@@ -1951,6 +1951,14 @@ bool is_tpm_ready(uint32_t locality)
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
+ /*
+ * if any timeout values are less than default values, set to default
+ * value (due to bug with some TPMs)
+ */
+ if ( g_timeout.timeout_a < TIMEOUT_A ) g_timeout.timeout_a = TIMEOUT_A;
+ if ( g_timeout.timeout_b < TIMEOUT_B ) g_timeout.timeout_b = TIMEOUT_B;
+ if ( g_timeout.timeout_c < TIMEOUT_C ) g_timeout.timeout_c = TIMEOUT_C;
+ if ( g_timeout.timeout_d < TIMEOUT_D ) g_timeout.timeout_d = TIMEOUT_D;
}
return true;
From: Christian Limpach [mailto:Chr...@eu...]
Sent: Monday, February 01, 2010 12:27 PM
To: Wang, Shane; Ross Philipson; tbo...@li...
Subject: Re: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
I was wondering about that. The values returned from the TPM in the hp6930p are definitely milliseconds, they are in fact equal to the default values.
A possible solution would be to always use the minimum of the value returned from the TPM and the default value. Presumably the reason for allowing the tpm to specify the timeout is to allow a slow TPM to specify longer timeouts.
christian
From: Wang, Shane [mailto:sha...@in...]
Sent: Sunday, January 31, 2010 10:33 PM
To: Ross Philipson; tbo...@li...
Cc: Christian Limpach
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Hi, Ross and Christian,
According to TCG PC Client Sepcific TPM Interface Specification (TIS), calling the TPM_GetCapability command with the capability TPM_CAP_PROP_TIS_TIMEOUTS return an array of uint32 values each representing the number of microseconds for the associated timeout. And the structure we used represents the number of milliseconds. I also tested the code with some TPMs. I guess maybe your hp6930p doesn't conform to the spec.
Thanks.
Shane
________________________________
From: Ross Philipson [mailto:Ros...@ci...]
Sent: 2010年1月29日 18:45
To: tbo...@li...
Cc: Christian Limpach
Subject: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Patch to fix timeout bug introduced by tboot.hg changeset 176. Either the TPM in the hp6930p doesn't operate to spec or the code was never tested. With the patch, the values read from the tpm are equal to the default values used before tpm timeout code was added in changesets 163 and 176.
Signed-off-by: Christian Limpach chr...@eu...<mailto:chr...@eu...>
Acked-by: Ross Philipson ros...@ci...<mailto:ros...@ci...>
diff -r 75e242a56344 tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 05 23:05:07 2010 -0800
+++ b/tboot/common/tpm.c Fri Jan 29 00:59:05 2010 +0000
@@ -1944,10 +1944,10 @@
* timeout_x represents the number of milliseconds for the timeout
* and timeout[x] represents the number of microseconds.
*/
- g_timeout.timeout_a = timeout[0]/1000;
- g_timeout.timeout_b = timeout[1]/1000;
- g_timeout.timeout_c = timeout[2]/1000;
- g_timeout.timeout_d = timeout[3]/1000;
+ g_timeout.timeout_a = timeout[0];
+ g_timeout.timeout_b = timeout[1];
+ g_timeout.timeout_c = timeout[2];
+ g_timeout.timeout_d = timeout[3];
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
|
|
From: Corrion, B. W <bra...@in...> - 2010-02-02 20:31:41
|
FYI not five minutes ago I just ran into the same TPM timeout on my HP 6930p testing the latest tboot.
Thanks
Brad
Brad Corrion
Platform Architect
Embedded & Communications Group
480-552-3366
From: Christian Limpach [mailto:Chr...@eu...]
Sent: Monday, February 01, 2010 1:27 PM
To: Wang, Shane; Ross Philipson; tbo...@li...
Subject: Re: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
I was wondering about that. The values returned from the TPM in the hp6930p are definitely milliseconds, they are in fact equal to the default values.
A possible solution would be to always use the minimum of the value returned from the TPM and the default value. Presumably the reason for allowing the tpm to specify the timeout is to allow a slow TPM to specify longer timeouts.
christian
From: Wang, Shane [mailto:sha...@in...]
Sent: Sunday, January 31, 2010 10:33 PM
To: Ross Philipson; tbo...@li...
Cc: Christian Limpach
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Hi, Ross and Christian,
According to TCG PC Client Sepcific TPM Interface Specification (TIS), calling the TPM_GetCapability command with the capability TPM_CAP_PROP_TIS_TIMEOUTS return an array of uint32 values each representing the number of microseconds for the associated timeout. And the structure we used represents the number of milliseconds. I also tested the code with some TPMs. I guess maybe your hp6930p doesn't conform to the spec.
Thanks.
Shane
________________________________
From: Ross Philipson [mailto:Ros...@ci...]
Sent: 2010年1月29日 18:45
To: tbo...@li...
Cc: Christian Limpach
Subject: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Patch to fix timeout bug introduced by tboot.hg changeset 176. Either the TPM in the hp6930p doesn't operate to spec or the code was never tested. With the patch, the values read from the tpm are equal to the default values used before tpm timeout code was added in changesets 163 and 176.
Signed-off-by: Christian Limpach chr...@eu...<mailto:chr...@eu...>
Acked-by: Ross Philipson ros...@ci...<mailto:ros...@ci...>
diff -r 75e242a56344 tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 05 23:05:07 2010 -0800
+++ b/tboot/common/tpm.c Fri Jan 29 00:59:05 2010 +0000
@@ -1944,10 +1944,10 @@
* timeout_x represents the number of milliseconds for the timeout
* and timeout[x] represents the number of microseconds.
*/
- g_timeout.timeout_a = timeout[0]/1000;
- g_timeout.timeout_b = timeout[1]/1000;
- g_timeout.timeout_c = timeout[2]/1000;
- g_timeout.timeout_d = timeout[3]/1000;
+ g_timeout.timeout_a = timeout[0];
+ g_timeout.timeout_b = timeout[1];
+ g_timeout.timeout_c = timeout[2];
+ g_timeout.timeout_d = timeout[3];
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
|
|
From: Christian L. <Chr...@eu...> - 2010-02-01 20:27:01
|
I was wondering about that. The values returned from the TPM in the hp6930p are definitely milliseconds, they are in fact equal to the default values.
A possible solution would be to always use the minimum of the value returned from the TPM and the default value. Presumably the reason for allowing the tpm to specify the timeout is to allow a slow TPM to specify longer timeouts.
christian
From: Wang, Shane [mailto:sha...@in...]
Sent: Sunday, January 31, 2010 10:33 PM
To: Ross Philipson; tbo...@li...
Cc: Christian Limpach
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Hi, Ross and Christian,
According to TCG PC Client Sepcific TPM Interface Specification (TIS), calling the TPM_GetCapability command with the capability TPM_CAP_PROP_TIS_TIMEOUTS return an array of uint32 values each representing the number of microseconds for the associated timeout. And the structure we used represents the number of milliseconds. I also tested the code with some TPMs. I guess maybe your hp6930p doesn't conform to the spec.
Thanks.
Shane
________________________________
From: Ross Philipson [mailto:Ros...@ci...]
Sent: 2010年1月29日 18:45
To: tbo...@li...
Cc: Christian Limpach
Subject: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Patch to fix timeout bug introduced by tboot.hg changeset 176. Either the TPM in the hp6930p doesn't operate to spec or the code was never tested. With the patch, the values read from the tpm are equal to the default values used before tpm timeout code was added in changesets 163 and 176.
Signed-off-by: Christian Limpach chr...@eu...<mailto:chr...@eu...>
Acked-by: Ross Philipson ros...@ci...<mailto:ros...@ci...>
diff -r 75e242a56344 tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 05 23:05:07 2010 -0800
+++ b/tboot/common/tpm.c Fri Jan 29 00:59:05 2010 +0000
@@ -1944,10 +1944,10 @@
* timeout_x represents the number of milliseconds for the timeout
* and timeout[x] represents the number of microseconds.
*/
- g_timeout.timeout_a = timeout[0]/1000;
- g_timeout.timeout_b = timeout[1]/1000;
- g_timeout.timeout_c = timeout[2]/1000;
- g_timeout.timeout_d = timeout[3]/1000;
+ g_timeout.timeout_a = timeout[0];
+ g_timeout.timeout_b = timeout[1];
+ g_timeout.timeout_c = timeout[2];
+ g_timeout.timeout_d = timeout[3];
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
|
|
From: Ross P. <Ros...@ci...> - 2010-02-01 09:56:31
|
Yes, it seems that is the case and we were totally unable to use tboot on our HP systems. Christian’s patch at least got things working and it is possible there are other systems out there that have the same problem. If you have another solution in mind that is fine (perhaps making it configurable) but there should be a way for folks to work around problems in the TPM hardware like this.
Thanks
Ross
From: Wang, Shane [mailto:sha...@in...]
Sent: Monday, February 01, 2010 6:33 AM
To: Ross Philipson; tbo...@li...
Cc: Christian Limpach
Subject: RE: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Hi, Ross and Christian,
According to TCG PC Client Sepcific TPM Interface Specification (TIS), calling the TPM_GetCapability command with the capability TPM_CAP_PROP_TIS_TIMEOUTS return an array of uint32 values each representing the number of microseconds for the associated timeout. And the structure we used represents the number of milliseconds. I also tested the code with some TPMs. I guess maybe your hp6930p doesn't conform to the spec.
Thanks.
Shane
________________________________
From: Ross Philipson [mailto:Ros...@ci...]
Sent: 2010年1月29日 18:45
To: tbo...@li...
Cc: Christian Limpach
Subject: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Patch to fix timeout bug introduced by tboot.hg changeset 176. Either the TPM in the hp6930p doesn't operate to spec or the code was never tested. With the patch, the values read from the tpm are equal to the default values used before tpm timeout code was added in changesets 163 and 176.
Signed-off-by: Christian Limpach chr...@eu...<mailto:chr...@eu...>
Acked-by: Ross Philipson ros...@ci...<mailto:ros...@ci...>
diff -r 75e242a56344 tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 05 23:05:07 2010 -0800
+++ b/tboot/common/tpm.c Fri Jan 29 00:59:05 2010 +0000
@@ -1944,10 +1944,10 @@
* timeout_x represents the number of milliseconds for the timeout
* and timeout[x] represents the number of microseconds.
*/
- g_timeout.timeout_a = timeout[0]/1000;
- g_timeout.timeout_b = timeout[1]/1000;
- g_timeout.timeout_c = timeout[2]/1000;
- g_timeout.timeout_d = timeout[3]/1000;
+ g_timeout.timeout_a = timeout[0];
+ g_timeout.timeout_b = timeout[1];
+ g_timeout.timeout_c = timeout[2];
+ g_timeout.timeout_d = timeout[3];
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
|
|
From: Wang, S. <sha...@in...> - 2010-02-01 06:33:25
|
Hi, Ross and Christian,
According to TCG PC Client Sepcific TPM Interface Specification (TIS), calling the TPM_GetCapability command with the capability TPM_CAP_PROP_TIS_TIMEOUTS return an array of uint32 values each representing the number of microseconds for the associated timeout. And the structure we used represents the number of milliseconds. I also tested the code with some TPMs. I guess maybe your hp6930p doesn't conform to the spec.
Thanks.
Shane
________________________________
From: Ross Philipson [mailto:Ros...@ci...]
Sent: 2010年1月29日 18:45
To: tbo...@li...
Cc: Christian Limpach
Subject: [tboot-devel] [PATCH] Fix timeout bug introduced by tboot.hg changeset 176.
Patch to fix timeout bug introduced by tboot.hg changeset 176. Either the TPM in the hp6930p doesn't operate to spec or the code was never tested. With the patch, the values read from the tpm are equal to the default values used before tpm timeout code was added in changesets 163 and 176.
Signed-off-by: Christian Limpach chr...@eu...<mailto:chr...@eu...>
Acked-by: Ross Philipson ros...@ci...<mailto:ros...@ci...>
diff -r 75e242a56344 tboot/common/tpm.c
--- a/tboot/common/tpm.c Tue Jan 05 23:05:07 2010 -0800
+++ b/tboot/common/tpm.c Fri Jan 29 00:59:05 2010 +0000
@@ -1944,10 +1944,10 @@
* timeout_x represents the number of milliseconds for the timeout
* and timeout[x] represents the number of microseconds.
*/
- g_timeout.timeout_a = timeout[0]/1000;
- g_timeout.timeout_b = timeout[1]/1000;
- g_timeout.timeout_c = timeout[2]/1000;
- g_timeout.timeout_d = timeout[3]/1000;
+ g_timeout.timeout_a = timeout[0];
+ g_timeout.timeout_b = timeout[1];
+ g_timeout.timeout_c = timeout[2];
+ g_timeout.timeout_d = timeout[3];
printk("TPM timeout values: A: %u, B: %u, C: %u, D: %u\n",
g_timeout.timeout_a, g_timeout.timeout_b, g_timeout.timeout_c,
g_timeout.timeout_d);
|
|
From: Cihula, J. <jos...@in...> - 2010-01-26 17:00:09
|
> From: Karthik . [mailto:tr...@gm...] > Sent: Tuesday, January 26, 2010 7:38 AM > > Hi Joe, > > Looks like the makefile for lcptools is broken. It complains about the > missing 'sbios_elt.c' file (No rule to make target `sbios_elt.o', > needed by `lcp_crtpol2'. Stop.). Extra file in my local directory from development--now fixed. Thanks. Joe |
|
From: Karthik . <tr...@gm...> - 2010-01-26 15:44:40
|
Hi Joe, Looks like the makefile for lcptools is broken. It complains about the missing 'sbios_elt.c' file (No rule to make target `sbios_elt.o', needed by `lcp_crtpol2'. Stop.). |
|
From: Cihula, J. <jos...@in...> - 2010-01-26 00:57:43
|
I have now checked in support for v2 of LCP. There are a few changes to tboot, mainly to support the new policy data file format. Most of the support is in the form of new tools in lcptools/. The overall policy "documentation" has been split into docs/policy_v1.txt and docs/policy_v2.txt. As referenced in policy_v2.txt, there is more documentation on the new commands in lcptools/lcptools2.txt. The existing, v1, tools are (mostly) unchanged and are still required for the current (< 2009) platforms (e.g. Weybridge, Montevina, McCreary). The new tools are required for all platforms released on or after 2009 (e.g. Calpella/Piketon/FoxHollow). Joe |
|
From: Cihula, J. <jos...@in...> - 2010-01-14 18:33:28
|
Ross, I added the '-ltspi' dependency when I removed TrouSerS in order to give a user who does not have TrouSerS installed a better error message (otherwise they get the missing header file error followed by a screenful of missing identifiers. This just provides a single error that libtspi is missing. How are you seeing this failing? Joe From: Ross Philipson [mailto:Ros...@ci...] Sent: Thursday, January 14, 2010 6:39 AM To: tbo...@li... Subject: [tboot-devel] [PATCH] Fix lcptools makefile Patch attached: The removal of Trousers from the build introduced a build issue in the lcptools/Makefile where -ltspi is listed as a build target and causes building to fail. Signed-off-by: Ross Philipson ros...@ci...<mailto:ros...@ci...> |
|
From: Michael G. <m.g...@tu...> - 2010-01-07 11:53:42
|
Hi all! I just found a new version of Intel's MLE Developer’s Guide at http://www.intel.com/technology/security/ Version December 2009 An official release announcement on this list of such updates would be great. btw: there are some annoying unresolved references in the text... Michael |
|
From: Cihula, J. <jos...@in...> - 2009-12-30 02:04:59
|
KeJin, The first thing you need to do is to get your system working. If you have two DIMMs installed, try removing the one in the first slot and see if that allows it to boot. If this fails and you are unable to get to the BIOS config, then you should contact Lenovo about whether they have any additional procedures. Once you get a booting machine, make sure you have the latest BIOS installed. Then try the latest version of tboot (from the mercurial repo) *and don't comment out anything*. If that fails, post your serial output and I can see what the failure reason is and how to get past it (if possible). Joe From: ars...@gm... [mailto:ars...@gm...] Sent: Wednesday, December 23, 2009 6:49 AM To: tbo...@li... Subject: [tboot-devel] tboot broke my desktop (twice!!) This is a long story ...(and I found 3 cases like me, go on and see..) First of all , Introduce the victim : My desktop PC is Lenovo ThinkCentre M57p , with winbond v1.2 TPM and Intel Q35 chipset,support VT-x , VT-d and TXT. I am going to use tboot to launch Xen. The OS is Ubuntu 9.04 32bit Desktop Version. Xen is v3.4.2, tboot version is 20090330, SINIT AC module is Q35_SINIT_17.BIN Then , Belows are what I have done: Step 1 : I enabled the TPM , VT,VT-d,TXT in BIOS ; OK! Step 2 : In Ubuntu , I make & make install trousers 0.31 There are some bugs to fix When build in Ubuntu 9.04(which have been solved in new trousers 0.32):(Added #include <limits.h> to remove INT_MAX undeclared error during build.---In Files : trspi/crypto/openssl/symmetric.c,tspi/tspi_aik.c and tspi/tsp_ps.c) OK! Step 3 : I make & make install tpm-tools; then execute $tpm_takeownership -z, and set the owner password. OK! Step 4 : make & make install tboot(excluded trousers in config.mk<http://config.mk>) There are a few "warning as error" during make ,It seems gcc in ubuntu 9.04 is not compatible with tboot's makefile options, So I degrade the gcc to 4.1 , Solved! OK! Step 5 : I Defined the LCP and Wrote it to TPM NV as docs/policy.txt says, and edited the menu.lst follow the README. OK! Until now , all right . Now the problems coming: When I reboot to start the tboot, it stops at TBOOT: unsupported BIOS data version (1) TBOOT: TPM: access reg release locality timeout TBOOT: shutdown_system() called for shutdown_type: TB_SHUTDOWN_HALT So I search it in source code , and find it in tboot/txt/heap.c, then I comment the lines which check the bios version /* check version */ // if ( bios_data->version < 2 ) { // printk("unsupported BIOS data version (%u)\n", bios_data->version); // return false; // } After that a likely check failure happened when check num_logical_procs just below bios check(in heap.c),and I also comment that check too. /* all TXT-capable CPUs support at least 2 cores */ // if ( bios_data->num_logical_procs < 2 ) { // printk("BIOS data has incorrect num_logical_procs (%u)\n", // bios_data->num_logical_procs); // return false; // } ******************************************** Here is a same case as me ......= =!! http://sourceforge.net/mailarchive/forum.php?thread_name=4F65016F6CB04E49BFFA15D4F7B798D92D571DD3%40orsmsx506.amr.corp.intel.com&forum_name=tboot-devel ******************************************** Reboot....This time , it hangs in TBOOT: executing GETSEC[SENTER]... (I used the serial and export the output to another PC to see it) Then I have to hold the power button to shutdown the computer. By the way , I didn't add "iommu=required" in line of tboot.gz and "iommu=1 vtd=1" in line of xen-3.4.2.gz in menu.lst. Is it necessary to trun on VT-d to run tboot correctly? ********************************************** Here is a similar case like me ......= =!! http://sourceforge.net/mailarchive/forum.php?thread_name=078A938E4AF9FF4AA7B9937889E8E57C1A883F83BF%40GVW0436EXB.americas.hpqcorp.net&forum_name=tboot-devel *********************************************** There Hal suggest that roll back the BIOS may make a differerce. But I can't find the earlier BIOS version for my ThinkCentre ,So I don't know if degrading the BIOS take effect.Then I wonder it may be the problem of the LCP. So I use the lcptools/tpmnv_relindex to release the policies those I had defined.Then reboot.......then NIGHTMARE .. "Something went wrong. My laptop(desktop) hung and I restarted it. But it didn't start properly. The power light and other lights came on, but the display did not light up. The fan started and disk began spinning, but after about a second, the whole thing powered down. The fan and disk stopped, and all of the lights went out. Then, after a few seconds, it turned itself back on. But once again, after starting the fan and disk, and before lighting the display, the laptop shut off. This cycle would repeat indefinitely, the laptop turning itself on and off. I have to make it stop by pressing and holding the power button." "In short, my laptop(desktop) was completely broken and useless." "Fortunately, being new it was covered by HP's(lenovo's) warranty." "They had replaced the motherboard and it worked fine. So I tried again. I enabled the new TPM, got VT and TXT enabled, and tried launching tboot." "It broke again." "Once again my laptop(desktop) is useless. It repeatedly turns itself on and off, and does not even light up the display. It does not get far enough into BIOS to boot from a CD or any other medium." ------from Hal Finney <<tboot broke my laptop! (twice!)>> ********************************************** http://sourceforge.net/mailarchive/forum.php?thread_name=078A938E4AF9FF4AA7B9937889E8E57C1A883F83BF%40GVW0436EXB.americas.hpqcorp.net&forum_name=tboot-devel ......= =!! *********************************************** God,Exactly the same to me !!!! I'm about what caused it to broke, BIOS or tboot?? Is there anybody who run tboot successful in ThinkCentre M57p , Please help me. |
|
From: Cihula, J. <jos...@in...> - 2009-12-30 01:55:58
|
I have created a new mailing list that will send out the changeset info for any changes to the tboot source code repository: tbo...@li...<mailto:tbo...@li...>. You can subscribe at https://lists.sourceforge.net/lists/listinfo/tboot-changelog. Joe |