trenchboot / trenchboot-issues

This repository is to centralize issues and development progress tracking for the TrenchBoot project.

         _____                    _     ____              _   
        |_   _| __ ___ _ __   ___| |__ | __ )  ___   ___ | |_ 
          | || '__/ _ \ '_ \ / __| '_ \|  _ \ / _ \ / _ \| __|
          | || | |  __/ | | | (__| | | | |_) | (_) | (_) | |_ 
          |_||_|  \___|_| |_|\___|_| |_|____/ \___/ \___/ \__|

TrenchBoot is a framework that allows individuals and projects to build security engines to perform launch integrity actions for their systems. The framework builds upon Boot Integrity Technologies (BITs) that establish one or more Roots of Trust (RoT) from which a degree of confidence that integrity actions were not subverted is derived.

Where to Start:

• General Architecture - A top level overview of TrenchBoot
• Use Case Definition - A collection of example use cases
• Developers Guide - A developers guide that explains the internals of TrenchBoot

trenchboot-issues's Issues

Integrate TPM 2.0 software stack into Qubes OS Dom0

Is your feature request related to a problem? Please describe.

Currently, Qubes OS AEM does not have support for TPM 2.0. This task is required to integrate the TPM 2.0 software stack into Qubes OS Dom0 to support TPM 2.0.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This issue is required add TPM 2.0 support on Intel hardware in Qubes OS AEM.

Describe the solution you'd like

Integrate the TPM 2.0 software stack into Qubes OS Dom0.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Latest GRUB, kernel, and SKL is not compatible

Affected component(s) or functionality

Working properly TrenchBoot D-RTM configuration: kernel + GRUB + Secure Kernel Loader

Brief summary

We tried to run D-RTM on PC Engines apu2 using latest versions from TrenchBoot repositories: SKL from master, GRUB from trenchboot_support_2.04, and kernel from linux-sl-5.13-amd branch.

Version

Firmware:

• coreboot build 20212712
• BIOS version v4.15.0.2
• SeaBIOS (version rel-1.14.0.1-0-g8610266a)

1st scenario: TrenchBoot latest version (from here):

• GRUB trenchboot_support_2.04
• kernel linux-sl-5.13-amd
• Secure Kernel Loader master, last commit at this day
  3432f4398652727f402b710c2fea4e3f1efecce6

2nd scenario: previous scenario with:

• GRUB 3mdeb fork from here

3rd scenario: previous scenario with:

• Patch for secure-kernel-loader with IOMMU workaround - link

To Reproduce

1. Build TrenchBoot using defconfigs from following versions, or use our branches
   to build image with bitbake: meta-fobnail
   (Pull requests with [NOT FOR MERGE] prefix)
2. Boot prepared system

Expected behavior

Booting from GRUB and SKL to Linux shell properly, without kernel panic on first
scenario

Actual behavior

In the 1st scenario: secure-kernel-loader is unable to run kernel because of
bad bootloader data format:

grub_cmd_slaunch:122: check for manufacturer
grub_cmd_slaunch:126: check for cpuid
grub_cmd_slaunch:136: set slaunch
grub_cmd_slaunch_module:156: check argc
grub_cmd_slaunch_module:161: check relocator
grub_cmd_slaunch_module:170: open file
grub_cmd_slaunch_module:175: get size
grub_cmd_slaunch_module:180: allocate memory
grub_cmd_slaunch_module:192: addr:  0x100000
grub_cmd_slaunch_module:194: target: 0x100000
grub_cmd_slaunch_module:196: add module
grub_cmd_slaunch_module:205: read file
grub_cmd_slaunch_module:215: close file
grub_slaunch_boot_skinit:41: real_mode_target: 0x8b000
grub_slaunch_boot_skinit:42: prot_mode_target: 0x1000000
grub_slaunch_boot_skinit:43: params: 0xcfdfb7c
Bad bootloader data format
Rebooting now..

In the 2nd scenario: secure-kernel-loader entry into an infinite loop during
flushing IOMMU cache and print dots endlessly:

shasum calculated:
0x001001dc: ff dc d4 84 73 07 f0 06 8a f3 eb 47 b5 ed 7e 09   ....s......G..~.
0x001001ec: 78 f5 a4 24 cc cc cc cc cc cc cc cc cc cc cc cc   x..$............
shasum calculated:
0x001001f0: 03 94 76 22 df 42 8c 3b ac f5 cc e5 ea 60 c6 ef   ..v".B.;.....`..
0x00100200: 50 52 55 ac 86 79 e3 5c 52 d5 84 8c 2d db 9c f0   PRU..y.\R...-...
PCR extended
IOMMU MMIO Base Address = 0xd0500000: 
0x00000000: IOMMU_MMIO_STATUS_REGISTER
0x00106001: IOMMU_MMIO_DEVICE_TABLE_BA
0x00103000: IOMMU_MMIO_COMMAND_BUF_BA
0x00105000: IOMMU_MMIO_EVENT_LOG_BA
0x00000018: IOMMU_MMIO_STATUS_REGISTER
INVALIDATE_IOMMU_ALL
0x00290ad2: IOMMU_MMIO_EXTENDED_FEATURE
0x0000000a: IOMMU_MMIO_STATUS_REGISTER
0x0000000a: IOMMU_MMIO_STATUS_REGISTER
Disabling SLB protection
IOMMU MMIO Base Address = 0xd0500000: 
0x0000000a: IOMMU_MMIO_STATUS_REGISTER
0x00106001: IOMMU_MMIO_DEVICE_TABLE_BA
0x00103000: IOMMU_MMIO_COMMAND_BUF_BA
0x00105000: IOMMU_MMIO_EVENT_LOG_BA
0x0000001a: IOMMU_MMIO_STATUS_REGISTER
INVALIDATE_IOMMU_ALL
0x00290ad2: IOMMU_MMIO_EXTENDED_FEATURE
0x0000000a: IOMMU_MMIO_STATUS_REGISTER
0x0000000a: IOMMU_MMIO_STATUS_REGISTER
Flushing IOMMU cache.....

In the 3rd scenario: kernel booting stops by TPM event log panic:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cfe81fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000cfe82000-0x00000000cfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000012effffff] usable
[    0.000000] BIOS-e820: [mem 0x000000012f000000-0x000000012fffffff] reserved

[...]

[    3.120808] slaunch: Error failed to find TPM event log
[    3.120808]  - error: 0xc0008022
[    3.120910] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[    3.121624] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.13.0-yocto-standard #1
[    3.121624] Hardware name: PC Engines apu2/apu2, BIOS v4.15.0.2 12/27/2021
[    3.121624] RIP: 0010:slaunch_skinit_reset+0x1b/0x1d
[    3.121624] Code: c7 c8 f6 bf ba e8 10 74 00 00 e9 89 14 4e ff 0f 1f 44 00 00 55 48 89 f2 48 89 fe 48 c7 c7 74 f8 bf ba 48 89 e5 e8 f0 73 00 00 <0f> 0b 83 c8 03 48 c7 c7 e0 f7 bf ba 89 05 e9 de c9 00 e8 d9 73 00
[    3.121624] RSP: 0018:ffffa46800023e50 EFLAGS: 00010246
[    3.121624] RAX: 0000000000000040 RBX: 0000000000000000 RCX: 0000000000000000
[    3.121624] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000ffffffff
[    3.121624] RBP: ffffa46800023e50 R08: ffffffffbaec17e8 R09: 0000000000000003
[    3.121624] R10: ffffffffbae51800 R11: ffffffffbae51800 R12: ffffffffbb070f67
[    3.121624] R13: ffff8f4400160b40 R14: ffffffffbb1b1384 R15: 0000000000000000
[    3.121624] FS:  0000000000000000(0000) GS:ffff8f442ad80000(0000) knlGS:0000000000000000
[    3.121624] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.226956] CR2: 0000000000000000 CR3: 000000001020a000 CR4: 00000000000406e0
[    3.226956] Call Trace:
[    3.226956]  slaunch_module_init+0x40d/0x501
[    3.226956]  ? slaunch_setup_txt+0x4f4/0x4f4
[    3.226956]  do_one_initcall+0x51/0x220
[    3.226956]  kernel_init_freeable+0x1f2/0x241
[    3.226956]  ? rest_init+0xc3/0xc3
[    3.226956]  kernel_init+0xe/0x10d
[    3.226956]  ret_from_fork+0x22/0x30
[    3.226956] Modules linked in:
[    3.267166] ---[ end trace 4937f4e6d9634fb5 ]---
[    3.271875] RIP: 0010:slaunch_skinit_reset+0x1b/0x1d
[    3.276895] Code: c7 c8 f6 bf ba e8 10 74 00 00 e9 89 14 4e ff 0f 1f 44 00 00 55 48 89 f2 48 89 fe 48 c7 c7 74 f8 bf ba 48 89 e5 e8 f0 73 00 00 <0f> 0b 83 c8 03 48 c7 c7 e0 f7 bf ba 89 05 e9 de c9 00 e8 d9 73 00
[    3.295697] RSP: 0018:ffffa46800023e50 EFLAGS: 00010246
[    3.300999] RAX: 0000000000000040 RBX: 0000000000000000 RCX: 0000000000000000
[    3.308180] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000ffffffff
[    3.315481] RBP: ffffa46800023e50 R08: ffffffffbaec17e8 R09: 0000000000000003
[    3.322738] R10: ffffffffbae51800 R11: ffffffffbae51800 R12: ffffffffbb070f67
[    3.329899] R13: ffff8f4400160b40 R14: ffffffffbb1b1384 R15: 0000000000000000
[    3.337146] FS:  0000000000000000(0000) GS:ffff8f442ac80000(0000) knlGS:0000000000000000
[    3.337203] hub 1-1:1.0: USB hub found
[    3.345275] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.349839] hub 1-1:1.0: 4 ports detected
[    3.354806] CR2: 0000000000000000 CR3: 000000001020a000 CR4: 00000000000406e0
[    3.366011] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    3.366983] Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    3.366983] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Screenshots

Full bootlogs:

Scenario 1
Scenario 2
Scenario 3

Additional context

N/A

Solutions you've tried

All of the described scenarios

Relevant documentation you've consulted

N/A

Related, non-duplicate issues

N/A

Update TrenchBoot boot protocol for AMD in Secure Kernel Loader

Is your feature request related to a problem? Please describe.

The current implementation of the TrenchBoot boot protocol for AMD platforms in Secure Kernel Loader needs to be updated and aligned with the TrenchBoot boot protocol being upstreamed to GRUB2 and Linux kernel.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is required to ensure that the TrenchBoot support for AMD platforms in Secure Kernel Loader is up-to-date and compatible with the latest TrenchBoot boot protocol being upstreamed to GRUB2 and Linux kernel.

Describe the solution you'd like

Update the TrenchBoot boot protocol for AMD platforms in Secure Kernel Loader and align it with the TrenchBoot boot protocol being upstreamed to GRUB2 and Linux kernel.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 4 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Extend the AEM scripts to use appropriate software stack for TPM 2.0

Is your feature request related to a problem? Please describe.

Currently, only TPM 1.2 is supported in Qubes OS AEM service code. This issue is required to extend the AEM scripts to use the appropriate software stack and functions for TPM 2.0.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is required to extend Qubes OS AEM to support TPM 2.0 on Intel hardware.

Describe the solution you'd like

Extend the AEM scripts to use the appropriate software stack and functions for TPM 2.0. TPM 1.2 and TPM 2.0 software stacks are not compatible, so the scripts themselves must use the proper API for a given TPM and its respective software stack.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Code rebase onto the most recent work implementing Secure Launch protocol being upstreamed to Linux and GRUB

Is your feature request related to a problem? Please describe.

The current state of TrenchBoot support has diverged with what was developed for QubesOS AEM for Intel hardware with TPM 1.2. This task aims to update the work and align with the TrenchBoot boot protocol being upstreamed to GRUB and Linux kernel.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This issue is required to ensure Qubes OS AEM supports the most recent TrenchBoot boot protocol upstreamed to GRUB and Linux kernel, which will provide improved security and functionality.

Describe the solution you'd like

Rebase the code to the most recent work implementing Secure Launch protocol and align with the TrenchBoot boot protocol being upstreamed to GRUB and Linux kernel.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 3 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Extend the AEM scripts to detect TPM version on the platform

Is your feature request related to a problem? Please describe.

Currently, Qubes OS AEM fully supports TPM 1.2 but has no support for TPM 2.0. This issue is required to extend the AEM scripts to detect the TPM version on the platform and use the appropriate software stack for the given TPM.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is required to extend Qubes OS AEM to support TPM 2.0 on Intel hardware.

Describe the solution you'd like

Extend the AEM scripts to detect the TPM version on the platform and use the appropriate software stack for the given TPM. This issue implements the AEM TPM 1.2 equivalent functionalities using TPM 2.0 software stack and as a result allowing the use of TPM 2.0 with Qubes OS AEM. It will require implementing the access to TPM 2.0 NVRAM, sealing and unsealing the secret data and generating TOTP.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Update TrenchBoot boot protocol for AMD in GRUB2

Is your feature request related to a problem? Please describe.

Although some work has been done to implement TrenchBoot support for Qubes OS on AMD hardware using GRUB2, the current implementation is not fully aligned with the TrenchBoot boot protocol being upstreamed to GRUB2 and Linux kernel. This issue aims to update the current work and align it with the TrenchBoot boot protocol being upstreamed to GRUB2 and Linux kernel.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is necessary to ensure that the TrenchBoot support for Qubes OS on AMD hardware using GRUB2 is properly implemented and fully functional, thus improving the security and functionality of the TrenchBoot solution in general.

Describe the solution you'd like

Update the TrenchBoot boot protocol for AMD platforms in GRUB2 to align with the TrenchBoot boot protocol being upstreamed to GRUB2 and Linux kernel. GRUB2 with TrenchBoot support has been added to Qubes building system on 3mdeb fork.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 4 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Review Phase 1 TrenchBoot Intel TXT and TPM 1.2 support Rull Requests

Is your feature request related to a problem? Please describe.

This issue tracks the review, and merge process for the Pull Requests created to
add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2 and to implement Xen
Secure Launch with Intel TXT support in Xen for TrenchBoot as Anti Evil Maid
project.The problem is
that TrenchBoot, which is used as an anti-evil maid solution in Qubes OS, does
not currently support TPM 1.2 on Intel TXT path and does not have Xen Secure
Launch with Intel TXT support. This limits the hardware compatibility for
TrenchBoot and hinders its ability to protect against certain attacks.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

The feature request is to add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2
and to implement Xen Secure Launch with Intel TXT support in Xen for TrenchBoot.
This would allow TrenchBoot to support older Intel hardware with Intel TXT and
launch Xen directly via DRTM on Intel hardware, improving its hardware
compatibility and security.

Describe the solution you'd like

Following PRs merged:

1. Add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2:
   QubesOS/qubes-grub2#13
2. Implement Xen Secure Launch with Intel TXT support in Xen for TrenchBoot:
   QubesOS/qubes-vmm-xen#160

Describe alternatives you've considered
N/A

Additional context

This feature request is Phase 1 for TrenchBoot as Anti Evil Maid project, as
outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem/
and https://docs.dasharo.com/projects/trenchboot-aem-v2/

Relevant documentation you've consulted
N/A

Test TrenchBoot support on AMD hardware with TPM 2.0 and TPM 1.2 with legacy boot mode

Is your feature request related to a problem? Please describe.

After the implementation of the updated TrenchBoot boot protocol for AMD platforms in Secure Kernel Loader, it is necessary to test the solution on AMD hardware with TPM 2.0 and TPM 1.2 with legacy boot mode to ensure proper functionality.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This issue is required to ensure that the TrenchBoot support for AMD platforms with TPM 2.0 and TPM 1.2 with legacy boot mode works properly after the implementation of the updated TrenchBoot boot protocol for AMD platforms in Secure Kernel Loader.

Describe the solution you'd like

Test the TrenchBoot support on AMD hardware with TPM 2.0 and TPM 1.2 with legacy boot mode to ensure proper functionality after the implementation of the updated TrenchBoot boot protocol for AMD platforms in Secure Kernel Loader.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 4 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Test TPM 2.0 support on Intel hardware with legacy boot mode and Update Qubes OS AEM documentation

Is your feature request related to a problem? Please describe.

The current Qubes OS AEM documentation does not provide information on TPM 2.0 support or how to use it with legacy boot mode on Intel hardware. Additionally, it is necessary to test the solution on Intel hardware with TPM 1.2 and 2.0 using legacy boot mode to ensure proper functionality.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is required to ensure that the Qubes OS AEM documentation is up-to-date and provides accurate information on how to use TPM 2.0 with legacy boot mode on Intel hardware. Proper testing is crucial to ensure the implementation works as expected on Intel hardware configuration.

Describe the solution you'd like
Test the solution on Intel hardware with TPM 1.2 and 2.0 using legacy boot mode to ensure proper functionality. Update the Qubes OS AEM documentation to include information on TPM 2.0 support and how to use it with legacy boot mode on Intel hardware.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Support for TPM 2.0 event log in Xen

Is your feature request related to a problem? Please describe.

Currently, Qubes OS AEM does not support logging of the Dom0 kernel and initial ram disk hashes to the TPM event log due to lack of TPM 2.0 event log support in Xen.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This issue is required to enable logging of the Dom0 kernel and initial ram disk hashes to the TPM event log, which could be used for future system attestation.

Describe the solution you'd like

Implement support for the TPM 2.0 event log in Xen to enable logging of the Dom0 kernel and initial ram disk hashes to the TPM event log.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Force all PCIe devices through D3Cold

The problem you're addressing (if any)
The only quasi-guaranteed way to reset a PCIe device is to force it through D3Cold (electrically powered off). Otherwise, there is an increased risk that state could be carried over, which could be used to compromise the next user of the device.

Describe the solution you'd like
Hold all PCIe devices in D3Cold for long enough for internal capacitors to discharge.

Where is the value to a user, and who might that user be?
All users who use PCIe pass-through to untrusted VMs, or VFIO with untrusted userspace drivers, will benefit from improved security. This includes all users of Qubes OS

Describe alternatives you've considered
None

Additional context
None

Relevant documentation you've consulted
Private communication

Related, non-duplicate issues
None

Implement parallel CPU cores bring-up for DRTM launch

Is your feature request related to a problem? Please describe.

Currently, the CPU cores are being woken up in parallel for DRTM launch in Qubes OS AEM, but later they are hacked to be waiting in a queue. If any interrupt would come at that time, it could be a serious danger. This needs to be fixed as soon as possible as required by Intel TXT specification.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is required to ensure the proper functioning of parallel CPU cores bring-up for DRTM launch in Qubes OS AEM as per Intel TXT specification.

Describe the solution you'd like

Implement parallel CPU cores bring-up for DRTM launch in Qubes OS AEM in compliance with the Intel TXT specification.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

TrenchBoot as a main provider of Anti Evil Maid for QubesOS for all x86 platforms

Is your feature request related to a problem? Please describe.
Not related to a problem specifically, but widening the use of TrenchBoot.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.
The idea is to extend the qubes-antievilmaid to support:

• TrenchBoot as the main provider of DRTM capable software
• both TPM 1.2 and TPM 2.0
• both Intel and AMD platforms
• both UEFI and legacy boot mode

Currently, QubeOS AEM supports only Intel TXT and TPM 1.2 in legacy boot mode which significantly limits the hardware that can be used. This is a perfect hole that TrenchBoot may perfectly fill.

Describe the solution you'd like
What is needed for PoC?

• Clean up the LandingZone package support for QubesOS: https://github.com/3mdeb/qubes-landing-zone/tree/lz_support (it needs renaming to SKL and probably a new release with new features)
• Rebase/refresh TrenchBoot GRUB2 for QubesOS: https://github.com/3mdeb/qubes-grub2/tree/trenchboot_support
• Add TPM1.2 support for Intel TXT
• Extend the AEM scripts to detect TPM version on the platform
• Extend the AEM scripts to use appropriate software stack for TPM 2.0 if present and include the stack in the dracut scripts
• TrenchBoot secure kernel loader will need improvements for AMD server SKUs with multiple nodes.
• Xen Secure Launch - Intel TXT support in Xen for TrenchBoot
• Test the solution on AMD and Intel hardware with TPM 2.0 and TPM1.2 with legacy boot mode

What is needed for a complete solution?

• TrenchBoot support for UEFI boot mode for AMD in GRUB and Xen. GRUB + Linux combination is rather known to work on Intel, but not on AMD.
• TrenchBoot support for UEFI boot mode in GRUB and Xen. Xen needs the UEFI Boot Services otherwise it won't boot, so it would be necessary to implement booting Xen without Boot Services.
• TrenchBoot support in GRUB2 merged upstream and shipped in a stable GRUB release
• Test the solution on AMD and Intel hardware with TPM 2.0 and TPM1.2 with legacy and UEFI boot mode

Describe alternatives you've considered
None.

Additional context
Some work has been done to show AEM on AMD and TPM 2.0. What has been achieved and proven to work is:

• TrenchBoot for AMD platform with former Landing Zone and GRUB with TrenchBoot support successfully booting Qubes OS.
• Successfully extended PCRs 17+ when slaunch is enabled in grub.cfg.

Rewriting the scripts to use TPM 2.0 software stack has been attempted but not finished. The effort has been presented on QubesOS and 3mdeb minisummit 2020: https://youtu.be/rM0vRi6qABE

Relevant documentation you've consulted
QubesOS/qubes-issues#6793

Proposal
https://docs.dasharo.com/projects/trenchboot-aem/

Support for TPM 2.0 module in Xen

Is your feature request related to a problem? Please describe.

Currently, Qubes OS AEM does not support TPM 2.0 in Xen, preventing the measurement of the Dom0 kernel and initial ram disk before they are executed.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This task is required to extend Qubes OS AEM to support TPM 2.0 on Intel hardware.

Describe the solution you'd like

Implement support for the TPM 2.0 module in Xen to enable the measurement of the Dom0 kernel and initial ram disk hashes.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as
outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

TrenchBoot Secure Kernel Loader (SKL) improvements for AMD server CPUs with multiple nodes

Is your feature request related to a problem? Please describe.

While the TrenchBoot Secure Kernel Loader (SKL) has been extensively tested on System on Chip and single CPU platforms, it has not been tested much on workstation/server segment CPUs which are more complex. For example, one server CPU package may contain two independent CPUs inside called nodes. Each node will enable protection on the SKL during DRTM execution. This protection has to be disabled on each node when TrenchBoot DRTM tasks are done. The task aims to implement the correct support for server CPUs in TrenchBoot SKL.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

Improvements to the TrenchBoot Secure Kernel Loader (SKL) for AMD server CPUs with multiple nodes would benefit the project by enabling the correct support for server CPUs and improving overall performance and security.

Describe the solution you'd like

Implement the correct support for server CPUs in TrenchBoot SKL.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 4 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

Improve navigation in the documentation

The problem you're addressing (if any)

Improve navigation in the documentation (trenchboot.org site)

Describe the solution you'd like

There were some specific requests (gathered from various channels) regarding the documentation navigation that could be improved:

• [1] Menu bar could respond to mouse-over events for faster site navigation
• TBD
• TBD
• TBD

Where is the value to a user, and who might that user be?

Both new and existing users of the documentation could benefit from better site navigation
and content organization (for content organization we will have a separate issue and discussion: TBD).

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features
you've considered.

Additional context

N/A

Relevant documentation you've consulted

N/A

Related, non-duplicate issues

N/A

Retest the solution on Intel hardware with TPM 1.2 and TPM 2.0 using legacy boot mode

Is your feature request related to a problem? Please describe.

It is necessary to retest the solution on Intel hardware with TPM 1.2 and TPM 2.0 using legacy boot mode to ensure proper functionality after updating the TrenchBoot support in Qubes OS AEM.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

This issue is required to ensure that the TrenchBoot support continues to work properly on Intel hardware with TPM 1.2 and TPM 2.0 using legacy boot mode after the code rebase onto the most recent work implementing Secure Launch protocol being upstreamed to Linux and GRUB implementation (#17).

Describe the solution you'd like

Retest the TrenchBoot support on Intel hardware with TPM 1.2 and TPM 2.0 using legacy boot mode after the code rebase onto the most recent work implementing Secure Launch protocol being upstreamed to Linux and GRUB to ensure proper functionality.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 3 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

TPM 1.2 support for Intel TXT path in GRUB

The problem you're addressing (if any)
GRUB with TrenchBoot support refuses to perform measured launch on Intel TXT enabled platform with TPM 1.2. The TPM 1.2 is reported as unsupported.

Describe the solution you'd like
Implement the TrechBoot support for TPM 1.2 for Intel TXT path in GRUB.

Where is the value to a user, and who might that user be?
Users with a slightly older platform still have TPM 1.2 onboard. The Intel ACMs are tightly coupled to TPM versions that were available at the time of platform shipment OR the TPMs are soldered and there are no means to upgrade their firmware even if the Intel ACM supports TPM2.0. Because of this, platforms owners might not be able to use TrenchBoot.

Describe alternatives you've considered
There are a few alternatives, but I do not consider them valid in my case:

• buy newer hardware with TPM 2.0
• use Intel Trusted Boot (tboot)

Additional context
When GRUB debugging is enabled for slaunch module, the GRUB prints an error on the debug console TPM 1.2 is not supported:

Relevant documentation you've consulted
https://github.com/TrenchBoot/grub/blob/intel-txt/grub-core/loader/i386/txt/txt.c#L617

Related, non-duplicate issues
None

Update the Secure Kernel Loader package support for QubesOS

Is your feature request related to a problem? Please describe.

Since the initial work done by 3mdeb engineers for AMD AEM in Qubes OS, the Secure Kernel Loader (formerly Landing Zone) package support has not been updated. The package has undergone significant improvements and added new features. SKL is an open-source module written by TrenchBoot developers required by AMD Secure Startup technology to perform DRTM launch. The task aims to refresh the previous work and update the SKL package for Qubes OS to the newest revision.

Is your feature request related to a new idea or technology that
would benefit the project? Please describe.

Updating the Secure Kernel Loader package support for QubesOS on AMD would benefit the project by providing a more up-to-date and reliable version of the package, which is essential for AMD Secure Startup technology to perform DRTM launch.

Describe the solution you'd like

Update the Secure Kernel Loader (SKL) package support for QubesOS on AMD to the newest revision.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 4 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Checklist:

• SKL package for QubesOS
• Above building in github actions
• Ensure SKL builds for different compilers - push https://github.com/TrenchBoot/secure-kernel-loader/blob/master/.github/workflows/build.yml forward
• Additional CI checks:
  • TrenchBoot/secure-kernel-loader#12
  • pre-commit ? we have some templates: https://github.com/3mdeb/hooks/blob/main/pre-commit-init/pre-commit-init.py but maybe not extra useful for this SKL repo
  • other proposals

Relevant documentation you've consulted

N/A