- 23 May, 2018 2 commits
-
-
Antonio Rosario Intilisano authored
BugLink: http://bugs.launchpad.net/bugs/1766054 Now that we have informed the firmware that the Power Button driver is active, laptops such as the Acer Swift 3 will generate a WMI key event with code 0x87 when the power button key is pressed. Add this keycode to the table so that it is converted to an appropriate input event. Signed-off-by:
Antonio Rosario Intilisano <antonio.intilisano@gmail.com> Acked-by:
Gianfranco Costamagna <locutusofborg@debian.org> Cc: Chris Chiu <chiu@endlessm.com> Cc: Daniel Drake <drake@endlessm.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
- 19 May, 2018 4 commits
-
-
Juerg Haefliger authored
Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Stefan Bader authored
Initially all the SPEC_CTRL related bits were added to the scattered feature word and that was used to sync between host and guest. But now upstream has extended the feature words and moved all related bits there. Because of that we have to change the handler code as well. CVE-2018-3639 (x86) [smb: tracked in private lp 1772146] Signed-off-by: -
Tyler Hicks authored
This reverts commit 9ef888da which is commit a5b29663 upstream. It introduced a regression by disabling speculation control when running under a hypervisor with certain CPUs. The revert required the removal of a recently added line that cleared the X86_FEATURE_SSBD CPU capability. The changes to the Atom Merrifield macro names were preserved since a patch in the SSBD (CVE-2018-3639) patch set expected the new name. CVE-2018-3639 (x86) Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> [smb: removed bug link for private 1772128] Signed-off-by:
-
Josh Poimboeuf authored
CVE-2018-3639 (x86) The _TIF_ALLWORK_MASK macro automatically includes the least-significant 16 bits of the thread_info flags, which is less than obvious and tends to create confusion and surprises when reading or modifying the code. Define the flags explicitly. Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Reviewed-by:
Miroslav Benes <mbenes@suse.cz> Reviewed-by:
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Acked-by: Ingo Molnar <mingo@kernel.org> # for the x86 changes Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Fixes: 593e8398 ("UBUNTU: SAUCE: x86/process: Allow runtime control of Speculative Store Bypass") (backported from commit 3a404842) Signed-off-by:
-
- 16 May, 2018 34 commits
-
-
Nicholas Piggin authored
CVE-2018-3639 (powerpc) Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> [mauricio: backport to Ubuntu 16.04 linux_4.4.0-124.148] Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Signed-off-by:
-
Mauricio Faria de Oliveira authored
CVE-2018-3639 (powerpc) After migration the security feature flags might have changed (e.g., destination system with unpatched firmware), but some flags are not set/clear again in init_cpu_char_feature_flags() because it assumes the security flags to be the defaults. Additionally, if the H_GET_CPU_CHARACTERISTICS hypercall fails then init_cpu_char_feature_flags() does not run again, which potentially might leave the system in an insecure or sub-optimal configuration. So, just restore the security feature flags to the defaults assumed by init_cpu_char_feature_flags() so it can set/clear them correctly, and to ensure safe settings are in place in case the hypercall fail. Fixes: f636c147 ("powerpc/pseries: Set or clear security feature flags") Depends-on: 19887d6a28e2 ("powerpc: Move default security feature flags") Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Mauricio Faria de Oliveira authored
CVE-2018-3639 (powerpc) This moves the definition of the default security feature flags (i.e., enabled by default) closer to the security feature flags. This can be used to restore current flags to the default flags. Signed-off-by:
-
Mauricio Faria de Oliveira authored
CVE-2018-3639 (powerpc) The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_* flags. Found by playing around with QEMU's implementation of the hypercall: H_CPU_CHAR=0xf000000000000000 H_CPU_BEHAV=0x0000000000000000 This clears H_CPU_BEHAV_FAVOUR_SECURITY and H_CPU_BEHAV_L1D_FLUSH_PR so pseries_setup_rfi_flush() disables 'rfi_flush'; and it also clears H_CPU_CHAR_L1D_THREAD_PRIV flag. So there is no RFI flush mitigation at all for cpu_show_meltdown() to report; but currently it does: Original kernel: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: RFI Flush Patched kernel: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Not affected H_CPU_CHAR=0x0000000000000000 H_CPU_BEHAV=0xf000000000000000 This sets H_CPU_BEHAV_BNDS_CHK_SPEC_BAR so cpu_show_spectre_v1() should report vulnerable; but currently it doesn't: Original kernel: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Not affected Patched kernel: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 Vulnerable Brown-paper-bag-by: -
Michael Ellerman authored
CVE-2018-3639 (powerpc) Add a definition for cpu_show_spectre_v2() to override the generic version. This has several permuations, though in practice some may not occur we cater for any combination. The most verbose is: Mitigation: Indirect branch serialisation (kernel only), Indirect branch cache disabled, ori31 speculation barrier enabled We don't treat the ori31 speculation barrier as a mitigation on its own, because it has to be *used* by code in order to be a mitigation and we don't know if userspace is doing that. So if that's all we see we say: Vulnerable, ori31 speculation barrier enabled (cherry picked from commit d6fbe1c5) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Add a definition for cpu_show_spectre_v1() to override the generic version. Currently this just prints "Not affected" or "Vulnerable" based on the firmware flag. Although the kernel does have array_index_nospec() in a few places, we haven't yet audited all the powerpc code to see where it's necessary, so for now we don't list that as a mitigation. (cherry picked from commit 56986016) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Now that we have the security flags we can simplify the code in pseries_setup_rfi_flush() because the security flags have pessimistic defaults. (cherry picked from commit 2e4a1616) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Now that we have the security flags we can significantly simplify the code in pnv_setup_rfi_flush(), because we can use the flags instead of checking device tree properties and because the security flags have pessimistic defaults. (cherry picked from commit 37c0bdd0) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Now that we have the security feature flags we can make the information displayed in the "meltdown" file more informative. (cherry picked from commit ff348355) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) This landed in setup_64.c for no good reason other than we had nowhere else to put it. Now that we have a security-related file, that is a better place for it so move it. (cherry picked from commit 8ad33041) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Now that we have feature flags for security related things, set or clear them based on what we see in the device tree provided by firmware. (cherry picked from commit 77addf6e) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Now that we have feature flags for security related things, set or clear them based on what we receive from the hypercall. Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) This commit adds security feature flags to reflect the settings we receive from firmware regarding Spectre/Meltdown mitigations. The feature names reflect the names we are given by firmware on bare metal machines. See the hostboot source for details. Arguably these could be firmware features, but that then requires them to be read early in boot so they're available prior to asm feature patching, but we don't actually want to use them for patching. We may also want to dynamically update them in future, which would be incompatible with the way firmware features work (at the moment at least). So for now just make them separate flags. Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Add some additional values which have been defined for the H_GET_CPU_CHARACTERISTICS hypercall. (cherry picked from c4bc3662) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) We might have migrated to a machine that uses a different flush type, or doesn't need flushing at all. Signed-off-by:
-
Mauricio Faria de Oliveira authored
CVE-2018-3639 (powerpc) Currently the rfi-flush messages print 'Using <type> flush' for all enabled_flush_types, but that is not necessarily true -- as now the fallback flush is always enabled on pseries, but the fixup function overwrites its nop/branch slot with other flush types, if available. So, replace the 'Using <type> flush' messages with '<type> flush is available'. Also, print the patched flush types in the fixup function, so users can know what is (not) being used (e.g., the slower, fallback flush, or no flush type at all if flush is disabled via the debugfs switch). Suggested-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) This ensures the fallback flush area is always allocated on pseries, so in case a LPAR is migrated from a patched to an unpatched system, it is possible to enable the fallback flush in the target system. Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) For PowerVM migration we want to be able to call setup_rfi_flush() again after we've migrated the partition. To support that we need to check that we're not trying to allocate the fallback flush area after memblock has gone away (i.e., boot-time only). Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) rfi_flush_enable() includes a check to see if we're already enabled (or disabled), and in that case does nothing. But that means calling setup_rfi_flush() a 2nd time doesn't actually work, which is a bit confusing. Move that check into the debugfs code, where it really belongs. Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Some versions of firmware will have a setting that can be configured to disable the RFI flush, add support for it. Fixes: 6e032b35 ("powerpc/powernv: Check device-tree for RFI flush settings") (cherry picked from commit eb0a2d26) Signed-off-by:
-
Michael Ellerman authored
CVE-2018-3639 (powerpc) Some versions of firmware will have a setting that can be configured to disable the RFI flush, add support for it. Fixes: 8989d568 ("powerpc/pseries: Query hypervisor for RFI flush settings") (cherry picked from commit 582605a4) Signed-off-by:
-
Jiri Kosina authored
CVE-2018-3639 (x86) cpu_show_common() is not used outside of arch/x86/kernel/cpu/bugs.c, so make it static. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jiri Kosina authored
CVE-2018-3639 (x86) __ssb_select_mitigation() returns one of the members of enum ssb_mitigation, not ssb_mitigation_cmd; fix the prototype to reflect that. Fixes: 24f7fc83 ("x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation") Signed-off-by:
-
Borislav Petkov authored
CVE-2018-3639 (x86) Fix some typos, improve formulations, end sentences with a fullstop. Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
CVE-2018-3639 (x86) The style for the 'status' file is CamelCase or this. _. Fixes: fae1fa0f ("proc: Provide details on speculation flaw mitigations") Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
CVE-2018-3639 (x86) Intel collateral will reference the SSB mitigation bit in IA32_SPEC_CTL[2] as SSBD (Speculative Store Bypass Disable). Hence changing it. It is unclear yet what the MSR_IA32_ARCH_CAPABILITIES (0x10a) Bit(4) name is going to be. Following the rename it would be SSBD_NO but that rolls out to Speculative Store Bypass Disable No. Also fixed the missing space in X86_FEATURE_AMD_SSBD. [ tglx: Fixup x86_amd_rds_enable() and rds_tif_to_amd_ls_cfg() as well ] Signed-off-by:
-
Kees Cook authored
CVE-2018-3639 (x86) Unless explicitly opted out of, anything running under seccomp will have SSB mitigations enabled. Choosing the "prctl" mode will disable this. [ tglx: Adjusted it to the new arch_seccomp_spec_mitigate() mechanism ] Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Thomas Gleixner authored
CVE-2018-3639 (x86) The migitation control is simpler to implement in architecture code as it avoids the extra function call to check the mode. Aside of that having an explicit seccomp enabled mode in the architecture mitigations would require even more workarounds. Move it into architecture code and provide a weak function in the seccomp code. Remove the 'which' argument as this allows the architecture to decide which mitigations are relevant for seccomp. Signed-off-by:
-
Kees Cook authored
CVE-2018-3639 (x86) If a seccomp user is not interested in Speculative Store Bypass mitigation by default, it can set the new SECCOMP_FILTER_FLAG_SPEC_ALLOW flag when adding filters. Signed-off-by:
-
Mickaël Salaün authored
CVE-2018-3639 (x86) Rename SECCOMP_FLAG_FILTER_TSYNC to SECCOMP_FILTER_FLAG_TSYNC to match the UAPI. Signed-off-by:
Mickaël Salaün <mic@digikod.net> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Kees Cook <keescook@chromium.org> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Will Drewry <wad@chromium.org> Acked-by:
Shuah Khan <shuahkh@osg.samsung.com> (backported from commit 6c045d07) [juergh: Context adjustments.] Signed-off-by:
-
Thomas Gleixner authored
CVE-2018-3639 (x86) Use PR_SPEC_FORCE_DISABLE in seccomp() because seccomp does not allow to widen restrictions. Signed-off-by:
-
Thomas Gleixner authored
CVE-2018-3639 (x86) For certain use cases it is desired to enforce mitigations so they cannot be undone afterwards. That's important for loader stubs which want to prevent a child from disabling the mitigation again. Will also be used for seccomp(). The extra state preserving of the prctl state for SSB is a preparatory step for EBPF dymanic speculation control. Signed-off-by:
-
Kees Cook authored
CVE-2018-3639 (x86) There's no reason for these to be changed after boot. Signed-off-by:
-
Stefan Bader authored
CVE-2018-3639 (x86) Upstream implementation reads the content of the SPEC_CTRL MSR once during boot to record the state of reserved bits. Any access to this MSR (to enable/disable IBRS) needs to preserve those reserved bits. This tries to catch and convert all occurrances of the Intel based IBRS changes we carry. Signed-off-by:
-
