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: 柯晋 <ars...@gm...> - 2009-12-25 03:59:10
|
Sorry, The link to Hal ‘s <tboot broke my laptop! (twice!)> is wrong ,it should be http://sourceforge.net/mailarchive/message.php?msg_name=da7b3ce30908160913h1a902a00wf798d7a9cd4f0a69%40mail.gmail.com Merry Xmas! ---------- KeJin Dec 25,2009 |
|
From: 柯晋 <ars...@gm...> - 2009-12-23 14:49:06
|
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)
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: Hal F. <hal...@gm...> - 2009-12-23 02:07:37
|
Some months ago there were some press announcements re attacks on TXT by Joanna Rutkowska's group at Invisible Things Lab (ITL). I believe it had to do with SMM and the semi-mythical SMM Transfer Monitor supported by TXT. Recently there was a new TXT flaw found by the same group. Details of the attack, and updated SINIT modules from Intel, were released yesterday. Somewhat ironically, the SINIT bug relates to a problem area many of us have run into in unsuccessfully trying to get various machines to go into TXT mode, namely the DMAR table in memory which describes devices and their memory access translations. This table is prepared by BIOS, but SINIT doesn't trust it. It goes over it with a fine tooth comb, checking it against the actual hardware devices which SINIT finds to exist, and then when SINIT is satisfied, it copies the table into secure memory for use by tboot. I and others have had problems where SINIT doesn't like something about the table and refuses to launch, leaving us scratching our heads as to what is wrong. ITL did not bother with head scratching, they just disassembled the SINIT code to see what it was doing. (This is because they were looking for attacks rather than trying to help befuddled would-be tboot users, but I can't help thinking that their skills would be useful in our debugging efforts.) They discovered a bug, as I said: a certain device register is 64 bits but SINIT only read the lower 32 bits and used that as an address. Oops, an easy mistake to make; I have done much the same but that software was not security sensitive. ITL wrote something into the high 32 bits before launching TXT and as a result the device table is not where SINIT thinks it is, hence SINIT gets fooled, and as they say, 0wned. Specifically SINIT doesn't find out about one of the DMA units and doesn't set it up with VT-d protections, allowing it to later be made to spray all over memory right on top of the supposedly protected region. I suppose I should remind readers of my call for Intel to open-source this security critical code in the hopes that our many eyes may find bugs without relying on embarrassing public press releases saying that TXT is broken. Invisible Things blog posting with link to paper: http://theinvisiblethings.blogspot.com/2009/12/another-txt-attack.html Intel security advisory: http://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00021&languageid=en-fr Fresh new SINIT modules available from sourceforge: http://sourceforge.net/projects/tboot/files/ So where is the CRL so we know not to trust attestations from broken SINITs? Or something like OCSP with a server run by Intel that we can query to see which SINITs are good and which are bad? Intel is going to be in trouble if anyone actually starts to use this technology, with their current lack of attention to these kinds of details! Hal Finney |
|
From: Martin P. <Mar...@ia...> - 2009-12-03 16:50:21
|
Cihula, Joseph wrote: >> From: Martin Pirker [mailto:Mar...@ia...] >> another BIOS update, another try.... >> >> Intel DQ45CB, bios rev 103(20091104) >> TBoot e57acd4d1460 > The work around is to disable legacy USB support. Indeed, that's the trick, thank you! I can confirm successful tboot, done with LCP "any" and "hashonly" policy. - as this disables the keyboard one has to control GRUB menu by serial console - for some reason GRUB only likes serial speed 9600, so tboot needs to be set to 9600, too - booted with a 2.6.30 kernel with TXT + Intel TPM patches - all TPM NV + TXT LCP stuff done solely with jTpmTools - I can also confirm a successful tboot on a HP dc7900 with vanilla 2.6.32 No TXT patching necessary :-) One board nailed - what about the others? - Is there a way to identify the BIOSs which seemingly do contain some bad code which turns the boards to bricks upon SINIT? I don't like the trial and error strategy... - Can anybody report tboot experiences with other Q45 boards, e.g. Asus P5Q-EM DO/P5Q-VM DO (Intel TPM) Fujitsu D2831-S/D2836-S (IFX TPM) Gigabyte GA-EQ45M-S2 (IFX TPM) ...and laptops? Best regards, Martin |
|
From: Cihula, J. <jos...@in...> - 2009-12-02 08:07:28
|
> From: Martin Pirker [mailto:Mar...@ia...] > Sent: Monday, November 23, 2009 2:32 AM > To: tbo...@li... > > Hi.... > > another BIOS update, another try.... > > Intel DQ45CB, bios rev 103(20091104) > TBoot e57acd4d1460 > > Good news: > board does not turn into a brick > > Bad news: > executing TBoot, it still gets stuck at > TBOOT: executing GETSEC[SENTER]... > > > ...so, will TXT work sometime on Intel's own mainboard? :-/ This BIOS is one of those that has usable RAM both below and above its ACPI reserved regions. It is also one of the BIOSes that gets hung in SMM when the legacy USB buffers (in those ACPI reserved regions) are DMA protected. 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. Joe |
|
From: Martin P. <Mar...@ia...> - 2009-11-23 10:32:25
|
Hi.... another BIOS update, another try.... Intel DQ45CB, bios rev 103(20091104) TBoot e57acd4d1460 Good news: board does not turn into a brick Bad news: executing TBoot, it still gets stuck at TBOOT: executing GETSEC[SENTER]... ...so, will TXT work sometime on Intel's own mainboard? :-/ Martin |
|
From: Stefan F. <ste...@re...> - 2009-10-13 16:13:12
|
TBOOT: ******************* TBOOT *******************
TBOOT: unavailable
TBOOT: *********************************************
TBOOT: command line: logging=serial,vga,memory
TBOOT: TPM is ready
TBOOT: TPM nv_locked: TRUE
TBOOT: read verified launch policy (256 bytes) from TPM NV
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_IMAGE
TBOOT: num_hashes: 5
TBOOT: hashes[0]: 07 84 2e 8f 2a 9f 3e 7d 6d 66 ca 11 03 2a 73 d5 44 bf b6 47
TBOOT: hashes[1]: 07 84 2e 8f 2a 9f 3e 7d 6d 66 ca 11 03 2a 73 d5 44 bf b6 47
TBOOT: hashes[2]: 07 84 2e 8f 2a 9f 3e 7d 6d 66 ca 11 03 2a 73 d5 44 bf b6 47
TBOOT: hashes[3]: cc 61 2b 02 f5 84 dd 57 52 14 59 ad 54 a4 8c 46 1c 91 ff 2e
TBOOT: hashes[4]: cc 61 2b 02 f5 84 dd 57 52 14 59 ad 54 a4 8c 46 1c 91 ff 2e
TBOOT: policy entry[1]:
TBOOT: mod_num: 1
TBOOT: pcr: 19
TBOOT: hash_type: TB_HTYPE_IMAGE
TBOOT: num_hashes: 4
TBOOT: hashes[0]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: hashes[1]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: hashes[2]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: hashes[3]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff0b
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: LT.ERRORCODE=0
TBOOT: LT.ESTS=0
TBOOT: bios_data (@7ca20008, 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: 0x00000002
TBOOT: CR0.NE not set
TBOOT: CR0 and EFLAGS OK
TBOOT: no machine check errors
TBOOT: CPU is ready for SENTER
TBOOT: checking previous errors on the last boot.
last boot has error.
TBOOT: user-provided SINIT found: /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 7ca00000
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=0084ec4c
TBOOT: &_mle_start=00803000
TBOOT: &_mle_end=00821000
TBOOT: &_post_launch_entry=00803020
TBOOT: &_txt_wakeup=008031f0
TBOOT: &g_mle_hdr=00818920
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=1e000
TBOOT: capabilities: 0x00000003
TBOOT: rlp_wake_getsec: 1
TBOOT: rlp_wake_monitor: 1
TBOOT: MLE start=803000, end=821000, size=1e000
TBOOT: ptab_size=3000, ptab_base=00800000
TBOOT: bios_data (@7ca20008, 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: 0x00000002
TBOOT: min_lo_ram: 0x0, max_lo_ram: 0x7c780000
TBOOT: min_hi_ram: 0x0, max_hi_ram: 0x0
TBOOT: no LCP manifest found
TBOOT: os_sinit_data (@7ca20154, 5c):
TBOOT: version: 4
TBOOT: mle_ptab: 0x800000
TBOOT: mle_size: 0x1e000 (122880)
TBOOT: mle_hdr_base: 0x15920
TBOOT: vtd_pmr_lo_base: 0x0
TBOOT: vtd_pmr_lo_size: 0x7c600000
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=7ca00000, size=67c0, num_pages=7
TBOOT: executing GETSEC[SENTER]...
TBOOT: ******************* TBOOT *******************
TBOOT: unavailable
TBOOT: *********************************************
TBOOT: command line: logging=serial,vga,memory
TBOOT: TPM is ready
TBOOT: TPM nv_locked: TRUE
TBOOT: read verified launch policy (256 bytes) from TPM NV
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_IMAGE
TBOOT: num_hashes: 5
TBOOT: hashes[0]: 07 84 2e 8f 2a 9f 3e 7d 6d 66 ca 11 03 2a 73 d5 44 bf b6 47
TBOOT: hashes[1]: 07 84 2e 8f 2a 9f 3e 7d 6d 66 ca 11 03 2a 73 d5 44 bf b6 47
TBOOT: hashes[2]: 07 84 2e 8f 2a 9f 3e 7d 6d 66 ca 11 03 2a 73 d5 44 bf b6 47
TBOOT: hashes[3]: cc 61 2b 02 f5 84 dd 57 52 14 59 ad 54 a4 8c 46 1c 91 ff 2e
TBOOT: hashes[4]: cc 61 2b 02 f5 84 dd 57 52 14 59 ad 54 a4 8c 46 1c 91 ff 2e
TBOOT: policy entry[1]:
TBOOT: mod_num: 1
TBOOT: pcr: 19
TBOOT: hash_type: TB_HTYPE_IMAGE
TBOOT: num_hashes: 4
TBOOT: hashes[0]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: hashes[1]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: hashes[2]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: hashes[3]: 38 3e 39 8a 64 a4 a6 57 b5 88 c2 bb b7 f3 a3 35 76 e5 ca 3f
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff0b
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: LT.ERRORCODE=c00038d1
TBOOT: AC module error : acm_type=1, progress=0d, error=e
TBOOT: LT.ESTS=1
TBOOT: TXT_RESET.STS is set and SENTER is disabled (0x01)
TBOOT: SMX not supported.
TBOOT: Error: ELF magic number is not matched.
TBOOT: assuming kernel is Linux format
TBOOT: Initrd from 0x7c0da000 to 0x7c77f800
TBOOT: Kernel (protected mode) from 0xc00000 to 0xf18950
TBOOT: Kernel (real mode) from 0x90000 to 0x93800
TBOOT: transfering control to kernel @0x00c00000...
� |
|
From: Martin T. <ma...@th...> - 2009-10-04 17:45:07
|
Hi I've been reading some reviews/articles suggesting that the Westmere CPU's (to come out in January 2010) will feature an updated version of trusted execution technology named "Lagrande SX". However, no details seem to be available on this. Does any of you know what are the changes compared to the current version? Thanks, Martin Thiim |
|
From: Cihula, J. <jos...@in...> - 2009-09-30 23:41:41
|
Error code 0xc0000001 isn't really an error code, but rather an indication that SINIT has finished successfully. SINIT writes this (almost) just before it transitions to the MLE entry point as a way of indicating that it has gotten that far. There is a small window of code that executes after this is written and before the actual jump to the MLE. Are you are confident that your code never executes (hence Shane's suggestion of making sure that you set the entry point correctly)? Can you post the serial log of your code's execution on the 4GB config? Also, is this a 2 core or 4 core CPU? Joe > From: Wang, Shane [mailto:sha...@in...] > Sent: Thursday, September 24, 2009 1:51 AM > To: Jonathan M. McCune > Cc: tbo...@li... > Subject: Re: [tboot-devel] SINIT Exit Point > > OK. > > So, it should not be the problem of entry point. Originally what I mean is the entry point in > tboot header structure. (see init_txt_heap()) > CONFIG_HIGHMEM4G should be kernel config. When you get "reset" in GETSEC[SENTER], kernel is > not running. So, I don't think the problem is related to any of kernel configs. > > Can you check your PMR setting for 4G? vtd_pmr_lo_base/size and vtd_pmr_hi_base/size. > > This is what I can think related to memory. > > PS: is it convenient for you to send me your serial log of your code? > > Shane > > Jonathan M. McCune wrote: > > Hi Shane, cc list, > > > > Jonathan M. McCune wrote: > >>>> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. > >>>> tboot works without issue. However, when I run my own code, the > >>>> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated > >>>> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I > >>>> am doing wrong based solely on that error message. > > > > This laptop contained 4GB of physical memory in two 2GB DIMMs. I > > removed one of them, leaving the system with only 2GB of physical > > memory. This enables my code to execute successfully. > > > > I realized this when I noticed that despite having CONFIG_HIGHMEM4G=y > > in the kernel config, the system only sees 3GB of memory. I then > > took a closer look at the value read from TXTCR_SINIT_BASE. The > > value is 0x7be00000 with 2GB of RAM in the system, but it changes to > > 0xbfe00000 with 4GB in the system. However, 0xbfe00000 is much closer > > to 3GB than 4GB. > > > > tboot will execute successfully with either amount of memory in the > > system, and also sees 0xbfe00000 in TXTCR_SINIT_BASE with 4GB of RAM > > in the system. > > > > Thus, I'm still not exactly sure what causes my code to fail. > > > > However, I discovered that the chipset in this laptop has an issue > > with making all 4GB of RAM available despite CONFIG_HIGHMEM4G=y, and > > instead requires PAE support to see more than 3GB of RAM (I did > > verify that with CONFIG_HIGHMEM64G=y all 4GB are visible to Linux). > > Here's a thread that discusses this unexpected need for PAE: > > > > http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/1787.html > > > > I'm not sure if these issues are related yet. Suggestions / comments > > / questions welcomed by all. > > > > Thanks, > > -Jon > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Wang, S. <sha...@in...> - 2009-09-24 08:52:01
|
OK. So, it should not be the problem of entry point. Originally what I mean is the entry point in tboot header structure. (see init_txt_heap()) CONFIG_HIGHMEM4G should be kernel config. When you get "reset" in GETSEC[SENTER], kernel is not running. So, I don't think the problem is related to any of kernel configs. Can you check your PMR setting for 4G? vtd_pmr_lo_base/size and vtd_pmr_hi_base/size. This is what I can think related to memory. PS: is it convenient for you to send me your serial log of your code? Shane Jonathan M. McCune wrote: > Hi Shane, cc list, > > Jonathan M. McCune wrote: >>>> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. >>>> tboot works without issue. However, when I run my own code, the >>>> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated >>>> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I >>>> am doing wrong based solely on that error message. > > This laptop contained 4GB of physical memory in two 2GB DIMMs. I > removed one of them, leaving the system with only 2GB of physical > memory. This enables my code to execute successfully. > > I realized this when I noticed that despite having CONFIG_HIGHMEM4G=y > in the kernel config, the system only sees 3GB of memory. I then > took a closer look at the value read from TXTCR_SINIT_BASE. The > value is 0x7be00000 with 2GB of RAM in the system, but it changes to > 0xbfe00000 with 4GB in the system. However, 0xbfe00000 is much closer > to 3GB than 4GB. > > tboot will execute successfully with either amount of memory in the > system, and also sees 0xbfe00000 in TXTCR_SINIT_BASE with 4GB of RAM > in the system. > > Thus, I'm still not exactly sure what causes my code to fail. > > However, I discovered that the chipset in this laptop has an issue > with making all 4GB of RAM available despite CONFIG_HIGHMEM4G=y, and > instead requires PAE support to see more than 3GB of RAM (I did > verify that with CONFIG_HIGHMEM64G=y all 4GB are visible to Linux). > Here's a thread that discusses this unexpected need for PAE: > > http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/1787.html > > I'm not sure if these issues are related yet. Suggestions / comments > / questions welcomed by all. > > Thanks, > -Jon |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-23 19:53:23
|
Hi Shane, cc list, Jonathan M. McCune wrote: >>> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. >>> tboot works without issue. However, when I run my own code, the >>> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated >>> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am >>> doing wrong based solely on that error message. This laptop contained 4GB of physical memory in two 2GB DIMMs. I removed one of them, leaving the system with only 2GB of physical memory. This enables my code to execute successfully. I realized this when I noticed that despite having CONFIG_HIGHMEM4G=y in the kernel config, the system only sees 3GB of memory. I then took a closer look at the value read from TXTCR_SINIT_BASE. The value is 0x7be00000 with 2GB of RAM in the system, but it changes to 0xbfe00000 with 4GB in the system. However, 0xbfe00000 is much closer to 3GB than 4GB. tboot will execute successfully with either amount of memory in the system, and also sees 0xbfe00000 in TXTCR_SINIT_BASE with 4GB of RAM in the system. Thus, I'm still not exactly sure what causes my code to fail. However, I discovered that the chipset in this laptop has an issue with making all 4GB of RAM available despite CONFIG_HIGHMEM4G=y, and instead requires PAE support to see more than 3GB of RAM (I did verify that with CONFIG_HIGHMEM64G=y all 4GB are visible to Linux). Here's a thread that discusses this unexpected need for PAE: http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/1787.html I'm not sure if these issues are related yet. Suggestions / comments / questions welcomed by all. Thanks, -Jon |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-23 17:17:07
|
Hi Shane, Thanks for your reply. Wang, Shane wrote: >> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. >> tboot works without issue. However, when I run my own code, the >> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated >> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am >> doing wrong based solely on that error message. > please check: > do you set the return entry in your code? I'm not sure what you mean by this. > another system? you mean hardware or software? do you use the correct sinit? I mean hardware, and I believe I am using the correct sinit, as I use the same sinit that allows tboot to work on each machine in question. My code works on an HP dc7800 with Q35_SINIT_16.BIN, and it works on a Lenovo T400 with GM45_PM45_SINIT_19.BIN. > can you run tboot on the system your system you mentioned? Yes, tboot works perfectly on the HP 8530p. > can you compare with tboot code what your code hasn't done? I can and will if I must but I am mostly just seeking to understand a little more about what the "SINIT Exit Point" error means. Is this related to the "return entry" you mention above? Thanks, -Jon |
|
From: Wang, S. <sha...@in...> - 2009-09-23 06:15:04
|
Jonathan M. McCune wrote: > Hi Shane, cc list, > > I'm experimenting with SENTER on an HP 8530p with the newest BIOS. > tboot works without issue. However, when I run my own code, the > laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated > with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am > doing wrong based solely on that error message. > > Attached is the log for the successful tboot run. I'm trying to > figure out what might be unusual about this platform that causes it > to fail, as my code does work on another system that I have here. please check: do you set the return entry in your code? another system? you mean hardware or software? do you use the correct sinit? can you run tboot on the system your system you mentioned? can you compare with tboot code what your code hasn't done? > > This line is interesting: > > TBOOT: SINIT does not support launch with MLE pagetable in ECX It is printed by me. SINIT will support this but now it is not ready. > > And there's a chance I'm doing something wrong with the MTRRs, but the > error message does not seem to relate to either of these. Any ideas? > > Thanks, > -Jon |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-22 20:26:27
|
Hi Shane, cc list, I'm experimenting with SENTER on an HP 8530p with the newest BIOS. tboot works without issue. However, when I run my own code, the laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am doing wrong based solely on that error message. Attached is the log for the successful tboot run. I'm trying to figure out what might be unusual about this platform that causes it to fail, as my code does work on another system that I have here. This line is interesting: TBOOT: SINIT does not support launch with MLE pagetable in ECX And there's a chance I'm doing something wrong with the MTRRs, but the error message does not seem to relate to either of these. Any ideas? Thanks, -Jon |
|
From: Martin P. <Mar...@ia...> - 2009-09-22 07:54:38
|
Wang, Shane wrote: > Error 0xc0000001 is fine. Anyway, you can reset and get the machine work;-) > Can you send me the log if convenient? > > Make sure you enabled TXT, TPM and VT-d in BIOS, get the correct SINIT for the board. attached Note that this is the identical setup/kernel which tboots on the HP box just fine - we moved the harddisk.... Thanks, Martin |
|
From: Wang, S. <sha...@in...> - 2009-09-22 02:57:39
|
Martin, Error 0xc0000001 is fine. Anyway, you can reset and get the machine work;-) Can you send me the log if convenient? Make sure you enabled TXT, TPM and VT-d in BIOS, get the correct SINIT for the board. Thanks. Shane Martin Pirker wrote: > Hi list... > > Martin Pirker wrote: >> I now have a box which is a brick :-((((( >> (Removing CMOS battery to clear TPM NV does not help) >> >> FYI (AFAIR): >> Intel DQ45CB, BIOS version 0085 >> TBoot f332236d7183 >> bootlog before crash captured from serial console attached > > We got a replacement board under warranty. > Updated to BIOS version 0093. > Updated TBoot to latest da3ebacc9b6d. > > Result: > Good news: The board is still working.... ;-) > > Bad news: > Executing TBoot, it gets stuck at > TBOOT: executing GETSEC[SENTER]... > > This happens every time, whenever control is transfered from > TBoot to SINIT AC, control appears to never get back to TBoot. > > After reset (by reset switch) we get: > LT.ERRORCODE=c0000001 > > This is > valid error/software error/SINIT > 00/0000 -> SINIT Exit Point > > > Martin > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your developing skills, take BlackBerry mobile applications to market > and stay ahead of the curve. Join us from November 9-12, 2009. > Register now! http://p.sf.net/sfu/devconf > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Martin P. <Mar...@ia...> - 2009-09-18 12:54:15
|
Hi list... Martin Pirker wrote: > I now have a box which is a brick :-((((( > (Removing CMOS battery to clear TPM NV does not help) > > FYI (AFAIR): > Intel DQ45CB, BIOS version 0085 > TBoot f332236d7183 > bootlog before crash captured from serial console attached We got a replacement board under warranty. Updated to BIOS version 0093. Updated TBoot to latest da3ebacc9b6d. Result: Good news: The board is still working.... ;-) Bad news: Executing TBoot, it gets stuck at TBOOT: executing GETSEC[SENTER]... This happens every time, whenever control is transfered from TBoot to SINIT AC, control appears to never get back to TBoot. After reset (by reset switch) we get: LT.ERRORCODE=c0000001 This is valid error/software error/SINIT 00/0000 -> SINIT Exit Point Martin |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-16 11:09:49
|
Hi Shane, Thanks for your reply. It turns out I had some bugs in some of my error-handling code and I was invoking SENTER when the MTRRs for the SINIT region had not yet been set correctly. Searching the MLE Developer's Guide for BadACMMType yields a paragraph that explains what was wrong. I should have posted another follow-up that I resolved the issue; sorry about that. Cheers, -Jon Wang, Shane wrote: > Can you find some info from sinit_errors.txt (see attached) in the SINIT package on sourceforge? > > But your type field is 5, it is strange. > > Shane > > Jonathan M. McCune wrote: > >> Hello list, >> >> Actually, I've just found Table 15 in Appendix B in the MLE >> Developer's Guide. >> >> I'm receiving error #BadACMMType (LT.ERRORCODE=0xc0000005). Does this >> mean that the MTRRs are incorrectly set for the ACMod area? From the >> table: "Load memory type error in Authenticated Code Execution Area." >> >> Some more of the table: >> >> Type Field Encodings for Processor-Initiated Intel(r) TXT Shutdowns >> >> Type Error condition Mnemonic >> >> 0 Legacy shutdown #LegacyShutdown >> 1-4 Reserved Reserved >> 5 Load memory type error in Authenticated Code Execution Area >> #BadACMMType 6 Unrecognized AC module format #UnsupportedACM >> 7 Failure to authenticate #AuthenticateFail >> 8 Invalid AC module format #BadACMFormat >> 9 Unexpected snoop hit detected #UnexpectedHITM >> 10 Invalid event #InvalidEvent >> >> Any advice / suggestions are much appreciated. >> >> Thanks, >> -Jon >> >> >> >> Jonathan M. McCune wrote: >> >>> Hello list, >>> >>> Where can I find a description of the causes associated with various >>> "processor error codes" that may end up in LT.ERRORCODE following an >>> attempted GETSEC[SENTER]? The MLE developer's guide seems to contain >>> only LCP-related error codes. >>> >>> Thanks! >>> -Jon >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and >>> deployment - and focus on what you do best, core application coding. >>> Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> tboot-devel mailing list >>> tbo...@li... >>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>> > > |
|
From: Wang, S. <sha...@in...> - 2009-09-16 07:59:31
|
Can you find some info from sinit_errors.txt (see attached) in the SINIT package on sourceforge? But your type field is 5, it is strange. Shane Jonathan M. McCune wrote: > Hello list, > > Actually, I've just found Table 15 in Appendix B in the MLE > Developer's Guide. > > I'm receiving error #BadACMMType (LT.ERRORCODE=0xc0000005). Does this > mean that the MTRRs are incorrectly set for the ACMod area? From the > table: "Load memory type error in Authenticated Code Execution Area." > > Some more of the table: > > Type Field Encodings for Processor-Initiated Intel(r) TXT Shutdowns > > Type Error condition Mnemonic > > 0 Legacy shutdown #LegacyShutdown > 1-4 Reserved Reserved > 5 Load memory type error in Authenticated Code Execution Area > #BadACMMType 6 Unrecognized AC module format #UnsupportedACM > 7 Failure to authenticate #AuthenticateFail > 8 Invalid AC module format #BadACMFormat > 9 Unexpected snoop hit detected #UnexpectedHITM > 10 Invalid event #InvalidEvent > > Any advice / suggestions are much appreciated. > > Thanks, > -Jon > > > > Jonathan M. McCune wrote: >> Hello list, >> >> Where can I find a description of the causes associated with various >> "processor error codes" that may end up in LT.ERRORCODE following an >> attempted GETSEC[SENTER]? The MLE developer's guide seems to contain >> only LCP-related error codes. >> >> Thanks! >> -Jon >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and >> deployment - and focus on what you do best, core application coding. >> Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> tboot-devel mailing list >> tbo...@li... >> https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-11 20:57:18
|
Hello list, Actually, I've just found Table 15 in Appendix B in the MLE Developer's Guide. I'm receiving error #BadACMMType (LT.ERRORCODE=0xc0000005). Does this mean that the MTRRs are incorrectly set for the ACMod area? From the table: "Load memory type error in Authenticated Code Execution Area." Some more of the table: Type Field Encodings for Processor-Initiated Intel® TXT Shutdowns Type Error condition Mnemonic 0 Legacy shutdown #LegacyShutdown 1-4 Reserved Reserved 5 Load memory type error in Authenticated Code Execution Area #BadACMMType 6 Unrecognized AC module format #UnsupportedACM 7 Failure to authenticate #AuthenticateFail 8 Invalid AC module format #BadACMFormat 9 Unexpected snoop hit detected #UnexpectedHITM 10 Invalid event #InvalidEvent Any advice / suggestions are much appreciated. Thanks, -Jon Jonathan M. McCune wrote: > Hello list, > > Where can I find a description of the causes associated with various > "processor error codes" that may end up in LT.ERRORCODE following an > attempted GETSEC[SENTER]? The MLE developer's guide seems to contain > only LCP-related error codes. > > Thanks! > -Jon > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-11 20:46:36
|
Hello list, Where can I find a description of the causes associated with various "processor error codes" that may end up in LT.ERRORCODE following an attempted GETSEC[SENTER]? The MLE developer's guide seems to contain only LCP-related error codes. Thanks! -Jon |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-11 12:00:52
|
Hi Shane, list, I use the term "brick" because I have been unable to recover it in that situation. I exchanged it under warranty for a new unit. HP has posted a relevant support document here: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01658899&lang=en&cc=us&taskId=135&prodSeriesId=3688868&prodTypeId=321957 ...but this did not work for me. My advice for folks is to upgrade to the newest available BIOS before trying tboot. Cheers, -Jon Wang, Shane wrote: > Great to hear that. > > Jon, when you say "Using F.09 will brick the laptop", I am wondering how your laptop can recover from the brick situation. Or, just remove the battery... you mentioned in the last email? That will help others. > > Thanks. > Shane > > Jonathan M. McCune wrote: > >> Hello list, >> >> A success story! >> >> I forgot to include intel_iommu=on on the kernel command line (and >> then to use a kernel which supports it). Summary: >> >> Laptop: HP 8530p >> BIOS Revision: F.0E >> tboot revision: changeset: 172:da3ebacc9b6d >> kernel: 2.6.30.6 with CONFIG_DMAR=yes >> grub: >> >> title tboot.hg + Ubuntu 9.04, kernel 2.6.30.6 >> root (hd0,1) >> kernel /tboot.gz logging=vga,memory,serial >> module /vmlinuz-2.6.30.6 root=/dev/sda3 ro intel_iommu=on >> module /initrd.img-2.6.30.6 >> module /GM45_PM45_SINIT_19.BIN >> boot >> >> This works! >> >> HOWEVER: Using BIOS revision F.09 (and I suspect, any earlier version) >> will BRICK THE LAPTOP. I did not try BIOS revision F.0C. >> >> Cheers, >> -Jon >> > > |
|
From: Wang, S. <sha...@in...> - 2009-09-11 02:00:41
|
Great to hear that. Jon, when you say "Using F.09 will brick the laptop", I am wondering how your laptop can recover from the brick situation. Or, just remove the battery... you mentioned in the last email? That will help others. Thanks. Shane Jonathan M. McCune wrote: > Hello list, > > A success story! > > I forgot to include intel_iommu=on on the kernel command line (and > then to use a kernel which supports it). Summary: > > Laptop: HP 8530p > BIOS Revision: F.0E > tboot revision: changeset: 172:da3ebacc9b6d > kernel: 2.6.30.6 with CONFIG_DMAR=yes > grub: > > title tboot.hg + Ubuntu 9.04, kernel 2.6.30.6 > root (hd0,1) > kernel /tboot.gz logging=vga,memory,serial > module /vmlinuz-2.6.30.6 root=/dev/sda3 ro intel_iommu=on > module /initrd.img-2.6.30.6 > module /GM45_PM45_SINIT_19.BIN > boot > > This works! > > HOWEVER: Using BIOS revision F.09 (and I suspect, any earlier version) > will BRICK THE LAPTOP. I did not try BIOS revision F.0C. > > Cheers, > -Jon |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-10 14:18:13
|
Hello list, A success story! I forgot to include intel_iommu=on on the kernel command line (and then to use a kernel which supports it). Summary: Laptop: HP 8530p BIOS Revision: F.0E tboot revision: changeset: 172:da3ebacc9b6d kernel: 2.6.30.6 with CONFIG_DMAR=yes grub: title tboot.hg + Ubuntu 9.04, kernel 2.6.30.6 root (hd0,1) kernel /tboot.gz logging=vga,memory,serial module /vmlinuz-2.6.30.6 root=/dev/sda3 ro intel_iommu=on module /initrd.img-2.6.30.6 module /GM45_PM45_SINIT_19.BIN boot This works! HOWEVER: Using BIOS revision F.09 (and I suspect, any earlier version) will BRICK THE LAPTOP. I did not try BIOS revision F.0C. Cheers, -Jon Jonathan M. McCune wrote: > Hi Shane, > > No change meant "fail." However, I am now trying with BIOS version > F.0E, and SENTER appears to work. I say "appears" because Linux doesn't > actually succeed in booting, and this laptop doesn't have a serial port > to capture the output. I'm using Ubuntu 9.04 with their kernel > 2.6.28-11-generic. > > title tboot.hg + Ubuntu 9.04, kernel 2.6.28-11-generic > root (hd0,1) > kernel /tboot.gz logging=vga,memory > module /vmlinuz-2.6.28-11-generic root=/dev/sda3 ro > module /initrd.img-2.6.28-11-generic > module /GM45_PM45_SINIT_19.BIN > boot > > The errors are to do with the SATA controller and with USB. I've been > playing with some BIOS settings which have been impacting the way in > which things fail. I'm planning to experiment further with these > settings and also try a newer kernel. Any suggestions are much appreciated. > > Cheers, > -Jon > > > > Wang, Shane wrote: >> Hi all, >> >> For Hal's question, I didn't get any message/hint to clear the flag and restore the laptop by removing the RTC battery. >> The flag should be in MSR register on the chipset. >> >> Jon, did you succeed to restore your laptop? Or, does "no change" mean "fail"? >> >> Shane >> >> Jonathan M. McCune wrote: >> >>> Hi Hal et al., >>> >>> When I had this problem on an 8530p, I tried the following >>> (unsuccessfully) to restore the machine to a state where it will boot: >>> >>> > 1. Remove memory on left slot (as shown in DIMM1.jpg) and restart >>> the unit. >>> >>> No change. >>> >>> > 2. Remove the memory on the right slot, replace it back and restart >>> the unit (keep the left slot still empty). >>> >>> No change. >>> >>> > 3. Replace with memory on the right slot with another one that has >>> a different frequency (e.g. if you have 800Mhz DIMM replace it with >>> 667Mhz one). Keep the left slot still empty. >>> >>> I don't have a DIMM of a different speed lying around. I have one >>> other model of HP laptop but it takes the identical stuff. I tried it >>> anyways. No change. >>> >>> > 4. Remove the RTC battery (will find it next to DIMMs) and let it >>> stay there for a while. After that connect it back and restart the >>> unit. >>> >>> Left DIMM still out. I left the battery out for a few minutes and >>> tried booting up with it removed. No change. I also removed the >>> CD-ROM drive and tried again. No change. >>> >>> I left the battery out for about half hour, then put it back in, then >>> tried booting up with the left DIMM still removed. No change. >>> >>> Cheers, >>> -Jon >>> >>> >>> Hal Finney wrote: >>> >>>> Thanks very much for the responses. Unfortunately I can't give you >>>> the >>>> BIOS version because the machine is a brick. I am at a conference >>>> this >>>> week so it may take a few days to get it fixed. >>>> >>>> The first time it broke I used the 20090330 version of tboot, with >>>> the latest SINIT downloaded from SourceForge. The second time, this >>>> past weekend, I believe I used tboot built from the mercurial tip, >>>> which I >>>> had downloaded moments before. >>>> >>>> I am not sure how to proceed after I get my laptop fixed. I can tell >>>> you what BIOS version is in the new one, but I will be hesitant to do >>>> another run of tboot to see if it breaks it again. Last time, they >>>> replaced the motherboard, so I don't expect that the new BIOS version >>>> will necessarily be the same as the one that broke. >>>> >>>> As far as the hang, I believe it occured immediately after the >>>> GETSEC[SENTER]. The display went blank. The one thing I noticed, at >>>> least the second time, is that the disk drive light was flickering in >>>> a smooth, uniform pattern. Maybe 30 times a second, just flickering >>>> on >>>> and off uniformly. This kind of worried me as I wondered if the >>>> failure mode was trashing my disk. After a few seconds, I pressed and >>>> held the power button to turn the laptop off. Trying to turn it back >>>> on led to the problem I described, where it repeatedly turns itself >>>> back off (and back on). >>>> >>>> One question, would you think that removing and replacing the RTC >>>> battery might clear enough internal state to let it boot? Any other >>>> interventions or resets that might be possible if I take the laptop >>>> apart somewhat? HP does have instructions to do so on the web site. >>>> >>>> Hal Finney >>>> >>>> On Mon, Aug 17, 2009 at 6:18 PM, Wang, Shane<sha...@in...> >>>> wrote: >>>> >>>>> Hi Hal, >>>>> >>>>> The reset behavior seems like it is due to the secret flag of TXT. >>>>> It looks like BIOS ACM does not clear the secret flag of TXT when >>>>> hang and reset happen. >>>>> >>>>> What version of SINIT and tboot are you using on that laptop? >>>>> What did you do to get hang? hang where? >>>>> >>>>> I am trying to find where the root cause is. >>>>> >>>>> Thanks. >>>>> Shane >>>>> >>>>> Hal Finney wrote: >>>>> >>>>>> I was traveling recently, and I wanted to do some experiments with >>>>>> TXT on the road, so I bought an HP laptop that supports the >>>>>> technology. It is an HP EliteBook 6930p. I got it set up with >>>>>> Linux and tboot, enabled TPM, VT and TXT, and tried booting tboot >>>>>> and a Linux kernel. >>>>>> >>>>>> Something went wrong. My laptop 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 was completely broken and useless. >>>>>> >>>>>> Fortunately, being new it was covered by HP's warranty. They >>>>>> talked me through the usual minor fixits on the phone, removing >>>>>> the disk and such, and nothing helped. They finally told me to >>>>>> take it to an authorized repair shop. The nearest one is 80 miles >>>>>> away so it was not super convenient, but I did it. Unfortunately >>>>>> it meant that I was not able to take the laptop on my trip and was >>>>>> not able to do my experiments. >>>>>> >>>>>> I got back this week and picked up my laptop from the repair shop. >>>>>> 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 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. >>>>>> >>>>>> I am a little worried about once again demanding that HP fix this >>>>>> machine under the terms of my warranty. I did not go into any >>>>>> detail about what I was doing when it broke the first time. In >>>>>> fact I thought it was probably just a defective machine; I did not >>>>>> necessarily connect it that much with tboot since I was just >>>>>> getting started with it and had only used it for an hour or so. >>>>>> But with the same thing happening twice now, it is clear that I am >>>>>> breaking it. And I am not running Windows, I am using experimental >>>>>> software, etc. Of course the machine is claimed to support TXT, so >>>>>> obviously it should not break from running tboot. But this is such >>>>>> a little-known and new technology that I'm sure only a few people >>>>>> at HP are familiar with it. I am not sure how to proceed with >>>>>> regard to the warranty. >>>>>> >>>>>> I wonder if anyone at HP reading this might be able to comment? It >>>>>> will not be good if HP laptops are turned into bricks by running >>>>>> tboot. >>>>>> >>>>>> Hal Finney >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports >>>>>> 2008 30-Day trial. Simplify your report design, integration and >>>>>> deployment - and focus on what you do best, core application >>>>>> coding. Discover what's new with Crystal Reports now. >>>>>> http://p.sf.net/sfu/bobj-july >>>>>> _______________________________________________ >>>>>> tboot-devel mailing list >>>>>> tbo...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>>>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day trial. Simplify your report design, integration and >>>> deployment - and focus on what you do best, core application coding. >>>> Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> tboot-devel mailing list >>>> tbo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>>> >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-09 16:18:23
|
Hi Shane, No change meant "fail." However, I am now trying with BIOS version F.0E, and SENTER appears to work. I say "appears" because Linux doesn't actually succeed in booting, and this laptop doesn't have a serial port to capture the output. I'm using Ubuntu 9.04 with their kernel 2.6.28-11-generic. title tboot.hg + Ubuntu 9.04, kernel 2.6.28-11-generic root (hd0,1) kernel /tboot.gz logging=vga,memory module /vmlinuz-2.6.28-11-generic root=/dev/sda3 ro module /initrd.img-2.6.28-11-generic module /GM45_PM45_SINIT_19.BIN boot The errors are to do with the SATA controller and with USB. I've been playing with some BIOS settings which have been impacting the way in which things fail. I'm planning to experiment further with these settings and also try a newer kernel. Any suggestions are much appreciated. Cheers, -Jon Wang, Shane wrote: > Hi all, > > For Hal's question, I didn't get any message/hint to clear the flag and restore the laptop by removing the RTC battery. > The flag should be in MSR register on the chipset. > > Jon, did you succeed to restore your laptop? Or, does "no change" mean "fail"? > > Shane > > Jonathan M. McCune wrote: > >> Hi Hal et al., >> >> When I had this problem on an 8530p, I tried the following >> (unsuccessfully) to restore the machine to a state where it will boot: >> >> > 1. Remove memory on left slot (as shown in DIMM1.jpg) and restart >> the unit. >> >> No change. >> >> > 2. Remove the memory on the right slot, replace it back and restart >> the unit (keep the left slot still empty). >> >> No change. >> >> > 3. Replace with memory on the right slot with another one that has >> a different frequency (e.g. if you have 800Mhz DIMM replace it with >> 667Mhz one). Keep the left slot still empty. >> >> I don't have a DIMM of a different speed lying around. I have one >> other model of HP laptop but it takes the identical stuff. I tried it >> anyways. No change. >> >> > 4. Remove the RTC battery (will find it next to DIMMs) and let it >> stay there for a while. After that connect it back and restart the >> unit. >> >> Left DIMM still out. I left the battery out for a few minutes and >> tried booting up with it removed. No change. I also removed the >> CD-ROM drive and tried again. No change. >> >> I left the battery out for about half hour, then put it back in, then >> tried booting up with the left DIMM still removed. No change. >> >> Cheers, >> -Jon >> >> >> Hal Finney wrote: >> >>> Thanks very much for the responses. Unfortunately I can't give you >>> the >>> BIOS version because the machine is a brick. I am at a conference >>> this >>> week so it may take a few days to get it fixed. >>> >>> The first time it broke I used the 20090330 version of tboot, with >>> the latest SINIT downloaded from SourceForge. The second time, this >>> past weekend, I believe I used tboot built from the mercurial tip, >>> which I >>> had downloaded moments before. >>> >>> I am not sure how to proceed after I get my laptop fixed. I can tell >>> you what BIOS version is in the new one, but I will be hesitant to do >>> another run of tboot to see if it breaks it again. Last time, they >>> replaced the motherboard, so I don't expect that the new BIOS version >>> will necessarily be the same as the one that broke. >>> >>> As far as the hang, I believe it occured immediately after the >>> GETSEC[SENTER]. The display went blank. The one thing I noticed, at >>> least the second time, is that the disk drive light was flickering in >>> a smooth, uniform pattern. Maybe 30 times a second, just flickering >>> on >>> and off uniformly. This kind of worried me as I wondered if the >>> failure mode was trashing my disk. After a few seconds, I pressed and >>> held the power button to turn the laptop off. Trying to turn it back >>> on led to the problem I described, where it repeatedly turns itself >>> back off (and back on). >>> >>> One question, would you think that removing and replacing the RTC >>> battery might clear enough internal state to let it boot? Any other >>> interventions or resets that might be possible if I take the laptop >>> apart somewhat? HP does have instructions to do so on the web site. >>> >>> Hal Finney >>> >>> On Mon, Aug 17, 2009 at 6:18 PM, Wang, Shane<sha...@in...> >>> wrote: >>> >>>> Hi Hal, >>>> >>>> The reset behavior seems like it is due to the secret flag of TXT. >>>> It looks like BIOS ACM does not clear the secret flag of TXT when >>>> hang and reset happen. >>>> >>>> What version of SINIT and tboot are you using on that laptop? >>>> What did you do to get hang? hang where? >>>> >>>> I am trying to find where the root cause is. >>>> >>>> Thanks. >>>> Shane >>>> >>>> Hal Finney wrote: >>>> >>>>> I was traveling recently, and I wanted to do some experiments with >>>>> TXT on the road, so I bought an HP laptop that supports the >>>>> technology. It is an HP EliteBook 6930p. I got it set up with >>>>> Linux and tboot, enabled TPM, VT and TXT, and tried booting tboot >>>>> and a Linux kernel. >>>>> >>>>> Something went wrong. My laptop 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 was completely broken and useless. >>>>> >>>>> Fortunately, being new it was covered by HP's warranty. They >>>>> talked me through the usual minor fixits on the phone, removing >>>>> the disk and such, and nothing helped. They finally told me to >>>>> take it to an authorized repair shop. The nearest one is 80 miles >>>>> away so it was not super convenient, but I did it. Unfortunately >>>>> it meant that I was not able to take the laptop on my trip and was >>>>> not able to do my experiments. >>>>> >>>>> I got back this week and picked up my laptop from the repair shop. >>>>> 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 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. >>>>> >>>>> I am a little worried about once again demanding that HP fix this >>>>> machine under the terms of my warranty. I did not go into any >>>>> detail about what I was doing when it broke the first time. In >>>>> fact I thought it was probably just a defective machine; I did not >>>>> necessarily connect it that much with tboot since I was just >>>>> getting started with it and had only used it for an hour or so. >>>>> But with the same thing happening twice now, it is clear that I am >>>>> breaking it. And I am not running Windows, I am using experimental >>>>> software, etc. Of course the machine is claimed to support TXT, so >>>>> obviously it should not break from running tboot. But this is such >>>>> a little-known and new technology that I'm sure only a few people >>>>> at HP are familiar with it. I am not sure how to proceed with >>>>> regard to the warranty. >>>>> >>>>> I wonder if anyone at HP reading this might be able to comment? It >>>>> will not be good if HP laptops are turned into bricks by running >>>>> tboot. >>>>> >>>>> Hal Finney >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports >>>>> 2008 30-Day trial. Simplify your report design, integration and >>>>> deployment - and focus on what you do best, core application >>>>> coding. Discover what's new with Crystal Reports now. >>>>> http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> tboot-devel mailing list >>>>> tbo...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>>>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and >>> deployment - and focus on what you do best, core application coding. >>> Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> tboot-devel mailing list >>> tbo...@li... >>> https://lists.sourceforge.net/lists/listinfo/tboot-devel >>> > > > |