From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>,
davejwatson@fb.com, borisp@mellanox.com, aviadye@mellanox.com,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Eric Dumazet <edumazet@google.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
oss-drivers@netronome.com
Subject: Re: [PATCH net v2] net/tls: prevent skb_orphan() from leaking TLS plain text with offload
Date: Wed, 7 Aug 2019 15:49:59 -0700 [thread overview]
Message-ID: <20190807154959.67f30851@cakuba.netronome.com> (raw)
In-Reply-To: <CA+FuTSeR1QqAZVTLQ-mJ8iHi+h+ghbrGyT6TWATTecQSbQP6sA@mail.gmail.com>
On Wed, 7 Aug 2019 14:46:23 -0400, Willem de Bruijn wrote:
> > > > @@ -984,6 +984,9 @@ ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
> > > > if (!skb)
> > > > goto wait_for_memory;
> > > >
> > > > +#ifdef CONFIG_TLS_DEVICE
> > > > + skb->decrypted = !!(flags & MSG_SENDPAGE_DECRYPTED);
> > > > +#endif
> > >
> > > Nothing is stopping userspace from passing this new flag. In send
> > > (tcp_sendmsg_locked) it is ignored. But can it reach do_tcp_sendpages
> > > through tcp_bpf_sendmsg?
> >
> > Ah, I think you're right, thanks for checking that :( I don't entirely
> > follow how 0608c69c9a80 ("bpf: sk_msg, sock{map|hash} redirect through
> > ULP") is safe then.
> >
> > One option would be to clear the flags kernel would previously ignore
> > in tcp_bpf_sendmsg(). But I feel like we should just go back to marking
> > the socket, since we don't need the per-message flexibility of a flag.
> >
> > WDYT?
>
> I don't feel strongly either way. Passing flags from send through
> tcp_bpf_sendmsg is probably unintentional, so should probably be
> addressed anyway? Then this is a bit simpler.
FWIW I had a closer look at the tcp_bpf_sendmsg() flags, and
MSG_SENDPAGE_NOPOLICY should be okay to let though there.
That flag is only meaningful to tls in case sockmap is layered
on top of tls and we'd always set it before calling tls.
v3 coming soon..
prev parent reply other threads:[~2019-08-07 22:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 6:06 [PATCH net v2] net/tls: prevent skb_orphan() from leaking TLS plain text with offload Jakub Kicinski
2019-08-07 16:59 ` Willem de Bruijn
2019-08-07 18:00 ` Jakub Kicinski
2019-08-07 18:46 ` Willem de Bruijn
2019-08-07 19:54 ` Willem de Bruijn
2019-08-07 22:49 ` Jakub Kicinski [this message]
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=20190807154959.67f30851@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=alexei.starovoitov@gmail.com \
--cc=aviadye@mellanox.com \
--cc=borisp@mellanox.com \
--cc=daniel@iogearbox.net \
--cc=davejwatson@fb.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=willemdebruijn.kernel@gmail.com \
/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