Re: [PATCH 00/21] x86: Trenchboot Secure Launch DRTM (Xen)

[Sergii Dmytruk <sergii.dmytruk@3mdeb.com>]

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.