docs/meeting-minutes: Add notes from January TrenchBoot AEM meeting #22
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| title: TrenchBoot Meeting Minutes | ||
| nav: | ||
| - ... |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| ## Attendees | ||
|
|
||
| - Daniel P. Smith (Apertus Solutions) | ||
| - Andrew Cooper (Citrix) | ||
| - Krystian Hebel (3mdeb) | ||
| - Michał Żygowski (3mdeb) | ||
|
|
||
| ## Agenda | ||
|
|
||
| - Review the current state of TrenchBoot boot protocol being upstreamed to GRUB | ||
| and Linux kernel | ||
| - Discuss the scope of the work needed to align Qubes OS Anti Evil Maid | ||
| solution based on TrenchBoot with the most recent boot protocol version | ||
| - Discuss possibilities to implement DRTM launch on S3 resume in Xen | ||
|
|
||
| ## Meeting Minutes | ||
|
|
||
| Current approach of booting Linux with TrenchBoot: | ||
|
|
||
| - meet Linux demand so that anything can do EBS and DRTM can still work | ||
| - Linux doing EBS to gather necessary info from firmware | ||
| - bootloader to put slaunch code to memory | ||
| - the code being put to memory is going to be standardized and does everything | ||
| what DRTM technology needs | ||
| - standardize an input table to be used for generic stub not specific to any | ||
| bootloader/kernel | ||
|
|
||
| Current Xen status: | ||
|
|
||
| - Xen efi needs fixing in order to work without Xen's efi-stub, so it would be | ||
| better to follow Linux's approach of jumping into Xen and Xen calling out to | ||
| slstub | ||
| - AP wakeup developed during the Qubes OS AEM PoC in Xen hypervisor kernel is | ||
| still valid and will be needed in the most recent approach as well | ||
| - for legacy boot module will have to be placed in memory by GRUB but GRUB will | ||
| also construct the input table and call SENTER/SKINIT | ||
|
There was a problem hiding this comment. Upstream, I'm only aware of support for AP booting after SKINIT. And even then, "won't crash if booted like this", and not really "PoC of working trenchboot" quality. I don't recall any patches for the Intel SENTER support. There was a problem hiding this comment. @andyhhp true, there were no patches yet. We still are putting things together and just a few days ago, we finished the whole integration and verification. What I meant here, is that the work we did for AP bring up after SENTER will be needed for both UEFI and legacy boot mode. The patch set shall be sent when new get everything rebase onto most recent boot protocol. Does that approach sounds good to you @andyhhp ? |
||
|
|
||
| DRTM S3 resume support for Xen: | ||
|
|
||
| - Idea: for legacy S3 resume mark pages with slaunch module so that Xen won't | ||
| use them and later do DRTM relaunch using the module (needs a plan how to | ||
| implement it in Xen for legacy BIOS boot) | ||
| - tboot relaunches itself and then resumes kernel, seals its state to DRTM | ||
| PCRs, does DRTM on itself and tries to unseal the state, if it is ok, the | ||
| state is unsealed and tboot may proceed with kernel resume (not exactly what | ||
| we want) | ||
| - Xen patches alternatives, not runtime, S3 resume measurement would not be the | ||
| same even when only text section would be measured | ||
| - ideal solution is for Xen to reinstantiate itself with DRTM and reload the VM | ||
| configuration | ||
|
|
||
| Possible solution for S3: | ||
|
|
||
| - boot into Xen | ||
| - search for SRT table and look for SL module | ||
| - take measurement of Xen at the end of reinitialization by calling DRTM (right | ||
| before jump to Dom0) so that the measurement will be stable | ||
|
There was a problem hiding this comment. "at the end of boot" and by delaying the dynamic launch until after we're done making boot-time modifications to Xen's .text/etc. Also, somewhere we need to say that this doesn't cope with livepatching yet, but we've decided that we can exclude livepatching support from a v1 implementation. |
||
| - Currently it is not possible to take a meaningful measurement of Dom0 after | ||
| coming back from S3. It is still valid to measure Dom0 on initial boot to | ||
| ensure that the correct dom0 kernel is used to start the system. For Dom0 do | ||
| external inspection of LKRG (future), for now Dom0 is not that relevant to be | ||
| measured according to Daniel and Andrew | ||
|
There was a problem hiding this comment. I think what I meant was that, because the measurement of dom0 is largely meaningless, we should exclude it from v1. Even just getting a meaningful measurement of Xen on S3 resume puts Trenchboot in a far superior position compared to Tboot. |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| # TrenchBoot Meetings Minutes | ||
|
|
||
| Here you will find the meeting minutes from various TrenchBoot meetings. | ||
|
|
||
| {nav} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, Xen's EFI code (like linux) depends on being able to use boot services, and expects to call EBS itself.
Previously, we had a plan to try and make Xen able to boot without access to boot services. And while this is still a good idea, the point I was trying to make is that because we must support boot services for Linux efi-stub, using the same approach in Xen would be a less invasive change overall, and therefore easier to upstream.
i.e. "making Xen work without boot services" can (and should) now be orthogonal to "making Xen work with trenchboot".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, initially we wanted to get rid of UEFI completely in Xen, but given the new approach of booting Linux with TrenchBoot, it doesn't make much sense to pursue deUEFIcation anymore. This is what I understood too. Do you request any change in the file @andyhhp ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm suggesting another approach:
xen.efiThat way there would be no difference in Xen code between UEFI and legacy boot at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Xen efi needs fixing in order to work without Xen's efi-stub," doesn't really parse IMO. We don't really have an efi-stub like Linux does. We've just got a bit of code which is compiled to MSABI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andyhhp so, could you please suggest how this sentence should look like?
Also what do you think about @krystian-hebel approach?