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:
> 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
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
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?!
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
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>
>> 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.
I like it too. Maybe we can ask users on rom-o-matic to provide neccesary
info for further project improvement
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:
> 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.
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, but that would still be better than the
current status today.
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
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
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:
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
An adversary capable of disassembling and reflashing the laptop can
circumvent the boot integrity without the user's knowledge.
External TPMs (v1.2?):
- 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
- TPM can also conditionally release secrets once a certain hash is
When using an encrypted data partition, it can be used to prevent
simple 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, then the partition cannot be
* 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, 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 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.
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) and Boot Guard:
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
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 implementing signatures verification:
Many ARM SOCs have the ability to check the signature of the first
code executing after the bootrom.
An example is documented on the USB armory wiki, for the Freescale
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 idea is to have a system that ties together the public key and a
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
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
An external chip would then have to be used. Let's call that chip HBM
(Hardware boot module).
| ^ ^
| | |
| | |
| | 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
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.
This means that the bootrom 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
The secret would be the key(or a part of it) to open the data
After changing the bootloader, to boot, the user would need to add
inside the HBM the respective public key, erasing the secret at the
Vendors could then keep the same features, but while letting users
replace their bootloader.
I'm not very confident with my knowledge on TPMs (and Boot guard).
And optionally its configuration.
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.
Currently, newer Intel hardware don't match the freedom and
Prevent hardware bricking is probably also one of
the potential reasons.
In contrast, many tablets have unsigned bootloaders.
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).
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
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
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.
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.