This is a first baby step towards making the inside-secure crypto driver
more broadly useful. The current driver only works for Marvell Armada HW
and requires proprietary firmware, only available under NDA from Marvell,
to be installed. This patch set allows the driver to be used with other
hardwar
While being a generic EIP97/EIP197 driver, the driver was only selectable
for Marvell Armada hardware. This fix makes the driver selectable for any
Device Tree supporting kernel configuration, allowing it to be used for
other compatible hardware by just adding the correct device tree entry.
It als
Until now, the inside-secure driver required a set of firmware images to be
present in /lib/firmware/inside-secure in order to be able to function.
These firmware images were not available to the general public and diffi-
cult to obtain (only under NDA from Marvell). Also, the driver did and does
n
This patch adds support for a PCIE development board with FPGA from Xilinx,
to facilitate pre-silicon driver development by both Inside Secure and its
IP customers. Since Inside Secure neither produces nor has access to actual
silicon, this is required functionality to allow us to contribute.
Sign
On Tue, 18 Jun 2019 at 06:14, Eric Biggers wrote:
>
> On Mon, Jun 17, 2019 at 10:09:33AM +0200, Ard Biesheuvel wrote:
> > diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> > index c23019a3b264..9ea0e71f5c6a 100644
> > --- a/include/linux/tcp.h
> > +++ b/include/linux/tcp.h
> > @@ -58,12 +58
On Mon, Jun 17, 2019 at 10:18:48AM +0200, Ard Biesheuvel wrote:
> The wusb code takes a very peculiar approach at implementing CBC-MAC,
> by using plain CBC into a scratch buffer, and taking the output IV
> as the MAC.
>
> We can clean up this code substantially by switching to the cbcmac
> shash,
On Mon, Jun 17, 2019 at 10:09:33AM +0200, Ard Biesheuvel wrote:
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index c23019a3b264..9ea0e71f5c6a 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -58,12 +58,7 @@ static inline unsigned int tcp_optlen(const struct sk_buff
Hi Arnd,
On Mon, Jun 17, 2019 at 01:59:08PM +0200, Arnd Bergmann wrote:
> The same bug that gcc hit in the past is apparently now showing
> up with clang, which decides to inline __serpent_setkey_sbox:
>
> crypto/serpent_generic.c:268:5: error: stack frame size of 2112 bytes in
> function '__ser
On Mon, Jun 17, 2019 at 12:24 PM Leonard Crestez
wrote:
>
> On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> > From: Chris Spencer
> >
> > The i.MX8 is arm64, but its CAAM DMA address size is 32-bits.
>
> > +/*
> > + * On i.MX8 boards the arch is arm64 but the CAAM dma address size is
> > + * 32 bit
On Mon, Jun 17, 2019 at 12:48 PM Leonard Crestez
wrote:
>
> On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> > Simplify clock initialization code by converting it to use clk-bulk,
> > devres and soc_device_match() match table. No functional change
> > intended.
>
> Subject is misspelled.
>
Will fix.
On Mon, Jun 17, 2019 at 1:57 PM David Miller wrote:
>
> From: Eric Dumazet
> Date: Mon, 17 Jun 2019 10:00:28 -0700
>
> > All our fastopen packetdrill tests pass (after I changed all the cookie
> > values in them)
> >
> > Signed-off-by: Eric Dumazet
>
> I'm going to apply this to net-next, I wan
On 5/22/19 10:37 PM, Herbert Xu wrote:
> On Mon, May 20, 2019 at 03:49:12PM -0700, Florian Fainelli wrote:
>> On 5/10/19 10:31 AM, Florian Fainelli wrote:
>>> Hi Herbert,
>>>
>>> This patch series adds support for BCM7211 to the iproc-rng200 driver,
>>> nothing special besides matching the compatib
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector
6, cfg="random: may_sleep use_f
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/tali
Moves struct talitos_edesc into talitos.h so that it can be used
from any place in talitos.c
It will be required for next patch ("crypto: talitos - fix hash
on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
drivers/crypto/talitos.c | 30 --
dri
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
Reviewed-by: Horia Geantă
---
taken o
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[3.385197] bus: 'platform': really_probe: probing driver talitos with
device ff02.crypto
[3
All mapping iterator logic is based on the assumption that sg->offset
is always lower than PAGE_SIZE.
But there are situations where sg->offset is such that the SG item
is on the second page. In that case sg_copy_to_buffer() fails
properly copying the data into the buffer. One of the reason is
tha
From: Eric Dumazet
Date: Mon, 17 Jun 2019 10:00:28 -0700
> All our fastopen packetdrill tests pass (after I changed all the cookie
> values in them)
>
> Signed-off-by: Eric Dumazet
I'm going to apply this to net-next, I want it to sit there for a
while.
Thanks.
On Mon, Jun 17, 2019 at 7:20 PM Eric Biggers wrote:
> On Mon, Jun 17, 2019 at 03:23:02PM +0200, Arnd Bergmann wrote:
> > On arm32, we get warnings about high stack usage in some of the functions:
> >
> > @@ -1541,6 +1543,10 @@ static void generate_random_hash_testvec(struct
> > crypto_shash *tfm
On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> Simplify clock initialization code by converting it to use clk-bulk,
> devres and soc_device_match() match table. No functional change
> intended.
Subject is misspelled.
> +struct clk_bulk_caam {
> + const struct clk_bulk_data *clks;
> + int n
On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> From: Chris Spencer
>
> The i.MX8 is arm64, but its CAAM DMA address size is 32-bits.
> +/*
> + * On i.MX8 boards the arch is arm64 but the CAAM dma address size is
> + * 32 bits on 8MQ and 36 bits on 8QM and 8QXP.
> + * For 8QM and 8QXP there is a c
On Mon, Jun 17, 2019 at 11:06:21AM -0700, Nick Desaulniers wrote:
> On Mon, Jun 17, 2019 at 6:35 AM Sedat Dilek wrote:
> >
> > Hi,
> >
> > while digging through a ClangBuiltLinux issue when linking with LLD
> > linker on x86-64 I checked the settings for...
> >
> > .rodata.cst16 and .rodata.cst32
On Mon, Jun 17, 2019 at 11:06 AM Nick Desaulniers
wrote:
> In fact, looking closer at that diff, the section in question
> previously had 32b alignment. Eric, was that change intentional? It
> seems funny to have a 32b entity size but a 16b alignment.
32B & 16B
--
Thanks,
~Nick Desaulniers
On Mon, Jun 17, 2019 at 6:35 AM Sedat Dilek wrote:
>
> Hi,
>
> while digging through a ClangBuiltLinux issue when linking with LLD
> linker on x86-64 I checked the settings for...
>
> .rodata.cst16 and .rodata.cst32
>
> ...in crypto tree and fell over this change in...
>
> commit "crypto: x86/crct
On Mon, Jun 17, 2019 at 03:23:02PM +0200, Arnd Bergmann wrote:
> On arm32, we get warnings about high stack usage in some of the functions:
>
> crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function
> 'alg_test_aead' [-Werror,-Wframe-larger-than=]
> static int alg_test_aead(c
On 6/17/19 1:09 AM, Ard Biesheuvel wrote:
> Using a bare block cipher in non-crypto code is almost always a bad idea,
> not only for security reasons (and we've seen some examples of this in
> the kernel in the past), but also for performance reasons.
>
> In the TCP fastopen case, we call into
From: Chris Spencer
The i.MX8 is arm64, but its CAAM DMA address size is 32-bits.
Signed-off-by: Aymen Sghaier
Signed-off-by: Franck LENORMAND
Signed-off-by: Chris Spencer
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc:
Per feedback from NXP tech support the way to use register based
service interface on i.MX8MQ is to follow the same set of steps
outlined for the case when virtualization is enabled, regardless if it
is. Current version of SRM for i.MX8MQ speaks of DECO DID_MS and DECO
DID_LS registers, but apparen
Exactly the same code to figure out DMA mask is repeated twice in the
driver code. To avoid repetition, move that logic into a standalone
subroutine in intern.h. While at it re-shuffle the code to make it
more readable with early returns.
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory
Add clock entry needed to support i.MX8MQ.
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Aymen Sghaier
Cc: Leonard Crestez
Cc: linux-crypto@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/crypto/caam/ctrl.c
Simplify clock initialization code by converting it to use clk-bulk,
devres and soc_device_match() match table. No functional change
intended.
Signed-off-by: Andrey Smirnov
Cc: Chris Spencer
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Aymen Sghaier
Cc: Leonard Creste
Everyone:
Picking up where Chris left off (I chatted with him privately
beforehead), this series adds support for i.MX8MQ to CAAM driver. Just
like [v1], this series is i.MX8MQ only.
Feedback is welcome!
Thanks,
Andrey Smirnov
Changes since [v2]:
- Dropped "crypto: caam - do not initialise cl
From: Herbert Xu
> Sent: 17 June 2019 15:56
> On Mon, Jun 17, 2019 at 04:54:16PM +0200, Arnd Bergmann wrote:
> >
> > Just converting the three testvec_config variables is what I originally
> > had in my patch. It got some configurations below the warning level,
> > but some others still had the pro
On Mon, Jun 17, 2019 at 4:56 PM Herbert Xu wrote:
>
> On Mon, Jun 17, 2019 at 04:54:16PM +0200, Arnd Bergmann wrote:
> >
> > Just converting the three testvec_config variables is what I originally
> > had in my patch. It got some configurations below the warning level,
> > but some others still ha
On Mon, Jun 17, 2019 at 04:54:16PM +0200, Arnd Bergmann wrote:
>
> Just converting the three testvec_config variables is what I originally
> had in my patch. It got some configurations below the warning level,
> but some others still had the problem. I considered sending two
> separate patches, but
On Mon, Jun 17, 2019 at 4:24 PM Herbert Xu wrote:
>
> On Mon, Jun 17, 2019 at 04:10:44PM +0200, Arnd Bergmann wrote:
> >
> > In most cases, this ends up in favor of clang (concerning the stack
> > warning size limit) because most variables are small, but here we have
> > a large stack object (two
On Mon, Jun 17, 2019 at 04:10:44PM +0200, Arnd Bergmann wrote:
>
> In most cases, this ends up in favor of clang (concerning the stack
> warning size limit) because most variables are small, but here we have
> a large stack object (two objects for the hash fuzzing) with a large redzone.
Oh I misse
On Mon, Jun 17, 2019 at 4:04 PM Herbert Xu wrote:
>
> On Mon, Jun 17, 2019 at 03:23:02PM +0200, Arnd Bergmann wrote:
> > On arm32, we get warnings about high stack usage in some of the functions:
> >
> > crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function
> > 'alg_test_aea
On Mon, Jun 17, 2019 at 03:23:02PM +0200, Arnd Bergmann wrote:
> On arm32, we get warnings about high stack usage in some of the functions:
>
> crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function
> 'alg_test_aead' [-Werror,-Wframe-larger-than=]
> static int alg_test_aead(c
Hi,
while digging through a ClangBuiltLinux issue when linking with LLD
linker on x86-64 I checked the settings for...
.rodata.cst16 and .rodata.cst32
...in crypto tree and fell over this change in...
commit "crypto: x86/crct10dif-pcl - cleanup and optimizations":
-.section .rodata.cst16.SHUF_
After the latest addition, the stack usage of sun4i_ss_cipher_poll
grew beyond the warning limit when KASAN is enabled:
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:118:12: error: stack frame size of
1152 bytes in function 'sun4i_ss_cipher_poll' [-Werror,-Wframe-larger-than=]
static int sun4i_ss_cip
On arm32, we get warnings about high stack usage in some of the functions:
crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function
'alg_test_aead' [-Werror,-Wframe-larger-than=]
static int alg_test_aead(const struct alg_test_desc *desc, const char *driver,
^
crypto/
The same bug that gcc hit in the past is apparently now showing
up with clang, which decides to inline __serpent_setkey_sbox:
crypto/serpent_generic.c:268:5: error: stack frame size of 2112 bytes in
function '__serpent_setkey' [-Werror,-Wframe-larger-than=]
Marking it 'noinline' reduces the stac
On Wed, Jun 12, 2019 at 01:35:36PM +0200, Sascha Hauer wrote:
> On Wed, Jun 12, 2019 at 10:33:56AM +, Horia Geanta wrote:
> > On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> > > Hi Horia,
> > >
> > > On Wed, May 15, 2019 at 01:35:16PM +, Horia Geanta wrote:
> > >> For talitos, the problem is
Instead of open coding the CCM aead mode in the driver, and invoking
the AES block cipher block by block, use a ccm(aes) aead transform
which already encapsulates this functionality. This is a cleaner use
of the crypto API, and permits optimized implementations to be used,
which are typically much
A bunch of minor fixes and sanity checks
Gilad Ben-Yossef (1):
crypto: ccree: add HW engine config check
Ofir Drang (3):
crypto: ccree: Relocate driver irq registration after clk init
crypto: ccree: check that cryptocell reset completed
crypto: ccree: prevent isr handling in case driver i
From: Ofir Drang
Relocate driver interrupt registration after clk gate enabling.
Signed-off-by: Ofir Drang
---
drivers/crypto/ccree/cc_driver.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/c
From: Ofir Drang
In case of driver probe and pm resume we need to check that the cryptocell
hardware reset cycle is completed. during the reset cycle that Cryptocell
provide read only access to the APB interface which allows to verify
through the CC registers that the reset is completed. Until re
Add check to verify the stated device tree HW configuration
matches the HW.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_driver.c| 18 ++
drivers/crypto/ccree/cc_driver.h| 3 +++
drivers/crypto/ccree/cc_host_regs.h | 17 +
3 files changed,
From: Ofir Drang
ccree irq may be shared with other devices, in order to prevent ccree isr
handling while device maybe suspended we added a check to verify that the
device is not suspended.
Signed-off-by: Ofir Drang
---
drivers/crypto/ccree/cc_driver.c | 3 +++
drivers/crypto/ccree/cc_pm.c
The AIRO driver applies a ctr(aes) on a buffer of considerable size
(2400 bytes), and instead of invoking the crypto API to handle this
in its entirety, it open codes the counter manipulation and invokes
the AES block cipher directly.
Let's fix this, by switching to the sync skcipher API instead.
On Sun, 16 Jun 2019 at 21:43, Eric Biggers wrote:
>
> On Sun, Jun 16, 2019 at 09:03:58PM +0200, Ard Biesheuvel wrote:
> > >
> > > Otherwise this patch looks correct to me.
> > >
> > > The actual crypto in this driver, on the other hand, looks very outdated
> > > and
> > > broken. Apparently it's
The wusb code takes a very peculiar approach at implementing CBC-MAC,
by using plain CBC into a scratch buffer, and taking the output IV
as the MAC.
We can clean up this code substantially by switching to the cbcmac
shash, as exposed by the CCM template. To ensure that the module is
loaded on dema
Using a bare block cipher in non-crypto code is almost always a bad idea,
not only for security reasons (and we've seen some examples of this in
the kernel in the past), but also for performance reasons.
In the TCP fastopen case, we call into the bare AES block cipher one or
two times (depending o
55 matches
Mail list logo
