1. 30 Nov, 2018 1 commit
    • Johannes Weiner's avatar
      psi: make disabling/enabling easier for vendor kernels · e0c27447
      Johannes Weiner authored
      Mel Gorman reports a hackbench regression with psi that would prohibit
      shipping the suse kernel with it default-enabled, but he'd still like
      users to be able to opt in at little to no cost to others.
      
      With the current combination of CONFIG_PSI and the psi_disabled bool set
      from the commandline, this is a challenge.  Do the following things to
      make it easier:
      
      1. Add a config option CONFIG_PSI_DEFAULT_DISABLED that allows distros
         to enable CONFIG_PSI in their kernel but leave the feature disabled
         unless a user requests it at boot-time.
      
         To avoid double negatives, rename psi_disabled= to psi=.
      
      2. Make psi_disabled a static branch to eliminate any branch costs
         when the feature is disabled.
      
      In terms of numbers before and after this patch, Mel says:
      
      : The following is a comparision using CONFIG_PSI=n as a baseline against
      : your patch and a vanilla kernel
      :
      :                          4.20.0-rc4             4.20.0-rc4             4.20.0-rc4
      :                 kconfigdisable-v1r1                vanilla        psidisable-v1r1
      : Amean     1       1.3100 (   0.00%)      1.3923 (  -6.28%)      1.3427 (  -2.49%)
      : Amean     3       3.8860 (   0.00%)      4.1230 *  -6.10%*      3.8860 (  -0.00%)
      : Amean     5       6.8847 (   0.00%)      8.0390 * -16.77%*      6.7727 (   1.63%)
      : Amean     7       9.9310 (   0.00%)     10.8367 *  -9.12%*      9.9910 (  -0.60%)
      : Amean     12     16.6577 (   0.00%)     18.2363 *  -9.48%*     17.1083 (  -2.71%)
      : Amean     18     26.5133 (   0.00%)     27.8833 *  -5.17%*     25.7663 (   2.82%)
      : Amean     24     34.3003 (   0.00%)     34.6830 (  -1.12%)     32.0450 (   6.58%)
      : Amean     30     40.0063 (   0.00%)     40.5800 (  -1.43%)     41.5087 (  -3.76%)
      : Amean     32     40.1407 (   0.00%)     41.2273 (  -2.71%)     39.9417 (   0.50%)
      :
      : It's showing that the vanilla kernel takes a hit (as the bisection
      : indicated it would) and that disabling PSI by default is reasonably
      : close in terms of performance for this particular workload on this
      : particular machine so;
      
      Link: http://lkml.kernel.org/r/20181127165329.GA29728@cmpxchg.orgSigned-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Reported-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e0c27447
  2. 29 Nov, 2018 1 commit
    • Catalin Marinas's avatar
      arm64: Add workaround for Cortex-A76 erratum 1286807 · ce8c80c5
      Catalin Marinas authored
      On the affected Cortex-A76 cores (r0p0 to r3p0), if a virtual address
      for a cacheable mapping of a location is being accessed by a core while
      another core is remapping the virtual address to a new physical page
      using the recommended break-before-make sequence, then under very rare
      circumstances TLBI+DSB completes before a read using the translation
      being invalidated has been observed by other observers. The workaround
      repeats the TLBI+DSB operation and is shared with the Qualcomm Falkor
      erratum 1009
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      ce8c80c5
  3. 28 Nov, 2018 5 commits
    • Thomas Gleixner's avatar
      x86/speculation: Provide IBPB always command line options · 55a97402
      Thomas Gleixner authored
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo 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.de
      55a97402
    • Thomas Gleixner's avatar
      x86/speculation: Add seccomp Spectre v2 user space protection mode · 6b3e64c2
      Thomas Gleixner authored
      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: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo 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.de
      
      6b3e64c2
    • Thomas Gleixner's avatar
      x86/speculation: Enable prctl mode for spectre_v2_user · 7cc765a6
      Thomas Gleixner authored
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo 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.de
      
      7cc765a6
    • Thomas Gleixner's avatar
      x86/speculation: Add prctl() control for indirect branch speculation · 9137bb27
      Thomas Gleixner authored
      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: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo 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.de
      9137bb27
    • Thomas Gleixner's avatar
      x86/speculation: Add command line control for indirect branch speculation · fa1202ef
      Thomas Gleixner authored
      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: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo 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.de
      fa1202ef
  4. 24 Nov, 2018 1 commit
  5. 22 Nov, 2018 1 commit
    • Benjamin Tissoires's avatar
      Revert "Input: Add the `REL_WHEEL_HI_RES` event code" · ffe0e7cf
      Benjamin Tissoires authored
      This reverts commit aaf9978c.
      
      Quoting Peter:
      
      There is a HID feature report called "Resolution Multiplier"
      Described in the "Enhanced Wheel Support in Windows" doc and
      the "USB HID Usage Tables" page 30.
      
      http://download.microsoft.com/download/b/d/1/bd1f7ef4-7d72-419e-bc5c-9f79ad7bb66e/wheel.docx
      https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
      
      This was new for Windows Vista, so we're only a decade behind here. I only
      accidentally found this a few days ago while debugging a stuck button on a
      Microsoft mouse.
      
      The docs above describe it like this: a wheel control by default sends
      value 1 per notch. If the resolution multiplier is active, the wheel is
      expected to send a value of $multiplier per notch (e.g. MS Sculpt mouse) or
      just send events more often, i.e. for less physical motion (e.g. MS Comfort
      mouse).
      
      For the latter, you need the right HW of course. The Sculpt mouse has
      tactile wheel clicks, so nothing really changes. The Comfort mouse has
      continuous motion with no tactile clicks. Similar to the free-wheeling
      Logitech mice but without any inertia.
      
      Note that the doc also says that Vista and onwards *always* enable this
      feature where available.
      
      An example HID definition looks like this:
      
             Usage Page Generic Desktop (0x01)
             Usage Resolution Multiplier (0x48)
             Logical Minimum 0
             Logical Maximum 1
             Physical Minimum 1
             Physical Maximum 16
             Report Size 2 # in bits
             Report Count 1
             Feature (Data, Var, Abs)
      
      So the actual bits have values 0 or 1 and that reflects real values 1 or 16.
      We've only seen single-bits so far, so there's low-res and hi-res, but
      nothing in between.
      
      The multiplier is available for HID usages "Wheel" and "AC Pan" (horiz wheel).
      Microsoft suggests that
      
      > Vendors should ship their devices with smooth scrolling disabled and allow
      > Windows to enable it. This ensures that the device works like a regular HID
      > device on legacy operating systems that do not support smooth scrolling.
      (see the wheel doc linked above)
      
      The mice that we tested so far do reset on unplug.
      
      Device Support looks to be all (?) Microsoft mice but nothing else
      
      Not supported:
      - Logitech G500s, G303
      - Roccat Kone XTD
      - all the cheap Lenovo, HP, Dell, Logitech USB mice that come with a
        workstation that I could find don't have it.
      - Etekcity something something
      - Razer Imperator
      
      Supported:
      - Microsoft Comfort Optical Mouse 3000 - yes, physical: 1:4
      - Microsoft Sculpt Ergonomic Mouse - yes, physical: 1:12
      - Microsoft Surface mouse - yes, physical: 1:4
      
      So again, I think this is really just available on Microsoft mice, but
      probably all decent MS mice released over the last decade.
      
      Looking at the hardware itself:
      
      - no noticeable notches in the weel
      - low-res: 18 events per 360deg rotation (click angle 20 deg)
      - high-res: 72 events per 360deg → matches multiplier of 4
      
      - I can feel the notches during wheel turns
      - low-res: 24 events per 360 deg rotation (click angle 15 deg)
        - horiz wheel is tilt-based, continuous output value 1
      - high-res: 24 events per 360deg with value 12 → matches multiplier of 12
        - horiz wheel output rate doubles/triples?, values is 3
      
      - It's a touch strip, not a wheel so no notches
      - high-res: events have value 4 instead of 1
        a bit strange given that it doesn't actually have notches.
      
      Ok, why is this an issue for the current API? First, because the logitech
      multiplier used in Harry's patches looks suspiciously like the Resolution
      Multiplier so I think we should assume it's the same thing. Nestor, can you
      shed some light on that?
      
      - `REL_WHEEL` is defined as the number of notches, emulated where needed.
      - `REL_WHEEL_HI_RES` is the movement of the user's finger in microns.
      - `WM_MOUSEWHEEL` (Windows) is is a multiple of 120, defined as "the threshold
        for action to be taken and one such action"
        https://docs.microsoft.com/en-us/windows/desktop/inputdev/wm-mousewheel
      
      If the multiplier is set to M, this means we need an accumulated value of M
      until we can claim there was a wheel click. So after enabling the multiplier
      and setting it to the maximum (like Windows):
      - M units are 15deg rotation → 1 unit is 2620/M micron (see below). This is
        the `REL_WHEEL_HI_RES` value.
        - wheel diameter 20mm: 15 deg rotation is 2.62mm, 2620 micron (pi * 20mm /
          (360deg/15deg))
      - For every M units accumulated, send one `REL_WHEEL` event
      
      The problem here is that we've now hardcoded 20mm/15 deg into the kernel and
      we have no way of getting the size of the wheel or the click angle into the
      kernel.
      
      In userspace we now have to undo the kernel's calculation. If our click angle
      is e.g. 20 degree we have to undo the (lossy) calculation from the kernel and
      calculate the correct angle instead. This also means the 15 is a hardcoded
      option forever and cannot be changed.
      
      In hid-logitech-hidpp.c, the microns per unit is hardcoded per device.
      Harry, did you measure those by hand? We'd need to update the kernel for
      every device and there are 10 years worth of devices from MS alone.
      
      The multiplier default is 8 which is in the right ballpark, so I'm pretty
      sure this is the same as the Resolution Multiplier, just in HID++ lingo. And
      given that the 120 magic factor is what Windows uses in the end, I can't
      imagine Logitech rolling their own thing here. Nestor?
      
      And we're already fairly inaccurate with the microns anyway. The MX Anywhere
      2S has a click angle of 20 degrees (18 stops) and a 17mm wheel, so a wheel
      notch is approximately 2.67mm, one event at multiplier 8 (1/8 of a notch)
      would be 334 micron. That's only 80% of the fallback value of 406 in the
      kernel. Multiplier 6 gives us 445micron (10% off). I'm assuming multiplier 7
      doesn't exist because it's not a factor of 120.
      
      Summary:
      
      Best option may be to simply do what Windows is doing, all the HW manufacturers
      have to use that approach after all. Switch `REL_WHEEL_HI_RES` to report in
      fractions of 120, with 120 being one notch and divide that by the multiplier
      for the actual events. So e.g. the Logitech multiplier 8 would send value 15
      for each event in hi-res mode. This can be converted in userspace to
      whatever userspace needs (combined with a hwdb there that tells you wheel
      size/click angle/...).
      
      Conflicts:
      	include/uapi/linux/input-event-codes.h -> I kept the new
               reserved event in the code, so I had to adapt the revert
               slightly
      Signed-off-by: Benjamin Tissoires's avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: Harry Cutts's avatarHarry Cutts <hcutts@chromium.org>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      ffe0e7cf
  6. 20 Nov, 2018 3 commits
    • Peter Zijlstra's avatar
      perf/x86/intel: Fix regression by default disabling perfmon v4 interrupt handling · 2a5bf23d
      Peter Zijlstra authored
      Kyle Huey reported that 'rr', a replay debugger, broke due to the following commit:
      
        af3bdb99 ("perf/x86/intel: Add a separate Arch Perfmon v4 PMI handler")
      
      Rework the 'disable_counter_freezing' __setup() parameter such that we
      can explicitly enable/disable it and switch to default disabled.
      
      To this purpose, rename the parameter to "perf_v4_pmi=" which is a much
      better description and allows requiring a bool argument.
      
      [ mingo: Improved the changelog some more. ]
      Reported-by: default avatarKyle Huey <me@kylehuey.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert O'Callahan <robert@ocallahan.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Link: http://lkml.kernel.org/r/20181120170842.GZ2131@hirez.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2a5bf23d
    • Will Deacon's avatar
      Documentation/security-bugs: Postpone fix publication in exceptional cases · 544b03da
      Will Deacon authored
      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: default avatarKees Cook <keescook@chromium.org>
      Co-developed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Co-developed-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      544b03da
    • Juergen Gross's avatar
      x86/boot: Mostly revert commit ae7e1238 ("Add ACPI RSDP address to setup_header") · 38418404
      Juergen Gross authored
      Peter Anvin pointed out that commit:
      
        ae7e1238 ("x86/boot: Add ACPI RSDP address to setup_header")
      
      should be reverted as setup_header should only contain items set by the
      legacy BIOS.
      
      So revert said commit. Instead of fully reverting the dependent commit
      of:
      
        e7b66d16 ("x86/acpi, x86/boot: Take RSDP address for boot params if available")
      
      just remove the setup_header reference in order to replace it by
      a boot_params in a followup patch.
      Suggested-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: boris.ostrovsky@oracle.com
      Cc: bp@alien8.de
      Cc: daniel.kiper@oracle.com
      Cc: sstabellini@kernel.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/20181120072529.5489-2-jgross@suse.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      38418404
  7. 17 Nov, 2018 2 commits
  8. 16 Nov, 2018 5 commits
  9. 15 Nov, 2018 1 commit
    • David Howells's avatar
      rxrpc: Fix life check · 7150ceaa
      David Howells authored
      The life-checking function, which is used by kAFS to make sure that a call
      is still live in the event of a pending signal, only samples the received
      packet serial number counter; it doesn't actually provoke a change in the
      counter, rather relying on the server to happen to give us a packet in the
      time window.
      
      Fix this by adding a function to force a ping to be transmitted.
      
      kAFS then keeps track of whether there's been a stall, and if so, uses the
      new function to ping the server, resetting the timeout to allow the reply
      to come back.
      
      If there's a stall, a ping and the call is *still* stalled in the same
      place after another period, then the call will be aborted.
      
      Fixes: bc5e3a54 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
      Fixes: f4d15fb6 ("rxrpc: Provide functions for allowing cleaner handling of signals")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7150ceaa
  10. 12 Nov, 2018 1 commit
    • Douglas Anderson's avatar
      dt-bindings: phy-qcom-qmp: Fix several mistakes from prior commits · 7243ec72
      Douglas Anderson authored
      Digging through the "phy-qcom-qmp" showed me many inconsistencies
      between the bindings and the reality of the driver.  Let's fix them
      all.
      
      * In commit 2d66eab1 ("dt-bindings: phy: qmp: Add support for QMP
        phy in IPQ8074") we probably should have explicitly listed that
        there are no clocks for this PHY and also added the reset names in
        alphabetical order.  You can see that there are no clocks in the
        driver where "clk_list" is NULL.
      
      * In commit 8587b220 ("dt-bindings: phy-qcom-qmp: Update bindings
        for QMP V3 USB PHY") we probably should have listed the resets for
        this new PHY and also removed the "(Optional)" marking for the "cfg"
        reset since PHYs that need "cfg" really do need it.  It's just that
        not all PHYs need it.
      
      * In commit 7f080207 ("dt-bindings: phy-qcom-qmp: Update bindings
        for sdm845") we forgot to update one instance of the string
        "qcom,qmp-v3-usb3-phy" to be "qcom,sdm845-qmp-usb3-phy".  Let's fix
        that.  We should also have added "qcom,sdm845-qmp-usb3-uni-phy" to
        the clock-names and reset-names lists.
      
      * In commit 99c7c736 ("dt-bindings: phy-qcom-qmp: Add UFS phy
        compatible string for sdm845") we should have added the set of
        clocks and resets for "qcom,sdm845-qmp-ufs-phy".  These were taken
        from the driver.
      
      * Cleanup the wording for what properties child nodes have to make it
        more obvious which types of PHYs need clocks and resets.  This was
        sorta implicit in the "-names" description but I found myself
        confused.
      
      * As per the code not all "pcie qmp phys" have resets.  Specifically
        note that the "has_lane_rst" property in the driver is false for
        "ipq8074-qmp-pcie-phy".  Thus make it clear exactly which PHYs need
        child nodes with resets.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarEvan Green <evgreen@chromium.org>
      Reviewed-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      7243ec72
  11. 11 Nov, 2018 3 commits
  12. 09 Nov, 2018 5 commits
  13. 08 Nov, 2018 1 commit
  14. 07 Nov, 2018 4 commits
  15. 06 Nov, 2018 2 commits
  16. 05 Nov, 2018 4 commits