On Mon, Sep 3, 2018 at 10:19 PM, Herbert Xu wrote:
> On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
>> v8 cover letter:
>>
>> I continue to hope this can land in v4.19, but I realize that's unlikely.
>> It would be nice, though, if some of the "trivial" patches could get taken
>> (e.g.
On Sat, Sep 01, 2018 at 12:17:07AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Optimize ChaCha20 NEON performance by:
>
> - Implementing the 8-bit rotations using the 'vtbl.8' instruction.
> - Streamlining the part that adds the original state and XORs the data.
> - Making some other sma
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote:
> The current arm64 CRC-T10DIF code only runs on cores that implement the
> 64x64 bit PMULL instructions that are part of the optional Crypto
> Extensions, and falls back to the highly inefficient C code otherwise.
>
> Let's provide a
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote:
> Introduce a facility that can be used to receive a notification
> callback when a new algorithm becomes available. This can be used by
> existing crypto registrations to trigger a switch from a software-only
> algorithm to a hard
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote:
> Now that the scalar fallbacks have been moved out of this driver into
> the core crc32()/crc32c() routines, we are left with a CRC32 crypto API
> driver for arm64 that is based only on 64x64 polynomial multiplication,
> which is an o
On Thu, Aug 23, 2018 at 05:48:45PM +0100, Ard Biesheuvel wrote:
> Replace the literal load of the addend vector with a sequence that
> performs each add individually. This sequence is only 2 instructions
> longer than the original, and 2% faster on Cortex-A53.
>
> This is an improvement by itself,
On Thu, Aug 23, 2018 at 03:48:51PM +0100, Ard Biesheuvel wrote:
> Speed up the GHASH algorithm based on 64-bit polynomial multiplication
> by adding support for 4-way aggregation. This improves throughput by
> ~85% on Cortex-A53, from 1.7 cycles per byte to 0.9 cycles per byte.
>
> When combined w
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
> v8 cover letter:
>
> I continue to hope this can land in v4.19, but I realize that's unlikely.
> It would be nice, though, if some of the "trivial" patches could get taken
> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repe
On Wed, Aug 22, 2018 at 10:51:44AM +0200, Ard Biesheuvel wrote:
> As it turns out, the AVX2 multibuffer SHA routines are currently
> broken [0], in a way that would have likely been noticed if this
> code were in wide use. Since the code is too complicated to be
> maintained by anyone except the or
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote:
> Currently, the CCP driver assumes that the SEV command issued to the PSP
> will always return (i.e. it will never hang). But recently, firmware bugs
> have shown that a command can hang. Since of the SEV commands are used
> in probe
On Tue, Aug 21, 2018 at 04:36:09PM +0300, Tudor Ambarus wrote:
> Adopt the SPDX license identifiers to ease license compliance
> management.
>
> Signed-off-by: Tudor Ambarus
> ---
> drivers/crypto/atmel-aes.c | 5 +
> drivers/crypto/atmel-authenc.h | 13 +
> drivers/crypto/a
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. While originally proposed for disk encryption on low-end
> devices, the
On Mon, Aug 06, 2018 at 03:43:56PM +0300, Horia Geantă wrote:
> This patch set converts caam/jr and caam/qi top level drivers
> from ablkcipher API to skcipher.
>
> First two patches remove the unused ablkcipher algorithms with
> support for IV generation.
> The following two patches deal with the
Ondrej Mosnacek wrote:
> Hi Herbert, Mikulas,
>
> I noticed the discussion about using kmalloc() inside crypto code and it
> made me wonder if the code in xts.c can actually be simplified to not
> require kmalloc() at all, while not badly affecting performace. I played
> around with it a little a
On Tue, Aug 28, 2018 at 08:43:35PM +0200, Ard Biesheuvel wrote:
> On 28 August 2018 at 19:01, Will Deacon wrote:
> > On Mon, Aug 27, 2018 at 01:02:43PM +0200, Ard Biesheuvel wrote:
> >> Add a CRC32 feature bit and wire it up to the CPU id register so we
> >> will be able to use alternatives patchi
On Mon, Aug 27, 2018 at 04:19:53PM -0700, Megha Dey wrote:
> On Mon, 2018-08-27 at 15:28 -0700, Tim Chen wrote:
> > On 08/22/2018 01:51 AM, Ard Biesheuvel wrote:
> > > As it turns out, the AVX2 multibuffer SHA routines are currently
> > > broken [0], in a way that would have likely been noticed if
On Tue, Aug 07, 2018 at 02:18:43PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> caps the skcipher request size similar to other limits and adds a sanity
> check at registration. Looking at instrumented tcrypt output, the largest
> is for lrw:
>
>
On Tue, Aug 07, 2018 at 02:18:39PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this uses
> the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
> bounds on stack usage.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafL
On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
Adding Rob Herring to the cc list.
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> i
This patch implement a generic way to get statistics about all crypto
usages.
Signed-off-by: Corentin Labbe
---
crypto/Kconfig | 11 +
crypto/Makefile | 1 +
crypto/ahash.c | 21 +-
crypto/algapi.c
This patch add a userspace tool for displaying kernel crypto API
statistics.
Signed-off-by: Corentin Labbe
---
tools/crypto/getstat.c | 294 +
1 file changed, 294 insertions(+)
create mode 100644 tools/crypto/getstat.c
diff --git a/tools/crypto/g
This patch is a try to implement a generic crypto driver statistics.
The goal is to have an "ifconfig" for crypto device.
Some driver tried to implement this via a debugfs interface.
This serie do it directly in the crypto API and give access to stats
via the crypto_user(netlink) API.
Then an use
Hi Herbert, Mikulas,
I noticed the discussion about using kmalloc() inside crypto code and it
made me wonder if the code in xts.c can actually be simplified to not
require kmalloc() at all, while not badly affecting performace. I played
around with it a little and it turns out we can drop the whol
Hi,
Some code logic I don't understand about the function pefile_digest_pe_contents
in the file crypto/asymmetric_keys/verify_pefile.c.
At the end of pefile_digest_pe_contents, please see the comment [sxw] below:
static int pefile_digest_pe_contents(const void *pebuf, unsigned int pelen,
24 matches
Mail list logo
