Complete: Heads port to Desktop - Asus P8H61M Pro

[ThePlexus]

Heads runs great on my x230 and very pleased with it. That being said, i wanted a desktop/home server for same. As this board is cheap enough and of reasonable spec, I am working to port heads to this board - anyone out there doing any work on this or have this board?

Specs;
LGA1155 i3/i5/i7
1 x PCIe 2.0 x16
1 x PCIe 2.0 x16 (x1 mode)
2 x PCIe 2.0 x1
Up to 16 GB Unbuffered, non ECC RAM at 1066/1333
2x SATA 6GB/s
4x SATA 3GB/s
TPM header for Asus/Infineon 20-in-1 TPM 1.2 or 2.0
1 x PS/2 keyboard/mouse combo port so Qubes can run the USB qube
1 x DVI
1 x D-Sub VGA
1 x HDMI
1 x LAN (RJ45) Gig-E
2 x USB 3.1 Gen 1
4 x USB 2.0 (with connectors for another 6 x USB 2.0 ports on mainboard)

WARNING: Some sellers list variants like the CM6630-8 and the V-P8H61E as P8H61-M Pro. CM6630-8 do not have TPM header present. V-P8H61E does have the header present, but the TPM refused to work for me - even with the manufacturer supplied firmware. YMMV .

Required modification: Per #545 4MB SPI is too small. You will need to swap the SPI chip from a 4MB variant out to a 8 or 16MB variant, which involves modifying the flash descriptor, extracting it and letting coreboot know to use the new descriptor. I captured the general how to in #547 . W25Q32 chip was changed for W25Q128. Its a DIP8 with a push/pull socket, so no soldering required.

The TPM needed coreboot support on this board, so I worked this and its been merged upstream https://review.coreboot.org/c/coreboot/+/32080 however a patch is needed to backport this into 4.9. Ill submit a pull for this soon.

While im waiting for measured boot to make it upstream in coreboot, I figured I would have a play with @merge branch as noted in #515 .. With my TPM patch, so far it is booting and i get coreboot output on the serial interface. I can drop to recovery shell from serial console, but no framebuffer output to monitor as yet. Ill update this issue as i get further along.

[ThePlexus]

Good progress so far.
-Graphics now operational (igfx_off required, legacy coreboot gfx setting - no high res framebuffer)
-Heads boots and we get the 'y/n/r/u/m' boot menu
-TPM (1.2) is recognised. tpm-reset works, seal-totp and unseal-totp is working from serial console.
-Using the authenticator device with TOTP we get matching numbers.

Stuff to work on

• both PS2 and USB keyboard inoperative so far
• Key import

[ThePlexus]

Still having teething problems with the PS2 keyboard, even with dmesg showing up i8042 ports. tried i8042.reset and atkeybd.reset kernel params and no joy. really perplexing, but ill battle on.

gui-init is not my friend as it requires the framebuffer option in coreboot, which for my test combination of sandybridge cpu and coreboot4.9 does not work. so for now, generic-init will have to do.

Need to look into the kernel options more and also figure out why random is taking ~60 seconds to init and throw up the uninit urandom read warnings. totp unseal works on the monitor now, numbers match the authenticator device.

Thanks very much to @merge for the re-basing of the patches against CB 4.9.

Looks like its pretty much there - PS2 keyboard and random init to sort out and that should be it. Heres a snapshot

[ThePlexus]

@tlaurion do you have PS2 keyboards working under KGPE-D16 ? Seems someone has similar problem to me, but when using KGPE-D16

https://mail.coreboot.org/pipermail/coreboot/2018-May/086801.html

he uses seaBIOS payload and gets same as me;

Got ps2 nak (status=51)

I removed my previous post.. seems i was mistaken, there appears no way for the Ps2 keyboard to work currently.

[ThePlexus]

Solution the PS/2 problem was actually to tell coreboot to not init the ps2 port and leave it to the payload. Coreboot devicetree was correctly setup for ps2 init but for some reason it prevents the payload from doing so.

Can now use a PS2 keyboard, TPM working, TOTP working and verifying, Qubes installed, /boot signed.

The port is now done and working using the @merge branch with CB 4.9.

I guess I will try to automate the mods with patches and submit them against the merge 4.9 branch, as this board will not work at all against the 4.8 branch, sadly.

with 4.10 coming soon, are we going to skip using 4.9? #500

[merge]

My 4.9 branch basically needs the few mentioned missing patches ported. help needed. And thanks for testing it! By then I assume 4.10 to be released but most probably rebasing onto 4.10 will be easy. so I think we'll skip 4.9.

We should separate our tasks of updating coreboot and dropping our measured boot in favour of the upstream vboot implementation. This shouldn't delay things nor confuse us.

I think it would be important to update to coreboot 4.10 very soon after it's available. I'll try to come up with a plan during next week and hope to have support :)

[tlaurion]

@merge I'll jump in. This needs to move forward.

[ThePlexus]

Thanks both - waiting for 4.10 to be part of Heads does make life easier for me, as I wont need to do patches to cover the TPM changes for this board - my changes for TPM enabling are not in 4.9 but will be in 4.10. It would mean that this board will be able to be supported with just the board file and coreboot/linux config files (as well as a little bit of user required magic to move the flash from 4Mb to 16Mb)

looking forward to 4.10 and seeing heads have its first home-level desktop board available!

[ThePlexus]

[tlaurion]

@shamen123

Note that the KGPE-D16 is a AMD based, natively initialized, binary blob, FSP and Intel ME free workstation/server platform :)

u-bmc needs to be ported to the iKVM chip (supported by openbmc, flashable from heads), TPM v2 user tools still needs to be ported to it, but else then that, KGPE-D16 and kcma-d8 platforms are the last known blob free, QubesOS 4.0 compatible platforms out there, while also being RYF certified.

Sent from my Galaxy S3 using FastHub-Libre

[ThePlexus]

@tlaurion

Note that the KGPE-D16 is a AMD based, natively initialized, binary blob, FSP and Intel ME free workstation/server platform :)

yes, its something that is probably more preferred for power users or those shy of intel (though, I'm yet to be convinced AMD is not plagued with similar intel issues and PSP is just the tip of the iceberg).

Selection of board also depends on price point and use case - P8H61-M pro for 60 GBP or a KGPE-D16 for near 400 GBP puts one as power user and the other as affordable privacy/security/attestation conscious desktop/home server users on tight budgets - for example; students, those in countries where high end boards are hard to come by or even folks on low incomes. The KGPE-D16 server/workstation is definitely more on the power user high end.

The P8H61-M pro can be nearly as de-blobbed as the x2X0 series when it comes to ME, certainly most tables and ive written a small tool to play with VSCC which, rumour has it, will also disable ME
(corna/me_cleaner#80 ). Its a cost vs risk/threat model assessment that I made myself when selecting to port this board to run a small home server for me.

So yep I agree with you - power workstation users would definitely be better off with the KGPE-D16. Those privacy/security/attestation conscious users on a tight budget who need heads on the desktop or home server - and are willing to accept a similar level of blob risk as heads on X220/230 - may find the P8H61-M pro model aligns with acceptable risk to their threat model, budget and use cases.

[tlaurion]

@shamen123 : update?

[hardestkit]

@tlaurion This is pretty much all done. Just finishing off the scripting for ME and IFD extraction.there have been some pitfalls around correctly identifying the board as many carry this name, but there are several variants.

[tlaurion]

@hardestkit PR?