tboot-devel — Developer support

[tboot-devel] [PATCH 1/2] Remove poly1305 object files on clean

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

From: Timo Lindfors <tim...@ik...>

Signed-off-by: Timo Juhani Lindfors <tim...@ik...>
---
 tboot/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tboot/Makefile b/tboot/Makefile
index f6530ea..dbcfdf9 100644
--- a/tboot/Makefile
+++ b/tboot/Makefile
@@ -68,7 +68,7 @@ $(DISTDIR)/boot/$(TARGET).gz : $(TARGET).gz
 
 
 clean :
-	rm -f $(TARGET)* $(TARGET_LDS) *~ include/*~ include/txt/*~ *.o common/*~ txt/*~ common/*.o txt/*.o
+	rm -f $(TARGET)* $(TARGET_LDS) *~ include/*~ include/txt/*~ *.o common/*~ txt/*~ common/*.o txt/*.o common/poly1305/*.o
 	rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out
 
 
-- 
2.20.1

[tboot-devel] [PATCH] Support higher resolution monitors

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

From: Timo Lindfors <tim...@ik...>

Testing done: Boot tboot with a 2560x1440 monitor. Verify that no
output is visible without this patch, and that output is correct with
this patch. This was tested on an HP EliteDesk 800 G2 with BIOS
version 2.17.

Signed-off-by: Timo Juhani Lindfors <tim...@ik...>
---
 include/config.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/config.h b/include/config.h
index f75c508..8211975 100644
--- a/include/config.h
+++ b/include/config.h
@@ -120,8 +120,8 @@ extern char _end[];              /* end of tboot */
 #endif /* NO_TBOOT_LOGLVL */
 
 /* Framebuffer */
-#define FB_MAX_HRES 1920
-#define FB_MAX_VRES 1080
+#define FB_MAX_HRES 2560
+#define FB_MAX_VRES 1440
 #define FB_BPP 32
 
 #endif /* __CONFIG_H__ */
-- 
2.20.1

[tboot-devel] txt-acminfo segfaults

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

Hi,

txt-acminfo 5th_gen_i5_i7_SINIT_79.BIN

segfaults on my system:

Program received signal SIGSEGV, Segmentation fault.
does_acmod_match_platform (hdr=hdr@entry=0x7ffff7fc3000) at ../tboot/txt/acmod.c:590
590	    txt_heap_t *txt_heap = get_txt_heap();
(gdb) bt
#0  does_acmod_match_platform (hdr=hdr@entry=0x7ffff7fc3000) at ../tboot/txt/acmod.c:590
#1  0x00005555555552de in match_platform (hdr=0x7ffff7fc3000) at txt-acminfo.c:207
#2  main (argc=<optimized out>, argv=<optimized out>) at txt-acminfo.c:244
(gdb) x/4i $rip
=> 0x555555556612 <does_acmod_match_platform+50>:	movabs 0xfed30300,%rax
    0x55555555661c <does_acmod_match_platform+60>:	cmpb   $0x4,0x11(%rbp)
    0x555555556620 <does_acmod_match_platform+64>:	jbe    0x555555556660 <does_acmod_match_platform+128>
    0x555555556622 <does_acmod_match_platform+66>:	cmpl   $0x5,0x8(%rax)

It seems heap.h defines get_txt_heap() that refers to the real 
read_pub_config_reg() before it is #define'd later. After I fixed this I 
noticed that does_acmod_match_platform() then segfaults when it tries to 
dereference the pointer returned by get_txt_heap().

I guess txt-acminfo should mmap() TXT heap? Should we then modify 
get_txt_heap() to behave differently depending on the context or perhaps 
modify does_acmod_match_platform() to take a pointer to the TXT heap as an 
argument to avoid this?


-Timo

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

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

On Tue, 24 Aug 2021, Lukasz Hawrylko wrote:
> Patch with fix is already prepared, I am waiting for GRUB team to merge
> new multiboot2 module tag to publish it.
>
> In meantime, if you have a system when you are able to reproduce this
> issue, may I ask you to test the fix?

Sure. I applied these to the Debian packages

grub2 2.04-20
tboot 1.10.2+dfsg.0-1

and can now boot the system with multiple ACM modules in /boot. Is there 
something else I should test as well?

-Timo

Re: [tboot-devel] increase maximum supported framebuffer size?

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

Hi Timo

On Tue, 2021-08-24 at 10:40 +0300, Timo Lindfors wrote:
> Hi,
> 
> would it be possible to increase the maximum supported framebuffer size 
> or is memory usage an issue? I don't get any output using the following:
> 
> Framebuffer info:
>      address: 0xc0000000
>      pitch: 10240
>      width: 2560
>      height: 1440
>      bpp: 32
>      type: 1
> Not supported framebuffer size/bpp
> 
> This is an HP Elitedesk 800 G2 in UEFI-only mode.
> 

To be honest I don't have access to TXT enabled system with screen
bigger than 1920x1080 that's why I choose this value. You can try to
edit FB_MAX_HRES and FB_MAX_VRES in config.h and check if there are any
problems with bigger values.

Thanks,
Lukasz

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

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

Hi Timo

On Tue, 2021-08-24 at 12:19 +0300, Timo Lindfors wrote:
> [replying to an old email thread]
> 
> 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.
> > 
> > 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.
> 
> Just for the record I hit this issue again on HP Elitedesk 800 G2 in 
> UEFI-only mode. Loading
> 
> 2nd_gen_i5_i7_SINIT_51.BIN
> 3rd_gen_i5_i7_SINIT_67.BIN
> 4th_gen_i5_i7_SINIT_75.BIN
> 5th_gen_i5_i7_SINIT_79.BIN
> 6th_7th_gen_i5_i7-SINIT_79.bin
> 7th_8th_gen_i5_i7-SINIT_81.bin
> GM45_GS45_PM45_SINIT_51.BIN
> Q35_SINIT_51.BIN
> Q45_Q43_SINIT_51.BIN
> Xeon-5600-3500-SINIT-v1.1.bin
> Xeon-E7-8800-4800-2800-SINIT-v1.1.bin
> i5_i7_DUAL_SINIT_51.BIN
> i7_QUAD_SINIT_51.BIN
> 
> causes the system to reset at SENTER with
> 
> TBOOT: TXT.ERRORCODE: 0x80000007
> TBOOT: 	 processor error 0x7
> 

Patch with fix is already prepared, I am waiting for GRUB team to merge
new multiboot2 module tag to publish it.

In meantime, if you have a system when you are able to reproduce this
issue, may I ask you to test the fix?

You have to build GRUB2 with following patch:
https://lists.gnu.org/archive/html/grub-devel/2021-08/msg00073.html

Here is a patch for TBOOT that uses changes in GRUB:

diff -r 6736ab640540 -r 47180cb4492f tboot/common/boot.S
--- a/tboot/common/boot.S	Tue Jul 06 11:02:08 2021 +0200
+++ b/tboot/common/boot.S	Thu Aug 19 14:17:40 2021 +0200
@@ -113,6 +113,13 @@
                    FB_MAX_VRES,   /* height */ \
                    FB_BPP         /* depth */
 
+        /* Module load preference tag */
+        mb2ht_init MB2_HDR_TAG_MOD_LOAD_PREFERENCE,
MB2_HDR_TAG_OPTIONAL, \
+                   0x900000,      /* min_addr */ \
+                   0xFFFFFFFF,    /* max_addr */ \
+                   0x1000,        /* align */ \
+                   0              /* preference */
+
         /* Multiboot2 header end tag. */
         mb2ht_init MB2_HDR_TAG_END, MB2_HDR_TAG_REQUIRED
 
diff -r 6736ab640540 -r 47180cb4492f tboot/include/multiboot.h
--- a/tboot/include/multiboot.h	Tue Jul 06 11:02:08 2021 +0200
+++ b/tboot/include/multiboot.h	Thu Aug 19 14:17:40 2021 +0200
@@ -77,6 +77,7 @@
 #define MB2_HDR_TAG_CONSOLE_FLAGS	  4
 #define MB2_HDR_TAG_FRAMEBUFFER		  5
 #define MB2_HDR_TAG_MOD_ALIGN		  6
+#define MB2_HDR_TAG_MOD_LOAD_PREFERENCE 11
 
 #define MB2_HDR_TAG_REQUIRED      0
 #define MB2_HDR_TAG_OPTIONAL		  1


If this works, I think that there is no need to change anything in the
documentation, but just submit the patch to fix that issue.

Thanks,
Lukasz

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

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

[replying to an old email thread]

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.
>
> 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.

Just for the record I hit this issue again on HP Elitedesk 800 G2 in 
UEFI-only mode. Loading

2nd_gen_i5_i7_SINIT_51.BIN
3rd_gen_i5_i7_SINIT_67.BIN
4th_gen_i5_i7_SINIT_75.BIN
5th_gen_i5_i7_SINIT_79.BIN
6th_7th_gen_i5_i7-SINIT_79.bin
7th_8th_gen_i5_i7-SINIT_81.bin
GM45_GS45_PM45_SINIT_51.BIN
Q35_SINIT_51.BIN
Q45_Q43_SINIT_51.BIN
Xeon-5600-3500-SINIT-v1.1.bin
Xeon-E7-8800-4800-2800-SINIT-v1.1.bin
i5_i7_DUAL_SINIT_51.BIN
i7_QUAD_SINIT_51.BIN

causes the system to reset at SENTER with

TBOOT: TXT.ERRORCODE: 0x80000007
TBOOT: 	 processor error 0x7

Loading only sinit 6th_7th_gen_i5_i7-SINIT_79.bin works:

TBOOT: checking if module  is an SINIT for this platform...
TBOOT: chipset production fused: 1
TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
TBOOT: processor family/model/stepping: 0x506e3
TBOOT: platform id: 0x4000000000000
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: SINIT matches platform
...
TBOOT: SINIT ACM successfully returned...

Could you try to contact again Fedora to get the wiki page fixed? It is 
still misleading people into putting all ACMs to /boot. I could not figure
out how to modify the wiki as it seems to be very restricted due to spam 
challenges.

Should we fix ./tboot/20_linux_tboot to complain if multiple ACMs are 
present? I would really prefer an error message over a system reset that 
is difficult to diagnose without serial console. Or should 20_linux_tboot 
try to automatically select the correct ACM? Or perhaps even create one 
boot entry per ACM to some submenu?

-Timo

[tboot-devel] increase maximum supported framebuffer size?

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

Hi,

would it be possible to increase the maximum supported framebuffer size 
or is memory usage an issue? I don't get any output using the following:

Framebuffer info:
     address: 0xc0000000
     pitch: 10240
     width: 2560
     height: 1440
     bpp: 32
     type: 1
Not supported framebuffer size/bpp

This is an HP Elitedesk 800 G2 in UEFI-only mode.

-Timo

Re: [tboot-devel] SSL3 compliance updates

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

Hi Tony

On Thu, 2021-06-24 at 10:32 -0400, Tony Camuso wrote:
> While SSL3 will provide backward compliance for deprecated
> functions for a while, there are a number of them in tboot
> that must be updated before backwards compliance is dropped
> in SSL3.
> 
> Is there an ETA for SSL3 compliance?


Please keep in mind that OpenSSL 3.0 has not been released yet, it's
currently on release candidate state.

TBOOT's code refactoring to be compliant with OpenSSL 3.0 is scheduled
for next release. I expect that it will be ready in August 2021. This
release will NOT drop compatibility with OpenSSL 1.1 and I suggest to
use this version till version 3.0 become stable.

Thanks,
Lukasz

[tboot-devel] SSL3 compliance updates

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

While SSL3 will provide backward compliance for deprecated
functions for a while, there are a number of them in tboot
that must be updated before backwards compliance is dropped
in SSL3.

Is there an ETA for SSL3 compliance?

[tboot-devel] Issue with grub2-2.02-0.86 and tboot-1.9.11

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

Hi,


 I have an issue with grub2-2.02-0.86 which I hadn't with grub2-2.02-0.80.


TBOOT: Error: Linux setup sectors 212 exceed maximum limitation 64.


Has anyone experienced the same error?


Cordialement / regards,

Olivier le Roy (contractor)

HW – SW development engineer
Thales LAS France

Re: [tboot-devel] Tboot on Intel NUC8i7HVK and Fedora 33

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

On Thu, 2021-03-25 at 00:16 +0000, Oliver, Dario N wrote:
> Hi Lukasz,
> 
> I am having some problems to get that custom grub running with Secure Boot.
> I am using an Hyper-V VM with Fedora 33 to test this, after having to reinstall the OS twice in my NUC.
> I guess the end result will be the same in the VM and the NUC without TXT support.
> 
> My build instructions for grub are represented in the following Dockerfile:
> 
> FROM fedora:33
> RUN dnf install -y git autoconf automake gettext-devel bison \
>                    findutils pkgconf-pkg-config python-unversioned-command \
>                    patch git-merge-changelog gcc flex
> RUN git clone https://git.savannah.gnu.org/git/grub.git
> WORKDIR grub
> RUN ./bootstrap && ./configure --with-platform=efi --target=x86_64 && make
> 
> Then, the process I follow to install it in my VM are:
> 
> grub-install --efi-directory=/boot/efi
> /usr/local/sbin/grub-mkconfig -o /boot/grub/grub.cfg
> 
> After this, if I disable secure boot on the VM, my custom grub (in /boot/efi/EFI/grub/grubx64.efi) gets called in the boot chain.
> But if I enable secure boot, the default fedora bootloader is called (/boot/efi/EFI/fedora/grubx64.efi) 
> To sign my custom grub, I am using the following (I know that it works for kernels, not sure for grub):
> 
> dnf install -y sbsigntools
> cat > openssl.cnf << EOF
> [ req ]
> distinguished_name      = req_distinguished_name
> x509_extensions         = v3
> string_mask             = utf8only
> prompt                  = no
> [ req_distinguished_name ]
> countryName             = US
> stateOrProvinceName     = OR
> localityName            = Hillsboro
> 0.organizationName      = Organization
> commonName              = Secure Boot Signing
> emailAddress            = sec...@te...
> [ v3 ]
> subjectKeyIdentifier    = hash
> authorityKeyIdentifier  = keyid:always,issuer
> basicConstraints        = critical,CA:FALSE
> extendedKeyUsage        = codeSigning,1.3.6.1.4.1.311.10.3.6
> nsComment               = "OpenSSL Generated Certificate"
> EOF
> openssl req -config ./openssl.cnf \
>         -new -x509 -newkey rsa:2048 \
>         -nodes -days 3650 -outform DER \
>         -keyout MOK.key \
>         -out MOK.der
> openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem        
> sbsign --key MOK.key --cert MOK.pem \
>        --output ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi
> cp ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi
> mokutil --import MOK.der
> 
> After the reboot, I do Mok Management to import the key.
> But the system keeps booting with the  /boot/efi/EFI/grub/grubx64.efi Instead of my custom one.
> 
> Just to see what happens, I replaced the fedora bootloader with my custom one, and I got the following error:
> 
> error: verification requested but nobody cares: (hd0,gpt2)/grub/x86_64-efi/normal.mod
> Entering rescue mode
> grub rescue>
> 
> Any hints on what is happening? 

Looks like you did everything correct, I am not quite sure how grub-
install works, if it copies GRUB modules as standalone files you may
have to sign them too. Please try to install GRUB using grub-mkimage
command. That allows to include all required modules in GRUB binary,
here is an example usage:

./grub-mkimage -d grub-core -O x86_64-efi -o grubx64.efi -p "/EFI/BOOT"
echo all_video boot btrfs cat chain configfile echo efifwsetup efinet
ext2 fat font gfxmenu gfxterm gzio halt hfsplus iso9660 jpeg loadenv lvm
mdraid09 mdraid1x minicmd normal part_apple part_msdos part_gpt
password_pbkdf2 png reboot search search_fs_uuid search_fs_file
search_label sleep syslinuxcfg test tftp regexp video xfs relocator
multiboot2 linux efinet tftp serial shim_lock multiboot

As a result you will get grubx64.efi file that you can sign and copy to
/boot partition replacing Fedora's GRUB.

I have prepared for you demo with GRUB and TBOOT that should work under
Secure Boot enabled systems [1]. You can copy all files to any USB stick
and try boot your NUC from it. Of course you will have to add key to MOK
database. You can use for that mmx64.efi tool, key that was used to sign
binaries from the demo is also included.

[1] https://cloud.hawrylko.pl/s/gVD4pFQehDaNmbp

Lukasz

Re: [tboot-devel] Tboot on Intel NUC8i7HVK and Fedora 33

[Oliver, D. N <dar...@in...>]

Hi Lukasz,

I am having some problems to get that custom grub running with Secure Boot.
I am using an Hyper-V VM with Fedora 33 to test this, after having to reinstall the OS twice in my NUC.
I guess the end result will be the same in the VM and the NUC without TXT support.

My build instructions for grub are represented in the following Dockerfile:

FROM fedora:33
RUN dnf install -y git autoconf automake gettext-devel bison \
                   findutils pkgconf-pkg-config python-unversioned-command \
                   patch git-merge-changelog gcc flex
RUN git clone https://git.savannah.gnu.org/git/grub.git
WORKDIR grub
RUN ./bootstrap && ./configure --with-platform=efi --target=x86_64 && make

Then, the process I follow to install it in my VM are:

grub-install --efi-directory=/boot/efi
/usr/local/sbin/grub-mkconfig -o /boot/grub/grub.cfg

After this, if I disable secure boot on the VM, my custom grub (in /boot/efi/EFI/grub/grubx64.efi) gets called in the boot chain.
But if I enable secure boot, the default fedora bootloader is called (/boot/efi/EFI/fedora/grubx64.efi) 
To sign my custom grub, I am using the following (I know that it works for kernels, not sure for grub):

dnf install -y sbsigntools
cat > openssl.cnf << EOF
[ req ]
distinguished_name      = req_distinguished_name
x509_extensions         = v3
string_mask             = utf8only
prompt                  = no
[ req_distinguished_name ]
countryName             = US
stateOrProvinceName     = OR
localityName            = Hillsboro
0.organizationName      = Organization
commonName              = Secure Boot Signing
emailAddress            = sec...@te...
[ v3 ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
basicConstraints        = critical,CA:FALSE
extendedKeyUsage        = codeSigning,1.3.6.1.4.1.311.10.3.6
nsComment               = "OpenSSL Generated Certificate"
EOF
openssl req -config ./openssl.cnf \
        -new -x509 -newkey rsa:2048 \
        -nodes -days 3650 -outform DER \
        -keyout MOK.key \
        -out MOK.der
openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem        
sbsign --key MOK.key --cert MOK.pem \
       --output ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi
cp ./grubx64.efi /boot/efi/EFI/grub/grubx64.efi
mokutil --import MOK.der

After the reboot, I do Mok Management to import the key.
But the system keeps booting with the  /boot/efi/EFI/grub/grubx64.efi Instead of my custom one.

Just to see what happens, I replaced the fedora bootloader with my custom one, and I got the following error:

error: verification requested but nobody cares: (hd0,gpt2)/grub/x86_64-efi/normal.mod
Entering rescue mode
grub rescue>

Any hints on what is happening? 

[tboot-devel] Announcement - TrenchBoot Developers Forum

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

I would like to announce that TrenchBoot Developers Forum will take
place on March 24th at 16:00 GMT

For more details and agenda please refer to
https://trenchboot.org/tdf-schedule.html

Lukasz

Re: [tboot-devel] Tboot on Intel NUC8i7HVK and Fedora 33

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

On Fri, 2021-03-19 at 17:51 +0000, Oliver, Dario N wrote:
> I could not find any docs on what to do after installing 2.x as regards Secure Boot.
> Should I sign that with my own key and perform Secure Boot customization?
> Can I use the Machine Owner Keys (MOK) feature of the Linux Shim to get that verified?
> After rebooting with Secure Boot enabled, I got the error messages saying that multiboot2 and relocator could not be found, which is weird because I still have them installed in "/boot/efi/EFI/fedora/x86_64-efi/"

If you 'make all' TBOOT, you should get tboot.mb2 file inside tboot
folder. That binary can be signed with standard sbsign tool and then
loaded from GRUB2 using multiboot2.

Looks like Fedora still does not allow to run multiboot2 kernels when
Secure Boot is enabled. You should try to build GRUB2 from the upstream
and then check if you will be able to boot signed tboot.mb2 file. If you
face any issues I can help you and setup QEMU environment where you will
be able to check how it works.TXT in QEMU does not work, but at least we
should get into point where TBOOT starts and complains that platform is
incompatible.

I suggest to use MOK, however custom PK or KEK should also work.
Generate your own key, provision it to MOK database and sign tboot.mb2

Thanks,
Lukasz

Re: [tboot-devel] Tboot on Intel NUC8i7HVK and Fedora 33

[Oliver, D. N <dar...@in...>]

I am in for testing the 2.x branch with Secure Boot support.

Run into a couple of issues while building:
1. make world fails because of missing README file (it should be README.md?)
2. generated 20_linux_tboot still say tboot version is 1.9.12 (tboot_version="1.9.12")

Anyways, this Dockerfile gets it built:

FROM fedora:33
RUN dnf install -y mercurial-py3 trousers-devel openssl-devel zlib-devel make gcc perl-interpreter
RUN hg clone http://hg.code.sf.net/p/tboot/code -r 2.x tboot-code
WORKDIR tboot-code
RUN cp README.md README && make world

I could not find any docs on what to do after installing 2.x as regards Secure Boot.
Should I sign that with my own key and perform Secure Boot customization?
Can I use the Machine Owner Keys (MOK) feature of the Linux Shim to get that verified?
After rebooting with Secure Boot enabled, I got the error messages saying that multiboot2 and relocator could not be found, which is weird because I still have them installed in "/boot/efi/EFI/fedora/x86_64-efi/"

Re: [tboot-devel] Tboot on Intel NUC8i7HVK and Fedora 33

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

Hi Oliver

On Thu, 2021-03-18 at 22:29 +0000, Oliver, Dario N wrote:
> So, I need to run with Secure Boot disabled.

TBOOT will not work with Secure Boot, when Secure Boot is enabled, GRUB
has to verify signature of all components that are going to be launched.
As tboot.gz file does not support signing, it is unable to use it with
Secure Boot.

There is an experimental implementation of Secure Boot support in TBOOT,
it is not officially released, but you can look at 2.x branch if you
want to test it by yourself.

> ***********************************************************
>          TXT measured launch: TRUE
>          secrets flag set: FALSE
> ***********************************************************
> unable to find TBOOT log
> 
> From that output, I guessed that I can do a measured launch ("TXT measured launch: TRUE"). But I wanted to double check that.
> According to [1], I guessed that I need SMX (Safer Mode Extensions) in my CPU to actually do a Measured Launch (although this is not mentioned in any place in tboot docs)
> Unfortunately, cpuid say that my hardware does not support SMX:
> 
> [root@localhost test]# cpuid | grep SMX
>       SMX: safer mode extensions              = false

That's a misleading message, "TXT measured launch" should be false, I
guess that because TXT is not available in your platform, txt-stat reads
some garbage from TXT registers space and by mistake interprets that as
"TXT measured launch: TRUE".

If your CPU does not support SMX there is no possibility to do TXT
measured launch.

> Questions
> ========
> 
> 1. Any way to test tboot in hardware that does not support SMX/TXT? Any simulator available?

It depends what do you want to test. Without TXT you can only do what
you already did - load TBOOT via multiboot2, verify that platform is not
TXT capable and fallback to standard Linux boot.

> 2. Do I actually need SMX to do a Measured Launch? Or is the presence of "TXT measured launch: TRUE" string the txt-stat enough to say that my hardware supports it?

In general, you can measure Linux during boot process without SMX,
however the idea of TBOOT is to use TXT to do a measured launch and TXT
requires SMX. No SMX -> no TXT -> TBOOT will not measure anything.

As I point earlier, this message is misleading, your hardware does not
support TXT because "TBOOT: ERR: CPU does not support SMX".

> 3. Is the invalid tboot generated grub configuration a bug? If so, where should I submit it?

Looks like a bug, I will take care of it.

> 4. Am I using the correct SINIT ACM module? Is my resulting txt-stat output the expected one for my scenario?

TBOOT: chipset ids: vendor: 0x8086, device: 0xb006, revision: 0x1
[...]
TBOOT:   1 ACM chipset id entries:
TBOOT:       vendor: 0x8086, device: 0xb008, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT:   chipset id mismatch

Provided SINIT does not support your platform, chipset ids do not match.
Nevertheless, it does not change anything, without SMX you can't run
SINIT.

Thanks,
Lukasz

[tboot-devel] Tboot on Intel NUC8i7HVK and Fedora 33

[Oliver, D. N <dar...@in...>]

Hello! 

I recently went over the experience of installing, configuring and running tboot, and I want to document my experience in this thread and ask some questions.
My setup consists on the following:

1. Intel NUC8i7HVK
2. Linux Kernel 5.8.15
3. tboot-1.9.11-2.fc33.x86_64

My first step was to figure out if my hardware supports a Measured Launch. For that, I guessed that txt-info would help.
The problem is txt-info needs access to /dev/mem, which is forbidden by the Kernel Lockdown functionality, which is turned on by default with my kernel version when Secure Boot is detected.
So, txt-info doesn't work unless Kernel Lockdown is disabled. A way of reproduce this is to boot with Secure Boot disabled, run txt-info successfully, enable Kernel Lockdown, and try to run txt-info again:

[root@localhost test]# mokutil --sb-state
SecureBoot disabled
[root@localhost test]# cat /sys/kernel/security/lockdown
[none] integrity confidentiality
[root@localhost test]# sudo txt-stat
Intel(r) TXT Configuration Registers:
        STS: 0x00000083
        ....
[root@localhost test]# echo integrity > /sys/kernel/security/lockdown
[root@localhost test]# txt-stat
ERROR: cannot open /dev/mem

So, I need to run with Secure Boot disabled. The output of txt-stat is the following:

[root@localhost test]# txt-stat
Intel(r) TXT Configuration Registers:
        STS: 0x00000083
            senter_done: TRUE
            sexit_done: TRUE
            mem_config_lock: FALSE
            private_open: TRUE
            locality_1_open: FALSE
            locality_2_open: FALSE
        ESTS: 0x00
            txt_reset: FALSE
        E2STS: 0x0000000000000004
            secrets: FALSE
        ERRORCODE: 0x00000000
        DIDVID: 0x00000001b0068086
            vendor_id: 0x8086
            device_id: 0xb006
            revision_id: 0x1
        FSBIF: 0xffffffffffffffff
        QPIIF: 0x000000009d003000
        SINIT.BASE: 0x00000000
        SINIT.SIZE: 0B (0x0)
        HEAP.BASE: 0x00000000
        HEAP.SIZE: 0B (0x0)
        DPR: 0x0000000000000000
            lock: FALSE
            top: 0x00000000
            size: 0MB (0B)
        PUBLIC.KEY:
            2d 67 dd d7 5e f9 33 92 66 a5 6f 27 18 95 55 ae
            77 a2 b0 de 77 42 22 e5 de 24 8d be b8 e3 3d d7

***********************************************************
         TXT measured launch: TRUE
         secrets flag set: FALSE
***********************************************************
unable to find TBOOT log

>From that output, I guessed that I can do a measured launch ("TXT measured launch: TRUE"). But I wanted to double check that.
According to [1], I guessed that I need SMX (Safer Mode Extensions) in my CPU to actually do a Measured Launch (although this is not mentioned in any place in tboot docs)
Unfortunately, cpuid say that my hardware does not support SMX:

[root@localhost test]# cpuid | grep SMX
      SMX: safer mode extensions              = false

Anyways, the tboot docs say that it will fall-through to a non-TXT boot in the case that it is not supported [2].
So, I just set it up to check what happened. 

I got my 8th_9th_gen_i5_i7-SINIT_81.zip SINIT ACM module from [3], unzipped it and copy the bin file to /boot, and updated that grub configuration.
After the initial boot, I got the error message that multiboot2 and relocator could not be found. So I followed the docs on how to install them. In Fedora they are provided by the grub2-efi-x64-modules package

After reboot and selecting tboot in the grub menu, boot failed and got a recovery shell.
By inspecting the generated /run/initramfs/rdsosreport.txt, the relevant error message I can see is:

systemctl[509]: Failed to switch root: Specified switch root path '/sysroot' does not seems to be an OS tree. os-release file is missing.

By this I guess that the generated tboot generated grub configuration is broken.
After visual inspection and manual edit of the grub.cfg file, I was able to get a valid configuration (rootflags was missing)

[root@localhost fedora]# diff grub.cfg grub.cfg.bak
206c206
<       module2 /vmlinuz-5.8.15-301.fc33.x86_64 root=UUID=f9f79342-5c5b-445e-ac3a-b4731f57e6e2 ro rootflags=subvol=root rhgb quiet intel_iommu=on noefi
---
>       module2 /vmlinuz-5.8.15-301.fc33.x86_64 root=UUID=f9f79342-5c5b-445e-ac3a-b4731f57e6e2 ro rhgb quiet intel_iommu=on noefi

And after that, I got the following tboot log

[root@localhost fedora]# txt-stat
Intel(r) TXT Configuration Registers:
        STS: 0x00000083
            senter_done: TRUE
            sexit_done: TRUE
            mem_config_lock: FALSE
            private_open: TRUE
            locality_1_open: FALSE
            locality_2_open: FALSE
        ESTS: 0x00
            txt_reset: FALSE
        E2STS: 0x0000000000000004
            secrets: FALSE
        ERRORCODE: 0x00000000
        DIDVID: 0x00000001b0068086
            vendor_id: 0x8086
            device_id: 0xb006
            revision_id: 0x1
        FSBIF: 0xffffffffffffffff
        QPIIF: 0x000000009d003000
        SINIT.BASE: 0x00000000
        SINIT.SIZE: 0B (0x0)
        HEAP.BASE: 0x00000000
        HEAP.SIZE: 0B (0x0)
        DPR: 0x0000000000000000
            lock: FALSE
            top: 0x00000000
            size: 0MB (0B)
        PUBLIC.KEY:
            2d 67 dd d7 5e f9 33 92 66 a5 6f 27 18 95 55 ae
            77 a2 b0 de 77 42 22 e5 de 24 8d be b8 e3 3d d7

***********************************************************
         TXT measured launch: TRUE
         secrets flag set: FALSE
***********************************************************
TBOOT log:
         max_size=32706
         zip_count=0
         curr_pos=5308
         buf:
TBOOT: *********************** TBOOT ***********************
TBOOT:    2019-11-25 16:00 +0200 1.9.11
TBOOT: *****************************************************
TBOOT: command line: logging=serial,memory
TBOOT: IA32_FEATURE_CONTROL_MSR: 00000005
TBOOT: ERR: CPU does not support SMX
TBOOT: IA32_FEATURE_CONTROL_MSR: 00000005
TBOOT: ERR: CPU does not support SMX
TBOOT: BSP is cpu 0
TBOOT: original e820 map:
TBOOT:  0000000000000000 - 0000000000058000  (1)
TBOOT:  0000000000058000 - 0000000000059000  (2)
TBOOT:  0000000000059000 - 000000000009e000  (1)
TBOOT:  000000000009e000 - 0000000000100000  (2)
TBOOT:  0000000000100000 - 0000000077a3e000  (1)
TBOOT:  0000000077a3e000 - 0000000077a3f000  (4)
TBOOT:  0000000077a3f000 - 0000000077a40000  (2)
TBOOT:  0000000077a40000 - 000000007e6d5000  (1)
TBOOT:  000000007e6d5000 - 000000007eb99000  (2)
TBOOT:  000000007eb99000 - 000000007ebf8000  (3)
TBOOT:  000000007ebf8000 - 000000007ec58000  (4)
TBOOT:  000000007ec58000 - 000000007f72c000  (2)
TBOOT:  000000007f72c000 - 000000007f7fe000  (20)
TBOOT:  000000007f7fe000 - 000000007f7ff000  (1)
TBOOT:  000000007f7ff000 - 0000000080000000  (2)
TBOOT:  00000000e0000000 - 00000000f0000000  (2)
TBOOT:  00000000fe000000 - 00000000fe011000  (2)
TBOOT:  00000000fec00000 - 00000000fec01000  (2)
TBOOT:  00000000fed00000 - 00000000fed01000  (2)
TBOOT:  00000000fee00000 - 00000000fee01000  (2)
TBOOT:  00000000ff000000 - 0000000100000000  (2)
TBOOT:  0000000100000000 - 000000027f000000  (1)
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: 0xc000000000000
TBOOT:   1 ACM chipset id entries:
TBOOT:       vendor: 0x8086, device: 0xb008, flags: 0x1, revision: 0x1, extended: 0x0
TBOOT:   chipset id mismatch
TBOOT: checking if module  is an SINIT for this platform...
TBOOT:   ACM size mismatch: acmod_size=2ae9c02, acm_hdr->size*4=c0c0c0c0
TBOOT: no SINIT AC module found
TBOOT: TXT.SINIT.BASE: 0x0
TBOOT: TXT.SINIT.SIZE: 0x0 (0)
TBOOT: SINIT ACM not provided.
TBOOT: reserving tboot memory log (60000 - 67fff) in e820 table
TBOOT: replaced memory map:
TBOOT:  0000000000000000 - 0000000000058000  (1)
TBOOT:  0000000000058000 - 0000000000059000  (2)
TBOOT:  0000000000059000 - 0000000000060000  (1)
TBOOT:  0000000000060000 - 0000000000068000  (2)
TBOOT:  0000000000068000 - 000000000009e000  (1)
TBOOT:  000000000009e000 - 0000000000100000  (2)
TBOOT:  0000000000100000 - 0000000077a3e000  (1)
TBOOT:  0000000077a3e000 - 0000000077a3f000  (4)
TBOOT:  0000000077a3f000 - 0000000077a40000  (2)
TBOOT:  0000000077a40000 - 000000007e6d5000  (1)
TBOOT:  000000007e6d5000 - 000000007eb99000  (2)
TBOOT:  000000007eb99000 - 000000007ebf8000  (3)
TBOOT:  000000007ebf8000 - 000000007ec58000  (4)
TBOOT:  000000007ec58000 - 000000007f72c000  (2)
TBOOT:  000000007f72c000 - 000000007f7fe000  (20)
TBOOT:  000000007f7fe000 - 000000007f7ff000  (1)
TBOOT:  000000007f7ff000 - 0000000080000000  (2)
TBOOT:  00000000e0000000 - 00000000f0000000  (2)
TBOOT:  00000000fe000000 - 00000000fe011000  (2)
TBOOT:  00000000fec00000 - 00000000fec01000  (2)
TBOOT:  00000000fed00000 - 00000000fed01000  (2)
TBOOT:  00000000fee00000 - 00000000fee01000  (2)
TBOOT:  00000000ff000000 - 0000000100000000  (2)
TBOOT:  0000000100000000 - 000000027f000000  (1)
TBOOT: adjusted e820 map:
TBOOT:  0000000000000000 - 0000000000058000  (1)
TBOOT:  0000000000058000 - 0000000000059000  (2)
TBOOT:  0000000000059000 - 0000000000060000  (1)
TBOOT:  0000000000060000 - 0000000000068000  (2)
TBOOT:  0000000000068000 - 000000000009e000  (1)
TBOOT:  000000000009e000 - 0000000000100000  (2)
TBOOT:  0000000000100000 - 0000000077a3e000  (1)
TBOOT:  0000000077a3e000 - 0000000077a3f000  (4)
TBOOT:  0000000077a3f000 - 0000000077a40000  (2)
TBOOT:  0000000077a40000 - 000000007e6d5000  (1)
TBOOT:  000000007e6d5000 - 000000007eb99000  (2)
TBOOT:  000000007eb99000 - 000000007ebf8000  (3)
TBOOT:  000000007ebf8000 - 000000007ec58000  (4)
TBOOT:  000000007ec58000 - 000000007f72c000  (2)
TBOOT:  000000007f72c000 - 000000007f7fe000  (20)
TBOOT:  000000007f7fe000 - 000000007f7ff000  (1)
TBOOT:  000000007f7ff000 - 0000000080000000  (2)
TBOOT:  00000000e0000000 - 00000000f0000000  (2)
TBOOT:  00000000fe000000 - 00000000fe011000  (2)
TBOOT:  00000000fec00000 - 00000000fec01000  (2)
TBOOT:  00000000fed00000 - 00000000fed01000  (2)
TBOOT:  00000000fee00000 - 00000000fee01000  (2)
TBOOT:  00000000ff000000 - 0000000100000000  (2)
TBOOT:  0000000100000000 - 000000027f000000  (1)
TBOOT: got sinit match on module #2
TBOOT: no LCP module found
TBOOT: ELF magic number is not matched, image is not ELF format.
TBOOT: assuming kernel is Linux format
TBOOT: Initrd from 0x7bbeb000 to 0x7e6d4c02
TBOOT: Kernel (protected mode) from 0x1000000 to 0x1b243f0
TBOOT: Kernel (real mode) from 0x69c00 to 0x6d800
TBOOT: Linux cmdline from 0x72900 to 0x72d00:
TBOOT:  root=UUID=f9f79342-5c5b-445e-ac3a-b4731f57e6e2 ro rootflags=subvol=roo
TBOOT:  t rhgb quiet intel_iommu=on noefi
TBOOT: EFI memmap: memmap base: 0x483b0, memmap size: 0x7b0
TBOOT: EFI memmap: descr size: 0x30, descr version: 0x1
TBOOT: transfering control to kernel @0x1000000...

>From what I see on the log, I have no SMX, and my SINIT ACM is bad (I guess)

Questions
========

1. Any way to test tboot in hardware that does not support SMX/TXT? Any simulator available?
2. Do I actually need SMX to do a Measured Launch? Or is the presence of "TXT measured launch: TRUE" string the txt-stat enough to say that my hardware supports it?
3. Is the invalid tboot generated grub configuration a bug? If so, where should I submit it?
4. Am I using the correct SINIT ACM module? Is my resulting txt-stat output the expected one for my scenario?

Many thanks! 

References
=========

[1] https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol2/o_b5573232dd8f1481-1975.html
[2] http://hg.code.sf.net/p/tboot/code/file/tip/README.md
[3] https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology.html

Re: [tboot-devel] 10th Gen ACM

[Jason A. <jan...@gm...>]

On Wed, Jan 20, 2021 at 3:45 AM Lukasz Hawrylko
<luk...@li...> wrote:
>
> Hi Jason
>
> On Sat, 2021-01-16 at 09:02 -0500, Jason Andryuk wrote:
> > On Mon, Jan 4, 2021 at 2:57 PM Jason Andryuk <
> > jan...@gm...
> > > wrote:
> > > Hi,
> > >
> > > Are SINIT ACMs available for 10th Gen processors, specifically 10th Gen 10810U?
> > >
> > > The intel page
> > > https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology.html
> > >
> > > has 8th_9th_gen_i5_i7-SINIT_81.zip as the latest file - but the file
> > > inside is named 7th_8th_gen_i5_i7-SINIT_81.bin.
> >
> > This acm does not match the 10810U.  From acminfo, I think the chipset
> > matches (0xb008), but the processor 0xa0660 is not in the processor id
> > entries.   0x906e0 is the latest in the ACM with 0x406e0, 0x506e0, and
> > 0x806e0 as well.
> >
> > However, tboot finds a BIOS-loaded SINIT and uses that (which matches
> > processors 0x806e0, 0x906e0, and 0xa0660).
> >
> > I am still interested in finding a download link for newer SINIT ACMs,
> > if anyone has one. :)
> >
>
> Please try this link: https://cdrdv2.intel.com/v1/dl/getContent/630744

That works.  Thanks, Lukasz!

Regards,
Jason

Re: [tboot-devel] 10th Gen ACM

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

Hi Jason

On Sat, 2021-01-16 at 09:02 -0500, Jason Andryuk wrote:
> On Mon, Jan 4, 2021 at 2:57 PM Jason Andryuk <
> jan...@gm...
> > wrote:
> > Hi,
> > 
> > Are SINIT ACMs available for 10th Gen processors, specifically 10th Gen 10810U?
> > 
> > The intel page 
> > https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology.html
> > 
> > has 8th_9th_gen_i5_i7-SINIT_81.zip as the latest file - but the file
> > inside is named 7th_8th_gen_i5_i7-SINIT_81.bin.
> 
> This acm does not match the 10810U.  From acminfo, I think the chipset
> matches (0xb008), but the processor 0xa0660 is not in the processor id
> entries.   0x906e0 is the latest in the ACM with 0x406e0, 0x506e0, and
> 0x806e0 as well.
> 
> However, tboot finds a BIOS-loaded SINIT and uses that (which matches
> processors 0x806e0, 0x906e0, and 0xa0660).
> 
> I am still interested in finding a download link for newer SINIT ACMs,
> if anyone has one. :)
> 

Please try this link: https://cdrdv2.intel.com/v1/dl/getContent/630744

Thanks,
Lukasz

Re: [tboot-devel] 10th Gen ACM

[Jason A. <jan...@gm...>]

On Mon, Jan 4, 2021 at 2:57 PM Jason Andryuk <jan...@gm...> wrote:
>
> Hi,
>
> Are SINIT ACMs available for 10th Gen processors, specifically 10th Gen 10810U?
>
> The intel page https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology.html
> has 8th_9th_gen_i5_i7-SINIT_81.zip as the latest file - but the file
> inside is named 7th_8th_gen_i5_i7-SINIT_81.bin.

This acm does not match the 10810U.  From acminfo, I think the chipset
matches (0xb008), but the processor 0xa0660 is not in the processor id
entries.   0x906e0 is the latest in the ACM with 0x406e0, 0x506e0, and
0x806e0 as well.

However, tboot finds a BIOS-loaded SINIT and uses that (which matches
processors 0x806e0, 0x906e0, and 0xa0660).

I am still interested in finding a download link for newer SINIT ACMs,
if anyone has one. :)

Regards,
Jason

Re: [tboot-devel] binaries in mercurial?

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

On Sat, 2021-01-02 at 19:31 +0200, Timo Lindfors wrote:
> Hi,
> 
> changeset:   620:805285ab8469
> user:        Lukasz Hawrylko <luk...@in...>
> date:        Fri Nov 13 16:09:33 2020 +0100
> summary:     Move old lcptool to deprecated folder and exclude from build
> 
> seems to add some binaries to mercurial version control:
> 
> $ hg clone 
> http://hg.code.sf.net/p/tboot/code
>  
> tboot-code
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 620 changesets with 2372 changes to 497 files (+1 heads)
> new changesets cedd93279188:cc489ff0c783
> updating to branch default
> 403 files updated, 0 files merged, 0 files removed, 0 files unresolved
> $ file tboot-code/deprecated/lcptools/lcp_writepol
> tboot-code/deprecated/lcptools/lcp_writepol: ELF 64-bit LSB executable, 
> x86-64, version 1 (SYSV), dynamically linked, interpreter 
> /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=403efd37304c2d0ca9830ec60c1115fd9d76787c, for GNU/Linux 3.2.0, not stripped
> 
> This is probably accidental?
> 
> The exact Debian lintian errors that caused me to spot this are
> 
> E: tboot source: source-is-missing deprecated/lcptools/lcp_crtpconf
> E: tboot source: source-is-missing deprecated/lcptools/lcp_crtpol
> E: tboot source: source-is-missing deprecated/lcptools/lcp_mlehash
> E: tboot source: source-is-missing deprecated/lcptools/lcp_readpol
> E: tboot source: source-is-missing deprecated/lcptools/lcp_writepol
> E: tboot source: source-is-missing deprecated/lcptools/tpmnv_defindex
> E: tboot source: source-is-missing deprecated/lcptools/tpmnv_getcap
> E: tboot source: source-is-missing deprecated/lcptools/tpmnv_lock
> E: tboot source: source-is-missing deprecated/lcptools/tpmnv_relindex
> E: tboot source: source-is-missing deprecated/lcptools/trousers_dep
> 
> 
> -Timo
> 

You are right, my mistake. Fixed.

Thanks,
Lukasz

[tboot-devel] 10th Gen ACM

[Jason A. <jan...@gm...>]

Hi,

Are SINIT ACMs available for 10th Gen processors, specifically 10th Gen 10810U?

The intel page https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology.html
has 8th_9th_gen_i5_i7-SINIT_81.zip as the latest file - but the file
inside is named 7th_8th_gen_i5_i7-SINIT_81.bin.

Thanks,
Jason

[tboot-devel] binaries in mercurial?

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

Hi,

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

seems to add some binaries to mercurial version control:

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

This is probably accidental?

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

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


-Timo

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

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

Hi Jerry

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

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

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

Thanks,
Lukasz