This blog enty first appeared on the 9esec blog.
FSP-T in open source projects
X86 CPUs boot up in a very bare state. They execute the first instruction at the top of memory mapped flash in 16 bit real mode. DRAM is not avaible (AMD Zen CPUs are the exception) and the CPU typically has no memory addressable SRAM, a feature which is common on ARM SOCs. This makes running C code quite hard because you are required to have a stack. This was solved on x86 using a technique called cache as ram or CAR. Intel calls this non eviction mode or NEM. You can read more about this here.
Hardware assisted root of trust mechanism and coreboot internals
This blog enty first appeared on the 9esec blog.
I started working for 9elements in October 2020 and my first assignment was to get Intel CBnT working on the OCP Deltalake using coreboot firmware. Intel Converged Bootguard and TXT is a hardware assisted method to set up a root of trust. In this blog post I will discuss some of the changes needed in coreboot to get this working. Setting CBnT up properly was definitely a challenge, but the work did not stop there. So while Intel CBnT provides a method to verify or measure the initial start-up code, it is not enough. You want to trust the code you run from start, the reset vector, to end, typically a bootloader. CBnT only takes care of the start. You have to make sure that each software component trusts the assets it uses and the next program it loads. This concept is called a chain of trust. Now in 2021 I have an assignment that involves supporting the older Intel Bootguard technology. Since Bootguard is very similar to CBnT, I'll also touch on that.
FSP1.1 Braswell TempRaminit problems
Coreboot is migrating platforms from a romcc bootblock to C_ENVIRONMENT_BOOTBLOCK in which Cache-as-Ram is set up in the bootblock.
When migrating Braswell, chromebooks featuring this SOC did not boot anymore while other boards did. Google uses a different FSP binary than the one present in the Intel Github FSP repository.
Previously the romcc bootblock set up caching of the ROM, located microcodes and performed the update before calling FSP TempRaminit.
A gentle introduction to Cache-as-Ram on X86
This explains a bit of history on CAR in coreboot and how it works.
Glossary
- CPU cache: CPU cache is a piece of fast memory used by the CPU to cache access to things accessed in the CPU's linear memory space. This includes for DRAM, PCI BARs, the boot flash.
- Cache-as-RAM/CAR: Using not memory mapped CPU cache as execution environment.
- XIP: Execute in place on a memory mapped (read only) medium.
- SRAM: Static Random Access Memory, here: memory mapped memory that needs no initialization.
- ROMCC: A C compiler using only the CPU registers.
Cache-as-Ram, the basics
When an X86 platforms boot, it starts in a pretty bare environment. The first instruction is fetched from the top of the boot medium, which on most x86 platforms is memory mapped below 4G (in 32bit protected mode). Not only do they start in 16bit 'real' mode, most of the hardware starts uninitialized. This includes the dram controller. Another thing about X86 platforms is that they generally don't feature SRAM, static RAM. SRAM for this purpose of this text is a small region of ram that is available without any initialization. Without RAM this leaves the system with just CPU registers and a memory mapped boot medium of which code can be executed in place (XIP) to initialize the hardware.
How to flash coreboot to the thinkpad x60 the proper way
What is so special about the x60 when running vendor bios?
Vendor BIOS write protects its bootblock, which means the lowest 64K of the flash can’t be modified
This is a problem since the first code that runs on the CPU comes from there and if we ever want to run coreboot the cpu must start with coreboot code. This write protection is set in the PBR (protect bios range) registers on the southbridge, there is currently no known way to change them back once they are locked by setting the SPI Configuration Lock-Down bit.
Hacking ath9k wifi device adventures
So here is where it all started. I have this apple branded atheros AR5BXB92, with an ar9280 chipset, which is supported by the ath9k Linux drivers. This chipset is supposed to support both 5GHz and 2.4GHz frequencies, but using the wavemon tool 5GHz SSID never show up even when I'm next to a device that emits one.
iw list shows the following:
Band 2:
Capabilities: 0x11ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5180 MHz [36] (16.0 dBm) (no IR)
* 5200 MHz [40] (16.0 dBm) (no IR)
* 5220 MHz [44] (16.0 dBm) (no IR)
* 5240 MHz [48] (16.0 dBm) (no IR)
* 5260 MHz [52] (17.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (16.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (16.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (16.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
So most of the 5GHz channels which are avaible in my country were disabled.
Changing the reg domain iw reg set BE did not change this
On the web I found some articles about modifying the reg domain in the eeprom
that is present on that wifi card. One of these is the following guide.
The link to the iwleeprom code is dead but can be found on the following github repo.
Doing so I found out that my region code is 0x65. I tried to modify that eeprom content
but that didn't seem to work properly for some reason.
I knew that almost everything is done by the kernel driver so I looked for the possibilty
to override this regional setting an I found it! By changing the reg_rules for my 0x65 domain
device and recompiling the ath9k module I got those 5GHz appearing in wavemon and listed as
supported in iw list!
Porting the Intel DG41WV and Intel 4 series DDR3 raminit to coreboot
This post will explain a bit how the Intel 4 series DDR3 raminit came to be and will introduce a new board that can make use of this code, namely the Intel DG41WV.
DDR3 raminit
In the past I have worked quite on a bit on the coreboot code that support the Intel 4 series desktop chipset (those chipsets go by the name of G41, G43, G45, Q43, Q45, P41, P43, P45, B43 with each having a somewhat different feature set). In the past I have made quite a few improvements to the coreboot code for this platform: