docs/meeting-minutes: Add notes from January TrenchBoot AEM meeting #22
Conversation
Signed-off-by: Michał Żygowski <[email protected]>
Signed-off-by: Michał Żygowski <[email protected]>
| - 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 |
There was a problem hiding this comment.
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.
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.
I'm suggesting another approach:
- Xen is built as usual, with changes we made in the first phase, but this time we use
xen.efi - GRUB, when started with slaunch activated, doesn't care about "EFI boot services" tag (conditional added before https://github.com/TrenchBoot/grub/blob/master/grub-core/loader/multiboot_mbi2.c#L257)
- BS are terminated (https://github.com/TrenchBoot/grub/blob/master/grub-core/loader/multiboot_mbi2.c#L943)
- UEFI MB2 entry point is not taken (https://github.com/TrenchBoot/grub/blob/master/grub-core/loader/multiboot_mbi2.c#L362)
- memory info is passed through Memory map tag (https://github.com/TrenchBoot/grub/blob/master/grub-core/loader/multiboot_mbi2.c#L810) and Basic memory info tag (https://github.com/TrenchBoot/grub/blob/master/grub-core/loader/multiboot_mbi2.c#L832)
- Xen boots through legacy MB2 path (actually, it starts with TXT entry that quickly jumps into MB2 path) with all necessary info provided by GRUB
That way there would be no difference in Xen code between UEFI and legacy boot at all.
There was a problem hiding this comment.
"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.
@andyhhp so, could you please suggest how this sentence should look like?
Also what do you think about @krystian-hebel approach?
| - 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 ?
| - 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.
| 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.
|
@krystian-hebel you review IMO is not mendatory I just wanted to make sure you get notifications with @andyhhp comments. |
…ter review Signed-off-by: Michał Żygowski <[email protected]>
Signed-off-by: Michał Żygowski [email protected]