Update ACMS for DRTM measured launch #1478

crogers1 · 2023-08-17T17:42:20Z

This PR introduces Intel's latest ACMs released here: https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html version 630744 into OpenXT.

The first commit updates the URLs to these ACMs on the mirror, and it also gives them new names which are abbreviations of the cpu codename they apply to. It also updates the hashes and starts tracking a license file from a recent ACM since the 630744 version no longer distributes the ACMs bundled with their error codes and individual license files.

The second commit updates their usage in isolinux and pxelinux cfgs. The installer.git code doesn't need to be updated as the ACMs are built into the dom0 image under /boot, and copied to the ESP for EFI boot in the function copy_to_esp() in part2/stages/functions/install-main

jandryuk · 2023-08-17T19:02:45Z

Instead of adding license.txt, should Legal Disclaimer.pdf be used for the "license"? It's not a license per-say, but it is included in the source zip file.

recipes-openxt/xenclient-dom0-tweaks/xenclient-dom0-tweaks/openxt.cfg needs to be updated for the new modules? Hmm. if you OTA, the old modules are probably left on the ESP. I don't think we have any support for clearing out old files from there.

This is dropping some support for older systems? That is fine from my end, but we should be clear about it.

However, I have an issue with at least one modern system. When I use CFL_SINIT_20211019_PRODUCTION_REL_NT_O1_1.10.0.bin with it, it reboots, seemingly in tboot. i.e. it enters a boot loop. Normally it uses the BIOS-provided SINIT. With Converged Bootguard and TXT (CBnT), TXT-enabled systems are shipping with an embedded SINIT module. I'm wondering if these external SINIT modules are really needed for newer systems. As I've seen, they can be problematic.

crogers1 · 2023-08-17T19:20:14Z

Instead of adding license.txt, should Legal Disclaimer.pdf be used for the "license"? It's not a license per-say, but it is included in the source zip file.

Thought about that, but since it wasn't actually a license, didn't think it qualified.

recipes-openxt/xenclient-dom0-tweaks/xenclient-dom0-tweaks/openxt.cfg needs to be updated for the new modules? Hmm. if you OTA, the old modules are probably left on the ESP. I don't think we have any support for clearing out old files from there.

from part2/stages/Functions/install-main:

 623     # make sure the ESP is starting from a clean slate                                                                                                                                                          
 624     # if we're upgrading. prevents outdated files from                                                                                                                                                          
 625     # older versions from populating the partition.                                                                                                                                                             
 626     if [ "${INSTALL_MODE}" = "upgrade" ]; then                                                                                                                                                                  
 627         do_cmd rm -rf ${ESP_MOUNT}/EFI/BOOT >&2                                                                                                                                                                 
 628         do_cmd rm -rf ${ESP_MOUNT}/EFI/OpenXT >&2                                                                                                                                                               
 629     fi

That should cover the old .acms

This is dropping some support for older systems? That is fine from my end, but we should be clear about it.

I can't be 100% sure about that. Based on the support matrix in the .zip it seems like they combined some platforms into a single SINIT. It however doesn't say anything about Xeon processors, for which we had separate SINIT's defined in the recipe. In practice they might just be BIOS provided but we'd need to test them out for sure.

However, I have an issue with at least one modern system. When I use CFL_SINIT_20211019_PRODUCTION_REL_NT_O1_1.10.0.bin with it, it reboots, seemingly in tboot. i.e. it enters a boot loop. Normally it uses the BIOS-provided SINIT. With Converged Bootguard and TXT (CBnT), TXT-enabled systems are shipping with an embedded SINIT module. I'm wondering if these external SINIT modules are really needed for newer systems. As I've seen, they can be problematic.

That's an issue then, if there's a txt errorcode you can pull that might tell us what's wrong. Otherwise I was under the impression it would prefer BIOS provided SINITs over the ones we provide. Maybe it has something to do with whichever version is newer. Are there any firmware updates for your system that's using the CFL SINIT?

jandryuk · 2023-08-17T19:35:36Z

Instead of adding license.txt, should Legal Disclaimer.pdf be used for the "license"? It's not a license per-say, but it is included in the source zip file.

Thought about that, but since it wasn't actually a license, didn't think it qualified.

Ok, leaving license seems fine.

recipes-openxt/xenclient-dom0-tweaks/xenclient-dom0-tweaks/openxt.cfg needs to be updated for the new modules? Hmm. if you OTA, the old modules are probably left on the ESP. I don't think we have any support for clearing out old files from there.

from part2/stages/Functions/install-main:

 623     # make sure the ESP is starting from a clean slate                                                                                                                                                          
 624     # if we're upgrading. prevents outdated files from                                                                                                                                                          
 625     # older versions from populating the partition.                                                                                                                                                             
 626     if [ "${INSTALL_MODE}" = "upgrade" ]; then                                                                                                                                                                  
 627         do_cmd rm -rf ${ESP_MOUNT}/EFI/BOOT >&2                                                                                                                                                                 
 628         do_cmd rm -rf ${ESP_MOUNT}/EFI/OpenXT >&2                                                                                                                                                               
 629     fi

That should cover the old .acms

Thanks. Nice that we have that.

This is dropping some support for older systems? That is fine from my end, but we should be clear about it.

I can't be 100% sure about that. Based on the support matrix in the .zip it seems like they combined some platforms into a single SINIT. It however doesn't say anything about Xeon processors, for which we had separate SINIT's defined in the recipe. In practice they might just be BIOS provided but we'd need to test them out for sure.

Well, gm45, q35, q45, i5_i7_DUAL and i7_QUAD are older Intel Core processors predating Sandy Bridge. Not sure what Xeon covers, but they are older Xeons as well.

However, I have an issue with at least one modern system. When I use CFL_SINIT_20211019_PRODUCTION_REL_NT_O1_1.10.0.bin with it, it reboots, seemingly in tboot. i.e. it enters a boot loop. Normally it uses the BIOS-provided SINIT. With Converged Bootguard and TXT (CBnT), TXT-enabled systems are shipping with an embedded SINIT module. I'm wondering if these external SINIT modules are really needed for newer systems. As I've seen, they can be problematic.

That's an issue then, if there's a txt errorcode you can pull that might tell us what's wrong. Otherwise I was under the impression it would prefer BIOS provided SINITs over the ones we provide. Maybe it has something to do with whichever version is newer. Are there any firmware updates for your system that's using the CFL SINIT?

tboot will overwrite the BIOS SINIT if a module is newer. The CFL SINIT is newer in this case. Let me look for a firmware update.

Hmmm, maybe I can get the TXT errorcode, too.

crogers1 · 2023-08-18T19:27:53Z

Updated with latest Intel ACMs released today.

crogers1 · 2023-08-21T16:56:31Z

Updated to include missing changes to the openxt.cfg file referencing the names of the new SINITs.

crogers1 · 2023-09-06T17:39:04Z

Added commit that uses acminfo to check if we're processing an ACM rather than looking at the fingerprint, since the fingerprint no longer exists for newer ACMs.

jandryuk · 2023-09-06T19:24:24Z

recipes-security/acms/acms.bb

+    ${OPENXT_MIRROR}/CFL_SINIT_20221220_PRODUCTION_REL_NT_O1_1.10.1_signed.bin;downloadfilename=cfl_wkl_cml.bin;name=cfl_wkl_cml \
+    ${OPENXT_MIRROR}/CML_S_SINIT_1_13_33_REL_NT_O1.PW_signed.bin;downloadfilename=cml_s.bin;name=cml_s \
+    ${OPENXT_MIRROR}/CMLSTGP_SINIT_v1_14_39_20211214_REL_NT_O1.PW_signed.bin;downloadfilename=cml_s_tgp.bin;name=cml_s_tgp \
+    ${OPENXT_MIRROR}/RKLS_SINIT_v1_14_46_20220818_REL_NT_O1.PW_signed.bin;downloadfilename=rkls.bin;name=rkls \


RKLS failed to download - it's 20220819.

630744_003 also has:
CML_RKL_S_SINIT_v1.13.33_REL_NT_O1.PW_signed.bin
CMLSTGP_SINIT_v1_14_46_20220819_REL_NT_O1.PW_signed.bin
which are not on the mirror or included here in SRC_URI.

The three CML_* files are identical:

5670905f72d7415fad97eb02bd994ae75c15ceec 630744_002/CML_S_SINIT_1_13_33_REL_NT_O1.PW_signed.bin 5670905f72d7415fad97eb02bd994ae75c15ceec 630744_003/CML_RKL_S_SINIT_v1.13.33_REL_NT_O1.PW_signed.bin 5670905f72d7415fad97eb02bd994ae75c15ceec 630744_003/CML_S_SINIT_1_13_33_REL_NT_O1.PW_signed.bin

My mistake on the 20220819. Pushing a fix for that. The change to v1_14_46 for CMLSTGP slipped past me, pushing a fix for that as well. It'll also go up on the mirror.

Not sure why they have 2 versions of the same sinit, but the CML_RKL_S isn't on the 630744_ACM_PlatformList_003.pdf, only the CML_S_SINIT_1_13_33 is. So I'm going to advocate for only listing that one in the SRC_URI and chalk up the inclusion of the other one to user error on Intel's part.

jandryuk · 2023-09-06T20:13:54Z

Something else is wrong with an OTA.

updatemgr: cp -f /mnt/upgrade/dom0/boot/xen.efi /mnt/upgrade/dom0/boot/shimx64.efi /mnt/upgrade/dom0/boot/tboot /mnt/upgrade/dom0/boot/bzImage /mnt/upgrade/dom0/boot/initrd /mnt/upgrade/dom0/boot/7th_gen_i5_i7-SINIT_74.bin /mnt/upgrade/dom0/boot/8th_gen_i5_i7-SINIT_76.bin /mnt/upgrade/dom0/boot/Xeon-5600-3500-SINIT-v1.1.bin /mnt/upgrade/dom0/boot/Xeon-E7-8800-4800-2800-SINIT-v1.1.bin /mnt/upgrade/dom0/boot/adl.bin /mnt/upgrade/dom0/boot/bdw_hsw.bin /mnt/upgrade/dom0/boot/cfl_wkl_cml.bin /mnt/upgrade/dom0/boot/cml_s.bin /mnt/upgrade/dom0/boot/cml_s_tgp.bin /mnt/upgrade/dom0/boot/microcode_20230808.bin /mnt/upgrade/dom0/boot/microcode_intel.bin /mnt/upgrade/dom0/boot/rkls.bin /mnt/upgrade/dom0/boot/skl_kbl_aml.bin /mnt/upgrade/dom0/boot/snb_ivb.bin /mnt/upgrade/dom0/boot/tgl.bin /mnt/upgrade/dom0/boot/*.BIN /mnt/upgrade/dom0/etc/xen/xenrefpolicy/policy/policy.24 /mnt/upgrade/dom0/usr/share/xenclient/bootloader/openxt.cfg /mnt/upgrade/dom0/usr/share/xenclient/bootloader/BOOT.CSV /mnt/upgrade/esp/EFI/OpenXT
updatemgr: cp: cannot stat '/mnt/upgrade/dom0/boot/*.BIN': No such file or directory
updatemgr: Failed to copy files to ESP
updatemgr: umount /mnt/upgrade/esp
updatemgr: ERROR: Failure committing dom0 with file dom0-rootfs.ext3.gz.

Ugh, the installer: https://github.com/OpenXT/installer/blob/e20749637d9a8016af6721d4bc3968cd5978c60a/part2/stages/Functions/install-main#L639

crogers1 · 2023-09-07T19:03:30Z

Ugh, the installer: https://github.com/OpenXT/installer/blob/e20749637d9a8016af6721d4bc3968cd5978c60a/part2/stages/Functions/install-main#L639

Hmm, guess we'll have to drop that line.

Signed-off-by: Chris Rogers <[email protected]>

with the new names of the SINITs. We use the renamed versions of the bins since they'll exist on the ESP under those names. Signed-off-by: Chris Rogers <[email protected]>

New SINIT modules no longer have the well known fingerprint that starts with c22c443. Instead, we can use the acminfo tool and check the return code to know whether or not the module being processed is a SINIT. Signed-off-by: Chris Rogers <[email protected]>

crogers1 · 2023-09-08T12:54:09Z

Updated acm hashes for the CMLSTGP

crogers1 force-pushed the update-acms branch from 579c2d6 to f1349d8 Compare August 18, 2023 19:27

crogers1 force-pushed the update-acms branch from f1349d8 to c666b85 Compare August 21, 2023 16:51

jandryuk reviewed Sep 6, 2023

View reviewed changes

crogers1 force-pushed the update-acms branch from bb577ca to 1674c67 Compare September 6, 2023 20:16

Chris Rogers added 3 commits September 8, 2023 08:53

[acms] Update SINIT modules to latest

ade8434

Signed-off-by: Chris Rogers <[email protected]>

[syslinux] Update isolinux, pxelinux, openxt.cfg

8211fab

with the new names of the SINITs. We use the renamed versions of the bins since they'll exist on the ESP under those names. Signed-off-by: Chris Rogers <[email protected]>

crogers1 force-pushed the update-acms branch from 1674c67 to e6ddf4b Compare September 8, 2023 12:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update ACMS for DRTM measured launch #1478

Update ACMS for DRTM measured launch #1478

crogers1 commented Aug 17, 2023

jandryuk commented Aug 17, 2023

crogers1 commented Aug 17, 2023

jandryuk commented Aug 17, 2023

crogers1 commented Aug 18, 2023

crogers1 commented Aug 21, 2023

crogers1 commented Sep 6, 2023

jandryuk Sep 6, 2023

jandryuk Sep 6, 2023

crogers1 Sep 6, 2023

jandryuk commented Sep 6, 2023

crogers1 commented Sep 7, 2023

crogers1 commented Sep 8, 2023

Update ACMS for DRTM measured launch #1478

Are you sure you want to change the base?

Update ACMS for DRTM measured launch #1478

Conversation

crogers1 commented Aug 17, 2023

jandryuk commented Aug 17, 2023

crogers1 commented Aug 17, 2023

jandryuk commented Aug 17, 2023

crogers1 commented Aug 18, 2023

crogers1 commented Aug 21, 2023

crogers1 commented Sep 6, 2023

jandryuk Sep 6, 2023

Choose a reason for hiding this comment

jandryuk Sep 6, 2023

Choose a reason for hiding this comment

crogers1 Sep 6, 2023

Choose a reason for hiding this comment

jandryuk commented Sep 6, 2023

crogers1 commented Sep 7, 2023

crogers1 commented Sep 8, 2023