Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 07:23:18PM -0800, Andy Lutomirski wrote: > On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote: > > On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote: > >> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf > >>

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote: > On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote: >> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: >>

Re: [RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support

On Thu, Jan 12, 2017 at 01:59:57PM +0100, Ondrej Mosnacek wrote: > This patch implements bulk request handling in the AES-NI crypto drivers. > The major advantage of this is that with bulk requests, the kernel_fpu_* > functions (which are usually quite slow) are now called only once for the >

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote: > On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote: > > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: > >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds > >>

RE: [PATCH v8 1/1] crypto: add virtio-crypto driver

> > On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote: > > On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > > > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: > > >> Hi, > > >> > > >>> > > >>> On 12/15/2016 03:03 AM, Gonglei wrote: > > >>> [...] > > + > >

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf wrote: > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds >> wrote: >> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf

[cryptodev:master 43/44] arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `ldr tt,=crypto_ft_tab'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: 1abee99eafab67fb1c98f9ecfc43cd5735384a86 commit: 81edb42629758bacdf813dd5e4542ae26e3ad73a [43/44] crypto: arm/aes - replace scalar AES cipher config: arm-allmodconfig (attached as .config) compiler:

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 12:55 PM, Josh Poimboeuf wrote: > > - Who's going to run sparse all the time to catch unauthorized users of > __aligned__(16)? Well, considering that we apparently only have a small handful of existing users without anybody having ever run any tool

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 02:15:11PM -0600, Josh Poimboeuf wrote: > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: > > On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds > > wrote: > > > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf

Re: [cryptodev:master 43/44] arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode

Hi Arnd, On 12 January 2017 at 19:04, kbuild test robot wrote: > tree: > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > master > head: 1abee99eafab67fb1c98f9ecfc43cd5735384a86 > commit: 81edb42629758bacdf813dd5e4542ae26e3ad73a [43/44]

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote: > On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds > wrote: > > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote: > >> > >> Just to clarify, I think you're asking if, for

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds wrote: > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote: >> >> Just to clarify, I think you're asking if, for versions of gcc which >> don't support -mpreferred-stack-boundary=3, objtool

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote: > > Just to clarify, I think you're asking if, for versions of gcc which > don't support -mpreferred-stack-boundary=3, objtool can analyze all C > functions to ensure their stacks are 16-byte aligned. > > It's certainly

[cryptodev:master 43/44] arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: 1abee99eafab67fb1c98f9ecfc43cd5735384a86 commit: 81edb42629758bacdf813dd5e4542ae26e3ad73a [43/44] crypto: arm/aes - replace scalar AES cipher config: arm-multi_v7_defconfig (attached as .config)

[PATCH 0/4] n2rng: add support for m5/m7 rng register layout

Commit c1e9b3b0eea1 ("hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs") added config strings to enable the random number generator in the sparc m5 and m7 platforms. This worked fine for client LDoms, but not for the primary LDom, or running on bare metal, because the actual rng hardware layout

[PATCH 4/4] n2rng: update version info

Signed-off-by: Shannon Nelson --- drivers/char/hw_random/n2-drv.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c index f0bd5ee..31cbdbb 100644 ---

[PATCH 1/4] n2rng: limit error spewage when self-test fails

If the self-test fails, it probably won't actually suddenly start working. Currently, this causes an endless spew of error messages on the console and in the logs, so this patch adds a limiter to the test. Reported-by: Sowmini Varadhan Signed-off-by: Shannon Nelson

[PATCH 2/4] n2rng: add device data descriptions

Since we're going to need to keep track of more than just one attribute of the hardware, we'll change the use of the data field from the match struct from a single flag to a struct pointer. This patch adds the struct template and initial descriptions. Signed-off-by: Shannon Nelson

[PATCH 3/4] n2rng: support new hardware register layout

Add the new register layout constants and the requisite logic for using them. Signed-off-by: Shannon Nelson --- drivers/char/hw_random/n2-drv.c | 144 +-- drivers/char/hw_random/n2rng.h | 36 +++--- 2 files changed, 134

Re: [PATCH v1 3/8] crypto:chcr- Fix key length for RFC4106

On Thu, Jan 12, 2017 at 10:08:46PM +0530, Harsh Jain wrote: > > That case is already handled in next if condition.It will error out with > -EINVAL in next condition. > > if (keylen == AES_KEYSIZE_128) { Good point. Please split the patches according to whether they should go into 4.10/4.11 and

Re: [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11

On 12 January 2017 at 16:45, Herbert Xu wrote: > On Wed, Jan 11, 2017 at 04:41:48PM +, Ard Biesheuvel wrote: >> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD >> AES (using bit slicing). The SIMD algorithms in this series take advantage

Re: [PATCH 2/2] crypto: mediatek - fix format string for 64-bit builds

On Wed, Jan 11, 2017 at 02:55:20PM +0100, Arnd Bergmann wrote: > After I enabled COMPILE_TEST for non-ARM targets, I ran into these > warnings: > > crypto/mediatek/mtk-aes.c: In function 'mtk_aes_info_map': > crypto/mediatek/mtk-aes.c:224:28: error: format '%d' expects argument of type > 'int',

Re: [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11

On Wed, Jan 11, 2017 at 04:41:48PM +, Ard Biesheuvel wrote: > This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD > AES (using bit slicing). The SIMD algorithms in this series take advantage > of the new skcipher walksize attribute to iterate over the input in the most >

Re: [PATCH 1/2] crypto: mediatek - remove ARM dependencies

On Wed, Jan 11, 2017 at 02:50:19PM +0100, Arnd Bergmann wrote: > Building the mediatek driver on an older ARM architecture results in a > harmless warning: > > warning: (ARCH_OMAP2PLUS_TYPICAL && CRYPTO_DEV_MEDIATEK) selects NEON which > has unmet direct dependencies (VFPv3 && CPU_V7) > > We

Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests

On Tue, Jan 10, 2017 at 03:24:46PM -0800, Andy Lutomirski wrote: > There are some hashes (e.g. sha224) that have some internal trickery > to make sure that only the correct number of output bytes are > generated. If something goes wrong, they could potentially overrun > the output buffer. > >

Re: [PATCH] crypto: mediatek: don't return garbage err on successful return

On Tue, Jan 03, 2017 at 01:21:22PM +, Colin King wrote: > From: Colin Ian King > > In the case where keylen <= bs mtk_sha_setkey returns an uninitialized > return value in err. Fix this by returning 0 instead of err. > > Issue detected by static analysis with

Re: [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code

On Mon, Jan 02, 2017 at 02:06:56PM -0300, Javier Martinez Canillas wrote: > Hello, > > This small series contains a couple of cleanups that removes some driver's > code > that isn't needed due the driver being for a DT-only platform. > > The changes were suggested by Arnd Bergmann as a response

Re: [PATCH] crypto: Replaced gcc specific attributes with macros from compiler.h

On Sat, Dec 31, 2016 at 09:26:23PM +0530, gidisr...@gmail.com wrote: > From: Gideon Israel Dsouza > > Continuing from this commit: 52f5684c8e1e > ("kernel: use macros from compiler.h instead of __attribute__((...))") > > I submitted 4 total patches. They are part of task

Re: [PATCH] crypto: testmgr - use kmemdup instead of kmalloc+memcpy

On Fri, Dec 30, 2016 at 02:12:00PM -0600, Eric Biggers wrote: > From: Eric Biggers > > It's recommended to use kmemdup instead of kmalloc followed by memcpy. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH v1 3/8] crypto:chcr- Fix key length for RFC4106

On 12-01-2017 21:39, Herbert Xu wrote: > On Fri, Jan 06, 2017 at 02:01:34PM +0530, Harsh Jain wrote: >> Check keylen before copying salt to avoid wrap around of Integer. >> >> Signed-off-by: Harsh Jain >> --- >> drivers/crypto/chelsio/chcr_algo.c | 4 ++-- >> 1 file changed,

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Freitag, 13. Januar 2017, 00:06:29 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote: > > I fully agree. Therefore, I was under the impression that disregarding the > > AAD in recvmsg entirely would be most appropriate as offered with the > >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Thu, Jan 12, 2017 at 04:50:46PM +0100, Stephan Müller wrote: > > So you say that we could remove it from authenc() entirely (this is currently > the only location where such copy operation is found for the encryption > direction)? > > I would concur that the kernel does not need that.

Re: [PATCH] fix itnull.cocci warnings

On Sat, Jan 07, 2017 at 10:46:17AM +0100, Julia Lawall wrote: > The first argument to list_for_each_entry cannot be NULL. > > Generated by: scripts/coccinelle/iterators/itnull.cocci > > CC: Harsh Jain > Signed-off-by: Julia Lawall > Signed-off-by:

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 00:17:59 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote: > > Each IOCB would transpire into an independent, separate recvmsg invocation > > without an additional sendmsg/sendpage operation. Thus, in order to > >

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

On Thu, Jan 12, 2017 at 05:10:14PM +0100, Stephan Müller wrote: > > Each IOCB would transpire into an independent, separate recvmsg invocation > without an additional sendmsg/sendpage operation. Thus, in order to support > multiple IOCBs, all data the multiple recvmsg invocations will operate on

Re: [PATCH v1 0/8] crypto:chcr- Bug fixes

On Fri, Jan 06, 2017 at 02:01:31PM +0530, Harsh Jain wrote: > The patch series is based on Herbert's cryptodev-2.6 tree. > It include bug fixes. > > Atul Gupta (4): > crypto:chcr-Change flow IDs > crypto:chcr- Fix panic on dma_unmap_sg > crypto:chcr- Check device is allocated before use >

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Freitag, 13. Januar 2017, 00:07:39 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:05:03PM +0100, Stephan Müller wrote: > > Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller: > > > > Hi Herbert, > > > > > That would mean that we would only support one

Re: [PATCH v1 3/8] crypto:chcr- Fix key length for RFC4106

On Fri, Jan 06, 2017 at 02:01:34PM +0530, Harsh Jain wrote: > Check keylen before copying salt to avoid wrap around of Integer. > > Signed-off-by: Harsh Jain > --- > drivers/crypto/chelsio/chcr_algo.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote: > > I fully agree. Therefore, I was under the impression that disregarding the > AAD > in recvmsg entirely would be most appropriate as offered with the patch > "crypto: AF_ALG - disregard AAD buffer space for output". In this case

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Donnerstag, 12. Januar 2017, 16:56:04 CET schrieb Stephan Müller: Hi Herbert, > > That would mean that we would only support one IOCB. As we also need to be standards compliant, would it be appropriate to only support one IOCB? I think this is a significant difference to other AIO

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 23:53:44 CET schrieb Herbert Xu: Hi Herbert, > > > If we only want to solve that for algif_aead, wouldn't it make more sense > > if the user space caller takes care of that (such as libkcapi)? By > > tinkering with the SGLs and copying the data to the dst buffer

Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management

Am Donnerstag, 12. Januar 2017, 23:51:28 CET schrieb Herbert Xu: Hi Herbert, > On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote: > > + * The following concept of the memory management is used: > > + * > > + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL > >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 23:39:24 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 04:34:39PM +0100, Stephan Müller wrote: > > We would only be able to remove it if all AEAD implementations are > > converted. But for the conversion time, we do face that issue. > > It doesn't

Re: [PATCH] crypto: kpp - clear CRYPTO_ALG_DEAD bit in prepare_alg

On Mon, Jan 02, 2017 at 01:33:41PM +, Salvatore Benedetto wrote: > Make sure CRYPTO_ALG_DEAD is not set when preparing for > alg registration. This fixes qat-dh registration that occurs > when reloading qat_c62x module. > > Signed-off-by: Salvatore Benedetto >

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 23:27:10 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote: > > As far as I understand, we have the following AAD copy operations that we > > discuss: > > > > - algif_aead: you suggested to add the AAD copy

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote: > > As far as I understand, we have the following AAD copy operations that we > discuss: > > - algif_aead: you suggested to add the AAD copy operation here > > - AEAD implementations: over time, the AEAD implementations shall

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 22:57:28 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote: > > When addressing the issue in the algif_aead code, and expect that over > > time > > the AEAD implementations will gain the copy operation, eventually

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 11:06:50PM +0800, Herbert Xu wrote: > On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote: > > > > For the entry code, could we just replace all calls with CALL_ALIGNED? > > That might be less intrusive than trying to adjust all the pt_regs > > accesses. > > >

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote: > On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote: > > On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu > > wrote: > > > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > > >>

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote: > On Wed, Jan 11, 2017 at 11:05 PM, Herbert Xu > wrote: > > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > >> > >> I'm pretty sure we have random asm code that may not maintain a > >>

[PATCH -next] crypto: mediatek - make symbol of_crypto_id static

From: Wei Yongjun Fixes the following sparse warning: drivers/crypto/mediatek/mtk-platform.c:585:27: warning: symbol 'of_crypto_id' was not declared. Should it be static? Signed-off-by: Wei Yongjun --- drivers/crypto/mediatek/mtk-platform.c |

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 09:03:18AM -0600, Josh Poimboeuf wrote: > > For the entry code, could we just replace all calls with CALL_ALIGNED? > That might be less intrusive than trying to adjust all the pt_regs > accesses. > > Then to ensure that nobody ever uses 'call' directly: > > '#define

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote: > > When addressing the issue in the algif_aead code, and expect that over time > the AEAD implementations will gain the copy operation, eventually we will > copy > the AAD twice. Of course, this could be prevented, if the

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 08:46:01AM +0100, Ingo Molnar wrote: > > * Herbert Xu wrote: > > > On Tue, Jan 10, 2017 at 09:05:28AM -0800, Linus Torvalds wrote: > > > > > > I'm pretty sure we have random asm code that may not maintain a > > > 16-byte stack alignment when

Re: [PATCH v8 1/1] crypto: add virtio-crypto driver

On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote: > On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: > >> Hi, > >> > >>> > >>> On 12/15/2016 03:03 AM, Gonglei wrote: > >>> [...] > + > +static struct crypto_alg

Re: [PATCH v8 1/1] crypto: add virtio-crypto driver

On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: >> Hi, >> >>> >>> On 12/15/2016 03:03 AM, Gonglei wrote: >>> [...] + +static struct crypto_alg virtio_crypto_algs[] = { { + .cra_name = "cbc(aes)", + .cra_driver_name =

Re: [PATCH v4 3/3] drivers: crypto: Enable CPT options crypto for build

/Add-Support-for-Cavium-Cryptographic-Acceleration-Unit/20170112-192240 config: parisc-allyesconfig (attached as .config) compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 10:21:07PM -0800, Andy Lutomirski wrote: > On Tue, Jan 10, 2017 at 10:01 PM, Andy Lutomirski wrote: > > On Tue, Jan 10, 2017 at 8:35 PM, Herbert Xu > > wrote: > >> On Tue, Jan 10, 2017 at 08:17:17PM -0800, Linus Torvalds

[PATCH] crypto: testmgr - use calculated count for number of test vectors

When working on AES in CCM mode for ARM, my code passed the internal tcrypt test before I had even bothered to implement the AES-192 and AES-256 code paths, which is strange because the tcrypt does contain AES-192 and AES-256 test vectors for CCM. As it turned out, the define

Re: [PATCH v4 3/3] drivers: crypto: Enable CPT options crypto for build

/Add-Support-for-Cavium-Cryptographic-Acceleration-Unit/20170112-192240 coccinelle warnings: (new ones prefixed by >>) >> drivers/crypto/cavium/cpt/cptvf_reqmanager.c:312:2-8: WARNING: NULL check >> before freeing functions like kfree, debugfs_remove, >> debugfs_remove_r

[PATCH] drivers: crypto: fix ifnullfree.cocci warnings

drivers/crypto/cavium/cpt/cptvf_reqmanager.c:312:2-8: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values.

[RFC PATCH 6/6] dm-crypt: Add bulk crypto processing support

This patch converts dm-crypt to use bulk requests when invoking skcipher operations, allowing the crypto drivers to process multiple sectors at once, while reducing the overhead caused by the small sector size. The new code detects if multiple sectors from a bio are contigously stored within a

[RFC PATCH 1/6] crypto: skcipher - Add bulk request processing API

This patch adds bulk request processing to the skcipher interface. Specifically, it adds a new type of request ('skcipher_bulk_request'), which allows passing multiple independent messages to the skcipher driver. The buffers for the message data are passed via just two sg lists (one for src

[RFC PATCH 4/6] crypto: simd - Add bulk request support

This patch adds proper support for the new bulk requests to the SIMD helpers. Signed-off-by: Ondrej Mosnacek --- crypto/simd.c | 61 +++ 1 file changed, 61 insertions(+) diff --git a/crypto/simd.c b/crypto/simd.c

[RFC PATCH 3/6] crypto: cryptd - Add skcipher bulk request support

This patch adds proper support for the new bulk requests to cryptd. Signed-off-by: Ondrej Mosnacek --- crypto/cryptd.c | 111 1 file changed, 111 insertions(+) diff --git a/crypto/cryptd.c b/crypto/cryptd.c index

[RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt

Hi, the goal of this patchset is to allow those skcipher API users that need to process batches of small messages (especially dm-crypt) to do so efficiently. The first patch introduces a new request type (and corresponding encrypt/decrypt functions) to the skcipher API. The new API can be used

[RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support

This patch implements bulk request handling in the AES-NI crypto drivers. The major advantage of this is that with bulk requests, the kernel_fpu_* functions (which are usually quite slow) are now called only once for the whole request. Signed-off-by: Ondrej Mosnacek ---

[RFC PATCH 2/6] crypto: skcipher - Add bulk request support to walk

This patch tweaks skcipher_walk so it can be used with the new bulk requests. The new skipher_walk can be initialized either from a skcipher_request (in which case its behavior is equivalent to the old code) or from a skcipher_bulk_request, in which case the usage is almost identical, the most

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu: Hi Herbert, > > I think it's too much churn. Let's get the algif_aead code fixed > up first, and then pursue this later. To eliminate the extra churn of having all AEAD implementations changed to invoke copy operation, what

Re: [PATCH v4 3/3] drivers: crypto: Enable CPT options crypto for build

-Support-for-Cavium-Cryptographic-Acceleration-Unit/20170112-192240 config: blackfin-allmodconfig (attached as .config) compiler: bfin-uclinux-gcc (GCC) 6.2.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross

Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers

Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu: Hi Herbert, > On Tue, Jan 10, 2017 at 02:36:21AM +0100, Stephan Müller wrote: > > to all driver maintainers: the patches I added are compile tested, but > > I do not have the hardware to verify the code. May I ask the respective >

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Hi Stephan, Thank you for the clarification. Regards, -George On 01/12/2017 04:49 PM, Stephan Müller wrote: Am Donnerstag, 12. Januar 2017, 16:40:32 CET schrieb George Cherian: Hi George, Sure, please do not forget to invoke xts_verify_key. Should I be using xts_check_key or

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Hi Stephan, On 01/11/2017 06:09 PM, Stephan Müller wrote: Am Mittwoch, 11. Januar 2017, 16:58:17 CET schrieb George Cherian: Hi George, I will add a seperate function for xts setkey and make changes as following. ... + +struct crypto_alg algs[] = { { + .cra_flags =

Re: x86-64: Maintain 16-byte stack alignment

* Herbert Xu wrote: > > But if we can't do this with automatic verification, then I'm not sure > > I want to do it at all. The asm is already more precarious than I'd > > like, and having a code path that is misaligned is asking for obscure > > bugs down the road.

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 08:01:51AM +, Ard Biesheuvel wrote: > > [From memory] the arm64 ELF psABI mandates a 16 byte stack alignment > at function entry, and 8 byte alignment at all other times. This means > compiled code will typically preserve 16 byte alignment, and > __aligned(16) on a

Re: x86-64: Maintain 16-byte stack alignment

On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote: > > The problem is that we have nasties like TRACE_IRQS_OFF. Performance I don't understand. What's the issue with TRACE_IRQS_OFF? It should be treated as any other function call. That is, enter it with an aligned stack, and the

Re: x86-64: Maintain 16-byte stack alignment

On 12 January 2017 at 06:12, Herbert Xu wrote: > On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote: >> >> Apologies for introducing this breakage. It seemed like an obvious and >> simple cleanup, so I didn't even bother to mention it in the commit >> log,