cbmk/util/dell-flash-unlock/README.md

135 lines
7.2 KiB
Markdown
Raw Normal View History

# Dell Laptop Internal Flashing
This utility allows you to use flashprog's internal programmer to program the
entire BIOS flash chip from software while still running the original Dell
BIOS, which normally restricts software writes to the flash chip. It seems like
this works on any Dell laptop that has an EC similar to the SMSC MEC5035 on the
E6400, which mainly seem to be the Latitude and Precision lines starting from
around 2008 (E6400 era).
## TL;DR
### Linux specific
- On Linux, ensure you are booting with the `iomem=relaxed` kernel parameter.
- If you get a "Function not implemented" error, ensure that your kernel has
"CONFIG_X86_IOPL_IOPERM" set to "y". Here are several common locations for
the config and how to check them:
- `zcat /proc/config.gz | grep IOPL`
- `grep IOPL /boot/config`
- `grep IOPL /boot/config-$(uname -r)`
If it says it is not set, then you will need to install or compile a kernel
with that option set.
### OpenBSD/NetBSD/FreeBSD
- On OpenBSD/NetBSD/FreeBSD, ensure you are booting with securelevel set to -1.
### General
Make sure an AC adapter is plugged into your system
Run `make` to compile the utility, and then run `./dell_flash_unlock` with
root/superuser permissions and follow the directions it outputs.
## Confirmed supported devices
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
- Latitude E6400, E6500
- Latitude E6410, E4310
- Latitude E6420, E6520
- Latitude E6430, E6530, E5530
- Latitude E7240
- Precision M6800, M5800
It is likely that any other Latitude/Precision laptops from the same era as
devices specifically mentioned in the above list will work as Dell seems to use
the same ECs in one generation.
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
## Tested
These systems have been tested, but were reported as not working with
dell-flash-unlock. This could be due to user error, a bug in this utility, or
the feature not being implemented in Dell's firmware. If you have such a system,
please test the utility and report whether or not it actually works for you.
- Latitude E6220
- Latitude E6330
## Detailed device specific behavior
- On GM45 era laptops, the expected behavior is that you will run the utility
for the first time, which will tell the EC to set the descriptor override on
the next boot. Then you will need to shut down the system, after which the
system will automatically boot up. You should then re-run the utility to
disable SMM, after which you can run flashprog. Finally, you should run the
utility a third time to reenable SMM so that shutdown works properly
afterwards.
- On 1st Generation Intel Core systems such as the E6410 and newer, run the
utility and shutdown in the same way as the E6400. However, it seems like the
EC no longer automatically boots the system. In this case you should manually
power it on. It also seems that the firmware does not set the BIOS Lock bit
when the descriptor override is set, making the 2nd run after the reboot
technically unnecessary. There is no harm in rerunning it though, as the
utility can detect when the flash is unlocked and perform the correct steps
as necessary.
## How it works
There are several ways the firmware can protect itself from being overwritten.
One way is the Intel Flash Descriptor (IFD) permissions. On Intel systems, the
flash image is divided into several regions such as the IFD itself, Gigabit
Ethernet (GBE) non-volative memory, Management Engine (ME) firmware, Platform
Data (PD), and the BIOS. The IFD contains a section which specifies the
read/write permissions for each SPI controller (such as the host system) and
each region of the flash, which are enforced by the chipset.
On the Latitude E6400, the host has read-only access to the IFD, no access to
the ME region, and read-write access to the PD, GBE, and BIOS regions. In order
for flashprog to write to the entire flash internally, the host needs full
permissions to all of these regions. Since the IFD is read only, we cannot
change these permissions unless we directly access the chip using an external
programmer, which defeats the purpose of internal flashing.
However, Intel chipsets have a pin strap that allows the flash descriptor
permissions to be overridden depending on the value of the pin at power on,
granting RW permissions to all regions. On the ICH9M chipset on the E6400, this
pin is HDA\_DOCK\_EN/GPIO33, which will enable the override if it is sampled
low. This pin happens to be connected to a GPIO controlled by the Embedded
Controller (EC), a small microcontroller on the board which handles things like
the keyboard, touchpad, LEDs, and other system level tasks. Software can send a
certain command to the EC, which tells it to pull GPIO33 low on the next boot.
Although we now have full access according to the IFD permissions, we still
cannot flash the whole chip, due to another protection the firmware uses.
Before software can update the BIOS, it must change the BIOS Write Enable
(BIOSWE) bit in the chipset from 0 to 1. However, if the BIOS Lock Enable (BLE)
bit is also set to 1, then changing the BIOSWE bit triggers a System Management
Interrupt (SMI). This causes the processor to enter System Management Mode
(SMM), a highly privileged x86 execution state which operates transparently to
the operating system. The code that SMM runs is provided by the BIOS, which
checks the BIOSWE bit and sets it back to 0 before returning control to the OS.
This feature is intended to only allow SMM code to update the system firmware.
As the switch to SMM suspends the execution of the OS, it appears to the OS
that the BIOSWE bit was never set to 1. Unfortunately, the BLE bit cannot be
set back to 0 once it is set to 1, so this functionality cannot be disabled
after it is first enabled by the BIOS.
Older versions of the E6400 BIOS did not set the BLE bit, allowing flashprog to
flash the entire flash chip internally after only setting the descriptor
override. However, more recent versions do set it, so we may have hit a dead
end unless we force downgrade to an older version (though there is a more
convenient method, as we are about to see).
What if there was a way to sidestep the BIOS Lock entirely? As it turns out,
there is, and it's called the Global SMI Enable (GBL\_SMI\_EN) bit. If it's set
to 1, then the chipset will generate SMIs, such as when we change BIOSWE with
BLE set. If it's 0, then no SMI will be generated, even with the BLE bit set.
On the E6400, GBL\_SMI\_EN is set to 1, and it can be changed back to 0, unlike
the BLE bit. But there still might be one bit in the way, the SMI\_LOCK bit,
which prevents modifications to GBL\_SMI\_EN when SMI\_LOCK is 1. Like the BLE
bit, it cannot be changed back to 0 once it set to 1. But we are in luck, as
the vendor E6400 BIOS leaves SMI\_LOCK unset at 0, allowing us to clear
GBL\_SMI\_EN and disable SMIs, bypassing the BIOS Lock protections.
There are other possible protection mechanisms that the firmware can utilize,
such as Protected Range Register settings, which apply access permissions to
address ranges of the flash, similar to the IFD. However, the E6400 vendor
firmware does not utilize these, so they will not be discussed.
rebase cbmk 9429287 per lbmk c4d90087..f5b04fa5 cbmk 9429287 is the present canoeboot revision, on this day, two commits after canoeboot 20231107 the cbmk revision was based on lbmk c4d90087, but lbmk has developed a lot since, right up to f5b04fa5. lbmk c4d90087 was four commits after libreboot 20231106 this patch brings cbmk up to date, versus lbmk f5b04fa5, which is 135 commits after libreboot 20231106 (not 4) therefore, the next canoeboot release shall import lbmk changes made *after* lbmk revision f5b04fa5. good day! In English (the above is for my reference, next time I make a new canoeboot release): This imports all of the numerous improvements from Libreboot, sans the non-FSDG-compliant changes. You can find a full list of such changes in the audit4 page: https://libreboot.org/news/audit4.html A full canoeboot-ised changelog will be available in the next canoeboot release, with these and subsequent changes. Most notable here is the update to the new GRUB 2.12 release (instead of 2.12-rc1), and the improvements Riku made to pico-serprog. And the build system improvements from lbmk, such as improved, more generic cmake and autoconf handling. Canoeboot-specific changes: I also tweaked the deblob logic, to make it less error-prone. The new design changes imported into cbmk (based on latest lbmk) somewhat broke the deblob logic; it was constantly reminding the user that blobs.list was missing for coreboot, at config/coreboot/blobs.list - coreboot is a multi-tree project in both cbmk and lbmk, and the deblob logic was tuned for single/multi, but was treating coreboot as both. for simplicity, i removed the check for whether blobs.list is present. this means that the operator must ensure that these files are present, in any given revision, where they are required on a given set of projects (and the files are all present, in this update to cbmk) Also of note: the grub.cfg improvements are included in this cbmk update. The improved grub.cfg can find grub/syslinux configs by default, not just grub anymore, also finds extlinux, and will also find them on EFI System Partition - in addition, UEFI-based install media is also more robust; although cbmk doesn't provide UEFI configurations on x86, our GRUB palyoad does still need to work with distro install media, and many of them now use UEFI-based GRUB configurations in their installation media, which just happen to work with our GRUB Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-02 11:37:25 +00:00
## References
- Open Security Training: Advanced x86: BIOS and SMM Internals - SMI Suppression
- https://opensecuritytraining.info/IntroBIOS_files/Day1_XX_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20SMI%20Suppression.pdf