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
>> authentication fails? How do
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 ++---
drivers/staging/ccree/ssi_driver.h
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?
The process just r
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 called _before_ crng_init
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 support"
> > + depends on
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.
>
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 from the iSCSI mai
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 cts_cbc_encrypt()
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---
> + Enable kernel sup
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 tls_sw_context *tls_sw_ctx(
> +
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 fixed 4-byte si
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
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, o
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 insertions(+)
create mode 100644 cnn55
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 changed,
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.
In
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 a look?
https://lkml.org/
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
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 inva
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.
Th
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 ++
crypto/Kconfig| 68 +++-
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 CRYPTO_ALG
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 tru
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 superse
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 drivers/crypt
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 +--
drivers/crypto/vmx/aes_cbc.c | 7 +--
drivers/cry
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&v5.
> Hopefully he actually ge
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
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 refactor
29 matches
Mail list logo
