netdev - Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware offloading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190104104615.GI3581@gauss3.secunet.de>
Date:   Fri, 4 Jan 2019 11:46:15 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Raed Salem <raeds@...lanox.com>
CC:     Boris Pismenny <borisp@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware
 offloading

On Fri, Jan 04, 2019 at 10:43:45AM +0000, Raed Salem wrote:
> 
> 
> > -----Original Message-----
> > From: Steffen Klassert [mailto:steffen.klassert@...unet.com]
> > Sent: Friday, January 04, 2019 8:34 AM
> > To: Raed Salem <raeds@...lanox.com>
> > Cc: Boris Pismenny <borisp@...lanox.com>; Yossi Kuperman
> > <yossiku@...lanox.com>; netdev@...r.kernel.org;
> > herbert@...dor.apana.org.au; davem@...emloft.net
> > Subject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware
> > offloading
> > 
> > On Thu, Dec 27, 2018 at 01:32:14PM +0000, Raed Salem wrote:
> > > In xfrm_input() when called with IPsec hardware offload done and
> > > without GRO, encap_type == 0, we end up skipping esp_input_tail as
> > > crypto_done is set only within GRO code path, fix by move out
> > > crypto_done assignment from the GRO code path and change code
> > > accordingly
> > 
> > We currently don't support IPsec hardware offload without GRO enabled.
> > This is because the IPsec hardware offload does not decapsulate the packet.
> > So the reverse policy check is done on the outer header instead of the inner
> > header for tunnel mode. This means that the reverse policy check will fail for
> > almost all tunnel mode configurations. The packet must be decapsulated
> > before we do the policy check, and that's not the case without GRO.
> > 
> > How did you test this?
> Used the iproute to configure IPsec hardware offload in transport mode with gro off,
> Running traffic using ping

How does your SA and policy database look like?