The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
 - Intel TXT and AMD SKINIT on x86 CPUs
 - legacy and UEFI boot
 - TPM1.2 and TPM2.0
 - (in the future) DRTM on Arm CPUs

DRTM is a version of a measured launch that starts on request rather
than at the start of a boot cycle.  One of its advantages is in not
including the firmware in the chain of trust.

Xen already supports DRTM via [tboot] which targets Intel TXT only.
tboot employs encapsulates some of the DRTM details within itself while
with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
for a TrenchBoot-enabled bootloader (think GRUB).  The one exception is
that UEFI case requires calling back into bootloader to initiate DRTM,
which is necessary to give Xen a chance of querying all the information
it needs from the firmware before performing DRTM start.

From reading the above tboot might seem like a more abstracted, but the
reality is that the payload needs to have DRTM-specific knowledge either
way.  TrenchBoot in principle allows coming up with independent
implementations of bootloaders and payloads that are compatible with
each other.

The "x86/boot: choose AP stack based on APIC ID" patch is shared with
[Parallelize AP bring-up] series which is required here because Intel
TXT always releases all APs simultaneously.  The rest of the patches are
unique.

-----

[TrenchBoot]: https://trenchboot.org/
[tboot]: https://sourceforge.net/p/tboot/wiki/Home/
[Parallelize AP bring-up]: https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/

-----

Kacper Stojek (2):
  x86/boot: add MLE header and new entry point
  xen/arch/x86: reserve TXT memory

Krystian Hebel (7):
  x86/include/asm/intel_txt.h: constants and accessors for TXT registers
    and heap
  x86/boot/slaunch_early: early TXT checks and boot data retrieval
  x86/intel_txt.c: restore boot MTRRs
  lib/sha1.c: add file
  x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)
  x86/boot: choose AP stack based on APIC ID
  x86/smpboot.c: TXT AP bringup

Michał Żygowski (2):
  x86/hvm: Check for VMX in SMX when slaunch active
  x86/cpu: report SMX, TXT and SKINIT capabilities

Sergii Dmytruk (10):
  include/xen/slr_table.h: Secure Launch Resource Table definitions
  x86/boot/slaunch_early: implement early initialization
  x86/mtrr: expose functions for pausing caching
  lib/sha256.c: add file
  x86/tpm.c: support extending PCRs of TPM2.0
  x86/tpm.c: implement event log for TPM2.0
  arch/x86: process DRTM policy
  x86/boot: find MBI and SLRT on AMD
  arch/x86: support slaunch with AMD SKINIT
  x86/slaunch: support EFI boot

 .gitignore                                  |    1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst |    7 +
 xen/arch/x86/Makefile                       |   12 +-
 xen/arch/x86/boot/Makefile                  |   10 +-
 xen/arch/x86/boot/head.S                    |  250 +++++
 xen/arch/x86/boot/slaunch_early.c           |  105 ++
 xen/arch/x86/boot/trampoline.S              |   40 +-
 xen/arch/x86/boot/x86_64.S                  |   42 +-
 xen/arch/x86/cpu/amd.c                      |   14 +
 xen/arch/x86/cpu/cpu.h                      |    1 +
 xen/arch/x86/cpu/hygon.c                    |    1 +
 xen/arch/x86/cpu/intel.c                    |   44 +
 xen/arch/x86/cpu/mtrr/generic.c             |   51 +-
 xen/arch/x86/e820.c                         |    5 +
 xen/arch/x86/efi/efi-boot.h                 |   90 +-
 xen/arch/x86/efi/fixmlehdr.c                |  122 +++
 xen/arch/x86/hvm/vmx/vmcs.c                 |    3 +-
 xen/arch/x86/include/asm/apicdef.h          |    4 +
 xen/arch/x86/include/asm/intel_txt.h        |  452 ++++++++
 xen/arch/x86/include/asm/mm.h               |    3 +
 xen/arch/x86/include/asm/msr-index.h        |    3 +
 xen/arch/x86/include/asm/mtrr.h             |    8 +
 xen/arch/x86/include/asm/processor.h        |    1 +
 xen/arch/x86/include/asm/slaunch.h          |   91 ++
 xen/arch/x86/include/asm/tpm.h              |   19 +
 xen/arch/x86/intel_txt.c                    |  177 ++++
 xen/arch/x86/setup.c                        |   32 +-
 xen/arch/x86/slaunch.c                      |  464 ++++++++
 xen/arch/x86/smpboot.c                      |   57 +
 xen/arch/x86/tboot.c                        |   20 +-
 xen/arch/x86/tpm.c                          | 1057 +++++++++++++++++++
 xen/common/efi/boot.c                       |    4 +
 xen/common/efi/runtime.c                    |    1 +
 xen/include/xen/efi.h                       |    1 +
 xen/include/xen/sha1.h                      |   12 +
 xen/include/xen/sha256.h                    |   12 +
 xen/include/xen/slr_table.h                 |  274 +++++
 xen/lib/Makefile                            |    2 +
 xen/lib/sha1.c                              |  240 +++++
 xen/lib/sha256.c                            |  238 +++++
 40 files changed, 3914 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/x86/boot/slaunch_early.c
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c
 create mode 100644 xen/arch/x86/include/asm/intel_txt.h
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/intel_txt.c
 create mode 100644 xen/arch/x86/slaunch.c
 create mode 100644 xen/arch/x86/tpm.c
 create mode 100644 xen/include/xen/sha1.h
 create mode 100644 xen/include/xen/sha256.h
 create mode 100644 xen/include/xen/slr_table.h
 create mode 100644 xen/lib/sha1.c
 create mode 100644 xen/lib/sha256.c


base-commit: df68a4cb7ed9418f0c5af56a717714b5280737e4
prerequisite-patch-id: 1c3014908bc6e1a5cab8de609270efdb1c412335
prerequisite-patch-id: 850544a1f9639283f2269ea75b630400dd1976aa
prerequisite-patch-id: 69e042a46f8ac0e3f85853e77082caf250719a8d
prerequisite-patch-id: d6c6d27bbe8ff2f5d96852a6eed72a4c99b61356
-- 
2.49.0

On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
> The aim of the [TrenchBoot] project is to provide an implementation of
> DRTM that is generic enough to cover various use cases:
>  - Intel TXT and AMD SKINIT on x86 CPUs
>  - legacy and UEFI boot
>  - TPM1.2 and TPM2.0
>  - (in the future) DRTM on Arm CPUs
>
> DRTM is a version of a measured launch that starts on request rather
> than at the start of a boot cycle.  One of its advantages is in not
> including the firmware in the chain of trust.
>
> Xen already supports DRTM via [tboot] which targets Intel TXT only.
> tboot employs encapsulates some of the DRTM details within itself while
> with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
> for a TrenchBoot-enabled bootloader (think GRUB).  The one exception is
> that UEFI case requires calling back into bootloader to initiate DRTM,
> which is necessary to give Xen a chance of querying all the information
> it needs from the firmware before performing DRTM start.
>
> From reading the above tboot might seem like a more abstracted, but the
> reality is that the payload needs to have DRTM-specific knowledge either
> way.  TrenchBoot in principle allows coming up with independent
> implementations of bootloaders and payloads that are compatible with
> each other.
>
> The "x86/boot: choose AP stack based on APIC ID" patch is shared with
> [Parallelize AP bring-up] series which is required here because Intel
> TXT always releases all APs simultaneously.  The rest of the patches are
> unique.

I've stripped out the sha2 patch and fixed up to use the existing sha2,
then kicked off some CI testing:

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
https://cirrus-ci.com/build/5452335868018688

When the dust has settled, I'll talk you through the failures.

~Andrew

On 22/04/2025 6:14 pm, Andrew Cooper wrote:
> I've stripped out the sha2 patch and fixed up to use the existing sha2,
> then kicked off some CI testing:
>
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
> https://cirrus-ci.com/build/5452335868018688
>
> When the dust has settled, I'll talk you through the failures.

And here we go.  Interestingly, the FreeBSD testing was entirely happy,
and that is the rare way around.

For Gitlab, there are several areas.

First, for MISRA.  In the job logs, you want the "Browse current
reports:" link which will give you full details, but it's all pretty
simple stuff.

kbl-suspend-x86-64-gcc-debug is a real S3 test on KabyLake hardware,
which appears to have gone to sleep and never woken up.  (More likely,
crashed on wakeup before we got the console up).  The AlderLake
equivalent test seems to be happy, as well as the AMD ones.

For the build issues, there are quite a few.

debian-12-x86_64-gcc-ibt is special, using an out-of-tree patch for
CET-IBT safety.  tl;dr function pointer callees need a cf_check
annotation.  But, all the failures here are from sha1, and from bits
which I don't think want to survive into the final form.

Other common failures seem to be:

    # take image offset into account
    arch/x86/efi/fixmlehdr xen.efi 0x200000
    Failed to find MLE header in xen.efi
    arch/x86/Makefile:220: recipe for target 'xen.efi' failed
    make[3]: *** [xen.efi] Error 1

~Andrew

On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
> On 22/04/2025 6:14 pm, Andrew Cooper wrote:
> > I've stripped out the sha2 patch and fixed up to use the existing sha2,
> > then kicked off some CI testing:
> >
> > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
> > https://cirrus-ci.com/build/5452335868018688
> >
> > When the dust has settled, I'll talk you through the failures.
>
> And here we go.  Interestingly, the FreeBSD testing was entirely happy,
> and that is the rare way around.
>
> For Gitlab, there are several areas.
>
> First, for MISRA.  In the job logs, you want the "Browse current
> reports:" link which will give you full details, but it's all pretty
> simple stuff.

Thanks, but that link gives me a list of 5096 failures all over the code
base.  Is there any way to see a diff against master?

> kbl-suspend-x86-64-gcc-debug is a real S3 test on KabyLake hardware,
> which appears to have gone to sleep and never woken up.  (More likely,
> crashed on wakeup before we got the console up).  The AlderLake
> equivalent test seems to be happy, as well as the AMD ones.

Hm, not sure what that could be, but will try to reproduce/guess.

> For the build issues, there are quite a few.
>
> debian-12-x86_64-gcc-ibt is special, using an out-of-tree patch for
> CET-IBT safety.  tl;dr function pointer callees need a cf_check
> annotation.  But, all the failures here are from sha1, and from bits
> which I don't think want to survive into the final form.

That stuff is gone and the build should succeed the next time.

> Other common failures seem to be:
>
>     # take image offset into account
>     arch/x86/efi/fixmlehdr xen.efi 0x200000
>     Failed to find MLE header in xen.efi
>     arch/x86/Makefile:220: recipe for target 'xen.efi' failed
>     make[3]: *** [xen.efi] Error 1
>
> ~Andrew

That seems to be the only reason behind the rest of build failures.
I was able to reproduce the failure in Fedora 37 docker.  Searching for
the header in 8KiB instead of 4KiB fixes it.  Looks like large default
alignment of some toolchains pushes `head.S` to 4 KiB offset.

On 23/04/2025 7:45 pm, Sergii Dmytruk wrote:
> On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
>> On 22/04/2025 6:14 pm, Andrew Cooper wrote:
>>> I've stripped out the sha2 patch and fixed up to use the existing sha2,
>>> then kicked off some CI testing:
>>>
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
>>> https://cirrus-ci.com/build/5452335868018688
>>>
>>> When the dust has settled, I'll talk you through the failures.
>> And here we go.  Interestingly, the FreeBSD testing was entirely happy,
>> and that is the rare way around.
>>
>> For Gitlab, there are several areas.
>>
>> First, for MISRA.  In the job logs, you want the "Browse current
>> reports:" link which will give you full details, but it's all pretty
>> simple stuff.
> Thanks, but that link gives me a list of 5096 failures all over the code
> base.  Is there any way to see a diff against master?

No sadly not.  What you see is a mix of the blocking issues, and the "we
want to see these so we can work on them".

Immediately under the link is the one-line tl;dr.  For ARM, it's just a
single:

Failure: 1 regressions found for clean guidelines
  service MC3A2.R7.2: (required) A `u' or `U' suffix shall be applied to
all integer constants that are represented in an unsigned type:
   violation: 1

Clicking through into the R7.2 analysis shows
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/ARM64/9791028027/PROJECT.ecd;/by_service/MC3A2.R7.2.html

This violation is shared with x86 because it's a header pulled into a
common file.

For x86, the list is rather longer.  You've got:

6x D1.1
2x D4.14
1x R5.3
116x R7.2
1x R7.3
12x R8.3
7x R8.4
1x R11.9
87x R20.7

These are the blocking directives/rules.  Others which you see in the
overall report are non-blocking.

>
>> kbl-suspend-x86-64-gcc-debug is a real S3 test on KabyLake hardware,
>> which appears to have gone to sleep and never woken up.  (More likely,
>> crashed on wakeup before we got the console up).  The AlderLake
>> equivalent test seems to be happy, as well as the AMD ones.
> Hm, not sure what that could be, but will try to reproduce/guess.

KBL is unreliable in one specific way, but not with these symptoms.

I reran the suspend test, and it failed in the same way.  I think it's a
deterministic bug.

I can probably dig out my emergency serial debugging patches for S3 if
you want?

>> Other common failures seem to be:
>>
>>     # take image offset into account
>>     arch/x86/efi/fixmlehdr xen.efi 0x200000
>>     Failed to find MLE header in xen.efi
>>     arch/x86/Makefile:220: recipe for target 'xen.efi' failed
>>     make[3]: *** [xen.efi] Error 1
>>
>> ~Andrew
> That seems to be the only reason behind the rest of build failures.
> I was able to reproduce the failure in Fedora 37 docker.  Searching for
> the header in 8KiB instead of 4KiB fixes it.  Looks like large default
> alignment of some toolchains pushes `head.S` to 4 KiB offset.

FYI, you can access all the Xen containers with:

CONTAINER=foo ./automation/scripts/containerize

in the xen.git tree.

Alignment that large is unexpected, and I suspect we want to fix it.  Is
it pre-existing, or something introduced by your series?

~Andrew

On Wed, Apr 23, 2025 at 11:43:15PM +0100, Andrew Cooper wrote:
> On 23/04/2025 7:45 pm, Sergii Dmytruk wrote:
> > On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
> >> On 22/04/2025 6:14 pm, Andrew Cooper wrote:
> >>> I've stripped out the sha2 patch and fixed up to use the existing sha2,
> >>> then kicked off some CI testing:
> >>>
> >>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
> >>> https://cirrus-ci.com/build/5452335868018688
> >>>
> >>> When the dust has settled, I'll talk you through the failures.
> >> And here we go.  Interestingly, the FreeBSD testing was entirely happy,
> >> and that is the rare way around.
> >>
> >> For Gitlab, there are several areas.
> >>
> >> First, for MISRA.  In the job logs, you want the "Browse current
> >> reports:" link which will give you full details, but it's all pretty
> >> simple stuff.
> > Thanks, but that link gives me a list of 5096 failures all over the code
> > base.  Is there any way to see a diff against master?
>
> No sadly not.  What you see is a mix of the blocking issues, and the "we
> want to see these so we can work on them".

Nicola Vetrini explained how some errors can be filtered in
https://lore.kernel.org/xen-devel/c2940798-11d0-4aaa-a013-64bef9bbdb82@apertussolutions.com/T/#m153e1cf8a6ef37d3d301253624c07fa3c25814c2
At least in this case it works when done correctly.

> >> kbl-suspend-x86-64-gcc-debug is a real S3 test on KabyLake hardware,
> >> which appears to have gone to sleep and never woken up.  (More likely,
> >> crashed on wakeup before we got the console up).  The AlderLake
> >> equivalent test seems to be happy, as well as the AMD ones.
> > Hm, not sure what that could be, but will try to reproduce/guess.
>
> KBL is unreliable in one specific way, but not with these symptoms.
>
> I reran the suspend test, and it failed in the same way.  I think it's a
> deterministic bug.
>
> I can probably dig out my emergency serial debugging patches for S3 if
> you want?

Thanks, I'll try to come up with something first.  So far I thought
about a change in how stack is picked for APs, but I would expect all
hardware to have issues with S3 if that was the problem.

> >> Other common failures seem to be:
> >>
> >>     # take image offset into account
> >>     arch/x86/efi/fixmlehdr xen.efi 0x200000
> >>     Failed to find MLE header in xen.efi
> >>     arch/x86/Makefile:220: recipe for target 'xen.efi' failed
> >>     make[3]: *** [xen.efi] Error 1
> >>
> >> ~Andrew
> > That seems to be the only reason behind the rest of build failures.
> > I was able to reproduce the failure in Fedora 37 docker.  Searching for
> > the header in 8KiB instead of 4KiB fixes it.  Looks like large default
> > alignment of some toolchains pushes `head.S` to 4 KiB offset.
>
> FYI, you can access all the Xen containers with:
>
> CONTAINER=foo ./automation/scripts/containerize
>
> in the xen.git tree.

Thanks, that looks more convenient.

> Alignment that large is unexpected, and I suspect we want to fix it.  Is
> it pre-existing, or something introduced by your series?
>
> ~Andrew

Pre-existing one.  I can see `-N` is already passed to `ld`:

-N, --omagic     Do not page align data, do not make text readonly

Specifying `--section-alignment 512 --file-alignment 512 --nmagic`
didn't reduce the alignment.  Statistics so far:

  Give 0x1000 offset:
  GNU ld (GNU Binutils for Debian) 2.31.1
  GNU ld version 2.38-27.fc37

  Give 0x440 offset:
  GNU ld (GNU Binutils for Debian) 2.40
  GNU ld (GNU Binutils for Debian) 2.41

Maybe that's not something configurable and just needs a newer version.

On 24/04/2025 7:47 pm, Sergii Dmytruk wrote:
>> Alignment that large is unexpected, and I suspect we want to fix it.  Is
>> it pre-existing, or something introduced by your series?
>>
>> ~Andrew
> Pre-existing one.  I can see `-N` is already passed to `ld`:
>
> -N, --omagic     Do not page align data, do not make text readonly
>
> Specifying `--section-alignment 512 --file-alignment 512 --nmagic`
> didn't reduce the alignment.  Statistics so far:
>
>   Give 0x1000 offset:
>   GNU ld (GNU Binutils for Debian) 2.31.1
>   GNU ld version 2.38-27.fc37
>
>   Give 0x440 offset:
>   GNU ld (GNU Binutils for Debian) 2.40
>   GNU ld (GNU Binutils for Debian) 2.41
>
> Maybe that's not something configurable and just needs a newer version.

Ah - that's something that was changed literally yesterday:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=d444763f8ca556d0a67a4b933be303d346baef02

in order to fix some problems we've had trying to get xen.efi happy to
be NX_COMPAT.

We couldn't identify any good reason why -N was in use.

~Andrew

On Thu, Apr 24, 2025 at 07:51:21PM +0100, Andrew Cooper wrote:
> On 24/04/2025 7:47 pm, Sergii Dmytruk wrote:
> >> Alignment that large is unexpected, and I suspect we want to fix it.  Is
> >> it pre-existing, or something introduced by your series?
> >>
> >> ~Andrew
> > Pre-existing one.  I can see `-N` is already passed to `ld`:
> >
> > -N, --omagic     Do not page align data, do not make text readonly
> >
> > Specifying `--section-alignment 512 --file-alignment 512 --nmagic`
> > didn't reduce the alignment.  Statistics so far:
> >
> >   Give 0x1000 offset:
> >   GNU ld (GNU Binutils for Debian) 2.31.1
> >   GNU ld version 2.38-27.fc37
> >
> >   Give 0x440 offset:
> >   GNU ld (GNU Binutils for Debian) 2.40
> >   GNU ld (GNU Binutils for Debian) 2.41
> >
> > Maybe that's not something configurable and just needs a newer version.
>
> Ah - that's something that was changed literally yesterday:
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=d444763f8ca556d0a67a4b933be303d346baef02
>
> in order to fix some problems we've had trying to get xen.efi happy to
> be NX_COMPAT.
>
> We couldn't identify any good reason why -N was in use.
>
> ~Andrew

The fewer cryptic flags the better, but adding either of those flags or
removing -N doesn't affect the file offset.  EFI_LDFLAGS even includes
--file-alignment=0x20, it just gets ignored and that could be
target-specific behaviour in older versions of ld.  This commit by Jan
Beulich might be the one fixing it:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bc5baa9f13ffb3fd4c39f1a779062bfb3a980cea

On 2025-04-23 20:45, Sergii Dmytruk wrote:
> On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
>> On 22/04/2025 6:14 pm, Andrew Cooper wrote:
>> > I've stripped out the sha2 patch and fixed up to use the existing sha2,
>> > then kicked off some CI testing:
>> >
>> > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
>> > https://cirrus-ci.com/build/5452335868018688
>> >
>> > When the dust has settled, I'll talk you through the failures.
>> 
>> And here we go.  Interestingly, the FreeBSD testing was entirely 
>> happy,
>> and that is the rare way around.
>> 
>> For Gitlab, there are several areas.
>> 
>> First, for MISRA.  In the job logs, you want the "Browse current
>> reports:" link which will give you full details, but it's all pretty
>> simple stuff.
> 
> Thanks, but that link gives me a list of 5096 failures all over the 
> code
> base.  Is there any way to see a diff against master?
> 

Hi,

yes, you can define selections of violations introduced on previously 
clean guidelines by clicking on the "ECLAIR" button on the upper right. 
See [1] which is the result of defining the "clean_added" selection 
shown in the attached screenshot. If you have other questions please let 
me know.

Thanks,
  Nicola

[1] 
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/ARM64/9791028027/PROJECT.ecd;/by_service.html#service&kind{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]}]}}}

>> kbl-suspend-x86-64-gcc-debug is a real S3 test on KabyLake hardware,
>> which appears to have gone to sleep and never woken up.  (More likely,
>> crashed on wakeup before we got the console up).  The AlderLake
>> equivalent test seems to be happy, as well as the AMD ones.
> 
> Hm, not sure what that could be, but will try to reproduce/guess.
> 
>> For the build issues, there are quite a few.
>> 
>> debian-12-x86_64-gcc-ibt is special, using an out-of-tree patch for
>> CET-IBT safety.  tl;dr function pointer callees need a cf_check
>> annotation.  But, all the failures here are from sha1, and from bits
>> which I don't think want to survive into the final form.
> 
> That stuff is gone and the build should succeed the next time.
> 
>> Other common failures seem to be:
>> 
>>     # take image offset into account
>>     arch/x86/efi/fixmlehdr xen.efi 0x200000
>>     Failed to find MLE header in xen.efi
>>     arch/x86/Makefile:220: recipe for target 'xen.efi' failed
>>     make[3]: *** [xen.efi] Error 1
>> 
>> ~Andrew
> 
> That seems to be the only reason behind the rest of build failures.
> I was able to reproduce the failure in Fedora 37 docker.  Searching for
> the header in 8KiB instead of 4KiB fixes it.  Looks like large default
> alignment of some toolchains pushes `head.S` to 4 KiB offset.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

On Wed, Apr 23, 2025 at 10:11:35PM +0200, Nicola Vetrini wrote:
> On 2025-04-23 20:45, Sergii Dmytruk wrote:
> > On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
> > > On 22/04/2025 6:14 pm, Andrew Cooper wrote:
> > > > I've stripped out the sha2 patch and fixed up to use the existing sha2,
> > > > then kicked off some CI testing:
> > > >
> > > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
> > > > https://cirrus-ci.com/build/5452335868018688
> > > >
> > > > When the dust has settled, I'll talk you through the failures.
> > >
> > > And here we go.  Interestingly, the FreeBSD testing was entirely
> > > happy,
> > > and that is the rare way around.
> > >
> > > For Gitlab, there are several areas.
> > >
> > > First, for MISRA.  In the job logs, you want the "Browse current
> > > reports:" link which will give you full details, but it's all pretty
> > > simple stuff.
> >
> > Thanks, but that link gives me a list of 5096 failures all over the code
> > base.  Is there any way to see a diff against master?
> >
>
> Hi,
>
> yes, you can define selections of violations introduced on previously clean
> guidelines by clicking on the "ECLAIR" button on the upper right. See [1]
> which is the result of defining the "clean_added" selection shown in the
> attached screenshot. If you have other questions please let me know.

Hi,

not sure why, but using "added" left 4861 violations.  Picking `_NO_TAG`
instead seemingly left only new violations.  Maybe that's something
specific to this particular run.  Either way, I can go through the list
now and know how to adjust it.  Thank you for the instructions.

> Thanks,
>  Nicola
>
> [1] https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/ARM64/9791028027/PROJECT.ecd;/by_service.html#service&kind{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]}]}}}

On 4/23/25 23:53, Sergii Dmytruk wrote:
> On Wed, Apr 23, 2025 at 10:11:35PM +0200, Nicola Vetrini wrote:
>> On 2025-04-23 20:45, Sergii Dmytruk wrote:
>>> On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
>>>> On 22/04/2025 6:14 pm, Andrew Cooper wrote:
>>>>> I've stripped out the sha2 patch and fixed up to use the existing sha2,
>>>>> then kicked off some CI testing:
>>>>>
>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
>>>>> https://cirrus-ci.com/build/5452335868018688
>>>>>
>>>>> When the dust has settled, I'll talk you through the failures.
>>>> And here we go.  Interestingly, the FreeBSD testing was entirely
>>>> happy,
>>>> and that is the rare way around.
>>>>
>>>> For Gitlab, there are several areas.
>>>>
>>>> First, for MISRA.  In the job logs, you want the "Browse current
>>>> reports:" link which will give you full details, but it's all pretty
>>>> simple stuff.
>>> Thanks, but that link gives me a list of 5096 failures all over the code
>>> base.  Is there any way to see a diff against master?
>>>
>> Hi,
>>
>> yes, you can define selections of violations introduced on previously clean
>> guidelines by clicking on the "ECLAIR" button on the upper right. See [1]
>> which is the result of defining the "clean_added" selection shown in the
>> attached screenshot. If you have other questions please let me know.
> Hi,
>
> not sure why, but using "added" left 4861 violations.  Picking `_NO_TAG`
> instead seemingly left only new violations.  Maybe that's something
> specific to this particular run.  Either way, I can go through the list
> now and know how to adjust it.  Thank you for the instructions.
>
I'm not sure I fully understand this. This is what I see on x86: the 
ones still shown are those rules where the CI is blocking and new issues 
have been introduced by that pipeline run (of course a different 
pipeline may yield different results). Only new violations are blocking, 
so that is why I filtered out the rest in this case.

Thanks,

  Nicola

>> Thanks,
>>   Nicola
>>
>> [1] https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/ARM64/9791028027/PROJECT.ecd;/by_service.html#service&kind{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]}]}}}

On Thu, Apr 24, 2025 at 12:54:41PM +0200, Nicola Vetrini wrote:
>
> On 4/23/25 23:53, Sergii Dmytruk wrote:
> > On Wed, Apr 23, 2025 at 10:11:35PM +0200, Nicola Vetrini wrote:
> > > On 2025-04-23 20:45, Sergii Dmytruk wrote:
> > > > On Wed, Apr 23, 2025 at 02:38:37PM +0100, Andrew Cooper wrote:
> > > > > On 22/04/2025 6:14 pm, Andrew Cooper wrote:
> > > > > > I've stripped out the sha2 patch and fixed up to use the existing sha2,
> > > > > > then kicked off some CI testing:
> > > > > >
> > > > > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
> > > > > > https://cirrus-ci.com/build/5452335868018688
> > > > > >
> > > > > > When the dust has settled, I'll talk you through the failures.
> > > > > And here we go.  Interestingly, the FreeBSD testing was entirely
> > > > > happy,
> > > > > and that is the rare way around.
> > > > >
> > > > > For Gitlab, there are several areas.
> > > > >
> > > > > First, for MISRA.  In the job logs, you want the "Browse current
> > > > > reports:" link which will give you full details, but it's all pretty
> > > > > simple stuff.
> > > > Thanks, but that link gives me a list of 5096 failures all over the code
> > > > base.  Is there any way to see a diff against master?
> > > >
> > > Hi,
> > >
> > > yes, you can define selections of violations introduced on previously clean
> > > guidelines by clicking on the "ECLAIR" button on the upper right. See [1]
> > > which is the result of defining the "clean_added" selection shown in the
> > > attached screenshot. If you have other questions please let me know.
> > Hi,
> >
> > not sure why, but using "added" left 4861 violations.  Picking `_NO_TAG`
> > instead seemingly left only new violations.  Maybe that's something
> > specific to this particular run.  Either way, I can go through the list
> > now and know how to adjust it.  Thank you for the instructions.
> >
> I'm not sure I fully understand this. This is what I see on x86: the ones
> still shown are those rules where the CI is blocking and new issues have
> been introduced by that pipeline run (of course a different pipeline may
> yield different results). Only new violations are blocking, so that is why I
> filtered out the rest in this case.

My bad, I still had "Hide" instead of "Show" in the selection.  Other
comboboxes are also hard to see but I wasn't even looking for one in
the title.  Thanks again.

> > > Thanks,
> > >   Nicola
> > >
> > > [1] https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/ARM64/9791028027/PROJECT.ecd;/by_service.html#service&kind{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]}]}}}

On 2025-04-22 19:14, Andrew Cooper wrote:
> On 22/04/2025 4:06 pm, Sergii Dmytruk wrote:
>> The aim of the [TrenchBoot] project is to provide an implementation of
>> DRTM that is generic enough to cover various use cases:
>>  - Intel TXT and AMD SKINIT on x86 CPUs
>>  - legacy and UEFI boot
>>  - TPM1.2 and TPM2.0
>>  - (in the future) DRTM on Arm CPUs
>> 
>> DRTM is a version of a measured launch that starts on request rather
>> than at the start of a boot cycle.  One of its advantages is in not
>> including the firmware in the chain of trust.
>> 
>> Xen already supports DRTM via [tboot] which targets Intel TXT only.
>> tboot employs encapsulates some of the DRTM details within itself 
>> while
>> with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
>> for a TrenchBoot-enabled bootloader (think GRUB).  The one exception 
>> is
>> that UEFI case requires calling back into bootloader to initiate DRTM,
>> which is necessary to give Xen a chance of querying all the 
>> information
>> it needs from the firmware before performing DRTM start.
>> 
>> From reading the above tboot might seem like a more abstracted, but 
>> the
>> reality is that the payload needs to have DRTM-specific knowledge 
>> either
>> way.  TrenchBoot in principle allows coming up with independent
>> implementations of bootloaders and payloads that are compatible with
>> each other.
>> 
>> The "x86/boot: choose AP stack based on APIC ID" patch is shared with
>> [Parallelize AP bring-up] series which is required here because Intel
>> TXT always releases all APs simultaneously.  The rest of the patches 
>> are
>> unique.
> 
> I've stripped out the sha2 patch and fixed up to use the existing sha2,
> then kicked off some CI testing:
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393
> https://cirrus-ci.com/build/5452335868018688
> 
> When the dust has settled, I'll talk you through the failures.
> 

Accidental use of C18 here

https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/tb-v1.1/X86_64/9791028023/PROJECT.ecd;/by_service/MC3A2.D1.1.html

> ~Andrew

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

On 22.04.2025 17:06, Sergii Dmytruk wrote:
> Kacper Stojek (2):
>   x86/boot: add MLE header and new entry point
>   xen/arch/x86: reserve TXT memory
> 
> Krystian Hebel (7):
>   x86/include/asm/intel_txt.h: constants and accessors for TXT registers
>     and heap
>   x86/boot/slaunch_early: early TXT checks and boot data retrieval
>   x86/intel_txt.c: restore boot MTRRs
>   lib/sha1.c: add file
>   x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)
>   x86/boot: choose AP stack based on APIC ID
>   x86/smpboot.c: TXT AP bringup
> 
> Michał Żygowski (2):
>   x86/hvm: Check for VMX in SMX when slaunch active
>   x86/cpu: report SMX, TXT and SKINIT capabilities
> 
> Sergii Dmytruk (10):
>   include/xen/slr_table.h: Secure Launch Resource Table definitions
>   x86/boot/slaunch_early: implement early initialization
>   x86/mtrr: expose functions for pausing caching
>   lib/sha256.c: add file
>   x86/tpm.c: support extending PCRs of TPM2.0
>   x86/tpm.c: implement event log for TPM2.0
>   arch/x86: process DRTM policy
>   x86/boot: find MBI and SLRT on AMD
>   arch/x86: support slaunch with AMD SKINIT
>   x86/slaunch: support EFI boot
> 
>  .gitignore                                  |    1 +
>  docs/hypervisor-guide/x86/how-xen-boots.rst |    7 +
>  xen/arch/x86/Makefile                       |   12 +-
>  xen/arch/x86/boot/Makefile                  |   10 +-
>  xen/arch/x86/boot/head.S                    |  250 +++++
>  xen/arch/x86/boot/slaunch_early.c           |  105 ++
>  xen/arch/x86/boot/trampoline.S              |   40 +-
>  xen/arch/x86/boot/x86_64.S                  |   42 +-
>  xen/arch/x86/cpu/amd.c                      |   14 +
>  xen/arch/x86/cpu/cpu.h                      |    1 +
>  xen/arch/x86/cpu/hygon.c                    |    1 +
>  xen/arch/x86/cpu/intel.c                    |   44 +
>  xen/arch/x86/cpu/mtrr/generic.c             |   51 +-
>  xen/arch/x86/e820.c                         |    5 +
>  xen/arch/x86/efi/efi-boot.h                 |   90 +-
>  xen/arch/x86/efi/fixmlehdr.c                |  122 +++
>  xen/arch/x86/hvm/vmx/vmcs.c                 |    3 +-
>  xen/arch/x86/include/asm/apicdef.h          |    4 +
>  xen/arch/x86/include/asm/intel_txt.h        |  452 ++++++++
>  xen/arch/x86/include/asm/mm.h               |    3 +
>  xen/arch/x86/include/asm/msr-index.h        |    3 +
>  xen/arch/x86/include/asm/mtrr.h             |    8 +
>  xen/arch/x86/include/asm/processor.h        |    1 +
>  xen/arch/x86/include/asm/slaunch.h          |   91 ++
>  xen/arch/x86/include/asm/tpm.h              |   19 +
>  xen/arch/x86/intel_txt.c                    |  177 ++++
>  xen/arch/x86/setup.c                        |   32 +-
>  xen/arch/x86/slaunch.c                      |  464 ++++++++
>  xen/arch/x86/smpboot.c                      |   57 +
>  xen/arch/x86/tboot.c                        |   20 +-
>  xen/arch/x86/tpm.c                          | 1057 +++++++++++++++++++
>  xen/common/efi/boot.c                       |    4 +
>  xen/common/efi/runtime.c                    |    1 +
>  xen/include/xen/efi.h                       |    1 +
>  xen/include/xen/sha1.h                      |   12 +
>  xen/include/xen/sha256.h                    |   12 +
>  xen/include/xen/slr_table.h                 |  274 +++++
>  xen/lib/Makefile                            |    2 +
>  xen/lib/sha1.c                              |  240 +++++
>  xen/lib/sha256.c                            |  238 +++++
>  40 files changed, 3914 insertions(+), 56 deletions(-)
>  create mode 100644 xen/arch/x86/boot/slaunch_early.c
>  create mode 100644 xen/arch/x86/efi/fixmlehdr.c
>  create mode 100644 xen/arch/x86/include/asm/intel_txt.h
>  create mode 100644 xen/arch/x86/include/asm/slaunch.h
>  create mode 100644 xen/arch/x86/include/asm/tpm.h
>  create mode 100644 xen/arch/x86/intel_txt.c
>  create mode 100644 xen/arch/x86/slaunch.c
>  create mode 100644 xen/arch/x86/tpm.c
>  create mode 100644 xen/include/xen/sha1.h
>  create mode 100644 xen/include/xen/sha256.h
>  create mode 100644 xen/include/xen/slr_table.h

Just one basic nit right here: In the names of new files you add, please
prefer dashes over underscores.

Jan

On Tue, Apr 22, 2025 at 05:23:30PM +0200, Jan Beulich wrote:
> Just one basic nit right here: In the names of new files you add, please
> prefer dashes over underscores.

I wasn't aware of this preference, will be updated in the next version.

> Jan

On 4/22/25 11:06, Sergii Dmytruk wrote:
> The aim of the [TrenchBoot] project is to provide an implementation of
> DRTM that is generic enough to cover various use cases:
>   - Intel TXT and AMD SKINIT on x86 CPUs
>   - legacy and UEFI boot
>   - TPM1.2 and TPM2.0
>   - (in the future) DRTM on Arm CPUs
> 
> DRTM is a version of a measured launch that starts on request rather
> than at the start of a boot cycle.  One of its advantages is in not
> including the firmware in the chain of trust.
> 
> Xen already supports DRTM via [tboot] which targets Intel TXT only.
> tboot employs encapsulates some of the DRTM details within itself while
> with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
> for a TrenchBoot-enabled bootloader (think GRUB).  The one exception is
> that UEFI case requires calling back into bootloader to initiate DRTM,
> which is necessary to give Xen a chance of querying all the information
> it needs from the firmware before performing DRTM start.
> 
>  From reading the above tboot might seem like a more abstracted, but the
> reality is that the payload needs to have DRTM-specific knowledge either
> way.  TrenchBoot in principle allows coming up with independent
> implementations of bootloaders and payloads that are compatible with
> each other.
> 
> The "x86/boot: choose AP stack based on APIC ID" patch is shared with
> [Parallelize AP bring-up] series which is required here because Intel
> TXT always releases all APs simultaneously.  The rest of the patches are
> unique.
> 

Sergii,

Thanks so much to you and the team over at 3mdeb for taking the lead on 
getting Secure Launch written for Xen.

One quick comment, Secure Launch will eventually support other 
architectures, and we really should not let the maintenance fall on the 
x86 maintainers, or eventually to "the rest". I would like to suggest 
adding an entry into the MAINTAINERS file for "TrenchBoot Secure Launch" 
and list any new files that are being introduced for Secure Launch. When 
adding the section to MAINTAINERS, I would kindly like to request that 
myself be included as a maintainer and Ross Phillipson as a reviewer.

V/r,
Daniel P. Smith