Tag: this-should-be-a-page

M.2 (NGFF) vs standard SATA drive sockets in Purism Librem laptops

We have gotten many questions on the M.2 (NGFF) drive in the Librem laptops, those questions ranging from:

  1. Can you boot from the M.2?
  2. Can you have both M.2 and SATA Drives?
  3. Which one is primary, which one is secondary?

So we wanted to confirm and answer those questions. In short:

  1. Can you boot from the M.2? Yes!
  2. Can you have both M.2 and SATA Drives? Yes!
  3. Which one is primary, which one is secondary? M.2 is primary

We also wanted to provide a brief HOWTO when you order with, or use, both an M.2 and a SATA drive.

Roadmap To A Completely Free BIOS

Purism is committed to users’ rights to privacy, security, and freedom. This post identifies the steps needed to achieve the standard set by the Free Software Foundation’s Respects Your Freedom endorsement.

On our status page, Road to FSF Endorsement… And Beyond, we are currently developing the coreboot BIOS for the Librem 13.

The Intel FSP Blob

Demand Freedom. Unlock Your Memory Init.Intel publishes a Firmware Support Package (FSP) so that silicon initialization (like memory init) can be integrated into any bootloader. The FSP is a binary blob provided by Intel.

Using the Free Software in coreboot but an FSP blob does not meet the FSF RYF endorsement requirements. Purism’s goal is to publish a Free Software implementation of the pieces handled by the FSP as soon as an implementation is available.

The Management Engine (ME) Blob

ME BlobBecause Purism ships Librem CPUs fused to allow unsigned software, we have set our sights on publishing a Free Software implementation of the Management Engine firmware. No other company currently offers CPUs with this configuration, though it is our hope that our success will prompt more and more companies to fuse their CPUs for freedom.

If you would like to help create a Free ME Firmware notwithstanding my cheesy ME-DRM logo, please contact us.

The Embedded Controller (EC)

ene KB3930The Librem 13 uses an ene KB3930QF-A1 with an external SPI 64KB firmware. Purism is grateful for the KB3930 datasheet that was made available as part of the One Laptop Per Child project. Good documentation is a critical step toward achieving a fully Free Software laptop.

The EC:

  • Powers the laptop on and off. The KB3930 is what recognizes the user pressed the power button and sends the “power on” signal to the laptop.
  • Talks SMBus to the battery.
  • Keeps the date & time while off.
  • Controls the fan speed.
  • Reports the keyboard and trackpad to the CPU (via the normal PS/2 interface, routed over the LPC bus).
  • Directly drives the power, sleep, and wifi LEDs.

SSD Firmware

Some really talented hackers at srlabs.de used a USB Flash Drive’s firmware to gain complete control over a Windows PC.

While Purism can offer best-in-class kernel security (the Linux kernel) and Free Software (PureOS), our goal is to free the firmware in the SSD as well. Purism wants to shine a light on all the dark corners of a high-end laptop.

Why free the functionality of such a small part of a laptop? Because it represents a not-insignificant level of user freedom. When the user can run, copy, distribute, study, change and improve the firmware on their SSD, it has the ability to produce as impressive results as what the srlabs.de team did.

Without that freedom, we are all poorer.

Freeing the BIOS: Memory Init

Librem 13Intel has not published their Firmware Support Package for 5th-Gen Intel Processors yet, such as the Haswell-ULT and Broadwell CPUs. In order to ship Coreboot on the Librem 13 on time, the alternative is to achieve interoperability with the memory and PCH init code from the proprietary BIOS.

Background

The default for coreboot is to use the FSP binary blob for recent Intel CPUs. Vladimir Serbinenko and Damien Zammit have freed the memory init code for Sandy Bridge and some Ivy Bridge CPUs. Our goal is to eventually free the memory init code for 5th-Gen CPUs.

When Intel releases the FSP, we can use that. In the meantime, here is a guide to memory init for 5th-Gen Intel CPUs.

Cache As RAM

inteldieshotWhen an Intel CPU first boots, the memory controller is not set yet. The first part of coreboot, known as the ROM stage, must avoid saving any variables or using any stack. Cache as RAM gets coreboot to the next stage. This is sort of a hack: first the MSRs are configured and the cache lines are filled with zeros as if there were memory present, then Cache Disable in CR0 is set and cleared without invalidating cache with INVD. Proprietary BIOSes use the same trick. With Cache as RAM, regular C code can run.

Memory Init

After setting GPU and PCH BARs, coreboot can proceed to initialize actual memory. The Librem 13 v1 has DDR3L DRAM. Here is the “MemoryInit” PEI Module and NbPei PEIM that do the memory init for the Librem 13 v1: Memoryinit.zip

The FSP will contain essentially the same code (perhaps with minor bugfixes) packaged so that coreboot can call into it. Studying either binary blob should give the same information.

Caveat: The sequence of operations used by the proprietary BIOS for memory init is not a guarantee it will work flawlessly for coreboot. Vladimir Serbinenko and Damien Zammit have already encountered inconsistent behavior with their efforts. However, Purism is committed to freeing the BIOS, and this is the first step.

Free Software Tools To Dump a PEIM

PEI Modules are in PE format, also used by Windows .exe files. The primary difference between the two is that Windows .exe files use .dlls while PEI Modules use PPIs (PEI Module-to-PEI Module Interfaces); PEIMs are statically linked.

The assembler source code of NbPei.peim looks like this:

$ radare2 NbPei.peim
[0x00000438]> pD
   ;-- entry0:
   0x0438    56             push esi
   0x0439    8b74240c       mov esi, dword [esp + 0xc]
   0x043d    e802000000     call 0x444 ;first_fn1
   0x0442    5e             pop esi
   0x0443    c3             ret

first_fn1:
   0x0444    55             push ebp
   0x0445    8bec           mov ebp, esp
   0x0447    51             push ecx
   0x0448    8b06           mov eax, dword [esi]
   0x044a    53             push ebx
; Here is the first EFI system reference
   0x044b    8b5864         mov ebx, dword [eax + 0x64]
   0x044e    57             push edi
   0x044f    33ff           xor edi, edi
   0x0451    57             push edi
   0x0452    57             push edi
   0x0453    57             push edi
   0x0454    6801800600     push 0x68001
   0x0459    6a01           push 1
   0x045b    56             push esi
; Another EFI system reference
   0x045c    ff5058         call dword [eax + 0x58]
   0x045f    8b06           mov eax, dword [esi]
   0x0461    8d4dfc         lea ecx, [ebp - 4]
   0x0464    51             push ecx
   0x0465    6a10           push 0x10
   0x0467    6a06           push 6
   0x0469    56             push esi
   0x046a    897dfc         mov dword [ebp - 4], edi
; Another EFI system reference
   0x046d    ff5034         call dword [eax + 0x34]
   0x0470    83c428         add esp, 0x28
   0x0473    85c0           test eax, eax

This is a great place to introduce you to radare2, partially licensed under GPLv3. It does not seem like anyone has attempted to disassemble a PEIM with radare before, but IDA Scripts exist to resolve the constants into EFI System Table symbolic names.

That’s the next step, then: automatically resolve the constants into EFI System Table symbols and other tooling to automate radare.

Conclusions

The memory init code is a significant step toward successfully booting a fully Free Software laptop. As the code for 5th-gen Intel CPUs has not been released, all we have right now are binary blobs. If you have suggestions regarding our approach please contact us.

BIOS Freedom Status as of November 2014

Steps to free the BIOS:

  1. Fuse CPU to allow unsigned BIOS binaries [DONE!]
  2. Free the FSP/ME
  3. Release a coreboot/libreboot for the Librem 15

The BIOS on the Librem 15 laptop currently uses an Intel binary blob, called FSP. We are working to release this under a free license. The current status of the BIOS freedom is kept here.

Binary Blob Situation

An Intel laptop design using coreboot/libreboot would need the following blobs freed:

Note: Intel at IDF14 suggested they might be willing to share some of the needed information for this effort.

  • Intel FSP previous known as “Intel Memory Reference Code” composed of several sub-programs (DRAM, PCH, SMC, and USB init)
  • Microcode updates
  • Embedded Controller (EC) / System Management Controller (SMC)
  • Management Engine (ME)

Intel is one of the largest semiconductor manufacturers, so they tend to take a slightly different approach for many of their designs. This section details efforts to build an FSF-endorsed laptop around an Intel CPU.

Intel Initial Chip Selections

The laptop design will probably involve making the right choices for the following chips as well as others:

  • Intel CPU that does not require microcode updates
  • Chipset (on Intel it’s called a Platform Controller Hub), example: “Intel X99 PCH”
  • Embedded Controller
  • Super I/O
  • BIOS flash chip (8 Megabytes which is 64 Megabits should be just fine)

Embedded Controller (EC) / System Management Controller

  • The EC/SMC controls what happens when the system is powered on and powered off. Example: when the user presses the power button to turn the system on.
  • In a laptop, the EC also handles signaling to/from the laptop battery.
  • Most of the time the hardware manufacturer who designs the board provides the EC pre-programmed.
  • The EC is central to functions like power on/off, suspend, and hibernate – so the hardware manufacturer must provide the necessary information for ACPI tables.

Microcode Updates

Neither Intel (nor AMD) allow third-party microcode updates. Both manufacturers use a signature to lock their microcode using a private key held only by the manufacturer.

Both make their CPUs with microcode already loaded at manufacture. This may qualify for the FSF endorsement exception since it is non-writable.

Therefore, it may be possible to purchase a CPU with working microcode. Then, no updates would be required. The CPU must be specified in great detail (e.g. a specific model, stepping, and revision is required) – the manufacturer typically adds microcode changes with each revision of the product.

Intel Firmware Support Package (FSP)

Intel bundles many blobs into a single package called an FSP. Coreboot/Libreboot can use Intel’s FSP but coreboot/libreboot does not provide the information on how to separate the FSP into its individual blobs.

Once the FSP has been analyzed, the list of Intel blobs starts to look similar to the list of AMD blobs:

  • Intel memory controller initialization source code is not available. The FSP has x86 binary code for this. Required for boot and FSF endorsement.
  • XHCI (USB 3) – ignore. Use a blob-free one like the PLX USB 3382.
  • AHCI (SATA) firmware. Intel Rapid Storage Technology adds a small solid-state drive (SSD) to a larger magnetic hard drive – hidden from the OS. It may be possible to bypass Rapid Storage Technology and initialize the SATA ports without a firmware blob.

Intel Management Engine (ME)

The Management Engine (ME) blob. It is a 5 Megabyte blob inside the mainboard bios and details about it can be found here: http://me.bios.io

The FSP binary is just a rework of the older “MRC” blob.  The whole reverse engineered MRC blob for sandybridge/ivybridge boards, it is currently available in the coreboot tree as NORTHBRIDGE_SANDYBRIDGE_NATIVE and NORTHBRIDGE_IVYBRIDGE_NATIVE.  However, the ME blob is something completely different and is still required to boot the boards that have MRC reversed engineered on.

The Librem PCH X99 uses it and the board will not boot without the blob. It is far bigger and much more dangerous than the FSP blob. The problem with the Management Engine is deeply rooted: it is a separate microcontroller embedded in the PCH and has a full network software stack, has access to DMA and other nasty things.  The firmware is signed by Intel and verified at each boot by the microcontroller, and if the firmware signature fails to verify correctly, the x86 cpu will not be allowed to boot. The bus clocks are actually configured by the ME firmware.

This would not be an issue if the microcontroller was isolated from the Internet, but it has a full network stack and can read your hard drive and memory which poses serious privacy concerns. Even though the ME is part of the platform and cannot be changed by usual methods like flashing a new firmware, it has poor security because it relies on security by obscurity which will eventually be cracked and the worst kind of rootkits could then run on them.

In an ideal world, we would need to bypass the ME firmware completely and load our own free ARC firmware that can initialize the clocks on the board.  This is nothing to do with FSP.

To make it easier, we could choose a northbridge that has been already ported from MRC to coreboot, such as the sandybridge/ivybridge northbridge.  This way FSP is not needed. But we still can’t see a way to disable the ME, there are people working on it but it’s a very very difficult problem to reverse engineer, because it uses RSA-2048 to secure it.

Intel Notes

TBD, need the complete list of blobs in the FSP and confirmation on Intel’s ability to provide proprietary source code.

Intel VGA BIOS – GPU Firmware

Intel integrated graphics is completely open source – no firmware is required.

Intel CPU Selection

Intel CPUs appear to be practically unusable without a microcode update. On the coreboot mailing list (http://www.coreboot.org/pipermail/coreboot/2013-December/076825.html, slightly abbreviated here) Ron Minnich says:

In the beginning, we had no microcode in coreboot, per the main goal: let linux do it. We just let Linux do the update. Not our problem. At some point, ca. 2005 or so, we had to let the blobs in because many of the new CPUs are *broken* without the microcode update: the microcode that comes embedded in the CPU must be updated or you’ll get some real problems, and possibly not even get through firmware.

So, sure, it’s pure to build without the microcode blob, which means in reality that you’re deciding to use the microcode blob *already embedded in the CPU*. And, on many new CPUs, the one that comes with the CPU has issues that mean you won’t get past DRAM init. And, if you do get past DRAM init and boot, you’ve got a CPU that may have subtle errors and corrupt memory.

We may be able to identify a few Intel CPUs that have no microcode updates – never say never, check in detail. However, the best information indicates that Intel does not ship CPUs with fully working microcode.