Bootguard, CSME and Intel gen 14th+ (Meteor Lake): S3 deprecated but still functional. Might break with future firmware/microcode updates

[tlaurion]

Current state https://github.com/linuxboot/heads/issues/1801#issuecomment-2532372097:

ME is now disabled and S3 is enabled and functional: #1846 (comment)

As I mentioned elsewhere, it's not supported by Intel so if it breaks with some update to silicon or fw there's a good chance they won't fix it (that's what happened with Tiger Lake), but right now it seems to work well

So S3 works as of now, so no need to enable ME/CSME to have s01x sleep yet. Read still: might break, and next gen will mostly require ME/CSME.

---

OLD ~ME/CSME is now required (cannot be disabled) to obtain S0ix sleep state. S3 is not possible on newer Intel platforms.~ ~So user has to switch ME on to suspend (sleep), or accept that no sleep is possible. Note that hibernation is not possible on QubesOS (Xen). So this means important change on UX.~ ~This is true on Intel gen 13+, ie NovaCustom V56 14th Gen, amongst others.~

This proved to be wrong statement, not so late after QubesOS mini-summit 2024, it was proven that Novacustom V56/Nitropad V56 Intel CPU gen 14th CAN do S3 still. So this problem is reported for next gen, CSME/ME not required for sleep YET:

ME is now disabled and S3 is enabled and functional: #1846 (comment)

As I mentioned elsewhere, it's not supported by Intel so if it breaks with some update to silicon or fw there's a good chance they won't fix it (that's what happened with Tiger Lake), but right now it seems to work well

---

There seems to be a confusion from community around possibility of getting Clevo laptops with unfused bootguard keys and being able to flash custom firmware on those Clevo laptops. Clarify that Clevo laptops have unfused bootguard keys only if ordered through Novacustom bulk orders from Clevo to be rebranded and distributed with Dasharo firmware.

[tlaurion]

Seems like s3 cannot be set nor ME HAP bit enabled to disable ME on v560ty/v540tu per @mkopec comments under https://github.com/linuxboot/heads/pull/1871

• S3 not preferred: https://github.com/linuxboot/heads/pull/1871#discussion_r1870135128
• HAP not enabled: ME not disabled: https://github.com/linuxboot/heads/pull/1871#discussion_r1871202320

[tlaurion]

"Clarify bootguard key fusing and update platforms limitations" will be seperate issue once we have to cross that bridge, no point doing prevention/documenting unknowns for the moment (i'm asked to be less verbose and told i'm off topic: letting go).

There seems to be a confusion from community around possibility of getting Clevo laptops with unfused bootguard keys and being able to flash custom firmware on those Clevo laptops. Clarify that Clevo laptops have unfused bootguard keys only if ordered through Novacustom bulk orders from Clevo to be rebranded and distributed with Dasharo firmware.

ME disablement/s3 was not considered a "Business oriented" discussion up to now even if flagged raised back to QubesOS mini-summit directly with stakeholders. Waiting for updates from the "business" side of things.

Heads never supported ME enabled platform up to now.

[macpijan]

Heads never supported ME enabled platform up to now.

Looking at the Intel's approach to S3, it is rather a matter of when not if this changes, unless this will be a hard blocker of supporting new platforms.

[tlaurion]

Heads never supported ME enabled platform up to now.

Looking at the Intel's approach to S3, it is rather a matter of when not if this changes, unless this will be a hard blocker of supporting new platforms.

@macpijan the point is that we are not there yet. Also, it will then be a documentation problem. If and when s3 is totally deprecated, and ME is needed for s01x (which QubesOS doesn't support yet, btw) then there will need to be a documentation and/or toggle under Heads giving choice to the user between s01x/ME being disabled. That binary choice will need to be taken by the user, and the user configuring his laptop power saving settings to poweroff, or Xen having to support hibernation... as any other OS out there offering the option.

But we are not there yet, aren't we? In all case, if ME can be disabled, it will be the default under Heads, and hopefully as an open source community pushing for what should be used, we will switch away of Intel to something else and focus on the alternatives more intensely. If we know it will happen in the future, maybe we should work on this today. Can somebody explain me why I would want my computer to always be awake again? If this is the case, I will power it off, which is recommended opsec anyway outside of roaming from outside the house to inside the house and when laptop is in physical presence, otherwise it should be powered off. My 2 cents.

[tlaurion]

Note to everyone lurking into this issue: we are not there yet and v506tu/v540tu will not have ME enabled, and supports s3. Its a question of adapting the configurations before #1821 under #1846 based on #1871 per @mkopec

Ref https://github.com/linuxboot/heads/pull/1846#issuecomment-2528510129

[mkopec]

ME is now disabled and S3 is enabled and functional: https://github.com/linuxboot/heads/pull/1846#issuecomment-2532346570

As I mentioned elsewhere, it's not supported by Intel so if it breaks with some update to silicon or fw there's a good chance they won't fix it (that's what happened with Tiger Lake), but right now it seems to work well

[mblanqui]

There seems to be a confusion from community around possibility of getting Clevo laptops with unfused bootguard keys and being able to flash custom firmware on those Clevo laptops. Clarify that Clevo laptops have unfused bootguard keys only if ordered through Novacustom bulk orders from Clevo to be rebranded and distributed with Dasharo firmware.

Laptop with Linux also sell a single sku of the V560TU with coreboot firmware, there's no mention of Dasharo on their website so presumably they're building from upstream.

[tlaurion]

Not a "leak" as for MSI bootguard private key leaked in 2023, but as important for Clevo but not a in public domain while still existing

Clevo bootguard signing keys are readily available, as instructions on how to sign custom firmware with signing toolkit from public WinRaid forum

[gitercn]

Hi @tlaurion and @mblanqui , I’m interested in modern Clevo laptops like the V560TU and X580. Some people say the X580 BIOS is locked, but I haven’t seen a concrete confirmation. Could I ask do you have any information regarding the:

1. Does the V560TU or X580 from other vendors have fused (locked) BootGuard?
2. If they are locked, can the leaked private keys be used to sign custom firmware and bypass BootGuard?
3. Are there any known cases of users successfully flashing Coreboot onto retail-purchased Clevo models (not NovaCustom/system76)?

[tlaurion]

Hi @tlaurion and @mblanqui , I’m interested in modern Clevo laptops like the V560TU and X580. Some people say the X580 BIOS is locked, but I haven’t seen a concrete confirmation. Could I ask do you have any information regarding the:

1. Does the V560TU or X580 from other vendors have fused (locked) BootGuard?

I can only reply for the Clevo v560TU/V540TU/NV41X that are distributed/sold by NovaCustom. As said at https://osresearch.net/Vendors/#novacustom-heads (as per latest commit while writing these lines:

NovaCustom buys Clevo laptops in bulk, ensuring BootGuard keys are not fused at the last manufacturing steps.

and

Nitrokey resells some of NovaCustom’s laptops.

TLDR: In 2025, Intel based laptops typically have BootGuard enabled, with OEM key fused (if Clevo is OEM; then they ship their laptops with their OEM key fused and only their OEM shipped firmware, signed with their private key can boot). If bought in bulk, Clevo here (replace Clevo by any other IBV that assembles motherboards components with soldered-on CPU) becomes becomes an IBV/ODM and the entity that sells/redistributes the hardware becomes the OEM. The OEM is the one selling the hardware, customizing what is put on the motherboard, casing, etc etc etc.

2. If they are locked, can the _leaked_ private keys be used to sign custom firmware and bypass BootGuard?

Yes, leaked private keys can be used to sign firmware and create totally valid firmware images that will pass BootGuard security validation. So technically, signed custom firmware would not bypass BootGuard; the technical security contracts ends where Clevo deliberately bundled their private keys with their firmware update packages. That's what I shared with binarly at https://github.com/binarly-io/SupplyChainAttacks/issues/6 which resulted in this blog post: https://www.binarly.io/blog/clevo-boot-guard-keys-leaked-in-update-package.

3. Are there any known cases of users successfully flashing Coreboot onto retail-purchased Clevo models (not NovaCustom/system76)?

No and its a problem/by legal agreements/fear of legal pursuits.

Nobody wants to risk creating such images in this gray legal area. Not even provide documentation to do this that would be platform generic.

• no coreboot developement will be done on those platforms but if there is prior jurisprudence permitting roms to be signed with Clevo private keys
• LinuxBoot won't document/provide images (non-redistributable blobs) to sign final images
• Maybe, I say maybe (don't quote me on that) https://github.com/9elements/converged-security-suite could be pushed to document better the generic way of signing a UEFI/coreboot image (but I see no point prior of the above two points being resolved to be interesting, which requires legal jurisprudence).

In face of law (so typical disclaimer here "don't do this unless you know the law blah blah", as well as "i'm not a lawyer" etc):

• Clevo private key was given, not stolen
  • Possession isn't theft: The key was distributed by the vendor. That’s not hacking or exfiltration.
• But still: copyright/IP still applies: Intel Boot Guard keys are part of an Intel-provided, license-bound verification chain (OEM Key Manifest, etc.). Even if released, they’re not open source or public domain.
  • Circumvention risk: In the US and similar jurisdictions (e.g., under DMCA 1201), using these keys to:
    • Bypass Boot Guard's intent (i.e., enforcing vendor control),
    • Even if to install your own code,
    • Could be interpreted as circumventing a technical protection measure, especially if redistributed.

So TLDR: Legally, publishing a firmware image signed with the leaked keys might violate:

• Copyright on original firmware blobs or key material.
• Circumvention clauses (especially if used to remove OEM protections or secure boot policies).
• Contractual clauses if the keys are part of an Intel/OEM signing process with restrictions.

So if we go back to linuxboot/Heads here

• Heads doesn't tamper UEFI images; Heads is coreboot, and coreboot requires a platform to be non-bootguarded (unfortunately that project doesn't receive a lot of contributions from people testing if board/laptop is in manufacturing mode/badly configured so bootguard is not properly enforced).
• LinuxBoot main use case is UEFI+DXE removal (utk/fiano) + u-root. To me, that would be the place to ask such questions, since LinuxBoot community is also closer to those who could do something there (bigger players that might want to do PoC on MSI/Clevo and have the legal support to prove the claims and push more secure solutions)
• To be honest, if there was such legal breakthrough/jurisprudence to show/prove/better bootguard with measured boot+IBB report and show real plug-and-pray limits of BootGuard (trusting OEM guards private key well forever, not sell it for 1M to partners etc etc), I think we would have a better trust in our ecoystem.

Anyway @gitercn the TLDR of TLDR:

• I approached journalists with this, asking them to order a PoC to show the public that BootGuard was bypassed with MSI leak. Nobody budged. With Clevo, its even worse, since its not a leak. Reminder that they gave the key, it was not taken. BootGuard requires proper safeguarding of those keys, which in turn requires proper security/processes which was proven over and over to be flawed. The real issue, in my opinion, is that humans want plug-and-pray. To change that, journalism would need to prove the world its not just a theoretical flaw. Clevo was that. No journalists I contacted went through revisiting MSI leak + Clevo. I personally gave up. But I doubt you will see public roms for those. And if you do, if not compiled from source; if not coreboot build images and reproducible builds; how would you trust that image enough to flash it on your computer to not leak private key material/confidential stuff back on the internet :)