March 2016 - coreboot - mail.coreboot.org

Re: [coreboot] [GSoC 2016] Proposal review
by Yurii Shevtsov March 17, 2016

March 17, 2016

Hello. Three days passed, but unfortunately I haven't got any feedback on my draft yet. Although, I can see Martin Roth is watching my proposal. Also I'm still not assigned to any task. Spare me some time, please :-) Thanks in advance 2016-03-14 23:11 GMT+02:00 Yurii Shevtsov <ungetch(a)gmail.com>: > I know we haven't discussed project properly yet, and I understand my > vision of project may vary from yours. So feel free to point me on a right > way :-) > Here is the link: > > https://docs.google.com/document/d/1OWOYfKMUSZTi4tTHmGIIY27KAbM5MJVV0Ddirjp… > > I made my proposal draft private. As for now I shared it with Ron Minnich > and Martin Roth. If you part of a GSoC commission, I'll add you too (head > to the doc link). > > Unfortunately, I haven't submitted any patch yet. Please, assign me to a > task. >

1 0

tpm api merge
by Alexander Couzens March 17, 2016

March 17, 2016

Hi, I'm looking at a huge tpm merge commit. +625, -748 So the question how can we merge this? As long we don't have further testing, it's hard to decide. We won't catch all bugs. May be chromeos have a tpm testing? And also reorganize the commit into smaller ones are very hard and I think it's not the effort worthy. Because merging two apis into one is a big thing. The only other way I can imagine merge I don't know how easy it is, having 3 apis lying in the tree. The 2 "old" apis and the new merged one. Extending the new api until it's working. Can we freeze the tpm apis for now? It would give zaolin more time to fix the problems and give the reviewer also more time to look over?! Best, lynxis https://review.coreboot.org/#/c/10542/ -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Re: [coreboot] [GSoC 2016] ROM-O-Matic project
by Yurii Shevtsov March 17, 2016

March 17, 2016

2016-03-17 22:13 GMT+02:00 ron minnich <rminnich(a)gmail.com>: > > > On Thu, Mar 17, 2016 at 1:08 PM Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> > wrote: > >> >> Once we get reproducible builds, we could: >> 1) Store an (SHA) hash of images in board-status. >> 2) Make the rom-o-matic build (with the board-status configs) and >> verify(checksums) the image of a known good state. >> >> >> > > I really like this idea. I wonder if we could add additional information > for a board, derived from, say, pci tree, dmidecode, that kind of thing, > that would be used to characterize a board. > > ron > I like it too. Maybe we can ask users on rom-o-matic to provide neccesary info for further project improvement

1 0

Re: [coreboot] Introduction
by Denis 'GNUtoo' Carikli March 17, 2016

March 17, 2016

On Tue, 8 Mar 2016 22:13:47 +0000 David Parreira <davidpessoaparreira(a)gmail.com> wrote: > Do you have a specifical project that you want to work on? > Should I propose a project? Beside hardware ports, work on related projects (payloads), there is also a list of infrastructure projects here: https://www.coreboot.org/Infrastructure_Projects > I have no expirence on this area but I really would like to work with We have some resources on the wiki about that, but the learning curve is still massive. For me it was and is still true even when having a background in another other area related to low level software. Denis.

1 0

Re: [coreboot] [GSoC 2016] ROM-O-Matic project
by Denis 'GNUtoo' Carikli March 17, 2016

March 17, 2016

On Wed, 09 Mar 2016 04:24:04 +0000 ron minnich <rminnich(a)gmail.com> wrote: > yeah, we had something like this in the linuxbios days. I think you > don't want to build it on demand, but rather have a bunch of > pre-built images that are known good. Once we get reproducible builds, we could: 1) Store an (SHA) hash of images in board-status. 2) Make the rom-o-matic build (with the board-status configs) and verify(checksums) the image of a known good state. That would still not guarantee that the given image would work on every variation of a given device[1], but that would still be better than the current status today. References: ----------- [1]I'm thinking of mainboards supporting several CPU families: In that case the rom-o-matic would somehow need to inform the user about the tested configuration. RAM sizes and modules also often varies between users. Denis.

2 1

[Beginner help] Learning advices
by Toweleeeie March 17, 2016

March 17, 2016

Hi all, I'm Alberto, a budding c++ programmer. Right now I grasp the basics of c++; I'm studying with "Programming principles and practices with C++" by Stroustroup and I want to start doing something more practical, contributing to a real life project like Coreboot. I'm also studying C, as it is the lingua franca for embedded software programming. What should I study to start contribute to this particular project? Do you advise any manual or anything? Thanks to all of you

1 0

A proposal against irreversible code signing.
by Denis 'GNUtoo' Carikli March 15, 2016

March 15, 2016

Hi, Coreboot, Replicant, and other communities have some trouble with signed bootloaders/BIOS/UEFI. So would the following make sense? Here the goal is to have boot integrity while still protecting the user's freedom to modify all the software running on their hardware. The implementation should be practical enough to permit most users, to actually exercise that freedom. Note that I didn't check every fact's accuracy. Some approaches to the issue: Chromebooks: ------------ Part of the flash is made read-only to implement the root of trust. There is then a chain of trust with signatures. The user is also permitted to run the OS of their choice, and, in some case, to replace part of the boot firmware. In either cases the user is warned if the software is replaced by something not signed by the vendor. However to fully replace the boot fimrware, the users have to be knowledgeable enough to dissemble their computer to remove the write protection. An adversary capable of disassembling and reflashing the laptop can circumvent the boot integrity without the user's knowledge. External TPMs[1] (v1.2?[1]): ---------------------------- - TPM can be used to hash data (and optionally sign the hash). The hash of the next data also depends on the value of the previous hash. - TPM can also conditionally release secrets once a certain hash is attained. When using an encrypted data partition, it can be used to prevent simple[2] evil maid attacks, by verifying the integrity of the software used before opening that partition. That can be done by making each pieces of the boot chain send, to the TPM, the next piece of code that is executed (and optionally some configuration data). Once a given hash is attained, the TPM would release the secret. The secret could then be used in different ways: * As part of the key to open the partition. If the boot fimrware changes[4], then the partition cannot be opened anymore. * To display some secret picture to the user when prompting for the passphrase. This way, when the boot fimrware is changed, the secret isn't released. The users then wound (hopefully) not open the partition because they would suspect tempering. At first this sounds a good compromise, but, on older hardware[8], replacing the boot firmware carries not obligation for it to send its pieces to the TPM. It could instead send the pieces of the old boot fimrware, if it can be retrieved somehow. This way the TPM would release its secret. This is probably one of the reason[9] why the bootblock is often made read only on proprietary boot fimrwares. However we want users to be able to easily replace their boot firmware. And the boot fimrware and the TPM have to interact, because the TPM cannot interact directly with the user. External CPU: ------------- Another approach would be to make an external CPU that can interact with the user check the boot fimrware. It could for instance warn the user in some ways, if the boot fimrware hash changed, or if the public key used to verify it changed. However that only shift the problem inside that external CPU, since the user might also want to change its firmware. Internal TPM(ME)[1] and Boot Guard[1]: -------------------------------------- Here the TPM is an application inside the ME, and Boot Guard can be used to force the first piece of the boot fimrware to be sent to the TPM. Then to release the TPM secret, one would have to either prevent that, or break the TPM checksum(SHA1). The downside is that the code running inside the ME is non-free. Having the user being able to replace its fimrware would only result in shift the problem. Bootroms[5] implementing signatures verification: -------------------------------------------------- Many ARM SOCs have the ability to check the signature of the first code executing after the bootrom[5]. An example is documented on the USB armory wiki[6], for the Freescale I.MX53. The SOC vendor (or here the final user) typically fuses the hash of a public key inside the SOC. This is irreversible. It would not be realistic to expect each computer user, many non-technical, to handle their own PKI. This also includes not loosing the private key, while keeping it secure from attackers. The proposal: ------------- The idea is to have a system that ties together the public key and a secret. On such system, any user would be able to replace the boot fimrware. But to still be able to boot the user would also have to replace the public key. When that happens, the previous secret would then be automatically erased and would have to be re-added. Having storage that big inside CPU/SOCs is probbaly unpractical, and dangerous[7]. An external chip would then have to be used. Let's call that chip HBM (Hardware boot module). +------------------+ +-------------------------->|External connector| | +------------------+ | ^ ^ | | | | | | | | v | +---------------------+ | +-------+ +-----+ | | HBM |<-----(---->| | | | | +------------+--------+ | | Flash |<----->| CPU | +-->| Public Key | Secret |<-----+ | | | | +------------+--------+ +-------+ +-----+ ^ ^ ^ ^ | | | | | +----------------[Write/clear]--+ | +------------[read, Write(clears Secret)]----+ Usage: User chosen boot fimrware: ---------------------------------- The user powers the computer. The HBM then verifies the boot flash. If the signatures matches, the HBM then flips a switch that would give exclusive access of the flash to the CPU. It would also release the secret to the CPU. The secret would be an image displayed at the same time than the password prompt (used to unlock the encrypted partition). An attacker trying to attack the user might still be able to capture that image if the users uses that computer in a public space. Hopefully the reconstructed image would differ in some subtle ways that a careful user might be able to notify. If the signature doesn't match, it might notify the user trough some GPIOs connected to a red led, and/or that powers off the computer. Once the user is notified, they would have to replace the public key and the secret to get the computer boot again. The machine could be recovered by connecting an external flasher to the HBM, ideally trough an easily available external connector. The external flasher could be some common ARM Single board computer. The boot fimrware could also be replaced from the CPU running it. With this system, the user could also be able to easily delegate the firmware updates to Their favorite GNU/Linux or boot firmware distribution. To change update provider the user would then replace the public key and could add back the same secret into the HBM. Usage: Android device vendor: ----------------------------- Most Android phones have a signed bootloader[10][11]. This means that the bootrom[5] will check the bootloader's signature and refuses to boot the phone if it doesn't match. On many phones, the bootloader can be unlocked. This means that the bootloader will stop checking signatures of what runs after it. However, this doesn't mean that the phone's CPU will run the (modified) bootloader the user chose. Unlocking the bootloader will also, typically, trigger the erase of the Android data partition, and potentially other actions. With the previous proposal, implementing such requirement would still be possible: The secret would be the key(or a part of it) to open the data partition. After changing the bootloader, to boot, the user would need to add inside the HBM the respective public key, erasing the secret at the same time. Vendors could then keep the same features, but while letting users replace their bootloader. References: ----------- [1]I'm not very confident with my knowledge on TPMs (and Boot guard). [2]https://github.com/GDSSecurity/EvilAbigail/ [3]https://mjg59.dreamwidth.org/35742.html [4]And optionally its configuration. [5]A bootrom is just a fancy name for in-silicon assembly instructions that are executed first at boot. Typically this is used to implement signature verification, booting from a variety of external storage(MMC/SD, eMMC, NAND, SPI flash, etc), or loading its code from external buses(Serial, USB) and the order in which they are tried. [6]https://github.com/inversepath/usbarmory/wiki/Secure-boot [7]http://blog.invisiblethings.org/2009/06/01/more-thoughts-on-cpu-backdoors… [8]Currently, newer Intel hardware don't match the freedom and privacy requirements. [9]Prevent hardware bricking is probably also one of the potential reasons. [10]In contrast, many tablets have unsigned bootloaders. [11]On embedded devices, the bootloader often does the equivalent of coreboot and grub. The functionality of each component of the boot chain might differ between devices and SOCs(System on a chip). Denis.

1 0

GSoC: VT-d on samus
by Huimin Zhang March 14, 2016

March 14, 2016

Hi all, I am a sophomore of Computer Science and Engineering at the University of California, Merced, and I would like to propose an original project for GSoC 2016: supporting IOMMU virtualization (VT-d) on the Chromebook Pixel 2 (samus) in coreboot. Specifically, I will be targeting the LS model as that is the model that I have on hand to work with. The i7-5500U Broadwell processor and the HM97 Wildcat Point chipset of the LS model both support VT-d which means the hardware is in place. The samus is already a target of coreboot so all that’s left to do is patch coreboot to pass along the ACPI direct memory access remapping (DMAR) table which was left out presumably due to its lack of relevance to ChromeOS. This contribution would extend the functionality of both coreboot and Google’s Chromebook Pixel 2, and benefit users who run traditional Linux with virtualization on the samus such as myself and Qubes OS users. I have the sundry required for unbricking on hand and have already performed a successful recovery. For posterity, it should be noted that the Winbond BIOS chip not only lacks the traditional protruding gull wing leads, it also has too many circuit features littered around it for an SOIC-8 test clip to make contact. My workaround was to clip off all the plastic legs around the lead contacts, disassemble the test clip into two halves, and firmly hold the two halves of the clip against the chip manually. Granted, it's quite grueling and also seems to deform the tiny chip leads, but it works. Disabling verification can help shorten the flashing process. This is a project that I would like to undertake even outside of GSoC for the sake being able to use VT-d on my laptop and I would be very appreciative of any assistance or feedback regarding my proposal. I hope to delve deeper into the project towards this weekend when my spring break starts. My formal project proposal will be shared on Google Docs once it is ready. Best, Min

1 0

Re: [coreboot] How to deal with Coverity reports?
by Stefan Reinauer March 14, 2016

March 14, 2016

On 03/14/2016 04:05 PM, Julius Werner wrote: > Is our general goal just to triage or to actually fix (as in: change > code so that they disappear) all Coverity errors? I think it's a great > tool that occasionally really finds that one odd bug, but most of the > issues I've looked at so far seem to be false positives of some sort > or another (either because for some error types it really just > guesses, or because of aggressive overinterpretation of the C > standard). Some of those may be easy to fix, but others may not, and I > don't think we should sacrifice speed or readability to make a tool > happy. It would be ideal if we could just mark a certain issue that it > found as "resolved" somehow (it already seems to report everything > only once, but something more explicit with maybe a comment field > would be nice). Most issues have not even been triaged yet. I agree that a fair amount of issues are not critical, and are flagged because coverity was not designed for low level software. These issues can be classified as False Positive or Intentional, which will make them go away. Stefan

1 0

Missing Coverity reports
by Paul Menzel March 14, 2016

March 14, 2016

Dear coreboot folks, does Coverity still check the coreboot code base or have there been changes? It’d be great to get it going again and to have the errors fixed in code that is currently committed. Thanks, paul

4 4