netdev - Re: [PATCH net-next v3 3/6] tls: implement rekey for TLS1.3

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: <ZNpC4lAmlLn-5A9h@hog>
Date: Mon, 14 Aug 2023 17:06:10 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Vadim Fedorenko <vfedorenko@...ek.ru>,
	Frantisek Krenzelok <fkrenzel@...hat.com>,
	Kuniyuki Iwashima <kuniyu@...zon.com>,
	Apoorv Kothari <apoorvko@...zon.com>,
	Boris Pismenny <borisp@...dia.com>,
	John Fastabend <john.fastabend@...il.com>,
	Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
	Gal Pressman <gal@...dia.com>,
	Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH net-next v3 3/6] tls: implement rekey for TLS1.3

2023-08-11, 18:43:47 -0700, Jakub Kicinski wrote:
> On Wed,  9 Aug 2023 14:58:52 +0200 Sabrina Dubroca wrote:
> >  			TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSRXSW);
> >  			TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSCURRRXSW);
> >  			conf = TLS_SW;
> 
> Should we add a statistic for rekeying?

Hmpf, at least I shouldn't be incrementing the existing stats on every
update, especially not TLSCURR* :/

I don't see much benefit in tracking succesful rekeys. Failed rekeys
seem more interesting to me. What would we get from counting succesful
rekeys?

> > +int tls_set_sw_offload(struct sock *sk, int tx,
> > +		       struct tls_crypto_info *new_crypto_info)
> >  {
> 
> This function is already 300 LoC and we're making longer with 
> a not-so-pretty goto skip;
> 
> Any way we can refactor it first?

I guess all the actual init (alloc software context and set it up)
could go in a separate function. I'll see if I can split a few more
things out from the end of the function without making it too messy.

> I think someone had a plan
> to at least make the per-algo stuff less verbose?

Yep, that's me. Basically, expanding the existing tls_cipher_size_desc
to completely remove the switch (crypto_info->cipher_type) (from both
setsockopt and getsockopt). I'll clean up and submit those changes,
and then rebase the next version of this series on top. Dunno why I
decided to focus on the rekey first.

-- 
Sabrina