What can we learn from leaked Insyde's BIOS for Intel Alder Lake October 8, 2022 | 3 min Read

What can we learn from leaked Insyde's BIOS for Intel Alder Lake

Leaked story timeline

According to the timestamp of the github repository, an unidentified user uploaded the Insyde’s partial firmware solution (4.8GB) only for Intel Alder Lake platform, which contains Intel reference implementation, OEM implementation, IBV solution, and related documentation on September 30, 2022.


On October 8 2022, the leaks attracted media tom’sHardware attention and reports, followed by the original repository deleted. Security researchers can still get leaked content via Internet Archive or forked repositories.

Leaked content

IBV OEM Support platform Host firmware
Insyde Lenovo Intel Alder Lake UEFI

Insyde is an IBV (Independent BIOS Vendor) developer and integrator of the firmware solution for various platforms. The leaked content is only part of the Insyde solution, which only supports Alder Lake. But there are several interesting finds:

  • Toolings from Insyde, that’d make OEM’s work easier like provisioning or tweaking BIOS images
  • Insyde’s framework for customization, which wrapped into EDK2-compatible interfaces, makes it easier for ODM/OEMs to integrate platform components such as Intel FSP
  • Intel reference implementation as well as the OEM implementation. Lenovo as an OEM vendor plays the main role in the leaked story.
  • Binary blobs: It’s worth noting that in addition to the binary blobs required by various devices (Bluetooth BLE, WiFi, Ethernet, etc.), there are three different ACMs for security features: BiosGuard, BootGuard, and TXT

In addition, one thing should be noted that the key pairs required by BootGuard during provisioning stage is also included in the leaked content:


In x86, the ACMs is signed by Intel while the OEM controls the latter part:


Let’s pray for Lenovo didn’t use any of those keys in the production (Prove us wrong!)!

Risk assessment of the leak to users

UEFI is highly rely on SMM (System Management Mode) that has greater priviledges than operating system and complexity of the firmware supply chain have led to higher security risks. The current disclosed massive exploitation of malicious firmware/bootkits and those not yet being disclosed is a big risk for both individual and data centers. We do not have comprehensive review of the leaked content. The attacker/bug hunter can hugely benefit from the leaks even if leaked OEM implementation is only partially used in the production. The Insyde’s solution can help the security researchers, bug hunters (and the attackers) find the vulnerablity and understand the result of reverse engineering easily, which adds up to the long-term high risk to the users.

Can open source firmware projects benefit from leaked content?

Unfortunately, no or rarely. These materials could theoretically help two groups of people:

* Individuals or organizations that are not eligible to sign CNDA with Intel, such as open source firmware maintainers. Please note that open source firmware projects cannot directly benefit/reuse from leaked content due to legal risks
* Researchers trying to understand complex supply chains

Who’s the leaker

The few pieces of information come from the git log:


But it is still impossible to confirm the person who leaked it. The leak is part of Insyde solution which integrate Intel’s resources. Perhaps Insyde knows more than we do.

How data center react

Server models are not affected by the leaked content directly but there may be some shared code base of firmware between server and desktop, so the data center should prepare:

  • Short-term plan:

    • Security team and patch management team should work together to ensure critical devices are upgraded to the latest version
    • The security operation team keep monitoring the priviledge escalation in operating system
    • Threat detection and auditing against existing firmware
  • Long-term solution:

    • Replace UEFI with coreboot/oreboot-based next-generation firmware
    • Integrate with security payloads (such as VaultBoot, LinuxBoot, etc.) to implement provisioning of hardware security features