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?

[hardestkit]

@tlaurion work on this board became abandoned. While it works with a lot of process followed correctly, and it is mostly reliable, there were some blockers that prevented this being viable for a wider user base..

1. There is an intermittent TPM issue which sometimes the coreboot will detect or wont detect the TPM at boot. Its easy to power cycle to resolve, but that should not be happening. Even with TPM debug logs enabled in coreboot, there is no obvious reason why the TPM does not show up. Just some boots its almost as if the TPM module is not plugged in. I have tried multiple motherboards, multiple CPUs and multiple TPMs (both 1.2 and 2.0) and the behavior is consistent. Some boots it just appears like no TPM is connected to the board. It is likely something lower down but I cant figure it out and those who may be able to help are probably better focused on bringing new features to coreboot and working on any security issues such as the recent SMM backport idea of yours.

2. There are several permutations of this board, as noted in later coreboot versions mainboard/asus/h61 - which will inevtiably confuse folks who want to try these out. All are branded 'P8H61-M Pro' but are wildly different. Some do not have a TPM header at all (the CM6630 type). There is also a VP8H61 variant (which hails from old ASUS OEM PC's that have been parted out) - that one does have a TPM header but only has 4x3GB/s SATA. There is also the original 'direct to customer' sale version which has a TPM header, more heatsinks and 6x Sata ports(4xGbps and 2x6Gbps). It just a bit of a confusing nightmare. The boad only goes up to 16GB RAM support too, which for a desktop nowadays is pretty poor.

3. this board uses a 4mb chip. While I do have a process for adapting the IFD to 8M layout and using coreboot config to make use of the space, its an extra bunch of steps for users to take to get the right ROM size just to fit heads/linux/coreboot and the (not fully maximized) ME (see point 4)

4. this is ultimately the biggest driver that led me to abandoning this one - all variants of the P8H61-M PRO do not run with me_cleaner on the ROM, it breaks the LPC bus and it just wont boot at all see here. However my testing found that if using the ME cleaner whitelist logic for the P8H61-M LX version and the EFFS,FCRS partitions are whitelisted in me_cleaner, then the me region can be shrunk and the system will boot. However, the problem I see here is that the whitelisted partitions are not included in measured boot. These could be modified and measured boot wont care in the slightest and TOTP/HOTP would report no change'. I found that the final nail in the coffin for pursing the P8H61-M boards.

Taken all together, it just seems like these boards have too many complexities, nuances and risks associated to be able to assure users of this projects aims.

That being said, I am working on another plan Stay tuned ;)

[tlaurion]

1- coreboot has a TPM delay option in the config. That might help, or not.

2- there should be a way, dmidecode? To clarify which exact board you are dealing with that would clarify the exact board we are talking about?

3- not sure I follow here. The coreboot config specifies a ROM image size and cbfs size. ROM size should march spi size, where cbfs needs to be calculated to fit BIOS region size of IFD. So ifd bios region should match BIOS region here, and when its the case, that BIOS region can fit some/all modules of Heads.

4- neither ME nor GBE regions are measured as of now, unfortunately. That could be possible though. Another idea here could be to lock those regions back so they cannot be written but externally.

[hardestkit]

1 - Im pretty sure I tried this. It was kinda weird like it just sometimes didnt even see the TPM. I tried ASUS branded TPMs and Foxconn. As per the first post the VP8H61 didnt work at all with the TPM despite having the header - yet i bought a different motherboard (exactly the same number and visually) and the TPM worked. I can check again, but honestly im working on a different board that would be a much better choice while being more available and more capable.

2. Its more a concern for people sourcing the boards. I had the port working with the P8H61-M Pro 'direct to consumer' board (4x 3gbs SATA, 2x 6Gbps SATA + TPM) and the 'parted out' ASUS OEM PC'baord - P8H61-M Pro VP8H61 (4x 3Gbps SATA + TPM), but obviously not with the P8H61-M Pro CM6630. I can see that even with documentation people may make mistakes and be upset if they bought the wrong thing - is it worth us saying as a project 'we support the P8H61M Pro' and then 'but not the CM6630 and also the VP8H61 is also a bit less capable and clunky' when i can focus my efforts on a board that has more features and does not have any of this confusion?

3. The P8H61M comes with a 4Mb socketed DIP-8. Coreboot needs patching to work with the 8Mb required for heads, and obviously the IFD needs modifying to the correct size. Its possible, it works, but its a bunch more steps. Again, i can focus more on a board that does not need this.

4. yep thats the only workaround - to lock the region. But as EFFS, FCRS partitions are a black box, we cannot guarantee anyone relying on this project that heads can say 'on the P8H61M Pro you will know if your ROM has changed'. I get that on other maximized roms we rely on the fact that its very unlikely that 90kb of ME is going to be useful even if it is changed, but with EFFS and FCRS partitions present in ME, there is more space we do not measure that may be useful and we just dont know. I kinda felt that was defeating the object of the whole thing, so its better to focus on a board that is happy to run with the ME reduced to just 90kb of BUP etc. Especially when the code in in the whitelisted partitions is known to do something specifically with the LPC bus on this board.

Ive already got another board on the go, its working and has way more feautres, im just trying to solve a graphics corruption issue when GRUB is loaded.

[tlaurion]

@ThePlexus watch for #1398 changes and rebase/adapt for merge!
Also removed from p8h61m-pro: @shamen123 under #692 (which user vanished)