diff options
| -rw-r--r-- | .SRCINFO | 2 | ||||
| -rw-r--r-- | PKGBUILD | 4 | ||||
| -rw-r--r-- | x86-change-default-to-spec_store_bypass_disable-prct.patch | 255 |
3 files changed, 261 insertions, 0 deletions
@@ -26,6 +26,7 @@ pkgbase = linux-xanmod-rog source = x86-ACPI-State-Optimize-C3-entry-on-AMD-CPUs.patch source = acpi-battery-Always-read-fresh-battery-state-on-update.patch source = hwmon-k10temp-support-Zen3-APUs.patch + source = x86-change-default-to-spec_store_bypass_disable-prct.patch source = cfg80211-dont-WARN-if-a-self-managed-device.patch source = r8152-fix-spurious-wakeups-from-s0i3.patch source = r8169-Add-device-10ec-8162-to-driver-r8169.patch @@ -67,6 +68,7 @@ pkgbase = linux-xanmod-rog sha256sums = 923230ed8367e28adfdeed75d3cdba9eec6b781818c37f6f3d3eb64101d2e716 sha256sums = f7a4bf6293912bfc4a20743e58a5a266be8c4dbe3c1862d196d3a3b45f2f7c90 sha256sums = de8c9747637768c4356c06aa65c3f157c526aa420f21fdd5edd0ed06f720a62e + sha256sums = cc401107f1bf7b7d8e8a78ee594f9db4b6fa252b7239b6aa88f678aef84d935c sha256sums = 3d8961438b5c8110588ff0b881d472fc71a4304d306808d78a4055a4150f351e sha256sums = f47a5a5e329e410a0ae7d46b450707d5575a4deda5b3b58281f5eca14938fb21 sha256sums = e4e55dd548c7689596a7c5c42e49c8f072bd2613bd416c6910b5c6410120eb1d @@ -119,6 +119,9 @@ source=("https://cdn.kernel.org/pub/linux/kernel/v${_branch}/linux-${_major}.tar #"x86-amd_nb-Add-AMD-family-19h-model-50h-PCI-ids.patch" # included in 5.14 "hwmon-k10temp-support-Zen3-APUs.patch" # landing in 5.15 + # 5.16 spectre defaults + "x86-change-default-to-spec_store_bypass_disable-prct.patch" + # squelch overzealous 802.11 regdomain not set warnings "cfg80211-dont-WARN-if-a-self-managed-device.patch" @@ -175,6 +178,7 @@ sha256sums=('7e068b5e0d26a62b10e5320b25dce57588cbbc6f781c090442138c9c9c3271b2' '923230ed8367e28adfdeed75d3cdba9eec6b781818c37f6f3d3eb64101d2e716' 'f7a4bf6293912bfc4a20743e58a5a266be8c4dbe3c1862d196d3a3b45f2f7c90' 'de8c9747637768c4356c06aa65c3f157c526aa420f21fdd5edd0ed06f720a62e' + 'cc401107f1bf7b7d8e8a78ee594f9db4b6fa252b7239b6aa88f678aef84d935c' '3d8961438b5c8110588ff0b881d472fc71a4304d306808d78a4055a4150f351e' 'f47a5a5e329e410a0ae7d46b450707d5575a4deda5b3b58281f5eca14938fb21' 'e4e55dd548c7689596a7c5c42e49c8f072bd2613bd416c6910b5c6410120eb1d' diff --git a/x86-change-default-to-spec_store_bypass_disable-prct.patch b/x86-change-default-to-spec_store_bypass_disable-prct.patch new file mode 100644 index 000000000000..a47f845e580b --- /dev/null +++ b/x86-change-default-to-spec_store_bypass_disable-prct.patch @@ -0,0 +1,255 @@ +From 1d4c03c1d9ea9ab1ee7ab0efbd05eec71b6a92d5 Mon Sep 17 00:00:00 2001 +From: Andrea Arcangeli <aarcange@redhat.com> +Date: Wed, 4 Nov 2020 18:50:54 -0500 +Subject: [PATCH] x86: change default to spec_store_bypass_disable=prctl + spectre_v2_user=prctl + +Switch the kernel default of SSBD and STIBP to the ones with +CONFIG_SECCOMP=n (i.e. spec_store_bypass_disable=prctl +spectre_v2_user=prctl) even if CONFIG_SECCOMP=y. + +Several motivations listed below: + +- If SMT is enabled the seccomp jail can still attack the rest of the + system even with spectre_v2_user=seccomp by using MDS-HT (except on + XEON PHI where MDS can be tamed with SMT left enabled, but that's a + special case). Setting STIBP become a very expensive window dressing + after MDS-HT was discovered. + +- The seccomp jail cannot attack the kernel with spectre-v2-HT + regardless (even if STIBP is not set), but with MDS-HT the seccomp + jail can attack the kernel too. + +- With spec_store_bypass_disable=prctl the seccomp jail can attack the + other userland (guest or host mode) using spectre-v2-HT, but the + userland attack is already mitigated by both ASLR and pid namespaces + for host userland and through virt isolation with libkrun or + kata. (if something if somebody is worried about spectre-v2-HT it's + best to mount proc with hidepid=2,gid=proc on workstations where not + all apps may run under container runtimes, rather than slowing down + all seccomp jails, but the best is to add pid namespaces to the + seccomp jail). As opposed MDS-HT is not mitigated and the seccomp + jail can still attack all other host and guest userland if SMT is + enabled even with spec_store_bypass_disable=seccomp. + +- If full security is required then MDS-HT must also be mitigated with + nosmt and then spectre_v2_user=prctl and spectre_v2_user=seccomp + would become identical. + +- Setting spectre_v2_user=seccomp is overall lower priority than to + setting javascript.options.wasm false in about:config to protect + against remote wasm MDS-HT, instead of worrying about Spectre-v2-HT + and STIBP which again is already statistically well mitigated by + other means in userland and it's fully mitigated in kernel with + retpolines (unlike the wasm assist call with MDS-HT). + +- SSBD is needed to prevent reading the JIT memory and the primary + user being the OpenJDK. However the primary user of SSBD wouldn't be + covered by spec_store_bypass_disable=seccomp because it doesn't use + seccomp and the primary user also explicitly declined to set + PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS despite it easily + could. In fact it would need to set it only when the sandboxing + mechanism is enabled for javaws applets, but it still declined it by + declaring security within the same user address space as an + untenable objective for their JIT, even in the sandboxing case where + performance would be a lesser concern (for the record: I kind of + disagree in not setting PR_SPEC_STORE_BYPASS in the sandbox case and + I prefer to run javaws through a wrapper that sets + PR_SPEC_STORE_BYPASS if I need). In turn it can be inferred that + even if the primary user of SSBD would use seccomp, they would + invoke it with SECCOMP_FILTER_FLAG_SPEC_ALLOW by now. + +- runc/crun already set SECCOMP_FILTER_FLAG_SPEC_ALLOW by default, k8s + and podman have a default json seccomp allowlist that cannot be + slowed down, so for the #1 seccomp user this change is already a + noop. + +- systemd/sshd or other apps that use seccomp, if they really need + STIBP or SSBD, they need to explicitly set the + PR_SET_SPECULATION_CTRL by now. The stibp/ssbd seccomp blind + catch-all approach was done probably initially with a wishful + thinking objective to pretend to have a peace of mind that it could + magically fix it all. That was wishful thinking before MDS-HT was + discovered, but after MDS-HT has been discovered it become just + window dressing. + +- For qemu "-sandbox" seccomp jail it wouldn't make sense to set STIBP + or SSBD. SSBD doesn't help with KVM because there's no JIT (if it's + needed with TCG it should be an opt-in with + PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS and it shouldn't + slowdown KVM for nothing). For qemu+KVM STIBP would be even more + window dressing than it is for all other apps, because in the + qemu+KVM case there's not only the MDS attack to worry about with + SMT enabled. Even after disabling SMT, there's still a theoretical + spectre-v2 attack possible within the same thread context from guest + mode to host ring3 that the host kernel retpoline mitigation has no + theoretical chance to mitigate. On some kernels a + ibrs-always/ibrs-retpoline opt-in model is provided that will + enabled IBRS in the qemu host ring3 userland which fixes this + theoretical concern. Only after enabling IBRS in the host userland + it would then make sense to proceed and worry about STIBP and an + attack on the other host userland, but then again SMT would need to + be disabled for full security anyway, so that would render STIBP + again a noop. + +- last but not the least: the lack of "spec_store_bypass_disable=prctl + spectre_v2_user=prctl" means the moment a guest boots and + sshd/systemd runs, the guest kernel will write to SPEC_CTRL MSR + which will make the guest vmexit forever slower, forcing KVM to + issue a very slow rdmsr instruction at every vmexit. So the end + result is that SPEC_CTRL MSR is only available in GCE. Most other + public cloud providers don't expose SPEC_CTRL, which means that not + only STIBP/SSBD isn't available, but IBPB isn't available either + (which would cause no overhead to the guest or the hypervisor + because it's write only and requires no reading during vmexit). So + the current default already net loss in security (missing IBPB) + which means most public cloud providers cannot achieve a fully + secure guest with nosmt (and nosmt is enough to fully mitigate + MDS-HT). It also means GCE and is unfairly penalized in performance + because it provides the option to enable full security in the guest + as an opt-in (i.e. nosmt and IBPB). So this change will allow all + cloud providers to expose SPEC_CTRL without incurring into any + hypervisor slowdown and at the same time it will remove the unfair + penalization of GCE performance for doing the right thing and it'll + allow to get full security with nosmt with IBPB being available (and + STIBP becoming meaningless). + +Example to put things in prospective: the STIBP enabled in seccomp has +never been about protecting apps using seccomp like sshd from an +attack from a malicious userland, but to the contrary it has always +been about protecting the system from an attack from sshd, after a +successful remote network exploit against sshd. In fact initially it +wasn't obvious STIBP would work both ways (STIBP was about preventing +the task that runs with STIBP to be attacked with spectre-v2-HT, but +accidentally in the STIBP case it also prevents the attack in the +other direction). In the hypothetical case that sshd has been remotely +exploited the last concern should be STIBP being set, because it'll be +still possible to obtain info even from the kernel by using MDS if +nosmt wasn't set (and if it was set, STIBP is a noop in the first +place). As opposed kernel cannot leak anything with spectre-v2 HT +because of retpolines and the userland is mitigated by ASLR already +and ideally PID namespaces too. If something it'd be worth checking if +sshd run the seccomp thread under pid namespaces too if available in +the running kernel. SSBD also would be a noop for sshd, since sshd +uses no JIT. If sshd prefers to keep doing the STIBP window dressing +exercise, it still can even after this change of defaults by opting-in +with PR_SPEC_INDIRECT_BRANCH. + +Ultimately setting SSBD and STIBP by default for all seccomp jails is +a bad sweet spot and bad default with more cons than pros that end up +reducing security in the public cloud (by giving an huge incentive to +not expose SPEC_CTRL which would be needed to get full security with +IBPB after setting nosmt in the guest) and by excessively hurting +performance to more secure apps using seccomp that end up having to +opt out with SECCOMP_FILTER_FLAG_SPEC_ALLOW. + +The following is the verified result of the new default with SMT +enabled: + +(gdb) print spectre_v2_user_stibp +$1 = SPECTRE_V2_USER_PRCTL +(gdb) print spectre_v2_user_ibpb +$2 = SPECTRE_V2_USER_PRCTL +(gdb) print ssb_mode +$3 = SPEC_STORE_BYPASS_PRCTL + +Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> +Signed-off-by: Kees Cook <keescook@chromium.org> +Link: https://lore.kernel.org/r/20201104235054.5678-1-aarcange@redhat.com +Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> +Link: https://lore.kernel.org/lkml/AAA2EF2C-293D-4D5B-BFA6-FF655105CD84@redhat.com +Acked-by: Waiman Long <longman@redhat.com> +Link: https://lore.kernel.org/lkml/c0722838-06f7-da6b-138f-e0f26362f16a@redhat.com +--- + Documentation/admin-guide/hw-vuln/spectre.rst | 10 ++++------ + Documentation/admin-guide/kernel-parameters.txt | 5 ++--- + arch/x86/kernel/cpu/bugs.c | 4 ++-- + 3 files changed, 8 insertions(+), 11 deletions(-) + +diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst +index e05e581af5cf..19b897cb1d45 100644 +--- a/Documentation/admin-guide/hw-vuln/spectre.rst ++++ b/Documentation/admin-guide/hw-vuln/spectre.rst +@@ -490,9 +490,8 @@ Spectre variant 2 + + Restricting indirect branch speculation on a user program will + also prevent the program from launching a variant 2 attack +- on x86. All sand-boxed SECCOMP programs have indirect branch +- speculation restricted by default. Administrators can change +- that behavior via the kernel command line and sysfs control files. ++ on x86. Administrators can change that behavior via the kernel ++ command line and sysfs control files. + See :ref:`spectre_mitigation_control_command_line`. + + Programs that disable their indirect branch speculation will have +@@ -674,9 +673,8 @@ Mitigation selection guide + off by disabling their indirect branch speculation when they are run + (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). + This prevents untrusted programs from polluting the branch target +- buffer. All programs running in SECCOMP sandboxes have indirect +- branch speculation restricted by default. This behavior can be +- changed via the kernel command line and sysfs control files. See ++ buffer. This behavior can be changed via the kernel command line ++ and sysfs control files. See + :ref:`spectre_mitigation_control_command_line`. + + 3. High security mode +diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt +index bdb22006f713..b558005780d3 100644 +--- a/Documentation/admin-guide/kernel-parameters.txt ++++ b/Documentation/admin-guide/kernel-parameters.txt +@@ -5265,8 +5265,7 @@ + auto - Kernel selects the mitigation depending on + the available CPU features and vulnerability. + +- Default mitigation: +- If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" ++ Default mitigation: "prctl" + + Not specifying this option is equivalent to + spectre_v2_user=auto. +@@ -5310,7 +5309,7 @@ + will disable SSB unless they explicitly opt out. + + Default mitigations: +- X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl" ++ X86: "prctl" + + On powerpc the options are: + +diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c +index d41b70fe4918..8feb866623d0 100644 +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -721,11 +721,11 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) + case SPECTRE_V2_USER_CMD_FORCE: + mode = SPECTRE_V2_USER_STRICT; + break; ++ case SPECTRE_V2_USER_CMD_AUTO: + case SPECTRE_V2_USER_CMD_PRCTL: + case SPECTRE_V2_USER_CMD_PRCTL_IBPB: + mode = SPECTRE_V2_USER_PRCTL; + break; +- case SPECTRE_V2_USER_CMD_AUTO: + case SPECTRE_V2_USER_CMD_SECCOMP: + case SPECTRE_V2_USER_CMD_SECCOMP_IBPB: + if (IS_ENABLED(CONFIG_SECCOMP)) +@@ -1132,7 +1132,6 @@ static enum ssb_mitigation __init __ssb_select_mitigation(void) + return mode; + + switch (cmd) { +- case SPEC_STORE_BYPASS_CMD_AUTO: + case SPEC_STORE_BYPASS_CMD_SECCOMP: + /* + * Choose prctl+seccomp as the default mode if seccomp is +@@ -1146,6 +1145,7 @@ static enum ssb_mitigation __init __ssb_select_mitigation(void) + case SPEC_STORE_BYPASS_CMD_ON: + mode = SPEC_STORE_BYPASS_DISABLE; + break; ++ case SPEC_STORE_BYPASS_CMD_AUTO: + case SPEC_STORE_BYPASS_CMD_PRCTL: + mode = SPEC_STORE_BYPASS_PRCTL; + break; +-- +2.33.1 + |