1. 01 Dec, 2018 1 commit
  2. 10 Nov, 2018 1 commit
  3. 18 Oct, 2018 3 commits
    • Eric Dumazet's avatar
      inet: frags: break the 2GB limit for frags storage · 7f617068
      Eric Dumazet authored
      Some users are willing to provision huge amounts of memory to be able
      to perform reassembly reasonnably well under pressure.
      
      Current memory tracking is using one atomic_t and integers.
      
      Switch to atomic_long_t so that 64bit arches can use more than 2GB,
      without any cost for 32bit arches.
      
      Note that this patch avoids an overflow error, if high_thresh was set
      to ~2GB, since this test in inet_frag_alloc() was never true :
      
      if (... || frag_mem_limit(nf) > nf->high_thresh)
      
      Tested:
      
      $ echo 16000000000 >/proc/sys/net/ipv4/ipfrag_high_thresh
      
      <frag DDOS>
      
      $ grep FRAG /proc/net/sockstat
      FRAG: inuse 14705885 memory 16000002880
      
      $ nstat -n ; sleep 1 ; nstat | grep Reas
      IpReasmReqds                    3317150            0.0
      IpReasmFails                    3317112            0.0
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      (cherry picked from commit 3e67f106f619dcfaf6f4e2039599bdb69848c714)
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f617068
    • Eric Dumazet's avatar
      inet: frags: use rhashtables for reassembly units · 23ce9c5c
      Eric Dumazet authored
      Some applications still rely on IP fragmentation, and to be fair linux
      reassembly unit is not working under any serious load.
      
      It uses static hash tables of 1024 buckets, and up to 128 items per bucket (!!!)
      
      A work queue is supposed to garbage collect items when host is under memory
      pressure, and doing a hash rebuild, changing seed used in hash computations.
      
      This work queue blocks softirqs for up to 25 ms when doing a hash rebuild,
      occurring every 5 seconds if host is under fire.
      
      Then there is the problem of sharing this hash table for all netns.
      
      It is time to switch to rhashtables, and allocate one of them per netns
      to speedup netns dismantle, since this is a critical metric these days.
      
      Lookup is now using RCU. A followup patch will even remove
      the refcount hold/release left from prior implementation and save
      a couple of atomic operations.
      
      Before this patch, 16 cpus (16 RX queue NIC) could not handle more
      than 1 Mpps frags DDOS.
      
      After the patch, I reach 9 Mpps without any tuning, and can use up to 2GB
      of storage for the fragments (exact number depends on frags being evicted
      after timeout)
      
      $ grep FRAG /proc/net/sockstat
      FRAG: inuse 1966916 memory 2140004608
      
      A followup patch will change the limits for 64bit arches.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: Stefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      (cherry picked from commit 648700f76b03b7e8149d13cc2bdb3355035258a9)
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23ce9c5c
    • Nicolas Ferre's avatar
      ARM: dts: at91: add new compatibility string for macb on sama5d3 · 3f724fec
      Nicolas Ferre authored
      [ Upstream commit 321cc359d899a8e988f3725d87c18a628e1cc624 ]
      
      We need this new compatibility string as we experienced different behavior
      for this 10/100Mbits/s macb interface on this particular SoC.
      Backward compatibility is preserved as we keep the alternative strings.
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f724fec
  4. 13 Oct, 2018 1 commit
  5. 04 Oct, 2018 1 commit
  6. 17 Aug, 2018 1 commit
  7. 15 Aug, 2018 10 commits
  8. 03 Aug, 2018 3 commits
  9. 22 Jul, 2018 1 commit
  10. 03 Jul, 2018 1 commit
    • Geert Uytterhoeven's avatar
      lib/vsprintf: Remove atomic-unsafe support for %pCr · ec7bea37
      Geert Uytterhoeven authored
      commit 666902e42fd8344b923c02dc5b0f37948ff4f225 upstream.
      
      "%pCr" formats the current rate of a clock, and calls clk_get_rate().
      The latter obtains a mutex, hence it must not be called from atomic
      context.
      
      Remove support for this rarely-used format, as vsprintf() (and e.g.
      printk()) must be callable from any context.
      
      Any remaining out-of-tree users will start seeing the clock's name
      printed instead of its rate.
      Reported-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Fixes: 900cca29 ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
      Link: http://lkml.kernel.org/r/1527845302-12159-5-git-send-email-geert+renesas@glider.be
      To: Jia-Ju Bai <baijiaju1990@gmail.com>
      To: Jonathan Corbet <corbet@lwn.net>
      To: Michael Turquette <mturquette@baylibre.com>
      To: Stephen Boyd <sboyd@kernel.org>
      To: Zhang Rui <rui.zhang@intel.com>
      To: Eduardo Valentin <edubezval@gmail.com>
      To: Eric Anholt <eric@anholt.net>
      To: Stefan Wahren <stefan.wahren@i2se.com>
      To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linux-doc@vger.kernel.org
      Cc: linux-clk@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-serial@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-renesas-soc@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec7bea37
  11. 26 Jun, 2018 1 commit
  12. 13 Jun, 2018 1 commit
  13. 30 May, 2018 2 commits
  14. 22 May, 2018 7 commits
    • Borislav Petkov's avatar
      Documentation/spec_ctrl: Do some minor cleanups · f79f0efe
      Borislav Petkov authored
      commit dd0792699c4058e63c0715d9a7c2d40226fcdddc upstream
      
      Fix some typos, improve formulations, end sentences with a fullstop.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f79f0efe
    • Kees Cook's avatar
      x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass · 05a85a39
      Kees Cook authored
      commit f21b53b20c754021935ea43364dbf53778eeba32 upstream
      
      Unless explicitly opted out of, anything running under seccomp will have
      SSB mitigations enabled. Choosing the "prctl" mode will disable this.
      
      [ tglx: Adjusted it to the new arch_seccomp_spec_mitigate() mechanism ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05a85a39
    • Thomas Gleixner's avatar
      prctl: Add force disable speculation · 036608d6
      Thomas Gleixner authored
      commit 356e4bfff2c5489e016fdb925adbf12a1e3950ee upstream
      
      For certain use cases it is desired to enforce mitigations so they cannot
      be undone afterwards. That's important for loader stubs which want to
      prevent a child from disabling the mitigation again. Will also be used for
      seccomp(). The extra state preserving of the prctl state for SSB is a
      preparatory step for EBPF dymanic speculation control.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      036608d6
    • Thomas Gleixner's avatar
      x86/speculation: Add prctl for Speculative Store Bypass mitigation · a078e3e8
      Thomas Gleixner authored
      commit a73ec77ee17ec556fe7f165d00314cb7c047b1ac upstream
      
      Add prctl based control for Speculative Store Bypass mitigation and make it
      the default mitigation for Intel and AMD.
      
      Andi Kleen provided the following rationale (slightly redacted):
      
       There are multiple levels of impact of Speculative Store Bypass:
      
       1) JITed sandbox.
          It cannot invoke system calls, but can do PRIME+PROBE and may have call
          interfaces to other code
      
       2) Native code process.
          No protection inside the process at this level.
      
       3) Kernel.
      
       4) Between processes.
      
       The prctl tries to protect against case (1) doing attacks.
      
       If the untrusted code can do random system calls then control is already
       lost in a much worse way. So there needs to be system call protection in
       some way (using a JIT not allowing them or seccomp). Or rather if the
       process can subvert its environment somehow to do the prctl it can already
       execute arbitrary code, which is much worse than SSB.
      
       To put it differently, the point of the prctl is to not allow JITed code
       to read data it shouldn't read from its JITed sandbox. If it already has
       escaped its sandbox then it can already read everything it wants in its
       address space, and do much worse.
      
       The ability to control Speculative Store Bypass allows to enable the
       protection selectively without affecting overall system performance.
      
      Based on an initial patch from Tim Chen. Completely rewritten.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a078e3e8
    • Thomas Gleixner's avatar
      prctl: Add speculation control prctls · 4812ffbb
      Thomas Gleixner authored
      commit b617cfc858161140d69cc0b5cc211996b557a1c7 upstream
      
      Add two new prctls to control aspects of speculation related vulnerabilites
      and their mitigations to provide finer grained control over performance
      impacting mitigations.
      
      PR_GET_SPECULATION_CTRL returns the state of the speculation misfeature
      which is selected with arg2 of prctl(2). The return value uses bit 0-2 with
      the following meaning:
      
      Bit  Define           Description
      0    PR_SPEC_PRCTL    Mitigation can be controlled per task by
                            PR_SET_SPECULATION_CTRL
      1    PR_SPEC_ENABLE   The speculation feature is enabled, mitigation is
                            disabled
      2    PR_SPEC_DISABLE  The speculation feature is disabled, mitigation is
                            enabled
      
      If all bits are 0 the CPU is not affected by the speculation misfeature.
      
      If PR_SPEC_PRCTL is set, then the per task control of the mitigation is
      available. If not set, prctl(PR_SET_SPECULATION_CTRL) for the speculation
      misfeature will fail.
      
      PR_SET_SPECULATION_CTRL allows to control the speculation misfeature, which
      is selected by arg2 of prctl(2) per task. arg3 is used to hand in the
      control value, i.e. either PR_SPEC_ENABLE or PR_SPEC_DISABLE.
      
      The common return values are:
      
      EINVAL  prctl is not implemented by the architecture or the unused prctl()
              arguments are not 0
      ENODEV  arg2 is selecting a not supported speculation misfeature
      
      PR_SET_SPECULATION_CTRL has these additional return values:
      
      ERANGE  arg3 is incorrect, i.e. it's not either PR_SPEC_ENABLE or PR_SPEC_DISABLE
      ENXIO   prctl control of the selected speculation misfeature is disabled
      
      The first supported controlable speculation misfeature is
      PR_SPEC_STORE_BYPASS. Add the define so this can be shared between
      architectures.
      
      Based on an initial patch from Tim Chen and mostly rewritten.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4812ffbb
    • Konrad Rzeszutek Wilk's avatar
      x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation · 6f70a553
      Konrad Rzeszutek Wilk authored
      commit 24f7fc83b9204d20f878c57cb77d261ae825e033 upstream
      
      Contemporary high performance processors use a common industry-wide
      optimization known as "Speculative Store Bypass" in which loads from
      addresses to which a recent store has occurred may (speculatively) see an
      older value. Intel refers to this feature as "Memory Disambiguation" which
      is part of their "Smart Memory Access" capability.
      
      Memory Disambiguation can expose a cache side-channel attack against such
      speculatively read values. An attacker can create exploit code that allows
      them to read memory outside of a sandbox environment (for example,
      malicious JavaScript in a web page), or to perform more complex attacks
      against code running within the same privilege level, e.g. via the stack.
      
      As a first step to mitigate against such attacks, provide two boot command
      line control knobs:
      
       nospec_store_bypass_disable
       spec_store_bypass_disable=[off,auto,on]
      
      By default affected x86 processors will power on with Speculative
      Store Bypass enabled. Hence the provided kernel parameters are written
      from the point of view of whether to enable a mitigation or not.
      The parameters are as follows:
      
       - auto - Kernel detects whether your CPU model contains an implementation
      	  of Speculative Store Bypass and picks the most appropriate
      	  mitigation.
      
       - on   - disable Speculative Store Bypass
       - off  - enable Speculative Store Bypass
      
      [ tglx: Reordered the checks so that the whole evaluation is not done
        	when the CPU does not support RDS ]
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f70a553
    • Konrad Rzeszutek Wilk's avatar
      x86/bugs: Expose /sys/../spec_store_bypass · 24e4dd97
      Konrad Rzeszutek Wilk authored
      commit c456442cd3a59eeb1d60293c26cbe2ff2c4e42cf upstream
      
      Add the sysfs file for the new vulerability. It does not do much except
      show the words 'Vulnerable' for recent x86 cores.
      
      Intel cores prior to family 6 are known not to be vulnerable, and so are
      some Atoms and some Xeon Phi.
      
      It assumes that older Cyrix, Centaur, etc. cores are immune.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24e4dd97
  15. 16 May, 2018 1 commit
  16. 09 May, 2018 1 commit
    • Marc Zyngier's avatar
      arm/arm64: KVM: Add PSCI version selection API · b8beca48
      Marc Zyngier authored
      commit 85bd0ba1ff9875798fad94218b627ea9f768f3c3 upstream.
      
      Although we've implemented PSCI 0.1, 0.2 and 1.0, we expose either 0.1
      or 1.0 to a guest, defaulting to the latest version of the PSCI
      implementation that is compatible with the requested version. This is
      no different from doing a firmware upgrade on KVM.
      
      But in order to give a chance to hypothetical badly implemented guests
      that would have a fit by discovering something other than PSCI 0.2,
      let's provide a new API that allows userspace to pick one particular
      version of the API.
      
      This is implemented as a new class of "firmware" registers, where
      we expose the PSCI version. This allows the PSCI version to be
      save/restored as part of a guest migration, and also set to
      any supported version if the guest requires it.
      
      Cc: stable@vger.kernel.org #4.16
      Reviewed-by: default avatarChristoffer Dall <cdall@kernel.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8beca48
  17. 29 Apr, 2018 1 commit
    • Vasily Gorbik's avatar
      s390: introduce CPU alternatives · d69aa5e6
      Vasily Gorbik authored
      [ Upstream commit 686140a1 ]
      
      Implement CPU alternatives, which allows to optionally patch newer
      instructions at runtime, based on CPU facilities availability.
      
      A new kernel boot parameter "noaltinstr" disables patching.
      
      Current implementation is derived from x86 alternatives. Although
      ideal instructions padding (when altinstr is longer then oldinstr)
      is added at compile time, and no oldinstr nops optimization has to be
      done at runtime. Also couple of compile time sanity checks are done:
      1. oldinstr and altinstr must be <= 254 bytes long,
      2. oldinstr and altinstr must not have an odd length.
      
      alternative(oldinstr, altinstr, facility);
      alternative_2(oldinstr, altinstr1, facility1, altinstr2, facility2);
      
      Both compile time and runtime padding consists of either 6/4/2 bytes nop
      or a jump (brcl) + 2 bytes nop filler if padding is longer then 6 bytes.
      
      .altinstructions and .altinstr_replacement sections are part of
      __init_begin : __init_end region and are freed after initialization.
      Signed-off-by: default avatarVasily Gorbik <gor@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d69aa5e6
  18. 13 Apr, 2018 2 commits
    • Martin Blumenstingl's avatar
      clk: meson: meson8b: add compatibles for Meson8 and Meson8m2 · a81437a7
      Martin Blumenstingl authored
      
      [ Upstream commit 855f06a1 ]
      
      The clock controller on Meson8, Meson8b and Meson8m2 is very similar
      based on the code from the Amlogic GPL kernel sources. Add separate
      compatibles for each SoC to make sure that we can easily implement
      all the small differences for each SoC later on.
      
      In general the Meson8 and Meson8m2 seem to be almost identical as they
      even share the same mach-meson8 directory in Amlogic's GPL kernel
      sources.
      The main clocks on Meson8, Meson8b and Meson8m2 are very similar,
      because they are all using the same PLL values, 90% of the clock gates
      are the same (the actual diffstat of the mach-meson8/clock.c and
      mach-meson8b/clock.c files is around 30 to 40 lines, when excluding
      all commented out code).
      The difference between the Meson8 and Meson8b clock gates seem to be:
      - Meson8 has AIU_PCLK, HDMI_RX, VCLK2_ENCT, VCLK2_ENCL, UART3,
        CSI_DIG_CLKIN gates which don't seem to be available on Meson8b
      - the gate on Meson8 for bit 7 seems to be named "_1200XXX" instead
        of "PERIPHS_TOP" (on Meson8b)
      - Meson8b has a SANA gate which doesn't seem to exist on Meson8 (or
        on Meson8 the same bit is used by the UART3 gate in Amlogic's GPL
        kernel sources)
      None of these gates is added for now, since it's unclear whether these
      definitions are actually correct (the VCLK2_ENCT gate for example is
      defined, but only used in some commented block).
      
      The main difference between all three SoCs seem to be the video (VPU)
      clocks. Apart from different supported clock rates (according to vpu.c
      in mach-meson8 and mach-meson8b from Amlogic's GPL kernel sources) the
      most notable difference is that Meson8m2 has a GP_PLL clock and a mux
      (probably the same as on the Meson GX SoCs) to support glitch-free
      (clock rate) switching.
      None of these VPU clocks are not supported by our mainline meson8b
      clock driver yet though.
      Signed-off-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a81437a7
    • Maxime Ripard's avatar
      dt-bindings: display: sun4i: Add allwinner,tcon-channel property · ed82ab87
      Maxime Ripard authored
      
      [ Upstream commit 22662f12 ]
      
      The Allwinner Timings Controller has two, mutually exclusive, channels.
      When the binding has been introduced, it was assumed that there would be
      only a single user per channel in the system.
      
      While this is likely for the channel 0 which only connects to LCD displays,
      it turns out that the channel 1 can be connected to multiple controllers in
      the SoC (HDMI and TV encoders for example). And while the simultaneous use
      of HDMI and TV outputs cannot be achieved, switching from one to the other
      at runtime definitely sounds plausible.
      
      Add an extra property, allwinner,tcon-channel, to specify for a given
      endpoint which TCON channel it is connected to, while falling back to the
      previous mechanism if that property is missing.
      Acked-by: default avatarChen-Yu Tsai <wens@csie.org>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed82ab87
  19. 08 Apr, 2018 1 commit