ArrowLakeS FSP: TmeEnable = 1 leaves TME inactive on Core Ultra 9 285K (single-key TME, no TME-MK)

Start with the Arrow Lake-S FSP-M UPD in ArrowLakeFspBinPkg/IoT/ArrowLakeS/Include/FspmUpd.h and its TmeEnable description; the report says the behavior also occurs with the current FSP release. Review the single-key TME requirements cited from the Intel specification and compare them with FSP-M behavior on a CPU without TME-MK or PCONFIG. Done means FSP-M enables and encrypts DRAM with single-key TME, verified by the described remanence test, or the UPD documents why this platform does not support it.

FSP

ArrowLakeFspBinPkg/IoT/ArrowLakeS/Fsp.fd from the ARL-S MR4 release (6062_50), intel/FSP commit bb6233faff, FSP-M $ARLFSPE image revision 0x0DE00D40. coreboot's 3rdparty/fsp carries the same file at its commit 98426bf.

The newest ARL-S release, IPU 2027.1 (6193_51), FSP-M image revision 0x0DE02750, behaves the same way on this board, so this is not fixed in the current release.

Platform

• CPU: Intel Core Ultra 9 285K (family 6, model 198, stepping 2), microcode 0x122
• Chipset: Z890
• Board: ASRock Z890 Pro RS WiFi
• Firmware: coreboot, with FSP 2.x in API mode

I'm porting coreboot to this board. The package README describes these binaries as being for Edge SKUs. I'm using them on a desktop board because no client FSP for Arrow Lake-S is published, and this CPU enumerates TME (below).

What the CPU enumerates

• CPUID.(EAX=7,ECX=0):ECX[13] (TME) = 1
• CPUID.(EAX=7,ECX=0):EDX[18] (PCONFIG) = 0
• CPUID.(EAX=1Bh) all zero
• IA32_TME_CAPABILITY (0x981) = 0x40000004: AES-XTS-256 supported, MK_TME_MAX_KEYID_BITS = 0, MK_TME_MAX_KEYS = 0

The CPU supports single-key TME but not TME-MK.

What happens

My coreboot build passes these FSP-M UPDs:

• TmeEnable = 1
• GenerateNewTmeKey = 1
• TmeExcludeBase and TmeExcludeSize set to the boot cache range

After boot, IA32_TME_ACTIVATE (0x982) reads 0x1 on all 24 CPUs: locked, with TME not enabled. Linux reports x86/tme: not enabled by BIOS.

0x982 reads 0x1 the same way with the stock IPU 2027.1 FSP-M and under the board vendor's firmware (ASRock 3.40).

The only documentation of the UPD, in FspmUpd.h, reads "Configure Total Memory Encryption (TME) to protect DRAM data from physical attacks" and names no further requirement. ArrowLakeFspBinPkg/Docs holds only the Meteor Lake integration guide, which doesn't mention TME.

#133 reports what looks like the same behaviour in the Eagle Stream FSP: FSP-M leaves TME disabled and the MSR is locked by the time FSP-S runs.

Activating from outside FSP-M doesn't work

As an experiment, I patched coreboot to write IA32_TME_ACTIVATE itself right after FspMemoryInit returned: 0x2a, with FSP's reserved memory in the exclusion range (IA32_TME_EXCLUDE_BASE = 0x7a800000, 8 MiB). The MSR then read 0x2b on all CPUs, and the system booted and passed memtester, but DRAM was not encrypted. After filling 8 GiB with a marker and a warm reset through 0xCF9, in which TME was activated again with a new key, 98.47% of the marker was still readable. Encryption on this platform evidently needs more than the MSR write, so firmware outside FSP-M
can't enable it.

What I expected

Intel's Intel Architecture Memory Encryption Technologies Specification (336907-007, revision 1.7) enumerates single-key TME by CPUID.7.ECX[13] alone (section 4.1.1). PCONFIG and the TME-MK key ID fields belong to TME-MK only (section 6.1). With TmeEnable = 1 on a CPU that enumerates TME, I expected FSP-M to activate single-key TME. That means writing IA32_TME_ACTIVATE with enable, key select and policy AES-XTS-256, and leaving MK_TME_KEYID_BITS at 0, whether or not the CPU supports TME-MK.

Single-key TME on a CPU without TME-MK

On a CPU that enumerates TME without TME-MK, a fix that only drops the PCONFIG/TME-MK check also needs to:

• not write MK_TME_CORE_ACTIVATE (0x9ff). 336907-007 section 4.2.3 says it #GPs without TME-MK, and the write in coreboot's CPU code faulted on this CPU until I made it conditional on MK_TME_MAX_KEYID_BITS != 0.
• write 0 to IA32_TME_ACTIVATE bits 35:32, which section 4.2.1 marks reserved without TME-MK.
• write 0 to bits 63:48 (MK_TME_CRYPTO_ALGS). Section 4.2.1 doesn't say whether these are reserved without TME-MK, but EDK2's MdePkg/Include/Register/Intel/ArchitecturalMsr.h does. Table 4-3 also lists "63:8 (reserved) ≠ 0" as #GP, which conflicts with the field definitions. Clarifying this in the spec would help.

How I'll verify a fix

IA32_TME_ACTIVATE reading enabled doesn't show that DRAM is encrypted: the experiment above read 0x2b and DRAM held plaintext. I test with remanence instead. Under Linux I fill 8 GiB with a 64-byte block that starts with a random 32-byte marker, warm-reset through 0xCF9 while the process still holds the memory, and count the marker in physical RAM after the next boot. With TME off on this board, every planted copy is still there after the reset: the scan matches 134,284,810 blocks for 134,217,728 planted, the excess being the same pattern held elsewhere in memory. With TME working and a new key on every boot, almost none should be, and pages the new boot hasn't written should read back as random data rather than zeros or plaintext. I'm happy to run an engineering FSP build through this test on the board.

Request

Please allow FSP-M to activate single-key TME on processors that enumerate TME without TME-MK or PCONFIG. If single-key TME isn't supported on this SKU or chipset, please document that in the TmeEnable description in FspmUpd.h. If the restriction is intended, please give the reason.