- Linux-stable-mirror - lists.linaro.org

[PATCH v5 3/3] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression

by Khushit Shah

Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support for Suppress EOI Broadcasts, which KVM completely mishandles. When x2APIC support was first added, KVM incorrectly advertised and "enabled" Suppress EOI Broadcast, without fully supporting the I/O APIC side of the equation, i.e. without adding directed EOI to KVM's in-kernel I/O APIC. That flaw was carried over to split IRQCHIP support, i.e. KVM advertised support for Suppress EOI Broadcasts irrespective of whether or not the userspace I/O APIC implementation supported directed EOIs. Even worse, KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without support for directed EOI came to rely on the "spurious" broadcasts. KVM "fixed" the in-kernel I/O APIC implementation by completely disabling support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but didn't do anything to remedy userspace I/O APIC implementations. KVM's bogus handling of Suppress EOI Broadcast is problematic when the guest relies on interrupts being masked in the I/O APIC until well after the initial local APIC EOI. E.g. Windows with Credential Guard enabled handles interrupts in the following order: 1. Interrupt for L2 arrives. 2. L1 APIC EOIs the interrupt. 3. L1 resumes L2 and injects the interrupt. 4. L2 EOIs after servicing. 5. L1 performs the I/O APIC EOI. Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt storm, e.g. if the IRQ line is still asserted and userspace reacts to the EOI by re-injecting the IRQ, because the guest doesn't de-assert the line until step #4, and doesn't expect the interrupt to be re-enabled until step #5. Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way of knowing if the userspace I/O APIC supports directed EOIs, i.e. suppressing EOI broadcasts would result in interrupts being stuck masked in the userspace I/O APIC due to step #5 being ignored by userspace. And fully disabling support for Suppress EOI Broadcast is also undesirable, as picking up the fix would require a guest reboot, *and* more importantly would change the virtual CPU model exposed to the guest without any buy-in from userspace. Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to explicitly enable or disable support for Suppress EOI Broadcasts. This gives userspace control over the virtual CPU model exposed to the guest, as KVM should never have enabled support for Suppress EOI Broadcast without userspace opt-in. Not setting either flag will result in legacy quirky behavior for backward compatibility. When KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST is set and using in-kernel IRQCHIP mode, KVM will use I/O APIC version 0x20, which includes support for the EOI Register. Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's APM. But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI is to support Directed EOI (KVM's name) irrespective of guest CPU vendor. Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs") Closes: https://lore.kernel.org/kvm/7D497EF1-607D-4D37-98E7-DAF95F099342@nutanix.com Cc: stable(a)vger.kernel.org Suggested-by: David Woodhouse <dwmw2(a)infradead.org> Co-developed-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Khushit Shah <khushit.shah(a)nutanix.com> --- Documentation/virt/kvm/api.rst | 28 +++++++++++++-- arch/x86/include/asm/kvm_host.h | 7 ++++ arch/x86/include/uapi/asm/kvm.h | 6 ++-- arch/x86/kvm/lapic.c | 64 ++++++++++++++++++++++----------- arch/x86/kvm/x86.c | 15 ++++++-- 5 files changed, 93 insertions(+), 27 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 57061fa29e6a..ad15ca519afc 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7800,8 +7800,10 @@ Will return -EBUSY if a VCPU has already been created. Valid feature flags in args[0] are:: - #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) - #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) + #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) + #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) + #define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (1ULL << 2) + #define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (1ULL << 3) Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC, @@ -7814,6 +7816,28 @@ as a broadcast even in x2APIC mode in order to support physical x2APIC without interrupt remapping. This is undesirable in logical mode, where 0xff represents CPUs 0-7 in cluster 0. +Setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST instructs KVM to enable +Suppress EOI Broadcasts. KVM will advertise support for Suppress EOI +Broadcast to the guest and suppress LAPIC EOI broadcasts when the guest +sets the Suppress EOI Broadcast bit in the SPIV register. When using +in-kernel IRQCHIP mode, enabling this capability will cause KVM to use +I/O APIC version 0x20, which includes support for the EOI Register for +directed EOI. + +Setting KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST disables support for +Suppress EOI Broadcasts entirely, i.e. instructs KVM to NOT advertise +support to the guest. + +Modern VMMs should either enable KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST +or KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST. If not, legacy quirky +behavior will be used by KVM: in split IRQCHIP mode, KVM will advertise +support for Suppress EOI Broadcasts but not actually suppress EOI +broadcasts; for in-kernel IRQCHIP mode, KVM will not advertise support for +Suppress EOI Broadcasts. + +Setting both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and +KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST will fail with an EINVAL error. + 7.8 KVM_CAP_S390_USER_INSTR0 ---------------------------- diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 48598d017d6f..4a6d94dc7a2a 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1229,6 +1229,12 @@ enum kvm_irqchip_mode { KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */ }; +enum kvm_suppress_eoi_broadcast_mode { + KVM_SUPPRESS_EOI_BROADCAST_QUIRKED, /* Legacy behavior */ + KVM_SUPPRESS_EOI_BROADCAST_ENABLED, /* Enable Suppress EOI broadcast */ + KVM_SUPPRESS_EOI_BROADCAST_DISABLED /* Disable Suppress EOI broadcast */ +}; + struct kvm_x86_msr_filter { u8 count; bool default_allow:1; @@ -1480,6 +1486,7 @@ struct kvm_arch { bool x2apic_format; bool x2apic_broadcast_quirk_disabled; + enum kvm_suppress_eoi_broadcast_mode suppress_eoi_broadcast_mode; bool has_mapped_host_mmio; bool guest_can_read_msr_platform_info; diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h index d420c9c066d4..d30241429fa8 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -913,8 +913,10 @@ struct kvm_sev_snp_launch_finish { __u64 pad1[4]; }; -#define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) -#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) +#define KVM_X2APIC_API_USE_32BIT_IDS (_BITULL(0)) +#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (_BITULL(1)) +#define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (_BITULL(2)) +#define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (_BITULL(3)) struct kvm_hyperv_eventfd { __u32 conn_id; diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 2c24fd8d815f..36a5af218802 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -107,21 +107,31 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector) bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm) { - /* - * The default in-kernel I/O APIC emulates the 82093AA and does not - * implement an EOI register. Some guests (e.g. Windows with the - * Hyper-V role enabled) disable LAPIC EOI broadcast without checking - * the I/O APIC version, which can cause level-triggered interrupts to - * never be EOI'd. - * - * To avoid this, KVM must not advertise Suppress EOI Broadcast support - * when using the default in-kernel I/O APIC. - * - * Historically, in split IRQCHIP mode, KVM always advertised Suppress - * EOI Broadcast support but did not actually suppress EOIs, resulting - * in quirky behavior. - */ - return !ioapic_in_kernel(kvm); + switch (kvm->arch.suppress_eoi_broadcast_mode) { + case KVM_SUPPRESS_EOI_BROADCAST_ENABLED: + return true; + case KVM_SUPPRESS_EOI_BROADCAST_DISABLED: + return false; + case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED: + /* + * The default in-kernel I/O APIC emulates the 82093AA and does not + * implement an EOI register. Some guests (e.g. Windows with the + * Hyper-V role enabled) disable LAPIC EOI broadcast without + * checking the I/O APIC version, which can cause level-triggered + * interrupts to never be EOI'd. + * + * To avoid this, KVM must not advertise Suppress EOI Broadcast + * support when using the default in-kernel I/O APIC. + * + * Historically, in split IRQCHIP mode, KVM always advertised + * Suppress EOI Broadcast support but did not actually suppress + * EOIs, resulting in quirky behavior. + */ + return !ioapic_in_kernel(kvm); + default: + WARN_ON_ONCE(1); + return false; + } } bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm) @@ -129,13 +139,25 @@ bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm) /* * Returns true if KVM should honor the guest's request to suppress EOI * broadcasts, i.e. actually implement Suppress EOI Broadcast. - * - * Historically, in split IRQCHIP mode, KVM ignored the suppress EOI - * broadcast bit set by the guest and broadcasts EOIs to the userspace - * I/O APIC. For In-kernel I/O APIC, the support itself is not - * advertised, but if bit was set by the guest, it was respected. */ - return ioapic_in_kernel(kvm); + switch (kvm->arch.suppress_eoi_broadcast_mode) { + case KVM_SUPPRESS_EOI_BROADCAST_ENABLED: + return true; + case KVM_SUPPRESS_EOI_BROADCAST_DISABLED: + return false; + case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED: + /* + * Historically, in split IRQCHIP mode, KVM ignored the suppress + * EOI broadcast bit set by the guest and broadcasts EOIs to the + * userspace I/O APIC. For In-kernel I/O APIC, the support itself + * is not advertised, but if bit was set by the guest, it was + * respected. + */ + return ioapic_in_kernel(kvm); + default: + WARN_ON_ONCE(1); + return false; + } } __read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c9c2aa6f4705..5d56b0384dcc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -121,8 +121,10 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); #define KVM_CAP_PMU_VALID_MASK KVM_PMU_CAP_DISABLE -#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \ - KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK) +#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \ + KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK | \ + KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST | \ + KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST) static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); @@ -6778,11 +6780,20 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, if (cap->args[0] & ~KVM_X2APIC_API_VALID_FLAGS) break; + if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) && + (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)) + break; + if (cap->args[0] & KVM_X2APIC_API_USE_32BIT_IDS) kvm->arch.x2apic_format = true; if (cap->args[0] & KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK) kvm->arch.x2apic_broadcast_quirk_disabled = true; + if (cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_ENABLED; + if (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_DISABLED; + r = 0; break; case KVM_CAP_X86_DISABLE_EXITS: -- 2.39.3

8 hours, 32 minutes

1
0
0 0

[PATCH v2 0/3] PCI: dwc: Fix missing iATU setup when ECAM is enabled

by Krishna Chaitanya Chundru

When ECAM is enabled, the driver skipped calling dw_pcie_iatu_setup() before configuring ECAM iATU entries. This left IO and MEM outbound windows unprogrammed, resulting in broken IO transactions. Additionally, dw_pcie_config_ecam_iatu() was only called during host initialization, so ECAM-related iATU entries were not restored after suspend/resume, leading to failures in configuration space access. To resolve these issues, the ECAM iATU configuration is moved into dw_pcie_setup_rc(). At the same time, dw_pcie_iatu_setup() is invoked when ECAM is enabled. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru(a)oss.qualcomm.com> --- Changes in v2: - Fixed the index 0 of the ATU window skipping. - Keep the ob_atu_index in dw_pcie instead of dw_pcie_rp & couple of nitpicks (Bjorn). - Link to v1: https://lore.kernel.org/r/20251203-ecam_io_fix-v1-0-5cc3d3769c18@oss.qualco… --- Krishna Chaitanya Chundru (3): PCI: dwc: Fix skipped index 0 in outbound ATU setup PCI: dwc: Correct iATU index increment for MSG TLP region PCI: dwc: Fix missing iATU setup when ECAM is enabled drivers/pci/controller/dwc/pcie-designware-host.c | 53 ++++++++++++++--------- drivers/pci/controller/dwc/pcie-designware.c | 3 ++ drivers/pci/controller/dwc/pcie-designware.h | 2 +- 3 files changed, 37 insertions(+), 21 deletions(-) --- base-commit: 3f9f0252130e7dd60d41be0802bf58f6471c691d change-id: 20251203-ecam_io_fix-6e060fecd3b8 Best regards, -- Krishna Chaitanya Chundru <krishna.chundru(a)oss.qualcomm.com>

9 hours, 6 minutes

1
2
0 0

[PATCH V3 0/2] LoongArch: KVM: fix "unreliable stack" issue

by Xianglai Li

When starting multi-core loongarch virtualization on loongarch physical machine, loading livepatch on the physical machine will cause an error similar to the following: [ 411.686289] livepatch: klp_try_switch_task: CPU 31/KVM:3116 has an unreliable stack The specific test steps are as follows: 1.Start a multi-core virtual machine on a physical machine 2.Enter the following command on the physical machine to turn on the debug switch: echo "file kernel/livepatch/transition.c +p" > /sys/kernel/debug/\ dynamic_debug/control 3.Load livepatch: modprobe livepatch-sample Through the above steps, similar prints can be viewed in dmesg. The reason for this issue is that the code of the kvm_exc_entry function was copied in the function kvm_loongarch_env_init. When the cpu needs to execute kvm_exc_entry, it will switch to the copied address for execution. The new address of the kvm_exc_entry function cannot be recognized in ORC, which eventually leads to the arch_stack_walk_reliable function returning an error and printing an exception message. To solve the above problems, we directly compile the switch.S file into the kernel instead of the module. In this way, the function kvm_exc_entry will no longer need to be copied. changlog: V3<-V2: 1.Replace the EXPORT_SYMBOL macro declaration symbol with the EXPORT_SYMBOL_FOR_KVM macro 2.Add some comments in kvm_enter_guest 3.Place the correct pc address in era 4.Move .p2align after .text V2<-V1: 1.Rollback the modification of function parameter types such as kvm_save_fpu. In the asm-prototypes.h header file, only the parameter types it depends on are included Cc: Huacai Chen <chenhuacai(a)kernel.org> Cc: WANG Xuerui <kernel(a)xen0n.name> Cc: Tianrui Zhao <zhaotianrui(a)loongson.cn> Cc: Bibo Mao <maobibo(a)loongson.cn> Cc: Charlie Jenkins <charlie(a)rivosinc.com> Cc: Xianglai Li <lixianglai(a)loongson.cn> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: Tiezhu Yang <yangtiezhu(a)loongson.cn> Xianglai Li (2): LoongArch: KVM: Compile the switch.S file directly into the kernel LoongArch: KVM: fix "unreliable stack" issue arch/loongarch/Kbuild | 2 +- arch/loongarch/include/asm/asm-prototypes.h | 21 +++++++++++++ arch/loongarch/include/asm/kvm_host.h | 3 -- arch/loongarch/kvm/Makefile | 2 +- arch/loongarch/kvm/main.c | 35 ++------------------- arch/loongarch/kvm/switch.S | 32 ++++++++++++++++--- 6 files changed, 53 insertions(+), 42 deletions(-) base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 -- 2.39.1

9 hours, 7 minutes

5
10
0 0

[PATCH] misc: bcm-vk: validate entry_size before memcpy_fromio()

by Guangshuo Li

The driver trusts the 'num' and 'entry_size' fields read from BAR2 and uses them directly to compute the length for memcpy_fromio() without any bounds checking. If these fields get corrupted or otherwise contain invalid values, num * entry_size can exceed the size of proc_mon_info.entries and lead to a potential out-of-bounds write. Add validation for 'entry_size' by ensuring it is non-zero and that num * entry_size does not exceed the size of proc_mon_info.entries. Fixes: ff428d052b3b ("misc: bcm-vk: add get_card_info, peerlog_info, and proc_mon_info") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/misc/bcm-vk/bcm_vk_dev.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c index a16b99bdaa13..a4a74c10f02b 100644 --- a/drivers/misc/bcm-vk/bcm_vk_dev.c +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c @@ -439,6 +439,7 @@ static void bcm_vk_get_proc_mon_info(struct bcm_vk *vk) struct device *dev = &vk->pdev->dev; struct bcm_vk_proc_mon_info *mon = &vk->proc_mon_info; u32 num, entry_size, offset, buf_size; + size_t max_bytes; u8 *dst; /* calculate offset which is based on peerlog offset */ @@ -458,6 +459,9 @@ static void bcm_vk_get_proc_mon_info(struct bcm_vk *vk) num, BCM_VK_PROC_MON_MAX); return; } + if (!entry_size || (size_t)num > max_bytes / entry_size) { + return; + } mon->num = num; mon->entry_size = entry_size; -- 2.43.0

9 hours, 15 minutes

3
2
0 0

[PATCH 0/7] arm64: dts: rockchip: Sound fixes and additions on RK3576 boards

by Alexey Charkov

Here are some device tree updates to improve sound output on RK3576 boards. The first two patches fix analog audio output on FriendlyElec NanoPi M5, as it doesn't work with the current device tree. The third one is purely cosmetic, to present a more user-friendly sound card name to the userspace on NanoPi M5. The rest add new functionality: HDMI sound output on three boards that didn't enable it, and analog sound on RK3576 EVB1. Signed-off-by: Alexey Charkov <alchark(a)gmail.com> --- Alexey Charkov (7): arm64: dts: rockchip: Fix headphones widget name on NanoPi M5 arm64: dts: rockchip: Configure MCLK for analog sound on NanoPi M5 arm64: dts: rockchip: Use a readable audio card name on NanoPi M5 arm64: dts: rockchip: Enable HDMI sound on FriendlyElec NanoPi M5 arm64: dts: rockchip: Enable HDMI sound on Luckfox Core3576 arm64: dts: rockchip: Enable HDMI sound on RK3576 EVB1 arm64: dts: rockchip: Enable analog sound on RK3576 EVB1 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 107 +++++++++++++++++++++ .../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 8 ++ arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 22 ++++- 3 files changed, 132 insertions(+), 5 deletions(-) --- base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8 change-id: 20251222-rk3576-sound-0c26e3b16924 Best regards, -- Alexey Charkov <alchark(a)gmail.com>

9 hours, 37 minutes

1
2
0 0

[PATCH] arm64: dts: imx95: correct I3C2 pclk to IMX95_CLK_BUSWAKEUP

by Carlos Song

I3C2 is in WAKEUP domain. Its pclk should be IMX95_CLK_BUSWAKEUP. Fixes: 969497ebefcf ("arm64: dts: imx95: Add i3c1 and i3c2") Signed-off-by: Carlos Song <carlos.song(a)nxp.com> Cc: <stable(a)vger.kernel.org> --- arch/arm64/boot/dts/freescale/imx95.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi index e45014d50abe..a4d854817559 100644 --- a/arch/arm64/boot/dts/freescale/imx95.dtsi +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi @@ -828,7 +828,7 @@ i3c2: i3c@42520000 { interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>; #address-cells = <3>; #size-cells = <0>; - clocks = <&scmi_clk IMX95_CLK_BUSAON>, + clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>, <&scmi_clk IMX95_CLK_I3C2SLOW>; clock-names = "pclk", "fast_clk"; status = "disabled"; -- 2.34.1

11 hours, 19 minutes

3
2
0 0

[PATCH v2 3/3] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer

by Harshit Mogalapalli

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail. Cc: stable(a)vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb <paul.x.webb(a)oracle.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- V1-> V2: Added a line about carrying measure list across kexec based on suggestion from Mimi Zohar. Made use to the new generic helper [Suggestion from Borislav] --- arch/x86/kernel/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e1..383d4a4784f5 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,15 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) { + int ret; + if (!ima_kexec_buffer_size) return -ENOENT; + ret = ima_validate_range(ima_kexec_buffer_phys, ima_kexec_buffer_size); + if (ret) + return ret; + *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size; -- 2.50.1

11 hours, 34 minutes

1
0
0 0

[PATCH v2 2/3] of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range()

by Harshit Mogalapalli

Refactor the OF/DT ima_get_kexec_buffer() to use a generic helper to validate the address range. No functional change intended. Cc: stable(a)vger.kernel.org Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- drivers/of/kexec.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c index 1ee2d31816ae..c4cf3552c018 100644 --- a/drivers/of/kexec.c +++ b/drivers/of/kexec.c @@ -128,7 +128,6 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size) { int ret, len; unsigned long tmp_addr; - unsigned long start_pfn, end_pfn; size_t tmp_size; const void *prop; @@ -144,17 +143,9 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size) if (!tmp_size) return -ENOENT; - /* - * Calculate the PFNs for the buffer and ensure - * they are with in addressable memory. - */ - start_pfn = PHYS_PFN(tmp_addr); - end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1); - if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) { - pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n", - tmp_addr, tmp_size); - return -EINVAL; - } + ret = ima_validate_range(tmp_addr, tmp_size); + if (ret) + return ret; *addr = __va(tmp_addr); *size = tmp_size; -- 2.50.1

11 hours, 34 minutes

1
0
0 0

[PATCH v2 1/3] ima: Add ima_validate_range() for previous kernel IMA buffer

by Harshit Mogalapalli

When the second-stage kernel is booted with a limiting command line (e.g. "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore. Introduce a small generic helper, ima_validate_range(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfn_range_is_mapped(). - On OF based architectures, use page_is_ram(). Cc: stable(a)vger.kernel.org Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- include/linux/ima.h | 1 + security/integrity/ima/ima_kexec.c | 35 ++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) diff --git a/include/linux/ima.h b/include/linux/ima.h index 8e29cb4e6a01..abf8923f8fc5 100644 --- a/include/linux/ima.h +++ b/include/linux/ima.h @@ -69,6 +69,7 @@ static inline int ima_measure_critical_data(const char *event_label, #ifdef CONFIG_HAVE_IMA_KEXEC int __init ima_free_kexec_buffer(void); int __init ima_get_kexec_buffer(void **addr, size_t *size); +int ima_validate_range(phys_addr_t phys, size_t size); #endif #ifdef CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c index 7362f68f2d8b..8b24e3312ea0 100644 --- a/security/integrity/ima/ima_kexec.c +++ b/security/integrity/ima/ima_kexec.c @@ -12,6 +12,8 @@ #include <linux/kexec.h> #include <linux/of.h> #include <linux/ima.h> +#include <linux/mm.h> +#include <linux/overflow.h> #include <linux/reboot.h> #include <asm/page.h> #include "ima.h" @@ -296,3 +298,36 @@ void __init ima_load_kexec_buffer(void) pr_debug("Error restoring the measurement list: %d\n", rc); } } + +/* + * ima_validate_range - verify a physical buffer lies in addressable RAM + * @phys: physical start address of the buffer from previous kernel + * @size: size of the buffer + * + * On success return 0. On failure returns -EINVAL so callers can skip + * restoring. + */ +int ima_validate_range(phys_addr_t phys, size_t size) +{ + unsigned long start_pfn, end_pfn; + phys_addr_t end_phys; + + if (check_add_overflow(phys, (phys_addr_t)size - 1, &end_phys)) + return -EINVAL; + + start_pfn = PHYS_PFN(phys); + end_pfn = PHYS_PFN(end_phys); + +#ifdef CONFIG_X86 + if (!pfn_range_is_mapped(start_pfn, end_pfn)) +#else + if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) +#endif + { + pr_warn("IMA: previous kernel measurement buffer %pa (size 0x%zx) lies outside available memory\n", + &phys, size); + return -EINVAL; + } + + return 0; +} -- 2.50.1

11 hours, 34 minutes

1
0
0 0

[PATCH v2 0/3] Address page fault in ima_restore_measurement_list()

by Harshit Mogalapalli

On x86_64: When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") V1: https://lore.kernel.org/all/20251112193005.3772542-1-harshit.m.mogalapalli@… V1 attempted to do a similar sanity check in x86_64. Borislav suggested to add a generic helper ima_validate_range() which could then be used for both OF based and x86_64. Testing information: -------------------- On x86_64: With latest 6.19-rc2 based, we could reproduce the issue, and patched kernel works fine. (with mem=8G on a 16G memory machine) Thanks for the reviews on V1. V1 -> V2: - Patch 1: Add a generic helper "ima_validate_range()" - Patch 2: Use this new helper in drivers/of/kexec.c -> No functional change. - Patch 3: Fix the page fault by doing sanity check with "ima_validate_range()" Thanks, Harshit Harshit Mogalapalli (3): ima: Add ima_validate_range() for previous kernel IMA buffer of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() x86/kexec: Add a sanity check on previous kernel's ima kexec buffer arch/x86/kernel/setup.c | 6 +++++ drivers/of/kexec.c | 15 +++---------- include/linux/ima.h | 1 + security/integrity/ima/ima_kexec.c | 35 ++++++++++++++++++++++++++++++ 4 files changed, 45 insertions(+), 12 deletions(-) -- 2.50.1

11 hours, 34 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror