June 2024 - Linux-stable-mirror

[PATCH v1 0/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)chromium.org> When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it didn't have proper documentation. This led to a lot of confusion, especially about whether or not memfd created with the MFD_NOEXEC_SEAL flag is sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set MFD_ALLOW_SEALING to be sealable, so it's a fair question. As one might have noticed, unlike other flags in memfd_create, MFD_NOEXEC_SEAL is actually a combination of multiple flags. The idea is to make it easier to use memfd in the most common way, which is NOEXEC + F_SEAL_EXEC + MFD_ALLOW_SEALING. This works with sysctl vm.noexec to help existing applications move to a more secure way of using memfd. Proposals have been made to put MFD_NOEXEC_SEAL non-sealable, unless MFD_ALLOW_SEALING is set, to be consistent with other flags [1] [2], Those are based on the viewpoint that each flag is an atomic unit, which is a reasonable assumption. However, MFD_NOEXEC_SEAL was designed with the intent of promoting the most secure method of using memfd, therefore a combination of multiple functionalities into one bit. Furthermore, the MFD_NOEXEC_SEAL has been added for more than one year, and multiple applications and distributions have backported and utilized it. Altering ABI now presents a degree of risk and may lead to disruption. MFD_NOEXEC_SEAL is a new flag, and applications must change their code to use it. There is no backward compatibility problem. When sysctl vm.noexec == 1 or 2, applications that don't set MFD_NOEXEC_SEAL or MFD_EXEC will get MFD_NOEXEC_SEAL memfd. And old-application might break, that is by-design, in such a system vm.noexec = 0 shall be used. Also no backward compatibility problem. I propose to include this documentation patch to assist in clarifying the semantics of MFD_NOEXEC_SEAL, thereby preventing any potential future confusion. This patch supersede previous patch which is trying different direction [3], and please remove [2] from mm-unstable branch when applying this patch. Finally, I would like to express my gratitude to David Rheinsberg and Barnabás Pőcze for initiating the discussion on the topic of sealability. [1] https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ [2] https://lore.kernel.org/lkml/20240513191544.94754-1-pobrn@protonmail.com/ [3] https://lore.kernel.org/lkml/20240524033933.135049-1-jeffxu@google.com/ Jeff Xu (1): mm/memfd: add documentation for MFD_NOEXEC_SEAL MFD_EXEC Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/mfd_noexec.rst | 86 ++++++++++++++++++++++ 2 files changed, 87 insertions(+) create mode 100644 Documentation/userspace-api/mfd_noexec.rst -- 2.45.2.505.gda0bf45e8d-goog

4 months, 1 week

6
6
0 0

[PATCH net 0/4] mptcp: various fixes

by Matthieu Baerts (NGI0)

The different patches here are some unrelated fixes for MPTCP: - Patch 1 ensures 'snd_una' is initialised on connect in case of MPTCP fallback to TCP followed by retransmissions before the processing of any other incoming packets. A fix for v5.9+. - Patch 2 makes sure the RmAddr MIB counter is incremented, and only once per ID, upon the reception of a RM_ADDR. A fix for v5.10+. - Patch 3 doesn't update 'add addr' related counters if the connect() was not possible. A fix for v5.7+. - Patch 4 updates the mailmap file to add Geliang's new email address. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Geliang Tang (1): mailmap: map Geliang's new email address Paolo Abeni (1): mptcp: ensure snd_una is properly initialized on connect YonglongLi (2): mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID mptcp: pm: update add_addr counters after connect .mailmap | 1 + net/mptcp/pm_netlink.c | 21 ++++++++++++++------- net/mptcp/protocol.c | 1 + tools/testing/selftests/net/mptcp/mptcp_join.sh | 5 +++-- 4 files changed, 19 insertions(+), 9 deletions(-) --- base-commit: c44711b78608c98a3e6b49ce91678cd0917d5349 change-id: 20240607-upstream-net-20240607-misc-fixes-024007171d60 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

4 months, 1 week

2
4
0 0

[PATCH v2] kbuild: Install dtb files as 0644 in Makefile.dtbinst

by Dragan Simic

The compiled dtb files aren't executable, so install them with 0644 as their permission mode, instead of defaulting to 0755 for the permission mode and installing them with the executable bits set. Some Linux distributions, including Debian, [1][2][3] already include fixes in their kernel package build recipes to change the dtb file permissions to 0644 in their kernel packages. These changes, when additionally propagated into the long-term kernel versions, will allow such distributions to remove their downstream fixes. [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749 [3] https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/rules.real?… Cc: Diederik de Haas <didi.debian(a)cknow.org> Cc: stable(a)vger.kernel.org Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more") Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- Notes: Changes in v2: - Improved the patch description, to include additional details and to address the patch submission issues pointed out by Greg K-H [4] - No changes were made to the patch itself Link to v1: https://lore.kernel.org/linux-kbuild/ae087ef1715142f606ba6477ace3e4111972cf… [4] https://lore.kernel.org/linux-kbuild/2024061006-ladylike-paving-a36b@gregkh/ scripts/Makefile.dtbinst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.dtbinst b/scripts/Makefile.dtbinst index 67956f6496a5..9d920419a62c 100644 --- a/scripts/Makefile.dtbinst +++ b/scripts/Makefile.dtbinst @@ -17,7 +17,7 @@ include $(srctree)/scripts/Kbuild.include dst := $(INSTALL_DTBS_PATH) quiet_cmd_dtb_install = INSTALL $@ - cmd_dtb_install = install -D $< $@ + cmd_dtb_install = install -D -m 0644 $< $@ $(dst)/%: $(obj)/% $(call cmd,dtb_install)

4 months, 1 week

3
3
0 0

[PATCH v2 0/9] arm64: dts: imx8qm: add subsystem lvds and mipi

by Frank Li

Add subsystem lvds and mipi. Add pwm and i2c in lvds and mipi. imx8qm-mek: - add remove-proc - fixed gpio number error for vmmc - add usb3 and typec - add pwm and i2c in lvds and mipi DTB_CHECK warning fixed by seperate patches. arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: usb@5b110000: usb@5b120000: 'port', 'usb-role-switch' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/usb/fsl,imx8qm-cdns3.yaml# arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: usb@5b120000: 'port', 'usb-role-switch' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/usb/cdns,usb3.yaml# ** binding fix patch: https://lore.kernel.org/imx/20240606161509.3201080-1-Frank.Li@nxp.com/T/#u arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: interrupt-controller@56240000: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/interrupt-controller/fsl,irqsteer.yaml# ** binding fix patch: https://lore.kernel.org/imx/20240528071141.92003-1-alexander.stein@ew.tq-gr… arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: pwm@56244000: 'oneOf' conditional failed, one must be fixed: 'interrupts' is a required property 'interrupts-extended' is a required property from schema $id: http://devicetree.org/schemas/pwm/imx-pwm.yaml# ** binding fix patch: https://lore.kernel.org/imx/dc9accba-78af-45ec-a516-b89f2d4f4b03@kernel.org… from schema $id: http://devicetree.org/schemas/interrupt-controller/fsl,irqsteer.yaml# arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: imx8qm-cm4-0: power-domains: [[15, 278], [15, 297]] is too short from schema $id: http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml# arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: imx8qm-cm4-1: power-domains: [[15, 298], [15, 317]] is too short ** binding fix patch: https://lore.kernel.org/imx/20240606150030.3067015-1-Frank.Li@nxp.com/T/#u Signed-off-by: Frank Li <Frank.Li(a)nxp.com> --- Changes in v2: Changes in v2: - split common lvds and mipi part to seperate dtsi file. - num-interpolated-steps = <100> - irq-steer add "fsl,imx8qm-irqsteer" - using mux-controller - move address-cells common dtsi - Link to v1: https://lore.kernel.org/r/20240606-imx8qm-dts-usb-v1-0-565721b64f25@nxp.com --- Frank Li (9): arm64: dts: imx8: add basic lvds and lvds2 subsystem arm64: dts: imx8qm: add lvds subsystem arm64: dts: imx8: add basic mipi subsystem arm64: dts: imx8qm: add mipi subsystem arm64: dts: imx8qm-mek: add cm4 remote-proc and related memory region arm64: dts: imx8qm-mek: add pwm and i2c in lvds subsystem arm64: dts: imx8qm-mek: add i2c in mipi[0,1] subsystem arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc arm64: dts: imx8qm-mek: add usb 3.0 and related type C nodes arch/arm64/boot/dts/freescale/imx8-ss-lvds0.dtsi | 63 +++++ arch/arm64/boot/dts/freescale/imx8-ss-lvds1.dtsi | 114 +++++++++ arch/arm64/boot/dts/freescale/imx8-ss-mipi0.dtsi | 138 +++++++++++ arch/arm64/boot/dts/freescale/imx8-ss-mipi1.dtsi | 138 +++++++++++ arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 280 +++++++++++++++++++++- arch/arm64/boot/dts/freescale/imx8qm-ss-lvds.dtsi | 77 ++++++ arch/arm64/boot/dts/freescale/imx8qm.dtsi | 27 +++ 7 files changed, 836 insertions(+), 1 deletion(-) --- base-commit: ee78a17615ad0cfdbbc27182b1047cd36c9d4d5f change-id: 20240606-imx8qm-dts-usb-9c55d2bfe526 Best regards, --- Frank Li <Frank.Li(a)nxp.com>

4 months, 1 week

2
2
0 0

[tip: timers/urgent] tick/nohz_full: Don't abuse smp_call_function_single() in tick_setup_device()

by tip-bot2 for Oleg Nesterov

The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 07c54cc5988f19c9642fd463c2dbdac7fc52f777 Gitweb: https://git.kernel.org/tip/07c54cc5988f19c9642fd463c2dbdac7fc52f777 Author: Oleg Nesterov <oleg(a)redhat.com> AuthorDate: Tue, 28 May 2024 14:20:19 +02:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 10 Jun 2024 20:18:13 +02:00 tick/nohz_full: Don't abuse smp_call_function_single() in tick_setup_device() After the recent commit 5097cbcb38e6 ("sched/isolation: Prevent boot crash when the boot CPU is nohz_full") the kernel no longer crashes, but there is another problem. In this case tick_setup_device() calls tick_take_do_timer_from_boot() to update tick_do_timer_cpu and this triggers the WARN_ON_ONCE(irqs_disabled) in smp_call_function_single(). Kill tick_take_do_timer_from_boot() and just use WRITE_ONCE(), the new comment explains why this is safe (thanks Thomas!). Fixes: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full") Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240528122019.GA28794@redhat.com Link: https://lore.kernel.org/all/20240522151742.GA10400@redhat.com --- kernel/time/tick-common.c | 42 ++++++++++++-------------------------- 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index d88b130..a47bcf7 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -178,26 +178,6 @@ void tick_setup_periodic(struct clock_event_device *dev, int broadcast) } } -#ifdef CONFIG_NO_HZ_FULL -static void giveup_do_timer(void *info) -{ - int cpu = *(unsigned int *)info; - - WARN_ON(tick_do_timer_cpu != smp_processor_id()); - - tick_do_timer_cpu = cpu; -} - -static void tick_take_do_timer_from_boot(void) -{ - int cpu = smp_processor_id(); - int from = tick_do_timer_boot_cpu; - - if (from >= 0 && from != cpu) - smp_call_function_single(from, giveup_do_timer, &cpu, 1); -} -#endif - /* * Setup the tick device */ @@ -221,19 +201,25 @@ static void tick_setup_device(struct tick_device *td, tick_next_period = ktime_get(); #ifdef CONFIG_NO_HZ_FULL /* - * The boot CPU may be nohz_full, in which case set - * tick_do_timer_boot_cpu so the first housekeeping - * secondary that comes up will take do_timer from - * us. + * The boot CPU may be nohz_full, in which case the + * first housekeeping secondary will take do_timer() + * from it. */ if (tick_nohz_full_cpu(cpu)) tick_do_timer_boot_cpu = cpu; - } else if (tick_do_timer_boot_cpu != -1 && - !tick_nohz_full_cpu(cpu)) { - tick_take_do_timer_from_boot(); + } else if (tick_do_timer_boot_cpu != -1 && !tick_nohz_full_cpu(cpu)) { tick_do_timer_boot_cpu = -1; - WARN_ON(READ_ONCE(tick_do_timer_cpu) != cpu); + /* + * The boot CPU will stay in periodic (NOHZ disabled) + * mode until clocksource_done_booting() called after + * smp_init() selects a high resolution clocksource and + * timekeeping_notify() kicks the NOHZ stuff alive. + * + * So this WRITE_ONCE can only race with the READ_ONCE + * check in tick_periodic() but this race is harmless. + */ + WRITE_ONCE(tick_do_timer_cpu, cpu); #endif }

4 months, 1 week

2
1
0 0

+ gcov-add-support-for-gcc-14.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: gcov: add support for GCC 14 has been added to the -mm mm-hotfixes-unstable branch. Its filename is gcov-add-support-for-gcc-14.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Peter Oberparleiter <oberpar(a)linux.ibm.com> Subject: gcov: add support for GCC 14 Date: Mon, 10 Jun 2024 11:27:43 +0200 Using gcov on kernels compiled with GCC 14 results in truncated 16-byte long .gcda files with no usable data. To fix this, update GCOV_COUNTERS to match the value defined by GCC 14. Tested with GCC versions 14.1.0 and 13.2.0. Link: https://lkml.kernel.org/r/20240610092743.1609845-1-oberpar@linux.ibm.com Signed-off-by: Peter Oberparleiter <oberpar(a)linux.ibm.com> Reported-by: Allison Henderson <allison.henderson(a)oracle.com> Reported-by: Chuck Lever III <chuck.lever(a)oracle.com> Tested-by: Chuck Lever <chuck.lever(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/gcov/gcc_4_7.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/kernel/gcov/gcc_4_7.c~gcov-add-support-for-gcc-14 +++ a/kernel/gcov/gcc_4_7.c @@ -18,7 +18,9 @@ #include <linux/mm.h> #include "gcov.h" -#if (__GNUC__ >= 10) +#if (__GNUC__ >= 14) +#define GCOV_COUNTERS 9 +#elif (__GNUC__ >= 10) #define GCOV_COUNTERS 8 #elif (__GNUC__ >= 7) #define GCOV_COUNTERS 9 _ Patches currently in -mm which might be from oberpar(a)linux.ibm.com are gcov-add-support-for-gcc-14.patch

4 months, 1 week

1
0
0 0

[PATCH v2] Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot

by Zijun Hu

Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree. Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Cc: stable(a)vger.kernel.org Reported-by: Wren Turkal <wt(a)penguintechs.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> Tested-by: Wren Turkal <wt(a)penguintechs.org> --- V1 -> V2: Add comments and more commit messages V1 discussion link: https://lore.kernel.org/linux-bluetooth/d553edef-c1a4-4d52-a892-715549d31eb… drivers/bluetooth/hci_qca.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 0c9c9ee56592..9a0bc86f9aac 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2450,15 +2450,27 @@ static void qca_serdev_shutdown(struct device *dev) struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); struct hci_uart *hu = &qcadev->serdev_hu; struct hci_dev *hdev = hu->hdev; - struct qca_data *qca = hu->priv; const u8 ibs_wake_cmd[] = { 0xFD }; const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; if (qcadev->btsoc_type == QCA_QCA6390) { - if (test_bit(QCA_BT_OFF, &qca->flags) || - !test_bit(HCI_RUNNING, &hdev->flags)) + /* The purpose of sending the VSC is to reset SOC into a initial + * state and the state will ensure next hdev->setup() success. + * if HCI_QUIRK_NON_PERSISTENT_SETUP is set, it means that + * hdev->setup() can do its job regardless of SoC state, so + * don't need to send the VSC. + * if HCI_SETUP is set, it means that hdev->setup() was never + * invoked and the SOC is already in the initial state, so + * don't also need to send the VSC. + */ + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || + hci_dev_test_flag(hdev, HCI_SETUP)) return; + /* The serdev must be in open state when conrol logic arrives + * here, so also fix the use-after-free issue caused by that + * the serdev is flushed or wrote after it is closed. + */ serdev_device_write_flush(serdev); ret = serdev_device_write_buf(serdev, ibs_wake_cmd, sizeof(ibs_wake_cmd)); -- 2.7.4

4 months, 1 week

6
24
0 0

[PATCH v3] kobject_uevent: Fix OOB access within zap_modalias_env()

by Zijun Hu

zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove. Fixes: 9b3fa47d4a76 ("kobject: fix suppressing modalias in uevents delivered over netlink") Cc: stable(a)vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- V3: Correct inline comments and take Dmitry's suggestion V2: Correct commit messages and add inline comments Previous discussion links: https://lore.kernel.org/lkml/ZlYo20ztfLWPyy5d@google.com/ https://lore.kernel.org/lkml/0b916393-eb39-4467-9c99-ac1bc9746512@quicinc.c… lib/kobject_uevent.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c index 03b427e2707e..b7f2fa08d9c8 100644 --- a/lib/kobject_uevent.c +++ b/lib/kobject_uevent.c @@ -433,8 +433,23 @@ static void zap_modalias_env(struct kobj_uevent_env *env) len = strlen(env->envp[i]) + 1; if (i != env->envp_idx - 1) { + /* @env->envp[] contains pointers to @env->buf[] + * with @env->buflen chars, and we are removing + * variable MODALIAS here pointed by @env->envp[i] + * with length @len as shown below: + * + * 0 @env->buf[] @env->buflen + * --------------------------------------------- + * ^ ^ ^ ^ + * | |-> @len <-| target block | + * @env->envp[0] @env->envp[i] @env->envp[i + 1] + * + * so the "target block" indicated above is moved + * backward by @len, and its right size is + * @env->buflen - (@env->envp[i + 1] - @env->envp[0]). + */ memmove(env->envp[i], env->envp[i + 1], - env->buflen - len); + env->buflen - (env->envp[i + 1] - env->envp[0])); for (j = i; j < env->envp_idx - 1; j++) env->envp[j] = env->envp[j + 1] - len; -- 2.7.4

4 months, 1 week

2
1
0 0

Re: [PATCH v2 1/1] Bluetooth: btrtl: Add missing MODULE_FIRMWARE declarations

by Vitaly Chikunov

Greg, Sasha, Please add this patch to 6.1.x branch. Mainline commit bb23f07cb63975968bbabe314486e2b087234fc5 This will fix Bluetooth support (visibility of devices) and manifested errors during boot: bluetooth hci0: Direct firmware load for rtl_bt/rtl8822cu_fw.bin failed with error -2 Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8822cu_fw.bin not found Downstream bug report: https://bugzilla.altlinux.org/50471 Thanks, On Tue, May 09, 2023 at 12:51:19PM -0700, Dan Gora wrote: > Add missing MODULE_FIRMWARE declarations for firmware referenced in > btrtl.c. > > Signed-off-by: Dan Gora <dan.gora(a)gmail.com> > --- > drivers/bluetooth/btrtl.c | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c > index 2915c82d719d..d978e7cea873 100644 > --- a/drivers/bluetooth/btrtl.c > +++ b/drivers/bluetooth/btrtl.c > @@ -1367,14 +1367,30 @@ MODULE_FIRMWARE("rtl_bt/rtl8723cs_vf_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8723cs_vf_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8723cs_xx_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8723cs_xx_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8723d_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8723d_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8723ds_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8723ds_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8761a_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8761a_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8761b_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8761b_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8761bu_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8761bu_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8821a_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8821a_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8821c_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8821c_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8821cs_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8821cs_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8822b_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8822b_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8822cs_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8822cs_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8822cu_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8822cu_config.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8851bu_fw.bin"); > +MODULE_FIRMWARE("rtl_bt/rtl8851bu_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8852au_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8852au_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8852bs_fw.bin"); > @@ -1383,5 +1399,3 @@ MODULE_FIRMWARE("rtl_bt/rtl8852bu_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8852bu_config.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8852cu_fw.bin"); > MODULE_FIRMWARE("rtl_bt/rtl8852cu_config.bin"); > -MODULE_FIRMWARE("rtl_bt/rtl8851bu_fw.bin"); > -MODULE_FIRMWARE("rtl_bt/rtl8851bu_config.bin"); > -- > 2.35.1.102.g2b9c120970 >

4 months, 1 week

1
0
0 0

[PATCH v6 00/10] x86/sev: KEXEC/KDUMP support for SEV-ES guests

by vsntk18＠gmail.com

From: Vasant Karasulli <vkarasulli(a)suse.de> Hi, here are changes to enable kexec/kdump in SEV-ES guests. The biggest problem for supporting kexec/kdump under SEV-ES is to find a way to hand the non-boot CPUs (APs) from one kernel to another. Without SEV-ES the first kernel parks the CPUs in a HLT loop until they get reset by the kexec'ed kernel via an INIT-SIPI-SIPI sequence. For virtual machines the CPU reset is emulated by the hypervisor, which sets the vCPU registers back to reset state. This does not work under SEV-ES, because the hypervisor has no access to the vCPU registers and can't make modifications to them. So an SEV-ES guest needs to reset the vCPU itself and park it using the AP-reset-hold protocol. Upon wakeup the guest needs to jump to real-mode and to the reset-vector configured in the AP-Jump-Table. The code to do this is the main part of this patch-set. It works by placing code on the AP Jump-Table page itself to park the vCPU and for jumping to the reset vector upon wakeup. The code on the AP Jump Table runs in 16-bit protected mode with segment base set to the beginning of the page. The AP Jump-Table is usually not within the first 1MB of memory, so the code can't run in real-mode. The AP Jump-Table is the best place to put the parking code, because the memory is owned, but read-only by the firmware and writeable by the OS. Only the first 4 bytes are used for the reset-vector, leaving the rest of the page for code/data/stack to park a vCPU. The code can't be in kernel memory because by the time the vCPU wakes up the memory will be owned by the new kernel, which might have overwritten it already. The other patches add initial GHCB Version 2 protocol support, because kexec/kdump need the MSR-based (without a GHCB) AP-reset-hold VMGEXIT, which is a GHCB protocol version 2 feature. The kexec'ed kernel is also entered via the decompressor and needs MMIO support there, so this patch-set also adds MMIO #VC support to the decompressor and support for handling CLFLUSH instructions. Finally there is also code to disable kexec/kdump support at runtime when the environment does not support it (e.g. no GHCB protocol version 2 support or AP Jump Table over 4GB). The diffstat looks big, but most of it is moving code for MMIO #VC support around to make it available to the decompressor. The previous version of this patch-set can be found here: https://lore.kernel.org/kvm/20240408074049.7049-1-vsntk18@gmail.com/ Please review. Thanks, Vasant Changes v5->v6: - Rebased to v6.10-rc3 kernel Changes v4->v5: - Rebased to v6.9-rc2 kernel - Applied review comments by Tom Lendacky - Exclude the AP jump table related code for SEV-SNP guests Changes v3->v4: - Rebased to v6.8 kernel - Applied review comments by Sean Christopherson - Combined sev_es_setup_ap_jump_table() and sev_setup_ap_jump_table() into a single function which makes caching jump table address unnecessary - annotated struct sev_ap_jump_table_header with __packed attribute - added code to set up real mode data segment at boot time instead of hardcoding the value. Joerg Roedel (9): x86/kexec/64: Disable kexec when SEV-ES is active x86/sev: Save and print negotiated GHCB protocol version x86/sev: Set GHCB data structure version x86/sev: Setup code to park APs in the AP Jump Table x86/sev: Park APs on AP Jump Table with GHCB protocol version 2 x86/sev: Use AP Jump Table blob to stop CPU x86/sev: Add MMIO handling support to boot/compressed/ code x86/sev: Handle CLFLUSH MMIO events x86/kexec/64: Support kexec under SEV-ES with AP Jump Table Blob Vasant Karasulli (1): x86/sev: Exclude AP jump table related code for SEV-SNP guests arch/x86/boot/compressed/sev.c | 45 +- arch/x86/include/asm/insn-eval.h | 1 + arch/x86/include/asm/realmode.h | 5 + arch/x86/include/asm/sev-ap-jumptable.h | 30 + arch/x86/include/asm/sev.h | 7 + arch/x86/kernel/machine_kexec_64.c | 12 + arch/x86/kernel/process.c | 8 + arch/x86/kernel/sev-shared.c | 234 +++++- arch/x86/kernel/sev.c | 376 +++++----- arch/x86/lib/insn-eval-shared.c | 921 ++++++++++++++++++++++++ arch/x86/lib/insn-eval.c | 911 +---------------------- arch/x86/realmode/Makefile | 9 +- arch/x86/realmode/init.c | 5 +- arch/x86/realmode/rm/Makefile | 11 +- arch/x86/realmode/rm/header.S | 3 + arch/x86/realmode/rm/sev.S | 85 +++ arch/x86/realmode/rmpiggy.S | 6 + arch/x86/realmode/sev/Makefile | 33 + arch/x86/realmode/sev/ap_jump_table.S | 131 ++++ arch/x86/realmode/sev/ap_jump_table.lds | 24 + 20 files changed, 1711 insertions(+), 1146 deletions(-) create mode 100644 arch/x86/include/asm/sev-ap-jumptable.h create mode 100644 arch/x86/lib/insn-eval-shared.c create mode 100644 arch/x86/realmode/rm/sev.S create mode 100644 arch/x86/realmode/sev/Makefile create mode 100644 arch/x86/realmode/sev/ap_jump_table.S create mode 100644 arch/x86/realmode/sev/ap_jump_table.lds base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670 -- 2.34.1

4 months, 1 week

3
11
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024