netdev - Re: [RFC crypto v3 0/9] Chelsio Inline TLS

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

Date:   Tue, 23 Jan 2018 13:42:00 +0530
From:   Atul Gupta <atul.gupta@...lsio.com>
To:     Sabrina Dubroca <sd@...asysnail.net>
Cc:     herbert@...dor.apana.org.au, linux-crypto@...r.kernel.org,
        ganeshgr@...lsio.com, netdev@...r.kernel.org, davem@...emloft.net,
        davejwatson@...com
Subject: Re: [RFC crypto v3 0/9] Chelsio Inline TLS



On Monday 22 January 2018 03:46 AM, Sabrina Dubroca wrote:
> 2017-12-20, 17:03:02 +0530, Atul Gupta wrote:
>> RFC series for Chelsio Inline TLS driver (chtls.ko)
>>
>> Driver use the ULP infrastructure to register chtls as Inline TLS ULP.
> I don't think drivers should be registering their own ULP. TLS
> offloading should be transparent to userspace, whatever HW ends up
> being used. If each driver implements its own ULP, the application has
> to be aware of what HW and what driver it's running on.
using different ULP is derived from 
https://patchwork.kernel.org/patch/9746381/
> I think this offload should rely on a generic infrastructure, not
> build its own private interface. Look at the current kTLS code, the
> proposal for an offload infrastructure [0] from Mellanox, and see how
> you can fit your driver into that, and extend what's missing.
>
> [0] https://patchwork.ozlabs.org/patch/849984/
The driver indeed used the proposed offload infrastructure and extended 
for Inline Rx/Tx
>
>
> [...]
>> Atul Gupta (9):
>>    chtls: structure and macro definiton
>>    cxgb4: Inline TLS FW Interface
>>    cxgb4: LLD driver changes to enable TLS
>>    chcr: Key Macro
>>    chtls: Key program
>>    chtls: CPL handler definition
>>    chtls: Inline crypto request Tx/Rx
>>    chtls: Register the ULP
>>    Makefile Kconfig
> That patchset is split so that each patch touches a separate set of
> files, and the description of the contents of each patch is very
> limited.  Can you try to group your changes by feature instead?  That
> should help you come up with descriptive commit messages as well.
Made all attempts to group the contents based on functionality, the set 
is broken into
driver registration, I/O with crypto Inline request, key handling and 
messages exchanged with
hardware.
>
> Thanks,
>