tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 38641b83ebc54635151810eeef00b61da3097952
commit: b460edb6230ac2877b0d176b9122736fed6f3c6e [5/15] crypto: inside-secure -
sha512 support
reproduce:
# apt-get install sparse
git
From: Fabio Estevam
i.MX51 and i.MX53 share the same sahara IP block version, so add
i.MX51 in the compatible list.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix typo in commit log "i.MX51 and i.MX53"
drivers/crypto/sahara.c | 5 -
1 file changed, 4 insertions(+), 1
From: Fabio Estevam
i.MX51 and i.MX53 share the same sahara IP block version, so add
i.MX51 in the list of supported SoCs.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix typo in commit log "i.MX51 and i.MX53"
Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt | 5 +++--
1
On 6/22/18 12:51 PM, Stephen Boyd wrote:
Perhaps it's because you implemented the 'wait' functionality in this
driver? Before the patch there wasn't any sort of wait check so we would
bail out if there wasn't any data even if the caller requested that we
wait for randomness to be available.
Quoting Timur Tabi (2018-06-22 08:41:11)
> On 6/22/18 10:38 AM, Stanimir Varbanov wrote:
> > Before entering into the read function we already hold a mutex which
> > serializes data reading so I cannot imagine how below sequence could
> > happen. Can you explain how to reproduce this race?
> >
>
From: Fabio Estevam
i.MX51 and i.MX51 share the same sahara IP block version, so add
i.MX51 in the compatible list.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/sahara.c
From: Fabio Estevam
i.MX51 and i.MX51 share the same sahara IP block version, so add
i.MX51 in the list of supported SoCs.
Signed-off-by: Fabio Estevam
---
Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
On 6/22/18 10:38 AM, Stanimir Varbanov wrote:
Before entering into the read function we already hold a mutex which
serializes data reading so I cannot imagine how below sequence could
happen. Can you explain how to reproduce this race?
1. Core 1 reads status register, shows data is available.
Hi,
On 06/21/2018 06:17 PM, Timur Tabi wrote:
> The hwrng.read callback includes a boolean parameter called 'wait'
> which indicates whether the function should block and wait for
> more data.
>
> When 'wait' is true, the driver spins on the DATA_AVAIL bit or until
> a reasonable timeout. The
On Fri, Jun 01, 2018 at 02:12:27PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The structure algs is local to the source and does not need to be in
> global scope, so make it static.
>
> Cleans up sparse warning:
> drivers/crypto/cavium/cpt/cptvf_algs.c:354:19: warning: symbol 'algs'
>
On Wed, Jun 13, 2018 at 04:29:58PM +0300, Tudor Ambarus wrote:
> Remove the limitation of single element scatterlists. ECDH with
> multi-element scatterlists is needed by TPM.
>
> Similar to 'commit 95ec01ba1ef0 ("crypto: ecdh - fix to allow multi
> segment scatterlists")'.
>
> Signed-off-by:
On Tue, May 29, 2018 at 02:13:42PM +0200, Antoine Tenart wrote:
> Hello Herbert,
>
> This series adds support for the SHA512 and SHA384 algorithms in the
> Inside Secure SafeXcel driver. Variants of those two algorithms are also
> added as well (hmac, and AEAD).
>
> Before doing so a few patches
On Wed, Jun 13, 2018 at 04:29:59PM +0300, Tudor Ambarus wrote:
> Remove it because when using a slow console, it can affect
> the speed of crypto operations.
>
> Similar to 'commit 730f23b66095 ("crypto: vmx - Remove overly
> verbose printk from AES XTS init")'.
>
> Signed-off-by: Tudor Ambarus
While commit 336073840a87 ("crypto: testmgr - Allow different compression
results")
allowed to test non-generic compression algorithms there are some corner
cases that would not be detected in test_comp().
For example if input -> compression -> decompression would all yield
the same bytes the
The test vectors were generated using the ThunderX ZIP coprocessor.
Signed-off-by: Jan Glauber
---
crypto/testmgr.c | 9 ++
crypto/testmgr.h | 77
2 files changed, 86 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index
Hi Herbert,
I've been trying to address your comment from:
https://marc.info/?l=linux-crypto-vger=152410933702305=2
with patches 1-4.
I've only found deflate and LZS to have a non-generic implementation,
but LZS does not have a generic one so for now deflate seems to be
the only algorithm that
Add missing cra_driver_name's and module aliases for deflate and lzs.
Signed-off-by: Jan Glauber
---
drivers/crypto/cavium/zip/zip_main.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/cavium/zip/zip_main.c
b/drivers/crypto/cavium/zip/zip_main.c
Make functions static where possible, found by sparse.
Signed-off-by: Jan Glauber
---
drivers/crypto/cavium/zip/zip_crypto.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/cavium/zip/zip_crypto.c
b/drivers/crypto/cavium/zip/zip_crypto.c
Rename deflate -> deflate_generic and add the default priority of 100.
Signed-off-by: Jan Glauber
---
crypto/Makefile | 2 +-
crypto/{deflate.c => deflate_generic.c} | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
rename crypto/{deflate.c => deflate_generic.c}
On 6/22/18 12:36 AM, Stephen Boyd wrote:
Quoting Timur Tabi (2018-06-21 08:17:55)
@@ -96,11 +110,39 @@ static int msm_rng_read(struct hwrng *hwrng, void *data,
size_t max, bool wait)
/* read random data from hardware */
do {
- val = readl_relaxed(rng->base +
Quoting Timur Tabi (2018-06-21 08:17:55)
> @@ -96,11 +110,39 @@ static int msm_rng_read(struct hwrng *hwrng, void *data,
> size_t max, bool wait)
>
> /* read random data from hardware */
> do {
> - val = readl_relaxed(rng->base + PRNG_STATUS);
> - if
On 21-06-18, 23:46, Timur Tabi wrote:
> On 6/21/18 11:44 PM, Vinod wrote:
> > So this make me think you should do 2 level support for ACPI, one ACPI
> > support and one V2 support where we dont touch CONFIG register. That way
> > both regions will work
>
> The ACPI system is a v2 system. If you
On 6/21/18 11:44 PM, Vinod wrote:
So this make me think you should do 2 level support for ACPI, one ACPI
support and one V2 support where we dont touch CONFIG register. That way
both regions will work
The ACPI system is a v2 system. If you want, I can just remove the read
of the CONFIG
On 21-06-18, 23:26, Timur Tabi wrote:
> On 6/21/18 11:23 PM, Vinod wrote:
> > On 21-06-18, 10:17, Timur Tabi wrote:
> > > Add support for probing on ACPI systems, with ACPI HID QCOM8160.
> > >
> > > On ACPI systems, clocks are always enabled, the PRNG should
> > > already be enabled, and the
On 6/21/18 11:24 PM, Vinod wrote:
On 21-06-18, 23:18, Timur Tabi wrote:
On 6/21/18 11:17 PM, Vinod wrote:
this should be a separate patch
What exactly should be a separate patch? This part?
- rng->hwrng.name = KBUILD_MODNAME,
- rng->hwrng.init = msm_rng_init,
-
On 6/21/18 11:23 PM, Vinod wrote:
On 21-06-18, 10:17, Timur Tabi wrote:
Add support for probing on ACPI systems, with ACPI HID QCOM8160.
On ACPI systems, clocks are always enabled, the PRNG should
already be enabled, and the register region is read-only.
The driver only verifies that the
On 21-06-18, 23:18, Timur Tabi wrote:
> On 6/21/18 11:17 PM, Vinod wrote:
> > this should be a separate patch
>
> What exactly should be a separate patch? This part?
>
> - rng->hwrng.name = KBUILD_MODNAME,
> - rng->hwrng.init = msm_rng_init,
> - rng->hwrng.cleanup = msm_rng_cleanup,
On 21-06-18, 10:17, Timur Tabi wrote:
> Add support for probing on ACPI systems, with ACPI HID QCOM8160.
>
> On ACPI systems, clocks are always enabled, the PRNG should
> already be enabled, and the register region is read-only.
> The driver only verifies that the hardware is already
> enabled
On 6/21/18 11:17 PM, Vinod wrote:
this should be a separate patch
What exactly should be a separate patch? This part?
- rng->hwrng.name = KBUILD_MODNAME,
- rng->hwrng.init = msm_rng_init,
- rng->hwrng.cleanup = msm_rng_cleanup,
- rng->hwrng.read = msm_rng_read,
+
On 21-06-18, 10:17, Timur Tabi wrote:
> The hwrng.read callback includes a boolean parameter called 'wait'
> which indicates whether the function should block and wait for
> more data.
>
> When 'wait' is true, the driver spins on the DATA_AVAIL bit or until
> a reasonable timeout. The timeout
Add support for probing on ACPI systems, with ACPI HID QCOM8160.
On ACPI systems, clocks are always enabled, the PRNG should
already be enabled, and the register region is read-only.
The driver only verifies that the hardware is already
enabled never tries to disable or configure it.
The hwrng.read callback includes a boolean parameter called 'wait'
which indicates whether the function should block and wait for
more data.
When 'wait' is true, the driver spins on the DATA_AVAIL bit or until
a reasonable timeout. The timeout can occur if there is a heavy load
on reading the
I have a business proposal in the tune of $10.2 Million USD for you to handle
with me. I have opportunity to transfer this abandon fund to your bank account
in your country which belongs to our client.
I am inviting you in this transaction where this money can be shared between us
at ratio
On 19.06.2018 00:33, Eric Biggers wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here
On 19 June 2018 at 00:33, Eric Biggers wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed
Building the kernel with CONFIG_THUMB2_KERNEL=y and
CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
arch/arm/crypto/speck-neon-core.S: Assembler messages:
arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here -- `bic
sp,#0xf'
On 18 June 2018 at 23:56, Eric Biggers wrote:
> On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote:
>> > +
>> > + // One-time XTS preparation
>> > +
>> > + /*
>> > + * Allocate stack space to store 128 bytes worth of tweaks. For
>> > + *
On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote:
> > +
> > + // One-time XTS preparation
> > +
> > + /*
> > + * Allocate stack space to store 128 bytes worth of tweaks. For
> > + * performance, this space is aligned to a 16-byte boundary so
From: Eric Biggers
Remove the original version of the VMAC template that had the nonce
hardcoded to 0 and produced a digest with the wrong endianness. I'm
unsure whether this had users or not (there are no explicit in-kernel
references to it), but given that the hardcoded nonce made it wildly
From: Eric Biggers
Hi, this series fixes various bugs in the VMAC template (crypto/vmac.c).
First, the per-request context was being stored in the transform
context, which made VMAC not thread-safe, and the kernel could be
crashed by using the same VMAC transform in multiple threads using
AF_ALG
From: Eric Biggers
The VMAC template assumes the block cipher has a 128-bit block size, but
it failed to check for that. Thus it was possible to instantiate it
using a 64-bit block size cipher, e.g. "vmac(cast5)", causing
uninitialized memory to be used.
Add the needed check when instantiating
From: Eric Biggers
Currently the VMAC template uses a "nonce" hardcoded to 0, which makes
it insecure unless a unique key is set for every message. Also, the
endianness of the final digest is wrong: the implementation uses little
endian, but the VMAC specification has it as big endian, as do
From: Eric Biggers
syzbot reported a crash in vmac_final() when multiple threads
concurrently use the same "vmac(aes)" transform through AF_ALG. The bug
is pretty fundamental: the VMAC template doesn't separate per-request
state from per-tfm (per-key) state like the other hash algorithms do,
On 17 June 2018 at 12:41, Stefan Agner wrote:
> On 17.06.2018 11:40, Ard Biesheuvel wrote:
>> On 17 June 2018 at 11:30, Ard Biesheuvel wrote:
>>> On 17 June 2018 at 00:40, Stefan Agner wrote:
Hi Eric,
On 14.02.2018 19:42, Eric Biggers wrote:
> Add an ARM NEON-accelerated
On 17.06.2018 11:40, Ard Biesheuvel wrote:
> On 17 June 2018 at 11:30, Ard Biesheuvel wrote:
>> On 17 June 2018 at 00:40, Stefan Agner wrote:
>>> Hi Eric,
>>>
>>> On 14.02.2018 19:42, Eric Biggers wrote:
Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
128-byte
On 17 June 2018 at 11:30, Ard Biesheuvel wrote:
> On 17 June 2018 at 00:40, Stefan Agner wrote:
>> Hi Eric,
>>
>> On 14.02.2018 19:42, Eric Biggers wrote:
>>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
>>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16
On 17 June 2018 at 00:40, Stefan Agner wrote:
> Hi Eric,
>
> On 14.02.2018 19:42, Eric Biggers wrote:
>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
>> Speck64. Each 128-byte chunk goes through
Hallo,
Sie haben eine wohltätige Spende in Höhe von 4.800, 000.00EUR, ich der
Amerika-Lotterie Wert $ 560 Millionen gewonnen und ich bin einen Teil davon
fünf glückliche Menschen und Altersheimen Spenden.Kontaktieren Sie mich für
diesen Gott Gelegenheit per e-Mail: jane.d...@zoho.com
Hi Eric,
On 14.02.2018 19:42, Eric Biggers wrote:
> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
> Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
> encrypted/decrypted
Hallo,
Sie haben eine wohltätige Spende in Höhe von 4.800, 000.00EUR, ich der
Amerika-Lotterie Wert $ 560 Millionen gewonnen und ich bin einen Teil davon
fünf glückliche Menschen und Altersheimen Spenden.Kontaktieren Sie mich für
diesen Gott Gelegenheit per e-Mail: jane.d...@zoho.com
On Fri, Jun 08, 2018 at 11:53:41AM +0200, Dmitry Vyukov wrote:
> keccakf() is the only function in kernel that uses __optimize() macro.
> __optimize() breaks frame pointer unwinder as optimized code uses RBP,
> and amusingly this always lead to degraded performance as gcc does not
> inline across
Jia He wrote:
> In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
> [7.019116] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:416
> [7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
> cryptomgr_test
> [7.035106] 1
On Wed, Jun 13, 2018 at 04:44:17PM +0200, Ondrej Mosnacek wrote:
> We must load the block from the temporary variable here, not directly
> from the input.
>
> Also add forgotten zeroing-out of the uninitialized part of the
> temporary block (as is done correctly in morus1280.c).
>
> Fixes:
Good Morning,
Although, I am not comfortable discussing the content of my mail on
the Internet owing to lots of unsolicited/Spam mails on the net
nowadays. However, I have made up my mind to will my late Husband's
funds to you so you can use it for charity duties and good work to
humanity. The
We must load the block from the temporary variable here, not directly
from the input.
Also add forgotten zeroing-out of the uninitialized part of the
temporary block (as is done correctly in morus1280.c).
Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations")
Reported-by:
On Wed, 2018-06-13 at 14:33 +0800, Herbert Xu wrote:
> On Fri, Jun 08, 2018 at 02:57:42PM -0700, Matthew Garrett wrote:
> > When EVM attempts to appraise a file signed with a crypto algorithm the
> > kernel doesn't have support for, it will cause the kernel to trigger a
> > module load. If the EVM
Remove the limitation of single element scatterlists. ECDH with
multi-element scatterlists is needed by TPM.
Similar to 'commit 95ec01ba1ef0 ("crypto: ecdh - fix to allow multi
segment scatterlists")'.
Signed-off-by: Tudor Ambarus
---
drivers/crypto/atmel-ecc.c | 31
Remove it because when using a slow console, it can affect
the speed of crypto operations.
Similar to 'commit 730f23b66095 ("crypto: vmx - Remove overly
verbose printk from AES XTS init")'.
Signed-off-by: Tudor Ambarus
---
drivers/crypto/atmel-ecc.c | 4
1 file changed, 4 deletions(-)
On Fri, Jun 08, 2018 at 02:57:42PM -0700, Matthew Garrett wrote:
> When EVM attempts to appraise a file signed with a crypto algorithm the
> kernel doesn't have support for, it will cause the kernel to trigger a
> module load. If the EVM policy includes appraisal of kernel modules this
> will in
On Wed, Jun 06, 2018 at 02:57:11PM -0700, Matthew Garrett wrote:
> When EVM attempts to appraise a file signed with a crypto algorithm the
> kernel doesn't have support for, it will cause the kernel to trigger a
> module load. If the EVM policy includes appraisal of kernel modules this
> will in
On Fri, Jun 8, 2018 at 2:57 PM Matthew Garrett wrote:
>
> When EVM attempts to appraise a file signed with a crypto algorithm the
> kernel doesn't have support for, it will cause the kernel to trigger a
> module load. If the EVM policy includes appraisal of kernel modules this
> will in turn call
Hi, Linus,
On 06/05/2018 04:49 PM, Linus Walleij wrote:
Instead of just providing a broad error message about the
chip being unlocked provide details on what is unlocked,
one line per thing that can be locked: data and OTP and
configuration are locked independently. Loose the
Failure to lock
Hi, Linus,
On 06/05/2018 04:49 PM, Linus Walleij wrote:
This reads out the serial number of the crypto chip and prints it,
also toss this into the entropy pool as it is device-unique data.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 56
Hi, Linus,
On 06/05/2018 04:49 PM, Linus Walleij wrote:
The config zone has 0x16 words of 4 bytes each, so provide
some basic defines so that we can address these individually.
Are you going to use all these defines? I would add just the defines
that are needed, when they are needed, but I
Hi, Linus,
On 06/05/2018 04:49 PM, Linus Walleij wrote:
Report errors once when they happen on the I2C bus so we
get good information in cases such as when the wrong I2C
address is used.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 27 +--
1 file
On 06/05/2018 04:49 PM, Linus Walleij wrote:
This is a pure I2C driver, and this device appears on the
96boards Secure96 mezzanine card, so we want to enable the
driver on other devices. Cut the Kconfig limitations to
Atmel SoC only.
Signed-off-by: Linus Walleij
Reviewed-by: Tudor Ambarus
Hi, Linus,
On 06/05/2018 04:49 PM, Linus Walleij wrote:
Instead of casting the struct for the command into (u8 *)
which is problematic in many ways, and instead of
calculating the CRC sum in a separate function, marshal,
checksum and send the command in one single function.
Instead of
On Fri, 2018-06-08 at 10:27 -0700, Dave Hansen wrote:
> On 06/08/2018 10:09 AM, Jarkko Sakkinen wrote:
> >
> > --- a/arch/x86/crypto/aesni-intel_asm.S
> > +++ b/arch/x86/crypto/aesni-intel_asm.S
> > @@ -45,6 +45,8 @@
> > #define MOVADQ movaps
> > #define MOVUDQ movups
> >
> > +#ifndef
Hi, Linus, Wolfram,
On 06/05/2018 04:49 PM, Linus Walleij wrote:
The Atmel ECC driver contains a check for the I2C bus clock
frequency, so as to check that the I2C adapter in use
satisfies the device specs.
If the device is connected to a device tree node that does not
contain a clock
SHA1 is reasonable in HMAC constructs, but it's desirable to be able to
use stronger hashes in digital signatures. Modify the EVM crypto code so
the hash type is imported from the digital signature and passed down to
the hash calculation code, and return the digest size to higher layers
for
When EVM attempts to appraise a file signed with a crypto algorithm the
kernel doesn't have support for, it will cause the kernel to trigger a
module load. If the EVM policy includes appraisal of kernel modules this
will in turn call back into EVM - since EVM is holding a lock until the
crypto
Same as V2, but rebased on next-integrity
On 8 June 2018 at 11:53, Dmitry Vyukov wrote:
> keccakf() is the only function in kernel that uses __optimize() macro.
> __optimize() breaks frame pointer unwinder as optimized code uses RBP,
> and amusingly this always lead to degraded performance as gcc does not
> inline across different
keccakf() is the only function in kernel that uses __optimize() macro.
__optimize() breaks frame pointer unwinder as optimized code uses RBP,
and amusingly this always lead to degraded performance as gcc does not
inline across different optimizations levels, so keccakf() wasn't inlined
into its
Hi Herbert
I noticed that you ever were aware of there might be uninitializaed walk.flags
issues at [1] which is commented by Eric Biggers
I wonder whether you thought there is still such issue?
I found this when I reviewed the codes. I haven't watched any exceptions/crashes
[1]
On Wed, Jun 06, 2018 at 04:58:29PM +0200, Harald Freudenberger wrote:
> Had a short glimpse to the mentioned add_hwgenerator_randomness()
> and this looks in fact like the API I am looking for :-)
> Thanks Stephan, I'll write some code and check this out.
The more convenient interface would be
SHA1 is reasonable in HMAC constructs, but it's desirable to be able to
use stronger hashes in digital signatures. Modify the EVM crypto code so
the hash type is imported from the digital signature and passed down to
the hash calculation code, and return the digest size to higher layers
for
When EVM attempts to appraise a file signed with a crypto algorithm the
kernel doesn't have support for, it will cause the kernel to trigger a
module load. If the EVM policy includes appraisal of kernel modules this
will in turn call back into EVM - since EVM is holding a lock until the
crypto
On 06.06.2018 16:26, PrasannaKumar Muralidharan wrote:
> Hi Herald,
>
> On 6 June 2018 at 18:18, Harald Freudenberger wrote:
>> Hello Theodore, hi Linux Community
>>
>> my patch for the s390 arch_get_random_seed* implementation is about to
>> be integrated with the current merge window for kernel
On 06.06.2018 15:11, Stephan Mueller wrote:
> Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger:
>
> Hi Harald,
>> I am still searching for a way to provide our good hardware entropy
>> source to the random pool in the random device driver. So I'd like to
>> have a new arch
Hi Herald,
On 6 June 2018 at 18:18, Harald Freudenberger wrote:
> Hello Theodore, hi Linux Community
>
> my patch for the s390 arch_get_random_seed* implementation is about to
> be integrated with the current merge window for kernel 4.18.
>
> So I'd like to start a discussion about a new API for
Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger:
Hi Harald,
>
> I am still searching for a way to provide our good hardware entropy
> source to the random pool in the random device driver. So I'd like to
> have a new arch interface which is called when the random pool finds
Hello Theodore, hi Linux Community
my patch for the s390 arch_get_random_seed* implementation is about to
be integrated with the current merge window for kernel 4.18.
So I'd like to start a discussion about a new API for the random.c
device driver. The current s390 hardware comes with a true
YuHao
This reads out the serial number of the crypto chip and prints it,
also toss this into the entropy pool as it is device-unique data.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 56 ++
1 file changed, 56 insertions(+)
diff --git
Rewrite the function atmel_ecc_init_read_cmd() into a more
general atmel_ecc_init_read_config_word() function to read
any word from the configuration zone, and use this
parameterized with what we want to read out.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 11 ---
1
This breaks out a lock status checker to be used with further
refactorings.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c
The config zone has 0x16 words of 4 bytes each, so provide
some basic defines so that we can address these individually.
Rename the last word to "footer", this is where we currently
look to see if the configuration is locked.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 2 +-
Instead of just providing a broad error message about the
chip being unlocked provide details on what is unlocked,
one line per thing that can be locked: data and OTP and
configuration are locked independently. Loose the
overzealous defines.
Signed-off-by: Linus Walleij
---
Instead of casting the struct for the command into (u8 *)
which is problematic in many ways, and instead of
calculating the CRC sum in a separate function, marshal,
checksum and send the command in one single function.
Instead of providing the length of the whole command
in defines, it makes more
The Atmel ECC driver contains a check for the I2C bus clock
frequency, so as to check that the I2C adapter in use
satisfies the device specs.
If the device is connected to a device tree node that does not
contain a clock frequency setting, such as an I2C mux or gate,
this blocks the probe. Make
Report errors once when they happen on the I2C bus so we
get good information in cases such as when the wrong I2C
address is used.
Signed-off-by: Linus Walleij
---
drivers/crypto/atmel-ecc.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git
This is a pure I2C driver, and this device appears on the
96boards Secure96 mezzanine card, so we want to enable the
driver on other devices. Cut the Kconfig limitations to
Atmel SoC only.
Signed-off-by: Linus Walleij
---
drivers/crypto/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git
On Sat, Jun 2, 2018 at 8:54 AM Herbert Xu wrote:
>
> On Fri, Jun 01, 2018 at 04:02:43PM -0700, Matthew Garrett wrote:
> > Trying to instantiate a non-existent crypto algorithm will cause the
> > kernel to trigger a module load. If EVM appraisal is enabled, this will
> > in turn trigger appraisal
On Fri, Jun 01, 2018 at 04:02:43PM -0700, Matthew Garrett wrote:
> Trying to instantiate a non-existent crypto algorithm will cause the
> kernel to trigger a module load. If EVM appraisal is enabled, this will
> in turn trigger appraisal of the module, which will fail because the
> crypto
SHA1 is reasonable in HMAC constructs, but it's desirable to be able to
use stronger hashes in digital signatures. Modify the EVM crypto code so
the hash type is imported from the digital signature and passed down to
the hash calculation code, and return the digest size to higher layers
for
Trying to instantiate a non-existent crypto algorithm will cause the
kernel to trigger a module load. If EVM appraisal is enabled, this will
in turn trigger appraisal of the module, which will fail because the
crypto algorithm isn't available. Add a CRYPTO_NOLOAD flag and skip
module loading if
[Resending because the email bounced back from all 3 mailing lists.
Sorry if you get this email twice]
Hi Eric et al.,
I know that this thread is already stale, and I'm sorry I couldn't join
earlier but maybe late is better than never. Allow me to first introduce
myself: my name is Tomer Ashur and
On Sat, May 26, 2018 at 12:08:57AM -0700, Eric Biggers wrote:
> Hello,
>
> The x86 asm implementations of Salsa20 have been missed so far in the
> fixes to stop abusing %ebp/%rbp in asm code to get correct stack traces.
> This has been causing the unwinder warnings reported by syzkaller to
>
On Thu, May 24, 2018 at 05:26:36PM +0530, Harsh Jain wrote:
> It includes Fixes and cleanup .
>
> Harsh Jain (3):
> crypto:chelsio:Return -ENOSPC for transient busy indication.
> crypt:chelsio:Send IV as Immediate for cipher algo
> crypto:chelsio: Remove separate buffer used for DMA map B0
601 - 700 of 29368 matches
Mail list logo
