Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

On 06/08/2017 05:09 AM, Jason A. Donenfeld wrote: > On Thu, Jun 8, 2017 at 4:43 AM, Theodore Ts'o wrote: >> What was the testing that was done for commit? It looks safe, but I'm >> unfamiliar enough with how the iSCSI authentication works that I'd >> prefer getting an ack'ed by

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

Hello, On 14/06/17 - 11:37:14, Dave Watson wrote: > Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP > sockets. Based on a similar infrastructure in tcp_cong. The idea is that any > ULP can add its own logic by changing the TCP proto_ops structure to its own > methods.

[PATCH V2] staging: ccree: - style fix, spaces and tabs

Changed code indent to be tabs across whole driver Found using checkpatch Signed-off-by: Derek Robson V1 had vague subject. --- drivers/staging/ccree/ssi_cipher.c | 45 +- drivers/staging/ccree/ssi_driver.c | 6 ++---

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On Wed, 14 Jun 2017 11:37:39 -0700 Dave Watson wrote: > --- /dev/null > +++ b/net/tls/Kconfig > @@ -0,0 +1,12 @@ > +# > +# TLS configuration > +# > +config TLS > + tristate "Transport Layer Security support" > + depends on NET > + default m > + ---help--- > +

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On 06/16/17 01:58 PM, Stephen Hemminger wrote: > On Wed, 14 Jun 2017 11:37:39 -0700 > Dave Watson wrote: > > > --- /dev/null > > +++ b/net/tls/Kconfig > > @@ -0,0 +1,12 @@ > > +# > > +# TLS configuration > > +# > > +config TLS > > + tristate "Transport Layer Security

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

On 6/16/2017 11:00 AM, Herbert Xu wrote: > On Fri, Jun 16, 2017 at 07:57:00AM +, Horia Geantă wrote: >> >> Commit 0605c41cc53ca ("crypto: cts - Convert to skcipher") appends >> CRYPTO_TFM_REQ_MAY_BACKLOG to the original crypto request flags for the >> last block - when calling

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Hi Lee, On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: > It seems like what you are doing is basically "good", i.e. if there is > not enough random data, don't use it. But what happens in that case? The > authentication fails? How does the user know to wait and try again?

Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior wrote: > I wouldn't just push the lock one up as is but move that write part to > crng_init to remain within the locked section. Like that: We can't quite do that, because invalidate_batched_entropy() needs to be

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On Wed, 14 Jun 2017 11:37:39 -0700 Dave Watson wrote: > + > +static inline struct tls_context *tls_get_ctx(const struct sock *sk) > +{ > + struct inet_connection_sock *icsk = inet_csk(sk); > + > + return icsk->icsk_ulp_data; > +} > + > +static inline struct

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote: > Hi Lee, > > On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: >> It seems like what you are doing is basically "good", i.e. if there is >> not enough random data, don't use it. But what happens in that case? The >>

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

On 6/15/2017 5:57 PM, Horia Geantă wrote: > On 6/2/2017 3:25 PM, David Gstir wrote: >> Hi! >> >> While testing fscrypt's filename encryption, I noticed that the >> implementation >> of cts(cbc(aes)) is broken when the CAAM hardware crypto driver is enabled. >> Some digging showed that the

[PATCH] crypto: vmx: remove unnecessary check

You can't reach init() if parent alg_name is invalid. Moreover, cypto_alloc_base() will return ENOENT if alg_name is NULL. Found while grasping the fallback mechanism. Signed-off-by: Tudor Ambarus --- drivers/crypto/vmx/aes.c | 7 +--

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

On Fri, Jun 16, 2017 at 07:57:00AM +, Horia Geantă wrote: > > Commit 0605c41cc53ca ("crypto: cts - Convert to skcipher") appends > CRYPTO_TFM_REQ_MAY_BACKLOG to the original crypto request flags for the > last block - when calling cts_cbc_encrypt(). > Is it really needed? Yes, because at this

[PATCH] crypto: caam: make of_device_ids const.

of_device_ids are not supposed to change at runtime. All functions working with of_device_ids provided by work with const of_device_ids. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2376 808 1283312 cf0

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On 2017-06-15 00:33:12 [+0200], Jason A. Donenfeld wrote: > There's a potential race that I fixed in my v5 of that patch set, but > Ted only took v4, and for whatever reason has been to busy to submit > the additional patch I already posted showing the diff between v4 > Hopefully he actually gets

Re: Crypto Fixes for 4.12

On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote: > As a side note, ext4 does something similar with a private > implementation, but it doesn't use something the evaluates to an > alloca. Instead it uses a fixed 4-byte size for the shash context > value in the on-stack declaration.

[PATCH v2 2/6] crypto: aes - refactor shared routines into separate core module

In preparation of further refactoring and cleanup of the AES code, move the implementations of crypto_aes_expand_key() and crypto_aes_set_key() into a separate module called aes_core, along with the Sboxes and the GF(2^8) routines that they rely on. Also, introduce crypto_aes_[en|de]crypt() based

[PATCH v2 6/6] crypto: aes - allow generic AES to be replaced by fixed time AES

On systems where a small memory footprint is important, the generic AES code with its 16 KB of lookup tables and fully unrolled encrypt and decrypt routines may be an unnecessary burden, especially given that modern SoCs often have dedicated instructions for AES. And even if they don't, a time

[PATCH v2 1/6] drivers/crypto/Kconfig: drop bogus CRYPTO_AES dependencies

In preparation of fine tuning the dependency relations between the accelerated AES drivers and the core support code, let's remove the dependency declarations that are false. None of these modules have link time dependencies on the generic AES code, nor do they declare any AES algos with

[PATCH v2 3/6] crypto: x86/aes-ni - switch to generic fallback

The time invariant AES-NI implementation is SIMD based, and so it needs a fallback in case the code is called from a context where SIMD is not allowed. On x86, this is really only when executing in the context of an interrupt taken while in kernel mode, since SIMD is allowed in all other cases.

[PATCH v2 4/6] crypto: aes - repurpose CRYPTO_AES and introduce CRYPTO_AES_GENERIC

Repurpose the Kconfig symbol CRYPTO_AES to signify that a 'select' or 'depends on' relationship on it can be satisfied by any driver that exposes a "aes" cipher. The existing generic AES code is now controlled by a new Kconfig symbol CRYPTO_AES_GENERIC, and only dependencies on CRYPTO_AES that

[PATCH v2 5/6] crypto: aes - add meaningful help text to the various AES drivers

Remove the duplicated boilerplate help text and add a bit of explanation about the nature of the various AES implementations that exist for ARM and x86. Signed-off-by: Ard Biesheuvel --- arch/arm/crypto/Kconfig | 4 +- arch/arm64/crypto/Kconfig | 7 ++

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On Fri, Jun 16, 2017 at 10:31 AM, Sebastian Andrzej Siewior wrote: > am talking about. Again: I actually figured that out myself after sending the initial email, so then I wrote a follow-up patch which I attached to this thread. You should have received it. Can you take

[PATCH v2 0/6] crypto: aes - allow generic AES to be omitted

The generic AES driver uses 16 lookup tables of 1 KB each, and has encryption and decryption routines that are fully unrolled. Given how the dependencies between this code and other drivers are declared in Kconfig files, this code is always pulled into the core kernel, even if it is usually

[PATCH 0/1] Add firmware for CNN55XX crypto driver

CNN55XX driver is accepted and needs firmware to functional. This patchset adds CNN55XX firmware v07 supports symmetric crypto operations. Srikanth Jampala (1): cavium: Add firmware for CNN55XX crypto driver. WHENCE| 9 + cnn55xx_se.fw | Bin 0 -> 27698 bytes 2 files

[PATCH 1/1] cavium: Add firmware for CNN55XX crypto driver.

This patchset adds the firmware for CNN55XX cryto driver, supports Symmetric crypto operations. The version of the firmware is v07. Signed-off-by: Srikanth Jampala --- WHENCE| 9 + cnn55xx_se.fw | Bin 0 -> 27698 bytes 2 files changed, 9

Re: [PATCH] random: silence compiler warnings and fix race

On 2017-06-15 00:45:26 [+0200], Jason A. Donenfeld wrote: > Odd versions of gcc for the sh4 architecture will actually warn about > flags being used while uninitialized, so we set them to zero. Non crazy > gccs will optimize that out again, so it doesn't make a difference. that is minor > Next,

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On 2017-06-16 14:12:42 [+0200], Jason A. Donenfeld wrote: > I actually figured that out myself after sending the initial email, so > then I wrote a follow-up patch which I attached to this thread. You > should have received it. Can you take a look? replied to the patch. Sebastian

Re: Crypto Fixes for 4.12

From: Theodore Ts'o Date: Fri, 16 Jun 2017 08:50:07 -0400 > On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote: >> As a side note, ext4 does something similar with a private >> implementation, but it doesn't use something the evaluates to an >> alloca. Instead it uses a