[coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)

Lil Evil Lil_Evil at gmx.de
Mon Sep 3 08:34:42 CEST 2018

Hi John,

I am the original poster of the thread you have quoted. all, apologies for the html formatted mail from my webmailer...
Great to see that I am not alone with my endeavor. However, due to other projects and lack of time, I have put this project temporarily on hold.
I have flashed a couple of coreboot trials, but the machine just spins up the fan in various patterns. Debug via serial console didn't work in this early stage. Getting some output there would be a great step ahead since I don't see any other debug option on this non-dev board.

regarding BootGuard:
I dont think bootguard is enforced, but its a while since I looked into the guts how this is acutally working.
However, I have patched my BIOS to include updated microcode, disabled ME and enabled all configuration options in the AMI bios. 
As a side effect I got an menuentry to enable secure boot and tinker with the key management, which I have not touched so far.
But based on the modifications I have done, I am pretty sure this shouldnt be an issue.

regarding FSP:
the Qotom board is very close to the intel dev board mentioned in my initial post and there are outdated coreboot patches under intel NDA that I couldnt get my hands on.
There is actually support for thie board in coreboot and you can get the FSP from intel's website, but coreboot is missing the FSP integration for those.
For FSP support the most probable option is to extract those from the firmware updates of google images, which I haven't started as I am tight up in other projects at the moment.

Let me know how I can best support your efforts

Gesendet: Samstag, 01. September 2018 um 21:01 Uhr
Von: "John Keates" <john at johnkeates.com>
An: "Nico Huber" <nico.huber at secunet.com>
Cc: coreboot <coreboot at coreboot.org>
Betreff: Re: [coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)
> On 31 Aug 2018, at 12:07, Nico Huber <nico.huber at secunet.com> wrote:
> Hi John,
> Am 29.08.18 um 04:02 schrieb John Keates:
>> Thank you for your reply! Sadly, Boot Guard is enabled in Verified Boot
>> mode. I’ll ask if Qotom can spin up a batch without any public key
>> burned into the CPU, or perhaps share the private key. (which is
>> obviously unlikely — but one can try)
> there are other alternatives; BootGuard has not a single key but a
> key hierarchy (probably for more profitable licensing schemes). So
> you could try to get your own certificate signed by Qotom. But...
> I can only advice against using BootGuard at all. If you don't have
> one, you'd be looking forward to an NDA with Intel*. Also, you'd have
> to integrate Intel's BootGuard ACM (piece of software that runs be-
> fore host firmware) into your coreboot image and might also have to
> adapt the early boot process of coreboot itself.

I thought the ACM was part of the ME or part of the Microcode itself, but I can be wrong.
>From what I’ve read, the CPU has the hash of a public key burned in using fuses, but that can only be done during manufacturing with the PCH attached.
This was because the fuses are blown using the ME, and the ME has control over the first address the CPU will start executing code from. So the CPU has some minimal code besides the microcode, both is signed by Intel. That code is also used to verify with the ME that the SPI flash has signed contents and because the check is done super early, only the result is taken, not the action that might follow from the result; so good signature/bad signature only stops the CPU if the ME is active and a (signed) Boot Guard policy exists to do anything about this.
That is why the exploit with the older Gigabyte motherboards worked where you remove the BootGuard DXE (or was it a PEI module?) and then the Boot Guard init still works and lets the CPU run, but the follow-up (halting/continuing) is never executed.
The same was with a TXE bug where you can drop the ME into debug mode and access it’s JTAG via USB3, which can also be replaced in existing firmwares. When using JTAG, you can store permanent changes in the ME firmware using the ME CPU itself to disable Boot Guard pre-flash and also-post flash.

Another thing is the manufacturing mode PCH hard strap which puts the ME in insecure/BUP only mode, but I haven’t found any reference to what that does to Boot Guard. It would be fine for me if that disables Boot Guard follow-up (it still runs the init checks), because I can permanently bridge the ME mode pads to keep it in manufacturing mode. (this board has in fact two options, one is ME1 which is a jumper, and puts it in Jumper Security Override mode, another is a GPOP33 pin strap which either does ‘more’ or something similar.

I suppose I could check this by flipping a few bits in the SPI flash and checking if it still boots, and then pull the jumper and check again.

> About the port itself. There is another pitfall: Intel FSP for Broad-
> well is not integrated into upstream coreboot. What is integrated are
> Google's blobs that do about the same as FSP but seem to be only licen-
> sable as part of Chromebooks. IANAL, but I assume you could get into
> trouble if you'd sell these blobs as part of your own product (not sure
> if you want to sell anything). If you just want to use it in-house, that
> might be possible, but again IANAL. (Welcome to the blob mess, btw.)
> The alternative (with a much better license situation now) would be to
> use Intel FSP. It does exist for Broadwell, it's "just" not integrated
> upstream.

So first try, I’d have to use google blobs just to get it running (is that that Purism does as well?),
and when I get that running I can try the bare Intel FSP instead. I did know about the license changes, that was good news indeed (much more liberal and easier to interpret).
I’m probably not going to publicly sell the stuff (but I will share it for free), so the commercial part and distribution aspect won’t affect me there.

> And some comments to your original mail:
>> - gpio.h is probably depending on the PCH used? Seems to be generic for
>> this PCH as well
> No, GPIO configuration is not generic. Never use the GPIO configuration
> of another board! You might provoke short-circuits (I guess the PCH is
> protected, but you never know what you break on the other side).
> If you have another already working (reference) firmware for your board
> (it seems so) you can dump the GPIO settings using `inteltool`.

I figured as much; I did dump all of the current data I could using the various tools, It’s running Aptio UEFI in practically template mode with very little changes from the demo board vs. this production board.

>> - romstage.c initialises the GPIOs does some PEI data copy/memset and
>> then romstage_common (which probably is around or before the CAR stage?)
> This code runs with CAR enabled (most C code before ramstage does). The
> PEI data is passed to the Google blob. The GPIO config and what happens
> in `romstage.c` are the most crucial parts to get your board booting.
> Alas, I can't tell you much about PEI data for Broadwell. Some settings
> are board specific, e.g. memory configuration. You have to figure the
> correct settings for your board (some questions may be answered by its
> schematics).

Ah, so the PEI data I probably have to extract from the existing firmware and pass that to Google’s blobs to make it work. The memory configuration/training data is regenerated at first boot AFAIK, so as long as the Google blob or the standard Intel FSP does that, I should be fine.

> Nico
> * Well, I have to admit, an NDA has become useful anyway when porting
> coreboot. Mostly because Intel doesn't document what they are doing
> to coreboot.
> <0xBD56B4A4138B3CE3.asc>--
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

I think I’ll do some more experiments since it’s a good starter project to learn from for me, even it in the end I can’t get past Boot Guard, I’ll still have more knowledge than I did before. At that point I’ll probably move to ARM based boards anyway, unless I can by the U-series CPU’s myself from a shady vendor without any blown fuses, I do have a reball & SMT rework lab nearby where they have the equipment, steel stencils, paste and experience to replace SoC’s, GPU’s, CPU’s and the likes. As long as they can program a heating curve for this Intel part it should be fine, and as far as I know, they can X-Ray larger BGA’s as well, so checking the solder joint status on the balls should be OK. This is a stretch (and a somewhat expensive hobby project at that point), but could be fun nonetheless.

coreboot mailing list: coreboot at coreboot.org

More information about the coreboot mailing list