From: Dave Watson <davejwatson@fb.com>
To: Boris Pismenny <borisp@mellanox.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Tom Herbert <tom@quantonium.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
<herbert@gondor.apana.org.au>, <linux-crypto@vger.kernel.org>,
<netdev@vger.kernel.org>, <ilyal@mellanox.com>,
Atul Gupta <atul.gupta@chelsio.com>,
Vakul Garg <vakul.garg@nxp.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Steffen Klassert <steffen.klassert@secunet.com>,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH RFC 4/5] tls: RX path for ktls
Date: Thu, 8 Mar 2018 14:22:49 -0800 [thread overview]
Message-ID: <20180308222249.GA42129@davejwatson-mba> (raw)
In-Reply-To: <510189dd-7aa3-0cc3-41a0-047e67c58e83@mellanox.com>
On 03/08/18 09:48 PM, Boris Pismenny wrote:
> Hi Dave,
>
> On 03/08/18 18:50, Dave Watson wrote:
> > Add rx path for tls software implementation.
> >
> > recvmsg, splice_read, and poll implemented.
> >
> > An additional sockopt TLS_RX is added, with the same interface as
> > TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
> > together (with two different setsockopt calls with appropriate keys).
> >
> > Control messages are passed via CMSG in a similar way to transmit.
> > If no cmsg buffer is passed, then only application data records
> > will be passed to userspace, and EIO is returned for other types of
> > alerts.
> >
> > EBADMSG is passed for decryption errors, and E2BIG is passed for framing
> > errors. Both are unrecoverable.
>
> I think E2BIG is for too long argument list. EMSGSIZE might be more
> appropriate.
Sounds good.
> Also, we must check that the record is not too short (cipher specific).
> For TLS1.2 with AES-GCM the minimum length is 8 (IV) + 16 (TAG).
> The correct error for this case is EBADMSG, like a decryption failure.
>
> Also, how about bad TLS version (e.g. not TLS1.2)?
> A separate error type is required for bad version, because it triggers a
> unique alert in libraries such as OpenSSL.
> I thought of using EINVAL for bad version. What do you think?
Ah, I did not realize there was a separate alert for that, sounds good.
>
> I wonder if we should provide a more flexible method of obtaining errors for
> the future.
> Maybe use a special CMSG for errors?
> This CMSG will be triggered only after the socket enters the error state.
I'm not opposed to this in principle, but without a concrete use am
hesitant to add it. I don't know of any other error codes that could
be returned besides the ones discussed above.
> > ....
> > +
> > +int tls_sw_recvmsg(struct sock *sk,
> > + struct msghdr *msg,
> > + size_t len,
> > + int nonblock,
> > + int flags,
> > + int *addr_len)
> > +{
> > + struct tls_context *tls_ctx = tls_get_ctx(sk);
> > + struct tls_sw_context *ctx = tls_sw_ctx(tls_ctx);
> > + unsigned char control;
> > + struct strp_msg *rxm;
> > + struct sk_buff *skb;
> > + ssize_t copied = 0;
> > + bool cmsg = false;
> > + int err = 0;
> > + long timeo;
> Maybe try to read from the error queue here?
Sure.
next prev parent reply other threads:[~2018-03-08 22:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1520527306.git.davejwatson@fb.com>
2018-03-08 16:50 ` [PATCH RFC 1/5] tls: Generalize zerocopy_from_iter Dave Watson
2018-03-08 16:50 ` [PATCH RFC 2/5] tls: Move cipher info to a separate struct Dave Watson
2018-03-08 16:50 ` [PATCH RFC 3/5] tls: Pass error code explicitly to tls_err_abort Dave Watson
2018-03-08 16:50 ` [PATCH RFC 4/5] tls: RX path for ktls Dave Watson
2018-03-08 19:48 ` Boris Pismenny
2018-03-08 22:22 ` Dave Watson [this message]
2018-03-08 16:50 ` [PATCH RFC 5/5] tls: Add receive path documentation Dave Watson
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=20180308222249.GA42129@davejwatson-mba \
--to=davejwatson@fb.com \
--cc=alexei.starovoitov@gmail.com \
--cc=atul.gupta@chelsio.com \
--cc=borisp@mellanox.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--cc=herbert@gondor.apana.org.au \
--cc=ilyal@mellanox.com \
--cc=john.fastabend@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=tom@quantonium.net \
--cc=vakul.garg@nxp.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;
as well as URLs for NNTP newsgroup(s).