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
| ||
|
Date: Fri, 4 Jan 2019 10:49:55 +0000 From: Raed Salem <raeds@...lanox.com> To: Steffen Klassert <steffen.klassert@...unet.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 > -----Original Message----- > From: Steffen Klassert [mailto:steffen.klassert@...unet.com] > Sent: Friday, January 04, 2019 12:46 PM > > > -----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? Ip x s s: src 1.2.3.4 dst 1.2.3.5 proto esp spi 0x31fe38e7 reqid 838744295 mode transport replay-window 0 aead rfc4106(gcm(aes)) 0x665aaa6855d6a0bcec53686c3c1cf6e68b96d8f7 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 crypto offload parameters: dev enp4s0 dir out sel src 0.0.0.0/0 dst 0.0.0.0/0 src 1.2.3.5 dst 1.2.3.4 proto esp spi 0x1e9d4491 reqid 513623185 mode transport replay-window 0 aead rfc4106(gcm(aes)) 0xb06d1980838185be356bfe9026c9735942369047 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 crypto offload parameters: dev enp4s0 dir in sel src 0.0.0.0/0 dst 0.0.0.0/0 ip x p s: src 1.2.3.5/32 dst 1.2.3.4/32 dir in priority 0 ptype main tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 513623185 mode transport src 1.2.3.4/32 dst 1.2.3.5/32 dir out priority 0 ptype main tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 838744295 mode transport
Powered by blists - more mailing lists