[RESPONDED] Firmware Security: CSME Version

When I run fwupdmgr security on Fedora Workstation 36, it provides an audit of the firmware. I get the following output:

Host Security ID: HSI:0 (v1.8.5)

✔ CSME manufacturing mode:       Locked
✔ CSME override:                 Locked
✔ Platform Debugging:            Disabled
✔ SPI BIOS region:               Locked
✔ SPI lock:                      Enabled
✔ SPI write:                     Disabled
✔ Supported CPU:                 Valid
✔ TPM empty PCRs:                Valid
✔ TPM v2.0:                      Found
✔ UEFI platform key:             Valid
✔ UEFI secure boot:              Enabled
✘ CSME v0:          Invalid

✔ IOMMU:                         Enabled
✔ Intel BootGuard:               Enabled
✔ Intel BootGuard ACM protected: Valid
✔ Intel BootGuard OTP fuse:      Valid
✔ Intel BootGuard verified boot: Valid
✔ Platform Debugging:            Locked
✔ TPM PCR0 reconstruction:       Valid

✔ Intel BootGuard error policy:  Valid
✔ Intel CET Enabled:             Enabled
✔ Pre-boot DMA protection:       Enabled
✔ Suspend-to-idle:               Enabled
✔ Suspend-to-ram:                Disabled

✔ Encrypted RAM:                 Enabled
✔ Intel SMAP:                    Enabled

Runtime Suffix -!
✔ Intel CET Active:              Supported
✔ Linux kernel:                  Untainted
✔ Linux kernel lockdown:         Enabled
✔ Linux swap:                    Encrypted
✔ fwupd plugins:                 Untainted

This system has a low HSI security level.
 » https://fwupd.github.io/hsi.html#low-security-level

Host Security Events

The only thing that it flags as an issue is CSME version. Looking at the documentation for this tool: FwupdPlugin – 1.0: Host Security ID Specification It seems like this is something that has to be updated in the BIOS.

Is this something I should be worried about, or can it be disregarded?

Something to note: this CLI tool will be getting a GUI in GNOME’s settings in a future version:

So, it would be great to see it get to HSI-4.

What did you do to get Encrypted RAM? That’s showing as disabled for me, so not sure what I missed (swap and my boot disk are both encrypted as far as I can see)

IIRC there’s an option for it in the BIOS if you have the 11th gen i7-1185G7. I could be wrong, though, so it’s always worth checking. It should be near other settings related to the CPU.

Quick update:

There’s discussion here about the CSME version:

An issue was posted to the CLI tool’s GitHub: CSME Invalid · Issue #4999 · fwupd/fwupd · GitHub

It seems like we either have to wait for Intel and or Framework to release an update. I’m not really sure which one, since I’m struggling to find if patches are CPU-specific and if one is available for the 11th gen i7-1185G7.

Thanks, I’ll give a look but may be out of luck as a cheapskate who only has a i5-1135G7.

1 Like

IIRC encrypted memory requires Intel vPro.

1 Like

Quick update:

Framework Support got back to me about this!

Thank you for your patience, I’ve escalated this report to our Lead Engineer who has confirmed that this will not be updated in the forthcoming 3.17 BIOS update, but is now planned to be updated/fixed in BIOS 3.18 hopefully due later this year.

This is great to hear. I really appreciate that they escalated the issue and that they were able to respond so quickly! Thanks Framework Support, I’m looking forward to BIOS 3.18!


I asked the support for an ETA on a new gen 11 firmware including the security fixes. Unfortunately they could not provide a time frame for the update.

the latest firmware update (3.17) for the gen 11 did not include Intel Management Engine related security fixes. What’s the ETA for the next firmware release that will include the security fixes?

Thanks for reaching out to Framework Support. Unfortunately, we currently don’t have an estimated timeline for the next firmware release but rest assured that our team is working on it and will surely announce the details when it happens. If you have other concerns or inquiries, please don’t hesitate to reach out. Thank you for your patience.

1 Like

Hi @43c

Thanks for updating this thread and thank you for reaching out to our support team, firmware updates shouldn’t be that long to be released, will update this space once it’s out.


I am having trouble justifying an upgrade if this significant delay is indicative of how Framework is going to address known vulnerabilities in their firmware. This thread discusses a vulnerability that could/should have been addressed in an update that was released more than 6 months ago but was not and no subsequent update has been forthcoming.


@Loell_Framework is there any update on this?


I get that priority is most likely 100% on the new AMD firmware and that Framework is operating with limited resources, though this is kind of a bummer. It’s already end of June and there is no update on this topic. Like @JoshB mentioned, if this is an indicator on how framework manages firmware vulnerabilities for older devices, It’s hard to recommend them for business use even though I’d really like to. :frowning:

@43c I’m grumpy that firmware related news of any kind is relegated to the backseat by the firmware team…now I’m trying to figure out just what exactly I’m going to do about it.

@GhostLegion It does suck we basically have no official timeline on firmware release for existing products with the fixes.
I saw @Kieran_Levin comment on the 12th Gen beta firmware post, They are testing out a new version and will try to get it out soon after validation.
let’s see how that goes.

Stumbled upon this thread, dumping some info :stuck_out_tongue:

Encrypted RAM requires the following BIOS flags
Intel Trusted Execution Technology
Total Memory Encryption - this flag achieves Pass for Encrypted RAM @ HSI4

PS: For anyone that randomly found themselves here on an “unsupported” OS for Framework, you need CONFIG_SECURITY_LOCKDOWN_LSM kernel flag compiled to report the security status. Probs a good idea to set it to “Integrity” as well.

So we’re now in February '24, in May '22, almost two years ago(!), intel released security updates for the CSME rated High and listing physical-unauthenticated or adjacent_network-authenticated as attack vectors:


I’ve heard many explanations from releasing a new laptop (sorry, two years, I don’t care anymore!) and a third party vendor being responsible. For the latter case you have SLAs (or, maybe you don’t).

If I’d have more time I’d seriously look into extracting the Windows update executable (e.g., using GitHub - jbit/uninsyde: Extract chunks from Insyde H2O Iflash files) and trying to flash the UEFI capsule manually. Because it seems that Framework won’t budge.

Mind me, if the statement would be “sorry, we don’t officially support Linux and we don’t have the SLAs to get our third-party vendor to provide updates, you’re on your own there” – I’d be much more OK with that. It’s the dishonesty and waiting for years that’s driving me crazy.

Framework, own up.


Well if this is on a 12th gen Intel you had the 3.06 Beta that actually fixed that issue, and then you had the 3.08 Beta which has been out just over a month 12th Gen Intel Core BIOS 3.08 Beta Release . In the original 3.06 Beta thread Framework did apologize and explained that they had hired additional dedicated personnel at Insyde to work through the backlog and push out regular UEFI updates. We are beginning to see the results of those efforts.

Also cross-posting here: I’ve created an updater to update on Linux through the UEFI shell. There are some caveats and you may not trust all files provided there-in (read the README):

It’s 11 gen. And there’s no “work” to push through, no firmware to develop. It’s literally just repackaging the CSME FWUpdate.bin in a UEFI capsule. Which Framework falsely claims isn’t possible while other vendors do this regularly.

Just pull apart any CSME update by, say, Lenovo, extract the cap file and you’ll find a UEFI capsule firmware.bin, extract with UEFIExtract and you’ll find a body.bin in there with the ME magic $FPT at 0x10 – just like the FWUpdate.bin file.

I don’t have a problem with overworked staff. But I get annoyed after almost 2 years(!) of delays with “sorrys” that don’t change a thing, mindless excuses and misinfo around LVFS not being able to update the CSME. If in doubt, contact Richard Hughes from LVFS to help you guide through the capsule creation process, he’s a kind soul.