Menu
▾
▴
tboot-devel — Developer support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
(8) |
Apr
(14) |
May
(8) |
Jun
(10) |
Jul
(14) |
Aug
(3) |
Sep
(13) |
Oct
(27) |
Nov
(39) |
Dec
(24) |
| 2009 |
Jan
(19) |
Feb
(4) |
Mar
(2) |
Apr
(15) |
May
|
Jun
(2) |
Jul
(44) |
Aug
(21) |
Sep
(20) |
Oct
(2) |
Nov
(1) |
Dec
(7) |
| 2010 |
Jan
(7) |
Feb
(10) |
Mar
(2) |
Apr
(12) |
May
(7) |
Jun
(2) |
Jul
(18) |
Aug
(11) |
Sep
(4) |
Oct
(25) |
Nov
(8) |
Dec
(1) |
| 2011 |
Jan
(27) |
Feb
(2) |
Mar
(19) |
Apr
(8) |
May
(16) |
Jun
(11) |
Jul
(9) |
Aug
(9) |
Sep
(35) |
Oct
(9) |
Nov
(8) |
Dec
(32) |
| 2012 |
Jan
(37) |
Feb
(20) |
Mar
(2) |
Apr
(24) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(21) |
Sep
(8) |
Oct
(15) |
Nov
(1) |
Dec
(7) |
| 2013 |
Jan
(4) |
Feb
(8) |
Mar
(38) |
Apr
(9) |
May
(42) |
Jun
(4) |
Jul
(21) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2014 |
Jan
(8) |
Feb
(8) |
Mar
(5) |
Apr
(9) |
May
(19) |
Jun
(1) |
Jul
(10) |
Aug
(25) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(12) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
(5) |
Nov
(3) |
Dec
(1) |
| 2016 |
Jan
(2) |
Feb
(24) |
Mar
|
Apr
(6) |
May
(26) |
Jun
(20) |
Jul
(8) |
Aug
(15) |
Sep
(21) |
Oct
(1) |
Nov
(7) |
Dec
(24) |
| 2017 |
Jan
(12) |
Feb
(2) |
Mar
(6) |
Apr
(8) |
May
(18) |
Jun
(13) |
Jul
(12) |
Aug
(8) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
(12) |
Mar
(8) |
Apr
(5) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
| 2019 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2020 |
Jan
(25) |
Feb
(12) |
Mar
(2) |
Apr
(13) |
May
(44) |
Jun
(9) |
Jul
|
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
|
| 2021 |
Jan
(6) |
Feb
|
Mar
(7) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(16) |
Sep
(4) |
Oct
(6) |
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
(5) |
Feb
(4) |
Mar
(22) |
Apr
(6) |
May
(4) |
Jun
(17) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2023 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jerry S. <jsn...@re...> - 2020-11-11 22:15:28
|
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 |
|
From: tony c. <tc...@re...> - 2020-10-22 12:17:14
|
> 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! |
|
From: Lukasz H. <luk...@li...> - 2020-10-21 07:45:17
|
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 |
|
From: tony c. <tc...@re...> - 2020-10-20 16:48:29
|
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();
^
|
|
From: Timo L. <tim...@ik...> - 2020-10-19 07:36:20
|
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 |
|
From: Briggs, K. 1 <kev...@lm...> - 2020-09-16 13:28:19
|
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
|
|
From: Lukasz H. <luk...@li...> - 2020-09-09 08:52:58
|
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
>
>
>
>
>
>
>
|
|
From: LE R. O. - C. <oli...@ex...> - 2020-09-08 08:30:24
|
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
|
|
From: Lukasz H. <luk...@li...> - 2020-09-07 12:26:14
|
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
|
|
From: LE R. O. - C. <oli...@ex...> - 2020-09-04 09:54:16
|
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
|
|
From: Lukasz H. <luk...@li...> - 2020-08-18 12:20:11
|
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
|
|
From: Timo L. <tim...@ik...> - 2020-08-15 11:03:24
|
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
|
|
From: Timo L. <tim...@ik...> - 2020-08-15 10:48:18
|
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! |
|
From: tony c. <tc...@re...> - 2020-06-23 16:14:37
|
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. |
|
From: Lukasz H. <luk...@li...> - 2020-06-18 13:34:23
|
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 |
|
From: Tony C. <tc...@re...> - 2020-06-17 12:54:44
|
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 |
|
From: Lukasz H. <luk...@li...> - 2020-06-08 13:21:02
|
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 |
|
From: Timo L. <tim...@ik...> - 2020-06-06 20:03:05
|
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 |
|
From: Timo L. <tim...@ik...> - 2020-06-01 22:16:15
|
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 |
|
From: Timo L. <tim...@ik...> - 2020-06-01 20:28:36
|
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 |
|
From: Timo L. <tim...@ik...> - 2020-06-01 18:08:56
|
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 |
|
From: Lukasz H. <luk...@li...> - 2020-06-01 15:21:25
|
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);
|
|
From: Timo L. <tim...@ik...> - 2020-05-31 22:27:40
|
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 |
|
From: Timo L. <tim...@ik...> - 2020-05-31 21:57:18
|
On Fri, 29 May 2020, Lukasz Hawrylko wrote:
> On Fri, 2020-05-29 at 12:36 +0300, Timo Lindfors wrote:
> I see "Failed to get EFI memory map" message, did you configure BIOS to
> use legacy boot? "set debug=mmap" should enable EFI memory map print in
> grub_efi_mmap_iterate(), but this does not work when booted in legacy
> mode.
Yes, Thinkpad R400 does not seem to support EFI. Finding a laptop
that that does TPM 2.0, UEFI, TXT and serial port seems to be bit
tricky but I'll keep looking.
> As printk is blocking call you can add few additional prints somewhere
> around tboot.c:384 and inside copy_e820_map() and efi_memmap_copy() to
> find out where exactly it hangs.
It seems to be stuck in the while loop in find_mb2_tag_type. Placing
printk(TBOOT_INFO"start=%p tag_type=%d start->type=%d start->size=%d\n",
start,
tag_type,
start->type,
start->size);
inside the while loop prints
TBOOT: start=0x10008 tag_type=17 start->type=3031684 start->size=-2147418113
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
TBOOT: start=0x80020008 tag_type=17 start->type=-1 start->size=-1
...
-Timo
|
|
From: Lukasz H. <luk...@li...> - 2020-05-29 14:24:52
|
On Fri, 2020-05-29 at 12:36 +0300, Timo Lindfors wrote: > On Thu, 28 May 2020, Timo Lindfors wrote: > > > If you don't see this dump in failing scenario please add > > > "set debug=mmap" to grub.cfg, now GRUB should print that. > > > > I added this after the serial console setup but this does not seem to print > > anything? I also cannot find it in the grub2 source code. Is this the correct > > syntax? > > Assuming you meant "lsmmap" I am attaching here output from cold and warm > boot. Unfortunately as you can see they are identical until the cold boot > gets stuck but maybe this still helps? I see "Failed to get EFI memory map" message, did you configure BIOS to use legacy boot? "set debug=mmap" should enable EFI memory map print in grub_efi_mmap_iterate(), but this does not work when booted in legacy mode. 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. As printk is blocking call you can add few additional prints somewhere around tboot.c:384 and inside copy_e820_map() and efi_memmap_copy() to find out where exactly it hangs. Thanks, Lukasz |
15 messages has been excluded from this view by a project administrator.
