Missing important FSP Hob structs header files for EagleStreamFspBinPkg

[johnnylinwiwynn]

EagleStreamFspBinPkg/Include only provides UPD header files for FSP input interface for the bootloader, but doesn't provide any important Hob struct header files for the FSP output interface. Running
"find -iname hob.h" I can see there are quite many Hob header files for Client FSP, such as
/AlderLakeFspBinPkg/Client/AlderLakeS/Include/FirmwareVersionInfoHob.h
./AlderLakeFspBinPkg/Client/AlderLakeS/Include/MemInfoHob.h
./AlderLakeFspBinPkg/Client/AlderLakeS/Include/FspInfoHob.h
./AlderLakeFspBinPkg/Client/AlderLakeS/Include/SmbiosCacheInfoHob.h

Can Intel please also release the needed Hob header files for EagleStreamFspBinPkg? For example, these are the Hob header files for WW43 2022 EGS FSP:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/vendorcode/intel/fsp/fsp2_0/sapphirerapids_sp/

Thanks.

[65a]

Trying the current FSP with coreboot HEAD is completely broken on the board I am porting (Tyan S5652) and I think this is part of the reason. Please release updated headers, currently I'm seeing a number of strange issues that may be related to misinterpreted HOB blocks, including the inability to run option ROMs or boot a Linux payload, despite making it to EOP.

[johnnylinwiwynn]

Some discussion on the change you can reference from
https://review.coreboot.org/c/coreboot/+/80360
At least with UEFI payload I can boot up OS.

https://github.com/johnnylinwiwynn/Intel_AC_OSF
FYI

[65a]

@johnnylinwiwynn two questions (I actually had read some of that gerrit change's comments trying to get things working):

1. What is a TOCTOU mitigated FSP? I don't think this board has bootguard enforcement (I don't think I would get this far), but ME has been placed in the MFG-mode.
2. How did you bring up graphics (or did you let OS bring up graphics)?
   I'll give it a try, thanks!

[65a]

Looking at my romstage setup and changing some things to match Archer city seems to have fixed things, I believe this was either using XAPIC by default, or configuring CXL, I was able to boot a bzImage. Thanks for that!

[LeanSheng]

@65a great to hear that it got resolved on your side!
I am also working on EGS and next generation Intel server platforms with coreboot.
Actually there is a slack group for Open Source Firmware, feel free to join:
https://join.slack.com/t/osfw/shared_invite/zt-2eyud9b4k-EulKQ3MwjTIAn0VAi_J_uA

You can then go to the coreboot channel and start discussions. There are many experienced and helpful folks there from all over the world :)

If not you could also drop me an email if you need something related:
sheng.tan@9elements.com

[johnnylinwiwynn]

@johnnylinwiwynn two questions (I actually had read some of that gerrit change's comments trying to get things working):

1. What is a TOCTOU mitigated FSP? I don't think this board has bootguard enforcement (I don't think I would get this far), but ME has been placed in the MFG-mode.

2. How did you bring up graphics (or did you let OS bring up graphics)?

I'll give it a try, thanks!

For some unknown reasons FSP needs to revert a commit related to a TOCTOU security pcd configuration otherwise Linux payload will reset and cannot boot, but UEFI payload is not affected by this. The FSP pcd is Intel NDA. I can share more if you have Intel FSP source code NDA.

I haven't tried to enable graphics since we use headless server only, but the community and firmware vender like 9elements, SysPro Consulting could help.

[65a]

I do not have an NDA, but thanks to your help I was able to boot a linux (also SeaBIOS but no keyboard, and u-boot with some issues) payload. I had success with XAPIC and late X2APIC (Called "XAPIC then X2APIC") mode, originally I was getting reboots in the default mode, but it may have also been some changes to try to configure CXL. I'll close my other issue , but it would still be nice if the FSP headers and Coreboot matched.

[65a]

As far as I can tell, Linux payload, and perhaps others, will only boot if coreboot is set to wipe memory. This results in one logged null pointer exception, but no other issues.

[65a]

TME is not working, as the policy part of the MSR is not programmed correctly. This may be a HOB/UPD issue, as copying Alderlake's coreboot init for TME doesn't produce any change.

[LeanSheng]

This is bad, let me try to reach out to my intel contact to fix this.

[nate-desimone]

For some unknown reasons FSP needs to revert a commit related to a TOCTOU security pcd configuration otherwise Linux payload will reset and cannot boot, but UEFI payload is not affected by this. The FSP pcd is Intel NDA. I can share more if you have Intel FSP source code NDA.

Intel has root caused the issue with the TOCTOU mitigation & coreboot. A fix is currently under development and will be included in an upcoming FSP release.

[65a]

Great news! For what it's worth, I think the headers coreboot uses today do not match, especially the memory hob. For instance, the binary dump of the hob data shows things like the module serial numbers, but coreboot doesn't see this, and most DIMMs have the present boolean set to false. Another example is that SNC is apparently enabled, even though it shouldn't be (wasn't requested) and TME is configured improperly. This seems like the structs on the coreboot side do not match the actual hob, so there's a memory safety issue. Publishing the actual HOB structs as returned by the FSP would help in these cases, but glad you are also looking at the reset/TOCTOU issue.

[felixsinger]

For some unknown reasons FSP needs to revert a commit related to a TOCTOU security pcd configuration otherwise Linux payload will reset and cannot boot, but UEFI payload is not affected by this. The FSP pcd is Intel NDA. I can share more if you have Intel FSP source code NDA.

Intel has root caused the issue with the TOCTOU mitigation & coreboot. A fix is currently under development and will be included in an upcoming FSP release.

Amazing. Thank you!