From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752628AbcFVWqt (ORCPT ); Wed, 22 Jun 2016 18:46:49 -0400 Received: from mga03.intel.com ([134.134.136.65]:52356 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764AbcFVWqp (ORCPT ); Wed, 22 Jun 2016 18:46:45 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,509,1459839600"; d="scan'208";a="1007744355" Date: Wed, 22 Jun 2016 15:45:38 -0700 (PDT) From: Mat Martineau X-X-Sender: mjmartin@mjmartin-mac01.local To: Tadeusz Struk , Stephan Mueller cc: Mat Martineau , dhowells@redhat.com, herbert@gondor.apana.org.au, linux-api@vger.kernel.org, marcel@holtmann.org, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, dwmw2@infradead.org, davem@davemloft.net Subject: Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface In-Reply-To: Message-ID: References: <20160515041645.15888.94903.stgit@tstruk-mobl1> <1499283.NSekfIF0FQ@tauon.atsec.com> <3072103.TY3EQcF1Bz@tauon.atsec.com> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Stephan and Tadeusz, On Fri, 10 Jun 2016, Tadeusz Struk wrote: > On 06/09/2016 11:36 AM, Stephan Mueller wrote: >> Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau: >> >> Hi Mat, Tadeusz, >> >> Ok, after checking the code again, I think that dropping that sanity check >> should be ok given that this length is part of the akcipher API. >> >> Tadeusz, as you are currently managing that patch set, would you re-spin it >> with the following check removed? >> >> + if (usedpages < akcipher_calcsize(ctx)) { >> + err = -EMSGSIZE; >> + goto unlock; >> + } >> > > Ok, I'll update the patch. Thanks, that helps (especially with pkcs1pad). This brings me to another proposal for read buffer sizing: AF_ALG akcipher can guarantee that partial reads (where the read buffer is shorter than the output of the crypto op) will work using the same semantics as SOCK_DGRAM/SOCK_SEQPACKET. With those sockets, as much data as will fit is copied in to the read buffer and the remainder is discarded. I realize there's a performance and memory tradeoff, since the crypto algorithm needs a sufficiently large output buffer that would have to be created by AF_ALG akcipher. The user could manage that tradeoff by providing a larger buffer (typically key_size?) if it wants to avoid allocating and copying intermediate buffers inside the kernel. -- Mat Martineau Intel OTC