Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package xen for openSUSE:Factory checked in at 2023-02-14 16:43:02 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/xen (Old) and /work/SRC/openSUSE:Factory/.xen.new.27156 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen" Tue Feb 14 16:43:02 2023 rev:326 rq:1065597 version:4.17.0_04 Changes: -------- --- /work/SRC/openSUSE:Factory/xen/xen.changes 2023-01-27 10:23:53.489964341 +0100 +++ /work/SRC/openSUSE:Factory/.xen.new.27156/xen.changes 2023-02-14 16:43:06.889621005 +0100 @@ -1,0 +2,24 @@ +Thu Feb 9 09:56:27 MST 2023 - [email protected] + +- bsc#1205792 - Partner-L3: launch-xenstore error messages show in + SLES15 SP4 xen kernel. + 63e4da00-dont-log-errors-when-trying-to-load-PVH-xenstore-stubdom.patch + +------------------------------------------------------------------- +Mon Feb 6 12:17:00 CET 2023 - [email protected] + +- bsc#1026236 - tidy/modernize patch + xen.bug1026236.suse_vtsc_tolerance.patch + +------------------------------------------------------------------- +Mon Feb 6 12:15:00 CET 2023 - [email protected] + +- Upstream bug fixes (bsc#1027519) + 63c05478-VMX-calculate-model-specific-LBRs-once.patch + 63c05478-VMX-support-CPUs-without-model-specific-LBR.patch +- bsc#1207544 - VUL-0: CVE-2022-42330: xen: Guests can cause + Xenstore crash via soft reset (XSA-425) + xsa425.patch -> + 63d24e91-tools-xenstore-revert-simplify-loop-handling.patch + +------------------------------------------------------------------- Old: ---- xsa425.patch New: ---- 63c05478-VMX-calculate-model-specific-LBRs-once.patch 63c05478-VMX-support-CPUs-without-model-specific-LBR.patch 63d24e91-tools-xenstore-revert-simplify-loop-handling.patch 63e4da00-dont-log-errors-when-trying-to-load-PVH-xenstore-stubdom.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xen.spec ++++++ --- /var/tmp/diff_new_pack.dLb4nZ/_old 2023-02-14 16:43:08.337629599 +0100 +++ /var/tmp/diff_new_pack.dLb4nZ/_new 2023-02-14 16:43:08.341629623 +0100 @@ -156,7 +156,10 @@ Source99: baselibs.conf # Upstream patches Patch1: 63a03e28-x86-high-freq-TSC-overflow.patch -Patch100: xsa425.patch +Patch2: 63c05478-VMX-calculate-model-specific-LBRs-once.patch +Patch3: 63c05478-VMX-support-CPUs-without-model-specific-LBR.patch +Patch4: 63d24e91-tools-xenstore-revert-simplify-loop-handling.patch +Patch5: 63e4da00-dont-log-errors-when-trying-to-load-PVH-xenstore-stubdom.patch # EMBARGOED security fixes # libxc Patch301: libxc-bitmap-long.patch ++++++ 63c05478-VMX-calculate-model-specific-LBRs-once.patch ++++++ # Commit e94af0d58f86c3a914b9cbbf4d9ed3d43b974771 # Date 2023-01-12 18:42:00 +0000 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/vmx: Calculate model-specific LBRs once at start of day There is no point repeating this calculation at runtime, especially as it is in the fallback path of the WRSMR/RDMSR handlers. Move the infrastructure higher in vmx.c to avoid forward declarations, renaming last_branch_msr_get() to get_model_specific_lbr() to highlight that these are model-specific only. No practical change. Signed-off-by: Andrew Cooper <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Reviewed-by: Kevin Tian <[email protected]> --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -396,6 +396,142 @@ void vmx_pi_hooks_deassign(struct domain domain_unpause(d); } +static const struct lbr_info { + u32 base, count; +} p4_lbr[] = { + { MSR_P4_LER_FROM_LIP, 1 }, + { MSR_P4_LER_TO_LIP, 1 }, + { MSR_P4_LASTBRANCH_TOS, 1 }, + { MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, + { MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, + { 0, 0 } +}, c2_lbr[] = { + { MSR_IA32_LASTINTFROMIP, 1 }, + { MSR_IA32_LASTINTTOIP, 1 }, + { MSR_C2_LASTBRANCH_TOS, 1 }, + { MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_C2_LASTBRANCH_FROM_TO }, + { MSR_C2_LASTBRANCH_0_TO_IP, NUM_MSR_C2_LASTBRANCH_FROM_TO }, + { 0, 0 } +}, nh_lbr[] = { + { MSR_IA32_LASTINTFROMIP, 1 }, + { MSR_IA32_LASTINTTOIP, 1 }, + { MSR_NHL_LBR_SELECT, 1 }, + { MSR_NHL_LASTBRANCH_TOS, 1 }, + { MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, + { MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, + { 0, 0 } +}, sk_lbr[] = { + { MSR_IA32_LASTINTFROMIP, 1 }, + { MSR_IA32_LASTINTTOIP, 1 }, + { MSR_NHL_LBR_SELECT, 1 }, + { MSR_NHL_LASTBRANCH_TOS, 1 }, + { MSR_SKL_LASTBRANCH_0_FROM_IP, NUM_MSR_SKL_LASTBRANCH }, + { MSR_SKL_LASTBRANCH_0_TO_IP, NUM_MSR_SKL_LASTBRANCH }, + { MSR_SKL_LASTBRANCH_0_INFO, NUM_MSR_SKL_LASTBRANCH }, + { 0, 0 } +}, at_lbr[] = { + { MSR_IA32_LASTINTFROMIP, 1 }, + { MSR_IA32_LASTINTTOIP, 1 }, + { MSR_C2_LASTBRANCH_TOS, 1 }, + { MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, + { MSR_C2_LASTBRANCH_0_TO_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, + { 0, 0 } +}, sm_lbr[] = { + { MSR_IA32_LASTINTFROMIP, 1 }, + { MSR_IA32_LASTINTTOIP, 1 }, + { MSR_SM_LBR_SELECT, 1 }, + { MSR_SM_LASTBRANCH_TOS, 1 }, + { MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, + { MSR_C2_LASTBRANCH_0_TO_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, + { 0, 0 } +}, gm_lbr[] = { + { MSR_IA32_LASTINTFROMIP, 1 }, + { MSR_IA32_LASTINTTOIP, 1 }, + { MSR_SM_LBR_SELECT, 1 }, + { MSR_SM_LASTBRANCH_TOS, 1 }, + { MSR_GM_LASTBRANCH_0_FROM_IP, NUM_MSR_GM_LASTBRANCH_FROM_TO }, + { MSR_GM_LASTBRANCH_0_TO_IP, NUM_MSR_GM_LASTBRANCH_FROM_TO }, + { 0, 0 } +}; +static const struct lbr_info *__ro_after_init model_specific_lbr; + +static const struct lbr_info *__init get_model_specific_lbr(void) +{ + switch ( boot_cpu_data.x86 ) + { + case 6: + switch ( boot_cpu_data.x86_model ) + { + /* Core2 Duo */ + case 0x0f: + /* Enhanced Core */ + case 0x17: + /* Xeon 7400 */ + case 0x1d: + return c2_lbr; + /* Nehalem */ + case 0x1a: case 0x1e: case 0x1f: case 0x2e: + /* Westmere */ + case 0x25: case 0x2c: case 0x2f: + /* Sandy Bridge */ + case 0x2a: case 0x2d: + /* Ivy Bridge */ + case 0x3a: case 0x3e: + /* Haswell */ + case 0x3c: case 0x3f: case 0x45: case 0x46: + /* Broadwell */ + case 0x3d: case 0x47: case 0x4f: case 0x56: + return nh_lbr; + /* Skylake */ + case 0x4e: case 0x5e: + /* Xeon Scalable */ + case 0x55: + /* Cannon Lake */ + case 0x66: + /* Goldmont Plus */ + case 0x7a: + /* Ice Lake */ + case 0x6a: case 0x6c: case 0x7d: case 0x7e: + /* Tiger Lake */ + case 0x8c: case 0x8d: + /* Tremont */ + case 0x86: + /* Kaby Lake */ + case 0x8e: case 0x9e: + /* Comet Lake */ + case 0xa5: case 0xa6: + return sk_lbr; + /* Atom */ + case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36: + return at_lbr; + /* Silvermont */ + case 0x37: case 0x4a: case 0x4d: case 0x5a: case 0x5d: + /* Xeon Phi Knights Landing */ + case 0x57: + /* Xeon Phi Knights Mill */ + case 0x85: + /* Airmont */ + case 0x4c: + return sm_lbr; + /* Goldmont */ + case 0x5c: case 0x5f: + return gm_lbr; + } + break; + + case 15: + switch ( boot_cpu_data.x86_model ) + { + /* Pentium4/Xeon with em64t */ + case 3: case 4: case 6: + return p4_lbr; + } + break; + } + + return NULL; +} + static int cf_check vmx_domain_initialise(struct domain *d) { static const struct arch_csw csw = { @@ -2837,6 +2973,7 @@ const struct hvm_function_table * __init vmx_function_table.tsc_scaling.setup = vmx_setup_tsc_scaling; } + model_specific_lbr = get_model_specific_lbr(); lbr_tsx_fixup_check(); ler_to_fixup_check(); @@ -2983,141 +3120,6 @@ static int vmx_cr_access(cr_access_qual_ return X86EMUL_OKAY; } -static const struct lbr_info { - u32 base, count; -} p4_lbr[] = { - { MSR_P4_LER_FROM_LIP, 1 }, - { MSR_P4_LER_TO_LIP, 1 }, - { MSR_P4_LASTBRANCH_TOS, 1 }, - { MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, - { MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, - { 0, 0 } -}, c2_lbr[] = { - { MSR_IA32_LASTINTFROMIP, 1 }, - { MSR_IA32_LASTINTTOIP, 1 }, - { MSR_C2_LASTBRANCH_TOS, 1 }, - { MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_C2_LASTBRANCH_FROM_TO }, - { MSR_C2_LASTBRANCH_0_TO_IP, NUM_MSR_C2_LASTBRANCH_FROM_TO }, - { 0, 0 } -}, nh_lbr[] = { - { MSR_IA32_LASTINTFROMIP, 1 }, - { MSR_IA32_LASTINTTOIP, 1 }, - { MSR_NHL_LBR_SELECT, 1 }, - { MSR_NHL_LASTBRANCH_TOS, 1 }, - { MSR_P4_LASTBRANCH_0_FROM_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, - { MSR_P4_LASTBRANCH_0_TO_LIP, NUM_MSR_P4_LASTBRANCH_FROM_TO }, - { 0, 0 } -}, sk_lbr[] = { - { MSR_IA32_LASTINTFROMIP, 1 }, - { MSR_IA32_LASTINTTOIP, 1 }, - { MSR_NHL_LBR_SELECT, 1 }, - { MSR_NHL_LASTBRANCH_TOS, 1 }, - { MSR_SKL_LASTBRANCH_0_FROM_IP, NUM_MSR_SKL_LASTBRANCH }, - { MSR_SKL_LASTBRANCH_0_TO_IP, NUM_MSR_SKL_LASTBRANCH }, - { MSR_SKL_LASTBRANCH_0_INFO, NUM_MSR_SKL_LASTBRANCH }, - { 0, 0 } -}, at_lbr[] = { - { MSR_IA32_LASTINTFROMIP, 1 }, - { MSR_IA32_LASTINTTOIP, 1 }, - { MSR_C2_LASTBRANCH_TOS, 1 }, - { MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, - { MSR_C2_LASTBRANCH_0_TO_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, - { 0, 0 } -}, sm_lbr[] = { - { MSR_IA32_LASTINTFROMIP, 1 }, - { MSR_IA32_LASTINTTOIP, 1 }, - { MSR_SM_LBR_SELECT, 1 }, - { MSR_SM_LASTBRANCH_TOS, 1 }, - { MSR_C2_LASTBRANCH_0_FROM_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, - { MSR_C2_LASTBRANCH_0_TO_IP, NUM_MSR_ATOM_LASTBRANCH_FROM_TO }, - { 0, 0 } -}, gm_lbr[] = { - { MSR_IA32_LASTINTFROMIP, 1 }, - { MSR_IA32_LASTINTTOIP, 1 }, - { MSR_SM_LBR_SELECT, 1 }, - { MSR_SM_LASTBRANCH_TOS, 1 }, - { MSR_GM_LASTBRANCH_0_FROM_IP, NUM_MSR_GM_LASTBRANCH_FROM_TO }, - { MSR_GM_LASTBRANCH_0_TO_IP, NUM_MSR_GM_LASTBRANCH_FROM_TO }, - { 0, 0 } -}; - -static const struct lbr_info *last_branch_msr_get(void) -{ - switch ( boot_cpu_data.x86 ) - { - case 6: - switch ( boot_cpu_data.x86_model ) - { - /* Core2 Duo */ - case 0x0f: - /* Enhanced Core */ - case 0x17: - /* Xeon 7400 */ - case 0x1d: - return c2_lbr; - /* Nehalem */ - case 0x1a: case 0x1e: case 0x1f: case 0x2e: - /* Westmere */ - case 0x25: case 0x2c: case 0x2f: - /* Sandy Bridge */ - case 0x2a: case 0x2d: - /* Ivy Bridge */ - case 0x3a: case 0x3e: - /* Haswell */ - case 0x3c: case 0x3f: case 0x45: case 0x46: - /* Broadwell */ - case 0x3d: case 0x47: case 0x4f: case 0x56: - return nh_lbr; - /* Skylake */ - case 0x4e: case 0x5e: - /* Xeon Scalable */ - case 0x55: - /* Cannon Lake */ - case 0x66: - /* Goldmont Plus */ - case 0x7a: - /* Ice Lake */ - case 0x6a: case 0x6c: case 0x7d: case 0x7e: - /* Tiger Lake */ - case 0x8c: case 0x8d: - /* Tremont */ - case 0x86: - /* Kaby Lake */ - case 0x8e: case 0x9e: - /* Comet Lake */ - case 0xa5: case 0xa6: - return sk_lbr; - /* Atom */ - case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36: - return at_lbr; - /* Silvermont */ - case 0x37: case 0x4a: case 0x4d: case 0x5a: case 0x5d: - /* Xeon Phi Knights Landing */ - case 0x57: - /* Xeon Phi Knights Mill */ - case 0x85: - /* Airmont */ - case 0x4c: - return sm_lbr; - /* Goldmont */ - case 0x5c: case 0x5f: - return gm_lbr; - } - break; - - case 15: - switch ( boot_cpu_data.x86_model ) - { - /* Pentium4/Xeon with em64t */ - case 3: case 4: case 6: - return p4_lbr; - } - break; - } - - return NULL; -} - enum { LBR_FORMAT_32 = 0x0, /* 32-bit record format */ @@ -3224,7 +3226,7 @@ static void __init ler_to_fixup_check(vo static int is_last_branch_msr(u32 ecx) { - const struct lbr_info *lbr = last_branch_msr_get(); + const struct lbr_info *lbr = model_specific_lbr; if ( lbr == NULL ) return 0; @@ -3563,7 +3565,7 @@ static int cf_check vmx_msr_write_interc if ( !(v->arch.hvm.vmx.lbr_flags & LBR_MSRS_INSERTED) && (msr_content & IA32_DEBUGCTLMSR_LBR) ) { - const struct lbr_info *lbr = last_branch_msr_get(); + const struct lbr_info *lbr = model_specific_lbr; if ( unlikely(!lbr) ) { ++++++ 63c05478-VMX-support-CPUs-without-model-specific-LBR.patch ++++++ # Commit 3edca52ce736297d7fcf293860cd94ef62638052 # Date 2023-01-12 18:42:00 +0000 # Author Andrew Cooper <[email protected]> # Committer Andrew Cooper <[email protected]> x86/vmx: Support for CPUs without model-specific LBR Ice Lake (server at least) has both architectural LBR and model-specific LBR. Sapphire Rapids does not have model-specific LBR at all. I.e. On SPR and later, model_specific_lbr will always be NULL, so we must make changes to avoid reliably hitting the domain_crash(). The Arch LBR spec states that CPUs without model-specific LBR implement MSR_DBG_CTL.LBR by discarding writes and always returning 0. Do this for any CPU for which we lack model-specific LBR information. Adjust the now-stale comment, now that the Arch LBR spec has created a way to signal "no model specific LBR" to guests. Signed-off-by: Andrew Cooper <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Reviewed-by: Kevin Tian <[email protected]> --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3546,17 +3546,25 @@ static int cf_check vmx_msr_write_interc goto gp_fault; /* + * The Arch LBR spec (new in Ice Lake) states that CPUs with no + * model-specific LBRs implement MSR_DBG_CTL.LBR by discarding writes + * and always returning 0. + * + * Use this property in all cases where we don't know any + * model-specific LBR information, as it matches real hardware + * behaviour on post-Ice Lake systems. + */ + if ( !model_specific_lbr ) + msr_content &= ~IA32_DEBUGCTLMSR_LBR; + + /* * When a guest first enables LBR, arrange to save and restore the LBR * MSRs and allow the guest direct access. * - * MSR_DEBUGCTL and LBR has existed almost as long as MSRs have - * existed, and there is no architectural way to hide the feature, or - * fail the attempt to enable LBR. - * - * Unknown host LBR MSRs or hitting -ENOSPC with the guest load/save - * list are definitely hypervisor bugs, whereas -ENOMEM for allocating - * the load/save list is simply unlucky (and shouldn't occur with - * sensible management by the toolstack). + * Hitting -ENOSPC with the guest load/save list is definitely a + * hypervisor bug, whereas -ENOMEM for allocating the load/save list + * is simply unlucky (and shouldn't occur with sensible management by + * the toolstack). * * Either way, there is nothing we can do right now to recover, and * the guest won't execute correctly either. Simply crash the domain @@ -3567,13 +3575,6 @@ static int cf_check vmx_msr_write_interc { const struct lbr_info *lbr = model_specific_lbr; - if ( unlikely(!lbr) ) - { - gprintk(XENLOG_ERR, "Unknown Host LBR MSRs\n"); - domain_crash(v->domain); - return X86EMUL_OKAY; - } - for ( ; lbr->count; lbr++ ) { unsigned int i; ++++++ 63d24e91-tools-xenstore-revert-simplify-loop-handling.patch ++++++ # Commit 10ced96ce9d4cbc140652795fe87af9f83bb1b29 # Date 2023-01-26 10:57:37 +0100 # Author Jason Andryuk <[email protected]> # Committer Jan Beulich <[email protected]> Revert "tools/xenstore: simplify loop handling connection I/O" I'm observing guest kexec trigger xenstored to abort on a double free. gdb output: Program received signal SIGABRT, Aborted. __pthread_kill_implementation (no_tid=0, signo=6, threadid=140645614258112) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt at ./nptl/pthread_kill.c:44 at ./nptl/pthread_kill.c:78 at ./nptl/pthread_kill.c:89 at ../sysdeps/posix/raise.c:26 at talloc.c:119 ptr=ptr@entry=0x559fae724290) at talloc.c:232 at xenstored_core.c:2945 (gdb) frame 5 at talloc.c:119 119 TALLOC_ABORT("Bad talloc magic value - double free"); (gdb) frame 7 at xenstored_core.c:2945 2945 talloc_increase_ref_count(conn); (gdb) p conn $1 = (struct connection *) 0x559fae724290 Looking at a xenstore trace, we have: IN 0x559fae71f250 20230120 17:40:53 READ (/local/domain/3/image/device-model-dom id ) wrl: dom 0 1 msec 10000 credit 1000000 reserve 100 disc ard wrl: dom 3 1 msec 10000 credit 1000000 reserve 100 disc ard wrl: dom 0 0 msec 10000 credit 1000000 reserve 0 disc ard wrl: dom 3 0 msec 10000 credit 1000000 reserve 0 disc ard OUT 0x559fae71f250 20230120 17:40:53 ERROR (ENOENT ) wrl: dom 0 1 msec 10000 credit 1000000 reserve 100 disc ard wrl: dom 3 1 msec 10000 credit 1000000 reserve 100 disc ard IN 0x559fae71f250 20230120 17:40:53 RELEASE (3 ) DESTROY watch 0x559fae73f630 DESTROY watch 0x559fae75ddf0 DESTROY watch 0x559fae75ec30 DESTROY watch 0x559fae75ea60 DESTROY watch 0x559fae732c00 DESTROY watch 0x559fae72cea0 DESTROY watch 0x559fae728fc0 DESTROY watch 0x559fae729570 DESTROY connection 0x559fae724290 orphaned node /local/domain/3/device/suspend/event-channel deleted orphaned node /local/domain/3/device/vbd/51712 deleted orphaned node /local/domain/3/device/vkbd/0 deleted orphaned node /local/domain/3/device/vif/0 deleted orphaned node /local/domain/3/control/shutdown deleted orphaned node /local/domain/3/control/feature-poweroff deleted orphaned node /local/domain/3/control/feature-reboot deleted orphaned node /local/domain/3/control/feature-suspend deleted orphaned node /local/domain/3/control/feature-s3 deleted orphaned node /local/domain/3/control/feature-s4 deleted orphaned node /local/domain/3/control/sysrq deleted orphaned node /local/domain/3/data deleted orphaned node /local/domain/3/drivers deleted orphaned node /local/domain/3/feature deleted orphaned node /local/domain/3/attr deleted orphaned node /local/domain/3/error deleted orphaned node /local/domain/3/console/backend-id deleted and no further output. The trace shows that DESTROY was called for connection 0x559fae724290, but that is the same pointer (conn) main() was looping through from connections. So it wasn't actually removed from the connections list? Reverting commit e8e6e42279a5 "tools/xenstore: simplify loop handling connection I/O" fixes the abort/double free. I think the use of list_for_each_entry_safe is incorrect. list_for_each_entry_safe makes traversal safe for deleting the current iterator, but RELEASE/do_release will delete some other entry in the connections list. I think the observed abort is because list_for_each_entry has next pointing to the deleted connection, and it is used in the subsequent iteration. Add a comment explaining the unsuitability of list_for_each_entry_safe. Also notice that the old code takes a reference on next which would prevents a use-after-free. This reverts commit e8e6e42279a5723239c5c40ba4c7f579a979465d. This is XSA-425/CVE-2022-42330. Fixes: e8e6e42279a5 ("tools/xenstore: simplify loop handling connection I/O") Signed-off-by: Jason Andryuk <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Reviewed-by: Julien Grall <[email protected]> --- a/tools/xenstore/xenstored_core.c +++ b/tools/xenstore/xenstored_core.c @@ -2935,8 +2935,23 @@ int main(int argc, char *argv[]) } } - list_for_each_entry_safe(conn, next, &connections, list) { - talloc_increase_ref_count(conn); + /* + * list_for_each_entry_safe is not suitable here because + * handle_input may delete entries besides the current one, but + * those may be in the temporary next which would trigger a + * use-after-free. list_for_each_entry_safe is only safe for + * deleting the current entry. + */ + next = list_entry(connections.next, typeof(*conn), list); + if (&next->list != &connections) + talloc_increase_ref_count(next); + while (&next->list != &connections) { + conn = next; + + next = list_entry(conn->list.next, + typeof(*conn), list); + if (&next->list != &connections) + talloc_increase_ref_count(next); if (conn_can_read(conn)) handle_input(conn); ++++++ 63e4da00-dont-log-errors-when-trying-to-load-PVH-xenstore-stubdom.patch ++++++ Subject: tools/helpers: don't log errors when trying to load PVH xenstore-stubdom From: Juergen Gross [email protected] Fri Jan 27 17:17:39 2023 +0100 Date: Thu Feb 9 11:33:20 2023 +0000: Git: 26f99e055dfecb8c52bb094bbb5aacb53148ae09 When loading a Xenstore stubdom the loader doesn't know whether the lo be loaded kernel is a PVH or a PV one. So it tries to load it as a PVH one first, and if this fails it is loading it as a PV kernel. This results in errors being logged in case the stubdom is a PV kernel. Suppress those errors by setting the minimum logging level to "critical" while trying to load the kernel as PVH. In case PVH mode and PV mode loading fails, retry PVH mode loading without changing the log level in order to get the error messages logged. Fixes: f89955449c5a ("tools/init-xenstore-domain: support xenstore pvh stubdom") Signed-off-by: Juergen Gross <[email protected]> Acked-by: Andrew Cooper <[email protected]> diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c index 04e351ca29..85cc9e8381 100644 --- a/tools/helpers/init-xenstore-domain.c +++ b/tools/helpers/init-xenstore-domain.c @@ -31,6 +31,8 @@ static int memory; static int maxmem; static xen_pfn_t console_gfn; static xc_evtchn_port_or_error_t console_evtchn; +static xentoollog_level minmsglevel = XTL_PROGRESS; +static void *logger; static struct option options[] = { { "kernel", 1, NULL, 'k' }, @@ -141,19 +143,33 @@ static int build(xc_interface *xch) goto err; } + /* + * This is a bodge. We can't currently inspect the kernel's ELF notes + * ahead of attempting to construct a domain, so try PVH first, suppressing + * errors by setting min level to high, and fall back to PV. + */ dom->container_type = XC_DOM_HVM_CONTAINER; + xtl_stdiostream_set_minlevel(logger, XTL_CRITICAL); rv = xc_dom_parse_image(dom); + xtl_stdiostream_set_minlevel(logger, minmsglevel); if ( rv ) { dom->container_type = XC_DOM_PV_CONTAINER; rv = xc_dom_parse_image(dom); if ( rv ) { - fprintf(stderr, "xc_dom_parse_image failed\n"); - goto err; + /* Retry PVH, now with normal logging level. */ + dom->container_type = XC_DOM_HVM_CONTAINER; + rv = xc_dom_parse_image(dom); + if ( rv ) + { + fprintf(stderr, "xc_dom_parse_image failed\n"); + goto err; + } } } - else + + if ( dom->container_type == XC_DOM_HVM_CONTAINER ) { config.flags |= XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; config.arch.emulation_flags = XEN_X86_EMU_LAPIC; @@ -412,8 +428,6 @@ int main(int argc, char** argv) char buf[16], be_path[64], fe_path[64]; int rv, fd; char *maxmem_str = NULL; - xentoollog_level minmsglevel = XTL_PROGRESS; - xentoollog_logger *logger = NULL; while ( (opt = getopt_long(argc, argv, "v", options, NULL)) != -1 ) { @@ -456,9 +470,7 @@ int main(int argc, char** argv) return 2; } - logger = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, - minmsglevel, 0); - + logger = xtl_createlogger_stdiostream(stderr, minmsglevel, 0); xch = xc_interface_open(logger, logger, 0); if ( !xch ) { ++++++ xen.bug1026236.suse_vtsc_tolerance.patch ++++++ --- /var/tmp/diff_new_pack.dLb4nZ/_old 2023-02-14 16:43:08.725631901 +0100 +++ /var/tmp/diff_new_pack.dLb4nZ/_new 2023-02-14 16:43:08.729631925 +0100 @@ -8,46 +8,44 @@ the hostadmin to decide how much tolerance all running domUs can actually handle. The default is zero tolerance. -Index: xen-4.17.0-testing/xen/arch/x86/time.c -=================================================================== ---- xen-4.17.0-testing.orig/xen/arch/x86/time.c -+++ xen-4.17.0-testing/xen/arch/x86/time.c +--- a/xen/arch/x86/time.c ++++ b/xen/arch/x86/time.c @@ -47,6 +47,9 @@ static char __initdata opt_clocksource[10]; string_param("clocksource", opt_clocksource); -+static unsigned int __read_mostly opt_suse_vtsc_tolerance; ++static unsigned int __ro_after_init opt_suse_vtsc_tolerance; +integer_param("suse_vtsc_tolerance", opt_suse_vtsc_tolerance); + unsigned long __read_mostly cpu_khz; /* CPU clock frequency in kHz. */ DEFINE_SPINLOCK(rtc_lock); unsigned long pit0_ticks; -@@ -2581,6 +2584,7 @@ int tsc_set_info(struct domain *d, +@@ -2581,6 +2584,8 @@ int tsc_set_info(struct domain *d, switch ( tsc_mode ) { + bool disable_vtsc; ++ case TSC_MODE_DEFAULT: case TSC_MODE_ALWAYS_EMULATE: d->arch.vtsc_offset = get_s_time() - elapsed_nsec; -@@ -2594,8 +2598,26 @@ int tsc_set_info(struct domain *d, +@@ -2594,8 +2599,25 @@ int tsc_set_info(struct domain *d, * When a guest is created, gtsc_khz is passed in as zero, making * d->arch.tsc_khz == cpu_khz. Thus no need to check incarnation. */ + disable_vtsc = d->arch.tsc_khz == cpu_khz; + -+ if ( tsc_mode == TSC_MODE_DEFAULT && gtsc_khz && -+ is_hvm_domain(d) && opt_suse_vtsc_tolerance ) ++ if ( tsc_mode == TSC_MODE_DEFAULT && !disable_vtsc && ++ opt_suse_vtsc_tolerance && is_hvm_domain(d) ) + { -+ long khz_diff; ++ long khz_diff = ABS((long)cpu_khz - gtsc_khz); + -+ khz_diff = ABS(((long)cpu_khz - gtsc_khz)); + disable_vtsc = khz_diff <= opt_suse_vtsc_tolerance; + -+ printk(XENLOG_G_INFO "d%d: host has %lu kHz," ++ printk(XENLOG_G_INFO "%pd: host has %lu kHz," + " domU expects %u kHz," + " difference of %ld is %s tolerance of %u\n", -+ d->domain_id, cpu_khz, gtsc_khz, khz_diff, ++ d, cpu_khz, gtsc_khz, khz_diff, + disable_vtsc ? "within" : "outside", + opt_suse_vtsc_tolerance); + }
