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 11:00:42 -0700 [thread overview]
Message-ID: <20190807110042.690cf50a@cakuba.netronome.com> (raw)
In-Reply-To: <CA+FuTScYkHho4hqrGf9q6=4iao-f2P2s258rjtQTCgn+nF-CYg@mail.gmail.com>
On Wed, 7 Aug 2019 12:59:00 -0400, Willem de Bruijn wrote:
> On Wed, Aug 7, 2019 at 2:06 AM Jakub Kicinski wrote:
> > diff --git a/net/core/sock.c b/net/core/sock.c
> > index d57b0cc995a0..0f9619b0892f 100644
> > --- a/net/core/sock.c
> > +++ b/net/core/sock.c
> > @@ -1992,6 +1992,20 @@ void skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
> > }
> > EXPORT_SYMBOL(skb_set_owner_w);
> >
> > +static bool can_skb_orphan_partial(const struct sk_buff *skb)
> > +{
> > +#ifdef CONFIG_TLS_DEVICE
> > + /* Drivers depend on in-order delivery for crypto offload,
> > + * partial orphan breaks out-of-order-OK logic.
> > + */
> > + if (skb->decrypted)
> > + return false;
> > +#endif
> > + return (IS_ENABLED(CONFIG_INET) &&
> > + skb->destructor == tcp_wfree) ||
>
> Please add parentheses around IS_ENABLED(CONFIG_INET) &&
> skb->destructor == tcp_wfree
Mm.. there are parenthesis around them, maybe I'm being slow,
could you show me how?
> I was also surprised that this works when tcp_wfree is not defined if
> !CONFIG_INET. But apparently it does (at -O2?) :)
I was surprised to but in essence it should work the same as
if (IS_ENABLED(CONFIG_xyz))
call_some_xyz_code();
from compiler's perspective, and we do that a lot. Perhaps kbuild
bot will prove us wrong :)
> > @@ -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?
> > skb_entail(sk, skb);
> > copy = size_goal;
> > }
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index 6e4afc48d7bb..979520e46e33 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -1320,6 +1320,7 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,
> > buff = sk_stream_alloc_skb(sk, nsize, gfp, true);
> > if (!buff)
> > return -ENOMEM; /* We'll just try again later. */
> > + skb_copy_decrypted(buff, skb);
>
> This code has to copy timestamps, tx_flags, zerocopy state and now
> this in three locations. Eventually we'll want a single helper for all
> of them..
Ack, should I take an action on that for net-next or was it a
note-to-self? :)
next prev parent reply other threads:[~2019-08-07 18:01 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 [this message]
2019-08-07 18:46 ` Willem de Bruijn
2019-08-07 19:54 ` Willem de Bruijn
2019-08-07 22:49 ` Jakub Kicinski
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=20190807110042.690cf50a@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