netdev - Re: [devel-ipsec] [PATCH ipsec-next v6] xfrm: Add Direction to the SA in or out

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: <ZhfDdak3thiwSfPk@gauss3.secunet.de>
Date: Thu, 11 Apr 2024 13:03:17 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Sabrina Dubroca <sd@...asysnail.net>
CC: Paul Wouters <paul@...ats.ca>, Antony Antony <antony@...nome.org>,
	"Nicolas Dichtel" <nicolas.dichtel@...nd.com>, Antony Antony
	<antony.antony@...unet.com>, Herbert Xu <herbert@...dor.apana.org.au>,
	<netdev@...r.kernel.org>, <devel@...ux-ipsec.org>, Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [devel-ipsec] [PATCH ipsec-next v6] xfrm: Add Direction to the
 SA in or out

On Thu, Apr 11, 2024 at 11:23:36AM +0200, Sabrina Dubroca wrote:
> 2024-04-10, 20:58:33 -0400, Paul Wouters wrote:
> > On Wed, 10 Apr 2024, Antony Antony via Devel wrote:
> > 
> > > For instance, there isn't a validation for unused XFRMA_SA_EXTRA_FLAGS in
> > > DELSA; if set, it's simply ignored. Similarly, if XFRMA_SA_DIR were set in
> > > DELSA, it would also be disregarded. Attempting to introduce validations for
> > > DELSA and other methods seems like an extensive cleanup task. Do we consider
> > > this level of validation within the scope of our current patch? It feels
> > > like we are going too far.
> > 
> > Is there a way where rate limited logging can be introduced, so that
> > userlands will clean up their use and after a few years change the API
> > to not allow setting bogus values?
> 
> Yes, this is doable. Steffen, does that seem reasonable? (for example,
> when XFRMA_REPLAY_THRESH is passed to NEWSA, or XFRMA_ALG_AEAD to
> DELSA, etc)

Yes, a cleanup would be very wellcome. But that might be a bit of
work :-)