- 07 Jun, 2018 18 commits
-
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit 3968523f upstream. mpls_label_ok() validates that the 'platform_label' array index from a userspace netlink message payload is valid. Under speculation the mpls_label_ok() result may not resolve in the CPU pipeline until after the index is used to access an array element. Sanitize the index to zero to prevent userspace-controlled arbitrary out-of-bounds speculation, a precursor for a speculative execution side channel vulnerability. Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 4.4: - mpls_label_ok() doesn't take an extack parameter - Drop change in mpls_getroute()] Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e7f17d03 linux-4.4.y) Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Jiri Slaby authored
BugLink: https://bugs.launchpad.net/bugs/1774181 In 4.4.118, we have commit c8961332 (x86/syscall: Sanitize syscall table de-references under speculation), which is a backport of upstream commit 2fbd7af5. But it fixed only the C part of the upstream patch -- the IA32 sysentry. So it ommitted completely the assembly part -- the 64bit sysentry. Fix that in this patch by explicit array_index_mask_nospec written in assembly. The same was used in lib/getuser.S. However, to have "sbb" working properly, we have to switch from "cmp" against (NR_syscalls-1) to (NR_syscalls), otherwise the last syscall number would be "and"ed by 0. It is because the original "ja" relies on "CF" or "ZF", but we rely only on "CF" in "sbb". That means: switch to "jae" conditional jump too. Final note: use rcx for mask as this is exactly what is overwritten by the 4th syscall argument (r10) right after. Reported-by:
Jan Beulich <JBeulich@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: Andy Lutomirski <luto@kernel.org> Cc: alan@linux.intel.com Cc: Jinpu Wang <jinpu.wang@profitbricks.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Rasmus Villemoes authored
BugLink: https://bugs.launchpad.net/bugs/1774181 commit b98c6a16 upstream. The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we already use that in e.g. the min/max macros which end with a ternary expression. This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is. The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i). Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arch@vger.kernel.org Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/151881604837.17395.10812767547837568328.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit 085331df) Commit 75f139aa "KVM: x86: Add memory barrier on vmcs field lookup" added a raw 'asm("lfence");' to prevent a bounds check bypass of 'vmcs_field_to_offset_table'. The lfence can be avoided in this path by using the array_index_nospec() helper designed for these types of fixes. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Andrew Honig <ahonig@google.com> Cc: kvm@vger.kernel.org Cc: Jim Mattson <jmattson@google.com> Link: https://lkml.kernel.org/r/151744959670.6342.3001723920950249067.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
David Woodhouse <dwmw@amazon.co.uk> [jwang: cherry pick to 4.4] Signed-off-by:
Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit edfbae53) Reflect the presence of get_user(), __get_user(), and 'syscall' protections in sysfs. The expectation is that new and better tooling will allow the kernel to grow more usages of array_index_nospec(), for now, only claim mitigation for __user pointer de-references. Reported-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit 259d8c1e) Wireless drivers rely on parse_txq_params to validate that txq_params->ac is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx() handler is called. Use a new helper, array_index_nospec(), to sanitize txq_params->ac with respect to speculation. I.e. ensure that any speculation into ->conf_tx() handlers is done with a value of txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Reported-by:
Christian Lamparter <chunkeey@gmail.com> Reported-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: linux-wireless@vger.kernel.org Cc: torvalds@linux-foundation.org Cc: "David S. Miller" <davem@davemloft.net> Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit 56c30ba7) 'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid 'file *' returned from __fcheck_files. Co-developed-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit 2fbd7af5) The syscall table base is a user controlled function pointer in kernel space. Use array_index_nospec() to prevent any out of bounds speculation. While retpoline prevents speculating into a userspace directed target it does not stop the pointer de-reference, the concern is leaking memory relative to the syscall table base, by observing instruction cache behavior. Reported-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit c7f631cb) Quoting Linus: I do think that it would be a good idea to very expressly document the fact that it's not that the user access itself is unsafe. I do agree that things like "get_user()" want to be protected, but not because of any direct bugs or problems with get_user() and friends, but simply because get_user() is an excellent source of a pointer that is obviously controlled from a potentially attacking user space. So it's a prime candidate for then finding _subsequent_ accesses that can then be used to perturb the cache. Unlike the __get_user() case get_user() includes the address limit check near the pointer de-reference. With that locality the speculation can be mitigated with pointer narrowing rather than a barrier, i.e. array_index_nospec(). Where the narrowing is performed by: cmp %limit, %ptr sbb %mask, %mask and %mask, %ptr With respect to speculation the value of %ptr is either less than %limit or NULL. Co-developed-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit b3d7ad85) Rename the open coded form of this instruction sequence from rdtsc_ordered() into a generic barrier primitive, barrier_nospec(). One of the mitigations for Spectre variant1 vulnerabilities is to fence speculative execution after successfully validating a bounds check. I.e. force the result of a bounds check to resolve in the instruction pipeline to ensure speculative execution honors that result before potentially operating on out-of-bounds data. No functional changes. Suggested-by:
Andi Kleen <ak@linux.intel.com> Suggested-by:
Ingo Molnar <mingo@redhat.com> Signed-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit babdde26) array_index_nospec() uses a mask to sanitize user controllable array indexes, i.e. generate a 0 mask if 'index' >= 'size', and a ~0 mask otherwise. While the default array_index_mask_nospec() handles the carry-bit from the (index - size) result in software. The x86 array_index_mask_nospec() does the same, but the carry-bit is handled in the processor CF flag without conditional instructions in the control flow. Suggested-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit f3804203) array_index_nospec() is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks via speculative execution. The array_index_nospec() implementation is expected to be safe for current generation CPUs across multiple architectures (ARM, x86). Based on an original implementation by Linus Torvalds, tweaked to remove speculative flows by Alexei Starovoitov, and tweaked again by Linus to introduce an x86 assembly implementation for the mask generation. Co-developed-by:
Alexei Starovoitov <ast@kernel.org> Suggested-by:
Cyril Novikov <cnovikov@lynx.com> Signed-off-by:
-
Mark Rutland authored
BugLink: https://bugs.launchpad.net/bugs/1774181 (cherry picked from commit f84a56f7) Document the rationale and usage of the new array_index_nospec() helper. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: linux-arch@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: gregkh@linuxfoundation.org Cc: kernel-hardening@lists.openwall.com Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727413645.33451.15878817161436755393.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) We now have individual feature flags for IBRS and IBPB, so query them when reloading microcode. Just like we do on boot (in arch/x86/kernel/cpu/common.c). Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) Commit f93e1bcd ("x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown") introduced a smarter detection of CPUs that are not affected by Meltdown. Make use of that when pti=auto which also matches Linus' tree. While at it, remove the unused variable 'enable'. Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) Fixes: f3b21b13 ("UBUNTU: SAUCE: x86/bugs: Honour SPEC_CTRL default") Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) It's ok to have holes in CPU feature bits array, so move the CPUID_7_EDX bits from word 16 to word 18 to match upstream. Primarily to avoid confusion and conflicts with future backports/cherry-picks. Fixes: e8e6c1d5 ("x86/cpufeatures: Add CPUID_7_EDX CPUID leaf") Signed-off-by:
-
Huaitong Han authored
CVE-2018-3639 (x86) This patch removes magic number with enum cpuid_leafs. Signed-off-by:
Huaitong Han <huaitong.han@intel.com> Signed-off-by:
-
- 06 Jun, 2018 13 commits
-
-
Hendrik Brueckner authored
BugLink: http://bugs.launchpad.net/bugs/1772593 Correct a trinity finding for the perf_event_open() system call with a perf event attribute structure that uses a frequency but has the sampling frequency set to zero. This causes a FP divide exception during the sample rate initialization for the hardware sampling facility. Fixes: 8c069ff4 ("s390/perf: add support for the CPU-Measurement Sampling Facility") Cc: stable@vger.kernel.org # 3.14+ Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 4bbaf258) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Johannes Wienke authored
BugLink: http://bugs.launchpad.net/bugs/1773509 ELAN0612 touchpad uses elan_i2c as its driver. ELAN0612 is being included in newer laptops, so add it to ACPI table to enable the touchpad. Signed-off-by:
Johannes Wienke <languitar@semipol.de> Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Signed-off-by:
-
Lei Xue authored
BugLink: https://bugs.launchpad.net/bugs/1774336 There is a potential race in fscache operation enqueuing for reading and copying multiple pages from cachefiles to netfs. If this race occurs, an oops similar to the following is seen: [585042.202316] FS-Cache: [585042.202343] FS-Cache: Assertion failed [585042.202367] FS-Cache: 6 == 5 is false [585042.202452] ------------[ cut here ]------------ [585042.202480] kernel BUG at fs/fscache/operation.c:494! ... [585042.209600] Call Trace: [585042.211233] [<ffffffffc034c29a>] fscache_op_work_func+0x2a/0x50 [fscache] [585042.212677] [<ffffffff81095a70>] process_one_work+0x150/0x3f0 [585042.213550] [<ffffffff810961ea>] worker_thread+0x11a/0x470 ... The race occurs in the following situation: One thread is in cachefiles_read_waiter: 1) object->work_lock is taken. 2) the operation is added to the to_do list. 3) the work lock is dropped. 4) fscache_enqueue_retrieval is called, which takes a reference. Another thread is in cachefiles_read_copier: 1) object->work_lock is taken 2) an item is popped off the to_do list. 3) object->work_lock is dropped. 4) some processing is done on the item, and fscache_put_retrieval() is called, dropping a reference. Now if the this process in cachefiles_read_copier takes place *between* steps 3 and 4 in cachefiles_read_waiter, a reference will be dropped before it is taken, which leads to the object's reference count hitting zero, which leads to lifecycle events for the object happening too soon, leading to the assertion failure later on. Move fscache_enqueue_retrieval under the lock in cachefiles_read_waiter. This means that the object cannot be popped off the to_do list until it is in a fully consistent state with the reference taken. Signed-off-by:
Lei Xue <carmark.dlut@gmail.com> Reviewed-by:
Daniel Axtens <dja@axtens.net> [dja: rewrite and expand commit message] (From https://www.redhat.com/archives/linux-cachefs/2018-February/msg00000.html This patch has been sitting on the mailing list for months with no response from the maintainer. A similar patch fixing the same issue was posted as far back as May 2017, and likewise had no response: https://www.redhat.com/archives/linux-cachefs/2017-May/msg00002.html I poked the list recently and also got nothing: https://www.redhat.com/archives/linux-cachefs/2018-May/msg00000.html and the problem was again reported and this patch validated by another user: https://www.redhat.com/archives/linux-cachefs/2018-May/msg00001.html Hence the submission as a sauce patch.) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
-
Jens Axboe authored
BugLink: http://bugs.launchpad.net/bugs/1772575 We have this: ERROR: "__aeabi_ldivmod" [drivers/block/nbd.ko] undefined! ERROR: "__divdi3" [drivers/block/nbd.ko] undefined! nbd.c:(.text+0x247c72): undefined reference to `__divdi3' due to a recent commit, that did 64-bit division. Use the proper divider function so that 32-bit compiles don't break. Fixes: ef77b515 ("nbd: use loff_t for blocksize and nbd_set_size args") Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit e88f72cb) Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1772775 This reverts commit b699d003. As per Eric Dumazet, the pskb_may_pull() is a NOP in this particular case, so the 'iph' reload is unnecessary. Signed-off-by:
-
Mimi Zohar authored
BugLink: http://bugs.launchpad.net/bugs/1771826 Userspace applications have been modified to write security xattrs, but they are not context aware. In the case of security.ima, the security xattr can be either a file hash or a file signature. Permitting writing one, but not the other requires the application to be context aware. In addition, userspace applications might write files to a staging area, which might not be in policy, and then change some file metadata (eg. owner) making it in policy. As a result, these files are not labeled properly. This reverts commit c68ed80c, which prevents writing file hashes as security.ima xattrs. Requested-by:
Patrick Ohly <patrick.ohly@intel.com> Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> (cherry picked from commit f5acb3dc) Signed-off-by:
-
Josef Bacik authored
BugLink: http://bugs.launchpad.net/bugs/1772575 If we have large devices (say like the 40t drive I was trying to test with) we will end up overflowing the int arguments to nbd_set_size and not get the right size for our device. Fix this by using loff_t everywhere so I don't have to think about this again. Thanks, Signed-off-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
-
Eric Desrochers authored
BugLink: https://bugs.launchpad.net/bugs/1771301 When IPv6 is compiled but disabled at runtime, __vxlan_sock_add returns -EAFNOSUPPORT. For metadata based tunnels, this causes failure of the whole operation of bringing up the tunnel. Ignore failure of IPv6 socket creation for metadata based tunnels caused by IPv6 not being available. Fixes: b1be00a6 ("vxlan: support both IPv4 and IPv6 sockets in a single vxlan device") Signed-off-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
-
Andy Whitcroft authored
The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including this "name" field. This pointer cannot be used by the user and it will leak a kernel address to user-space, which will reveal the location of kernel code and data and undermine KASLR protection. Model this code after the compat ioctl which copies the returned data to a previously cleared temporary structure on the stack (excluding the name pointer) and copy out to userspace from there. As we already have an inparam union with an appropriate member and that memory is already cleared even for read only calls make use of that as a temporary store. Based on an initial patch by Brian Belleville. CVE-2018-7755 Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
-
Laurent Pinchart authored
BugLink: https://bugs.launchpad.net/bugs/1773905 UVC 1.5 devices report a bInterfaceProtocol value set to 1 in their interface descriptors. The uvcvideo driver only matches on bInterfaceProtocol 0, preventing those devices from being detected. More changes to the driver are needed for full UVC 1.5 compatibility. However, at least the UVC 1.5 Microsoft Surface Pro 3 cameras have been reported to work out of the box with the driver with an updated match table. Enable UVC 1.5 support in the match table to support the devices that can work with the current driver implementation. Devices that can't will fail, but that's hardly a regression as they're currently not detected at all anyway. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit 8afe97be) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-By:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1772671 Only print a single newline between the "Seccomp" and "Speculation_Store_Bypass" lines in /proc/PID/status files. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1744173 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. If so we just fail, we don't support migrating from a patched to an unpatched machine. Or we do support it, but there will be no RFI flush enabled on the destination. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Breno Leitao <brenohl@br.ibm.com> Signed-off-by:
-
Nicholas Piggin authored
BugLink: https://bugs.launchpad.net/bugs/1744173 The fallback RFI flush is used when firmware does not provide a way to flush the cache. It's a "displacement flush" that evicts useful data by displacing it with an uninteresting buffer. The flush has to take care to work with implementation specific cache replacment policies, so the recipe has been in flux. The initial slow but conservative approach is to touch all lines of a congruence class, with dependencies between each load. It has since been determined that a linear pattern of loads without dependencies is sufficient, and is significantly faster. Measuring the speed of a null syscall with RFI fallback flush enabled gives the relative improvement: P8 - 1.83x P9 - 1.75x The flush also becomes simpler and more adaptable to different cache geometries. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Gustavo Walbon <gwalbon@linux.vnet.ibm.com> Signed-off-by:
-
- 05 Jun, 2018 1 commit
-
-
Juerg Haefliger authored
Ignore: yes Signed-off-by:
-
- 25 May, 2018 8 commits
-
-
Stefan Bader authored
Signed-off-by: -
Konrad Rzeszutek Wilk authored
The X86_FEATURE_SSBD is an synthetic CPU feature - that is it bit location has no relevance to the real CPUID 0x7.EBX[31] bit position. For that we need the new CPU feature name. Fixes: 52817587 ("x86/cpufeatures: Disentangle SSBD enumeration") CC: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: stable@vger.kernel.org Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CVE-2018-3639 (x86) (backported from https://patchwork.kernel.org/patch/10416823/) [smb: context] Signed-off-by:
-
Konrad Rzeszutek Wilk authored
The "336996 Speculative Execution Side Channel Mitigations" from May defines this as SSB_NO, hence lets sync-up. Signed-off-by:
-
Tom Lendacky authored
Expose the new virtualized architectural mechanism, VIRT_SSBD, for using speculative store bypass disable (SSBD) under SVM. This will allow guests to use SSBD on hardware that uses non-architectural mechanisms for enabling SSBD. [ tglx: Folded the migration fixup from Paolo Bonzini ] Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Thomas Gleixner authored
Add the necessary logic for supporting the emulated VIRT_SPEC_CTRL MSR to x86_virt_spec_ctrl(). If either X86_FEATURE_LS_CFG_SSBD or X86_FEATURE_VIRT_SPEC_CTRL is set then use the new guest_virt_spec_ctrl argument to check whether the state must be modified on the host. The update reuses speculative_store_bypass_update() so the ZEN-specific sibling coordination can be reused. Signed-off-by:
-
Thomas Gleixner authored
x86_spec_ctrL_mask is intended to mask out bits from a MSR_SPEC_CTRL value which are not to be modified. However the implementation is not really used and the bitmask was inverted to make a check easier, which was removed in "x86/bugs: Remove x86_spec_ctrl_set()" Aside of that it is missing the STIBP bit if it is supported by the platform, so if the mask would be used in x86_virt_spec_ctrl() then it would prevent a guest from setting STIBP. Add the STIBP bit if supported and use the mask in x86_virt_spec_ctrl() to sanitize the value which is supplied by the guest. Signed-off-by:
Borislav Petkov <bp@suse.de> CVE-2018-3639 (x86) (cherry-picked from commit be6fcb54) Signed-off-by:
-
Thomas Gleixner authored
x86_spec_ctrl_set() is only used in bugs.c and the extra mask checks there provide no real value as both call sites can just write x86_spec_ctrl_base to MSR_SPEC_CTRL. x86_spec_ctrl_base is valid and does not need any extra masking or checking. Signed-off-by:
-
Thomas Gleixner authored
x86_spec_ctrl_base is the system wide default value for the SPEC_CTRL MSR. x86_spec_ctrl_get_default() returns x86_spec_ctrl_base and was intended to prevent modification to that variable. Though the variable is read only after init and globaly visible already. Remove the function and export the variable instead. Signed-off-by:
-
