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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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

Attachment: Screenshot from 2025-04-23 22-09-16.png
Description: PNG image