.png){kind=small}
Introduction
If you haven’t read the previous TrenchBoot AEM blog posts ([1], [2]) or our project plan yet, it may be a good reading to catch up on what the TrenchBoot AEM project is about.
What’s new in TrenchBoot AEM?
This phase doesn’t really add any new features visible from user’s point of view. Instead, it focused mostly on bringing the code up to current Secure Launch implementation, which was still evolving when we started the AEM project. With Secure Launch code brought up to speed, we should be able to put more effort towards upstreaming soon.
Taught by our hiccups with earlier phases, we also changed our approach to testing. Now we don’t check only if the PCRs were extended, but also whether their values are correct. Qubes OS packages, created by CI, are now used wherever possible, and manually built Xen and/or GRUB are used only for development and debugging outside of Qubes OS.
Secure Launch specification
Secure Launch specification was created as an attempt to provide a unified experience in passing configuration and other meta-data to a TrenchBoot Secure Launch entry point across all supported architectures. Latest version of the specification can be found on TrenchBoot site.
The document starts with an overview of architecture, which describes what components take part in dynamic launch, together with interactions between them. It is followed by description of Secure Launch Resource Table (SLRT), which takes majority of specification.
One very important part of SLRT called DRTM Measurements Policy describes what components have to be measured by DLME (Dynamic Launch Measured Environment, Xen in our case). The size of this entry may vary to provide flexibility for different number of components. This allowed us to properly measure more than just two of modules passed to Xen (dom0 kernel and initramfs), so previous limitation that excluded microcode and XSM has been lifted.
Addition of Multiboot2 protocol to the Secure Launch entailed new entry type for modules. This was not added to the specification yet, we’re still gathering all small fixes that can be done before next revision in this issue.
Installation
From user’s point of view the installation process is virtually the same as before. Follow instructions from the previous blog post and you’re good to go. Just remember to use binaries for v0.3, which can be downloaded from here. The same components have to be installed as before, but keep in mind that their revisions are different, so you can’t just copy and paste the instructions as they are in previous post. This shouldn’t be a problem, you don’t mindlessly run commands suggested by some random guy on the Internet in dom0 anyway, right? :)
If you’re updating from previous AEM version, keep in mind that unsealing will fail on the first boot. This is expected, and it is described in AEM README.
Testing
One additional change visible for the user is the ability to dump TPM event log.
A script doing just that is part of anti-evil-maid package. It can be run as
root in dom0 by calling sudo anti-evil-maid-dump-evt-log. Example output
obtained on HP EliteDesk 800 G2 with Intel Core i5-6500T:
|
|
To verify PCR values are correct digests from the entries can be extended using debug PCR 16 (make sure it is reset before starting!) and compared with actual values of PCR 17 and 18.
There is a bug in older ACMs (we’ve noticed it on Skylake/Kaby Lake, it may be present also on other processors from that period) that causes the first entry in the log to contain result instead of input digest. This can be worked around by taking SHA1 of
Eventof that entry, e.g. by runningecho "<hex-string of event>" | xxd -p -r | sha1sum, and using that to extend the PCR instead of whatever was logged. To the best of my knowledge, Intel never publicly acknowledged this bug, but if anyone has a trusted source that can be quoted, please add a comment about that at the bottom of the page.
Known issues
We’ve noticed few issues that we share here for full transparency:
- Bad measurement logged by ACM. This isn’t exactly something we can fix, as ACM is closed-source binary signed by Intel, and Intel won’t fix such old and no longer officially supported CPU family. What we may try to do is to catch this problem in parser, inform the user about it and print proper value.
- Xen on HP mentioned above doesn’t bring up all cores after TXT launch. This doesn’t happen on any other platform we tested. “Clean” Xen without patches applied for Qubes OS (but with AEM patches we developed) doesn’t exhibit this problem, neither does it happen if Qubes OS is started without AEM - it seems that there is some interaction between those, we’re still debugging it.
- There is no textual description of events logged in early environment, even
though that data is available as part of DRTM Measurements Policy. Passing it
to function that does the measurement and logging would require calculating
string length and
strnlen()is not available for linking in early code. - Xen doesn’t measure and log
SLAUNCH_STARTandSLAUNCH_ENDentries. These are used to mark beginning and end of measurements to not allow any software running either before or after to create entries impersonating expected components. - S3 still wasn’t tested, and probably doesn’t work, or worse: works insecurely.
Next steps
As said in the introduction, code that uses SLRT is now close enough to the final form that we can safely focus on upstreaming it. In fact, SMP bringup already has been sent to xen-devel mailing list. It is common code used by every Xen boot (on x86) so it went separately, mostly as a way to introduce ourselves before dropping relatively big new feature that a handful of people would ever use. Next sets of patches will probably target QubesOS organization on GitHub before true upstream sources. That way we will be able to get review from final users of AEM before bothering wider audience.
Next phase will bring support for AEM to AMD processors. This should make it easier, cheaper, and generally more available - for TXT you need vPro processor, but for AMD you just need any processor, starting with Athlon 64. Anything younger than 15 years should do, as long as the platform has a discrete TPM.
How you can help
By testing, of course! Install AEM, see if it performs as it should and report any encountered problem in trenchboot-issues repository.
Spreading the word is another way of helping. The more people know about AEM the better. We may not be able to test it on every possible configuration, but perhaps others have platforms that we don’t.
You can also stay updated on our project’s progress by visiting our GitHub milestones, and join our discussions in the public Matrix channel, where everyone can participate and share their thoughts.
