1. 01 12月, 2018 3 次提交
    • L
      can: hi311x: Use level-triggered interrupt · 50d94ac1
      Lukas Wunner 提交于
      commit f164d020 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 544b03da 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 14fdc2c5 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
  2. 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 d52888aa 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
  3. 21 11月, 2018 1 次提交
    • M
      ovl: automatically enable redirect_dir on metacopy=on · be677259
      Miklos Szeredi 提交于
      commit d47748e5 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
  4. 14 11月, 2018 4 次提交
  5. 22 10月, 2018 6 次提交
  6. 16 10月, 2018 1 次提交
  7. 30 9月, 2018 1 次提交
  8. 27 9月, 2018 2 次提交
  9. 20 9月, 2018 1 次提交
    • D
      KVM: x86: Control guest reads of MSR_PLATFORM_INFO · 6fbbde9a
      Drew Schmitt 提交于
      Add KVM_CAP_MSR_PLATFORM_INFO so that userspace can disable guest access
      to reads of MSR_PLATFORM_INFO.
      
      Disabling access to reads of this MSR gives userspace the control to "expose"
      this platform-dependent information to guests in a clear way. As it exists
      today, guests that read this MSR would get unpopulated information if userspace
      hadn't already set it (and prior to this patch series, only the CPUID faulting
      information could have been populated). This existing interface could be
      confusing if guests don't handle the potential for incorrect/incomplete
      information gracefully (e.g. zero reported for base frequency).
      Signed-off-by: NDrew Schmitt <dasch@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6fbbde9a
  10. 19 9月, 2018 1 次提交
  11. 17 9月, 2018 2 次提交
  12. 14 9月, 2018 1 次提交
    • M
      xen/balloon: add runtime control for scrubbing ballooned out pages · 197ecb38
      Marek Marczykowski-Górecki 提交于
      Scrubbing pages on initial balloon down can take some time, especially
      in nested virtualization case (nested EPT is slow). When HVM/PVH guest is
      started with memory= significantly lower than maxmem=, all the extra
      pages will be scrubbed before returning to Xen. But since most of them
      weren't used at all at that point, Xen needs to populate them first
      (from populate-on-demand pool). In nested virt case (Xen inside KVM)
      this slows down the guest boot by 15-30s with just 1.5GB needed to be
      returned to Xen.
      
      Add runtime parameter to enable/disable it, to allow initially disabling
      scrubbing, then enable it back during boot (for example in initramfs).
      Such usage relies on assumption that a) most pages ballooned out during
      initial boot weren't used at all, and b) even if they were, very few
      secrets are in the guest at that time (before any serious userspace
      kicks in).
      Convert CONFIG_XEN_SCRUB_PAGES to CONFIG_XEN_SCRUB_PAGES_DEFAULT (also
      enabled by default), controlling default value for the new runtime
      switch.
      Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      197ecb38
  13. 12 9月, 2018 1 次提交
  14. 10 9月, 2018 1 次提交
  15. 07 9月, 2018 1 次提交
  16. 03 9月, 2018 3 次提交
  17. 02 9月, 2018 1 次提交
  18. 31 8月, 2018 1 次提交
  19. 30 8月, 2018 5 次提交
  20. 29 8月, 2018 1 次提交