From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sabrina Dubroca Subject: Re: [PATCH net 2/3] tls: clear key material from kernel memory when do_tls_setsockopt_conf fails Date: Thu, 6 Sep 2018 09:49:53 +0200 Message-ID: <20180906074953.GB14270@bistromath.localdomain> References: <695fc3449c2ba927e97abd48b452a31ec73d6c61.1536152698.git.sd@queasysnail.net> <567f747b-e817-4a9b-1768-96575caea845@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: netdev@vger.kernel.org, Ilya Lesokhin , Aviad Yehezkel , Dave Watson To: Boris Pismenny Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:47370 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726490AbeIFMXq (ORCPT ); Thu, 6 Sep 2018 08:23:46 -0400 Content-Disposition: inline In-Reply-To: <567f747b-e817-4a9b-1768-96575caea845@mellanox.com> Sender: netdev-owner@vger.kernel.org List-ID: 2018-09-05, 16:53:54 +0300, Boris Pismenny wrote: > Hi Sabrina, > > On 9/5/2018 4:21 PM, Sabrina Dubroca wrote: > > Fixes: 3c4d7559159b ("tls: kernel TLS support") > > Signed-off-by: Sabrina Dubroca > > --- > > net/tls/tls_main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c > > index 180b6640e531..0d432d025471 100644 > > --- a/net/tls/tls_main.c > > +++ b/net/tls/tls_main.c > > @@ -499,7 +499,7 @@ static int do_tls_setsockopt_conf(struct sock *sk, char __user *optval, > > goto out; > > err_crypto_info: > > - memset(crypto_info, 0, sizeof(*crypto_info)); > > + memzero_explicit(crypto_info, sizeof(struct tls12_crypto_info_aes_gcm_128)); > > Besides the key, there are other (not secret) information in > tls12_crypto_info_aes_gcm_128. I'd prefer you do not delete it to enable > users to obtain it (using getsockopt) in case we decide to implement a > fallback to userspace in the future. Such a fallback must obtain the > kernel's iv, and record sequence number. The operation failed. There's no reason for this stale data to remain in the kernel. And you couldn't recover it with getsockopt, because you'll hit !TLS_CRYPTO_INFO_READY, since we're already resetting tls_crypto_info. Resetting tls_crypto_info on failure is necessary, otherwise your socket will be in a broken state, with TLS not setup but unable to perform a new attempt. Userspace already has all this information anyway, since it passed it to the kernel, so why would it need to recover it from the kernel? -- Sabrina