From 5253b809df610a489208e37d2e4871ea5f5fe547 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20=C5=BBygowski?= Date: Wed, 25 Jan 2023 17:03:40 +0100 Subject: [PATCH 1/3] docs/meeting-minutes: Add notes from January TrenchBoot AEM meeting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Michał Żygowski --- .../TrenchBoot-AEM-January24-2023.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md diff --git a/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md b/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md new file mode 100644 index 0000000..427f7c8 --- /dev/null +++ b/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md @@ -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 + +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 +- 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 From 8b0da9c705ded4de85d647ca0910fd2371968459 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20=C5=BBygowski?= Date: Wed, 25 Jan 2023 17:35:49 +0100 Subject: [PATCH 2/3] docs/meeting-minutes: Add navigation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Michał Żygowski --- docs/meeting-minutes/.pages.yml | 3 +++ docs/meeting-minutes/index.md | 5 +++++ mkdocs.yml | 1 + 3 files changed, 9 insertions(+) create mode 100644 docs/meeting-minutes/.pages.yml create mode 100644 docs/meeting-minutes/index.md diff --git a/docs/meeting-minutes/.pages.yml b/docs/meeting-minutes/.pages.yml new file mode 100644 index 0000000..ae4bb0e --- /dev/null +++ b/docs/meeting-minutes/.pages.yml @@ -0,0 +1,3 @@ +title: TrenchBoot Meeting Minutes +nav: + - ... \ No newline at end of file diff --git a/docs/meeting-minutes/index.md b/docs/meeting-minutes/index.md new file mode 100644 index 0000000..8897087 --- /dev/null +++ b/docs/meeting-minutes/index.md @@ -0,0 +1,5 @@ +# TrenchBoot Meetings Minutes + +Here you will find the meeting minutes from various TrenchBoot meetings. + +{nav} diff --git a/mkdocs.yml b/mkdocs.yml index e5b7905..ad24cb7 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -20,6 +20,7 @@ nav: - Documentation: - ... | documentation/*.md - ... | blueprints/*.md + - ... | meeting-minutes/*.md - Steering Committee: - ... | steering-committee/*.md - FAQ: From d686155c061dd599b80f39fcd69dc6e5cba1e5c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20=C5=BBygowski?= Date: Thu, 26 Jan 2023 12:43:35 +0100 Subject: [PATCH 3/3] docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md: Apply fixes after review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Michał Żygowski --- .../meeting-minutes/TrenchBoot-AEM-January24-2023.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md b/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md index 427f7c8..11d9de2 100644 --- a/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md +++ b/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md @@ -53,10 +53,12 @@ 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 +- take measurement of Xen 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. so + that the measurement will be stable. This doesn't cope with livepatching yet, + but livepatching support can be omitted in 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 + ensure that the correct dom0 kernel is used to start the system. Also dom0 + measurement will be largely meaningless, so it can be excluded from v1 + implementation