[PATCH v2] tpm: Move Linux RNG connection to hwrng

The tpm-rng.c approach is completely inconsistent with how the kernel handles hotplug. Instead manage a hwrng device for each TPM. This will cause the kernel to read entropy from the TPM when it is plugged in, and allow access to the TPM rng via /dev/hwrng. Signed-off-by: PrasannaKumar

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

On Thu, Oct 26, 2017 at 03:54:50PM +0200, Jarkko Sakkinen wrote: > Device number (the character device index) is not a stable identifier > for a TPM chip. That is the reason why every call site passes > TPM_ANY_NUM to tpm_chip_find_get(). > > This commit changes the API in a way that instead a

[PATCH 1/2] crypto: atmel-aes - properly set IV after {en,de}crypt

Certain cipher modes like CTS expect the IV (req->info) of ablkcipher_request (or equivalently req->iv of skcipher_request) to contain the last ciphertext block when the {en,de}crypt operation is done. Fix this issue for the Atmel AES hardware engine. The tcrypt test case for cts(cbc(aes)) is now

[PATCH 2/2] crypto: atmel-aes - Reset the controller before each use

When using the rfc4543(gcm(aes))) mode, the registers of the hardware engine are not empty after use. If the engine is not reset before its next use, the following results will be invalid. Always reset the hardware engine. Signed-off-by: Romain Izard ---

[PATCH 0/2] Fixes for the Atmel AES crypto module

After encountering an issue with cts(cbc(aes)) in the Atmel AES module, I have used tcrypt and libkcapi's test suite to validate my fix. This led me to observe some other issues. This series includes the IV issue correction for the Atmel AES crypto engine, as well as a secondary issue observed

[PATCH] crypto: ccm - preserve the IV buffer

The IV buffer used during CCM operations is used twice, during both the hashing step and the ciphering step. When using a hardware accelerator that updates the contents of the IV buffer at the end of ciphering operations, the value will be modified. In the decryption case, the subsequent setup of

Re: [PATCH v5 17/18] ima: Implement support for module-style appended signatures

On Tue, 2017-10-17 at 22:53 -0200, Thiago Jung Bauermann wrote: Below are a few additional comments. > @@ -200,18 +239,28 @@ int ima_read_xattr(struct dentry *dentry, > */ > int ima_appraise_measurement(enum ima_hooks func, >struct integrity_iint_cache *iint, > -

Re: [PATCH RESEND 4/4] dma: caam: add dma memcpy driver

On Mon, Oct 30, 2017 at 03:46:54PM +0200, Horia Geantă wrote: > @@ -600,6 +600,23 @@ config ZX_DMA > help > Support the DMA engine for ZTE ZX family platform devices. > > +config CRYPTO_DEV_FSL_CAAM_DMA File is sorted alphabetically > + tristate "CAAM DMA engine support" > +

[PATCH 2/3] staging: ccree: handle limiting of DMA masks

Properly handle limiting of DMA masks based on device and bus capabilities. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_driver.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/staging/ccree/ssi_driver.c

[PATCH 1/3] staging: ccree: copy IV to DMAable memory

We are being passed an IV buffer from unknown origin, which may be stack allocated and thus not safe for DMA. Allocate a DMA safe buffer for the IV and use that instead. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_cipher.c | 16 ++--

[PATCH 3/3] staging: ccree: remove dead code

The inflight_counter field is updated in a single location and never used. Remove it. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_cipher.c | 4 drivers/staging/ccree/ssi_driver.h | 1 - 2 files changed, 5 deletions(-) diff --git

[PATCH 0/3] staging: ccree: Fixes and cleanups

Fixes and cleanups for 4.15 Gilad Ben-Yossef (3): staging: ccree: copy IV to DMAable memory staging: ccree: handle limiting of DMA masks staging: ccree: remove dead code drivers/staging/ccree/ssi_cipher.c | 20 ++-- drivers/staging/ccree/ssi_cipher.h | 1 +

Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

On Mon, Oct 30, 2017 at 08:29:25PM -0500, Brijesh Singh wrote: > Okay, Just tried static global with CONFIG_VMAP_STACK=y and I am getting > wrong physical address with __pa. PSP command fails with error code > "INVALID_ADDRESS". The same thing works fine with kmalloc() buffer. Ah, right, module

Re: [PATCH] crypto: testmgr: don't allocate IV on stack

On Tue, Oct 31, 2017 at 09:05:57AM +, Horia Geantă wrote: > > > > The driver that is mapping the IV directly should be fixed instead. > > Only input that is given in the form of SG lists can be mapped. > > Everything else should be copied if they need to go over DMA. > > > Herbert, wouldn't

Re: [PATCH] crypto: testmgr: don't allocate IV on stack

On 10/31/2017 10:00 AM, Herbert Xu wrote: > On Tue, Oct 31, 2017 at 07:56:26AM +, Gilad Ben-Yossef wrote: >> The IV was allocated on the stack in testmgr skcipher tests. >> Since HW based tfm providers need to DMA the IV to the HW, >> this leads to problems and is detected by the DMA-API debug

Re: [PATCH] crypto: testmgr: don't allocate IV on stack

On Tue, Oct 31, 2017 at 9:59 AM, Herbert Xu wrote: > On Tue, Oct 31, 2017 at 07:56:26AM +, Gilad Ben-Yossef wrote: >> The IV was allocated on the stack in testmgr skcipher tests. >> Since HW based tfm providers need to DMA the IV to the HW, >> this leads to

Re: [PATCH] crypto: testmgr: don't allocate IV on stack

On Tue, Oct 31, 2017 at 07:56:26AM +, Gilad Ben-Yossef wrote: > The IV was allocated on the stack in testmgr skcipher tests. > Since HW based tfm providers need to DMA the IV to the HW, > this leads to problems and is detected by the DMA-API debug > code. > > Fix it by allocating the IV using

[PATCH] crypto: testmgr: don't allocate IV on stack

The IV was allocated on the stack in testmgr skcipher tests. Since HW based tfm providers need to DMA the IV to the HW, this leads to problems and is detected by the DMA-API debug code. Fix it by allocating the IV using kmalloc instead. Signed-off-by: Gilad Ben-Yossef ---