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]
Message-ID: <cf066030-2193-6b4f-05ae-afe7ead52ca7@chelsio.com>
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,
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ