yeet another post
This commit is contained in:
Jade Lovelace
parent
7e0b3a05e1
commit
26d2e57e42
1 changed files with 220 additions and 0 deletions
220
content/posts/pulling-apart-dell-uefi.md
Normal file
220
content/posts/pulling-apart-dell-uefi.md
Normal file
|
|
@ -0,0 +1,220 @@
|
||||||
|
+++
|
||||||
|
date = "2023-10-19"
|
||||||
|
draft = false
|
||||||
|
path = "/blog/pulling-apart-dell-uefi"
|
||||||
|
tags = ["uefi"]
|
||||||
|
title = "Pulling apart Dell UEFI images and messing with ACPI"
|
||||||
|
+++
|
||||||
|
|
||||||
|
This is a quick post to write down the method that worked for me to acquire and
|
||||||
|
pull apart a Dell UEFI image to get the executables out, and how to poke at
|
||||||
|
ACPI.
|
||||||
|
|
||||||
|
The specific issue I was curious about and trying to find more information
|
||||||
|
about is the [`rtsx` card reader NVMe regression][rtsx-explanation] on the Dell
|
||||||
|
XPS 15 9560, which is the laptop I use.
|
||||||
|
|
||||||
|
[rtsx-explanation]: https://lore.kernel.org/regressions/c7bdd821686e496eb31e4298050dfb72@realtek.com/
|
||||||
|
|
||||||
|
The regression was caused by the card reader driver no longer setting a
|
||||||
|
register that forces the PCIe `CLKREQ#` pin to be always pulled low, which was,
|
||||||
|
in effect, making the kernel no longer ask the chipset for PCIe clock all the
|
||||||
|
time.
|
||||||
|
|
||||||
|
However, this is even more confusing, because this is essentially a
|
||||||
|
force-disabling bit for attempting to do PCIe ASPM, which was never enabled in
|
||||||
|
the first place on the machine!
|
||||||
|
|
||||||
|
For *some reason*, the *card reader* ceasing to ask the chipset for clock all
|
||||||
|
the time (which, given that ASPM is purportedly disabled in the ACPI tables,
|
||||||
|
should be a no-op!) caused the *NVMe SSD*, which has nothing to do with the
|
||||||
|
card reader, to lose its PCIe link after the card reader driver loads. Further,
|
||||||
|
this happened to every kind of SSD, so it must be some kind of platform bug.
|
||||||
|
|
||||||
|
If you have any ideas of why this is happening, send me an email at <bug at jade
|
||||||
|
dot fyi>, I am very curious.
|
||||||
|
|
||||||
|
# Extracting the firwmare
|
||||||
|
|
||||||
|
I acquired a copy of the firmware [from fwupd here][fwupd]. This is a
|
||||||
|
Microsoft cabinet file. I then used [BIOSUtilities] and p7zip to extract it:
|
||||||
|
|
||||||
|
[fwupd]: https://fwupd.org/lvfs/devices/com.dell.uefi34578c72.firmware
|
||||||
|
|
||||||
|
```
|
||||||
|
mkdir bios
|
||||||
|
mv ../4d77eabfe13e3d153dfe9f19b570de40cc90260ef7229b2ca070e06b5c840040-Dell_XPS_15_9560_Precision_5520_System_BIOS_Ver.1.24.0.cab bios
|
||||||
|
(cd bios; 7z x *.cab)
|
||||||
|
python Dell_PFS_Extract.py -i bios -o bios_ex
|
||||||
|
```
|
||||||
|
|
||||||
|
This then produces some files:
|
||||||
|
|
||||||
|
```
|
||||||
|
BIOSUtilities » ls bios_ex/firmware.bin_extracted/Firmware/1\ firmware\ --\ *
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 1 System BIOS with BIOS Guard v1.24.0.bin'
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 2 Embedded Controller v1.0.29.bin'
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 3 Intel Management Engine (VPro) Update v11.8.86.3877.bin'
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 4 Main System TI Port Controller 0 v7.0.0.31.bin'
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 5 System Board Map v1.0.1.bin'
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 6 PCR0 XML v0.0.0.1.xml'
|
||||||
|
'bios_ex/firmware.bin_extracted/Firmware/1 firmware -- 7 Model Information v1.0.0.0.txt'
|
||||||
|
```
|
||||||
|
|
||||||
|
[BIOSUtilities]: https://github.com/platomav/BIOSUtilities
|
||||||
|
|
||||||
|
From here, you can use UEFITool on these files:
|
||||||
|
|
||||||
|
```
|
||||||
|
UEFITool firmware.bin_extracted/Firmware/1\ firmware\ --\ 1\ System\ BIOS\ with\ BIOS\ Guard\ v1.24.0.bin
|
||||||
|
```
|
||||||
|
|
||||||
|
From here you can go hunting through the data in there or try `UEFIExtract`.
|
||||||
|
|
||||||
|
You can find a PE32 image called Setup somewhere in the UEFI image, and extract
|
||||||
|
it. With such an image, you can use [`ifrextractor`][ifrextractor] to pull out
|
||||||
|
the BIOS options. Acquire a copy like so:
|
||||||
|
|
||||||
|
[ifrextractor]: https://github.com/LongSoft/IFRExtractor-RS
|
||||||
|
|
||||||
|
`ifrextractor.nix`:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
{ rustPlatform, fetchFromGitHub }:
|
||||||
|
rustPlatform.buildRustPackage {
|
||||||
|
pname = "ifrextractor";
|
||||||
|
version = "0.0.1";
|
||||||
|
src = fetchFromGitHub {
|
||||||
|
owner = "longsoft";
|
||||||
|
repo = "ifrextractor-rs";
|
||||||
|
rev = "f40b9be0da561ede62f3988072100550a73d5386";
|
||||||
|
sha256 = "sha256-No0H91iMcOQlE0Hcc+w02w5CP3M+Ixct+92+XsreIik=";
|
||||||
|
};
|
||||||
|
cargoSha256 = "sha256-smVHEBhjUcy4ApyJzhV31sMTB87Cdq59fxkSJsS1/cw=";
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
nix-build -E 'with import <nixpkgs> {}; callPackage ./ifrextractor.nix'
|
||||||
|
```
|
||||||
|
|
||||||
|
Then extract the setup stuff with the following:
|
||||||
|
|
||||||
|
```
|
||||||
|
ifrextractor firmware.bin_extracted/Section_PE32_image_Setup_body.efi
|
||||||
|
```
|
||||||
|
|
||||||
|
Then read the extremely large file named like:
|
||||||
|
`Section_PE32_image_Setup_body.efi.0.0.en-US.ifr.txt`.
|
||||||
|
|
||||||
|
If you *did* want to tamper with hidden settings, you could potentially have
|
||||||
|
such bad ideas with similar methods to the following (please take a backup of
|
||||||
|
the NVRAM first to not brick your computer!):
|
||||||
|
|
||||||
|
* <https://ristovski.github.io/posts/inside-insydeh2o/#peeking-inside-the-bios-image>
|
||||||
|
* <https://hansdegoede.livejournal.com/25413.html>
|
||||||
|
|
||||||
|
If you want to stick the thing in Ghidra, there does [exist an extension,
|
||||||
|
efiSeek][efiSeek], but I couldn't really tell if it was providing any useful
|
||||||
|
analysis results.
|
||||||
|
|
||||||
|
[efiSeek]: https://github.com/DSecurity/efiSeek
|
||||||
|
|
||||||
|
# ACPI
|
||||||
|
|
||||||
|
In investigating the power management issue I was curious about, I wanted to
|
||||||
|
understand what was in the ACPI tables and what was going on. These tables are
|
||||||
|
probably somewhere in the UEFI image as well, but I am not sure where.
|
||||||
|
|
||||||
|
You can dump the ACPI tables from a running system using `acpidump` from `acpica-tools`:
|
||||||
|
|
||||||
|
```
|
||||||
|
mkdir acpi && cd acpi
|
||||||
|
sudo acpidump -b
|
||||||
|
iasl -d *.dat
|
||||||
|
```
|
||||||
|
|
||||||
|
If you want to get values of ACPI variables, you can use the [ACPI
|
||||||
|
debugger][acpidbg] from the Linux kernel distribution:
|
||||||
|
|
||||||
|
[acpidbg]: https://docs.kernel.org/firmware-guide/acpi/aml-debugger.html
|
||||||
|
|
||||||
|
First, enable the right Kconfig options:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
{ lib, config, ... }: {
|
||||||
|
boot.kernelPackages = pkgs.linuxPackages.extend (self: super: {
|
||||||
|
kernel = super.kernel.override (old: {
|
||||||
|
kernelPatches = old.kernelPatches ++ [
|
||||||
|
{
|
||||||
|
name = "acpi_nonsense";
|
||||||
|
patch = null;
|
||||||
|
extraStructuredConfig = with lib.kernel; {
|
||||||
|
ACPI_DEBUGGER = yes;
|
||||||
|
ACPI_DEBUGGER_USER = module;
|
||||||
|
DEVMEM = yes;
|
||||||
|
STRICT_DEVMEM = no;
|
||||||
|
IO_STRICT_DEVMEM = option no;
|
||||||
|
};
|
||||||
|
}
|
||||||
|
];
|
||||||
|
});
|
||||||
|
});
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Then:
|
||||||
|
|
||||||
|
```
|
||||||
|
cd some-linux-sources
|
||||||
|
make acpi
|
||||||
|
sudo ./power/acpi/acpidbg
|
||||||
|
```
|
||||||
|
|
||||||
|
Inside the debugger you can print out things:
|
||||||
|
|
||||||
|
```
|
||||||
|
- Evaluate UCSI
|
||||||
|
Evaluating \UCSI
|
||||||
|
Evaluation of \UCSI returned object 00000000a57a6a95, external buffer length 18
|
||||||
|
[Integer] = 0000000000000000
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also use `Dump` to get information about a variable, such as its
|
||||||
|
offset, if you need to peek/poke the memory.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
If you want to tamper with the ACPI tables for investigating a potential fix,
|
||||||
|
there are a couple of ways to do it.
|
||||||
|
|
||||||
|
At runtime, you can [load an overlay][overlay]:
|
||||||
|
|
||||||
|
```
|
||||||
|
modprobe acpi_configfs
|
||||||
|
cd /sys/kernel/config/acpi/table/
|
||||||
|
mkdir my-ssdt ; cat ~youruser/somewhere/my-ssdt.aml > my-ssdt/aml
|
||||||
|
|
||||||
|
# unload with:
|
||||||
|
rmdir my-ssdt
|
||||||
|
```
|
||||||
|
|
||||||
|
[overlay]: https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html
|
||||||
|
|
||||||
|
It's also possible to replace the ACPI tables [with the initrd][initrd-acpi]:
|
||||||
|
Create a cpio archive with `kernel/firmware/acpi/*.dat`, then prepend it to the
|
||||||
|
actual initrd.
|
||||||
|
|
||||||
|
[initrd-acpi]: https://docs.kernel.org/admin-guide/acpi/initrd_table_override.html
|
||||||
|
|
||||||
|
# Conclusion
|
||||||
|
|
||||||
|
This whole affair did not achieve much, but it was very interesting, and I have
|
||||||
|
more of an idea how firmware works on x86.
|
||||||
|
|
||||||
|
For further information:
|
||||||
|
- [ACPI Spec][https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5_Aug29.pdf]
|
||||||
|
|
||||||
|
There may also exist schematics of the machine online, but I cannot confirm
|
||||||
|
this.
|
||||||
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue