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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 30 Jan 2018 06:51:46 +0000
From:   Atul Gupta <atul.gupta@...lsio.com>
To:     Dave Watson <davejwatson@...com>,
        "sd@...asysnail.net" <sd@...asysnail.net>
CC:     "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "ganeshgr@...lsio.co" <ganeshgr@...lsio.co>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Boris Pismenny" <borisp@...lanox.com>,
        Ilya Lesokhin <ilyal@...lanox.com>
Subject: RE: [RFC crypto v3 8/9] chtls: Register the ULP

@Dave Watson, Did you get chance to look at my response?

What I was referring is that passing "tls" ulp type in setsockopt may be insufficient to make the decision when multi HW assist Inline TLS solution exists.
Some HW may go beyond defining sendmsg/sendpage of the prot and require additional info to setup the env? Also, we need to keep vendor specific code out of tls_main.c i.e anything other than base/sw_tx prot perhaps go to hw driver.

Sabrina echoed similar concern early last week, can we discuss or have thoughts how to address this?

Thanks
Atul

-----Original Message-----
From: Atul Gupta 
Sent: Sunday, January 28, 2018 11:26 AM
To: 'Dave Watson' <davejwatson@...com>
Cc: herbert@...dor.apana.org.au; linux-crypto@...r.kernel.org; ganeshgr@...lsio.co; netdev@...r.kernel.org; davem@...emloft.net; Boris Pismenny <borisp@...lanox.com>; Ilya Lesokhin <ilyal@...lanox.com>
Subject: RE: [RFC crypto v3 8/9] chtls: Register the ULP



-----Original Message-----
From: Dave Watson [mailto:davejwatson@...com] 
Sent: Friday, January 26, 2018 2:39 AM
To: Atul Gupta <atul.gupta@...lsio.com>
Cc: herbert@...dor.apana.org.au; linux-crypto@...r.kernel.org; ganeshgr@...lsio.co; netdev@...r.kernel.org; davem@...emloft.net; Boris Pismenny <borisp@...lanox.com>; Ilya Lesokhin <ilyal@...lanox.com>
Subject: Re: [RFC crypto v3 8/9] chtls: Register the ULP

<1513769897-26945-1-git-send-email-atul.gupta@...lsio.com>

On 12/20/17 05:08 PM, Atul Gupta wrote:
> +static void __init chtls_init_ulp_ops(void) {
> +	chtls_base_prot			= tcp_prot;
> +	chtls_base_prot.hash		= chtls_hash;
> +	chtls_base_prot.unhash		= chtls_unhash;
> +	chtls_base_prot.close		= chtls_lsk_close;
> +
> +	chtls_cpl_prot			= chtls_base_prot;
> +	chtls_init_rsk_ops(&chtls_cpl_prot, &chtls_rsk_ops,
> +			   &tcp_prot, PF_INET);
> +	chtls_cpl_prot.close		= chtls_close;
> +	chtls_cpl_prot.disconnect	= chtls_disconnect;
> +	chtls_cpl_prot.destroy		= chtls_destroy_sock;
> +	chtls_cpl_prot.shutdown		= chtls_shutdown;
> +	chtls_cpl_prot.sendmsg		= chtls_sendmsg;
> +	chtls_cpl_prot.recvmsg		= chtls_recvmsg;
> +	chtls_cpl_prot.sendpage		= chtls_sendpage;
> +	chtls_cpl_prot.setsockopt	= chtls_setsockopt;
> +	chtls_cpl_prot.getsockopt	= chtls_getsockopt;
> +}

Much of this file should go in tls_main.c, reusing as much as possible. For example it doesn't look like the get/set sockopts have changed at all for chtls.

Agree, should common code and anything other than TLS_BASE_TX/TLS_SW_TX prot should go in vendor specific file/driver. Since, prot require redefinition for hardware the code is kept in chtls_main.c

> +
> +static int __init chtls_register(void) {
> +	chtls_init_ulp_ops();
> +	register_listen_notifier(&listen_notifier);
> +	cxgb4_register_uld(CXGB4_ULD_TLS, &chtls_uld_info);
> +	tcp_register_ulp(&tcp_chtls_ulp_ops);
> +	return 0;
> +}
> +
> +static void __exit chtls_unregister(void) {
> +	unregister_listen_notifier(&listen_notifier);
> +	tcp_unregister_ulp(&tcp_chtls_ulp_ops);
> +	chtls_free_all_uld();
> +	cxgb4_unregister_uld(CXGB4_ULD_TLS);
> +}

The idea with ULP is that there is one ULP hook per protocol, not per driver.  

One thought is that apps/lib calling setsockopt pass the required ulp type [tls or chtls or xtls], this enables any HW assist to define base_prot as required and keep common code [tls_main] independent of underlying HW. 
If we are to have single TLS ULP hook [good from user point] then need a way to determine which Inline tls hw is used? System with multiple Inline TLS capable hw and differing functionality would require checks in tls_main to exercise that specific functionality/callback?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ