netdev - Re: [PATCH net-next] xfrm: Call IP receive handler directly for inbound tunnel-mode packets

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] [day] [month] [year] [list]

Message-ID: <20120111044528.GA13790@gondor.apana.org.au>
Date:	Wed, 11 Jan 2012 15:45:28 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"Ward, David - 0663 - MITLL" <david.ward@...mit.edu>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] xfrm: Call IP receive handler directly for
	inbound tunnel-mode packets

On Mon, Jan 02, 2012 at 02:52:36PM -0500, Ward, David - 0663 - MITLL wrote:
>
> Sorry if I'm missing something, but how are such overruns avoided on the  
> outbound side?

We use tail calls on the output path.

> Assuming there might be a better way to make this change, are there  
> examples of existing setups that would be negatively affected? From my  
> perspective this behavior is just an unintended artifact of xfrm'ed  
> packets being placed back into netif_rx, which only occurs for inbound  
> packets, and it complicates the usage of network taps on these  
> interfaces (i.e. how do you systematically determine whether any packet  
> is post-xfrm and was already seen in an earlier form?). It seems to me  
> that network taps operate at a lower layer than xfrm, and so xfrm should  
> be invisible to the network taps. If users are, for example, capturing  
> ESP packets from a PF_PACKET socket and want to examine the decrypted  
> payload, I think the capture application should be responsible for the  
> decryption, just as it would be at higher layers with something like  
> SSL/TLS (and again for example, both protocols can be decrypted by  
> Wireshark when provided the keys).

While I sympathise with your argument, doing it nearly 10 years
after this behaviour was implemented is just too dangerous IMHO.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html