diff options
Diffstat (limited to 'arch_patches.patch')
| -rw-r--r-- | arch_patches.patch | 406 |
1 files changed, 0 insertions, 406 deletions
diff --git a/arch_patches.patch b/arch_patches.patch deleted file mode 100644 index 168bfd8bf220..000000000000 --- a/arch_patches.patch +++ /dev/null @@ -1,406 +0,0 @@ -From 063d50bafe25c4e997baab1caead7cbca7b49e79 Mon Sep 17 00:00:00 2001 -From: "Jan Alexander Steffens (heftig)" <jan.steffens@gmail.com> -Date: Mon, 16 Sep 2019 04:53:20 +0200 -Subject: [PATCH] ZEN: Add sysctl and CONFIG to disallow unprivileged - CLONE_NEWUSER - -Our default behavior continues to match the vanilla kernel. ---- - include/linux/user_namespace.h | 4 ++++ - init/Kconfig | 16 ++++++++++++++++ - kernel/fork.c | 14 ++++++++++++++ - kernel/sysctl.c | 12 ++++++++++++ - kernel/user_namespace.c | 7 +++++++ - 5 files changed, 53 insertions(+) - -diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h -index 33a4240e6a6f17..82213f9c4c17fb 100644 ---- a/include/linux/user_namespace.h -+++ b/include/linux/user_namespace.h -@@ -139,6 +139,8 @@ static inline void set_rlimit_ucount_max(struct user_namespace *ns, - - #ifdef CONFIG_USER_NS - -+extern int unprivileged_userns_clone; -+ - static inline struct user_namespace *get_user_ns(struct user_namespace *ns) - { - if (ns) -@@ -172,6 +174,8 @@ extern bool current_in_userns(const struct user_namespace *target_ns); - struct ns_common *ns_get_owner(struct ns_common *ns); - #else - -+#define unprivileged_userns_clone 0 -+ - static inline struct user_namespace *get_user_ns(struct user_namespace *ns) - { - return &init_user_ns; -diff --git a/init/Kconfig b/init/Kconfig -index 11f8a845f259da..02b7a0e455a5d7 100644 ---- a/init/Kconfig -+++ b/init/Kconfig -@@ -1226,6 +1226,22 @@ config USER_NS - - If unsure, say N. - -+config USER_NS_UNPRIVILEGED -+ bool "Allow unprivileged users to create namespaces" -+ default y -+ depends on USER_NS -+ help -+ When disabled, unprivileged users will not be able to create -+ new namespaces. Allowing users to create their own namespaces -+ has been part of several recent local privilege escalation -+ exploits, so if you need user namespaces but are -+ paranoid^Wsecurity-conscious you want to disable this. -+ -+ This setting can be overridden at runtime via the -+ kernel.unprivileged_userns_clone sysctl. -+ -+ If unsure, say Y. -+ - config PID_NS - bool "PID Namespaces" - default y -diff --git a/kernel/fork.c b/kernel/fork.c -index 10885c649ca42c..e0fe98e1afbdb5 100644 ---- a/kernel/fork.c -+++ b/kernel/fork.c -@@ -98,6 +98,10 @@ - #include <linux/io_uring.h> - #include <linux/bpf.h> - -+#ifdef CONFIG_USER_NS -+#include <linux/user_namespace.h> -+#endif -+ - #include <asm/pgalloc.h> - #include <linux/uaccess.h> - #include <asm/mmu_context.h> -@@ -1950,6 +1954,10 @@ static __latent_entropy struct task_struct *copy_process( - if ((clone_flags & (CLONE_NEWUSER|CLONE_FS)) == (CLONE_NEWUSER|CLONE_FS)) - return ERR_PTR(-EINVAL); - -+ if ((clone_flags & CLONE_NEWUSER) && !unprivileged_userns_clone) -+ if (!capable(CAP_SYS_ADMIN)) -+ return ERR_PTR(-EPERM); -+ - /* - * Thread groups must share signals as well, and detached threads - * can only be started up within the thread group. -@@ -3056,6 +3064,12 @@ int ksys_unshare(unsigned long unshare_flags) - if (unshare_flags & CLONE_NEWNS) - unshare_flags |= CLONE_FS; - -+ if ((unshare_flags & CLONE_NEWUSER) && !unprivileged_userns_clone) { -+ err = -EPERM; -+ if (!capable(CAP_SYS_ADMIN)) -+ goto bad_unshare_out; -+ } -+ - err = check_unshare_flags(unshare_flags); - if (err) - goto bad_unshare_out; -diff --git a/kernel/sysctl.c b/kernel/sysctl.c -index 083be6af29d705..42aa3c7835b96d 100644 ---- a/kernel/sysctl.c -+++ b/kernel/sysctl.c -@@ -105,6 +105,9 @@ - #ifdef CONFIG_LOCKUP_DETECTOR - #include <linux/nmi.h> - #endif -+#ifdef CONFIG_USER_NS -+#include <linux/user_namespace.h> -+#endif - - #if defined(CONFIG_SYSCTL) - -@@ -1949,6 +1952,15 @@ static struct ctl_table kern_table[] = { - .proc_handler = proc_dointvec, - }, - #endif -+#ifdef CONFIG_USER_NS -+ { -+ .procname = "unprivileged_userns_clone", -+ .data = &unprivileged_userns_clone, -+ .maxlen = sizeof(int), -+ .mode = 0644, -+ .proc_handler = proc_dointvec, -+ }, -+#endif - #ifdef CONFIG_PROC_SYSCTL - { - .procname = "tainted", -diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c -index 6b2e3ca7ee993a..0253002184f1d9 100644 ---- a/kernel/user_namespace.c -+++ b/kernel/user_namespace.c -@@ -21,6 +21,13 @@ - #include <linux/bsearch.h> - #include <linux/sort.h> - -+/* sysctl */ -+#ifdef CONFIG_USER_NS_UNPRIVILEGED -+int unprivileged_userns_clone = 1; -+#else -+int unprivileged_userns_clone; -+#endif -+ - static struct kmem_cache *user_ns_cachep __read_mostly; - static DEFINE_MUTEX(userns_state_mutex); - - -From 175ccdaae5fbcb712d5b6e4f613ba30840f63713 Mon Sep 17 00:00:00 2001 -From: "Jan Alexander Steffens (heftig)" <heftig@archlinux.org> -Date: Thu, 18 Nov 2021 22:53:31 +0100 -Subject: [PATCH] PCI: Add more NVIDIA controllers to the MSI masking quirk - -For: https://bugs.archlinux.org/task/72734 -For: https://bugs.archlinux.org/task/72777 ---- - drivers/pci/quirks.c | 2 ++ - 1 file changed, 2 insertions(+) - -diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c -index 208fa03acdda00..7fdb7e9c2e12c4 100644 ---- a/drivers/pci/quirks.c -+++ b/drivers/pci/quirks.c -@@ -5802,3 +5802,5 @@ static void nvidia_ion_ahci_fixup(struct pci_dev *pdev) - pdev->dev_flags |= PCI_DEV_FLAGS_HAS_MSI_MASKING; - } - DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0ab8, nvidia_ion_ahci_fixup); -+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0ab9, nvidia_ion_ahci_fixup); -+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0d88, nvidia_ion_ahci_fixup); - -From 914ce66bcae415509aaa4a2a1033344c3fe4d937 Mon Sep 17 00:00:00 2001 -From: Ajay Garg <ajaygargnsit@gmail.com> -Date: Tue, 12 Oct 2021 19:26:53 +0530 -Subject: [PATCH] iommu: intel: do deep dma-unmapping, to avoid - kernel-flooding. - -Origins at : -https://lists.linuxfoundation.org/pipermail/iommu/2021-October/thread.html - -=== Changes from v1 => v2 === - -a) -Improved patch-description. - -b) -A more root-level fix, as suggested by - - 1. - Alex Williamson <alex.williamson@redhat.com> - - 2. - Lu Baolu <baolu.lu@linux.intel.com> - -=== Issue === - -Kernel-flooding is seen, when an x86_64 L1 guest (Ubuntu-21) is booted in qemu/kvm -on a x86_64 host (Ubuntu-21), with a host-pci-device attached. - -Following kind of logs, along with the stacktraces, cause the flood : - -...... - DMAR: ERROR: DMA PTE for vPFN 0x428ec already set (to 3f6ec003 not 3f6ec003) - DMAR: ERROR: DMA PTE for vPFN 0x428ed already set (to 3f6ed003 not 3f6ed003) - DMAR: ERROR: DMA PTE for vPFN 0x428ee already set (to 3f6ee003 not 3f6ee003) - DMAR: ERROR: DMA PTE for vPFN 0x428ef already set (to 3f6ef003 not 3f6ef003) - DMAR: ERROR: DMA PTE for vPFN 0x428f0 already set (to 3f6f0003 not 3f6f0003) -...... - -=== Current Behaviour, leading to the issue === - -Currently, when we do a dma-unmapping, we unmap/unlink the mappings, but -the pte-entries are not cleared. - -Thus, following sequencing would flood the kernel-logs : - -i) -A dma-unmapping makes the real/leaf-level pte-slot invalid, but the -pte-content itself is not cleared. - -ii) -Now, during some later dma-mapping procedure, as the pte-slot is about -to hold a new pte-value, the intel-iommu checks if a prior -pte-entry exists in the pte-slot. If it exists, it logs a kernel-error, -along with a corresponding stacktrace. - -iii) -Step ii) runs in abundance, and the kernel-logs run insane. - -=== Fix === - -We ensure that as part of a dma-unmapping, each (unmapped) pte-slot -is also cleared of its value/content (at the leaf-level, where the -real mapping from a iova => pfn mapping is stored). - -This completes a "deep" dma-unmapping. - -Signed-off-by: Ajay Garg <ajaygargnsit@gmail.com> -Link: https://lore.kernel.org/linux-iommu/20211012135653.3852-1-ajaygargnsit@gmail.com/ ---- - drivers/iommu/intel/iommu.c | 2 ++ - 1 file changed, 2 insertions(+) - -diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c -index 78f8c8e6803e97..d8da48a91ba3b2 100644 ---- a/drivers/iommu/intel/iommu.c -+++ b/drivers/iommu/intel/iommu.c -@@ -5092,6 +5092,8 @@ static size_t intel_iommu_unmap(struct iommu_domain *domain, - gather->freelist = domain_unmap(dmar_domain, start_pfn, - last_pfn, gather->freelist); - -+ dma_pte_clear_range(dmar_domain, start_pfn, last_pfn); -+ - if (dmar_domain->max_addr == iova + size) - dmar_domain->max_addr = iova; - - -From e71a0f598c1748c9528e9408edef4278ef3e192b Mon Sep 17 00:00:00 2001 -From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> -Date: Thu, 18 Nov 2021 21:18:01 -0800 -Subject: [PATCH] cpufreq: intel_pstate: ITMT support for overclocked system - -On systems with overclocking enabled, CPPC Highest Performance can be -hard coded to 0xff. In this case even if we have cores with different -highest performance, ITMT can't be enabled as the current implementation -depends on CPPC Highest Performance. - -On such systems we can use MSR_HWP_CAPABILITIES maximum performance field -when CPPC.Highest Performance is 0xff. - -Due to legacy reasons, we can't solely depend on MSR_HWP_CAPABILITIES as -in some older systems CPPC Highest Performance is the only way to identify -different performing cores. - -Reported-by: Michael Larabel <Michael@MichaelLarabel.com> -Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> ---- - drivers/cpufreq/intel_pstate.c | 10 ++++++++++ - 1 file changed, 10 insertions(+) - -diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c -index e15c3bc17a55ce..8a2c6b58b6524f 100644 ---- a/drivers/cpufreq/intel_pstate.c -+++ b/drivers/cpufreq/intel_pstate.c -@@ -335,6 +335,8 @@ static void intel_pstste_sched_itmt_work_fn(struct work_struct *work) - - static DECLARE_WORK(sched_itmt_work, intel_pstste_sched_itmt_work_fn); - -+#define CPPC_MAX_PERF U8_MAX -+ - static void intel_pstate_set_itmt_prio(int cpu) - { - struct cppc_perf_caps cppc_perf; -@@ -345,6 +347,14 @@ static void intel_pstate_set_itmt_prio(int cpu) - if (ret) - return; - -+ /* -+ * On some systems with overclocking enabled, CPPC.highest_perf is hardcoded to 0xff. -+ * In this case we can't use CPPC.highest_perf to enable ITMT. -+ * In this case we can look at MSR_HWP_CAPABILITIES bits [8:0] to decide. -+ */ -+ if (cppc_perf.highest_perf == CPPC_MAX_PERF) -+ cppc_perf.highest_perf = HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached)); -+ - /* - * The priorities can be set regardless of whether or not - * sched_set_itmt_support(true) has been called and it is valid to - -From 2da5bc399d0eadfd487dbe8d3786253814c14bf1 Mon Sep 17 00:00:00 2001 -From: Kiran K <kiran.k@intel.com> -Date: Wed, 13 Oct 2021 13:35:11 +0530 -Subject: [PATCH] Bluetooth: btintel: Fix bdaddress comparison with garbage - value - -Intel Read Verision(TLV) data is parsed into a local structure variable -and it contains a field for bd address. Bd address is returned only in -bootloader mode and hence bd address in TLV structure needs to be validated -only if controller is present in boot loader mode. - -Signed-off-by: Kiran K <kiran.k@intel.com> -Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com> ---- - drivers/bluetooth/btintel.c | 22 ++++++++++++++-------- - 1 file changed, 14 insertions(+), 8 deletions(-) - -diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c -index f1705b46fc8898..b9055a3e61ed76 100644 ---- a/drivers/bluetooth/btintel.c -+++ b/drivers/bluetooth/btintel.c -@@ -2006,14 +2006,16 @@ static int btintel_prepare_fw_download_tlv(struct hci_dev *hdev, - if (ver->img_type == 0x03) { - btintel_clear_flag(hdev, INTEL_BOOTLOADER); - btintel_check_bdaddr(hdev); -- } -- -- /* If the OTP has no valid Bluetooth device address, then there will -- * also be no valid address for the operational firmware. -- */ -- if (!bacmp(&ver->otp_bd_addr, BDADDR_ANY)) { -- bt_dev_info(hdev, "No device address configured"); -- set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks); -+ } else { -+ /* -+ * Check for valid bd address in boot loader mode. Device -+ * will be marked as unconfigured if empty bd address is -+ * found. -+ */ -+ if (!bacmp(&ver->otp_bd_addr, BDADDR_ANY)) { -+ bt_dev_info(hdev, "No device address configured"); -+ set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks); -+ } - } - - btintel_get_fw_name_tlv(ver, fwname, sizeof(fwname), "sfi"); -@@ -2303,6 +2305,10 @@ static int btintel_setup_combined(struct hci_dev *hdev) - goto exit_error; - } - -+ /* memset ver_tlv to start with clean state as few fields are exclusive -+ * to bootloader mode and are not populated in operational mode -+ */ -+ memset(&ver_tlv, 0, sizeof(ver_tlv)); - /* For TLV type device, parse the tlv data */ - err = btintel_parse_version_tlv(hdev, &ver_tlv, skb); - if (err) { - -From 75e3bb9c92b0c9bbc2cbf3c829c648358b141082 Mon Sep 17 00:00:00 2001 -From: Matan Ziv-Av <matan@svgalib.org> -Date: Tue, 23 Nov 2021 22:14:55 +0200 -Subject: [PATCH] lg-laptop: Recognize more models - -LG uses 5 instead of 0 in the third digit (second digit after 2019) of the year string to indicate newer models in the same year. Handle this case as well. - -Signed-off-by: Matan Ziv-Av <matan@svgalib.org> -For: https://bugs.archlinux.org/task/71772 ---- - drivers/platform/x86/lg-laptop.c | 12 ++++++++++++ - 1 file changed, 12 insertions(+) - -diff --git a/drivers/platform/x86/lg-laptop.c b/drivers/platform/x86/lg-laptop.c -index 88b551caeaaf41..d6f74d3a7605e2 100644 ---- a/drivers/platform/x86/lg-laptop.c -+++ b/drivers/platform/x86/lg-laptop.c -@@ -658,6 +658,18 @@ static int acpi_add(struct acpi_device *device) - if (product && strlen(product) > 4) - switch (product[4]) { - case '5': -+ if (strlen(product) > 5) -+ switch (product[5]) { -+ case 'N': -+ year = 2021; -+ break; -+ case '0': -+ year = 2016; -+ break; -+ default: -+ year = 2022; -+ } -+ break; - case '6': - year = 2016; - break; |