1. 15 5月, 2019 5 次提交
    • T
      x86/speculation/mds: Add mitigation control for MDS · 29510670
      Thomas Gleixner 提交于
      commit bc1241700acd82ec69fde98c5763ce51086269f8 upstream
      
      Now that the mitigations are in place, add a command line parameter to
      control the mitigation, a mitigation selector function and a SMT update
      mechanism.
      
      This is the minimal straight forward initial implementation which just
      provides an always on/off mode. The command line parameter is:
      
        mds=[full|off]
      
      This is consistent with the existing mitigations for other speculative
      hardware vulnerabilities.
      
      The idle invocation is dynamically updated according to the SMT state of
      the system similar to the dynamic update of the STIBP mitigation. The idle
      mitigation is limited to CPUs which are only affected by MSBDS and not any
      other variant, because the other variants cannot be mitigated on SMT
      enabled systems.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NJon Masters <jcm@redhat.com>
      Tested-by: NJon Masters <jcm@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29510670
    • T
      x86/speculation/mds: Conditionally clear CPU buffers on idle entry · 4df98b3f
      Thomas Gleixner 提交于
      commit 07f07f55a29cb705e221eda7894dd67ab81ef343 upstream
      
      Add a static key which controls the invocation of the CPU buffer clear
      mechanism on idle entry. This is independent of other MDS mitigations
      because the idle entry invocation to mitigate the potential leakage due to
      store buffer repartitioning is only necessary on SMT systems.
      
      Add the actual invocations to the different halt/mwait variants which
      covers all usage sites. mwaitx is not patched as it's not available on
      Intel CPUs.
      
      The buffer clear is only invoked before entering the C-State to prevent
      that stale data from the idling CPU is spilled to the Hyper-Thread sibling
      after the Store buffer got repartitioned and all entries are available to
      the non idle sibling.
      
      When coming out of idle the store buffer is partitioned again so each
      sibling has half of it available. Now CPU which returned from idle could be
      speculatively exposed to contents of the sibling, but the buffers are
      flushed either on exit to user space or on VMENTER.
      
      When later on conditional buffer clearing is implemented on top of this,
      then there is no action required either because before returning to user
      space the context switch will set the condition flag which causes a flush
      on the return to user path.
      
      Note, that the buffer clearing on idle is only sensible on CPUs which are
      solely affected by MSBDS and not any other variant of MDS because the other
      MDS variants cannot be mitigated when SMT is enabled, so the buffer
      clearing on idle would be a window dressing exercise.
      
      This intentionally does not handle the case in the acpi/processor_idle
      driver which uses the legacy IO port interface for C-State transitions for
      two reasons:
      
       - The acpi/processor_idle driver was replaced by the intel_idle driver
         almost a decade ago. Anything Nehalem upwards supports it and defaults
         to that new driver.
      
       - The legacy IO port interface is likely to be used on older and therefore
         unaffected CPUs or on systems which do not receive microcode updates
         anymore, so there is no point in adding that.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NFrederic Weisbecker <frederic@kernel.org>
      Reviewed-by: NJon Masters <jcm@redhat.com>
      Tested-by: NJon Masters <jcm@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4df98b3f
    • T
      x86/speculation/mds: Clear CPU buffers on exit to user · e4fa775b
      Thomas Gleixner 提交于
      commit 04dcbdb8057827b043b3c71aa397c4c63e67d086 upstream
      
      Add a static key which controls the invocation of the CPU buffer clear
      mechanism on exit to user space and add the call into
      prepare_exit_to_usermode() and do_nmi() right before actually returning.
      
      Add documentation which kernel to user space transition this covers and
      explain why some corner cases are not mitigated.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NFrederic Weisbecker <frederic@kernel.org>
      Reviewed-by: NJon Masters <jcm@redhat.com>
      Tested-by: NJon Masters <jcm@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4fa775b
    • T
      x86/speculation/mds: Add mds_clear_cpu_buffers() · 1f7c31be
      Thomas Gleixner 提交于
      commit 6a9e529272517755904b7afa639f6db59ddb793e upstream
      
      The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by
      clearing the affected CPU buffers. The mechanism for clearing the buffers
      uses the unused and obsolete VERW instruction in combination with a
      microcode update which triggers a CPU buffer clear when VERW is executed.
      
      Provide a inline function with the assembly magic. The argument of the VERW
      instruction must be a memory operand as documented:
      
        "MD_CLEAR enumerates that the memory-operand variant of VERW (for
         example, VERW m16) has been extended to also overwrite buffers affected
         by MDS. This buffer overwriting functionality is not guaranteed for the
         register operand variant of VERW."
      
      Documentation also recommends to use a writable data segment selector:
      
        "The buffer overwriting occurs regardless of the result of the VERW
         permission check, as well as when the selector is null or causes a
         descriptor load segment violation. However, for lowest latency we
         recommend using a selector that indicates a valid writable data
         segment."
      
      Add x86 specific documentation about MDS and the internal workings of the
      mitigation.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NFrederic Weisbecker <frederic@kernel.org>
      Reviewed-by: NJon Masters <jcm@redhat.com>
      Tested-by: NJon Masters <jcm@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f7c31be
    • S
      Documentation/l1tf: Fix small spelling typo · 34aae15c
      Salvatore Bonaccorso 提交于
      commit 60ca05c3b44566b70d64fbb8e87a6e0c67725468 upstream
      
      Fix small typo (wiil -> will) in the "3.4. Nested virtual machines"
      section.
      
      Fixes: 5b76a3cf ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry")
      Cc: linux-kernel@vger.kernel.org
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-doc@vger.kernel.org
      Cc: trivial@kernel.org
      Signed-off-by: NSalvatore Bonaccorso <carnil@debian.org>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34aae15c
  2. 08 5月, 2019 1 次提交
    • A
      USB: core: Fix bug caused by duplicate interface PM usage counter · 83c6688d
      Alan Stern 提交于
      commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream.
      
      The syzkaller fuzzer reported a bug in the USB hub driver which turned
      out to be caused by a negative runtime-PM usage counter.  This allowed
      a hub to be runtime suspended at a time when the driver did not expect
      it.  The symptom is a WARNING issued because the hub's status URB is
      submitted while it is already active:
      
      	URB 0000000031fb463e submitted while active
      	WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363
      
      The negative runtime-PM usage count was caused by an unfortunate
      design decision made when runtime PM was first implemented for USB.
      At that time, USB class drivers were allowed to unbind from their
      interfaces without balancing the usage counter (i.e., leaving it with
      a positive count).  The core code would take care of setting the
      counter back to 0 before allowing another driver to bind to the
      interface.
      
      Later on when runtime PM was implemented for the entire kernel, the
      opposite decision was made: Drivers were required to balance their
      runtime-PM get and put calls.  In order to maintain backward
      compatibility, however, the USB subsystem adapted to the new
      implementation by keeping an independent usage counter for each
      interface and using it to automatically adjust the normal usage
      counter back to 0 whenever a driver was unbound.
      
      This approach involves duplicating information, but what is worse, it
      doesn't work properly in cases where a USB class driver delays
      decrementing the usage counter until after the driver's disconnect()
      routine has returned and the counter has been adjusted back to 0.
      Doing so would cause the usage counter to become negative.  There's
      even a warning about this in the USB power management documentation!
      
      As it happens, this is exactly what the hub driver does.  The
      kick_hub_wq() routine increments the runtime-PM usage counter, and the
      corresponding decrement is carried out by hub_event() in the context
      of the hub_wq work-queue thread.  This work routine may sometimes run
      after the driver has been unbound from its interface, and when it does
      it causes the usage counter to go negative.
      
      It is not possible for hub_disconnect() to wait for a pending
      hub_event() call to finish, because hub_disconnect() is called with
      the device lock held and hub_event() acquires that lock.  The only
      feasible fix is to reverse the original design decision: remove the
      duplicate interface-specific usage counter and require USB drivers to
      balance their runtime PM gets and puts.  As far as I know, all
      existing drivers currently do this.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83c6688d
  3. 04 5月, 2019 1 次提交
  4. 02 5月, 2019 2 次提交
  5. 06 4月, 2019 1 次提交
    • N
      ARM: 8833/1: Ensure that NEON code always compiles with Clang · d93fe5e6
      Nathan Chancellor 提交于
      [ Upstream commit de9c0d49d85dc563549972edc5589d195cd5e859 ]
      
      While building arm32 allyesconfig, I ran into the following errors:
      
        arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
        '-mfloat-abi=softfp -mfpu=neon'
      
        In file included from lib/raid6/neon1.c:27:
        /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
        error: "NEON support not enabled"
      
      Building V=1 showed NEON_FLAGS getting passed along to Clang but
      __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
      only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
      which is the '-march' value for allyesconfig.
      
      >From lib/Basic/Targets/ARM.cpp in the Clang source:
      
        // This only gets set when Neon instructions are actually available, unlike
        // the VFP define, hence the soft float and arch check. This is subtly
        // different from gcc, we follow the intent which was that it should be set
        // when Neon instructions are actually available.
        if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
          Builder.defineMacro("__ARM_NEON", "1");
          Builder.defineMacro("__ARM_NEON__");
          // current AArch32 NEON implementations do not support double-precision
          // floating-point even when it is present in VFP.
          Builder.defineMacro("__ARM_NEON_FP",
                              "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
        }
      
      Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
      beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
      definined by Clang. This doesn't functionally change anything because
      that code will only run where NEON is supported, which is implicitly
      armv7.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/287Suggested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d93fe5e6
  6. 03 4月, 2019 1 次提交
  7. 24 3月, 2019 2 次提交
    • G
      stable-kernel-rules.rst: add link to networking patch queue · 2ca85aac
      Greg Kroah-Hartman 提交于
      commit a41e8f25fa8f8f67360d88eb0eebbabe95a64bdf upstream.
      
      The networking maintainer keeps a public list of the patches being
      queued up for the next round of stable releases.  Be sure to check there
      before asking for a patch to be applied so that you do not waste
      people's time.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ca85aac
    • S
      clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability · e19ca3fe
      Samuel Holland 提交于
      commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream.
      
      The Allwinner A64 SoC is known[1] to have an unstable architectural
      timer, which manifests itself most obviously in the time jumping forward
      a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
      timer frequency of 24 MHz, implying that the time went slightly backward
      (and this was interpreted by the kernel as it jumping forward and
      wrapping around past the epoch).
      
      Investigation revealed instability in the low bits of CNTVCT at the
      point a high bit rolls over. This leads to power-of-two cycle forward
      and backward jumps. (Testing shows that forward jumps are about twice as
      likely as backward jumps.) Since the counter value returns to normal
      after an indeterminate read, each "jump" really consists of both a
      forward and backward jump from the software perspective.
      
      Unless the kernel is trapping CNTVCT reads, a userspace program is able
      to read the register in a loop faster than it changes. A test program
      running on all 4 CPU cores that reported jumps larger than 100 ms was
      run for 13.6 hours and reported the following:
      
       Count | Event
      -------+---------------------------
        9940 | jumped backward      699ms
         268 | jumped backward     1398ms
           1 | jumped backward     2097ms
       16020 | jumped forward       175ms
        6443 | jumped forward       699ms
        2976 | jumped forward      1398ms
           9 | jumped forward    356516ms
           9 | jumped forward    357215ms
           4 | jumped forward    714430ms
           1 | jumped forward   3578440ms
      
      This works out to a jump larger than 100 ms about every 5.5 seconds on
      each CPU core.
      
      The largest jump (almost an hour!) was the following sequence of reads:
          0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
      
      Note that the middle bits don't necessarily all read as all zeroes or
      all ones during the anomalous behavior; however the low 10 bits checked
      by the function in this patch have never been observed with any other
      value.
      
      Also note that smaller jumps are much more common, with backward jumps
      of 2048 (2^11) cycles observed over 400 times per second on each core.
      (Of course, this is partially explained by lower bits rolling over more
      frequently.) Any one of these could have caused the 95 year time skip.
      
      Similar anomalies were observed while reading CNTPCT (after patching the
      kernel to allow reads from userspace). However, the CNTPCT jumps are
      much less frequent, and only small jumps were observed. The same program
      as before (except now reading CNTPCT) observed after 72 hours:
      
       Count | Event
      -------+---------------------------
          17 | jumped backward      699ms
          52 | jumped forward       175ms
        2831 | jumped forward       699ms
           5 | jumped forward      1398ms
      
      Further investigation showed that the instability in CNTPCT/CNTVCT also
      affected the respective timer's TVAL register. The following values were
      observed immediately after writing CNVT_TVAL to 0x10000000:
      
       CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
      --------------------+------------+--------------------+-----------------
       0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
       0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
       0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
       0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
      
      The pattern of errors in CNTV_TVAL seemed to depend on exactly which
      value was written to it. For example, after writing 0x10101010:
      
       CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
      --------------------+------------+--------------------+-----------------
       0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
       0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
       0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
       0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
       0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
       0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
      
      I was also twice able to reproduce the issue covered by Allwinner's
      workaround[4], that writing to TVAL sometimes fails, and both CVAL and
      TVAL are left with entirely bogus values. One was the following values:
      
       CNTVCT             | CNTV_TVAL  | CNTV_CVAL
      --------------------+------------+--------------------------------------
       0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      
      ========================================================================
      
      Because the CPU can read the CNTPCT/CNTVCT registers faster than they
      change, performing two reads of the register and comparing the high bits
      (like other workarounds) is not a workable solution. And because the
      timer can jump both forward and backward, no pair of reads can
      distinguish a good value from a bad one. The only way to guarantee a
      good value from consecutive reads would be to read _three_ times, and
      take the middle value only if the three values are 1) each unique and
      2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
      if an anomaly is detected.
      
      However, since there is a distinct pattern to the bad values, we can
      optimize the common case (1022/1024 of the time) to a single read by
      simply ignoring values that match the error pattern. This still takes no
      more than 3 cycles in the worst case, and requires much less code. As an
      additional safety check, we still limit the loop iteration to the number
      of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
      
      For the TVAL registers, the simple solution is to not use them. Instead,
      read or write the CVAL and calculate the TVAL value in software.
      
      Although the manufacturer is aware of at least part of the erratum[4],
      there is no official name for it. For now, use the kernel-internal name
      "UNKNOWN1".
      
      [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
      [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
      [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
      [4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Tested-by: NAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: NSamuel Holland <samuel@sholland.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e19ca3fe
  8. 20 2月, 2019 1 次提交
  9. 26 1月, 2019 1 次提交
  10. 10 1月, 2019 1 次提交
  11. 06 12月, 2018 5 次提交
    • T
      x86/speculation: Provide IBPB always command line options · 9f3baace
      Thomas Gleixner 提交于
      commit 55a974021ec952ee460dc31ca08722158639de72 upstream
      
      Provide the possibility to enable IBPB always in combination with 'prctl'
      and 'seccomp'.
      
      Add the extra command line options and rework the IBPB selection to
      evaluate the command instead of the mode selected by the STIPB switch case.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Casey Schaufler <casey.schaufler@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Waiman Long <longman9394@gmail.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Dave Stewart <david.c.stewart@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181125185006.144047038@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f3baace
    • T
      x86/speculation: Add seccomp Spectre v2 user space protection mode · d1ec2354
      Thomas Gleixner 提交于
      commit 6b3e64c237c072797a9ec918654a60e3a46488e2 upstream
      
      If 'prctl' mode of user space protection from spectre v2 is selected
      on the kernel command-line, STIBP and IBPB are applied on tasks which
      restrict their indirect branch speculation via prctl.
      
      SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
      makes sense to prevent spectre v2 user space to user space attacks as
      well.
      
      The Intel mitigation guide documents how STIPB works:
          
         Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
         prevents the predicted targets of indirect branches on any logical
         processor of that core from being controlled by software that executes
         (or executed previously) on another logical processor of the same core.
      
      Ergo setting STIBP protects the task itself from being attacked from a task
      running on a different hyper-thread and protects the tasks running on
      different hyper-threads from being attacked.
      
      While the document suggests that the branch predictors are shielded between
      the logical processors, the observed performance regressions suggest that
      STIBP simply disables the branch predictor more or less completely. Of
      course the document wording is vague, but the fact that there is also no
      requirement for issuing IBPB when STIBP is used points clearly in that
      direction. The kernel still issues IBPB even when STIBP is used until Intel
      clarifies the whole mechanism.
      
      IBPB is issued when the task switches out, so malicious sandbox code cannot
      mistrain the branch predictor for the next user space task on the same
      logical processor.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Casey Schaufler <casey.schaufler@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Waiman Long <longman9394@gmail.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Dave Stewart <david.c.stewart@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181125185006.051663132@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1ec2354
    • T
      x86/speculation: Enable prctl mode for spectre_v2_user · 7b62ef14
      Thomas Gleixner 提交于
      commit 7cc765a67d8e04ef7d772425ca5a2a1e2b894c15 upstream
      
      Now that all prerequisites are in place:
      
       - Add the prctl command line option
      
       - Default the 'auto' mode to 'prctl'
      
       - When SMT state changes, update the static key which controls the
         conditional STIBP evaluation on context switch.
      
       - At init update the static key which controls the conditional IBPB
         evaluation on context switch.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Casey Schaufler <casey.schaufler@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Waiman Long <longman9394@gmail.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Dave Stewart <david.c.stewart@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181125185005.958421388@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b62ef14
    • T
      x86/speculation: Add prctl() control for indirect branch speculation · 238ba6e7
      Thomas Gleixner 提交于
      commit 9137bb27e60e554dab694eafa4cca241fa3a694f upstream
      
      Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
      PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
      indirect branch speculation via STIBP and IBPB.
      
      Invocations:
       Check indirect branch speculation status with
       - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
      
       Enable indirect branch speculation with
       - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
      
       Disable indirect branch speculation with
       - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
      
       Force disable indirect branch speculation with
       - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
      
      See Documentation/userspace-api/spec_ctrl.rst.
      Signed-off-by: NTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Casey Schaufler <casey.schaufler@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Waiman Long <longman9394@gmail.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Dave Stewart <david.c.stewart@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      238ba6e7
    • T
      x86/speculation: Add command line control for indirect branch speculation · 71187543
      Thomas Gleixner 提交于
      commit fa1202ef224391b6f5b26cdd44cc50495e8fab54 upstream
      
      Add command line control for user space indirect branch speculation
      mitigations. The new option is: spectre_v2_user=
      
      The initial options are:
      
          -  on:   Unconditionally enabled
          - off:   Unconditionally disabled
          -auto:   Kernel selects mitigation (default off for now)
      
      When the spectre_v2= command line argument is either 'on' or 'off' this
      implies that the application to application control follows that state even
      if a contradicting spectre_v2_user= argument is supplied.
      Originally-by: NTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Casey Schaufler <casey.schaufler@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Waiman Long <longman9394@gmail.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Dave Stewart <david.c.stewart@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181125185005.082720373@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71187543
  12. 01 12月, 2018 3 次提交
    • L
      can: hi311x: Use level-triggered interrupt · 50d94ac1
      Lukas Wunner 提交于
      commit f164d0204b1156a7e0d8d1622c1a8d25752befec upstream.
      
      If the hi3110 shares the SPI bus with another traffic-intensive device
      and packets are received in high volume (by a separate machine sending
      with "cangen -g 0 -i -x"), reception stops after a few minutes and the
      counter in /proc/interrupts stops incrementing.  Bus state is "active".
      Bringing the interface down and back up reconvenes the reception.  The
      issue is not observed when the hi3110 is the sole device on the SPI bus.
      
      Using a level-triggered interrupt makes the issue go away and lets the
      hi3110 successfully receive 2 GByte over the course of 5 days while a
      ks8851 Ethernet chip on the same SPI bus handles 6 GByte of traffic.
      
      Unfortunately the hi3110 datasheet is mum on the trigger type.  The pin
      description on page 3 only specifies the polarity (active high):
      http://www.holtic.com/documents/371-hi-3110_v-rev-kpdf.do
      
      Cc: Mathias Duckeck <m.duckeck@kunbus.de>
      Cc: Akshay Bhat <akshay.bhat@timesys.com>
      Cc: Casey Fitzpatrick <casey.fitzpatrick@timesys.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50d94ac1
    • W
      Documentation/security-bugs: Postpone fix publication in exceptional cases · bcec3b85
      Will Deacon 提交于
      commit 544b03da39e2d7b4961d3163976ed4bfb1fac509 upstream.
      
      At the request of the reporter, the Linux kernel security team offers to
      postpone the publishing of a fix for up to 5 business days from the date
      of a report.
      
      While it is generally undesirable to keep a fix private after it has
      been developed, this short window is intended to allow distributions to
      package the fix into their kernel builds and permits early inclusion of
      the security team in the case of a co-ordinated disclosure with other
      parties. Unfortunately, discussions with major Linux distributions and
      cloud providers has revealed that 5 business days is not sufficient to
      achieve either of these two goals.
      
      As an example, cloud providers need to roll out KVM security fixes to a
      global fleet of hosts with sufficient early ramp-up and monitoring. An
      end-to-end timeline of less than two weeks dramatically cuts into the
      amount of early validation and increases the chance of guest-visible
      regressions.
      
      The consequence of this timeline mismatch is that security issues are
      commonly fixed without the involvement of the Linux kernel security team
      and are instead analysed and addressed by an ad-hoc group of developers
      across companies contributing to Linux. In some cases, mainline (and
      therefore the official stable kernels) can be left to languish for
      extended periods of time. This undermines the Linux kernel security
      process and puts upstream developers in a difficult position should they
      find themselves involved with an undisclosed security problem that they
      are unable to report due to restrictions from their employer.
      
      To accommodate the needs of these users of the Linux kernel and
      encourage them to engage with the Linux security team when security
      issues are first uncovered, extend the maximum period for which fixes
      may be delayed to 7 calendar days, or 14 calendar days in exceptional
      cases, where the logistics of QA and large scale rollouts specifically
      need to be accommodated. This brings parity with the linux-distros@
      maximum embargo period of 14 calendar days.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Amit Shah <aams@amazon.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Co-developed-by: NThomas Gleixner <tglx@linutronix.de>
      Co-developed-by: NDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NTyler Hicks <tyhicks@canonical.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcec3b85
    • W
      Documentation/security-bugs: Clarify treatment of embargoed information · 160a390a
      Will Deacon 提交于
      commit 14fdc2c5318ae420e68496975f48dc1dbef52649 upstream.
      
      The Linux kernel security team has been accused of rejecting the idea of
      security embargoes. This is incorrect, and could dissuade people from
      reporting security issues to us under the false assumption that the
      issue would leak prematurely.
      
      Clarify the handling of embargoed information in our process
      documentation.
      Co-developed-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Acked-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      160a390a
  13. 27 11月, 2018 3 次提交
    • K
      USB: Wait for extra delay time after USB_PORT_FEAT_RESET for quirky hub · ed8acd13
      Kai-Heng Feng 提交于
      commit 781f0766cc41a9dd2e5d118ef4b1d5d89430257b upstream.
      
      Devices connected under Terminus Technology Inc. Hub (1a40:0101) may
      fail to work after the system resumes from suspend:
      [  206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd
      [  206.143691] usb 3-2.4: device descriptor read/64, error -32
      [  206.351671] usb 3-2.4: device descriptor read/64, error -32
      
      Info for this hub:
      T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=480 MxCh= 4
      D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=1a40 ProdID=0101 Rev=01.11
      S:  Product=USB 2.0 Hub
      C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
      
      Some expirements indicate that the USB devices connected to the hub are
      innocent, it's the hub itself is to blame. The hub needs extra delay
      time after it resets its port.
      
      Hence wait for extra delay, if the device is connected to this quirky
      hub.
      Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed8acd13
    • K
      x86/mm: Move LDT remap out of KASLR region on 5-level paging · 4074ca7d
      Kirill A. Shutemov 提交于
      commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream
      
      On 5-level paging the LDT remap area is placed in the middle of the KASLR
      randomization region and it can overlap with the direct mapping, the
      vmalloc or the vmap area.
      
      The LDT mapping is per mm, so it cannot be moved into the P4D page table
      next to the CPU_ENTRY_AREA without complicating PGD table allocation for
      5-level paging.
      
      The 4 PGD slot gap just before the direct mapping is reserved for
      hypervisors, so it cannot be used.
      
      Move the direct mapping one slot deeper and use the resulting gap for the
      LDT remap area. The resulting layout is the same for 4 and 5 level paging.
      
      [ tglx: Massaged changelog ]
      
      Fixes: f55f0501 ("x86/pti: Put the LDT in its own PGD if PTI is on")
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NAndy Lutomirski <luto@kernel.org>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: dave.hansen@linux.intel.com
      Cc: peterz@infradead.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: bhe@redhat.com
      Cc: willy@infradead.org
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181026122856.66224-2-kirill.shutemov@linux.intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      4074ca7d
    • F
      x86/earlyprintk: Add a force option for pciserial device · 9f0e46bf
      Feng Tang 提交于
      [ Upstream commit d2266bbfa9e3e32e3b642965088ca461bd24a94f ]
      
      The "pciserial" earlyprintk variant helps much on many modern x86
      platforms, but unfortunately there are still some platforms with PCI
      UART devices which have the wrong PCI class code. In that case, the
      current class code check does not allow for them to be used for logging.
      
      Add a sub-option "force" which overrides the class code check and thus
      the use of such device can be enforced.
      
       [ bp: massage formulations. ]
      Suggested-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Stuart R . Anderson" <stuart.r.anderson@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: Frederic Weisbecker <frederic@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H Peter Anvin <hpa@linux.intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thymo van Beers <thymovanbeers@gmail.com>
      Cc: alan@linux.intel.com
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/20181002164921.25833-1-feng.tang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      9f0e46bf
  14. 21 11月, 2018 1 次提交
    • M
      ovl: automatically enable redirect_dir on metacopy=on · be677259
      Miklos Szeredi 提交于
      commit d47748e5ae5af6572e520cc9767bbe70c22ea498 upstream.
      
      Current behavior is to automatically disable metacopy if redirect_dir is
      not enabled and proceed with the mount.
      
      If "metacopy=on" mount option was given, then this behavior can confuse the
      user: no mount failure, yet metacopy is disabled.
      
      This patch makes metacopy=on imply redirect_dir=on.
      
      The converse is also true: turning off full redirect with redirect_dir=
      {off|follow|nofollow} will disable metacopy.
      
      If both metacopy=on and redirect_dir={off|follow|nofollow} is specified,
      then mount will fail, since there's no way to correctly resolve the
      conflict.
      Reported-by: NDaniel Walsh <dwalsh@redhat.com>
      Fixes: d5791044 ("ovl: Provide a mount option metacopy=on/off...")
      Cc: <stable@vger.kernel.org> # v4.19
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be677259
  15. 14 11月, 2018 4 次提交
  16. 22 10月, 2018 6 次提交
  17. 16 10月, 2018 1 次提交
  18. 30 9月, 2018 1 次提交