[GSoC-2015] Introduction – Qemu Support for ARM64


A new post after a long time. I’ll introduce myself again for the benefit of (few? :P) faded memories. I am Naman, a senior year undergraduate from India. I worked on developing alternate resource-efficient CBFS access patterns for ARM SoCs as a part of GSoC-2014. I am fortunate enough to engage as a GSoC student for coreboot this year too. I have had a busy semester but finally, as the summers arrive, I look forward to dive into the riveting world of coreboot hacking!

This summer I would be working to introduce a qemu target for arm64 architecture supporting coreboot. Currently, In order to work on aarch64, users require to have suitable hardware. This project intends to clear away this constraint. We have a growing aarch64 support with the tegra132 port, but no support for arm64 in emulation. Having a qemu target might be helpful for many projects which aim to arm64 work.

Continue reading [GSoC-2015] Introduction – Qemu Support for ARM64

GSoC 2015 Introduction – Nicky Sielicki

Hey coreboot community!

My name is Nicky Sielicki. I’m one of our Google Summer of Code 2015 participants. I’m a sophomore, err– I guess now I’m a junior, at the University of Wisconsin. You can read personal details about me at nicky.io, or maybe get to know me– I’m n1cky on freenode! Come say hello.

I’ve been hanging around the coreboot community for about 6 months or so after learning about coreboot from a 2008 GoogleTechTalks video about coreboot and why it’s awesome. I purchased a chromebook in hopes of playing around with coreboot and learning something. Over my winter break, I spent a lot of time reading, flashing unsuccessfully, and understanding more about coreboot.

Continue reading GSoC 2015 Introduction – Nicky Sielicki

On coreboot leadership…

Dear coreboot community!

I want to wholeheartedly thank every single one of you, who has contributed code to the coreboot project, reviewed code, improved our documentation in the wiki, or has contributed to the project by other means. You all have helped create a truly great project.

In 2014 alone, more coreboot devices have shipped than in all previous years combined! Since the start of coreboot v2 in 2003, 345 contributors have put over 12 thousand commits, an estimated effort of 457 years (COCOMO model) into the project. Since 2010, we have added support for all new Intel mobile and AMD R and G series processors. In the last year alone, we have added support for ARM/ARM64 SOCs from 7 vendors and, support for the MIPS and RISC-V architecture.

Continue reading On coreboot leadership…

coreboot GSOC 2015 projects

Welcome the coreboot GSOC 2015 students!

Łukasz Dmitrowski – End user flash tool

lynxislazus – H8S EC firmware

Naman – Qemu Support for ARM64 Architecture

n1cky –  Improve/automate reporting and testing


A special thanks to this years mentors: adurbin, furquan, martinr, carldani, stepan, pgeorgi, rminnich, ruik, stefanct, and carebear!

coreboot GSoC 2015

coreboot has been accepted as a mentoring organization for GSoC 2015! We are accepting student applications for coreboot, flashrom, and SerialICE projects.

Students:  Welcome! Please review the coreboot GSoC page and Project Ideas page. Student applications formally open on 16 March at 19:00 UTC.

Mentors:  Please signup in Melange and request to join the coreboot project. You must signup for 2015, even if you already have a Melange account. You may also find the GSoC Mentor Guide helpful.

Community:  Please recruit and welcome prospective students to the organization. You may provide ideas on the Projects Page.

The truth about Purism: Why Librem is not the same as libre


Purism Librem is an interesting project which promises to produce a completely libre laptop, designed to respect the user’s privacy and the user’s rights. The indivduals behind the project seem so confident as to “promise that a Purism system and all its components will be free according to the strictest of guidelines set forth by the Free Software Foundation’s Free Software Definition.” Can they deliver on this bold claim?

I first heard about Purism Librem sometime last October, when someone on #coreboot posted a link to Purism’s ideas/ideology page. It promised a fully libre system, from the ground up, with a high emphasis on libre firmware.

I only glanced over that page quickly before dismissing it as another over-ambitious and mis-informed project. There was no way that the Intel CPU and chipset they wanted could run libre, given Intel’s tight grip on the low level boot process. Coupled with their desire to include an Nvidia GPU — another high-profile offender in the libre software world — their ideas looked doomed.

The first red flag was that we, the coreboot hackers, were never contacted by Purism about what it would take to get such a design up and running on the firmware side. We could have immediately told them that there are major pieces of the initialization path for their CPU which were missing source. That is, they were only available as blobs.

The possibility of reverse engineering those blobs existed at the time. Although that takes a lot of effort, we’ve done it numerous times before. But they never asked. Had they done so, we would have also told them about another major offender. That’s the microcontroller in the chipset, which needs a signed firmware binary. By “signed” I mean a state-of-the art cryptographic verification mechanism. The chipset will refuse to run any firmware unless it was signed by a secret key held deep within Intel’s most secure dungeons. In short, this blob isn’t going away.

It was obvious to me from those first versions of Librem’s web page that the designers behind it had no idea about the binary situation. My impression was that they never contacted knowledgeable parties about it. They were reinventing the wheel and they were doomed to fail.

But that wasn’t to be. A month or so later, the subject popped up again on #coreboot. This time, they were considering crowd-funding. The information they provided via their website has changed as well. They were now claiming to be working with Intel about releasing source code for the early initialization blobs, and talking about disabling the chipset microcontroller entirely.

That sounded like a reasonable plan, with only one deadly fault: Intel doesn’t release this type of source code, and the Intel decision-makers do not talk with low-volume customers directly. Not even Google could get the source code out of Intel after shipping millions of Intel Chromebooks. The few hundred units that Purism was planning to build was definitely not going to cut it.

By that point, I made up my mind that the people behind Purism were either naive, or full of it. Deep in my heart, I wanted them to succeed, and I wanted to personally congratulate them for said success. I’m a coreboot developer; I know how this business rolls. I can make your firmware email me a daily digest of your passwords and Facebook activity, and you wouldn’t even know about it. I know what I’m talking about.

Fast-forward to the middle of January. Librem’s crowd-funding campaign had been extended from December to the end of January. A lot of new information also appeared on their web pages. Besides a quote from Richard Stallman, suggesting the FSF endorses their project, their campaign page was filled with buzz-words that seemed to have come straight out of Stallman’s most iconic speeches. The claim was that Librem is “designed to respect your privacy”.

There was also a graphic representation of the software stack. A green square meant libre, while a white square meant closed. There was so much green on the reverse pyramid of the graph, that it was too easy to miss the two or three white squares at the base. They were the platform firmware. That’s the part that emails me your passwords without any of the green dots above it being aware.

Finally, by January 22, a ZDNet article appeared which confirmed what I had predicted all along: that Librem will ship with proprietary firmware. That’s announcement came just a week shy of the crowd-funding campaign drawing to a close. With proprietary firmware, Librem is just as free as any other laptop on the market with GNU/Linux. Or in other words, it’s not any more free. It is certainly not libre.

So at the end of the day, Librem is bringing nothing new to the market. Laptops with libre operating systems have existed for decades. The only real innovators in this area have been Google and GluGlug. Google ships partially free firmware, although insufficiently libre to be able to provide the “respect your privacy” guarantee. GluGlug can make this claim, and it ships laptops with fully libre firmware. The downside of GluGlug is that it’s an aftermarket add-on. GluGlug and Google have been in business far longer than Purism. So, what has Purism brought in that’s new and exciting and libre? Nothing.

Intel Boot Guard

So some innocent post on the coreboot mailing list managed to make some waves.

The problem they try to solve…

Intel Boot Guard is the latest effort in a long series by Intel and others to allow computers to provide some reliable information about the state a computer is in. They're working on int since at least 2003, with projects and trade groups named Palladium, TCPA, and now TCG, and some of them faced scrutiny in the past already because the freedom of computing was deemed under attack (partly realistic, but with some hyperbole). The scheme they developed ultimately requires having a chip in system that keeps track of the system state and is able to keep secrets from the main CPU until it proves that the system is in a safe state, called TPM (short for Trusted Platform Module). From the beginning the TPM was designed as a passive component: Some other part of the system needs to update the TPM's view of the platform, the TPM is not able to lock down any component in the system except access to its own memory. The TPM consists of some way to keep track of the system state, some non-volatile memory (for the "secrets"), a way to bind secrets to system states, and it also provides some cryptographic operations - among them: creating RSA keypairs, and working with them. One major design issue is where the trust is rooted in: The first verification of signatures happens by code on the CPU, so if you are able to intercept that and replace it with your own, it's trivial to emulate a "properly" booted system (by just sending the right values to the TPM). Moving that issue ever earlier in the boot process, the last frontier is eventually the bootblock, the part of the firmware that contains the first instructions executed by the CPU: Since it comes first, it verifies the part that comes after it, which again verifies its successor, and so on. Analogous to a proof by induction, the entire system state remains well-known as long as the first component tests the next component, and every other component does likewise. But if you can't trust the bootblock to send a truthful state into the TPM, you have already lost. Enter Boot Guard: It allows the hardware vendor to lock down the boot block so the machine only starts if the code stored there matches a key they wrote into the computer.

… and its very own problems

The main grief with this approach is that this key can't be rewritten once it is in. So when the hardware vendor (say Lenovo) sets this key, they are the only ones that can provide firmware to the machine, even if the owner of the machine wants something else. In combination with the complexity of UEFI, which commonly includes a network stack (and thus the capability to communicate with the world) and the ability to load and execute code (eg. through the net), some people are uncomfortable with that prospect. Others just want the ability to replace all code on a system, including firmware, as a matter of principle - and since they own their machines, I find it really hard to argue that they shouldn't be able to.

There's more to it: Verified Boot vs. Measured Boot

But this isn't the whole story to Intel's Boot Guard. The option of installing a key is what Intel refers to as "Verified Boot". It's described in some short words on their product brief for these CPUs. That document also talks about another mode, "Measured Boot". In this mode, Boot Guard creates a hash over the bootblock and sends it off to the TPM. The value is stored in one of TPM's plenty registers, and in particular in a register that isn't writable by code running on the CPU (there's some circuitry to make sure of that). This is supposed to prevent replay attacks in which it would be possible to fake a certain Boot Guard state if it's ever possible for an attacker to disable Boot Guard altogether.

User friendly security, powered by Boot Guard

Since the TPM is able to bind data it stores to those registers, it's possible to verify the system state against a key stored in the TPM that is bound against a known good state: In the factory, have the TPM create a keypair, and bind it against the bootblock that is installed. Export the public part of the key (the TPM won't relinquish the private one, so this operation is safe). When trying to assert if the system is still in a good state, encrypt a random value (nonce) with the public key, and send it to the system to test. If it can decrypt the value and send it back, the state is known, and everything is fine. This could be a measure for Windows to employ on a Domain login, to assert that the system wasn't tampered with. Or the Windows Account / Store / Update so it can report suspect events (you already have to register the machine with Microsoft when using Windows, so let's use it for something user-friendly). Or bind the encryption key for the disk against that state, so the data is only readable in that computer with that firmware. (Since TPM crypto is so slow, this is somewhat more involved, but conceptually that's what can be done with it) A user wanting to install their own firmware (including bootblock), will face loss of access to an encrypted disk that is bound to the bootblock in this way, and to a Domain that does this verification. From a security perspective, both are desirable. But they can use Boot Guard with their own TPM state, and encrypt the disk with their own secret stored within that chip. With "Verified Mode", overwriting the firmware just transforms their computer into a nice, expensive, dead brick.

So what went wrong?

The issue isn't that Intel added Boot Guard to their platform. It's that Intel provides the Verified Boot mode. Had they not done that, the effort would be universally lauded as a technology that improves the security of their users (and without ripping holes in their security fabric like Intel TXT did). But as is, as Matthew Garrett states, "vendors are forced to choose between security and freedom". And that's an exercise most vendors routinely fail to do properly. So Intel, please: Protect the vendors from themselves, and your users from the vendors between yourself and your users, and do the right thing. Drop Verified Boot in future chipsets, and discourage vendors from using it now.

Request for Participation: coreboot consortium for business

We want to make coreboot more accessible and usable for businesses. In order to coordinate efforts, we plan to create a business organization (a.k.a. a coreboot consortium) that helps commercial players out in the field to become a part of the coreboot community, share marketing materials, participate in working groups, and other efforts to promote the use of coreboot in the market place and be successful with coreboot based solutions.

If you work for an organization that is using coreboot, developing coreboot, or is just interested in coreboot, please help us learn about your needs and wishes and fill out the following form: http://goo.gl/glhNh5

coreboot Code of Conduct

coreboot has grown and matured a lot in the last few years and we have many new contributors and users. This growth has been something I have been thinking about for some time. I often ask myself what makes a good community? How does our community grow and flourish? How do we get new contributors and new students for GSOC. How can I contribute to growing our community?  These questions were on my mind as I attended the GSOC reunion in San Jose last fall and again later at the coreboot meetup in Prague. Discussions at both events helped shape my ideas, but GSOC reunion had some key elements to shaping a good community.

A reoccurring topic at GSOC gatherings is how to  expand project communities, keeping students engaged after GSOC, and how to get new students and contributors involved with projects. Normally, these discussions are among mentors, who are well entrenched in the FLOSS culture, are experienced developers, and have developed strong relationships within their project. Unlike previous mentor summits, the GSOC reunion was open to past students and mentors to attend, which brought a different perspective. Many of the students  were not involved in the projects after GSOC and we wanted to know why. This was an opportunity to hear from students about what worked for them and what didn’t work. Most of the students I met still used lots of open source software, but there were a number of reasons that they no longer developed on their GSOC project. Some students lost interest in the project, but still developed on other projects. Some students got jobs that didn’t deal with open source, but would do it again given the opportunity. Finally, there were some students (and mentors) that said that they didn’t like working in open source, that they were mistreated, forced or flamed out, or never felt welcome and appreciated. It is the last group that I wanted to make a difference in.

While most developers don’t experience something as terrible as the harassment that happened in the context of Gamergate or other terrible behavior documented at technical and open source conferences the last several years, it does indicate that there is a problem in our open source communities. This terrible behavior online and offline is unacceptable.  You shouldn’t be required to have a thick skin to develop open source. It should be a collaborative, not combative environment. We can’t lose valuable contributors because they felt uncomfortable or unwanted. A few mentors of large communities have had to deal with some really ugly incidents  (I’m trying to recall, but I think it was folks from Debian and Ubuntu among others) and they provided some great advice. The first was that mature communities should have some rules for behavior.  The second, and maybe more important, is that community members must point out when someone is behaving poorly. I felt that these were important point and started to consider how to make coreboot a more safe and welcoming place.

Typically, harassment, trolling, flaming, etc  is not a problem in the coreboot community.  We have a group that is generally friendly and helpful. We try to encourage good behavior and discourage bad behavior, but we could do more.  With a growing and maturing community we are going a step farther and describing what is unacceptable within our community with the coreboot Code of Conduct. It is a simple and straight forward statement about what we expect from out community members. The code of conduct is based on the Citizen Code of Conduct and similar documents in the open source community. Feel free to comment and provide feedback either publicly or privately.  Please note that this isn’t directed at anyone in particular or for a specific instance. It is part of “growing up” as an active and maturing community.