1. 11 1月, 2017 2 次提交
  2. 10 1月, 2017 4 次提交
    • J
      stmmac: adding new glue driver dwmac-dwc-qos-eth · d8256121
      jpinto 提交于
      This patch adds a new glue driver called dwmac-dwc-qos-eth which
      was based in the dwc_eth_qos as is. To assure retro-compatibility a slight
      tweak was also added to stmmac_platform.
      Signed-off-by: NJoao Pinto <jpinto@synopsys.com>
      Tested-by: NNiklas Cassel <niklas.cassel@axis.com>
      Reviewed-by: NLars Persson <larper@axis.com>
      Acked-by: NAlexandre TORGUE <alexandre.torgue@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8256121
    • J
      stmmac: adding DT parameter for LPI tx clock gating · b4b7b772
      jpinto 提交于
      This patch adds a new parameter to the stmmac DT: snps,en-tx-lpi-clockgating.
      It was ported from synopsys/dwc_eth_qos.c and it is useful if lpi tx clock
      gating is needed by stmmac users also.
      Signed-off-by: NJoao Pinto <jpinto@synopsys.com>
      Tested-by: NNiklas Cassel <niklas.cassel@axis.com>
      Reviewed-by: NLars Persson <larper@axis.com>
      Acked-by: NAlexandre TORGUE <alexandre.torgue@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4b7b772
    • J
      siphash: implement HalfSipHash1-3 for hash tables · 1ae2324f
      Jason A. Donenfeld 提交于
      HalfSipHash, or hsiphash, is a shortened version of SipHash, which
      generates 32-bit outputs using a weaker 64-bit key. It has *much* lower
      security margins, and shouldn't be used for anything too sensitive, but
      it could be used as a hashtable key function replacement, if the output
      is never exposed, and if the security requirement is not too high.
      
      The goal is to make this something that performance-critical jhash users
      would be willing to use.
      
      On 64-bit machines, HalfSipHash1-3 is slower than SipHash1-3, so we alias
      SipHash1-3 to HalfSipHash1-3 on those systems.
      
      64-bit x86_64:
      [    0.509409] test_siphash:     SipHash2-4 cycles: 4049181
      [    0.510650] test_siphash:     SipHash1-3 cycles: 2512884
      [    0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920
      [    0.512904] test_siphash:    JenkinsHash cycles:  978267
      So, we map hsiphash() -> SipHash1-3
      
      32-bit x86:
      [    0.509868] test_siphash:     SipHash2-4 cycles: 14812892
      [    0.513601] test_siphash:     SipHash1-3 cycles:  9510710
      [    0.515263] test_siphash: HalfSipHash1-3 cycles:  3856157
      [    0.515952] test_siphash:    JenkinsHash cycles:  1148567
      So, we map hsiphash() -> HalfSipHash1-3
      
      hsiphash() is roughly 3 times slower than jhash(), but comes with a
      considerable security improvement.
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: NJean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ae2324f
    • J
      siphash: add cryptographically secure PRF · 2c956a60
      Jason A. Donenfeld 提交于
      SipHash is a 64-bit keyed hash function that is actually a
      cryptographically secure PRF, like HMAC. Except SipHash is super fast,
      and is meant to be used as a hashtable keyed lookup function, or as a
      general PRF for short input use cases, such as sequence numbers or RNG
      chaining.
      
      For the first usage:
      
      There are a variety of attacks known as "hashtable poisoning" in which an
      attacker forms some data such that the hash of that data will be the
      same, and then preceeds to fill up all entries of a hashbucket. This is
      a realistic and well-known denial-of-service vector. Currently
      hashtables use jhash, which is fast but not secure, and some kind of
      rotating key scheme (or none at all, which isn't good). SipHash is meant
      as a replacement for jhash in these cases.
      
      There are a modicum of places in the kernel that are vulnerable to
      hashtable poisoning attacks, either via userspace vectors or network
      vectors, and there's not a reliable mechanism inside the kernel at the
      moment to fix it. The first step toward fixing these issues is actually
      getting a secure primitive into the kernel for developers to use. Then
      we can, bit by bit, port things over to it as deemed appropriate.
      
      While SipHash is extremely fast for a cryptographically secure function,
      it is likely a bit slower than the insecure jhash, and so replacements
      will be evaluated on a case-by-case basis based on whether or not the
      difference in speed is negligible and whether or not the current jhash usage
      poses a real security risk.
      
      For the second usage:
      
      A few places in the kernel are using MD5 or SHA1 for creating secure
      sequence numbers, syn cookies, port numbers, or fast random numbers.
      SipHash is a faster and more fitting, and more secure replacement for MD5
      in those situations. Replacing MD5 and SHA1 with SipHash for these uses is
      obvious and straight-forward, and so is submitted along with this patch
      series. There shouldn't be much of a debate over its efficacy.
      
      Dozens of languages are already using this internally for their hash
      tables and PRFs. Some of the BSDs already use this in their kernels.
      SipHash is a widely known high-speed solution to a widely known set of
      problems, and it's time we catch-up.
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: NJean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Eric Biggers <ebiggers3@gmail.com>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c956a60
  3. 08 1月, 2017 1 次提交
  4. 04 1月, 2017 2 次提交
  5. 03 1月, 2017 3 次提交
  6. 30 12月, 2016 3 次提交
    • A
      vfio-mdev: Make mdev_parent private · 9372e6fe
      Alex Williamson 提交于
      Rather than hoping for good behavior by marking some elements
      internal, enforce it by making the entire structure private and
      creating an accessor function for the one useful external field.
      
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Cc: Jike Song <jike.song@intel.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
      9372e6fe
    • A
      vfio-mdev: de-polute the namespace, rename parent_device & parent_ops · 42930553
      Alex Williamson 提交于
      Add an mdev_ prefix so we're not poluting the namespace so much.
      
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Cc: Jike Song <jike.song@intel.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
      42930553
    • M
      net: dev_weight: TX/RX orthogonality · 3d48b53f
      Matthias Tafelmeier 提交于
      Oftenly, introducing side effects on packet processing on the other half
      of the stack by adjusting one of TX/RX via sysctl is not desirable.
      There are cases of demand for asymmetric, orthogonal configurability.
      
      This holds true especially for nodes where RPS for RFS usage on top is
      configured and therefore use the 'old dev_weight'. This is quite a
      common base configuration setup nowadays, even with NICs of superior processing
      support (e.g. aRFS).
      
      A good example use case are nodes acting as noSQL data bases with a
      large number of tiny requests and rather fewer but large packets as responses.
      It's affordable to have large budget and rx dev_weights for the
      requests. But as a side effect having this large a number on TX
      processed in one run can overwhelm drivers.
      
      This patch therefore introduces an independent configurability via sysctl to
      userland.
      Signed-off-by: NMatthias Tafelmeier <matthias.tafelmeier@gmx.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d48b53f
  7. 28 12月, 2016 4 次提交
  8. 27 12月, 2016 1 次提交
  9. 21 12月, 2016 3 次提交
    • D
      net: hix5hd2_gmac: fix compatible strings name · f7ca8e3b
      Dongpo Li 提交于
      The SoC hix5hd2 compatible string has the suffix "-gmac" and
      we should not change its compatible string.
      So we should name all the compatible string with the suffix "-gmac".
      Creating a new name suffix "-gemac" is unnecessary.
      
      We also add another SoC compatible string in dt binding documentation
      and describe which generic version the SoC belongs to.
      
      Fixes: d0fb6ba7 ("net: hix5hd2_gmac: add generic compatible string")
      Signed-off-by: NDongpo Li <lidongpo@hisilicon.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7ca8e3b
    • J
      dt: bindings: net: use boolean dt properties for eee broken modes · 308d3165
      jbrunet 提交于
      The patches regarding eee-broken-modes was merged before all people
      involved could find an agreement on the best way to move forward.
      
      While we agreed on having a DT property to mark particular modes as broken,
      the value used for eee-broken-modes mapped the phy register in very direct
      way. Because of this, the concern is that it could be used to implement
      configuration policies instead of describing a broken HW.
      
      In the end, having a boolean property for each mode seems to be preferred
      over one bit field value mapping the register (too) directly.
      
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      308d3165
    • M
      ima: define a canonical binary_runtime_measurements list format · d68a6fe9
      Mimi Zohar 提交于
      The IMA binary_runtime_measurements list is currently in platform native
      format.
      
      To allow restoring a measurement list carried across kexec with a
      different endianness than the targeted kernel, this patch defines
      little-endian as the canonical format.  For big endian systems wanting
      to save/restore the measurement list from a system with a different
      endianness, a new boot command line parameter named "ima_canonical_fmt"
      is defined.
      
      Considerations: use of the "ima_canonical_fmt" boot command line option
      will break existing userspace applications on big endian systems
      expecting the binary_runtime_measurements list to be in platform native
      format.
      
      Link: http://lkml.kernel.org/r/1480554346-29071-10-git-send-email-zohar@linux.vnet.ibm.comSigned-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Acked-by: NDmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Andreas Steffen <andreas.steffen@strongswan.org>
      Cc: Josh Sklar <sklar@linux.vnet.ibm.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Stewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d68a6fe9
  10. 20 12月, 2016 2 次提交
  11. 19 12月, 2016 4 次提交
  12. 17 12月, 2016 1 次提交
  13. 16 12月, 2016 7 次提交
  14. 15 12月, 2016 3 次提交