-
-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server port to ASUS KGPE-D16 #134
Comments
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. |
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? |
Supports Infineon module. |
Forgot to update : OpenBMC port was made. Need to test. |
Porting is on it's way! Actual boot trace: KGPE-D16-No_TPM.txt |
@zaolin : Any input on TPM initialization issues encountered in the above trace? Exerpt of coreboot wrongly detecting the 2.0 TPM as 1.2:
|
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). |
@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. |
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. |
@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:
|
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.
[…]
|
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:
|
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
Usage:
Limitation:
Still missing:
|
KGPE-D16 support is merged into Heads! Still missing:
|
Would that make sense? Using Qubes as a server spinner for Qubes seems like a nice and practical experiment.
The text was updated successfully, but these errors were encountered: