into memory alongside
the CAAM driver.
They will be used in a later commit as a source for the trusted key
seal/unseal mechanism.
Signed-off-by: Steffen Trumtrar
Signed-off-by: Ahmad Fatoum
---
To: "Horia Geantă"
To: Aymen Sghaier
To: Herbert Xu
To: "David S. Miller"
Cc:
For cases a trusted key source already sources the kernel RNG, we can
use get_random_bytes_wait to get the random data for key material.
Make the get_random callback optional to allow sources to make use of
this.
Signed-off-by: Ahmad Fatoum
---
To: James Bottomley
To: Jarkko Sakkinen
To: Mimi
generalized trusted keys to support multiple backends
and added an API to access the CAAM blob mechanism. Based on these,
provide the necessary glue to use the CAAM for trusted keys.
Signed-off-by: Ahmad Fatoum
---
To: Jonathan Corbet
To: David Howells
To: Jarkko Sakkinen
To: James Bottomley
owells
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: Steffen Trumtrar
Cc: Udit Agarwal
Cc: Jan Luebbe
Cc: David Gstir
Cc: Franck LENORMAND
Cc: Sumit Garg
Cc: linux-integr...@vger.kernel.org
Cc: keyri...@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Hello Jarkko,
On 16.03.21 20:22, Jarkko Sakkinen wrote:
> On Tue, Mar 16, 2021 at 06:01:18PM +0100, Ahmad Fatoum wrote:
>> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
>> built into many newer i.MX and QorIQ SoCs by NXP.
>>
>> The CA
Hello Richard,
On 17.03.21 00:14, Richard Weinberger wrote:
> Ahmad,
>
> On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct caam_blob_priv *blobifier;
Hello Richard,
On 17.03.21 00:10, Richard Weinberger wrote:
> On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>> This series has been tested with dmcrypt[5] on an i.MX6DL.
>
> Do have this series also in a git repo to pull from?
> I'd like to give it a test on variou
Hello Horia,
On 21.03.21 21:01, Horia Geantă wrote:
> On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
>> This patch series builds on top of Sumit's rework to have the CAAM as yet
>> another
>> trusted key backend.
>>
> Shouldn't the description under TRUS
Hello Horia,
On 21.03.21 21:48, Horia Geantă wrote:
> On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> [...]
>> +struct trusted_key_ops caam_trusted_key_ops = {
>> +.migratable = 0, /* non-migratable */
>> +.init = trusted_caam_init,
>> +.seal = trus
Hello Horia,
On 21.03.21 21:01, Horia Geantă wrote:
>> - [RFC] drivers: crypto: caam: key: Add caam_tk key type
>>Franck added[3] a new "caam_tk" key type based on Udit's work. The key
>>material stays within the kernel only, but can optionally be user-set
>>instead of coming from RNG
Hello Horia,
On 21.03.21 21:46, Horia Geantă wrote:
> On 3/16/2021 7:01 PM, Ahmad Fatoum wrote:
>> +init_job_desc(desc, 0);
>> +append_key_as_imm(desc, keymod, keymod_len, keymod_len,
>> + CLASS_2 | KEY_DEST_CLASS_REG);
>> +append_seq_
Hello Mimi,
On 23.03.21 19:07, Mimi Zohar wrote:
> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
>> On 21.03.21 21:48, Horia Geantă wrote:
>>> caam has random number generation capabilities, so it's worth using that
>>> by implementing .get_random.
&g
Hello Sumit,
On 24.03.21 11:47, Sumit Garg wrote:
> On Wed, 24 Mar 2021 at 14:56, Ahmad Fatoum wrote:
>>
>> Hello Mimi,
>>
>> On 23.03.21 19:07, Mimi Zohar wrote:
>>> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
>>>> On 21.03.21 21:48,
Hello Jarkko,
On 28.03.21 22:37, Jarkko Sakkinen wrote:
> On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote:
>> Generally speaking, I’d say trusting the CAAM RNG and trusting in it’s
>> other features are two separate things. However, reading through the CAAM
>> key blob spec I’ve got he
Hello Jarkko,
On 01.04.21 01:30, Jarkko Sakkinen wrote:
>> Option (C) sounds reasonable to me but I would rather prefer an info
>> message rather than warning as otherwise it would reflect that we are
>> enforcing kernel RNG choice for a user to trust upon.
>
> I gave some though on this.
>
> I
Hello Richard,
On 30.03.21 23:50, Richard Weinberger wrote:
> Ahmad,
>
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
>
>> TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1
>> allow_discards"
>> echo $TABLE | dmsetup create
Hello Richard,
On 31.03.21 21:36, Richard Weinberger wrote:
> James,
>
> - Ursprüngliche Mail -
>> Von: "James Bottomley"
>> Well, yes. For the TPM, there's a defined ASN.1 format for the keys:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-
Hello Richard,
On 31.03.21 20:35, Richard Weinberger wrote:
> Ahmad,
>
> On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>> +#define KEYMOD "kernel:trusted"
>
> why is the CAAM key modifier hard coded?
> I'd love to have way to pass my own modifier.
&
Hello,
On 01.04.21 12:20, Richard Weinberger wrote:
> Ahmad,
>
> - Ursprüngliche Mail -
>> Von: "Ahmad Fatoum"
>>> I'm pretty sure with minimal changes it will work with your recent approach
>>> too.
>>
>> I am using dmset
Hello Richard,
On 01.04.21 12:53, Richard Weinberger wrote:
> Ahmad,
>
> - Ursprüngliche Mail -
>> Do you mean systemd-cryptsetup? It looks to me like it's just a way to supply
>> the keyphrase. With trusted keys and a keyphrase unknown to userspace, this
>> won't work.
>
> Nah, I meant
Hello Richard,
On 01.04.21 13:05, Richard Weinberger wrote:
> Ahmad,
>
> - Ursprüngliche Mail -
>> Von: "Ahmad Fatoum"
>>> I don't want you to force to use cryptsetup.
>>
>> I'd love to use cryptsetup with LUKS and trusted keys e
Hello Richard, Sumit,
On 01.04.21 15:17, Richard Weinberger wrote:
> Sumit,
>
> - Ursprüngliche Mail -
>> Von: "Sumit Garg"
>> IIUC, this would require support for multiple trusted keys backends at
>> runtime but currently the trusted keys subsystem only supports a
>> single backend whic
Hello Kshitiz,
On 09.04.24 12:54, Kshitiz Varshney wrote:
> Hi David,
>> + b->fmt_version = DCP_BLOB_VERSION;
>> + get_random_bytes(b->nonce, AES_KEYSIZE_128);
>> + get_random_bytes(b->blob_key, AES_KEYSIZE_128);
>
> We can use HWRNG instead of using kernel RNG. Please refer
>
23 matches
Mail list logo