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]
Date:   Thu, 25 Apr 2019 12:41:12 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [bpf PATCH v2 1/3] bpf: tls, implement unhash to avoid
 transition out of ESTABLISHED

On Thu, 25 Apr 2019 12:35:58 -0700, John Fastabend wrote:
> On 4/25/19 12:32 PM, John Fastabend wrote:
> > On 4/25/19 12:29 PM, Jakub Kicinski wrote:  
> >> On Thu, 25 Apr 2019 09:03:08 -0700, John Fastabend wrote:  
> >>> +static void tls_sk_proto_unhash(struct sock *sk)
> >>> +{
> >>> +	struct tls_context *ctx = tls_get_ctx(sk);
> >>> +	void (*sk_proto_unhash)(struct sock *sk);
> >>> +	bool free_ctx;
> >>> +
> >>> +	if (!ctx)
> >>> +		return sk->sk_prot->unhash(sk);
> >>> +	sk_proto_unhash = ctx->sk_proto_unhash;
> >>> +	free_ctx = tls_sk_proto_destroy(sk, ctx, false);
> >>> +	tls_put_ctx(sk);  
> >>
> >> Oh, I think you can't put_ctx() unconditionally,
> >> when free_ctx is false, tls_device_sk_destruct() 
> >> needs it the ctx pointer.
> >>
> >> I think this explains the offload crashing.
> >>  
> > 
> > ugh yeah. So we need to _not_ free it from tls_sk_proto_destroy
> > do the put_ctx and then finally free it. Otherwise we can't
> > restore the sk_proto fields. v3 on its way. Thanks.
> >   
> 
> I'm going to throw that patch I sent earlier in this thread
> on the series as well. Its the minimal set to get things working
> again for me. Will follow up some selftests so we don't get
> here again.

SGTM, I've been racking my brain trying to come up with a good test for
the offload stuff, because it's really hard to test that without actual
HW.  I don't see any other way than adding full on per-packet crypto
logic into netdevsim or such :/  Trying to lie about having offloaded
the crypto breaks down in corner cases.

> >>> +	if (sk_proto_unhash)
> >>> +		sk_proto_unhash(sk);
> >>> +	if (free_ctx)
> >>> +		tls_ctx_free(ctx);
> >>> +}
> >>>  
> >>> -skip_tx_cleanup:
> >>> +static void tls_sk_proto_close(struct sock *sk, long timeout)
> >>> +{
> >>> +	void (*sk_proto_close)(struct sock *sk, long timeout);
> >>> +	struct tls_context *ctx = tls_get_ctx(sk);
> >>> +	bool free_ctx;
> >>> +
> >>> +	if (!ctx)
> >>> +		return sk->sk_prot->destroy(sk);
> >>> +
> >>> +	lock_sock(sk);
> >>> +	sk_proto_close = ctx->sk_proto_close;
> >>> +	free_ctx = tls_sk_proto_destroy(sk, ctx, true);
> >>> +	tls_put_ctx(sk);  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ