tboot-devel — Developer support

[tboot-devel] [PATCH] Set GDT to map CS and DS to 4GB segments before jumping to Linux

[Łukasz H. <lu...@ha...>]

# HG changeset patch
# User Łukasz Hawryłko <lu...@ha...>
# Date 1639270553 -3600
#      Sun Dec 12 01:55:53 2021 +0100
# Node ID 8ab1cfa6301f1f892d7d8e82532c6609e136765c
# Parent  5a30b6b09e77844ea26e9298ac3819c33bca617b
Set GDT to map CS and DS to 4GB segments before jumping to Linux

There was an issue that TBOOT can copy Linux kernel binary to address outside
of memory mapped in GTD. If this happens, platform will reset when trying to
jump to Linux. In original implementation this limit was set to 256MB.

To prevent that situation, this commit sets GDT segments to cover whole memory
below 4GB.

Signed-off-by: Lukasz Hawrylko <lu...@ha...>

diff -r 5a30b6b09e77 -r 8ab1cfa6301f tboot/common/linux.c
--- a/tboot/common/linux.c	Fri Dec 10 15:35:42 2021 +0100
+++ b/tboot/common/linux.c	Sun Dec 12 01:55:53 2021 +0100
@@ -471,8 +471,8 @@
     static const uint64_t gdt_table[] __attribute__ ((aligned(16))) = {
         0,
         0,
-        0x00c09b000000ffff,     /* cs */
-        0x00c093000000ffff      /* ds */
+        0x00cf9b000000ffff,     /* cs */
+        0x00cf93000000ffff      /* ds */
     };
     /* both 4G flat, CS: execute/read, DS: read/write */
 

[tboot-devel] FW: The rationale for defeaturing "Maximum Agility" option | PCR Extended Policy Support

[Eydelberg, A. <ale...@in...>]

Hello,


I have initiated the query of the TBOOT extpol option's  usefulness which Pawel have broadcasted (thank you, Pawel and everybody who replied) and have received few questions below.

> "No objections, but we would be interested in understanding the root rationale for the change."<
> "Why would you not just switch the default and leave the Agility as an option?" <
> "I'm also interested in the rationale. The change of default I can understand. I think that most people using tboot use the "extpol" option. I don't understand completely removing agility as an option." <

Let me answer these questions and provide background of the query.


ACM extend policy control was introduced many years ago during architectural adoption of TPM 2.0 family. It is traced back to Q2 of 2015.

At that time there were no TPM samples, no clear understanding of TPM algorithm agility use cases, no fully supported cryptography in our code bases, nor potential consequences of PCR bank capping due to insufficient internal crypto support.

In the presence of such uncertainty, introduction of such policy settings seemed to be prudent - allow Users get what they prefer as measurements regardless of TPM abilities at the expense of performance or get faster service at the expense of loosing of some of the PCR banks which might get capped.

Lots of things changed for the past 6 years.
- we have come up with converged BtG and TXT technologies and our Startup and SINIT ACMs share lots of code, crypto included.
- we have full embedded crypto code supporting all hashing and signature algorithms we need.
Situation when with Max Perf policy setting we might need to get PCR bank capped due to lack of internal support is unlikely.
- Max Agility setting is unacceptable for Startup ACM and is deprecated in it. This is due to strong boot performance requirements.
- SINIT execution time with Max Agility setting is essentially longer, but we have not received any such complaints or acceleration requests.
This bears the innuendo that this setting is not used in practice.
- Internally support of this policy engenders essential complexity, including set of supported TPM2 commands, way how we maintain event log, execution flow differences etc.
This is burden which I would like to drop if possible, harmonize support between two ACMs, remove potentially unneeded externally visible knob, solidify ACM core.

With all of the above reasoning I was not going to change the default setting.
I understand that it is awkward to leave default == 1 which means Max Perf but changing it to 0 is onerous.
(This default BTW expresses our vision 6 years ago that Max Agility is preferred selection ! Real life performance demands have changed it.)
This is very inertial legacy as it is OS visible change and not only for Tboot but also for a Windows world and multiple other products.

What I intend to do is simply formally defeature this policy setting and remain default to be == 1, which appears to be current practice.
Most likely internally in SINIT I will simply ignore this setting and will not generate an error if it is all of a sudden set == 0. I do not want to multiply security unrelated error situations.
Internally SINIT will invariantly use Max Perf regardless of this setting. As soon as there are no PCR bank capping this will not produce visible difference.
In extreme case when capping occurs and is undesirable it will always be possible to enable missing crypto algorithm in SINIT code. All of them are build controlled.

Thank you,

-ae

From: Randzio, Pawel <paw...@in...>
Sent: Thursday, December 2, 2021 12:34 AM
To: Eydelberg, Alex <ale...@in...>
Cc: Mowka, Mateusz <mat...@in...>
Subject: The rationale for defeaturing "Maximum Agility" option | PCR Extended Policy Support

Hi Alex,

I sent out a message through the TBOOT mailing list as you asked. There's some questions that came up in response to the announcement.

Greg W. Wettstein gr...@wi...<mailto:gr...@wi...>
> "No objections, but we would be interested in understanding the root rationale for the change."

Travis Gilbert tra...@de...<mailto:tra...@de...>
> "Why would you not just switch the default and leave the Agility as an option?"
> "I'm also interested in the rationale. The change of default I can understand. I think that most people using tboot use the "extpol" option. I don't understand completely removing agility as an option."

Could I ask you to respond to these questions? Best if you could send an e-mail with the answers straight to the mailing list tbo...@li...<mailto:tbo...@li...> and I'll get it through there.

Thanks,
--Paweł

---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------

MY ORIGINAL ANNOUNCEMENT FOR REFERENCE:
> Hello,
>
> I would like to inform you that there are plans to defeature TBOOT extpol option and fix it to the current default.
>
> The change affects TPM2.0 PCR Extended Policy Support. It has two options:
> - "Maximum Agility" - hashes computed using TPM2.0
> - "Maximum Performance" - hashes computed using software, not TPM usage
>
> We want to defeature the "Maximum Agility" option and leave only "Maximum Performance" (current default).
>
> If you have any objections, please inform me.
>
> Thanks,
> --Paweł Randzio

Re: [tboot-devel] [ANNOUNCEMENT] PCR Extended Policy - planned DEFEATURING

[Gilbert, T. <Tra...@de...>]

Internal Use - Confidential

> -----Original Message-----
> From: Dr. G.W. Wettstein <gr...@wi...>
> Sent: Wednesday, December 1, 2021 08:53
> To: Randzio, Pawel; tbo...@li...; tboot-
> de...@li...
> Subject: Re: [tboot-devel] [ANNOUNCEMENT] PCR Extended Policy - planned
> DEFEATURING
> 
> 
> [EXTERNAL EMAIL]
> 
> On Dec 1,  9:04am, "Randzio, Pawel" wrote:
> } Subject: [tboot-devel] [ANNOUNCEMENT] PCR Extended Policy - planned
> DEFEAT
> 
> > Hello,
> 
> Good morning, I hope this note finds the day, or evening, going well for
> everyone.
> 
> > I would like to inform you that there are plans to defeature TBOOT
> > extpol option and fix it to current default.
> >
> > The change affects TPM2.0 PCR Extended Policy Support. It has two options:
> >
> >   *   "Maximum Agility" - hashes computed using TPM2.0
> >   *   "Maximum Performance" - hashes computed using software, no TPM
> usage
> >
> > We want to defeature the "Maximum Agility" option and leave only
> "Maximum Performance" (current default).

Why would you not just switch the default and leave the Agility as an option?

> >
> > If you have any objections, please inform me.
> 
> No objections but we would be interested in understanding the root rationale
> for the change.

I'm also interested in the rationale. The change of default I can understand. I think that
 most people using tboot use the "extpol" option. I don't understand completely removing agility as an option.

[tboot-devel] PCR17 Replay Issue

[Thompson, K. <ken...@in...>]

Hi,
We're encountering an issue in that the event log measurements in PCR17 (see eventlog.json attachment) are not "replaying" with the PCR's final measurement.  In other TXT/TBoot environments, the code that produces the event log and performs replay (of PCR17) are reported to work.  In this case, the environment is...

Bios:  WLYDCRB1.SYS.0020.P35.2101050157
OS: Fedora 34
Tboot: 10.1.2

Does the tboot team have any recommendations on how to investigate this issue?  Is it possible that "startup locality" is in play?

Thanks,
Kent

Re: [tboot-devel] [ANNOUNCEMENT] PCR Extended Policy - planned DEFEATURING

[Dr. G.W. W. <gr...@wi...>]

On Dec 1,  9:04am, "Randzio, Pawel" wrote:
} Subject: [tboot-devel] [ANNOUNCEMENT] PCR Extended Policy - planned DEFEAT

> Hello,

Good morning, I hope this note finds the day, or evening, going well
for everyone.

> I would like to inform you that there are plans to defeature TBOOT
> extpol option and fix it to current default.
>
> The change affects TPM2.0 PCR Extended Policy Support. It has two options:
> 
>   *   "Maximum Agility" - hashes computed using TPM2.0
>   *   "Maximum Performance" - hashes computed using software, no TPM usage
>
> We want to defeature the "Maximum Agility" option and leave only
"Maximum Performance" (current default).
>
> If you have any objections, please inform me.

No objections but we would be interested in understanding the root
rationale for the change.

> Thanks,
> --Pawe Randzio
> ---------------------------------------------------------------------
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydz=
> ial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-31=
> 6 | Kapital zakladowy 200.000 PLN.

Have a good day.

Dr. Greg

}-- End of excerpt from "Randzio, Pawel"

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: gr...@en...
------------------------------------------------------------------------------
"Never try to catch two frogs with one hand."
                                -- Chinese proverb

[tboot-devel] [ANNOUNCEMENT] PCR Extended Policy - planned DEFEATURING

[Randzio, P. <paw...@in...>]

Hello,

I would like to inform you that there are plans to defeature TBOOT extpol option and fix it to current default.

The change affects TPM2.0 PCR Extended Policy Support. It has two options:

  *   "Maximum Agility" - hashes computed using TPM2.0
  *   "Maximum Performance" - hashes computed using software, no TPM usage

We want to defeature the "Maximum Agility" option and leave only "Maximum Performance" (current default).

If you have any objections, please inform me.

Thanks,
--Paweł Randzio
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

[tboot-devel] [Announcement] Linux Secure Launch - TrenchBoot Summit

[Łukasz H. <lu...@ha...>]

Hello

I want to invite you to Linux Secure Launch - TrenchBoot Summit that
will take place at November 16th, starting from 4PM UTC.

Summit will be focused on DRTM and SRTM technologies that can be used
with Linux, including TrenchBoot - a new initiative that adds platform
independent support for DRTM to the Linux based systems.

For more details and presentation schedule please check:
https://trenchboot.org/secure-launch-summit/

Thanks,
Lukasz

[tboot-devel] [PATCH 3 of 3] Ensure that growth of Multiboot tags does not go beyond original area

[alex <thi...@gm...>]

# HG changeset patch
# User Alex Olson <ale...@st...>
# Date 1634323050 18000
#      Fri Oct 15 13:37:30 2021 -0500
# Node ID 06433602ffe048ceb946d538d51620ae8152c93d
# Parent  f3574795bf2ecbd0e717268f9cb9ccc8982f1861
Ensure that growth of Multiboot tags does not go beyond original area

The grow_mb2_tag() function can only rearrange Multiboot content
within the area originally allocated by the parent bootloader (Grub).

This revision ensures that boot will not continue if the expansion of
a tag would overflow the original area.

In practice, small expansions as a result of tboot added content
are normally "paid for" through tboot's removal of other tags.

Signed-off-by: Alex Olson <ale...@st...>

diff -r f3574795bf2e -r 06433602ffe0 tboot/common/loader.c
--- a/tboot/common/loader.c	Tue Oct 19 13:53:09 2021 -0500
+++ b/tboot/common/loader.c	Fri Oct 15 13:37:30 2021 -0500
@@ -375,6 +375,7 @@
     if (growth > slack){
         printk(TBOOT_ERR"YIKES!!! grow_mb2_tag slack %d < growth %d\n",
                slack, growth);
+        apply_policy(TB_ERR_FATAL);
     }
 
     /* now we copy down from the bottom, going up */

[tboot-devel] [PATCH 2 of 3] Replace EFI memory map in Multiboot2 info

[alex <thi...@gm...>]

# HG changeset patch
# User Alex Olson <ale...@st...>
# Date 1634669589 18000
#      Tue Oct 19 13:53:09 2021 -0500
# Node ID f3574795bf2ecbd0e717268f9cb9ccc8982f1861
# Parent  4eda9c0cf72d0fe0c217c251bdef2c5628e0c0a6
Replace EFI memory map in Multiboot2 info

tboot modifies both the e820 and EFI memory maps during its boot process,
but was only updating the Multiboot content's e820 map.  This meant
the unmodified EFI map was being passed even though it should have contained
reserved ranges specific to tboot.

This probably went unnoticied since the Linux kernel is not booted using
Multiboot (thus, was already receiving the updated EFI map on EFI systems).

This revision adds the update of the EFI Multiboot content, but has to make a
slight tradeoff as the combined expansion of the E820 and EFI memory maps
cannot be "paid" for with the memory savings from other Multiboot tag deletions.

Signed-off-by: Alex Olson <ale...@st...>

diff -r 4eda9c0cf72d -r f3574795bf2e tboot/common/efi_memmap.c
--- a/tboot/common/efi_memmap.c	Fri Oct 15 13:35:59 2021 -0500
+++ b/tboot/common/efi_memmap.c	Tue Oct 19 13:53:09 2021 -0500
@@ -372,4 +372,10 @@
     } else {
         return false;
     }
-}
\ No newline at end of file
+}
+
+
+bool efi_memmap_present(void)
+{
+    return efi_mmap_available;
+}
diff -r 4eda9c0cf72d -r f3574795bf2e tboot/common/loader.c
--- a/tboot/common/loader.c	Fri Oct 15 13:35:59 2021 -0500
+++ b/tboot/common/loader.c	Tue Oct 19 13:53:09 2021 -0500
@@ -331,6 +331,18 @@
     return true;
 }
 
+
+static bool remove_mb2_tag_by_type(loader_ctx *lctx, uint32_t tag_type)
+{
+    struct mb2_tag *start = next_mb2_tag(NULL);
+    struct mb2_tag *victim = find_mb2_tag_type(start, tag_type);
+
+    if (victim != NULL) {
+        return remove_mb2_tag(lctx,victim);
+    }
+    return false;
+}
+
 static bool
 grow_mb2_tag(loader_ctx *lctx, struct mb2_tag *which, uint32_t how_much)
 {
@@ -1401,11 +1413,22 @@
     }
 
     /* replace map in loader context with copy */
-    replace_e820_map(g_ldr_ctx);
+    if ( is_loader_launch_efi(g_ldr_ctx) && efi_memmap_present() ) {
+        /* for EFI, reclaim MB2 space by deleting the E820 map,
+           this ensures grow_mb2_tag() has enough slack available.
+           Due to the growth of each, there can only be one...
+         */
+        remove_mb2_tag_by_type(g_ldr_ctx, MB2_TAG_TYPE_MMAP);
+        replace_efi_map(g_ldr_ctx);
+    } else {
+        remove_mb2_tag_by_type(g_ldr_ctx, MB2_TAG_TYPE_EFI_MMAP);
+        replace_e820_map(g_ldr_ctx);
+    }
 
     if (get_tboot_dump_memmap()) {
         printk(TBOOT_DETA"adjusted e820 map:\n");
         print_e820_map();
+        efi_memmap_dump();
     }
 
     if ( !verify_loader_context(g_ldr_ctx) )
@@ -1907,6 +1930,47 @@
     return;
 }
 
+void
+replace_efi_map(loader_ctx *lctx)
+{
+    /* currently must be MBI type 2 */
+    if ( LOADER_CTX_BAD(lctx) || lctx->type == MB1_ONLY ){
+        return;
+    }
+
+    struct mb2_tag *start = (struct mb2_tag *)(lctx->addr + 8);
+    struct mb2_tag_efi_mmap *tag;
+    tag = (struct mb2_tag_efi_mmap *)find_mb2_tag_type(start, MB2_TAG_TYPE_EFI_MMAP);
+
+    if ( !tag ) {
+        printk(TBOOT_INFO"MB2 EFI map not found\n");
+        return;
+    }
+
+    const uint32_t old_mmap_size = tag->size - sizeof(struct mb2_tag_efi_mmap);
+    uint32_t new_descr_size=0;
+    uint32_t new_descr_vers=0;
+    uint32_t new_mmap_size=0;
+    void    *new_mmap;
+
+    new_mmap = (void *)efi_memmap_get_addr(&new_descr_size, &new_descr_vers, &new_mmap_size);
+
+    if ( old_mmap_size < new_mmap_size ) {
+        /* we have to grow */
+        if (false ==
+            grow_mb2_tag(lctx, (struct mb2_tag *)tag, (new_mmap_size-old_mmap_size))) {
+            printk(TBOOT_ERR"MB2 failed to grow EFI map tag\n");
+            return;
+        }
+    } else {
+        tag->size = sizeof(struct mb2_tag_efi_mmap) + new_mmap_size;
+    }
+    /* copy in new data */
+    tag->descr_size = new_descr_size;
+    tag->descr_vers = new_descr_vers;
+    tb_memcpy(tag->efi_mmap, new_mmap, new_mmap_size);
+}
+
 void print_loader_ctx(loader_ctx *lctx)
 {
     if (lctx->type != MB2_ONLY){
diff -r 4eda9c0cf72d -r f3574795bf2e tboot/include/efi_memmap.h
--- a/tboot/include/efi_memmap.h	Fri Oct 15 13:35:59 2021 -0500
+++ b/tboot/include/efi_memmap.h	Tue Oct 19 13:53:09 2021 -0500
@@ -98,4 +98,5 @@
                                       uint64_t *ram_base, uint64_t *ram_size);
 void efi_memmap_dump(void);
 
-#endif
\ No newline at end of file
+bool efi_memmap_present(void);
+#endif
diff -r 4eda9c0cf72d -r f3574795bf2e tboot/include/loader.h
--- a/tboot/include/loader.h	Fri Oct 15 13:35:59 2021 -0500
+++ b/tboot/include/loader.h	Tue Oct 19 13:53:09 2021 -0500
@@ -97,6 +97,7 @@
 extern void determine_loader_type(void *addr, uint32_t magic);
 extern unsigned long get_loader_ctx_end(loader_ctx *lctx);
 extern void replace_e820_map(loader_ctx *lctx);
+extern void replace_efi_map(loader_ctx *lctx);
 extern uint8_t *get_loader_rsdp(loader_ctx *lctx, uint32_t *length);
 extern bool is_loader_launch_efi(loader_ctx *lctx);
 extern bool get_loader_efi_ptr(loader_ctx *lctx, uint32_t *address, 

[tboot-devel] [PATCH 1 of 3] make efi_memmap_reserve handle gaps like e820_protect_region already does

[alex <thi...@gm...>]

# HG changeset patch
# User Alex Olson <ale...@st...>
# Date 1634322959 18000
#      Fri Oct 15 13:35:59 2021 -0500
# Node ID 4eda9c0cf72d0fe0c217c251bdef2c5628e0c0a6
# Parent  5bf5c12411d3a4a7e0a552203b40bfe59d5c7789
make efi_memmap_reserve handle gaps like e820_protect_region already does

This revision corrects an inconsistency in the way efi_memmap_reserve
deals with requests that lie within a gap in the memory map.

In such cases, e820_protect_region() created a new range in the map,
however efi_memmap_reserve was doing nothing since its logic was
based on finding an overlapping range.

This revision makes efi_memmap_reserve add a new range.  Unlike
the e820 case, the EFI memory map have an "attributes" field as well
and it is somewhat ambigious how to define the attributes of a new map.
Since we are only using this for reserved ranges, the attributes are set to zero
for simplicity...

Signed-off-by: Alex Olson <ale...@st...>

diff -r 5bf5c12411d3 -r 4eda9c0cf72d tboot/common/efi_memmap.c
--- a/tboot/common/efi_memmap.c	Wed Sep 15 16:53:34 2021 +0200
+++ b/tboot/common/efi_memmap.c	Fri Oct 15 13:35:59 2021 -0500
@@ -144,6 +144,8 @@
  * Region has to be aligned to page size, function will round non-aligned
  * values. Base address is rounded down, length - up.
  * 
+ * If the specified region lies within a gap, a new region will be added
+ *
  * @param base   starting address
  * @param length length of region to reserve
  */
@@ -164,6 +166,7 @@
     uint64_t end = base + length;
     efi_mem_descr_t* desc = NULL;
     uint32_t i = 0;
+    bool in_range = false;
 
     while ((desc = efi_memmap_walk(desc)) != NULL) {
         uint64_t desc_base = desc->physical_start;
@@ -185,6 +188,9 @@
             goto cont;
         }
 
+        /* In all cases below, the current range is involved */
+        in_range = true;
+
         /* case 1: the current ram range is within the range:
            base, desc_base, desc_end, end */
         if ((base <= desc_base) && (desc_end <= end)) {
@@ -250,6 +256,15 @@
         ++i;
     }
 
+    /* Insert the new region */
+    if ( !in_range ) {
+
+        desc = efi_memmap_walk(NULL);
+        if( !insert_after_region(0, base, length, EFI_RESERVED_TYPE, 0) ) {
+            return false;
+        }
+    }
+
     return true;
 }
 

[tboot-devel] [PATCH 0 of 3] Use correct EFI memory map for Multiboot2 booting

[alex <thi...@gm...>]

These patches allow tboot to boot an OS kernel/VMM using
Multiboot2 with a proper EFI Memory map.  This is relevant to booting
a non-Linux OS, such as Xen.

Issues fixed:

- The EFI-related code for marking reserved memory ranges did not create
  a new range if the requested range was outside all existing ranges.
  (This was different behavior than the related code for handling the E820 memory map)

- Although tboot previously updated its internal copy of the EFI Memory Map,
  the EFI Memory map used for Multiboot2 booting of the OS kernel/VMM was the original,
  lacking tboot's updates to it.

- There was no safeguard that prevented tboot's updated Multiboot2 content from
  overflowing the original area used for such.

Re: [tboot-devel] Issue with warm reboot

[Loris W. <lor...@ou...>]

Hi Lukasz,

Ok I will contact Getac.

Thank you for your support.

Loris

________________________________
De : Lukasz Hawrylko <luk...@li...>
Envoyé : vendredi 1 octobre 2021 15:01
À : Loris Wilbert <lor...@ou...>; tbo...@li... <tbo...@li...>
Objet : Re: [tboot-devel] Issue with warm reboot

Hi Loris

I have no idea how can I help you here. Can you ask Getac if they have tested X500 with Intel TXT and if it is officially supported?

Thanks,
Lukasz

-----Original Message-----
From: Loris Wilbert <lor...@ou...<mailto:Loris%20Wilbert%20%3cl...@ou...%3e>>
To: Lukasz Hawrylko <luk...@li...<mailto:Lukasz%20Hawrylko%20%3cl...@li...%3e>>, tbo...@li... <tbo...@li...<mailto:%22t...@li...%22%20%3ct...@li...%3e>>
Subject: RE: [tboot-devel] Issue with warm reboot
Date: Wed, 29 Sep 2021 10:26:02 +0000

Hi Lukasz,

I have this problem with a Getac X500 G3 (CPU : Intel(R) Core(TM) i5-7440HQ CPU @ 2.80GHz).

I realised the same test on another Getac X500 G3 and the same issue appear.

Thanks,

Loris
________________________________
De : Lukasz Hawrylko <luk...@li...>
Envoyé : lundi 27 septembre 2021 13:49
À : Loris Wilbert <lor...@ou...>; tbo...@li... <tbo...@li...>
Objet : Re: [tboot-devel] Issue with warm reboot

On Wed, 2021-09-22 at 08:18 +0000, Loris Wilbert wrote:
> Hi Lukasz,
>
> I've attached full TBOOT logs to this mail.
>
> Thank you for you assistance.

This looks like an issue with TPM. Is it possible to replace TPM module
on the system? Did you try to run TBOOT on another system with the same
specs?

Thanks,
Lukasz

Re: [tboot-devel] Issue with warm reboot

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

Hi Loris

I have no idea how can I help you here. Can you ask Getac if they have
tested X500 with Intel TXT and if it is officially supported?

Thanks,
Lukasz

-----Original Message-----
From: Loris Wilbert <lor...@ou...>
To: Lukasz Hawrylko <luk...@li...>, tboot-
de...@li... <tbo...@li...>
Subject: RE: [tboot-devel] Issue with warm reboot
Date: Wed, 29 Sep 2021 10:26:02 +0000

Hi Lukasz,

I have this problem with a Getac X500 G3 (CPU : Intel(R) Core(TM) i5-
7440HQ CPU @ 2.80GHz).

I realised the same test on another Getac X500 G3 and the same issue
appear.

Thanks,

Loris
De : Lukasz Hawrylko <luk...@li...>
Envoyé : lundi 27 septembre 2021 13:49
À : Loris Wilbert <lor...@ou...>; tboot-
de...@li... <tbo...@li...>
Objet : Re: [tboot-devel] Issue with warm reboot 
On Wed, 2021-09-22 at 08:18 +0000, Loris Wilbert wrote:
> Hi Lukasz,
> 
> I've attached full TBOOT logs to this mail.
> 
> Thank you for you assistance.

This looks like an issue with TPM. Is it possible to replace TPM module
on the system? Did you try to run TBOOT on another system with the same
specs?

Thanks,
Lukasz

Re: [tboot-devel] Issue with warm reboot

[Loris W. <lor...@ou...>]

Hi Lukasz,

I have this problem with a Getac X500 G3 (CPU : Intel(R) Core(TM) i5-7440HQ CPU @ 2.80GHz).

I realised the same test on another Getac X500 G3 and the same issue appear.

Thanks,

Loris
________________________________
De : Lukasz Hawrylko <luk...@li...>
Envoyé : lundi 27 septembre 2021 13:49
À : Loris Wilbert <lor...@ou...>; tbo...@li... <tbo...@li...>
Objet : Re: [tboot-devel] Issue with warm reboot

On Wed, 2021-09-22 at 08:18 +0000, Loris Wilbert wrote:
> Hi Lukasz,
>
> I've attached full TBOOT logs to this mail.
>
> Thank you for you assistance.

This looks like an issue with TPM. Is it possible to replace TPM module
on the system? Did you try to run TBOOT on another system with the same
specs?

Thanks,
Lukasz

Re: [tboot-devel] Issue with warm reboot

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

On Wed, 2021-09-22 at 08:18 +0000, Loris Wilbert wrote:
> Hi Lukasz,
> 
> I've attached full TBOOT logs to this mail.
> 
> Thank you for you assistance.

This looks like an issue with TPM. Is it possible to replace TPM module
on the system? Did you try to run TBOOT on another system with the same
specs?

Thanks,
Lukasz

Re: [tboot-devel] Issue with warm reboot

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

Hi Loris

On Tue, 2021-09-21 at 08:53 +0000, Loris Wilbert wrote:
> Hello, 
> 
> I'm having a problem about warm reboot and I don't have this issue
> with a cold reboot.
> 
> TBOOT: TPM: write cmd timeout
> TBOOT: TPM: Create return value = 00000101
> TBOOT: failed to seal data
> 
> Has anyone experienced the same error ?

Could you please include full TBOOT log?

Thanks,
Lukasz

[tboot-devel] Issue with warm reboot

[Loris W. <lor...@ou...>]

Hello,

I'm having a problem about warm reboot and I don't have this issue with a cold reboot.


TBOOT: TPM: write cmd timeout
TBOOT: TPM: Create return value = 00000101
TBOOT: failed to seal data


Has anyone experienced the same error ?

Regards,

Loris Wilbert

Re: [tboot-devel] txt-acminfo segfaults

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

On Thu, 26 Aug 2021, Lukasz Hawrylko wrote:
> May I ask you to prepare the patch?

I'll look into this. Ideally it would be nice to get rid of including C 
files from other C files completely.

-Timo

Re: [tboot-devel] [PATCH 2/2] Ensure all source files end with a newline

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

On Wed, 2021-08-25 at 12:05 +0300, Timo Juhani Lindfors wrote:
> From: Timo Lindfors <tim...@ik...>
> 
> Signed-off-by: Timo Juhani Lindfors <tim...@ik...>

Thank you for the patches, I have pushed them upstream.

Lukasz

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

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

On Wed, 2021-08-25 at 11:58 +0300, Timo Juhani Lindfors wrote:
> 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...>

Thank you for the patch, I have pushed it upstream.

Lukasz

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

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

On Thu, 2021-08-26 at 11:05 +0300, Timo Lindfors wrote:
> On Thu, 26 Aug 2021, Lukasz Hawrylko wrote:
> > You can check if txt-stat dumps TBOOT log correctly. Nothing else comes
> > into my mind.
> 
> Looks normal to me. I've attached a compressed version to this mail.

Looks good, thank you for your tests. As soon as GRUB maintainers accept
the patch, I will push changes to TBOOT upstream.

Lukasz

Re: [tboot-devel] txt-acminfo segfaults

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

Hi Timo

On Wed, 2021-08-25 at 11:47 +0300, Timo Lindfors wrote:
> 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?
> 

It looks like that this issue was introduced in:

o  changeset:   627:d8a8e17f6d41
|  user:        Lukasz Hawrylko <luk...@in...>
|  date:        Thu May 13 16:04:27 2021 +0200
|  summary:     Check for client/server match when selecting SINIT

To solve that txt-acminfo should map TXT heap and then pass pointer to
does_acmod_match_platform() function. I think that this will be the best
solution.

May I ask you to prepare the patch?

Thanks,
Lukasz

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

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

On Thu, 26 Aug 2021, Lukasz Hawrylko wrote:
> You can check if txt-stat dumps TBOOT log correctly. Nothing else comes
> into my mind.

Looks normal to me. I've attached a compressed version to this mail.

-Timo

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

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

On Wed, 2021-08-25 at 09:28 +0300, Timo Lindfors wrote:
> 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?

You can check if txt-stat dumps TBOOT log correctly. Nothing else comes
into my mind.

Lukasz

[tboot-devel] [PATCH 2/2] Ensure all source files end with a newline

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

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

Signed-off-by: Timo Juhani Lindfors <tim...@ik...>
---
 lcp-gen2/ElementBase.py  | 3 ---
 tboot/Makefile           | 2 +-
 uml/prepare_cpu.plantuml | 2 +-
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/lcp-gen2/ElementBase.py b/lcp-gen2/ElementBase.py
index 3fbc738..7086ce1 100644
--- a/lcp-gen2/ElementBase.py
+++ b/lcp-gen2/ElementBase.py
@@ -57,6 +57,3 @@ if __name__ == "__main__":
   #print packed
   #e.packHash('SHA384')
   #e.packHash('SHA512')
-  
-  
-    
\ No newline at end of file
diff --git a/tboot/Makefile b/tboot/Makefile
index dbcfdf9..3fe6a9a 100644
--- a/tboot/Makefile
+++ b/tboot/Makefile
@@ -143,4 +143,4 @@ endif
 	$(CPP) $(AFLAGS) $< -o $@
 
 %.S : %.pl $(HDRS) $(BUILD_DEPS)
-	/usr/bin/perl $< "elf" $(AFLAGS) $@
\ No newline at end of file
+	/usr/bin/perl $< "elf" $(AFLAGS) $@
diff --git a/uml/prepare_cpu.plantuml b/uml/prepare_cpu.plantuml
index 41908ff..5fba6cc 100644
--- a/uml/prepare_cpu.plantuml
+++ b/uml/prepare_cpu.plantuml
@@ -6,4 +6,4 @@ start
 :check & exit virtual-8086 mode;
 :check if no machine check in progress;
 stop
-@enduml
\ No newline at end of file
+@enduml
-- 
2.20.1