1. 19 4月, 2017 1 次提交
    • I
      esp4/6: Fix GSO path for non-GSO SW-crypto packets · 8f92e03e
      Ilan Tayari 提交于
      If esp*_offload module is loaded, outbound packets take the
      GSO code path, being encapsulated at layer 3, but encrypted
      in layer 2. validate_xmit_xfrm calls esp*_xmit for that.
      
      esp*_xmit was wrongfully detecting these packets as going
      through hardware crypto offload, while in fact they should
      be encrypted in software, causing plaintext leakage to
      the network, and also dropping at the receiver side.
      
      Perform the encryption in esp*_xmit, if the SA doesn't have
      a hardware offload_handle.
      
      Also, align esp6 code to esp4 logic.
      
      Fixes: fca11ebd ("esp4: Reorganize esp_output")
      Fixes: 383d0350 ("esp6: Reorganize esp_output")
      Signed-off-by: NIlan Tayari <ilant@mellanox.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      8f92e03e
  2. 14 4月, 2017 3 次提交
  3. 15 2月, 2017 1 次提交
    • S
      esp: Add a software GRO codepath · 7785bba2
      Steffen Klassert 提交于
      This patch adds GRO ifrastructure and callbacks for ESP on
      ipv4 and ipv6.
      
      In case the GRO layer detects an ESP packet, the
      esp{4,6}_gro_receive() function does a xfrm state lookup
      and calls the xfrm input layer if it finds a matching state.
      The packet will be decapsulated and reinjected it into layer 2.
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      7785bba2