tboot-devel — Developer support

[tboot-devel] binaries in mercurial?

[Timo L. <tim...@ik...>]

Hi,

changeset:   620:805285ab8469
user:        Lukasz Hawrylko <luk...@in...>
date:        Fri Nov 13 16:09:33 2020 +0100
summary:     Move old lcptool to deprecated folder and exclude from build

seems to add some binaries to mercurial version control:

$ hg clone http://hg.code.sf.net/p/tboot/code 
tboot-code
requesting all changes
adding changesets
adding manifests
adding file changes
added 620 changesets with 2372 changes to 497 files (+1 heads)
new changesets cedd93279188:cc489ff0c783
updating to branch default
403 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ file tboot-code/deprecated/lcptools/lcp_writepol
tboot-code/deprecated/lcptools/lcp_writepol: ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked, interpreter 
/lib64/ld-linux-x86-64.so.2, BuildID[sha1]=403efd37304c2d0ca9830ec60c1115fd9d76787c, for GNU/Linux 3.2.0, not stripped

This is probably accidental?

The exact Debian lintian errors that caused me to spot this are

E: tboot source: source-is-missing deprecated/lcptools/lcp_crtpconf
E: tboot source: source-is-missing deprecated/lcptools/lcp_crtpol
E: tboot source: source-is-missing deprecated/lcptools/lcp_mlehash
E: tboot source: source-is-missing deprecated/lcptools/lcp_readpol
E: tboot source: source-is-missing deprecated/lcptools/lcp_writepol
E: tboot source: source-is-missing deprecated/lcptools/tpmnv_defindex
E: tboot source: source-is-missing deprecated/lcptools/tpmnv_getcap
E: tboot source: source-is-missing deprecated/lcptools/tpmnv_lock
E: tboot source: source-is-missing deprecated/lcptools/tpmnv_relindex
E: tboot source: source-is-missing deprecated/lcptools/trousers_dep


-Timo

Re: [tboot-devel] tboot and tpm1.2

[Lukasz H. <luk...@li...>]

Hi Jerry

On Wed, 2020-11-11 at 15:15 -0700, Jerry Snitselaar wrote:
> Would it be possible, or has any thought been given to being able to
> build tboot with only tpm2.0 support? We have started to deprecate
> support for tpm1.2, and eventually would like to just support
> tpm2.0. One possible stopping point to accomplishing that is the
> dependency tboot has on trousers. I don't know much about tboot,
> so I don't know if that is something that could be possible in
> the future.

TBOOT itself does not depend on TrouSerS. This library is only required
to build policy generation tool - lcptools. If you call 'make' inside
tboot directory, not from repository root, you don't have to install
TrouSerS.

There is a new version of that tool - lcptools-v2 that does not depend
on TrouSerS. In next TBOOT release I am going to mark lcptools as
depreciated and exclude it from building process, so there will be no
dependency on TrouSerS any more in TBOOT.

Thanks,
Lukasz

[tboot-devel] tboot and tpm1.2

[Jerry S. <jsn...@re...>]

Would it be possible, or has any thought been given to being able to
build tboot with only tpm2.0 support? We have started to deprecate
support for tpm1.2, and eventually would like to just support
tpm2.0. One possible stopping point to accomplishing that is the
dependency tboot has on trousers. I don't know much about tboot,
so I don't know if that is something that could be possible in
the future.

Thanks,
Jerry

Re: [tboot-devel] tboot fails to build after applying changeset: 599:d4c520cbea8c

[tony c. <tc...@re...>]

> Message: 2
> Date: Wed, 21 Oct 2020 09:45:02 +0200
> From: Lukasz Hawrylko <luk...@li...>
> To: tony camuso <tc...@re...>,
> 	tbo...@li...
> Subject: Re: [tboot-devel] tboot fails to build after applying
> 	changeset: 599:d4c520cbea8c
> Message-ID:
> 	<969...@li...>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi Tony
> 
> On Tue, 2020-10-20 at 12:48 -0400, tony camuso wrote:
>> I'm applying the following patches from the hg repo.
>>
>> 0001-Fix-CFLAGS-passing-to-recursive-makefiles.patch
>> 0002-Install-man-pages-only-for-tools-that-are-installed.patch
>> 0003-Add-man-pages-for-all-installed-commands.patch
>> 0004-Fix-spelling-errors.patch
>> 0005-All-TXT-tools-now-have-txt-prefix.patch
>> 0006-Update-man-pages-for-txt-tools.patch
>> 0007-Clarify-license-issues.patch
>> 0008-Fix-issues-reported-by-Coverity-Scan.patch
>> 0009-Fix-man-page-syntax-error.patch
>> 0010-Ensure-txt-acminfo-does-not-print-false-information-.patch
>> 0011-Do-not-try-to-read-EFI-mem-map-when-booted-with-mult.patch
>> 0012-Use-SHA1-based-default-policy-when-TPM1.2-is-detecte.patch
>> 0013-Unmask-NMI-after-returning-from-SINIT.patch
>> 0014-Update-GRUB-scripts-to-use-multiboot2-only.patch
>> 0015-Update-lcptools-v2-to-meet-requirements-from-MLE-DG-.patch
>> 0016-Implement-SM2-signing-and-SM2-signature-verification.patch
>>
>> After applying this patch ...
>> changeset:   599:d4c520cbea8c
>> user:        Mateusz Mowka <mat...@in...>
>> date:        Fri Jul 17 14:19:31 2020 +0200
>> summary:     Implement SM2 signing and SM2 signature verification.
>>
>> I get the following build errors. What am I missing?
>>
>> lcputils.c: In function 'verify_ec_signature':
>> lcputils.c:730:19: error: 'NID_sm2' undeclared (first use in this function)
>>            curveId = NID_sm2;
>>                      ^
>> lcputils.c:730:19: note: each undeclared identifier is reported only once for each function it appears in
>> lcputils.c:731:9: error: implicit declaration of function 'EVP_sm3' [-Werror=implicit-function-declaration]
>>            mdtype = EVP_sm3();
>>            ^
> 
> What is your OpenSSL version? These functions should be available in
> OpenSSL since 1.1.1 version.
> 
> Thanks,
> Lukasz
> 

OK, that was it.
$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

I don't see that problem with ..
OpenSSL 1.1.1g FIPS  21 Apr 2020

THANKS!

Re: [tboot-devel] tboot fails to build after applying changeset: 599:d4c520cbea8c

[Lukasz H. <luk...@li...>]

Hi Tony

On Tue, 2020-10-20 at 12:48 -0400, tony camuso wrote:
> I'm applying the following patches from the hg repo.
> 
> 0001-Fix-CFLAGS-passing-to-recursive-makefiles.patch
> 0002-Install-man-pages-only-for-tools-that-are-installed.patch
> 0003-Add-man-pages-for-all-installed-commands.patch
> 0004-Fix-spelling-errors.patch
> 0005-All-TXT-tools-now-have-txt-prefix.patch
> 0006-Update-man-pages-for-txt-tools.patch
> 0007-Clarify-license-issues.patch
> 0008-Fix-issues-reported-by-Coverity-Scan.patch
> 0009-Fix-man-page-syntax-error.patch
> 0010-Ensure-txt-acminfo-does-not-print-false-information-.patch
> 0011-Do-not-try-to-read-EFI-mem-map-when-booted-with-mult.patch
> 0012-Use-SHA1-based-default-policy-when-TPM1.2-is-detecte.patch
> 0013-Unmask-NMI-after-returning-from-SINIT.patch
> 0014-Update-GRUB-scripts-to-use-multiboot2-only.patch
> 0015-Update-lcptools-v2-to-meet-requirements-from-MLE-DG-.patch
> 0016-Implement-SM2-signing-and-SM2-signature-verification.patch
> 
> After applying this patch ...
> changeset:   599:d4c520cbea8c
> user:        Mateusz Mowka <mat...@in...>
> date:        Fri Jul 17 14:19:31 2020 +0200
> summary:     Implement SM2 signing and SM2 signature verification.
> 
> I get the following build errors. What am I missing?
> 
> lcputils.c: In function 'verify_ec_signature':
> lcputils.c:730:19: error: 'NID_sm2' undeclared (first use in this function)
>           curveId = NID_sm2;
>                     ^
> lcputils.c:730:19: note: each undeclared identifier is reported only once for each function it appears in
> lcputils.c:731:9: error: implicit declaration of function 'EVP_sm3' [-Werror=implicit-function-declaration]
>           mdtype = EVP_sm3();
>           ^

What is your OpenSSL version? These functions should be available in
OpenSSL since 1.1.1 version.

Thanks,
Lukasz

[tboot-devel] tboot fails to build after applying changeset: 599:d4c520cbea8c

[tony c. <tc...@re...>]

I'm applying the following patches from the hg repo.

0001-Fix-CFLAGS-passing-to-recursive-makefiles.patch
0002-Install-man-pages-only-for-tools-that-are-installed.patch
0003-Add-man-pages-for-all-installed-commands.patch
0004-Fix-spelling-errors.patch
0005-All-TXT-tools-now-have-txt-prefix.patch
0006-Update-man-pages-for-txt-tools.patch
0007-Clarify-license-issues.patch
0008-Fix-issues-reported-by-Coverity-Scan.patch
0009-Fix-man-page-syntax-error.patch
0010-Ensure-txt-acminfo-does-not-print-false-information-.patch
0011-Do-not-try-to-read-EFI-mem-map-when-booted-with-mult.patch
0012-Use-SHA1-based-default-policy-when-TPM1.2-is-detecte.patch
0013-Unmask-NMI-after-returning-from-SINIT.patch
0014-Update-GRUB-scripts-to-use-multiboot2-only.patch
0015-Update-lcptools-v2-to-meet-requirements-from-MLE-DG-.patch
0016-Implement-SM2-signing-and-SM2-signature-verification.patch

After applying this patch ...
changeset:   599:d4c520cbea8c
user:        Mateusz Mowka <mat...@in...>
date:        Fri Jul 17 14:19:31 2020 +0200
summary:     Implement SM2 signing and SM2 signature verification.

I get the following build errors. What am I missing?

lcputils.c: In function 'verify_ec_signature':
lcputils.c:730:19: error: 'NID_sm2' undeclared (first use in this function)
          curveId = NID_sm2;
                    ^
lcputils.c:730:19: note: each undeclared identifier is reported only once for each function it appears in
lcputils.c:731:9: error: implicit declaration of function 'EVP_sm3' [-Werror=implicit-function-declaration]
          mdtype = EVP_sm3();
          ^
lcputils.c:731:16: error: assignment makes pointer from integer without a cast [-Werror]
          mdtype = EVP_sm3();
                 ^
lcputils.c:772:5: error: implicit declaration of function 'EVP_MD_CTX_new' [-Werror=implicit-function-declaration]
      mctx = EVP_MD_CTX_new();
      ^
lcputils.c:772:10: error: assignment makes pointer from integer without a cast [-Werror]
      mctx = EVP_MD_CTX_new();
           ^
lcputils.c:779:9: error: implicit declaration of function 'EVP_PKEY_set_alias_type' [-Werror=implicit-function-declaration]
          result = EVP_PKEY_set_alias_type(evp_key, EVP_PKEY_SM2);
          ^
lcputils.c:779:51: error: 'EVP_PKEY_SM2' undeclared (first use in this function)
          result = EVP_PKEY_set_alias_type(evp_key, EVP_PKEY_SM2);
                                                    ^
lcputils.c:792:9: error: implicit declaration of function 'EVP_PKEY_CTX_set1_id' [-Werror=implicit-function-declaration]
          result = EVP_PKEY_CTX_set1_id(pctx, SM2_ID, SM2_ID_LEN);
          ^
lcputils.c:798:5: error: implicit declaration of function 'EVP_MD_CTX_set_pkey_ctx' [-Werror=implicit-function-declaration]
      EVP_MD_CTX_set_pkey_ctx(mctx, pctx);
      ^
lcputils.c: In function 'ec_sign_data':
lcputils.c:889:10: error: assignment makes pointer from integer without a cast [-Werror]
      mctx = EVP_MD_CTX_new();
           ^
lcputils.c:919:51: error: 'EVP_PKEY_SM2' undeclared (first use in this function)
          result = EVP_PKEY_set_alias_type(evp_key, EVP_PKEY_SM2);
                                                    ^
lcputils.c:942:9: error: passing argument 3 of 'EVP_DigestSignInit' makes pointer from integer without a cast [-Werror]
          result = EVP_DigestSignInit(mctx, &pctx, EVP_sm3(), NULL, evp_key);
          ^
In file included from /usr/include/openssl/x509.h:73:0,
                  from /usr/include/openssl/engine.h:99,
                  from lcputils.c:46:
/usr/include/openssl/evp.h:660:5: note: expected 'const struct EVP_MD *' but argument is of type 'int'
  int EVP_DigestSignInit(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx,
      ^
lcputils.c:985:5: error: implicit declaration of function 'ECDSA_SIG_get0_r' [-Werror=implicit-function-declaration]
      sig_r = ECDSA_SIG_get0_r(ecdsa_sig);
      ^
lcputils.c:985:11: error: assignment makes pointer from integer without a cast [-Werror]
      sig_r = ECDSA_SIG_get0_r(ecdsa_sig);
            ^
lcputils.c:986:5: error: implicit declaration of function 'ECDSA_SIG_get0_s' [-Werror=implicit-function-declaration]
      sig_s = ECDSA_SIG_get0_s(ecdsa_sig);
      ^
lcputils.c:986:11: error: assignment makes pointer from integer without a cast [-Werror]
      sig_s = ECDSA_SIG_get0_s(ecdsa_sig);
            ^
lcputils.c: In function 'der_encode_sig_comps':
lcputils.c:1274:5: error: implicit declaration of function 'ECDSA_SIG_set0' [-Werror=implicit-function-declaration]
      if (!ECDSA_SIG_set0(sig, r, s)) {
      ^
hash.c: In function 'hash_buffer':
hash.c:124:9: error: implicit declaration of function 'EVP_sm3' [-Werror=implicit-function-declaration]
          md = EVP_sm3();
          ^
hash.c:124:12: error: assignment makes pointer from integer without a cast [-Werror]
          md = EVP_sm3();
             ^

[tboot-devel] tboot now in Debian

[Timo L. <tim...@ik...>]

Hi,

tboot is now in Debian unstable: https://tracker.debian.org/pkg/tboot

If you need a backport for Debian 10, please let me know.

As explained in

https://salsa.debian.org/debian/tboot/-/blob/master/debian/README.Debian

you cannot yet use this with normal kernel packages as they lack 
CONFIG_INTEL_TXT=y:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960195

-Timo

Re: [tboot-devel] "no LCP module found" on Getac X500 G3

[Briggs, K. 1 <kev...@lm...>]

Hi Olivier,

 

Is your system hanging or resetting after:

 

                   TBOOT: executing GETSEC[SENTER]...

 

I've experienced very similar issues with a large quantity of Getac laptops,
TBOOT, and RHEL.  I don't see it in your log output, but check your
TXT.ERRORCODE register value, and use Intel's error code mappings to gain
more information. I believe this is proved in the zips from their website
when downloading a SINIT ACM.

 

In my case, I consistently saw errors related to an invalid bootguard
profile.  After much debugging and communications with Getac, the issue
turned out to be in firmware/hardware, and all laptops needed to be shipped
back and repaired by Getac.

 

Also, I don't see it mentioned often online and in various resources, but it
should be noted that LCP and VLP are optional features.  The errors in
txt-stat output relating to failure to read VLP/LCP from NVRAM are by no
means fatal.  In fact, even in your log output, you can see: ".failed to
read policy from TPM NV, using default.", and below that, it probably says
something like: "..policy_type: TB_POLTYPE_CONT_NON_FATAL".

 

That of course isn't to say LCP/VLP are not useful features, but they are
optional, and if you are for instance only intending to do remote
attestation you may not even need them depending on how your system is
designed.  You can still TBOOT, create attestation keys, generate quotes,
attest remotely to a verifier, and other things without ever using LCP/VLP.
My point here is that I think it is unlikely that the LCP is the source of
your issue.

 

Kevin

 

From: LE ROY Olivier - Contractor <oli...@ex...> 
Sent: Friday, September 4, 2020 5:29 AM
To: tbo...@li...
Subject: EXTERNAL: [tboot-devel] "no LCP module found" on Getac X500 G3

 

I have a Getac X500 G3 that I am trying to get TBOOT working on under a
CentOS 7.7 OS with TBOOT 1.9.11. The TBOOT startup, without any policy,
looks as follows:

TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: *********************** TBOOT ***********************
TBOOT:    2019-11-25 16:00 +0200 1.9.11
TBOOT: *****************************************************
TBOOT: command line: extpol=sha256 logging=serial,memory
...
TBOOT: TXT chipset and all needed capabilities present
...
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:      ACM info_table version mismatch (6)
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
TBOOT: processor family/model/stepping: 0x906e9
TBOOT: platform id: 0x14000000000000
TBOOT:      1 ACM chipset id entries:
TBOOT:          vendor: 0x8086, device: 0xb006, flags: 0x1, revision: 0x1,
extended: 0x0
TBOOT:      4 ACM processor id entries:
TBOOT:          fms: 0x406e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT:          fms: 0x506e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT:          fms: 0x806e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
TBOOT:          fms: 0x906e0, fms_mask: 0xfff3ff0, platform_id: 0x0,
platform_mask: 0x0
...
TBOOT: SINIT matches platform
...
TBOOT: AC mod base alignment OK
TBOOT: AC mod size OK

...
TBOOT: reading Verified Launch Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01200001 in TPM NV
TBOOT:     :reading failed
TBOOT: reading Launch Control Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01400001 in TPM NV
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:
...
TBOOT: executing GETSEC[SENTER]...

 

I tried to implement a LCP @ 0x01400001 and a VLP @ 0x01200001. These 2
policies were known to work on same OS but different platform (Supermicro).

For LCP, I have the following error:


reading Launch Control Policy from TPM NV...
TBOOT:     :70 bytes read
TBOOT: in unwrap_lcp_policy
TBOOT: no LCP module found
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:

 

I tried to implement the LCP @ 0x01800001, but without success, for this
index is locked. I.e.: tpm2_nvlist

0x1800001:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly:
authwrite|policydelete|writelocked|writedefine|authread|no_da|written|platfo
rmcreate
    value: 0x42C0462
  size: 70
  authorization policy:
1169A46A813A8CCDD0F3066785207BB9B67AFD3A6CD6DFE5C5AEE120867A96DF

0x1800003:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly:
policywrite|policydelete|write_stclear|authread|no_da|written|platformcreate
    value: 0x8440462
  size: 104
  authorization policy:
EF9A26FC22D1AE8CECFF59E9481AC1EC533DBE228BEC6D17930F4CB2CC5B9724

0x1800004:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: authwrite|policydelete|authread|no_da|written|platformcreate
    value: 0x4040462
  size: 8
  authorization policy:
1169A46A813A8CCDD0F3066785207BB9B67AFD3A6CD6DFE5C5AEE120867A96DF

0x1c00002:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly:
ppwrite|writeall|ppread|ownerread|authread|policyread|no_da|written|platform
create
    value: 0x1100F62
  size: 991

0x1c0000a:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly:
ppwrite|writeall|ppread|ownerread|authread|policyread|no_da|written|platform
create
    value: 0x1100F62
  size: 788

 

My LCP is created the following manner:

 

        tpm2_nvdefine -x 0x01400001 -a 0x40000001 -s 70 -t 0x204000a -P
$TPM_OWNER_PASSWORD
        lcp2_mlehash --create --alg sha256 --cmdline "extpol=sha256
logging=serial,memory" /boot/tboot.gz > mle_hash
        lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver
0 --out mle.elt mle_hash
        lcp2_crtpollist --create --out list_unsig.lst mle.elt
        lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign
0x0A --ctrl 0x00 --data list.data list_unsig.lst
        tpm2_nvwrite -x 0x01400001 -a 0x40000001 -P $TPM_OWNER_PASSWORD
list.pol
        cp -f list.data /boot/

 

Any idea why this LCP, which consists in just an mle element, could be
functional on a platform and not on another?

 

Cordialement / regards,

Olivier le Roy (contractor)

HW - SW development engineer
Thales LAS France

Re: [tboot-devel] "no LCP module found" on Getac X500 G3

[Lukasz H. <luk...@li...>]

Did you add LCP data part to grub.cfg as module2 entry? If you have
multiple SINITs in grub.cfg, please leave only good one and check if it
helps.

Thanks,
Lukasz

On Tue, 2020-09-08 at 08:29 +0000, LE ROY Olivier - Contractor wrote:
> 
> <!--
> p
> 	{margin-top:0;
> 	margin-bottom:0}
> -->
> 
> 
> 
> Hi Lukasz and all,
> 
> 
> 
> thanks for your insight.
> 
> 
> 
> I understand that 
> 
> 
> > it is an expected behaviour that TBOOT is unable to read
> 
> 
> my LCP policy with an MLE element.
> 
> 
> 
> 
> 
> But I don't see the reason why, on a Supermicro platform, TBOOT logs are:
> 
> TBOOT: bios_data (@0x77f00008, 0x2c):
> 
> TBOOT:      version: 3
> 
> TBOOT:      bios_sinit_size: 0x40000 (262144)
> 
> 
> TBOOT:      lcp_pd_base: 0x0
> 
> TBOOT:      lcp_pd_size: 0x0 (0)
> 
> TBOOT:      lcp_pd_base: 0x0
> 
> TBOOT:      lcp_pd_size: 0x0 (0)
> 
> ...
> 
> TBOOT: v2 LCP policy data found
> 
> TBOOT:      lcp_po_base: 0x77f0014c
> 
> TBOOT:      lcp_po_size: 0x5e (94)
> 
> TBOOT:      lcp_pd_base: 0x0
> 
> TBOOT:      lcp_pd_size: 0x0 (0)
> 
> TBOOT:      lcp_pd_base: 0x0
> 
> TBOOT:      lcp_pd_size: 0x0 (0)
> 
> ...
> 
> TBOOT:      lcp_po_base: 0x77f0014c
> 
> TBOOT:      lcp_po_size: 0x5e (94)
> 
> 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: v2 LCP policy data found
> 
> TBOOT: no LCP module found
> 
> 
> 
> 
> 
> whereas and on a Getac platform, same policy ouptuts following TBOOT logs:
> reading
>  Launch Control Policy from TPM NV...
> 
> TBOOT:     :70 bytes read
> 
> TBOOT: in unwrap_lcp_policy
> 
> TBOOT: no LCP module found
> 
> TBOOT:     :reading failed
> 
> TBOOT: failed to read policy from TPM NV, using default
> 
> TBOOT: policy:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Cordialement / regards,
> 
> 
> 
> Olivier le Roy (contractor)
> 
> 
> 
> HW – SW development engineer
> 
> Thales LAS France
> 
> Tel.: +33 1 64 91 66 43
> 
> Mobile : +33 6 26 56 44 99
> 
> 
> 
> 
> De : Lukasz Hawrylko <luk...@li...>
> 
> Envoyé : lundi 7 septembre 2020 14:25:58
> 
> À : LE ROY Olivier - Contractor; tbo...@li...
> 
> Objet : Re: [tboot-devel] "no LCP module found" on Getac X500 G3
>  
> 
> 
> 
> Hi Olivier
> 
> 
> 
> On Fri, 2020-09-04 at 09:28 +0000, LE ROY Olivier - Contractor wrote:
> 
> 
> 
> > I tried to implement a LCP @ 0x01400001 and a VLP @ 0x01200001. These 2 policies were known to work on same OS but different platform (Supermicro).
> 
> > For LCP, I have the following error:
> 
> > 
> 
> > reading Launch Control Policy from TPM NV...
> 
> > TBOOT:     :70 bytes read
> 
> > TBOOT: in unwrap_lcp_policy
> 
> > TBOOT: no LCP module found
> 
> > TBOOT:     :reading failed
> 
> > TBOOT: failed to read policy from TPM NV, using default
> 
> > TBOOT: policy:
> 
> 
> 
> [snip]
> 
> 
> 
> > My LCP is created the following manner:
> 
> > 
> 
> >         tpm2_nvdefine -x 0x01400001 -a 0x40000001 -s 70 -t 0x204000a -P $TPM_OWNER_PASSWORD
> 
> >         lcp2_mlehash --create --alg sha256 --cmdline "extpol=sha256 logging=serial,memory" /boot/tboot.gz > mle_hash
> 
> >         lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out mle.elt mle_hash
> 
> >         lcp2_crtpollist --create --out list_unsig.lst mle.elt
> 
> >         lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign 0x0A --ctrl 0x00 --data list.data list_unsig.lst
> 
> >         tpm2_nvwrite -x 0x01400001 -a 0x40000001 -P $TPM_OWNER_PASSWORD list.pol
> 
> >         cp -f list.data /boot/
> 
> > 
> 
> > Any idea why this LCP, which consists in just an mle element, could be functional on a platform and not on another?
> 
> 
> 
> With these commands you create LCP with MLE element that is consumed by
> 
> SINIT. It is an expected behaviour that TBOOT is unable to read it.
> 
> 
> 
> To create policy for TBOOT (VLP) you have to use tb_polgen tool, ex.:
> 
> 
> 
>     tb_polgen --create --ctrl 0x00 --type continue vl.pol
> 
>     tb_polgen --add --num 0 --pcr 19 --hash image \
> 
>               --cmdline "intel_iommu=on console=ttyS0,115200n8" \
> 
>               --image /boot/bzImage vl.pol
> 
> 
> 
> Then you have two options how to provision it to TPM:
> 
>  * provision as standalone policy
> 
>  * add it to LCP as custom element
> 
> 
> 
> If you already use LCP, easier way is to add custom element with TBOOT's
> 
> policy.
> 
> 
> 
>     lcp2_crtpolelt --create --ctrl 0x00 --type custom --out vl.elt \
> 
>                    --uuid tboot vl.pol
> 
> 
> 
> Then build LCP list with all elements that you want to have, provision
> 
> it to TPM and copy .data file to /boot (and add entry to grub.cfg).
> 
> 
> 
> If anything is unclear, please ask. It would be helpful if you can
> 
> describe what is your goal, what behaviour you want to achieve.
> 
> 
> 
> Thanks,
> 
> Lukasz
> 
> 
> 
> 
> 
> 
> 

Re: [tboot-devel] "no LCP module found" on Getac X500 G3

[LE R. O. - C. <oli...@ex...>]

Hi Lukasz and all,


thanks for your insight.


I understand that

> it is an expected behaviour that TBOOT is unable to read

my LCP policy with an MLE element.


But I don't see the reason why, on a Supermicro platform, TBOOT logs are:

TBOOT: bios_data (@0x77f00008, 0x2c):
TBOOT:      version: 3
TBOOT:      bios_sinit_size: 0x40000 (262144)

TBOOT:      lcp_pd_base: 0x0
TBOOT:      lcp_pd_size: 0x0 (0)
TBOOT:      lcp_pd_base: 0x0
TBOOT:      lcp_pd_size: 0x0 (0)
...
TBOOT: v2 LCP policy data found
TBOOT:      lcp_po_base: 0x77f0014c
TBOOT:      lcp_po_size: 0x5e (94)
TBOOT:      lcp_pd_base: 0x0
TBOOT:      lcp_pd_size: 0x0 (0)
TBOOT:      lcp_pd_base: 0x0
TBOOT:      lcp_pd_size: 0x0 (0)
...
TBOOT:      lcp_po_base: 0x77f0014c
TBOOT:      lcp_po_size: 0x5e (94)
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: v2 LCP policy data found
TBOOT: no LCP module found


whereas and on a Getac platform, same policy ouptuts following TBOOT logs:

reading Launch Control Policy from TPM NV...
TBOOT:     :70 bytes read
TBOOT: in unwrap_lcp_policy
TBOOT: no LCP module found
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:



Cordialement / regards,

Olivier le Roy (contractor)

HW – SW development engineer
Thales LAS France
Tel.: +33 1 64 91 66 43
Mobile : +33 6 26 56 44 99
________________________________
De : Lukasz Hawrylko <luk...@li...>
Envoyé : lundi 7 septembre 2020 14:25:58
À : LE ROY Olivier - Contractor; tbo...@li...
Objet : Re: [tboot-devel] "no LCP module found" on Getac X500 G3

Hi Olivier

On Fri, 2020-09-04 at 09:28 +0000, LE ROY Olivier - Contractor wrote:

> I tried to implement a LCP @ 0x01400001 and a VLP @ 0x01200001. These 2 policies were known to work on same OS but different platform (Supermicro).
> For LCP, I have the following error:
>
> reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT: in unwrap_lcp_policy
> TBOOT: no LCP module found
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:

[snip]

> My LCP is created the following manner:
>
>         tpm2_nvdefine -x 0x01400001 -a 0x40000001 -s 70 -t 0x204000a -P $TPM_OWNER_PASSWORD
>         lcp2_mlehash --create --alg sha256 --cmdline "extpol=sha256 logging=serial,memory" /boot/tboot.gz > mle_hash
>         lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out mle.elt mle_hash
>         lcp2_crtpollist --create --out list_unsig.lst mle.elt
>         lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign 0x0A --ctrl 0x00 --data list.data list_unsig.lst
>         tpm2_nvwrite -x 0x01400001 -a 0x40000001 -P $TPM_OWNER_PASSWORD list.pol
>         cp -f list.data /boot/
>
> Any idea why this LCP, which consists in just an mle element, could be functional on a platform and not on another?

With these commands you create LCP with MLE element that is consumed by
SINIT. It is an expected behaviour that TBOOT is unable to read it.

To create policy for TBOOT (VLP) you have to use tb_polgen tool, ex.:

    tb_polgen --create --ctrl 0x00 --type continue vl.pol
    tb_polgen --add --num 0 --pcr 19 --hash image \
              --cmdline "intel_iommu=on console=ttyS0,115200n8" \
              --image /boot/bzImage vl.pol

Then you have two options how to provision it to TPM:
 * provision as standalone policy
 * add it to LCP as custom element

If you already use LCP, easier way is to add custom element with TBOOT's
policy.

    lcp2_crtpolelt --create --ctrl 0x00 --type custom --out vl.elt \
                   --uuid tboot vl.pol

Then build LCP list with all elements that you want to have, provision
it to TPM and copy .data file to /boot (and add entry to grub.cfg).

If anything is unclear, please ask. It would be helpful if you can
describe what is your goal, what behaviour you want to achieve.

Thanks,
Lukasz

Re: [tboot-devel] "no LCP module found" on Getac X500 G3

[Lukasz H. <luk...@li...>]

Hi Olivier

On Fri, 2020-09-04 at 09:28 +0000, LE ROY Olivier - Contractor wrote:

> I tried to implement a LCP @ 0x01400001 and a VLP @ 0x01200001. These 2 policies were known to work on same OS but different platform (Supermicro).
> For LCP, I have the following error:
> 
> reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT: in unwrap_lcp_policy
> TBOOT: no LCP module found
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:

[snip]

> My LCP is created the following manner:
> 
>         tpm2_nvdefine -x 0x01400001 -a 0x40000001 -s 70 -t 0x204000a -P $TPM_OWNER_PASSWORD
>         lcp2_mlehash --create --alg sha256 --cmdline "extpol=sha256 logging=serial,memory" /boot/tboot.gz > mle_hash
>         lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out mle.elt mle_hash
>         lcp2_crtpollist --create --out list_unsig.lst mle.elt
>         lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign 0x0A --ctrl 0x00 --data list.data list_unsig.lst
>         tpm2_nvwrite -x 0x01400001 -a 0x40000001 -P $TPM_OWNER_PASSWORD list.pol
>         cp -f list.data /boot/
> 
> Any idea why this LCP, which consists in just an mle element, could be functional on a platform and not on another?

With these commands you create LCP with MLE element that is consumed by
SINIT. It is an expected behaviour that TBOOT is unable to read it.

To create policy for TBOOT (VLP) you have to use tb_polgen tool, ex.:

    tb_polgen --create --ctrl 0x00 --type continue vl.pol
    tb_polgen --add --num 0 --pcr 19 --hash image \
              --cmdline "intel_iommu=on console=ttyS0,115200n8" \
              --image /boot/bzImage vl.pol

Then you have two options how to provision it to TPM:
 * provision as standalone policy
 * add it to LCP as custom element

If you already use LCP, easier way is to add custom element with TBOOT's
policy.

    lcp2_crtpolelt --create --ctrl 0x00 --type custom --out vl.elt \
                   --uuid tboot vl.pol

Then build LCP list with all elements that you want to have, provision
it to TPM and copy .data file to /boot (and add entry to grub.cfg).

If anything is unclear, please ask. It would be helpful if you can
describe what is your goal, what behaviour you want to achieve.

Thanks,
Lukasz

[tboot-devel] "no LCP module found" on Getac X500 G3

[LE R. O. - C. <oli...@ex...>]

I have a Getac X500 G3 that I am trying to get TBOOT working on under a
CentOS 7.7 OS with TBOOT 1.9.11. The TBOOT startup, without any policy, looks as follows:

TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
TBOOT: CPU is SMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: *********************** TBOOT ***********************
TBOOT:    2019-11-25 16:00 +0200 1.9.11
TBOOT: *****************************************************
TBOOT: command line: extpol=sha256 logging=serial,memory
...
TBOOT: TXT chipset and all needed capabilities present
...
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:      ACM info_table version mismatch (6)
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
TBOOT: processor family/model/stepping: 0x906e9
TBOOT: platform id: 0x14000000000000
TBOOT:      1 ACM chipset id entries:
TBOOT:          vendor: 0x8086, device: 0xb006, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT:      4 ACM processor id entries:
TBOOT:          fms: 0x406e0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT:          fms: 0x506e0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT:          fms: 0x806e0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
TBOOT:          fms: 0x906e0, fms_mask: 0xfff3ff0, platform_id: 0x0, platform_mask: 0x0
...
TBOOT: SINIT matches platform
...
TBOOT: AC mod base alignment OK
TBOOT: AC mod size OK

...
TBOOT: reading Verified Launch Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01200001 in TPM NV
TBOOT:     :reading failed
TBOOT: reading Launch Control Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01400001 in TPM NV
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:
...
TBOOT: executing GETSEC[SENTER]...


I tried to implement a LCP @ 0x01400001 and a VLP @ 0x01200001. These 2 policies were known to work on same OS but different platform (Supermicro).

For LCP, I have the following error:

reading Launch Control Policy from TPM NV...
TBOOT:     :70 bytes read
TBOOT: in unwrap_lcp_policy
TBOOT: no LCP module found
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:


I tried to implement the LCP @ 0x01800001, but without success, for this index is locked. I.e.: tpm2_nvlist

0x1800001:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: authwrite|policydelete|writelocked|writedefine|authread|no_da|written|platformcreate
    value: 0x42C0462
  size: 70
  authorization policy: 1169A46A813A8CCDD0F3066785207BB9B67AFD3A6CD6DFE5C5AEE120867A96DF

0x1800003:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: policywrite|policydelete|write_stclear|authread|no_da|written|platformcreate
    value: 0x8440462
  size: 104
  authorization policy: EF9A26FC22D1AE8CECFF59E9481AC1EC533DBE228BEC6D17930F4CB2CC5B9724

0x1800004:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: authwrite|policydelete|authread|no_da|written|platformcreate
    value: 0x4040462
  size: 8
  authorization policy: 1169A46A813A8CCDD0F3066785207BB9B67AFD3A6CD6DFE5C5AEE120867A96DF

0x1c00002:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: ppwrite|writeall|ppread|ownerread|authread|policyread|no_da|written|platformcreate
    value: 0x1100F62
  size: 991

0x1c0000a:
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: ppwrite|writeall|ppread|ownerread|authread|policyread|no_da|written|platformcreate
    value: 0x1100F62
  size: 788


My LCP is created the following manner:


        tpm2_nvdefine -x 0x01400001 -a 0x40000001 -s 70 -t 0x204000a -P $TPM_OWNER_PASSWORD
        lcp2_mlehash --create --alg sha256 --cmdline "extpol=sha256 logging=serial,memory" /boot/tboot.gz > mle_hash
        lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out mle.elt mle_hash
        lcp2_crtpollist --create --out list_unsig.lst mle.elt
        lcp2_crtpol --create --type list --pol list.pol --alg sha256 --sign 0x0A --ctrl 0x00 --data list.data list_unsig.lst
        tpm2_nvwrite -x 0x01400001 -a 0x40000001 -P $TPM_OWNER_PASSWORD list.pol
        cp -f list.data /boot/


Any idea why this LCP, which consists in just an mle element, could be functional on a platform and not on another?


Cordialement / regards,

Olivier le Roy (contractor)

HW – SW development engineer
Thales LAS France

Re: [tboot-devel] lcptools-v2 regressions in e73d11a8a2d6

[Lukasz H. <luk...@li...>]

Hi Timo

On Sat, 2020-08-15 at 11:42 +0300, Timo Lindfors wrote:
> Hi,
> 
> changeset:   603:e73d11a8a2d6
> user:        Mateusz Mowka <mat...@in...>
> date:        Wed Jul 01 09:08:25 2020 +0200
> summary:     Update lcptools-v2 to meet requirements from MLE DG rev16.
> 
> seems to re-introduce spelling errors that were fixed in
> 
> changeset:   590:2fbc7ec3b2c8
> user:        Timo Juhani Lindfors <tim...@ik...>
> date:        Sat May 09 20:59:11 2020 +0300
> summary:     Fix spelling errors
> 
> See e.g.
> 
>           if ( *out_file == '\0' ) {
> -            ERROR("Error: no output file specified\n");
> +            ERROR("Error: no ouput file specified\n");
>               return 1;
>           }
> 
> Is this perhaps some merge conflict issue or does lcptool-v2 master data 
> live in some other repository completely and that's why modifications made 
> in tboot repository get overwritten?
> 
> The complete list of spelling errors reported by the debian lintian tool 
> is here:
> 
> I: tboot: spelling-error-in-manpage usr/share/man/man8/lcp2_crtpollist.8.gz ouput output
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpol successfull successful
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpol defiend defined
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpolelt ouput output
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpolelt defiend defined
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpollist succesfully successfully
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpollist successfull successful
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpollist defiend defined
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_mlehash ouput output
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_mlehash Unknonw Unknown
> I: tboot: spelling-error-in-binary usr/sbin/lcp2_mlehash defiend defined
> 
> 
> 
> -Timo
> 

You are right, something gone wrong during merging. Fix will be pushed
in few days when I find a little free time.

Thanks,
Lukasz

[tboot-devel] lcptools-v2 regressions in e73d11a8a2d6

[Timo L. <tim...@ik...>]

Hi,

changeset:   603:e73d11a8a2d6
user:        Mateusz Mowka <mat...@in...>
date:        Wed Jul 01 09:08:25 2020 +0200
summary:     Update lcptools-v2 to meet requirements from MLE DG rev16.

seems to re-introduce spelling errors that were fixed in

changeset:   590:2fbc7ec3b2c8
user:        Timo Juhani Lindfors <tim...@ik...>
date:        Sat May 09 20:59:11 2020 +0300
summary:     Fix spelling errors

See e.g.

          if ( *out_file == '\0' ) {
-            ERROR("Error: no output file specified\n");
+            ERROR("Error: no ouput file specified\n");
              return 1;
          }

Is this perhaps some merge conflict issue or does lcptool-v2 master data 
live in some other repository completely and that's why modifications made 
in tboot repository get overwritten?

The complete list of spelling errors reported by the debian lintian tool 
is here:

I: tboot: spelling-error-in-manpage usr/share/man/man8/lcp2_crtpollist.8.gz ouput output
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpol successfull successful
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpol defiend defined
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpolelt ouput output
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpolelt defiend defined
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpollist succesfully successfully
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpollist successfull successful
I: tboot: spelling-error-in-binary usr/sbin/lcp2_crtpollist defiend defined
I: tboot: spelling-error-in-binary usr/sbin/lcp2_mlehash ouput output
I: tboot: spelling-error-in-binary usr/sbin/lcp2_mlehash Unknonw Unknown
I: tboot: spelling-error-in-binary usr/sbin/lcp2_mlehash defiend defined



-Timo

Re: [tboot-devel] extra bytes printed after SHA1 hash?

[Timo L. <tim...@ik...>]

Hi,

On Mon, 8 Jun 2020, Lukasz Hawrylko wrote:
> TBOOT is using hardcoded default policy when TPM is not provisioned.
> That policy enforces SHA256 even if TPM1.2 is detected. That leads to
> undesirable behaviour.

Thanks, this seems to work!

Re: [tboot-devel] tboot fails to build on GCC7+

[tony c. <tc...@re...>]

On 6/18/20 9:33 AM, Lukasz Hawrylko wrote:
> On Wed, 2020-06-17 at 08:54 -0400, Tony Camuso wrote:
>> Sorry for the noise, if this has already been reported or corrected.
>>
>> tboot is built with the -Wextra Cflag, which is an alias for a
>> collection of warning flags. tboot's make interprets warnings as errors.
>>
>>  From GCC 7 forward, the -Wextra Cflag includes -Wimplicit-fallthrough.
>>
>> The GCC 7+ switch statement requires a break statement after each case.
>> Without a break statement after a case, then an "implicit fallthrough"
>> condition exists, where the matched case is executed, and the following
>> case is also executed. If none of the fallthrough cases has a statement,
>> and if the last statement in the fallthrough cascade is a break, all is
>> forgiven, and the GCC 7+ compiler will move on.
>>
>> Otherwise, GCC 7+ with -Wextra will issue the following error when
>> -Werror is set, as it is in the tboot make.
>>
>> error: this statement may fall through [-Werror=implicit-fallthrough=]
>>
>> That means case statements with implicit fallthroughs will be flagged
>> as compile errors and crater the build. There exists a number of
>> compiler specific ways to tell the compiler that the fallthrough is
>> there by design, but the simplest way to avert this problem is to add
>> the -Wno-implicit-fallthrough flag to the CFLAGS_WARN variable in tboot's
>> Config.mk file.
>>
> 
> Hi Tony
> 
> Thank you for your patch. This is already fixed in a6180f9e9e86. In
> general we want to have -Wimplicit-fallthrough enabled, however there
> was a bug where different CFLAGS value was passed to safestringlib
> Makefile depends on building environment. Sometimes safestringlib was
> build with -Werror -Wextra, sometimes not. [1]
> 
> Could you please check if with that commit you can build TBOOT without
> errors?
> 
> [1] https://sourceforge.net/p/tboot/mailman/message/37005286/
> 
> Thanks,
> Lukasz
> 

Thanks, Lukasz! That patch fixes the build problem I was having.

Re: [tboot-devel] tboot fails to build on GCC7+

[Lukasz H. <luk...@li...>]

On Wed, 2020-06-17 at 08:54 -0400, Tony Camuso wrote:
> Sorry for the noise, if this has already been reported or corrected.
> 
> tboot is built with the -Wextra Cflag, which is an alias for a
> collection of warning flags. tboot's make interprets warnings as errors.
> 
> From GCC 7 forward, the -Wextra Cflag includes -Wimplicit-fallthrough.
> 
> The GCC 7+ switch statement requires a break statement after each case.
> Without a break statement after a case, then an "implicit fallthrough"
> condition exists, where the matched case is executed, and the following
> case is also executed. If none of the fallthrough cases has a statement,
> and if the last statement in the fallthrough cascade is a break, all is
> forgiven, and the GCC 7+ compiler will move on.
> 
> Otherwise, GCC 7+ with -Wextra will issue the following error when
> -Werror is set, as it is in the tboot make.
> 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
> 
> That means case statements with implicit fallthroughs will be flagged
> as compile errors and crater the build. There exists a number of
> compiler specific ways to tell the compiler that the fallthrough is
> there by design, but the simplest way to avert this problem is to add
> the -Wno-implicit-fallthrough flag to the CFLAGS_WARN variable in tboot's
> Config.mk file.
> 

Hi Tony

Thank you for your patch. This is already fixed in a6180f9e9e86. In
general we want to have -Wimplicit-fallthrough enabled, however there
was a bug where different CFLAGS value was passed to safestringlib
Makefile depends on building environment. Sometimes safestringlib was
build with -Werror -Wextra, sometimes not. [1]

Could you please check if with that commit you can build TBOOT without
errors?

[1] https://sourceforge.net/p/tboot/mailman/message/37005286/

Thanks,
Lukasz

[tboot-devel] tboot fails to build on GCC7+

[Tony C. <tc...@re...>]

Sorry for the noise, if this has already been reported or corrected.

tboot is built with the -Wextra Cflag, which is an alias for a
collection of warning flags. tboot's make interprets warnings as errors.

>From GCC 7 forward, the -Wextra Cflag includes -Wimplicit-fallthrough.

The GCC 7+ switch statement requires a break statement after each case.
Without a break statement after a case, then an "implicit fallthrough"
condition exists, where the matched case is executed, and the following
case is also executed. If none of the fallthrough cases has a statement,
and if the last statement in the fallthrough cascade is a break, all is
forgiven, and the GCC 7+ compiler will move on.

Otherwise, GCC 7+ with -Wextra will issue the following error when
-Werror is set, as it is in the tboot make.

error: this statement may fall through [-Werror=implicit-fallthrough=]

That means case statements with implicit fallthroughs will be flagged
as compile errors and crater the build. There exists a number of
compiler specific ways to tell the compiler that the fallthrough is
there by design, but the simplest way to avert this problem is to add
the -Wno-implicit-fallthrough flag to the CFLAGS_WARN variable in tboot's
Config.mk file.

Signed-off-by: Tony Camuso <tc...@re...>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index e730511..4382336 100644
--- a/Config.mk
+++ b/Config.mk
@@ -41,7 +41,7 @@ cc-option = $(shell if test -z "`$(1) $(2) -S -o /dev/null -xc \
 
 CFLAGS_WARN       = -Wall -Wformat-security -Werror -Wstrict-prototypes \
 	            -Wextra -Winit-self -Wswitch-default -Wunused-parameter \
-	            -Wwrite-strings \
+	            -Wwrite-strings -Wno-implicit-fallthrough \
 	            $(call cc-option,$(CC),-Wlogical-op,) \
 	            -Wno-missing-field-initializers
 
-- 
2.18.1

Re: [tboot-devel] extra bytes printed after SHA1 hash?

[Lukasz H. <luk...@li...>]

On Sat, 2020-06-06 at 23:02 +0300, Timo Lindfors wrote:
> Hi,
> 
> when I boot current mercurial tip with TPM 1.2 I get the following output:
> 
> TBOOT: verifying policy 
> TBOOT: verifying module "root=UUID=bc701bae-ee9c-4151-a85b-0f5a68212975 ro quiet net.ifnames=0 intel_iommu=on"...
> TBOOT:   OK : 26 0d 8e 28 3d 24 8b 45 74 92 02 76 50 f4 28 11 2b 6c d5 03 00 00 00 00 00 00 00 00 00 00 d8 9b
> TBOOT: verifying module ""...
> TBOOT:   OK : ed 04 ea fe e3 e4 30 63 ae c2 ba 41 cc 35 de aa f0 2a e7 18 00 00 00 00 00 00 00 00 00 00 d8 9b
> TBOOT: all modules are verified
> 
> Notice how both hashes end with the same byte string "00 00 00 00 00 00 00 
> 00 00 00 d8 9b". Is the code printing 32 bytes of memory (length of a 
> SHA256 hash) but the memory actually contains a SHA1 hash?
> 
> -Timo
> 
> 

Hi Timo

TBOOT is using hardcoded default policy when TPM is not provisioned.
That policy enforces SHA256 even if TPM1.2 is detected. That leads to
undesirable behaviour.

To fix that issue I created another default policy that uses SHA1 and is
applied when TPM1.2 is present. Patch is already published.

Thanks,
Lukasz

[tboot-devel] extra bytes printed after SHA1 hash?

[Timo L. <tim...@ik...>]

Hi,

when I boot current mercurial tip with TPM 1.2 I get the following output:

TBOOT: verifying policy 
TBOOT: verifying module "root=UUID=bc701bae-ee9c-4151-a85b-0f5a68212975 ro quiet net.ifnames=0 intel_iommu=on"...
TBOOT:   OK : 26 0d 8e 28 3d 24 8b 45 74 92 02 76 50 f4 28 11 2b 6c d5 03 00 00 00 00 00 00 00 00 00 00 d8 9b
TBOOT: verifying module ""...
TBOOT:   OK : ed 04 ea fe e3 e4 30 63 ae c2 ba 41 cc 35 de aa f0 2a e7 18 00 00 00 00 00 00 00 00 00 00 d8 9b
TBOOT: all modules are verified

Notice how both hashes end with the same byte string "00 00 00 00 00 00 00 
00 00 00 d8 9b". Is the code printing 32 bytes of memory (length of a 
SHA256 hash) but the memory actually contains a SHA1 hash?

-Timo

Re: [tboot-devel] tboot 1.9.12 build failure if CFLAGS is set in environment

[Timo L. <tim...@ik...>]

On Mon, 1 Jun 2020, Timo Lindfors wrote:
> tboot prints
>
> "TBOOT: this routine only prints out multiboot 2"
>
> and never enters the else block where the printk()s are...

This gave me a hint: Using multiboot2/module2 seems to work with cold 
boot. This might not mean anything of course if the issue is caused
by memory corruption.

-Timo

Re: [tboot-devel] tboot 1.9.12 build failure if CFLAGS is set in environment

[Timo L. <tim...@ik...>]

On Fri, 29 May 2020, Lukasz Hawrylko wrote:
> I will setup my environment to test legacy boot and I will check if the
> same problem occurs. If it is possible, please try EFI boot on your PC.

I set a Thinkpad T430s (BIOS version 2.69) to UEFI-only mode without CSM 
and installed a fresh Debian 10. I then upgraded to debian unstable and 
installed tboot and txt-enabled kernel. The boot seems to get stuck with 
both warm and cold boot. What is worse, I get no output from tboot at 
all, there is only a warning

"WARNING: no console will be available to OS"

supposedly from grub2? As T430s does not have a serial port and none of 
the docking stations for that model have a serial port I am kind of blind 
here.

-Timo

Re: [tboot-devel] tboot 1.9.12 build failure if CFLAGS is set in environment

[Timo L. <tim...@ik...>]

Hi,

On Mon, 1 Jun 2020, Lukasz Hawrylko wrote:
>> On warm boot this prints just
>>
>> TBOOT: start=0x0x10008 tag_type=17 start->type=3031684 start->size=-2147418113
>> TBOOT: start=0x0x80020008 tag_type=17 start->type=0 start->size=0
>>
>
> That looks like memory corruption... Does it work when you remove all
> SINITs except the good one?

Hmm, So do both cold boot and warm boot prints look like memory corruption 
or just the cold boot where it gets stuck?

Listing only GM45_GS45_PM45_SINIT_51.BIN in grub.cfg still results in 
tboot getting stuck.

> Could you please apply following patch and send me a log?

tboot prints

"TBOOT: this routine only prints out multiboot 2"

and never enters the else block where the printk()s are...

> One more test - please remove 'memory' option in 'logging' parameter
> from TBOOT command line in grub.cfg and check if that helps.

This does not seem to change the behavior either.

-Timo

Re: [tboot-devel] tboot 1.9.12 build failure if CFLAGS is set in environment

[Lukasz H. <luk...@li...>]

On Mon, 2020-06-01 at 01:27 +0300, Timo Lindfors wrote:
> On Mon, 1 Jun 2020, Timo Lindfors wrote:
> > printk(TBOOT_INFO"start=%p tag_type=%d start->type=%d start->size=%d\n",
> >       start,
> >       tag_type,
> >       start->type,
> >       start->size);
> 
> On warm boot this prints just
> 
> TBOOT: start=0x0x10008 tag_type=17 start->type=3031684 start->size=-2147418113
> TBOOT: start=0x0x80020008 tag_type=17 start->type=0 start->size=0
> 

That looks like memory corruption... Does it work when you remove all
SINITs except the good one?

Could you please apply following patch and send me a log?

One more test - please remove 'memory' option in 'logging' parameter
from TBOOT command line in grub.cfg and check if that helps.

Thanks,
Lukasz

diff -r 1f912c52b1cc tboot/common/loader.c
--- a/tboot/common/loader.c	Sat May 23 20:32:48 2020 +0300
+++ b/tboot/common/loader.c	Mon Jun 01 17:17:01 2020 +0200
@@ -1907,10 +1907,11 @@
         return;
     } else {
         struct mb2_tag *start = (struct mb2_tag *)(lctx->addr + 8);
-        printk(TBOOT_INFO"MB2 dump, size %d\n", *(uint32_t *)lctx->addr);
+        printk(TBOOT_INFO"MB2 dump, size %d addr %p\n", *(uint32_t *)lctx->addr,
+               lctx->addr);
         while (start != NULL){
-            printk(TBOOT_INFO"MB2 tag found of type %d size %d ", 
-                   start->type, start->size);
+            printk(TBOOT_INFO"MB2 tag found of type %d size %d addr %p ", 
+                   start->type, start->size, start);
             switch (start->type){
             case MB2_TAG_TYPE_CMDLINE:
             case MB2_TAG_TYPE_LOADER_NAME:
@@ -1924,6 +1925,8 @@
                 {
                     struct mb2_tag_module *ts = 
                         (struct mb2_tag_module *) start;
+                    printk(TBOOT_INFO"mod_start 0x%x, mod_end 0x%x ",
+                           ts->mod_start, ts->mod_end);
                     printk_long(ts->cmdline);
                 }
                 break;
diff -r 1f912c52b1cc tboot/common/tboot.c
--- a/tboot/common/tboot.c	Sat May 23 20:32:48 2020 +0300
+++ b/tboot/common/tboot.c	Mon Jun 01 17:17:01 2020 +0200
@@ -369,6 +369,8 @@
        print_loader_ctx(g_ldr_ctx);
     */
 
+    print_loader_ctx(g_ldr_ctx);
+
     /* clear resume vector on S3 resume so any resets will not use it */
     if ( !is_launched() && s3_flag )        set_s3_resume_vector(&_tboot_shared.acpi_sinfo, 0);

Re: [tboot-devel] tboot 1.9.12 build failure if CFLAGS is set in environment

[Timo L. <tim...@ik...>]

On Mon, 1 Jun 2020, Timo Lindfors wrote:
> printk(TBOOT_INFO"start=%p tag_type=%d start->type=%d start->size=%d\n",
>       start,
>       tag_type,
>       start->type,
>       start->size);

On warm boot this prints just

TBOOT: start=0x0x10008 tag_type=17 start->type=3031684 start->size=-2147418113
TBOOT: start=0x0x80020008 tag_type=17 start->type=0 start->size=0

-Timo