Server port to ASUS KGPE-D16

[tlaurion]

Would that make sense? Using Qubes as a server spinner for Qubes seems like a nice and practical experiment.

1. Having a server that would validate its status prior to passphrase validation (local or even remote openbmc).
2. It is possible to use Qubes in server mode (kinda)
3. It is possible to have 16mb of flash on that beast, that can boot libreboot/coreboot without binary blobs.

[osresearch]

This is a very good idea. There is the beginning of a server build of heads in the moc branch to support the Mass Open Cloud project's end-to-end attested design.

[osresearch]

Does it have a TPM? That is a fairly hard requirement for measured boot and the attestation system.

[tlaurion]

Does it have a TPM? That is a fairly hard requirement for measured boot and the attestation system.

TPM YES With Owner Controlled CRTM - TPM is an option addon module

@osresearch : It has a 20-1 header, which normally support TGC 1.2, but there is some TPM enforcing TGC 2.0 for 20-1 pins headers. Any advice on what might be supported best?

[tlaurion]

Supports Infineon module. http://anzwix.com/a/Coreboot/Mbasuskgped16AddTPMSupport

[tlaurion]

Forgot to update : OpenBMC port was made. Need to test. https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php

[tlaurion]

@flammit @osresearch

Porting is on it's way! Heads boots, but the TPM is wrongly detected as a version 1.2 instead of 2.0 resulting in ownership being impossible. Investigating. This branch includes RaptorEngineer's flashrom patches so that OpenBMC can be flashed from within Heads.

Actual boot trace: KGPE-D16-No_TPM.txt

[tlaurion]

@zaolin : Any input on TPM initialization issues encountered in the above trace?

Exerpt of coreboot wrongly detecting the 2.0 TPM as 1.2:

TPM initialization. TPM: Init Found TPM SLB9660 TT 1.2 by Infineon TPM: Open TPM: Startup TPM: command 0x99 returned 0x1e TPM: Error code 0x1e.

[osresearch]

This is great news. Glad to hear that progress is being made on the KGPE-D16.

Regarding TPM 2.0, we really need to figure out the best way to work with them. Issue #287 begins to address it, but we'll also need to find a lightweight library that works well with it (and decide if we want to support fTPM systems).

[paulmenzel]

@tlaurion, please bring the issue up on the coreboot mailing list or submit an issue to the coreboot bug tracker with your config, the commit hash and the full boot log.

[paulmenzel]

Also, as far as I understood the Linux TPM folks, the Linux kernel should be able to work around broken firmware and set up the TPM by itself. If not, please try with latest Linux master, and report an issue to the Linux kernel TPM folks.

[tlaurion]

@paulmenzel: the thing is that we want TPM being initialised and used to measure romstage and ramstage BEFORE Linux enters fully in play.

This patch resolves the issue of SLB9665 TPM2.0 being detected and initialized as a SLB9660 TPM1.2.

Here is my patch against flammit's heads' coreboot 4.7, and my branch, missing proper TPM2.0 tools to use the initialized TPM.

Boot log exerpt:

lpc_tpm: Read reg 0xf00 returns 0x1a15d1 Found TPM SLB9665 TT 2.0 by Infineon TPM: Open

[paulmenzel]

On 01/31/18 17:40, tlaurion wrote:

@paulmenzel: the thing is that we want TPM being initialised and used to measure romstage and ramstage BEFORE Linux enters fully in play.

@tlaurion, sorry for the misunderstanding. I am aware of that. Checking if Linux is able to correctly set it up was just to make sure that it is working in the first place.

[…]

[tlaurion]

Work continues here.

From there, Heads boots, initializes SL9665 TPM 2.0 chipset, but usage of TPM doesn't work, since no libraries included do support 2.0. So TPM support in heads is there but unused for the moment.

Patch set includes RaptorEngineering's flashrom patches to flash openbmc from within heads. It also contains coreboot patches so that kvm chip can obtain memory access prior to releasing it to coreboot. So openbmc works, permits internal flashing (updates) and updates of kgpe-d16 heads updates both from within heads.

Missing:

• TPM2.0 toolset to properly acquire, measure and attest system integrity.
• Working remote console to have heads attestation through OpenBMC once TPM2 is implemented.
• Working Xen boot console parameters to interface properly with OpenBMC so system ttyS0 and ttyS1 can interact. That would permit to SSH into the OpenBMC interact with Qubes dom0 from there.
• User's GPG keys flashed into a seperate CBFS partition, so reproducible build images could be downloaded from verified build servers on the internet, instead of needing to be produced from user's own build-system with integrated keys.
• Xen patches to properly support no-real-boot option should be upstreamed into Xen/Qubes. As a result, Xen/Qubes upgrades would'nt need to be incorporated into the firmware like it is the case now, reducing the lifespan of the motherboard soldered SPI flash chips. This is a lot to ask from users to maintain updated heads roms images in check with Qubes issued QSB. Heads upgrades should happen rarely, only when heads related security updates or desired features updates needs to be applied.

• Revive Qubes Network Server to support new qubesadmin API and HVM, so that Qubes Firewall permits "from-" rules and permit the exposition of specified qubes to the external world.

  make CONFIG=config/kgpe-d16-generic.config -j4 sha256sum kgpe-d16.rom 0d1f6f20b12026b7f20a33a1930957c9e3ecc539384401426e88986a5d32bab3 kgpe-d16.rom

[tlaurion]

Pull request

KGPE-D16 is now officially supported by Heads! This workstation/server board supports Qubes perfectly (HVM/IOMMU/HAP/SLAT/TPM/Remapping)! A RYF server board, serving as a base for reasonably secure computing. Note the TPM2 support is still missing from a toolset perspective.

Based on flammit's modifications made atop of this branch

• Ported to the new build system. Building the kgpe-d16 image is made by make BOARD=kgpe-d16
• Reduced the coreboot patches needed to the minimum, permitting KVM (SMBs) chip to boot (IKVM4 and others).
• Reduced flashrom patches to the bare minimal, permitting KVM chip to be flashed from within heads.
• Xen boots from multiboot grub generated configuration. No more firmware updates every time Qubes issues a QSB! You just have to sign new configuration!

Usage:

• Fist flash heads externally on a W25Q128FVSG SOP8 chip soldered on top of a SOP8 SO8 SOIC8 TO DIP8 adapter through an EEPROM CH341A flasher, supported by flashrom.
• Flammit submitted dropbear support into heads, so it is possible to interact with heads externally from SSH or by console through an USB to serial adapter (RS232 RS-232 Female Serial to USB 2.0 Cable Adapter)
• The system boots without outputting console to the vga graphic card until the system setups it's own console (both coreboot, heads and password output are sent to serial console and KVM). Connect to the KVM chip through SSH, which gets it's IP from DHCP, or from the static IP setuped in board configuration if desired. I connect to the system from serial console with screen /dev/ttyS0 115200. Disconnect and kill screen session with ctrl-a ctrl-\
• Flashing heads update firmwares is done through flashrom-kgpe-d16.sh /media/coreboot.rom
• Qubes disk password is asked through OpenBMC console/serial console.

Limitation:

• It is currently impossible to reflash the kvm chip from within the kvm. It's possible to do it from the physical serial port console or dropbear ssh connection opened from heads. I prefer to do it from a serial to USB connection from my Qubes laptop through sudo minicom -D /dev/ttyUSB0 then flashrom-kgpe-d16-openbmc.sh /media/flash-asus-20180122172732. Do not forget to turn off REST API access and to change default SSH password when building OpenBMC

Still missing:

• TPM2.0 toolset to properly acquire, measure and attest system integrity. EDIT: as of coreboot 4.9, VBOOT was meged upstream (what's up, measured boot???). TODO!
• User's GPG keys flashed into a seperate CBFS partition, so reproducible build images could be downloaded from verified build servers on the internet, instead of needing to be produced from user's own build-system with integrated keys.
• Revive Qubes Network Server to support new qubesadmin API and HVM, so that Qubes Firewall permits "from-" rules and permit the exposition of specified qubes to the external world.

---

make BOARD=kgpe-d16 -j4

[tlaurion]

@osresearch https://github.com/osresearch/heads/pull/335

[tlaurion]

KGPE-D16 support is merged into Heads!

Still missing:

• Port for VBOOT support so that trusted boot is supported with multiple firmware copies for validation (we have 16mb of flash so no space constraints.) Patchset is available here
• User's GPG keys flashed into a seperate CBFS partition, so reproducible build images could be downloaded from verified build servers on the internet, instead of needing to be produced from user's own build-system to integrate signing keys. WIP here
• Revive Qubes Network Server to support new qubesadmin API and HVM, so that Qubes Firewall permits "from-" rules and permit the exposition of specified qubes to the external world.