[tboot-devel] Fix a bug in hash_module function

2018-02-26 Thread shiwan...@gohighsec.com 
Hi,

There is a bug in hash_module function.
My machine is tpm2.0. As I have no machine of tpm1.2, I don't know whether it 
has the same issue for the machine of tpm1.2.
When I set extpol=agile in the command line of tboot, module 1 can't be 
measured.
Below is the related section of the TBOOT output:

TBOOT: verifying policy 
TBOOT: all modules are verified
TBOOT: pre_k_s3_state:
TBOOT:   vtd_pmr_lo_base: 0x0
TBOOT:   vtd_pmr_lo_size: 0x79e0
TBOOT:   vtd_pmr_hi_base: 0x1
TBOOT:   vtd_pmr_hi_size: 0xf8000
TBOOT:   pol_hash: bc d9 65 82 9e 76 20 45 d6 96 bf eb 03 40 1f ba 66 ad d4 b1 
29 92 f6 30 11 3a 1f e2 d6 3a 0f 15 
TBOOT:   VL measurements:
TBOOT: PCR 17 (alg count 3):
TBOOT: alg 0004: ca 96 de 41 2b 4e 8c 06 2e 57 0d 30 13 d2 fc cb 4b 
20 25 0a 
TBOOT: alg 000B: 27 80 8f 64 e6 38 39 82 cd 3b cc 10 cf cb 34 57 c0 
b6 5f 46 5f 77 9d 89 b6 68 83 9e af 26 3a 67 
TBOOT: alg 0012: f6 3d d4 02 06 3f 6c 5b b2 69 91 df 68 e3 90 c5 2f 
0a 97 d6 8c b6 4b ff 4b 9e fb 72 fa ec 39 cd 
TBOOT: PCR 18 (alg count 3):
TBOOT: alg 0004: ca 96 de 41 2b 4e 8c 06 2e 57 0d 30 13 d2 fc cb 4b 
20 25 0a 
TBOOT: alg 000B: 27 80 8f 64 e6 38 39 82 cd 3b cc 10 cf cb 34 57 c0 
b6 5f 46 5f 77 9d 89 b6 68 83 9e af 26 3a 67 
TBOOT: alg 0012: f6 3d d4 02 06 3f 6c 5b b2 69 91 df 68 e3 90 c5 2f 
0a 97 d6 8c b6 4b ff 4b 9e fb 72 fa ec 39 cd 
TBOOT: PCR 17 (alg count 3):
TBOOT: alg 0004: f9 6a eb ea 73 09 90 1f 2a 29 ff 08 95 7d 55 c6 0a 
4a fc 40 
TBOOT: alg 000B: f9 8e 31 73 54 36 76 28 76 63 2a 20 93 ab 9c 7a 92 
9d a9 8f 77 45 0b fc 2f d0 d7 ba 51 d3 50 08 
TBOOT: alg 0012: 40 3a 7e fb ed 38 01 21 00 aa 08 f2 0d 1c 8e 8f fc 
52 7e 96 30 5f d0 e2 a2 78 4a a6 f2 1a d0 19 

But when I modify the size of buf in hash_module function, it works normally.
Below is the related section of the TBOOT output:

TBOOT: verifying policy 
TBOOT: verifying module "
root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv
=centos/swap rhgb quiet rd.shell=0 tpm_tis.force=1 tpm_tis.interrupts=0 intel_io
mmu=on"...
TBOOT: verifying module ""...
TBOOT: all modules are verified
TBOOT: pre_k_s3_state:
TBOOT:   vtd_pmr_lo_base: 0x0
TBOOT:   vtd_pmr_lo_size: 0x79e0
TBOOT:   vtd_pmr_hi_base: 0x1
TBOOT:   vtd_pmr_hi_size: 0xf8000
TBOOT:   pol_hash: bc d9 65 82 9e 76 20 45 d6 96 bf eb 03 40 1f ba 66 ad d4 b1 
29 92 f6 30 11 3a 1f e2 d6 3a 0f 15 
TBOOT:   VL measurements:
TBOOT: PCR 17 (alg count 3):
TBOOT: alg 0004: ca 96 de 41 2b 4e 8c 06 2e 57 0d 30 13 d2 fc cb 4b 
20 25 0a 
TBOOT: alg 000B: 27 80 8f 64 e6 38 39 82 cd 3b cc 10 cf cb 34 57 c0 
b6 5f 46 5f 77 9d 89 b6 68 83 9e af 26 3a 67 
TBOOT: alg 0012: f6 3d d4 02 06 3f 6c 5b b2 69 91 df 68 e3 90 c5 2f 
0a 97 d6 8c b6 4b ff 4b 9e fb 72 fa ec 39 cd 
TBOOT: PCR 18 (alg count 3):
TBOOT: alg 0004: ca 96 de 41 2b 4e 8c 06 2e 57 0d 30 13 d2 fc cb 4b 
20 25 0a 
TBOOT: alg 000B: 27 80 8f 64 e6 38 39 82 cd 3b cc 10 cf cb 34 57 c0 
b6 5f 46 5f 77 9d 89 b6 68 83 9e af 26 3a 67 
TBOOT: alg 0012: f6 3d d4 02 06 3f 6c 5b b2 69 91 df 68 e3 90 c5 2f 
0a 97 d6 8c b6 4b ff 4b 9e fb 72 fa ec 39 cd 
TBOOT: PCR 17 (alg count 3):
TBOOT: alg 0004: f9 6a eb ea 73 09 90 1f 2a 29 ff 08 95 7d 55 c6 0a 
4a fc 40 
TBOOT: alg 000B: f9 8e 31 73 54 36 76 28 76 63 2a 20 93 ab 9c 7a 92 
9d a9 8f 77 45 0b fc 2f d0 d7 ba 51 d3 50 08 
TBOOT: alg 0012: 40 3a 7e fb ed 38 01 21 00 aa 08 f2 0d 1c 8e 8f fc 
52 7e 96 30 5f d0 e2 a2 78 4a a6 f2 1a d0 19 
TBOOT: PCR 17 (alg count 3):
TBOOT: alg 0004: d4 ff a8 7f 7f 12 02 7f e8 67 73 89 17 ab 33 58 1e 
85 48 ea 
TBOOT: alg 000B: 42 61 23 70 e1 ca 80 87 a6 7f 26 21 a2 c2 bf 61 d3 
73 63 65 aa 9d 35 4f a1 cd 73 64 ec cf cb 0f 
TBOOT: alg 0012: 75 0f d0 fb 27 55 92 a5 36 b3 d8 eb 27 a6 43 98 c4 
08 22 59 c7 9a 88 f5 01 8e 80 ce 6a eb 90 9e 


Signed-off-by: Shi Wangyi

diff -r 59086d17f60d -r 09d977294ceb tboot/common/policy.c
--- a/tboot/common/policy.c Sun Feb 18 08:08:30 2018 -0800
+++ b/tboot/common/policy.c Sun Feb 25 20:47:51 2018 -0500
@@ -461,7 +461,7 @@
 return true;
 }
 
-uint8_t buf[128];
+uint8_t buf[64];
 
 if ( !tpm_fp->hash(tpm, 2, base, size, _hl) )
 return false;


Thanks,
Wangyi
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TXT SINIT ACM failure on power-cycling node

2018-02-26 Thread Rich Persaud 
These are very likely to be OEM BIOS bugs - if you escalate to your server OEM, 
they can create fixes.  We started testing TXT on enterprise clients almost 10 
years ago.  It took a while for OEMs (Dell, Lenovo, HP) to roll out TXT fixes, 
but they all did eventually.  Server and workstation TXT may need a similar 
test-fix-test cycle.

OEMs sometimes don't have an easy way to repro TXT issues, which is why the 
industry needs an open-source test suite for SRTM and DRTM.  Now that Windows 
10 is adding DRTM features, OEM testing of TXT will hopefully improve.  Each 
separate customer report will help TXT fixes to be prioritized, especially when 
the issue is easy to repro.

Rich

> On Feb 26, 2018, at 16:59, Jan Schermer  wrote:
> 
> My HP z240 workstation occassionaly refuses to boot at all if I yank out the 
> power cable while in TXT mode.
> Solution: leave power disconnected for >5 minutes, then reset BIOS (yes, 
> really).
> 
> I had similiar issues with Lenovo system.
> 
> I don’t think OEMs test anything...
> 
> Jan
> 
>> On 26 Feb 2018, at 22:52, Rich Persaud  wrote:
>> 
>> On TXT-enabled vPro client devices (e.g. Dell 7040) that have been tested 
>> with OpenXT, Xen and OpenEmbedded measured launch [1], if you use the 
>> hardware power switch to perform a non-graceful shutdown of an operating 
>> system that was booted with TXT, the following will occur:
>> 
>>  (a)  User presses hardware power button to turn on the device.
>>  (b)  Device powers on for a few seconds, then powers back off (TXT reset).
>>  (c)  User presses hardware power button to turn on the device.
>>  (d)  Device powers on normally, OS successfully completes measured launch.
>> 
>> Your issue sounds like a device-specific OEM BIOS defect, have you tried 
>> contacting the OEM? Does it happen on servers from a different OEM? Which 
>> CPU generation?
>> 
>> If there is interest in collaborating on OE/Yocto layers for TXT, TPM, 
>> SecureBoot, we can arrange a conference call or ELC BoF.
>> 
>> Rich
>> 
>> [1] 
>> https://openxt.atlassian.net/wiki/spaces/DC/pages/81035265/Measured+Launch+SRTM+and+DRTM
>> 
>> 
>>> On Feb 22, 2018, at 15:54, Nasim, Kam  wrote:
>>> 
>>> Hi folks,
>>>  
>>> We’ve been trying to integrate Tboot in our Boot sequence and have it 
>>> working fine for the most part. We specify a default ANY Launch Control 
>>> Policy (LCP) as main intention is to capture boot measurements in TPM PCRs 
>>> and not really enforce a boot halt action.
>>>  
>>> I noticed that when I power cycle the node or any other kind of 
>>> non-graceful restart, it stops at the Boot menu with the following Error:
>>>  
>>> Message
>>> An issue is observed in the previous invocation of TXT SINIT Authenticated 
>>> Code Module (ACM) because the TXT information stored in the TPM chip may be 
>>> corrupted. 
>>> Detailed Description
>>> An issue in observed in the previous invocation of TXT SINIT Authenticated 
>>> Code Module (ACM) because the TXT information stored in the TPM chip may be 
>>> corrupted. 
>>> Recommended Response Action
>>> Do one of the following: 1) Update the BIOS firmware. 2) Go to System Setup 
>>> > System Security page, click the "Clear" option under TPM command. Restart 
>>> the system, go to System Setup > System Security page, click the "Activate" 
>>> option under TPM command, and then enable TXT.
>>>  
>>>  
>>> I am able to continue past this but was wondering if there is any way to 
>>> disable this. We don’t want to be manually doing this for all of our 
>>> servers after a Power Cycle event.
>>>  
>>> Have others seen this? Is this a form of corruption in the ACM? How do I 
>>> flush that state on a power cycle?
>>>  
>>>  
>>> Thanks,
>>> Kam
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> tboot-devel mailing list
>>> tboot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! 
>> http://sdm.link/slashdot___
>> tboot-devel mailing list
>> tboot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] TXT SINIT ACM failure on power-cycling node

2018-02-26 Thread Jan Schermer 
My HP z240 workstation occassionaly refuses to boot at all if I yank out the 
power cable while in TXT mode.
Solution: leave power disconnected for >5 minutes, then reset BIOS (yes, 
really).

I had similiar issues with Lenovo system.

I don’t think OEMs test anything...

Jan

> On 26 Feb 2018, at 22:52, Rich Persaud  wrote:
> 
> On TXT-enabled vPro client devices (e.g. Dell 7040) that have been tested 
> with OpenXT, Xen and OpenEmbedded measured launch [1], if you use the 
> hardware power switch to perform a non-graceful shutdown of an operating 
> system that was booted with TXT, the following will occur:
> 
>  (a)  User presses hardware power button to turn on the device.
>  (b)  Device powers on for a few seconds, then powers back off (TXT reset).
>  (c)  User presses hardware power button to turn on the device.
>  (d)  Device powers on normally, OS successfully completes measured launch.
> 
> Your issue sounds like a device-specific OEM BIOS defect, have you tried 
> contacting the OEM? Does it happen on servers from a different OEM? Which CPU 
> generation?
> 
> If there is interest in collaborating on OE/Yocto layers for TXT, TPM, 
> SecureBoot, we can arrange a conference call or ELC BoF.
> 
> Rich
> 
> [1] 
> https://openxt.atlassian.net/wiki/spaces/DC/pages/81035265/Measured+Launch+SRTM+and+DRTM
>  
> 
> 
> 
> On Feb 22, 2018, at 15:54, Nasim, Kam  > wrote:
> 
>> Hi folks,
>>  
>> We’ve been trying to integrate Tboot in our Boot sequence and have it 
>> working fine for the most part. We specify a default ANY Launch Control 
>> Policy (LCP) as main intention is to capture boot measurements in TPM PCRs 
>> and not really enforce a boot halt action.
>>  
>> I noticed that when I power cycle the node or any other kind of non-graceful 
>> restart, it stops at the Boot menu with the following Error:
>>  
>> Message
>> An issue is observed in the previous invocation of TXT SINIT Authenticated 
>> Code Module (ACM) because the TXT information stored in the TPM chip may be 
>> corrupted. 
>> Detailed Description
>> An issue in observed in the previous invocation of TXT SINIT Authenticated 
>> Code Module (ACM) because the TXT information stored in the TPM chip may be 
>> corrupted. 
>>  <>Recommended Response Action
>> Do one of the following: 1) Update the BIOS firmware. 2) Go to System Setup 
>> > System Security page, click the "Clear" option under TPM command. Restart 
>> the system, go to System Setup > System Security page, click the "Activate" 
>> option under TPM command, and then enable TXT.
>>  
>>  
>> I am able to continue past this but was wondering if there is any way to 
>> disable this. We don’t want to be manually doing this for all of our servers 
>> after a Power Cycle event.
>>  
>> Have others seen this? Is this a form of corruption in the ACM? How do I 
>> flush that state on a power cycle?
>>  
>>  
>> Thanks,
>> Kam
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org ! 
>> http://sdm.link/slashdot 
>> ___
>> tboot-devel mailing list
>> tboot-devel@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel 
>> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org ! 
> http://sdm.link/slashdot___ 
> 
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/tboot-devel 
> 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel