netdev - Re: [PATCH net v2 3/3] Documentation: add TLS offload documentation

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 May 2019 11:57:35 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Boris Pismenny <borisp@...lanox.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        "alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
        "davejwatson@...com" <davejwatson@...com>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "vakul.garg@....com" <vakul.garg@....com>,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH net v2 3/3] Documentation: add TLS offload documentation

On Wed, 22 May 2019 11:25:02 +0000, Boris Pismenny wrote:
> > +Performance metrics
> > +===================
> > +
> > +TLS offload can be characterized by the following basic metrics:
> > +
> > + * max connection count
> > + * connection installation rate
> > + * connection installation latency
> > + * total cryptographic performance
> > +
> > +Note that each TCP connection requires a TLS session in both directions,
> > +the performance may be reported treating each direction separately.
> > +
> > +Max connection count
> > +--------------------
> > +
> > +The number of connections device can support can be exposed via
> > +``devlink resource`` API.  
> 
> This is future changes, let's document when we implement this.

In what sense?  The devlink resource API exists today, and doesn't
require any infrastructure changes to report TLS table occupancy.
I think it's a good idea to point driver authors at this existing
infrastructure so they don't invent their own.  Even if no driver
today implements it.

> > +Known bugs
> > +==========
> > +
> > +skb_orphan() leaks clear text
> > +-----------------------------
> > +
> > +Currently drivers depend on the :c:member:`sk` member of
> > +:c:type:`struct sk_buff <sk_buff>` to identify segments requiring
> > +encryption. Any operation which removes or does not preserve the socket
> > +association such as :c:func:`skb_orphan` or :c:func:`skb_clone`
> > +will cause the driver to miss the packets and lead to clear text leaks.
> > +
> > +Redirects leak clear text
> > +-------------------------
> > +
> > +In the RX direction, if segment has already been decrypted by the device
> > +and it gets redirected or mirrored - clear text will be transmitted out.  
> 
> Not sure if it is a bug or a feature as it needs administrator 
> intervention ;)

Right, I'm not loosing that much sleep over this one :)

> Overall, looks good to me.
> Acked-by: Boris Pismenny <borisp@...lanox.com>

Thank you!!