Fork: 0
ajax / AMI-Aptio-BIOS-Reversed
Transfer to URL with SHA Find file
Newer
Older
AMI-Aptio-BIOS-Reversed / docs / firmware_overview.md
@Ajax Dong Ajax Dong 12 hours ago 8 KB Added some docs
Raw Blame History

Firmware Overview

This repository is a recovered source-oriented view of a Lenovo HR650X server
BIOS built on AMI Aptio V and Intel Purley platform code. It is not a pristine
vendor source tree. The current layout combines decompiled C, reconstructed
headers, generated function inventories, IDA artifacts, and analyst notes that
were regrouped by package path where debug/assert/PDB/source-path evidence was
available.

Use this document as the top-level map for the firmware. For provenance of the
package layout itself, see original_layout_recovery.md
and original_layout_evidence.json.

Platform Identity

  • System family: Lenovo HR650X server firmware.
  • Silicon generation: Intel Purley server platform.
  • Firmware framework: AMI Aptio V / UEFI PI.
  • Build evidence visible across modules: HR6N0XMLK, DEBUG_VS2015, IA32 PEI
    modules, and X64 DXE/SMM modules.
  • Source status: recovered/decompiled module source. Function names, types, and
    structures are a mixture of original symbols, debug-path hints, EDK II/AMI
    conventions, and analyst reconstruction.

Major Package Areas

Package Role in this tree
MdePkg, MdeModulePkg, UefiCpuPkg UEFI PI core services, DXE/PEI/SMM infrastructure, CPU and common library code.
AmiModulePkg AMI platform services: setup, NVRAM, flash, secure boot, TCG, CSM, PCI, terminal, storage, generic event log, and runtime support.
AmiIpmiPkg IPMI and BMC integration across PEI, DXE, and SMM.
AmiNetworkPkg UEFI network stack, PXE/HTTP/iSCSI, BMC LAN setup, and Redfish-related modules.
AmiTsePkg AMI text/setup environment and Aptio setup UI.
AmiCryptoPkg Crypto service initialization in PEI/DXE/SMM-facing components.
LenovoServerPkg Lenovo HR650X server integration: setup defaults, POST/status handling, system inventory, SMBIOS updates, ready-to-boot hooks, and OEM platform policy.
PurleyPlatPkg, PurleySktPkg, PurleyRpPkg Intel Purley platform, socket, south-cluster, ME/SPS, RAS, FPGA, SKU, board, and riser/platform-update logic.
CpPlatPkg, CpRcPkg Configuration/register access, WHEA, and platform support code used by the Purley server stack.
Build/GuidArtifacts GUID-named recovered artifacts whose original module identity remains incomplete or ambiguous.

Execution Model

The firmware follows the standard UEFI PI boot shape:

  1. SEC transfers into PEI.
  2. PEI Core dispatches PEIMs, publishes PPIs, builds HOBs, discovers firmware
    volumes, and initializes memory.
  3. DXE IPL discovers and loads the DXE Core, creates the x64 handoff context,
    and transfers the HOB list into DXE.
  4. DXE Core installs the boot-service execution environment: protocol database,
    handle database, memory services, image loading, events, timers, firmware
    volume services, and driver dispatch.
  5. DXE drivers initialize platform, storage, network, setup, security, BMC,
    ME/SPS, SMBIOS, ACPI, and runtime services.
  6. SMM IPL loads the SMM Core into SMRAM. SMM drivers then register SMI
    handlers for flash, NVRAM, IPMI, storage, RAS, chipset, and runtime work.
  7. BDS and setup select boot policy, maintain Boot#### variables, and launch
    the selected boot option.
  8. Runtime services, ACPI tables, SMBIOS tables, SMM handlers, and BMC/ME
    interfaces remain relevant after ExitBootServices.

The recovered core anchors are:

  • MdeModulePkg/Core/Pei/PeiMain/PeiCore/README.md for PEI dispatch, PPIs,
    HOB creation, memory initialization, and firmware-volume discovery.
  • MdeModulePkg/Core/DxeIplPeim/README.md and
    MdeModulePkg/Core/DxeIplPeim/DxeIpl.md for DXE core discovery, LZMA
    decompression, page table creation, and transfer to DXE.
  • MdeModulePkg/Core/Dxe/SectionExtraction/CoreSectionExtraction/README.md for
    the recovered DXE Core evidence.
  • MdeModulePkg/Core/PiSmmCore/PiSmmIpl/README.md and
    MdeModulePkg/Core/PiSmmCore/PiSmmCore/README.md for SMM loading, SMRAM
    management, SMM communication, and SMI dispatch.
  • PurleySktPkg/Override/IA32FamilyCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm/README.md
    for the CPU-side SMM execution component.

Behavioural Themes

Platform Bring-up

Purley PEI/DXE modules initialize CPU, memory, PCH, GPIO, PCIe/IIO, FPGA, ME/SPS,
watchdog, and board-specific SKU data. The tree contains both generic Intel/AMI
infrastructure and Lenovo/Purley board overlays. Important areas include:

  • PurleySktPkg/SouthClusterLbg/SiInit/Pei/SiInitPreMem
  • PurleySktPkg/SouthClusterLbg/SiInit/Pei/SiInit
  • PurleySktPkg/Me/Heci/*
  • PurleySktPkg/Me/Sps/*
  • PurleySktPkg/Smm/*
  • PurleyRpPkg/Uba/UbaMain/Dxe/Type*
  • LenovoServerPkg/POSTStatus/*
  • LenovoServerPkg/OemPlatformEarlyPhasePei
  • LenovoServerPkg/OemPlatformDxePhase

Security and Measured Boot

The firmware contains multiple security layers:

  • Boot Guard PEI support validates FV Main hash material early in PEI and can
    set a PCD to block boot on mismatch.
  • TCG/TPM modules initialize TPM 2.0, expose EFI_TCG2_PROTOCOL, extend PCRs,
    manage event logs, and update TPM ACPI objects.
  • Secure Boot DXE reads SecureBootSetup, provisions PK/KEK/db/dbx/dbt/dbr
    variables from firmware-volume data, and sets SetupMode.
  • SMM and secure-flash modules provide privileged update paths and runtime
    handlers that should be treated as high-impact code.

Primary evidence:

  • PurleyPlatPkg/BootGuard/ExtendBtGSupportToDxe/Pei/BootGuardPei/README.md
  • AmiModulePkg/TCG2/Common/TcgDxe/Tcg2Dxe/README.md
  • AmiModulePkg/SecureBoot/SecureBootDXE/README.md
  • AmiModulePkg/Flash/SmiFlash/README.md
  • AmiModulePkg/SecureFlash/SecSMIFlash/README.md

Management Controller Integration

BMC/IPMI behaviour is a first-class part of the firmware. The IPMI stack spans
PEI, DXE, and SMM:

  • PEI initializes BMC access early enough for watchdog, boot flags, and status
    reporting.
  • DXE initializes KCS transport, runs BMC self-test, checks BMC firmware,
    installs SMBIOS Type 42/SPMI records, and coordinates BMC setup options.
  • SEL/status-code modules forward platform health and POST events.
  • SMM modules keep BMC event-log and IPMI command paths available after boot.
  • Lenovo inventory modules collect platform data and likely report it to BMC
    and SMBIOS consumers.

Primary evidence:

  • AmiIpmiPkg/Ipmi/PeiIpmiInitialize/PeiIpmiBmcInitialize/PeiIpmiBmcInitialize/README.md
  • AmiIpmiPkg/Ipmi/IpmiInitialize/DxeIpmiBmcInitialize/DxeIpmiBmcInitialize/README.md
  • AmiIpmiPkg/Ipmi/SmmIpmiBmcInitialize/README.md
  • AmiIpmiPkg/Ipmi/DxeSelStatusCode/README.md
  • AmiIpmiPkg/Ipmi/SmmBmcElog/README.md
  • LenovoServerPkg/SystemInventory/SystemInventory/README.md

Setup, Policy, and Boot Selection

Setup behaviour is split between AMI UI infrastructure, Lenovo setup forms and
defaults, platform setup-update modules, and BDS boot-option handling:

  • AmiTsePkg/EDK/MiniSetup/AMITSE implements the Aptio setup UI, menu database
    parsing, boot-option management, HDD/security policy hooks, and display/input
    interaction.
  • LenovoServerPkg/Setup, ServerMgmtSetup, SocketSetup, and
    SetupDefaults define HR650X-specific setup variables and defaults.
  • PurleyRpPkg/Uba/UbaMain/Dxe/Type*/SetupConfigUpdateDxe modules specialize
    setup data by board/riser/SKU type.
  • Boot policy is represented through UEFI variables such as Boot####,
    BootOrder, BootNext, Timeout, and setup variables.

Primary evidence:

  • AmiTsePkg/EDK/MiniSetup/AMITSE/README.md
  • LenovoServerPkg/Setup/README.md
  • LenovoServerPkg/ServerMgmtSetup/README.md
  • LenovoServerPkg/SetupDefaults/SetupDefaultLoad/README.md
  • PurleyRpPkg/Uba/UbaMain/Dxe/TypeNeonCityEPRP/SetupConfigUpdateDxe/README.md

Reading Guidance

  • Treat module READMEs as summaries of recovered evidence, not as independent
    proof of vendor intent.
  • Prefer claims supported by function names, strings, GUIDs, protocols,
    variables, source paths, or multiple module notes.
  • Keep PEI, DXE, SMM, BDS, and runtime behaviours separate. Similar module names
    often describe different execution contexts.
  • For sensitive areas such as flash, variable services, secure boot, TPM, BMC,
    SMM communication, and RAS error handling, inspect the .c, .h, and sidecar
    .md files before making security conclusions.