1. 19 9月, 2020 9 次提交
    • R
      net: rds: delete duplicated words · d936b1d5
      Randy Dunlap 提交于
      Drop repeated words in net/rds/.
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com>
      Cc: linux-rdma@vger.kernel.org
      Cc: rds-devel@oss.oracle.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d936b1d5
    • R
      net: core: delete duplicated words · 4250b75b
      Randy Dunlap 提交于
      Drop repeated words in net/core/.
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4250b75b
    • T
      tipc: add automatic rekeying for encryption key · 23700da2
      Tuong Lien 提交于
      Rekeying is required for security since a key is less secure when using
      for a long time. Also, key will be detached when its nonce value (or
      seqno ...) is exhausted. We now make the rekeying process automatic and
      configurable by user.
      
      Basically, TIPC will at a specific interval generate a new key by using
      the kernel 'Random Number Generator' cipher, then attach it as the node
      TX key and securely distribute to others in the cluster as RX keys (-
      the key exchange). The automatic key switching will then take over, and
      make the new key active shortly. Afterwards, the traffic from this node
      will be encrypted with the new session key. The same can happen in peer
      nodes but not necessarily at the same time.
      
      For simplicity, the automatically generated key will be initiated as a
      per node key. It is not too hard to also support a cluster key rekeying
      (e.g. a given node will generate a unique cluster key and update to the
      others in the cluster...), but that doesn't bring much benefit, while a
      per-node key is even more secure.
      
      We also enable user to force a rekeying or change the rekeying interval
      via netlink, the new 'set key' command option: 'TIPC_NLA_NODE_REKEYING'
      is added for these purposes as follows:
      - A value >= 1 will be set as the rekeying interval (in minutes);
      - A value of 0 will disable the rekeying;
      - A value of 'TIPC_REKEYING_NOW' (~0) will force an immediate rekeying;
      
      The default rekeying interval is (60 * 24) minutes i.e. done every day.
      There isn't any restriction for the value but user shouldn't set it too
      small or too large which results in an "ineffective" rekeying (thats ok
      for testing though).
      Acked-by: NJon Maloy <jmaloy@redhat.com>
      Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23700da2
    • T
      tipc: add automatic session key exchange · 1ef6f7c9
      Tuong Lien 提交于
      With support from the master key option in the previous commit, it
      becomes easy to make frequent updates/exchanges of session keys between
      authenticated cluster nodes.
      Basically, there are two situations where the key exchange will take in
      place:
      
      - When a new node joins the cluster (with the master key), it will need
        to get its peer's TX key, so that be able to decrypt further messages
        from that peer.
      
      - When a new session key is generated (by either user manual setting or
        later automatic rekeying feature), the key will be distributed to all
        peer nodes in the cluster.
      
      A key to be exchanged is encapsulated in the data part of a 'MSG_CRYPTO
      /KEY_DISTR_MSG' TIPC v2 message, then xmit-ed as usual and encrypted by
      using the master key before sending out. Upon receipt of the message it
      will be decrypted in the same way as regular messages, then attached as
      the sender's RX key in the receiver node.
      
      In this way, the key exchange is reliable by the link layer, as well as
      security, integrity and authenticity by the crypto layer.
      
      Also, the forward security will be easily achieved by user changing the
      master key actively but this should not be required very frequently.
      
      The key exchange feature is independent on the presence of a master key
      Note however that the master key still is needed for new nodes to be
      able to join the cluster. It is also optional, and can be turned off/on
      via the sysfs: 'net/tipc/key_exchange_enabled' [default 1: enabled].
      
      Backward compatibility is guaranteed because for nodes that do not have
      master key support, key exchange using master key ie. tx_key = 0 if any
      will be shortly discarded at the message validation step. In other
      words, the key exchange feature will be automatically disabled to those
      nodes.
      
      v2: fix the "implicit declaration of function 'tipc_crypto_key_flush'"
      error in node.c. The function only exists when built with the TIPC
      "CONFIG_TIPC_CRYPTO" option.
      
      v3: use 'info->extack' for a message emitted due to netlink operations
      instead (- David's comment).
      Reported-by: Nkernel test robot <lkp@intel.com>
      Acked-by: NJon Maloy <jmaloy@redhat.com>
      Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ef6f7c9
    • T
      tipc: introduce encryption master key · daef1ee3
      Tuong Lien 提交于
      In addition to the supported cluster & per-node encryption keys for the
      en/decryption of TIPC messages, we now introduce one option for user to
      set a cluster key as 'master key', which is simply a symmetric key like
      the former but has a longer life cycle. It has two purposes:
      
      - Authentication of new member nodes in the cluster. New nodes, having
        no knowledge of current session keys in the cluster will still be
        able to join the cluster as long as they know the master key. This is
        because all neighbor discovery (LINK_CONFIG) messages must be
        encrypted with this key.
      
      - Encryption of session encryption keys during automatic exchange and
        update of those.This is a feature we will introduce in a later commit
        in this series.
      
      We insert the new key into the currently unused slot 0 in the key array
      and start using it immediately once the user has set it.
      After joining, a node only knowing the master key should be fully
      communicable to existing nodes in the cluster, although those nodes may
      have their own session keys activated (i.e. not the master one). To
      support this, we define a 'grace period', starting from the time a node
      itself reports having no RX keys, so the existing nodes will use the
      master key for encryption instead. The grace period can be extended but
      will automatically stop after e.g. 5 seconds without a new report. This
      is also the basis for later key exchanging feature as the new node will
      be impossible to decrypt anything without the support from master key.
      
      For user to set a master key, we define a new netlink flag -
      'TIPC_NLA_NODE_KEY_MASTER', so it can be added to the current 'set key'
      netlink command to specify the setting key to be a master key.
      
      Above all, the traditional cluster/per-node key mechanism is guaranteed
      to work when user comes not to use this master key option. This is also
      compatible to legacy nodes without the feature supported.
      
      Even this master key can be updated without any interruption of cluster
      connectivity but is so is needed, this has to be coordinated and set by
      the user.
      Acked-by: NJon Maloy <jmaloy@redhat.com>
      Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      daef1ee3
    • T
      tipc: optimize key switching time and logic · f779bf79
      Tuong Lien 提交于
      We reduce the lasting time for a pending TX key to be active as well as
      for a passive RX key to be freed which generally helps speed up the key
      switching. It is not expected to be too fast but should not be too slow
      either. Also the key handling logic is simplified that a pending RX key
      will be removed automatically if it is found not working after a number
      of times; the probing for a pending TX key is now carried on a specific
      message user ('LINK_PROTOCOL' or 'LINK_CONFIG') which is more efficient
      than using a timer on broadcast messages, the timer is reserved for use
      later as needed.
      
      The kernel logs or 'pr***()' are now made as clear as possible to user.
      Some prints are added, removed or changed to the debug-level. The
      'TIPC_CRYPTO_DEBUG' definition is removed, and the 'pr_debug()' is used
      instead which will be much helpful in runtime.
      
      Besides we also optimize the code in some other places as a preparation
      for later commits.
      
      v2: silent more kernel logs, also use 'info->extack' for a message
      emitted due to netlink operations instead (- David's comments).
      Acked-by: NJon Maloy <jmaloy@redhat.com>
      Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f779bf79
    • S
      devlink: collect flash notify params into a struct · 6700acc5
      Shannon Nelson 提交于
      The dev flash status notify function parameter lists are getting
      rather long, so add a struct to be filled and passed rather than
      continuously changing the function signatures.
      Signed-off-by: NShannon Nelson <snelson@pensando.io>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6700acc5
    • S
      devlink: add timeout information to status_notify · f92970c6
      Shannon Nelson 提交于
      Add a timeout element to the DEVLINK_CMD_FLASH_UPDATE_STATUS
      netlink message for use by a userland utility to show that
      a particular firmware flash activity may take a long but
      bounded time to finish.  Also add a handy helper for drivers
      to make use of the new timeout value.
      
      UI usage hints:
       - if non-zero, add timeout display to the end of the status line
       	[component] status_msg  ( Xm Ys : Am Bs )
           using the timeout value for Am Bs and updating the Xm Ys
           every second
       - if the timeout expires while awaiting the next update,
         display something like
       	[component] status_msg  ( timeout reached : Am Bs )
       - if new status notify messages are received, remove
         the timeout and start over
      Signed-off-by: NShannon Nelson <snelson@pensando.io>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f92970c6
    • F
      net: use exponential backoff in netdev_wait_allrefs · 0e4be9e5
      Francesco Ruggeri 提交于
      The combination of aca_free_rcu, introduced in commit 2384d025
      ("net/ipv6: Add anycast addresses to a global hashtable"), and
      fib6_info_destroy_rcu, introduced in commit 9b0a8da8 ("net/ipv6:
      respect rcu grace period before freeing fib6_info"), can result in
      an extra rcu grace period being needed when deleting an interface,
      with the result that netdev_wait_allrefs ends up hitting the msleep(250),
      which is considerably longer than the required grace period.
      This can result in long delays when deleting a large number of interfaces,
      and it can be observed with this script:
      
      ns=dummy-ns
      NIFS=100
      
      ip netns add $ns
      ip netns exec $ns ip link set lo up
      ip netns exec $ns sysctl net.ipv6.conf.default.disable_ipv6=0
      ip netns exec $ns sysctl net.ipv6.conf.default.forwarding=1
      
      for ((i=0; i<$NIFS; i++))
      do
              if=eth$i
              ip netns exec $ns ip link add $if type dummy
              ip netns exec $ns ip link set $if up
              ip netns exec $ns ip -6 addr add 2021:$i::1/120 dev $if
      done
      
      for ((i=0; i<$NIFS; i++))
      do
              if=eth$i
              ip netns exec $ns ip link del $if
      done
      
      ip netns del $ns
      
      Instead of using a fixed msleep(250), this patch tries an extra
      rcu_barrier() followed by an exponential backoff.
      
      Time with this patch on a 5.4 kernel:
      
      real	0m7.704s
      user	0m0.385s
      sys	0m1.230s
      
      Time without this patch:
      
      real    0m31.522s
      user    0m0.438s
      sys     0m1.156s
      
      v2: use exponential backoff instead of trying to wake up
          netdev_wait_allrefs.
      v3: preserve reverse christmas tree ordering of local variables
      v4: try an extra rcu_barrier before the backoff, plus some
          cosmetic changes.
      Signed-off-by: NFrancesco Ruggeri <fruggeri@arista.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e4be9e5
  2. 18 9月, 2020 6 次提交
  3. 17 9月, 2020 2 次提交
  4. 16 9月, 2020 5 次提交
  5. 15 9月, 2020 18 次提交
反馈
建议
客服 返回
顶部