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:   Thu, 19 Jul 2018 06:28:05 -0400
From:   Boris Pismenny <borisp@...lanox.com>
To:     Vakul Garg <vakul.garg@....com>, netdev@...r.kernel.org
Cc:     aviadye@...lanox.com, davejwatson@...com, davem@...emloft.net
Subject: Re: [net-next v3 1/5] net/tls: Do not enable zero-copy prematurely

Hi Vakul,

On 7/19/2018 7:16 AM, Vakul Garg wrote:
> Zero-copy mode was left enabled even when zerocopy_from_iter() failed.
> Set the zero-copy mode only when zerocopy_from_iter() succeeds. This
> leads to removal of argument 'zc' of function decrypt_skb_update().
> Function decrypt_skb_update() does not need to check whether
> ctx->decrypted is set since it is never called if ctx->decrypted is
> true.
> 

This patch breaks our tls_device code for the following 2 reasons:
1. We need to disable zerocopy if the device decrypted the record, 
because decrypted data has to be copied to user buffers.
2. ctx->decrypted must be checked in decrypt_skb_update, because it 
might change after calling tls_device_decrypted.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ