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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]

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 #2: Screenshot from 2025-04-23 22-09-16.png --]
[-- Type: image/png, Size: 19088 bytes --]