Open BeataZdunczyk opened 1 year ago
Rebased Xen patches (by now they include TPM 2.0 and processing of DRTM from SLRT) on aem-phase3-rebase
of https://github.com/TrenchBoot/xen.
Commits looks a bit different now and most of the code differences are due to taking most of review comments into account (skipped those which might need discussion), especially the one about using a different prefix for SL-related symbols (I went with slaunch_
which was already used in one place and is also used in GRUB changes).
Commits: https://github.com/TrenchBoot/xen/compare/c23e698430...aem-phase3-rebase
Diff of diffs (includes "changes" like line number or hash differences):
```diff
--- /dev/fd/63 2023-12-20 19:40:09.799219058 +0200
+++ /dev/fd/62 2023-12-20 19:40:09.799219058 +0200
@@ -1,6 +1,6 @@
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
new file mode 100644
-index 0000000000..cfb966b60d
+index 0000000000..5bff1deb9b
--- /dev/null
+++ b/.github/workflows/build.yml
@@ -0,0 +1,17 @@
@@ -17,7 +17,7 @@
+ qubes-dom0-package:
+ uses: TrenchBoot/.github/.github/workflows/qubes-dom0-package.yml@master
+ with:
-+ base-commit: 'cbb35e72802f3a285c382a995ef647b59e5caf2f'
++ base-commit: 'c23e698430f3381304643d59b1ae373e36a318d5'
+ patch-start: 1300
+ qubes-component: 'vmm-xen'
+ spec-pattern: '/^Patch1202:/'
@@ -38,10 +38,10 @@
xen.gz
~~~~~~
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
-index 177a2ff742..594093fcca 100644
+index 4eec765106..76606f7617 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
-@@ -55,6 +55,7 @@ obj-y += percpu.o
+@@ -56,6 +56,7 @@ obj-y += percpu.o
obj-y += physdev.o
obj-$(CONFIG_COMPAT) += x86_64/physdev.o
obj-y += psr.o
@@ -49,7 +49,7 @@
obj-y += setup.o
obj-y += shutdown.o
obj-y += smp.o
-@@ -63,6 +64,7 @@ obj-y += spec_ctrl.o
+@@ -64,6 +65,7 @@ obj-y += spec_ctrl.o
obj-y += srat.o
obj-y += string.o
obj-y += time.o
@@ -93,10 +93,10 @@
for (acpiid = 0; acpiid < ARRAY_SIZE(x86_acpiid_to_apicid); acpiid++)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
-index 47e6e5fe41..b33e9070e8 100644
+index fcd8d5e8b2..2ac86a3774 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
-@@ -989,7 +989,7 @@ __next:
+@@ -985,7 +985,7 @@ __next:
*/
if (boot_cpu_physical_apicid == -1U)
boot_cpu_physical_apicid = get_apic_id();
@@ -129,7 +129,7 @@
$(LD) $(subst x86_64,i386,$(LDFLAGS_DIRECT)) -N -T $(filter %.lds,$^) -o $@ $<
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
-index 0fb7dd3029..32f99dfc52 100644
+index 245c859dd7..2cd9a3a0b5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -3,6 +3,7 @@
@@ -152,7 +152,7 @@
+ .long 0x42b651cb /* UUID3 */
+ .long 0x00000034 /* MLE header size */
+ .long 0x00020002 /* MLE version 2.2 */
-+ .long (sl_stub_entry - start) /* Linear entry point of MLE (SINIT virt. address) */
++ .long (slaunch_stub_entry - start) /* Linear entry point of MLE (SINIT virt. address) */
+ .long 0x00000000 /* First valid page of MLE */
+ .long 0x00000000 /* Offset within binary of first byte of MLE */
+ .long 0x00000000 /* Offset within binary of last byte + 1 of MLE */
@@ -166,7 +166,7 @@
.section .init.rodata, "a", @progbits
.Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
-@@ -425,6 +445,31 @@ __pvh_start:
+@@ -428,6 +448,31 @@ __pvh_start:
#endif /* CONFIG_PVH_GUEST */
@@ -190,7 +190,7 @@
+ * - APs must be brought up by MONITOR or GETSEC[WAKEUP], depending on
+ * which is supported by a given SINIT ACM
+ */
-+sl_stub_entry:
++slaunch_stub_entry:
+ movl $SLAUNCH_BOOTLOADER_MAGIC,%eax
+
+ /* Fall through to Multiboot entry point. */
@@ -198,7 +198,7 @@
__start:
cld
cli
-@@ -453,6 +498,10 @@ __start:
+@@ -456,6 +501,10 @@ __start:
/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
xor %edx,%edx
@@ -209,13 +209,13 @@
/* Check for Multiboot2 bootloader. */
cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
je .Lmultiboot2_proto
-@@ -468,6 +517,27 @@ __start:
+@@ -471,6 +520,27 @@ __start:
cmovnz MB_mem_lower(%ebx),%edx
jmp trampoline_bios_setup
+.Lslaunch_proto:
+ /* Save information that TrenchBoot slaunch was used. */
-+ movl $1, sym_esi(sl_status)
++ movl $1, sym_esi(slaunch_active)
+
+ /* Push arguments to stack and call txt_early_tests(). */
+ push $sym_offs(__2M_rwdata_end) /* end of target image */
@@ -237,7 +237,7 @@
.Lmultiboot2_proto:
/* Skip Multiboot2 information fixed part. */
lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
-@@ -789,6 +859,14 @@ cmdline_parse_early:
+@@ -792,6 +862,14 @@ cmdline_parse_early:
reloc:
.incbin "reloc.bin"
@@ -325,7 +325,7 @@
/* Relocations for trampoline Real Mode segments. */
diff --git a/xen/arch/x86/boot/txt_early.c b/xen/arch/x86/boot/txt_early.c
new file mode 100644
-index 0000000000..f94b2c6cc0
+index 0000000000..c52a600e8d
--- /dev/null
+++ b/xen/arch/x86/boot/txt_early.c
@@ -0,0 +1,131 @@
@@ -369,7 +369,7 @@
+
+ /* Verify the value of the low PMR base. It should always be 0. */
+ if (os_sinit->vtd_pmr_lo_base != 0)
-+ txt_reset(SL_ERROR_LO_PMR_BASE);
++ txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
+
+ /*
+ * Low PMR size should not be 0 on current platforms. There is an ongoing
@@ -377,12 +377,12 @@
+ * yet supported by the code.
+ */
+ if (os_sinit->vtd_pmr_lo_size == 0)
-+ txt_reset(SL_ERROR_LO_PMR_BASE);
++ txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
+
+ /* Check if regions overlap. Treat regions with no hole between as error. */
+ if (os_sinit->vtd_pmr_hi_size != 0 &&
+ os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size)
-+ txt_reset(SL_ERROR_HI_PMR_BASE);
++ txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
+
+ /* All regions accessed by 32b code must be below 4G. */
+ if (os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <= 0x100000000ull)
@@ -397,17 +397,17 @@
+
+ /* Check if all of Xen before relocation is covered by PMR. */
+ if (!is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr))
-+ txt_reset(SL_ERROR_LO_PMR_MLE);
++ txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+ /* Check if all of Xen after relocation is covered by PMR. */
+ if (load_base_addr != tgt_base_addr &&
+ !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr))
-+ txt_reset(SL_ERROR_LO_PMR_MLE);
++ txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+ /* Check if MBI is covered by PMR. MBI starts with 'uint32_t total_size'. */
+ if (!is_in_pmr(os_sinit, os_mle->boot_params_addr,
+ *(uint32_t *)os_mle->boot_params_addr, check_high_pmr))
-+ txt_reset(SL_ERROR_BUFFER_BEYOND_PMR);
++ txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+
+ /* Check if TPM event log (if present) is covered by PMR. */
+ /*
@@ -431,7 +431,7 @@
+ if (os_mle->evtlog_addr != 0 && os_mle->evtlog_size != 0 &&
+ !is_in_pmr(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
+ check_high_pmr))
-+ txt_reset(SL_ERROR_BUFFER_BEYOND_PMR);
++ txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+ */
+}
+
@@ -451,7 +451,7 @@
+
+ if (txt_os_mle_data_size(txt_heap) < sizeof(*os_mle) ||
+ txt_os_sinit_data_size(txt_heap) < sizeof(*os_sinit))
-+ txt_reset(SL_ERROR_GENERIC);
++ txt_reset(SLAUNCH_ERROR_GENERIC);
+
+ os_mle = txt_os_mle_data_start(txt_heap);
+ os_sinit = txt_os_sinit_data_start(txt_heap);
@@ -513,10 +513,10 @@
BUG /* start_secondary() shouldn't return. */
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
-index 5d77672f6b..890b6ba3a9 100644
+index ffdc6fb2fc..1124f2be3d 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
-@@ -1093,8 +1093,8 @@ static void __init ivt_idle_state_table_update(void)
+@@ -1213,8 +1213,8 @@ static void __init ivt_idle_state_table_update(void)
unsigned int cpu, max_apicid = boot_cpu_physical_apicid;
for_each_present_cpu(cpu)
@@ -528,10 +528,10 @@
case 0: case 1:
/* 1 and 2 socket systems use default ivt_cstates */
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
-index 41e1e3f272..34d3631904 100644
+index aca9fa310c..9a8cc4e92e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
-@@ -1559,7 +1559,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+@@ -1538,7 +1538,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
break;
cpu_id.phys_id =
@@ -541,7 +541,7 @@
rc = -EFAULT;
diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
-index b653a19c93..03a0a86902 100644
+index c5911cf48d..f836fec189 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -11,6 +11,7 @@
@@ -556,7 +556,7 @@
rdmsrl(MSR_MTRRcap, mtrr_cap);
rdmsrl(MSR_MTRRdefType, mtrr_def);
-+ if ( sl_status )
++ if ( slaunch_active )
+ txt_restore_mtrrs(e820_verbose);
+
if ( e820_verbose )
@@ -577,22 +577,23 @@
diff --git a/xen/arch/x86/include/asm/intel_txt.h b/xen/arch/x86/include/asm/intel_txt.h
new file mode 100644
-index 0000000000..bbf6f566ed
+index 0000000000..8be44fae1a
--- /dev/null
+++ b/xen/arch/x86/include/asm/intel_txt.h
-@@ -0,0 +1,397 @@
+@@ -0,0 +1,398 @@
++#include
sl_status
is now a bool
and called slaunch_active
. By the way, I noticed that x86/boot/txt_early: add early TXT tests and restore MBI pointer
commit adds declaration of (now) slaunch_active
without definition, so Xen doesn't compile. Don't know if it's worth fixing by adding essentially empty intel_txt.c
in that commit.
Also, there should be no tabulation in the changes anymore.
@SergiiDmytruk great news! Thank you for the comparison of the diff of diffs, it is helpful. @krystian-hebel please take a look.
sl_status
is now abool
I'm not sure how I feel about this change. To the best of my knowledge, size of bool
is not defined. There is BOOL_WIDTH
in limits.h
since C23, I haven't found anything similar for earlier standards. This may be important because in assembly we assume that it is 32b.
On top of that, we will soon be implementing AMD counterpart, so we may need a way of differentiating between those two, which would require more bits than a single bool
provides.
Xen doesn't compile. Don't know if it's worth fixing by adding essentially empty
intel_txt.c
in that commit.
There was a recent discussion about how Xen can't be easily bisected because of problems like this, so please fix it.
I'm not sure how I feel about this change. To the best of my knowledge, size of
bool
is not defined. There isBOOL_WIDTH
inlimits.h
since C23, I haven't found anything similar for earlier standards. This may be important because in assembly we assume that it is 32b.
I did the change because it was suggested in the review, can revert (I even have aem-phase3-rebase-before-sl_status-rename
branch locally). I think bool
is 1 byte and I didn't notice that assembly treats the variable as 4 bytes. Can add a static assert for the size if bool
will remain.
On top of that, we will soon be implementing AMD counterpart, so we may need a way of differentiating between those two, which would require more bits than a single
bool
provides.
Is there a need to pack it in a single variable? It can be slaunch_active
and slaunch_type
.
There was a recent discussion about how Xen can't be easily bisected because of problems like this, so please fix it.
Will do.
Is there a need to pack it in a single variable? It can be
slaunch_active
andslaunch_type
.
Actually, this may be even better. Often tasks have to be done for all vendors, and SLRT should make it similar between them, we just have to get its address differently. In fact, everything that has to be done on AMD that isn't required for Intel is already done without slaunch_type
.
Change of the commit which wasn't building: https://github.com/TrenchBoot/xen/compare/6bbfc3c871143bf0bc0adf778b6cd8d40b64a14c..390826d5a1650a585d02f9761d60284a8b612915 It's the same where assembly needed to be updated.
Branch difference: https://github.com/TrenchBoot/xen/compare/150a0a329a76676484c878a542089eaf2b286d6a..0c8fec9a0638f61996b6e0f35c48ef35f1837c8b
Changes look good now, and it seems to work on minimal Xen+Alpine setup, I think https://github.com/QubesOS/qubes-vmm-xen/pull/160 can be updated with those now.
I think QubesOS/qubes-vmm-xen#160 can be updated with those now.
To avoid a potential deadlock: I'm not the one who should be updating it, right?
Updated https://github.com/QubesOS/qubes-vmm-xen/pull/160 and commented on all review comments which were addressed or which I knew how to answer. There are some more left to answer, some to do (like define constants and add log messages). @krystian-hebel:
volatile
on read_txt_reg()
?BUG
macro?@SergiiDmytruk I replied to the first 4 comments you listed.
As for 5, it depends on what layer of security that question is about. They are measured, and they won't be less secure than it would be without TB because of that. Xen can choose to ignore it and set it's own MTRRs (perhaps it already does, haven't checked), but by restoring them at this point we get decent execution speed. Booting from UC is slooooow.
For 6, if BUG
prints something that would be visible for end users, definitely use it. Otherwise this would still be silent, but most likely something else would break if TXT heap or SINIT can't be found, so maybe that would also be good reason for using BUG
. If nothing else, this would at least make code clearer by having one less indentation level.
Thanks, @krystian-hebel.
Integrated your comments for 1 and 2 to corresponding commits.
For 6, if
BUG
prints something that would be visible for end users, definitely use it. Otherwise this would still be silent, but most likely something else would break if TXT heap or SINIT can't be found, so maybe that would also be good reason for usingBUG
. If nothing else, this would at least make code clearer by having one less indentation level.
It prints source code location and halts, so I guess it'll do.
Didn't update the PR yet, but pushed the changes. Their difference: https://github.com/TrenchBoot/xen/compare/0c8fec9a0638f61996b6e0f35c48ef35f1837c8b..37d1ba6086f103010cab4e90e83eb9f1033894ae
(Looks like last time I wrote a comment here I confused its preview for an actual comment and closed the browser. Not much was lost anyway.)
Last changes (constants and a comment): https://github.com/TrenchBoot/xen/compare/37d1ba6086f103010cab4e90e83eb9f1033894ae..81ac532e6c77290b6ecf6e4caf76915f350ca6d3
I think this addresses all outstanding comments on https://github.com/QubesOS/qubes-vmm-xen/pull/160 (several without reply are covered by a reply to a similar comment nearby).
Review of GRUB has been moved to https://github.com/TrenchBoot/grub/pull/16. Original approach from https://github.com/QubesOS/qubes-grub2/pull/13 proved to be impractical - review of patches to patches, indirect building, and most annoyingly, GH had problems with showing so many comments at once, some of us were greeted by unicorn of death instead of PR page:
After review and a lot of debugging https://github.com/TrenchBoot/grub/pull/16 was finally positively tested and reviewed. New set of patches was created and sent back to ~the land of unicorns~ https://github.com/QubesOS/qubes-grub2/pull/13.
Is your feature request related to a problem? Please describe.
This issue tracks the review, and merge process for the Pull Requests created to add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2 and to implement Xen Secure Launch with Intel TXT support in Xen for TrenchBoot as Anti Evil Maid project.The problem is that TrenchBoot, which is used as an anti-evil maid solution in Qubes OS, does not currently support TPM 1.2 on Intel TXT path and does not have Xen Secure Launch with Intel TXT support. This limits the hardware compatibility for TrenchBoot and hinders its ability to protect against certain attacks.
Is your feature request related to a new idea or technology that would benefit the project? Please describe.
The feature request is to add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2 and to implement Xen Secure Launch with Intel TXT support in Xen for TrenchBoot. This would allow TrenchBoot to support older Intel hardware with Intel TXT and launch Xen directly via DRTM on Intel hardware, improving its hardware compatibility and security.
Describe the solution you'd like
Following PRs merged:
Describe alternatives you've considered N/A
Additional context
This feature request is Phase 1 for TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem/ and https://docs.dasharo.com/projects/trenchboot-aem-v2/
Relevant documentation you've consulted N/A