On Fri, May 17, 2024 at 09:31:15PM -0700, Eric Biggers wrote:
>
> This is "normal" behavior when the crypto API instantiates a template:
>
> 1. drbg.c asks for "hmac(sha512)"
>
> 2. The crypto API looks for a direct implementation of "hmac(sha512)".
>This includes requesting a mod
On Sat May 18, 2024 at 7:31 AM EEST, Eric Biggers wrote:
> This is "normal" behavior when the crypto API instantiates a template:
>
> 1. drbg.c asks for "hmac(sha512)"
>
> 2. The crypto API looks for a direct implementation of "hmac(sha512)".
>This includes requesting a module with
On Sat May 18, 2024 at 10:03 AM EEST, Herbert Xu wrote:
> When the Crypto API is built into the kernel, it may be invoked
> during system initialisation before modules can be loaded. Ensure
> that it doesn't load modules if this is the case by checking
> crypto_boot_test_finished().
>
> Add a call
On Sat, May 18, 2024 at 01:56:44PM +0300, Jarkko Sakkinen wrote:
>
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -36,6 +36,8 @@ config TCG_TPM2_HMAC
> bool "Use HMAC and encrypted transactions on the TPM bus"
> default y
> + select CRYPTO_DRBG
>
On Sat, May 18, 2024 at 02:04:18PM +0300, Jarkko Sakkinen wrote:
>
> Right does this mean for TPM driver that a crypto API invocation not
> having everthing needed loaded will block until this is not the case?
All this does is disable module loading by the Crypto API (because
there is no point and
On Sat May 18, 2024 at 3:32 PM EEST, Herbert Xu wrote:
> On Sat, May 18, 2024 at 02:04:18PM +0300, Jarkko Sakkinen wrote:
> >
> > Right does this mean for TPM driver that a crypto API invocation not
> > having everthing needed loaded will block until this is not the case?
>
> All this does is disab
On May 18, 2024 5:32:56 AM PDT, Herbert Xu wrote:
>On Sat, May 18, 2024 at 02:04:18PM +0300, Jarkko Sakkinen wrote:
>>
>> Right does this mean for TPM driver that a crypto API invocation not
>> having everthing needed loaded will block until this is not the case?
>
>All this does is disable module
Introduce tpm2_key_rsa implementing asymmetric TPM RSA key.
I submit this first as RFC as I could not execute the keyctl padd in the
following sequence (returns EBADF):
tpm2_createprimary --hierarchy o -G rsa2048 -c owner.txt
tpm2_evictcontrol -c owner.txt 0x8101
tpm2_getcap handles-persisten
ASN.1 template is required for TPM2 asymmetric keys, as it needs to be
piggy-packed with the input data before applying TPM2_RSA_Decrypt. This
patch prepares crypto subsystem for the addition of those keys.
Signed-off-by: Jarkko Sakkinen
---
crypto/rsa-pkcs1pad.c | 16 ++--
i
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm.h| 2 -
drivers/char/tpm/tpm2-cmd.c | 77 +++
drivers/char/tpm/tpm2-space.c | 61 ---
include/linux/tpm.h | 2 +
4 files changed, 79 insertions(+), 63 deletions(-)
When asn1_encode_sequence() fails, WARN is not the correct solution.
1. asn1_encode_sequence() is not an internal function (located
in lib/asn1_encode.c).
2. Location is known, which makes the stack trace useless.
3. Results a crash if panic_on_warn is set.
It is also noteworthy that the use o
Migrate tpm2_key_{encode,decode}() to TPM driver and export the symbols
to make them callable from trusted keys.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 5 +
drivers/char/tpm/tpm2_key.c
From: James Prestwood
Based on earlier work by James Prestwood.
Add ASN.1 compatible asymmetric TPM2 RSA key subtype:
1. Signing and decryption (with the private key) is handled by TPM2_RSA_Decrypt.
2. Encryption (with the public key) is handled by the kernel RSA
implementation.
Link: https
## Overview
Introduce tpm2_key_rsa implementing asymmetric TPM RSA key.
I submit this first as RFC as I could not execute the keyctl padd in the
following sequence (returns EBADF):
tpm2_createprimary --hierarchy o -G rsa2048 -c owner.txt
tpm2_evictcontrol -c owner.txt 0x8101
tpm2_getcap hand
ASN.1 template is required for TPM2 asymmetric keys, as it needs to be
piggy-packed with the input data before applying TPM2_RSA_Decrypt. This
patch prepares crypto subsystem for the addition of those keys.
Signed-off-by: Jarkko Sakkinen
---
crypto/rsa-pkcs1pad.c | 16 ++--
i
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm.h| 2 -
drivers/char/tpm/tpm2-cmd.c | 77 +++
drivers/char/tpm/tpm2-space.c | 61 ---
include/linux/tpm.h | 2 +
4 files changed, 79 insertions(+), 63 deletions(-)
When asn1_encode_sequence() fails, WARN is not the correct solution.
1. asn1_encode_sequence() is not an internal function (located
in lib/asn1_encode.c).
2. Location is known, which makes the stack trace useless.
3. Results a crash if panic_on_warn is set.
It is also noteworthy that the use o
Migrate tpm2_key_{encode,decode}() to TPM driver and export the symbols
to make them callable from trusted keys.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/Kconfig | 5 +
drivers/char/tpm/Makefile | 5 +
drivers/char/tpm/tpm2_key.c
From: James Prestwood
Based on earlier work by James Prestwood.
Add ASN.1 compatible asymmetric TPM2 RSA key subtype:
1. Signing and decryption (with the private key) is handled by TPM2_RSA_Decrypt.
2. Encryption (with the public key) is handled by the kernel RSA
implementation.
Link: https
On Sat, May 18, 2024 at 06:07:39AM -0700, James Bottomley wrote:
>
> I have a curiosity question: if Eric is right and it's looking for an
> optional hmac accelerator module, why don't I see this? The only real config
> difference between what I tested and what Nicholas did is he's arm and I'm
20 matches
Mail list logo
