On Fri, Sep 06, 2019 at 11:18:19AM +, Horia Geanta wrote:
> On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> > In order to access IP block's registers we need to enable appropriate
> > clocks first, otherwise we are risking hanging the CPU.
> >
> > The problem becomes very apparent when trying to
On Mon, Sep 09, 2019 at 05:21:55PM +1000, Herbert Xu wrote:
> On Fri, Sep 06, 2019 at 11:18:19AM +, Horia Geanta wrote:
> > On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> > > In order to access IP block's registers we need to enable appropriate
> > > clocks first, otherwise we are risking hanging
On Wed, Sep 04, 2019 at 09:36:45AM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the (AES) CBCMAC family of authentication
> algorithms: AES-CBCMAC, AES-XCBCMAC and AES-MAC
> It has been verified with a Xilinx PCIE FPGA board as well as the Marvell
> Armada A8K based Macchiatobi
On Tue, Sep 03, 2019 at 07:35:07PM -0700, Andrey Smirnov wrote:
> With IRQ requesting being managed by devres we need to make sure that
> we dispose of IRQ mapping after and not before it is free'd (otherwise
> we'll end up with a warning from the kernel). To achieve that simply
> convert IRQ mappi
On Tue, Sep 03, 2019 at 02:54:16PM +0800, zhong jiang wrote:
> PTR_ERR_OR_ZERO contains if(IS_ERR(...)) + PTR_ERR. It is better to
> use it directly. hence just replace it.
>
> Signed-off-by: zhong jiang
> ---
> arch/arm64/crypto/aes-glue.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions
On Tue, Sep 03, 2019 at 09:43:22AM -0700, Ard Biesheuvel wrote:
> This is a collection of improvements for the ARM and arm64 implementations
> of the AES based skciphers.
>
> NOTES:
> - the last two patches add XTS ciphertext stealing test vectors and should
> NOT be merged until all AES-XTS imp
On Tue, Sep 03, 2019 at 07:35:03PM -0700, Andrey Smirnov wrote:
> Everyone:
>
> This series bugfixes and small improvement I made while doing more
> testing of CAAM code:
>
> - "crypto: caam - make sure clocks are enabled first"
>
>fixes a recent regression (and, conincidentally a leak caus
On Wed, Sep 04, 2019 at 02:18:09PM +, Wei Yongjun wrote:
> When using single_open() for opening, single_release() should be
> used instead of seq_release(), otherwise there is a memory leak.
>
> Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
> Signed-off-by: Wei
On Wed, Sep 04, 2019 at 11:01:17AM +0800, zhong jiang wrote:
> Use kzfree instead of memset() + kfree().
>
> Signed-off-by: zhong jiang
> ---
> drivers/crypto/marvell/hash.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http:
On Thu, Sep 05, 2019 at 09:41:12AM -0700, Stephen Boyd wrote:
> Sebastian reports that after commit ff296293b353 ("random: Support freezable
> kthreads in add_hwgenerator_randomness()") we can call might_sleep() when the
> task state is TASK_INTERRUPTIBLE (state=1). This leads to the following
> w
On Wed, Sep 04, 2019 at 10:56:32AM -0700, Ard Biesheuvel wrote:
> The RFC4106 key derivation code instantiates an AES cipher transform
> to encrypt only a single block before it is freed again. Switch to
> the new AES library which is more suitable for such use cases.
>
> Signed-off-by: Ard Bieshe
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf
> Of Herbert Xu
> Sent: Monday, September 9, 2019 9:38 AM
> To: Pascal van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> da...@davemloft.net;
> Pascal Van Leeuwen
> Subject: Re: [PAT
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf
> Of Pascal Van Leeuwen
> Sent: Monday, September 9, 2019 12:38 PM
> To: Herbert Xu ; Pascal van Leeuwen
>
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> da...@davemloft.net
> Subject: RE: [P
On 9/9/2019 10:46 AM, Herbert Xu wrote:
> On Tue, Sep 03, 2019 at 07:35:07PM -0700, Andrey Smirnov wrote:
>> With IRQ requesting being managed by devres we need to make sure that
>> we dispose of IRQ mapping after and not before it is free'd (otherwise
>> we'll end up with a warning from the kernel
On Mon, Sep 09, 2019 at 10:50:12AM +, Pascal Van Leeuwen wrote:
>
> So my suggestion would be to supply the CRC32 patch and
> then resubmit this patchset unmodified. Would that be OK?
That's fine.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://g
On Sat, Sep 07, 2019 at 09:04:08PM +0200, Corentin Labbe wrote:
> > Also, I'm not sure what is the point of having the clocks names be
> > parameters there as well. It's constant across all the compatibles,
> > the only thing that isn't is the number of clocks and the module clock
> > rate. It's wh
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
master
head: 78a1bc18c8ea2bf8bffa007f62c1e471c543d669
commit: 649021ce0f08ac0c19535ef48821fefedfbddd7e [288/301] crypto: caam -
dispose of IRQ mapping only after IRQ is freed
config: arm64-allyesconfig (
On 9/9/2019 10:53 AM, Herbert Xu wrote:
> On Tue, Sep 03, 2019 at 07:35:03PM -0700, Andrey Smirnov wrote:
>> Everyone:
>>
>> This series bugfixes and small improvement I made while doing more
>> testing of CAAM code:
>>
>> - "crypto: caam - make sure clocks are enabled first"
>>
>>fixes a rece
This patch adds support for the CRC32 "hash" algorithm
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 1 +
drivers/crypto/inside-secure/safexcel.h | 2 +
drivers/crypto/inside-secure/safexcel_hash.c | 115 +--
3 files changed
This patchset adds support for the (AES) CBCMAC family of authentication
algorithms: AES-CBCMAC, AES-XCBCMAC and AES-MAC
It has been verified with a Xilinx PCIE FPGA board as well as the Marvell
Armada A8K based Macchiatobin development board.
Pascal van Leeuwen (3):
crypto: inside-secure - Adde
This patch adds support for the AES XCBC authentication algorithm
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 1 +
drivers/crypto/inside-secure/safexcel.h | 1 +
drivers/crypto/inside-secure/safexcel_hash.c | 136 ++-
3 fi
This patch adds support for the AES-CMAC authentication algorithm.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 1 +
drivers/crypto/inside-secure/safexcel.h | 1 +
drivers/crypto/inside-secure/safexcel_hash.c | 99
3 fil
This patch adds support for the AES-CBCMAC authentication algorithm.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 1 +
drivers/crypto/inside-secure/safexcel.h | 1 +
drivers/crypto/inside-secure/safexcel_hash.c | 235 ++-
3
Link to previous cover letter:
https://lore.kernel.org/linux-integrity/1540193596.3202.7.ca...@hansenpartnership.com/
This is marked v6 instead of v5 because I did a v5 after feedback on v4
but didn't get around to posting it and then had to rework the whole of
the kernel space handling while I w
This separates out the old tpm_buf_... handling functions from static
inlines in tpm.h and makes them their own tpm-buf.c file. This is a
precursor so we can add new functions for other TPM type handling
Signed-off-by: James Bottomley
---
v2: added this patch to separate out the API changes
v3
Most complex TPM commands require appending TPM2B buffers to the
command body. Since TPM2B types are essentially variable size arrays,
it makes it impossible to represent these complex command arguments as
structures and we simply have to build them up using append primitives
like these.
Signed-o
It's very convenient when parsing responses to have a cursor you
simply move over the response extracting the data. Add such cursor
functions for the TPM unsigned integer types.
Signed-off-by: James Bottomley
---
drivers/char/tpm/tpm-buf.c | 26 ++
drivers/char/tpm/tpm.h
On Sun, 8 Sep 2019 at 09:04, Uri Shir wrote:
>
> In XTS encryption/decryption the plaintext byte size
> can be >= AES_BLOCK_SIZE. This patch enable the AES-XTS ciphertext
> stealing implementation in ccree driver.
>
> Signed-off-by: Uri Shir
> ---
> drivers/crypto/ccree/cc_cipher.c | 16 ++--
The TPM2 session handling code needs to save and restore a single
volatile context for the elliptic curve version of the NULL seed, so
export the APIs which do this for internal use.
Signed-off-by: James Bottomley
---
drivers/char/tpm/tpm.h| 4
drivers/char/tpm/tpm2-space.c | 8
This code adds true session based HMAC authentication plus parameter
decryption and response encryption using AES.
The basic design of this code is to segregate all the nasty crypto,
hash and hmac code into tpm2-sessions.c and export a usable API.
The API first of all starts off by gaining a sess
Introducing encryption sessions changes where the return parameters
are located in the buffer because if a return session is present
they're 4 bytes beyond the header with those 4 bytes showing the
parameter length. If there is no return session, then they're in the
usual place immediately after t
We use tpm2_pcr_extend() in trusted keys to extend a PCR to prevent a
key from being re-loaded until the next reboot. To use this
functionality securely, that extend must be protected by a session
hmac.
Signed-off-by: James Bottomley
---
v3: add error handling to sessions
---
drivers/char/tpm
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf
> Of Herbert Xu
> Sent: Monday, September 9, 2019 1:35 PM
> To: Pascal Van Leeuwen
> Cc: Pascal van Leeuwen ; linux-crypto@vger.kernel.org;
> antoine.ten...@bootlin.com; da...@davemloft.net
> Subject: Re: [PATCH
If some entity is snooping the TPM bus, they can see the random
numbers we're extracting from the TPM and do prediction attacks
against their consumers. Foil this attack by using response
encryption to prevent the attacker from seeing the random sequence.
Signed-off-by: James Bottomley
---
v3:
If some entity is snooping the TPM bus, the can see the data going in
to be sealed and the data coming out as it is unsealed. Add parameter
and response encryption to these cases to ensure that no secrets are
leaked even if the bus is snooped.
As part of doing this conversion it was discovered th
This is the last component of encrypted tpm2 session handling that
allows us to verify from userspace that the key derived from the NULL
seed genuinely belongs to the TPM and has not been spoofed.
The procedure for doing this involves creating an attestation identity
key (which requires verificati
Document how the new encrypted secure interface for TPM2 works and how
security can be assured after boot by certifying the NULL seed.
Signed-off-by: James Bottomley
---
v6: replace kernel space with null seed context save
---
Documentation/security/tpm/tpm-security.rst | 204 +
This runs through a preset sequence using sessions to demonstrate that
the session handling code functions. It does both HMAC, encryption
and decryption by testing an encrypted sealing operation with
authority and proving that the same sealed data comes back again via
an HMAC and response encrypti
On Mon, Sep 9, 2019 at 3:20 PM Ard Biesheuvel wrote:
>
> On Sun, 8 Sep 2019 at 09:04, Uri Shir wrote:
> >
> > In XTS encryption/decryption the plaintext byte size
> > can be >= AES_BLOCK_SIZE. This patch enable the AES-XTS ciphertext
> > stealing implementation in ccree driver.
> >
> > Signed-off
Add Nuvoton NPCM BMC Random Number Generator(RNG) driver.
Signed-off-by: Tomer Maimon
---
drivers/char/hw_random/Kconfig| 13 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/npcm-rng.c | 203 ++
3 files changed, 217 insertions(+)
create mode
Added device tree binding documentation for Nuvoton BMC
NPCM Random Number Generator (RNG).
Signed-off-by: Tomer Maimon
---
.../bindings/rng/nuvoton,npcm-rng.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,n
This patch set adds Randon Number Generator (RNG) support
for the Nuvoton NPCM Baseboard Management Controller (BMC).
The RNG driver we use power consumption when the RNG
is not required.
The NPCM RNG driver tested on NPCM750 evaluation board.
Addressed comments from:.
- Daniel Thompson, Milt
On Mon, Sep 09, 2019 at 12:07:17PM +, Horia Geanta wrote:
>
> Why all?
> I've ack-ed only 1 and 4.
>
> Besides this, patches 11 and/or 12 break the functionality,
> i.e. driver gets stuck during crypto self-tests.
Should I back out 5-12 or everything but patch 1?
Patch 4 can't be applied wit
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to unmap memory and drop explicit de-initialization
> code.
>
> NOTE: There's no corresponding unmapping code in caam_jr_remove which
> seems like a resource leak.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc
On Mon, Sep 09, 2019 at 01:38:37PM +0200, Maxime Ripard wrote:
> On Sat, Sep 07, 2019 at 09:04:08PM +0200, Corentin Labbe wrote:
> > > Also, I'm not sure what is the point of having the clocks names be
> > > parameters there as well. It's constant across all the compatibles,
> > > the only thing th
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to unmap memory and drop corresponding iounmap() call.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-ker...@
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to remove debugfs and drop corresponding
> debugfs_remove_recursive() call.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger.kernel.or
On 9/9/2019 3:52 PM, Herbert Xu wrote:
> On Mon, Sep 09, 2019 at 12:07:17PM +, Horia Geanta wrote:
>>
>> Why all?
>> I've ack-ed only 1 and 4.
>>
>> Besides this, patches 11 and/or 12 break the functionality,
>> i.e. driver gets stuck during crypto self-tests.
>
> Should I back out 5-12 or eve
On Mon, Sep 09, 2019 at 01:26:31PM +, Horia Geanta wrote:
>
> Let's go with patches 1-4, and revert 5-12.
OK, done and pushed out.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
While storing an int in a pointer is safe the compiler is not
happy about it. So we need some extra casting in order to make
this warning free.
Fixes: 1d3f75bce123 ("crypto: caam - dispose of IRQ mapping only...")
Signed-off-by: Herbert Xu
Reviewed-by: Horia Geantă
diff --git a/drivers/crypto/
On Mon, Sep 09, 2019 at 03:19:06PM +0200, Corentin Labbe wrote:
> On Mon, Sep 09, 2019 at 01:38:37PM +0200, Maxime Ripard wrote:
> > On Sat, Sep 07, 2019 at 09:04:08PM +0200, Corentin Labbe wrote:
> > > > Also, I'm not sure what is the point of having the clocks names be
> > > > parameters there as
On Mon, 9 Sep 2019 at 13:34, Gilad Ben-Yossef wrote:
>
> On Mon, Sep 9, 2019 at 3:20 PM Ard Biesheuvel
> wrote:
> >
> > On Sun, 8 Sep 2019 at 09:04, Uri Shir wrote:
> > >
> > > In XTS encryption/decryption the plaintext byte size
> > > can be >= AES_BLOCK_SIZE. This patch enable the AES-XTS cip
On Mon, Sep 09, 2019 at 05:31:30PM +0300, Tomer Maimon wrote:
> Hi Daniel,
>
> appreciate your comments and sorry for the late reply
>
> On Thu, 29 Aug 2019 at 13:47, Daniel Thompson
> wrote:
>
> > On Wed, Aug 28, 2019 at 07:26:17PM +0300, Tomer Maimon wrote:
> > > Add Nuvoton NPCM BMC Random N
On Mon, Sep 9, 2019 at 5:38 PM Ard Biesheuvel wrote:
>
> On Mon, 9 Sep 2019 at 13:34, Gilad Ben-Yossef wrote:
> >
> > On Mon, Sep 9, 2019 at 3:20 PM Ard Biesheuvel
> > wrote:
> > >
> > > On Sun, 8 Sep 2019 at 09:04, Uri Shir wrote:
> > > >
> > > > In XTS encryption/decryption the plaintext byt
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to de-initialize the RNG and drop explicit de-initialization
> code in caam_remove().
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger
On Mon, Sep 09, 2019 at 03:38:02PM +0100, Ard Biesheuvel wrote:
>
> The blocksize is primarily used by the walking code to ensure that the
> input is a round multiple. In the XTS case, we can't blindly use the
> skcipher walk interface to go over the data anyway, since the last
> full block needs s
When algif_skcipher does a partial operation it always process data
that is a multiple of blocksize. However, for algorithms such as
CTR this is wrong because even though it can process any number of
bytes overall, the partial block must come at the very end and not
in the middle.
This is exactly
When VMAP_STACK is selected, stack cannot be DMA-mapped.
Therefore, the hash result has to be DMA-mapped in the request
context and copied into areq->result at completion.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
dif
Le 09/09/2019 à 07:29, Gustavo A. R. Silva a écrit :
Add missing break statement in order to prevent the code from falling
through to case CRYPTO_ALG_TYPE_AHASH.
Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface")
Cc: sta...@vger.kernel.org
Reported-by: kbuild test robot
59 matches
Mail list logo
