tboot-devel — Developer support

Re: [tboot-devel] tboot not picking the right ACM module on Dell Latitude E5470

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

On Tue, 7 Apr 2020, Lukasz Hawrylko wrote:
> Unfortunately, this bug is not reported anywhere. In real life scenarios
> I don't see any benefits of loading multiple SINITs. In most cases you
> have one SINIT that is dedicated to the platform.

The main benefit is that you can automate installation more easily and you 
can use the same image on all machines. This allows using even a LiveUSB 
with tboot. If we can't put this logic to tboot then maybe it should be 
put to the part that generates the grub configuration file at least? I'm 
open to any other ideas of course.

> better to change documentation that only one SINIT can be loaded. I will
> check who is the owner of TBOOT page in Fedora's wiki.

Thanks!

-Timo

Re: [tboot-devel] tboot not picking the right ACM module on Dell Latitude E5470

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

On Thu, 2020-04-02 at 17:25 +0300, Timo Lindfors wrote:
> Hi,
> 
> On Thu, 2 Apr 2020, Lukasz Hawrylko wrote:
> > There is a bug in TBOOT that may results in overlapping loaded SINITs by
> > TBOOT's logs. That problem occurs when you load multiple SINITs in GRUB
> > and in most cases the last one will be corrupted. That's why, when TBOOT
> > executes GETSEC[SENTER] CPU fails on SINIT integrity check and resets
> > platform.
> > 
> > The workaround for that issue is to have only one SINIT in grub.cfg, so
> > in your scenario you should remove all SINITs except 6th_gen from /boot
> > and recreate grub.cfg
> 
> Is the bug report perhaps available somewhere? I'd very much like to fix this as it 
> is causing many support issues since for example 
> https://fedoraproject.org/wiki/Tboot
> 
> suggests
> 
> "You may download all of the ACM modules into /boot and list them all as 
> modules in your grub.conf. tboot will pick the right module for your 
> platform. "
> 
> I can't change that wiki page as edits are currently not allowed even if I 
> create an account.
> 
> -Timo
> 

Hi Timo

Unfortunately, this bug is not reported anywhere. In real life scenarios
I don't see any benefits of loading multiple SINITs. In most cases you
have one SINIT that is dedicated to the platform.

I am not sure if that issue can be fixed without moving TBOOT log memory
pool somewhere else and that change will brake other tools. It will be
better to change documentation that only one SINIT can be loaded. I will
check who is the owner of TBOOT page in Fedora's wiki.

Thanks,
Lukasz

Re: [tboot-devel] tboot not picking the right ACM module on Dell Latitude E5470

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

Hi,

On Thu, 2 Apr 2020, Lukasz Hawrylko wrote:
> There is a bug in TBOOT that may results in overlapping loaded SINITs by
> TBOOT's logs. That problem occurs when you load multiple SINITs in GRUB
> and in most cases the last one will be corrupted. That's why, when TBOOT
> executes GETSEC[SENTER] CPU fails on SINIT integrity check and resets
> platform.
>
> The workaround for that issue is to have only one SINIT in grub.cfg, so
> in your scenario you should remove all SINITs except 6th_gen from /boot
> and recreate grub.cfg

Is the bug report perhaps available somewhere? I'd very much like to fix this as it 
is causing many support issues since for example https://fedoraproject.org/wiki/Tboot
suggests

"You may download all of the ACM modules into /boot and list them all as 
modules in your grub.conf. tboot will pick the right module for your 
platform. "

I can't change that wiki page as edits are currently not allowed even if I 
create an account.

-Timo

Re: [tboot-devel] tboot not picking the right ACM module on Dell Latitude E5470

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

On Tue, 2020-03-31 at 23:27 +0300, Timo Lindfors wrote:
> Hi,
> 
> if I have the following ACM modules in /boot
> 
> 018c4c0bc64cad7c939061e111937849f61af395c9981a03ac4a10083058aa5d 
> 4th_gen_i5_i7_SINIT_75.BIN
> 0848adfea4c9479b1cd096aeda1d4a3afe309dd45ca43a1e8d8b3cf972c9c14f
> 6th_7th_gen_i5_i7-SINIT_79.bin
> 193fc2b763bae1b1eebaf15452b395fd5153043190eb61dd86e246914ee7d80e
> 6th_gen_i5_i7_SINIT_71.BIN
> 
> update-grub generates a configuration file like
> 
> echo    'Loading tboot 1.9.7 ...'
>           multiboot2      /tboot.gz logging=serial,memory
>           echo    'Loading Linux...
>           module2 /vmlinuz...
>           echo    'Loading initial ramdisk ...'
>           module2 /initrd.img...
>           echo    'Loading sinit 4th_gen_i5_i7_SINIT_75.BIN ...'
>           module2 /4th_gen_i5_i7_SINIT_75.BIN
>           echo    'Loading sinit 6th_7th_gen_i5_i7-SINIT_79.bin ...'
>           module2 /6th_7th_gen_i5_i7-SINIT_79.bin
>           echo    'Loading sinit 6th_gen_i5_i7_SINIT_71.BIN ...'
>           module2 /6th_gen_i5_i7_SINIT_71.BIN
> 
> Unfortunately if modules are ordered like this the machine will just 
> reboot after a while.
> 
> The machine boots correctly if I order "6th_gen" to be before 
> "6th_7th_gen" in the above list.
> 
> I'm not quite sure which part should be fixed here:
> 
> 1) Is this a bug in the file 6th_7th_gen? If yes, should it be somehow 
> blacklisted and/or documented so that users would avoid it?
> 
> 2) Is this a bug in tboot's logic that tries to pick a matching module? I 
> could not see anything wrong in the code.
> 
> 3) Should we fix this in the shell script that generates the configuration 
> file so that it orders the files "correctly"?
> 

Hi Timo

There is a bug in TBOOT that may results in overlapping loaded SINITs by
TBOOT's logs. That problem occurs when you load multiple SINITs in GRUB
and in most cases the last one will be corrupted. That's why, when TBOOT
executes GETSEC[SENTER] CPU fails on SINIT integrity check and resets
platform.

The workaround for that issue is to have only one SINIT in grub.cfg, so
in your scenario you should remove all SINITs except 6th_gen from /boot
and recreate grub.cfg

Thanks,
Lukasz

[tboot-devel] tboot not picking the right ACM module on Dell Latitude E5470

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

Hi,

if I have the following ACM modules in /boot

018c4c0bc64cad7c939061e111937849f61af395c9981a03ac4a10083058aa5d 
4th_gen_i5_i7_SINIT_75.BIN
0848adfea4c9479b1cd096aeda1d4a3afe309dd45ca43a1e8d8b3cf972c9c14f
6th_7th_gen_i5_i7-SINIT_79.bin
193fc2b763bae1b1eebaf15452b395fd5153043190eb61dd86e246914ee7d80e
6th_gen_i5_i7_SINIT_71.BIN

update-grub generates a configuration file like

echo    'Loading tboot 1.9.7 ...'
          multiboot2      /tboot.gz logging=serial,memory
          echo    'Loading Linux...
          module2 /vmlinuz...
          echo    'Loading initial ramdisk ...'
          module2 /initrd.img...
          echo    'Loading sinit 4th_gen_i5_i7_SINIT_75.BIN ...'
          module2 /4th_gen_i5_i7_SINIT_75.BIN
          echo    'Loading sinit 6th_7th_gen_i5_i7-SINIT_79.bin ...'
          module2 /6th_7th_gen_i5_i7-SINIT_79.bin
          echo    'Loading sinit 6th_gen_i5_i7_SINIT_71.BIN ...'
          module2 /6th_gen_i5_i7_SINIT_71.BIN

Unfortunately if modules are ordered like this the machine will just 
reboot after a while.

The machine boots correctly if I order "6th_gen" to be before 
"6th_7th_gen" in the above list.

I'm not quite sure which part should be fixed here:

1) Is this a bug in the file 6th_7th_gen? If yes, should it be somehow 
blacklisted and/or documented so that users would avoid it?

2) Is this a bug in tboot's logic that tries to pick a matching module? I 
could not see anything wrong in the code.

3) Should we fix this in the shell script that generates the configuration 
file so that it orders the files "correctly"?


Here's the cpu information and tboot version

cpu:
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 94
model name    : Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
stepping    : 3
microcode    : 0xcc
cpu MHz        : 844.213
cache size    : 8192 KB
physical id    : 0
siblings    : 8
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 22
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd
ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap
clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln
pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
mds swapgs taa itlb_multihit
bogomips    : 5424.00
clflush size    : 64
cache_alignment    : 64
address sizes    : 39 bits physical, 48 bits virtual
power management:

ii  tboot          1.9.7-0ubuntu1 amd64        Trusted Boot (tboot)


best regards,
Timo Lindfors

[tboot-devel] private key compromise in secure boot

[Mat <alt...@gm...>]

How would one design handling private key(used to sign image) compromise in
the secure/trusted boot solution on embedded devices like routers sold to
millions of customers?

I am looking for step-by-step instructions including how would patch these
devices in the event private key is leaked.

>

Re: [tboot-devel] Update on my tboot kernel signature verification work

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

On Mon, 2020-02-10 at 12:07 -0500, Paul Moore wrote:
> On Wed, Feb 5, 2020 at 12:58 PM Paul Moore (pmoore2) via tboot-devel
> <
> tbo...@li...
> > wrote:
> > ... I do have some interest in pursuing this on my own time, but considering all of the other demands on my time I'm not certain how much I will be able to contribute.
> 
> On a somewhat related topic, can anyone recommend a small, inexpensive
> system that has a TPM2 and supports Intel TXT on both UEFI and
> UEFI/CMS (legacy BIOS) boot?  Sadly all of my current personal
> crash-n-burn systems are TPM1.2 based.
> 
> 

You can check Intel NUC, search for one with vPro CPU, TPM2.0 and
possibility to connect serial console. For example NUC5i5MYHE meets that
requirements.

Thanks,
Lukasz

Re: [tboot-devel] Update on my tboot kernel signature verification work

[Paul M. <pa...@pa...>]

On Wed, Feb 5, 2020 at 12:58 PM Paul Moore (pmoore2) via tboot-devel
<tbo...@li...> wrote:
> ... I do have some interest in pursuing this on my own time, but considering all of the other demands on my time I'm not certain how much I will be able to contribute.

On a somewhat related topic, can anyone recommend a small, inexpensive
system that has a TPM2 and supports Intel TXT on both UEFI and
UEFI/CMS (legacy BIOS) boot?  Sadly all of my current personal
crash-n-burn systems are TPM1.2 based.

-- 
paul moore
www.paul-moore.com

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

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

Hi,


thanks Lukasz for your hints and advice on this mailing list,

thanks Paul for your comprehensive README.md at https://github.com/anuvu/tboot,


I was able to setup a LCP policy that checks integrity of tboot + cmdline and a VLP policy that checks integrity of kernel + cmdline and initramfs on my Supermicro X11SPM-TF server.


Regards,

Olivier
________________________________
De : Lukasz Hawrylko <luk...@li...>
Envoyé : jeudi 6 février 2020 10:22:49
À : LE ROY Olivier - Contractor; tbo...@li...
Objet : Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

On Wed, 2020-02-05 at 14:41 +0000, LE ROY Olivier - Contractor wrote:
> Hi Lukasz,
>
> > What exactly did you add to that policy in lcp-gen2 tool? LCP is a
> policy dedicated for SINIT, not for TBOOT.
> > The another approach is to create separate index for VLP (0x01C10131)
> and put VLP there.
>
> I understand better why there weren't any log for the LCP_ANY policy and why tboot expects a VLP.
> Thanks for the comprehensive answer.
> I am still learning to implement policies in TPM2.0, trying to transpose what was done in a previous TPM1.2 based project.
>
> > What do mean "doesn't seem to understand it"? With LCP_ANY SINIT will
> allow any MLE to be executed.
>
> I was following the recommendation to start with something simple, i.e. LCP_ANY.
> Presently, I am trying a list policy, with an MLE element which hash is the tboot.gz hash, to implement a VLP at 0x01c10131.
>
> TBOOT logs are as follows:
> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT: policy:
> TBOOT: unsupported version (1)
> TBOOT:     :reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
> TBOOT:      version: 2
>
> The policy was created using lcp-gen2 from tboot-1.9.9 python tools (tboot-1.9.11 has the same results).
> Do you have a hint why the generated policy has "version (1)" while tboot expects a version: 2?
>
> Regards,
>
> Olivier
>

MLE element goes to LCP and is consumed by SINIT, not TBOOT. You can't
provision VLP index with LCP.

To create VLP you have to use tb_polgen tool. Here is an example:

  # create policy
  tb_polgen --create --ctrl 0x00 --type continue vl.pol

  # add kernel and its cmdline hash, extend PCR19
  tb_polgen --add --num 0 --pcr 19 --hash image --cmdline "..." \
            --image bzImage

  # add initrd hash, extend PCR20
  tb_polgen --add --num 1 --pcr 20 --hash image --cmdline "" \
            --image initrd.img

If you want to create policy with MLE element you have to use lcp-gen2
tool and provision it to LCP index. But as I said, TBOOT has nothing to
do with it, you should not expect that TBOOT will measure itself :)

Thanks,
Lukasz

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

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

On Wed, 2020-02-05 at 14:41 +0000, LE ROY Olivier - Contractor wrote:
> Hi Lukasz,
> 
> > What exactly did you add to that policy in lcp-gen2 tool? LCP is a
> policy dedicated for SINIT, not for TBOOT. 
> > The another approach is to create separate index for VLP (0x01C10131)
> and put VLP there. 
> 
> I understand better why there weren't any log for the LCP_ANY policy and why tboot expects a VLP.
> Thanks for the comprehensive answer.
> I am still learning to implement policies in TPM2.0, trying to transpose what was done in a previous TPM1.2 based project.
> 
> > What do mean "doesn't seem to understand it"? With LCP_ANY SINIT will
> allow any MLE to be executed.
> 
> I was following the recommendation to start with something simple, i.e. LCP_ANY.
> Presently, I am trying a list policy, with an MLE element which hash is the tboot.gz hash, to implement a VLP at 0x01c10131.
> 
> TBOOT logs are as follows:
> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT: policy:
> TBOOT: unsupported version (1)
> TBOOT:     :reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
> TBOOT:      version: 2
> 
> The policy was created using lcp-gen2 from tboot-1.9.9 python tools (tboot-1.9.11 has the same results).
> Do you have a hint why the generated policy has "version (1)" while tboot expects a version: 2?
> 
> Regards,
> 
> Olivier
> 

MLE element goes to LCP and is consumed by SINIT, not TBOOT. You can't
provision VLP index with LCP.

To create VLP you have to use tb_polgen tool. Here is an example:

  # create policy
  tb_polgen --create --ctrl 0x00 --type continue vl.pol

  # add kernel and its cmdline hash, extend PCR19
  tb_polgen --add --num 0 --pcr 19 --hash image --cmdline "..." \
            --image bzImage

  # add initrd hash, extend PCR20
  tb_polgen --add --num 1 --pcr 20 --hash image --cmdline "" \
            --image initrd.img

If you want to create policy with MLE element you have to use lcp-gen2
tool and provision it to LCP index. But as I said, TBOOT has nothing to
do with it, you should not expect that TBOOT will measure itself :)

Thanks,
Lukasz
  

[tboot-devel] Update on my tboot kernel signature verification work

[Paul M. (pmoore2) <pm...@ci...>]

Hello all,

I wanted to provide a quick update on the TXT/sig project and point you
at it's new location on GitHub:

 * https://github.com/anuvu/tboot

... the TXT/sig changes can be found in the master branch.  In addition
to the code changes, I've included a README.md with a lot of information
on how to use the tboot signature verification code, as well as TXT and
tboot in general.  Even if you are not interested in using signed kernel
images, you may find the README.md documentation helpful.

Unfortunately for my TXT/sig efforts, there have been some changes in
the product I am working on and the TXT/sig capability is not expected
to be a critical part of the product.  This means my contributions going
forward are likely to be seriously diminished.  I do have some interest
in pursuing this on my own time, but considering all of the other
demands on my time I'm not certain how much I will be able to
contribute.  I've cleaned the existing patches up as much as time would
allow, and I believe they are in half-reasonable shape; if the tboot
community wants to merge them as they currently are, I'm happy to do
whatever I can on my end to make that happen.  If someone wants to take
these patches and build on top of them, that's fine too.  If there is
anything I can do to help, please let me know, just understand my time
is likely to be limited.

Beyond the TXT/sig patches, I believe the repo mentioned above contains
some other patches which I believe have standalone value:

* "all: ensure we can build on a modern system"

This patch allows tboot to successfully build with GCC v9.  I know there
have been other GCC related patches posted to the mailing list; it might
be worthwhile checking to see if this patch adds additional corrections.

* "lcptools-v2: add pconf2 policy element support"

Adds the ability to create a TPM2 PCONF policy element to the lcptools-
v2 tools.  I realize that there is a strong desire on the part of Intel
to move to the Python GUI tools, but for those of us who prefer the
command line lcptools-v2 tools this may be useful.

* "tboot: get the TPM extpol setting from the ACM"

This patch adds the ability to query the ACM during boot and adjust the
"extpol" setting based on the ACM's reported support (cmdline example:
"extpol=acm").

Hopefully some of this work will prove helpful, even if it is just the
information in README.md.  Thanks for all your help over the past year!

-Paul

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

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

Hi Lukasz,


> What exactly did you add to that policy in lcp-gen2 tool? LCP is a
policy dedicated for SINIT, not for TBOOT.

> The another approach is to create separate index for VLP (0x01C10131)
and put VLP there.


I understand better why there weren't any log for the LCP_ANY policy and why tboot expects a VLP.

Thanks for the comprehensive answer.

I am still learning to implement policies in TPM2.0, trying to transpose what was done in a previous TPM1.2 based project.


> What do mean "doesn't seem to understand it"? With LCP_ANY SINIT will
allow any MLE to be executed.


I was following the recommendation to start with something simple, i.e. LCP_ANY.

Presently, I am trying a list policy, with an MLE element which hash is the tboot.gz hash, to implement a VLP at 0x01c10131.


TBOOT logs are as follows:

TBOOT: reading Verified Launch Policy from TPM NV...
TBOOT:     :70 bytes read
TBOOT: policy:
TBOOT: unsupported version (1)
TBOOT:     :reading failed
TBOOT: reading Launch Control Policy from TPM NV...
TBOOT:     :70 bytes read
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:
TBOOT:      version: 2


The policy was created using lcp-gen2 from tboot-1.9.9 python tools (tboot-1.9.11 has the same results).

Do you have a hint why the generated policy has "version (1)" while tboot expects a version: 2?


Regards,

Olivier


________________________________
De : Lukasz Hawrylko <luk...@li...>
Envoyé : mardi 4 février 2020 17:15
À : LE ROY Olivier - Contractor; tbo...@li...
Objet : Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

Hi Olivier

On Tue, 2020-02-04 at 13:50 +0000, LE ROY Olivier - Contractor wrote:
> Hi,
>
> I am trying to get a simple LCP_ANY launch control policy to work on a Supermicro X11SPM-TF server with AOM-TPM-9670V TPM 2.0 module, without success. I get the "read error" from SINIT ACM each time.
>
> I am using tboot version 1.9.9.
>
> The LCP_ANY policy was created using two different ways:
>
> 1/ with lcp-gen2 python tools available in tboot sources,
>
> 2/ using a ready-made binary file, which is known to work, that is provided by Dr. G.W. Wettstein, and was contributed on this mailing list: (https://sourceforge.net/p/tboot/mailman/message/36477790/)
> Dump of the platform owner NVram definition with functional LCP_ANY policy:
>
> 00000016: 00 03 0b 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000032: 00 00 00 00 00 00 02 00 00 00 00 00 c8 00 08 30 ...............0
> 00000048: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000064: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000070: 00 00 00 00 00 00                               ................
>
> Attributes: 0x224000a
>     OWNERWRITE
>     POLICYWRITE
>     AUTHREAD
>     NO_DA
>     WRITTEN
> and NVram index to 0x1c10106 for my Cascade Lake Intel Xeon Silver 4216 CPU based chipset.
>
> These two policies fail with following tboot error:
> TBOOT: no SINIT provided by bootloader; using BIOS SINIT
> ...
> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV
> TBOOT:     :reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:

What exactly did you add to that policy in lcp-gen2 tool? LCP is a
policy dedicated for SINIT, not for TBOOT. There is a possibility to add
additional data to LCP called custom element. TBOOT reads LCP and than
checks if there is a custom element that it can use as its own policy
(called VLP). If it does not find any, it will throw "reading failed"
error.

The another approach is to create separate index for VLP (0x01C10131)
and put VLP there.

> The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram but doesn't seem to understand it.
>
> There are no reason indicated in the TBOOT log.

What do mean "doesn't seem to understand it"? With LCP_ANY SINIT will
allow any MLE to be executed.

As I write above - TBOOT does not parse and apply LCP it only searches
for embedded VLP, so you will not get any information in logs.

>
> One reason I think of could be that the NVram index 0x01C10106 wasn't defined with proper attributes.
> I define it with:
>
> tpm2_nvdefine -x 0x01c10106 -a 0x40000001 -s 70 -t 0x0204000a -P password

That looks correct.

Thanks,
Lukasz

Re: [tboot-devel] [RFC] tboot: kernel signature verification

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

On Tue, 2020-01-28 at 22:11 -0500, Paul Moore wrote:
> On Sat, Dec 21, 2019 at 12:00 PM Paul Moore (pmoore2) via tboot-devel
> <
> tbo...@li...
> > wrote:
> > On Fri, 2019-12-20 at 10:51 +0100, Lukasz Hawrylko wrote:
> > > On Tue, 2019-12-17 at 20:12 +0000, Paul Moore (pmoore2) wrote:
> > > > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > > > > On Thu, 2019-12-05 at 17:20 +0000, Paul Moore (pmoore2) wrote:
> > > > > > A question for discussion: if the VLP is loaded from it's own
> > > > > > nvindex,
> > > > > > and there is also a VLP present inside the LCP, which VLP do we
> > > > > > want
> > > > > > to
> > > > > > use?  I'm assuming it is the VLP we loaded directly, and not
> > > > > > from
> > > > > > inside
> > > > > > the LCP, but thought it was worth checking.
> > > > > > 
> > > > > 
> > > > > In "stock" TBOOT, VLP loaded from its own index has higher
> > > > > priority
> > > > > over
> > > > > one embedded in LCP, so I agree with you that here it should work
> > > > > like
> > > > > that.
> > > > 
> > > > I was thinking about this some more and I'm now wondering if we
> > > > should
> > > > only support the new TB_HTYPE_PECOFF hash type if it is present in a
> > > > VLP
> > > > loaded from the LCP.  In order to use the new signature support
> > > > admins
> > > > are going to need to generate a new LCP to contain the certificate
> > > > payload, why not store the VLP in the LCP at that point?
> > > 
> > > To be honest I don't like to add any kind of limitation when it is not
> > > needed. I think that in first approach we should allow to use any of
> > > possible configurations. If admins prefer to delete VLP index in TPM
> > > and
> > > put everything in LCP, they will do it, if, for any reasons, they want
> > > to keep VLP under its own index and put only certificate in LCP - why
> > > not, we support that case too :)
> > 
> > Okay, that's fine.  FWIW, it seems to me as if keeping the VLP in it's
> > own nvindex is a bit of a legacy solution, especially when we consider
> > the PECOFF signature validation.  In the PECOFF case you *must* have a
> > LCP to carry the certificates.  Not to mention the benefits of a signed
> > LCP allowing you to update the policy without updating the values stored
> > in the TPM nvindex (assuming the same policy signing key).
> 
> I've been playing with this and it would appear, at least on my TPM2
> system, that loading a VLP directly into the TPM conflicts with the
> LCP.
> 
> Lukasz, have you been able to load both a VLP and a LCP into a TPM2?
> 
> 

Yes, I had both VLP and LCP loaded in TPM 2.0, I don't think I had any
issues with that. How does this conflict look like in your platform?

Thanks,
Lukasz

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

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

Hi Olivier

On Tue, 2020-02-04 at 13:50 +0000, LE ROY Olivier - Contractor wrote:
> Hi,
> 
> I am trying to get a simple LCP_ANY launch control policy to work on a Supermicro X11SPM-TF server with AOM-TPM-9670V TPM 2.0 module, without success. I get the "read error" from SINIT ACM each time.
> 
> I am using tboot version 1.9.9.
> 
> The LCP_ANY policy was created using two different ways:
> 
> 1/ with lcp-gen2 python tools available in tboot sources,
> 
> 2/ using a ready-made binary file, which is known to work, that is provided by Dr. G.W. Wettstein, and was contributed on this mailing list: (https://sourceforge.net/p/tboot/mailman/message/36477790/)
> Dump of the platform owner NVram definition with functional LCP_ANY policy:
> 
> 00000016: 00 03 0b 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000032: 00 00 00 00 00 00 02 00 00 00 00 00 c8 00 08 30 ...............0
> 00000048: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000064: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000070: 00 00 00 00 00 00                               ................
> 
> Attributes: 0x224000a
>     OWNERWRITE
>     POLICYWRITE
>     AUTHREAD
>     NO_DA
>     WRITTEN
> and NVram index to 0x1c10106 for my Cascade Lake Intel Xeon Silver 4216 CPU based chipset.
> 
> These two policies fail with following tboot error:
> TBOOT: no SINIT provided by bootloader; using BIOS SINIT
> ...
> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV
> TBOOT:     :reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:

What exactly did you add to that policy in lcp-gen2 tool? LCP is a
policy dedicated for SINIT, not for TBOOT. There is a possibility to add
additional data to LCP called custom element. TBOOT reads LCP and than
checks if there is a custom element that it can use as its own policy
(called VLP). If it does not find any, it will throw "reading failed"
error.

The another approach is to create separate index for VLP (0x01C10131)
and put VLP there. 

> The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram but doesn't seem to understand it.
> 
> There are no reason indicated in the TBOOT log.

What do mean "doesn't seem to understand it"? With LCP_ANY SINIT will
allow any MLE to be executed.

As I write above - TBOOT does not parse and apply LCP it only searches
for embedded VLP, so you will not get any information in logs.

> 
> One reason I think of could be that the NVram index 0x01C10106 wasn't defined with proper attributes.
> I define it with:
> 
> tpm2_nvdefine -x 0x01c10106 -a 0x40000001 -s 70 -t 0x0204000a -P password

That looks correct.

Thanks,
Lukasz

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

[Paul M. (pmoore2) <pm...@ci...>]

On Tue, 2020-02-04 at 14:59 +0000, LE ROY Olivier - Contractor wrote:
> Hi,
> 
> thanks for this checklist , but unfortunately, I already observed
> these manipulations, without success.
> 
> I must say the same attempt was done on two Supermicro platforms
> (Brodwell based and Cascade Lake based) with same result:
> 
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed

I'm sorry to hear that didn't help.  Unfortunately the tboot code that
reads the LCP doesn't provide a lot of detailed information by default;
you may need to instrument the tboot code to debug this further.

If you haven't found it already, a good starting point is the
tboot/common/policy.c:set_policy() function.

> De : Paul Moore (pmoore2) <pm...@ci...>
> Envoyé : mardi 4 février 2020 15:44
> À : LE ROY Olivier - Contractor; tbo...@li...
> Objet : Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get
> LCP_ANY policy working on Supermicro X11SPM-TF
>  
> On Tue, 2020-02-04 at 13:50 +0000, LE ROY Olivier - Contractor wrote:
> > These two policies fail with following tboot error:
> > TBOOT: no SINIT provided by bootloader; using BIOS SINIT
> > ...
> > TBOOT: reading Verified Launch Policy from TPM NV...
> > TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV
> > TBOOT:     :reading failed
> > TBOOT: reading Launch Control Policy from TPM NV...
> > TBOOT:     :70 bytes read
> > TBOOT:     :reading failed
> > TBOOT: failed to read policy from TPM NV, using default
> > TBOOT: policy:
> > 
> > The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram
> but
> > doesn't seem to understand it.
> > 
> > There are no reason indicated in the TBOOT log.
> > 
> > One reason I think of could be that the NVram index 0x01C10106
> wasn't
> > defined with proper attributes.
> > I define it with:
> > 
> > tpm2_nvdefine -x 0x01c10106 -a 0x40000001 -s 70 -t 0x0204000a -P
> > password
> > 
> > Hoping someone will help me solve this problem,
> 
> Hi,
> 
> I'm not sure if this would help, but here is the process I typically
> follow when first getting TXT working on a TPM2 system.
> 
> 1. Reset / Clear the TPM and Take Ownership
> 
> This may not be strictly necessary if you can guarantee the TPM is in
> a
> known good state, but if you aren't certain and you don't have
> anything
> stored in the TPM I think a full TPM reset/clear is a smart idea.  You
> typically need to do the TPM clear via the BIOS menu system, and on
> some
> systems you need an admin/supervisor password set before you can
> access
> the TPM clear option.  Once the TPM is cleared you can take ownership
> with the following command:
> 
>   # tpm2_takeownership -o <password> -e <password> -l <password>
> 
> 2. Define the LCP Index
> 
> You already know how to do this, but after you clear the TPM you will
> need to redefine the NVRAM index on the TPM.
> 
>   # tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P <password> \
>                   -s 70 -t 0x204000A
> 
> 3. Write the TPM's Portion of the LCP into the TPM
> 
> The LCP is too large to fit into the TPM so we split into *.data and
> *.pol files when generating it via the lcp2_crtpol tool.  You'll want
> to
> pass the *.data file to tboot during boot and the *.pol file
> (lists.pol
> in the example below) you'll want to write to the TPM using the
> following command:
> 
>   # tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P <password> lists.pol
> 
> Hopefully that gets you closer to a working system.  I'm in the
> process
> of writing up some better notes, I'll send a note to the list when
> they
> are available.
> 
> Good luck!
> 
> -Paul
> 
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

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

Hi,


thanks for this checklist , but unfortunately, I already observed these manipulations, without success.


I must say the same attempt was done on two Supermicro platforms (Brodwell based and Cascade Lake based) with same result:


TBOOT:     :70 bytes read
TBOOT:     :reading failed


Regards,

Olivier le Roy



________________________________
De : Paul Moore (pmoore2) <pm...@ci...>
Envoyé : mardi 4 février 2020 15:44
À : LE ROY Olivier - Contractor; tbo...@li...
Objet : Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

On Tue, 2020-02-04 at 13:50 +0000, LE ROY Olivier - Contractor wrote:
> These two policies fail with following tboot error:
> TBOOT: no SINIT provided by bootloader; using BIOS SINIT
> ...
> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV
> TBOOT:     :reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
>
> The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram but
> doesn't seem to understand it.
>
> There are no reason indicated in the TBOOT log.
>
> One reason I think of could be that the NVram index 0x01C10106 wasn't
> defined with proper attributes.
> I define it with:
>
> tpm2_nvdefine -x 0x01c10106 -a 0x40000001 -s 70 -t 0x0204000a -P
> password
>
> Hoping someone will help me solve this problem,

Hi,

I'm not sure if this would help, but here is the process I typically
follow when first getting TXT working on a TPM2 system.

1. Reset / Clear the TPM and Take Ownership

This may not be strictly necessary if you can guarantee the TPM is in a
known good state, but if you aren't certain and you don't have anything
stored in the TPM I think a full TPM reset/clear is a smart idea.  You
typically need to do the TPM clear via the BIOS menu system, and on some
systems you need an admin/supervisor password set before you can access
the TPM clear option.  Once the TPM is cleared you can take ownership
with the following command:

  # tpm2_takeownership -o <password> -e <password> -l <password>

2. Define the LCP Index

You already know how to do this, but after you clear the TPM you will
need to redefine the NVRAM index on the TPM.

  # tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P <password> \
                  -s 70 -t 0x204000A

3. Write the TPM's Portion of the LCP into the TPM

The LCP is too large to fit into the TPM so we split into *.data and
*.pol files when generating it via the lcp2_crtpol tool.  You'll want to
pass the *.data file to tboot during boot and the *.pol file (lists.pol
in the example below) you'll want to write to the TPM using the
following command:

  # tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P <password> lists.pol

Hopefully that gets you closer to a working system.  I'm in the process
of writing up some better notes, I'll send a note to the list when they
are available.

Good luck!

-Paul

Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

[Paul M. (pmoore2) <pm...@ci...>]

On Tue, 2020-02-04 at 13:50 +0000, LE ROY Olivier - Contractor wrote:
> These two policies fail with following tboot error:
> TBOOT: no SINIT provided by bootloader; using BIOS SINIT
> ...
> TBOOT: reading Verified Launch Policy from TPM NV...
> TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV
> TBOOT:     :reading failed
> TBOOT: reading Launch Control Policy from TPM NV...
> TBOOT:     :70 bytes read
> TBOOT:     :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
> 
> The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram but
> doesn't seem to understand it.
> 
> There are no reason indicated in the TBOOT log.
> 
> One reason I think of could be that the NVram index 0x01C10106 wasn't
> defined with proper attributes.
> I define it with:
> 
> tpm2_nvdefine -x 0x01c10106 -a 0x40000001 -s 70 -t 0x0204000a -P
> password
> 
> Hoping someone will help me solve this problem,

Hi,

I'm not sure if this would help, but here is the process I typically
follow when first getting TXT working on a TPM2 system.

1. Reset / Clear the TPM and Take Ownership

This may not be strictly necessary if you can guarantee the TPM is in a
known good state, but if you aren't certain and you don't have anything
stored in the TPM I think a full TPM reset/clear is a smart idea.  You
typically need to do the TPM clear via the BIOS menu system, and on some
systems you need an admin/supervisor password set before you can access
the TPM clear option.  Once the TPM is cleared you can take ownership
with the following command:

  # tpm2_takeownership -o <password> -e <password> -l <password>

2. Define the LCP Index

You already know how to do this, but after you clear the TPM you will
need to redefine the NVRAM index on the TPM.

  # tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P <password> \
                  -s 70 -t 0x204000A

3. Write the TPM's Portion of the LCP into the TPM

The LCP is too large to fit into the TPM so we split into *.data and
*.pol files when generating it via the lcp2_crtpol tool.  You'll want to
pass the *.data file to tboot during boot and the *.pol file (lists.pol
in the example below) you'll want to write to the TPM using the
following command:

  # tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P <password> lists.pol

Hopefully that gets you closer to a working system.  I'm in the process
of writing up some better notes, I'll send a note to the list when they
are available.

Good luck!

-Paul

[tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF

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

Hi,

I am trying to get a simple LCP_ANY launch control policy to work on a Supermicro X11SPM-TF server with AOM-TPM-9670V TPM 2.0 module, without success. I get the "read error" from SINIT ACM each time.

I am using tboot version 1.9.9.

The LCP_ANY policy was created using two different ways:

1/ with lcp-gen2 python tools available in tboot sources,

2/ using a ready-made binary file, which is known to work, that is provided by Dr. G.W. Wettstein, and was contributed on this mailing list: (https://sourceforge.net/p/tboot/mailman/message/36477790/)
Dump of the platform owner NVram definition with functional LCP_ANY policy:

00000016: 00 03 0b 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00000032: 00 00 00 00 00 00 02 00 00 00 00 00 c8 00 08 30 ...............0
00000048: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000064: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00                               ................

Attributes: 0x224000a
    OWNERWRITE
    POLICYWRITE
    AUTHREAD
    NO_DA
    WRITTEN
and NVram index to 0x1c10106 for my Cascade Lake Intel Xeon Silver 4216 CPU based chipset.

These two policies fail with following tboot error:
TBOOT: no SINIT provided by bootloader; using BIOS SINIT
...
TBOOT: reading Verified Launch Policy from TPM NV...
TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV
TBOOT:     :reading failed
TBOOT: reading Launch Control Policy from TPM NV...
TBOOT:     :70 bytes read
TBOOT:     :reading failed
TBOOT: failed to read policy from TPM NV, using default
TBOOT: policy:


The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram but doesn't seem to understand it.

There are no reason indicated in the TBOOT log.

One reason I think of could be that the NVram index 0x01C10106 wasn't defined with proper attributes.
I define it with:

tpm2_nvdefine -x 0x01c10106 -a 0x40000001 -s 70 -t 0x0204000a -P password

Hoping someone will help me solve this problem,



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

Re: [tboot-devel] [RFC] tboot: kernel signature verification

[Paul M. <pa...@pa...>]

On Sat, Dec 21, 2019 at 12:00 PM Paul Moore (pmoore2) via tboot-devel
<tbo...@li...> wrote:
> On Fri, 2019-12-20 at 10:51 +0100, Lukasz Hawrylko wrote:
> > On Tue, 2019-12-17 at 20:12 +0000, Paul Moore (pmoore2) wrote:
> > > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote:
> > > > On Thu, 2019-12-05 at 17:20 +0000, Paul Moore (pmoore2) wrote:
> > > > > A question for discussion: if the VLP is loaded from it's own
> > > > > nvindex,
> > > > > and there is also a VLP present inside the LCP, which VLP do we
> > > > > want
> > > > > to
> > > > > use?  I'm assuming it is the VLP we loaded directly, and not
> > > > > from
> > > > > inside
> > > > > the LCP, but thought it was worth checking.
> > > > >
> > > >
> > > > In "stock" TBOOT, VLP loaded from its own index has higher
> > > > priority
> > > > over
> > > > one embedded in LCP, so I agree with you that here it should work
> > > > like
> > > > that.
> > >
> > > I was thinking about this some more and I'm now wondering if we
> > > should
> > > only support the new TB_HTYPE_PECOFF hash type if it is present in a
> > > VLP
> > > loaded from the LCP.  In order to use the new signature support
> > > admins
> > > are going to need to generate a new LCP to contain the certificate
> > > payload, why not store the VLP in the LCP at that point?
> >
> > To be honest I don't like to add any kind of limitation when it is not
> > needed. I think that in first approach we should allow to use any of
> > possible configurations. If admins prefer to delete VLP index in TPM
> > and
> > put everything in LCP, they will do it, if, for any reasons, they want
> > to keep VLP under its own index and put only certificate in LCP - why
> > not, we support that case too :)
>
> Okay, that's fine.  FWIW, it seems to me as if keeping the VLP in it's
> own nvindex is a bit of a legacy solution, especially when we consider
> the PECOFF signature validation.  In the PECOFF case you *must* have a
> LCP to carry the certificates.  Not to mention the benefits of a signed
> LCP allowing you to update the policy without updating the values stored
> in the TPM nvindex (assuming the same policy signing key).

I've been playing with this and it would appear, at least on my TPM2
system, that loading a VLP directly into the TPM conflicts with the
LCP.

Lukasz, have you been able to load both a VLP and a LCP into a TPM2?

-- 
paul moore
www.paul-moore.com

Re: [tboot-devel] [PATCH 1/1] Config.mk, safestringlib/makefile : allow tool overrides

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

On Fri, 2020-01-24 at 10:40 -0800, Christopher Clark wrote:
> To simplify integration of tboot into build systems such as
> OpenEmbeddded, use softer assignments and appends to define
> the build tool and flag variables.
> 
> Signed-off-by: Christopher Clark <
> chr...@gm...
> >
> 
> This patch is based on an OpenXT patch by Eric Chanudet:
> https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0001-config-Allow-build-system-integration.patch
> 
> 

Merged into upstream.

Thanks,
Lukasz

Re: [tboot-devel] [PATCH 2/2] safestringlib: fix warnings with GCC 6.4.0

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

On Fri, 2020-01-24 at 10:40 -0800, Christopher Clark wrote:
> Allow compilation with -Werror, which is enabled by default in OpenEmbedded.
> 
>  -Wunused-parameter fixes are macro related.
> 
>  -Wswitch-default fixes fall-throughs in format parsing that
>   would be caught during compilation by GCC (invalid formats).
> 
>  -Wdiscarded-qualifiers fixes add missing const around error messages
>   which are usually literals.
> 
>  -Wincompatible-pointer-types, mem_prim_set32() takes a uint32_t* from
>   wwmemset_s() wchar_t input without a cast.
> 
> Signed-off-by: Christopher Clark <
> chr...@gm...
> >
> Patch is by Eric Chanudet for OpenXT:
> https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0014-safestringlib-Attend-GCC-warnings.patch
> 
> 

Merged into upstream.

Thanks,
Lukasz

Re: [tboot-devel] Confused about the TXT register values

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

On Fri, 2020-01-24 at 12:34 -0300, Martin Galvan wrote:
> The TXT.STS values make more sense now, though the PCH DID is still
> incorrect. Is there a way to check whether TXT is enabled other than
> looking at SINIT.BASE and HEAP.BASE?

Please look at txt_verify_platform() function in verify.c there are few
checks that TBOOT does to verify if platform is properly configured for
measured launch.

You can also look at does_acmod_match_platform() in acmod.c, to see how
TBOOT checks if SINIT ACM matches platform. It compares CPU and PCH IDs
from SINIT header to actual values.

Thanks,
Lukasz

Re: [tboot-devel] tboot, TPM 2.0 on Dell PowerEdge R730

[Paul M. <pa...@pa...>]

On Fri, Jan 24, 2020 at 1:52 PM Christopher Clark
<chr...@gm...> wrote:
> On Tue, Jan 21, 2020 at 12:32 AM Lukasz Hawrylko
> <luk...@li...> wrote:
> >
> > On Wed, 2020-01-15 at 18:36 -0800, Christopher Clark wrote:
> > > Hello
> > >
> > > I am trying to boot with tboot and TPM 2.0 on a Dell PowerEdge R730
> > > and encountering reboot at SENTER every time with the following:
> > >
> > > TBOOT: TXT.ERRORCODE: 0xc0033451
> > > TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xd
> > >
> > > which SINIT_Errors-Broadwell-4th-gen.pdf indicates is: Invalid PMR configuration
> [...]
> >
> > Hi Christopher
> >
> > At first point please ensure that you are using latest SINIT, I know
> > that ACM team was working on similar issue, but I don't know if they
> > have already released version with the fix.
> >
> > If problem still exists with latest SINIT, you can try to modify TBOOT
> > and check if that helps. Please apply following patch over v1.9.11
> >
> > diff -r 003178d05f52 tboot/txt/txt.c
> > --- a/tboot/txt/txt.c   Tue Jan 14 11:54:11 2020 +0100
> > +++ b/tboot/txt/txt.c   Tue Jan 21 09:27:51 2020 +0100
> > @@ -559,6 +559,12 @@
> >              if (!vtd_disable_dma_remap(iter)) {
> >                  printk("    vtd_disable_dma_remap failed!\n");
> >              }
> > +            if (!vtd_disable_qie(iter)) {
> > +                printk("    vtd_disable_qie failed!\n");
> > +            }
> > +            if (!vtd_disable_ire(iter)) {
> > +                printk("    vtd_disable_ire failed!\n");
> > +            }
> >          }
> >      }
> >
>
> Hi Lukasz,
>
> Thanks for your reply and for the patch, and I can confirm that with
> the patch applied, tboot does proceed past the previous point it was
> triggering reboot and it no longer reports a PMR errorcode 0xc0033451.
>
> My next encounter was with a different error due to the wrong hash
> algorithm being selected by tboot. The TPM 2.0 on this machine (Dell
> don't sell TPM 1.2s for it any more) reports availability of both SHA1
> and SHA256, but the BIOS won't allow enabling TXT without configuring
> it to use SHA256, and then tboot was picking SHA1, which then tripped
> a mismatch failure.
>
> I've got it all the way to a successful launch with tboot 1.9.11 into
> Xen and dom0, once SHA256 is enabled as the hash algorithm with this
> basic patch:
>
> diff --git a/tboot/common/tpm_20.c b/tboot/common/tpm_20.c
> --- a/tboot/common/tpm_20.c
> +++ b/tboot/common/tpm_20.c
> @@ -2778,6 +2778,8 @@ static bool tpm20_init(struct tpm_if *ti)
>     return false;
>      }
>
> +    ti->cur_alg = TB_HALG_SHA256;
> +
>      if (handle2048 != 0)
>          goto out;

You might be able to skip the patch by simply specifying an 'extpol'
parameter on the tboot command line, for example: "extpol=sha256".

The patch linked below also adds support for "extpol=acm" which checks
the ACM for supported TPM2 extpol settings and selects one
automatically (it gives priority to the embedded policy which should
extend both the SHA1 and SHA256 PCR banks).

* https://github.com/pcmoore/misc-tboot/commit/130a8cb226d50aaba3f55bd7f0ab6daf25aa0a19

-- 
paul moore
www.paul-moore.com

Re: [tboot-devel] tboot, TPM 2.0 on Dell PowerEdge R730

[Christopher C. <chr...@gm...>]

On Tue, Jan 21, 2020 at 12:32 AM Lukasz Hawrylko
<luk...@li...> wrote:
>
> On Wed, 2020-01-15 at 18:36 -0800, Christopher Clark wrote:
> > Hello
> >
> > I am trying to boot with tboot and TPM 2.0 on a Dell PowerEdge R730
> > and encountering reboot at SENTER every time with the following:
> >
> > TBOOT: TXT.ERRORCODE: 0xc0033451
> > TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xd
> >
> > which SINIT_Errors-Broadwell-4th-gen.pdf indicates is: Invalid PMR configuration
[...]
>
> Hi Christopher
>
> At first point please ensure that you are using latest SINIT, I know
> that ACM team was working on similar issue, but I don't know if they
> have already released version with the fix.
>
> If problem still exists with latest SINIT, you can try to modify TBOOT
> and check if that helps. Please apply following patch over v1.9.11
>
> diff -r 003178d05f52 tboot/txt/txt.c
> --- a/tboot/txt/txt.c   Tue Jan 14 11:54:11 2020 +0100
> +++ b/tboot/txt/txt.c   Tue Jan 21 09:27:51 2020 +0100
> @@ -559,6 +559,12 @@
>              if (!vtd_disable_dma_remap(iter)) {
>                  printk("    vtd_disable_dma_remap failed!\n");
>              }
> +            if (!vtd_disable_qie(iter)) {
> +                printk("    vtd_disable_qie failed!\n");
> +            }
> +            if (!vtd_disable_ire(iter)) {
> +                printk("    vtd_disable_ire failed!\n");
> +            }
>          }
>      }
>

Hi Lukasz,

Thanks for your reply and for the patch, and I can confirm that with
the patch applied, tboot does proceed past the previous point it was
triggering reboot and it no longer reports a PMR errorcode 0xc0033451.

My next encounter was with a different error due to the wrong hash
algorithm being selected by tboot. The TPM 2.0 on this machine (Dell
don't sell TPM 1.2s for it any more) reports availability of both SHA1
and SHA256, but the BIOS won't allow enabling TXT without configuring
it to use SHA256, and then tboot was picking SHA1, which then tripped
a mismatch failure.

I've got it all the way to a successful launch with tboot 1.9.11 into
Xen and dom0, once SHA256 is enabled as the hash algorithm with this
basic patch:

diff --git a/tboot/common/tpm_20.c b/tboot/common/tpm_20.c
--- a/tboot/common/tpm_20.c
+++ b/tboot/common/tpm_20.c
@@ -2778,6 +2778,8 @@ static bool tpm20_init(struct tpm_if *ti)
    return false;
     }

+    ti->cur_alg = TB_HALG_SHA256;
+
     if (handle2048 != 0)
         goto out;


I also needed these two small OpenXT patches applied, for building
with gcc 6.4.0 and OpenEmbedded -- I've just posted them as
submissions to this list.

https://sourceforge.net/p/tboot/mailman/message/36908229/
OpenXT original:
https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0001-config-Allow-build-system-integration.patch

https://sourceforge.net/p/tboot/mailman/message/36908230/
OpenXT original:
https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0014-safestringlib-Attend-GCC-warnings.patch

Thanks again,

Christopher

[tboot-devel] [PATCH 2/2] safestringlib: fix warnings with GCC 6.4.0

[Christopher C. <chr...@gm...>]

Allow compilation with -Werror, which is enabled by default in OpenEmbedded.

 -Wunused-parameter fixes are macro related.

 -Wswitch-default fixes fall-throughs in format parsing that
  would be caught during compilation by GCC (invalid formats).

 -Wdiscarded-qualifiers fixes add missing const around error messages
  which are usually literals.

 -Wincompatible-pointer-types, mem_prim_set32() takes a uint32_t* from
  wwmemset_s() wchar_t input without a cast.

Signed-off-by: Christopher Clark <chr...@gm...>
Patch is by Eric Chanudet for OpenXT:
https://github.com/OpenXT/xenclient-oe/blob/fc13893594f684baea65b7ee09066a8ddb840b4d/recipes-security/tboot/tboot-1.9.9/0014-safestringlib-Attend-GCC-warnings.patch

diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/abort_handler_s.c
--- a/safestringlib/safeclib/abort_handler_s.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/abort_handler_s.c	Fri Jan 24 10:10:20 2020 -0800
@@ -67,6 +67,7 @@
 
 void abort_handler_s(const char *msg, void *ptr, errno_t error)
 {
+	(void) ptr;
 	slprintf("ABORT CONSTRAINT HANDLER: (%u) %s\n", error,
 		 (msg) ? msg : "Null message");
 	slabort();
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/ignore_handler_s.c
--- a/safestringlib/safeclib/ignore_handler_s.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/ignore_handler_s.c	Fri Jan 24 10:10:20 2020 -0800
@@ -64,7 +64,9 @@
 
 void ignore_handler_s(const char *msg, void *ptr, errno_t error)
 {
-
+	(void) ptr;
+	(void) error;
+	(void) msg;
 	sldebug_printf("IGNORE CONSTRAINT HANDLER: (%u) %s\n", error,
 		       (msg) ? msg : "Null message");
 	return;
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/safe_str_constraint.h
--- a/safestringlib/safeclib/safe_str_constraint.h	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/safe_str_constraint.h	Fri Jan 24 10:10:20 2020 -0800
@@ -48,12 +48,13 @@
  * Safe C Lib internal string routine to consolidate error handling
  */
 static inline void handle_error(char *orig_dest, rsize_t orig_dmax,
-                                char *err_msg, errno_t err_code)
+                                const char *err_msg, errno_t err_code)
 {
 #ifdef SAFECLIB_STR_NULL_SLACK
     /* null string to eliminate partial copy */
     while (orig_dmax) { *orig_dest = '\0'; orig_dmax--; orig_dest++; }
 #else
+    (void) orig_dmax;
     *orig_dest = '\0';
 #endif
 
@@ -62,12 +63,13 @@
 }
 
 static inline void handle_wc_error(wchar_t *orig_dest, rsize_t orig_dmax,
-                                char *err_msg, errno_t err_code)
+                                   const char *err_msg, errno_t err_code)
 {
 #ifdef SAFECLIB_STR_NULL_SLACK
     /* null string to eliminate partial copy */
     while (orig_dmax) { *orig_dest = L'\0'; orig_dmax--; orig_dest++; }
 #else
+    (void) orig_dmax;
     *orig_dest = L'\0';
 #endif
 
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/snprintf_support.c
--- a/safestringlib/safeclib/snprintf_support.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/snprintf_support.c	Fri Jan 24 10:10:20 2020 -0800
@@ -78,6 +78,7 @@
 			case '+' : // force a sign be used
 				index++; // skip the flag character
 				break;
+			default: break;
 			}
 			// check for and skip the optional field width
 			while ( format[index] != '\0' && format[index] >= '0' && format[index] <= '9') {
@@ -112,6 +113,7 @@
 			case 'z' :
 			case 't' : index++;
 			           break;
+			default: break;
 			}
 
 			// Recognize and record the actual modifier
@@ -212,6 +214,7 @@
 		case FMT_INT   :
 			retValue = 1;
 			break;
+		default: break;
 	}
 	return retValue;
 }
diff -r dcec96ce7d2c -r aed3b7861fb0 safestringlib/safeclib/wmemset_s.c
--- a/safestringlib/safeclib/wmemset_s.c	Fri Jan 24 10:03:42 2020 -0800
+++ b/safestringlib/safeclib/wmemset_s.c	Fri Jan 24 10:10:20 2020 -0800
@@ -98,7 +98,7 @@
         return (RCNEGATE(ESLEMAX));
     }
 
-    mem_prim_set32(dest, len, value);
+    mem_prim_set32((void*)dest, len, value);
 
     return (RCNEGATE(EOK));
 }