Netdev List
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Boris Pismenny <borisp@mellanox.com>
Cc: netdev@vger.kernel.org, Ilya Lesokhin <ilyal@mellanox.com>,
	Aviad Yehezkel <aviadye@mellanox.com>,
	Dave Watson <davejwatson@fb.com>
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	[thread overview]
Message-ID: <20180906074953.GB14270@bistromath.localdomain> (raw)
In-Reply-To: <567f747b-e817-4a9b-1768-96575caea845@mellanox.com>

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 <sd@queasysnail.net>
> > ---
> >   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

  reply	other threads:[~2018-09-06 12:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 13:21 [PATCH net 0/3] tls: don't leave keys in kernel memory Sabrina Dubroca
2018-09-05 13:21 ` [PATCH net 1/3] tls: don't copy the key out of tls12_crypto_info_aes_gcm_128 Sabrina Dubroca
2018-09-05 13:21 ` [PATCH net 2/3] tls: clear key material from kernel memory when do_tls_setsockopt_conf fails Sabrina Dubroca
2018-09-05 13:53   ` Boris Pismenny
2018-09-06  7:49     ` Sabrina Dubroca [this message]
2018-09-05 13:21 ` [PATCH net 3/3] tls: zero the crypto information from tls_context before freeing Sabrina Dubroca
2018-09-05 13:48   ` Vakul Garg
2018-09-06  7:42     ` Sabrina Dubroca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180906074953.GB14270@bistromath.localdomain \
    --to=sd@queasysnail.net \
    --cc=aviadye@mellanox.com \
    --cc=borisp@mellanox.com \
    --cc=davejwatson@fb.com \
    --cc=ilyal@mellanox.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox