- 06 Jun, 2018 9 commits
-
-
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:
David S. Miller <davem@davemloft.net> (cherry picked from commit f4eb17e1) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Juerg Haefliger <juergh@canonical.com>
-
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:
Jens Axboe <axboe@fb.com> (back ported from commit ef77b515) 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:
Thadeu Lima de Souza Cascardo <cascardo@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:
Khalid Elmously <khalid.elmously@canonical.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 21 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:
Thomas Gleixner <tglx@linutronix.de> CVE-2018-3639 (x86) (cherry-picked from commit 240da953) 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:
-
Borislav Petkov authored
Function bodies are very similar and are going to grow more almost identical code. Add a bool arg to determine whether SPEC_CTRL is being set for the guest or restored to the host. No functional changes. Signed-off-by:
-
Thomas Gleixner authored
The upcoming support for the virtual SPEC_CTRL MSR on AMD needs to reuse speculative_store_bypass_update() to avoid code duplication. Add an argument for supplying a thread info (TIF) value and create a wrapper speculative_store_bypass_update_current() which is used at the existing call site. Signed-off-by:
-
Tom Lendacky authored
Some AMD processors only support a non-architectural means of enabling speculative store bypass disable (SSBD). To allow a simplified view of this to a guest, an architectural definition has been created through a new CPUID bit, 0x80000008_EBX[25], and a new MSR, 0xc001011f. With this, a hypervisor can virtualize the existence of this definition and provide an architectural method for using SSBD to a guest. Add the new CPUID feature, the new MSR and update the existing SSBD support to use this MSR when present. Signed-off-by:
-
Thomas Gleixner authored
AMD is proposing a VIRT_SPEC_CTRL MSR to handle the Speculative Store Bypass Disable via MSR_AMD64_LS_CFG so that guests do not have to care about the bit position of the SSBD bit and thus facilitate migration. Also, the sibling coordination on Family 17H CPUs can only be done on the host. Extend x86_spec_ctrl_set_guest() and x86_spec_ctrl_restore_host() with an extra argument for the VIRT_SPEC_CTRL MSR. Hand in 0 from VMX and in SVM add a new virt_spec_ctrl member to the CPU data structure which is going to be used in later patches for the actual implementation. Signed-off-by:
-
Thomas Gleixner authored
The AMD64_LS_CFG MSR is a per core MSR on Family 17H CPUs. That means when hyperthreading is enabled the SSBD bit toggle needs to take both cores into account. Otherwise the following situation can happen: CPU0 CPU1 disable SSB disable SSB enable SSB <- Enables it for the Core, i.e. for CPU0 as well So after the SSB enable on CPU1 the task on CPU0 runs with SSB enabled again. On Intel the SSBD control is per core as well, but the synchronization logic is implemented behind the per thread SPEC_CTRL MSR. It works like this: CORE_SPEC_CTRL = THREAD0_SPEC_CTRL | THREAD1_SPEC_CTRL i.e. if one of the threads enables a mitigation then this affects both and the mitigation is only disabled in the core when both threads disabled it. Add the necessary synchronization logic for AMD family 17H. Unfortunately that requires a spinlock to serialize the access to the MSR, but the locks are only shared between siblings. Signed-off-by:
-
Thomas Gleixner authored
Add a ZEN feature bit so family-dependent static_cpu_has() optimizations can be built for ZEN. Signed-off-by:
-
Borislav Petkov authored
CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on models up to B1. But they do support CPB (AMD's Core Performance Boosting cpufreq CPU feature), so fix that. Signed-off-by:
Ingo Molnar <mingo@kernel.org> CVE-2018-3639 (x86) (backported from commit f7f3dc00) Signed-off-by:
-
Thomas Gleixner authored
The SSBD enumeration is similarly to the other bits magically shared between Intel and AMD though the mechanisms are different. Make X86_FEATURE_SSBD synthetic and set it depending on the vendor specific features or family dependent setup. Change the Intel bit to X86_FEATURE_SPEC_CTRL_SSBD to denote that SSBD is controlled via MSR_SPEC_CTRL and fix up the usage sites. Signed-off-by:
-
Thomas Gleixner authored
The availability of the SPEC_CTRL MSR is enumerated by a CPUID bit on Intel and implied by IBRS or STIBP support on AMD. That's just confusing and in case an AMD CPU has IBRS not supported because the underlying problem has been fixed but has another bit valid in the SPEC_CTRL MSR, the thing falls apart. Add a synthetic feature bit X86_FEATURE_MSR_SPEC_CTRL to denote the availability on both Intel and AMD. While at it replace the boot_cpu_has() checks with static_cpu_has() where possible. This prevents late microcode loading from exposing SPEC_CTRL, but late loading is already very limited as it does not reevaluate the mitigation options and other bits and pieces. Having static_cpu_has() is the simplest and least fragile solution. Signed-off-by:
-
Borislav Petkov authored
Intel and AMD have different CPUID bits hence for those use synthetic bits which get set on the respective vendor's in init_speculation_control(). So that debacles like what the commit message of c65732e4 ("x86/cpu: Restore CPUID_8000_0008_EBX reload") talks about don't happen anymore. Signed-off-by:
Jörg Otte <jrg.otte@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Link: https://lkml.kernel.org/r/20180504161815.GG9257@pd.tnic CVE-2018-3639 (x86) (backported from commit e7c587da) [smb: dropped guest_cpuid_has checks in svm.c and vmx.c] Signed-off-by:
-
Thomas Gleixner authored
svm_vcpu_run() invokes x86_spec_ctrl_restore_host() after VMEXIT, but before the host GS is restored. x86_spec_ctrl_restore_host() uses 'current' to determine the host SSBD state of the thread. 'current' is GS based, but host GS is not yet restored and the access causes a triple fault. Move the call after the host GS restore. Fixes: 885f82bf x86/process: Allow runtime control of Speculative Store Bypass Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> CVE-2018-3639 (x86) (backported from commit 15e6c22f) [smb: context adapted] Signed-off-by:
-
Konrad Rzeszutek Wilk authored
Fixes: 7bb4d366 ("x86/bugs: Make cpu_show_common() static") Fixes: 24f7fc83 ("x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation") Signed-off-by:
-
Jim Mattson authored
Cast val and (val >> 32) to (u32), so that they fit in a general-purpose register in both 32-bit and 64-bit code. [ tglx: Made it u32 instead of uintptr_t ] Fixes: c65732e4 ("x86/cpu: Restore CPUID_8000_0008_EBX reload") Signed-off-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
-
- 23 May, 2018 9 commits
-
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Turns out commit a0562819 ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some specific systems. Despite trying, I was unable to find any automagic way to determine if the OpRegion panel type is respectable or not. The only glimmer of hope I had was bit 8 in the SCIC response, but that turned out to not work either (it was always 0 on both types of systems). So, to fix the regressions without breaking the machine we know to need the OpRegion panel type, let's just add a quirk for this. Only specific machines known to require the OpRegion panel type will therefore use it. Everyone else will fall bck to the VBT panel type. The only known machine so far is a "Conrac GmbH IX45GM2". The PCI subsystem ID on this machine is just a generic 8086:2a42, so of no use. Instead we'll go with a DMI match. I suspect we can now also revert commit aeddda06 ("drm/i915: Ignore panel type from OpRegion on SKL") but let's leave that to a separate patch. v2: Do the DMI match in the opregion code directly, as dev_priv->quirks gets populated too late Cc: Rob Kramer <rob@solution-space.com> Cc: Martin van Es <martin@mrvanes.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Marco Krüger <krgsch@gmail.com> Cc: Sean Greenslade <sean@seangreenslade.com> Cc: Trudy Tective <bertslany@gmail.com> Cc: Robin Müller <rm1990@gmx.de> Cc: Alexander Kobel <a-kobel@a-kobel.de> Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com> Cc: Emil Andersen Lauridsen <mine809@gmail.com> Cc: oceans112@gmail.com Cc: James Hogan <james@albanarts.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: stable@vger.kernel.org References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a0562819 ("drm/i915: Get panel_type from OpRegion panel details") Tested-by:
Marco Krüger <krgsch@gmail.com> Tested-by:
Alexey Shumitsky <alexey.shumitsky@gmail.com> Tested-by:
Sean Greenslade <sean@seangreenslade.com> Tested-by:
Emil Andersen Lauridsen <mine809@gmail.com> Tested-by:
Robin Müller <rm1990@gmx.de> Tested-by: oceans112@gmail.com Tested-by:
Rob Kramer <rob@solution-space.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.comAcked-by:
Jani Nikula <jani.nikula@intel.com> (cherry picked from commit c8ebfad7) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Acked-by:
-
Rodrigo Vivi authored
BugLink: http://bugs.launchpad.net/bugs/1770565 According to spec: "KBL re-uses SKL values, except where specific KBL values are listed." And recently spec has changed adding different table for Display Port only. But for all SKUs (H,S,U,Y) we have slightly different values. v2: Fix wrong condition spotted by Jani. v3: Fix 7th entry of KBL H and S table - by Manasi. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476806256-13318-1-git-send-email-rodrigo.vivi@intel.com (cherry picked from commit 0fdd4918) Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 The spec was recently fixed to have the correct iboost setting for the SKL Y/U DP DDI buffer translation table entry 2. Update our tables to match. Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> (cherry picked from commit 5ac90567) Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 We no longer have any need to look up the intel_digital_port based on the passed in intel_encoder, but we still want to look up the port. Let's just move that logic into intel_ddi_get_encoder_port() and drop the dig_port stuff. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1468328376-6380-9-git-send-email-ville.syrjala@linux.intel.com (backported from commit 5a5d24dc) Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Program the 'iboost_bit' based on what the VBT says it should be for the specific port type, rather than assume it's always the same for DP and HDMI. Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 DDI buffer prorgramming works quite differently depending on the mode of the DDI port (DP/eDP/FDI vs. HDMI/DVI). Let's split the function that does the programming into two matching variants as well. Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 When the DDI port is in HDMI/DVI mode, it automagically uses the buffer translations values from entry 9. Let's make that explicit in the code. Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Now that the SKL iboost programming is done from intel_ddi_pre_enable() for HDMI, let's move the BXT bxt_ddi_vswing_sequence() call there as well. This makes things look more similar to the DP/eDP case which is handled in ddi_signal_levels(). Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit 9f332437) Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Currently we fail to program the iboost stuff for HDMI/DVI. Let's remedy that. Cc: stable@vger.kernel.org Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements") Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
