From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:33696 "EHLO
        mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1750880AbeCHWXL (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 8 Mar 2018 17:23:11 -0500
Date: Thu, 8 Mar 2018 14:22:49 -0800
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
Message-ID: <20180308222249.GA42129@davejwatson-mba>
References: <cover.1520527306.git.davejwatson@fb.com>
 <20180308165043.GA19592@davejwatson-mba>
 <510189dd-7aa3-0cc3-41a0-047e67c58e83@mellanox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <510189dd-7aa3-0cc3-41a0-047e67c58e83@mellanox.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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.