Jarkko Sakkinen wrote:
> On Tue May 21, 2024 at 9:18 PM EEST, James Bottomley wrote:
> ...
> You don't save a single byte of memory with any constant that dictates
> the size requirements for multiple modules in two disjoint subsystems.
I think James is just suggesting you replace your limit arg
On Tue May 21, 2024 at 9:18 PM EEST, James Bottomley wrote:
> On Tue, 2024-05-21 at 06:16 +0300, Jarkko Sakkinen wrote:
> [...]
> > diff --git a/include/crypto/tpm2_key.h b/include/crypto/tpm2_key.h
> > new file mode 100644
> > index ..acf41b2e0c92
> > --- /dev/null
> > +++ b/include/cr
On Tue, May 21, 2024 at 10:53:18AM +0800, Herbert Xu wrote:
> On Mon, May 20, 2024 at 11:49:56AM -0400, Nícolas F. R. A. Prado wrote:
> >
> > Unfortunately this patch didn't work either. The warning is still there
> > unchanged.
>
> OK perhaps we can do it by calling current_is_async ourselves.
>
On Tue, 2024-05-21 at 06:16 +0300, Jarkko Sakkinen wrote:
[...]
> diff --git a/include/crypto/tpm2_key.h b/include/crypto/tpm2_key.h
> new file mode 100644
> index ..acf41b2e0c92
> --- /dev/null
> +++ b/include/crypto/tpm2_key.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0-
On Tue May 21, 2024 at 10:25 AM EEST, Bharat Bhushan wrote:
> > + rc = crypto_akcipher_encrypt(req);
> > + rc = crypto_wait_req(rc, &cwait);
> > +
>
> Few Minor comments,
> Extra line here
Yeah, makes sense.
> > + if (!rc)
> > + rc = req->dst_len;
> > +
> > + akcipher_request
> -Original Message-
> From: Jarkko Sakkinen
> Sent: Tuesday, May 21, 2024 8:47 AM
> To: Herbert Xu
> Cc: linux-integr...@vger.kernel.org; keyri...@vger.kernel.org;
> andreas.fu...@infineon.com; James Prestwood ;
> David Woodhouse ; Eric Biggers
> ; James Bottomley
> ; Jarkko Sakkinen
On Tue May 21, 2024 at 8:47 AM EEST, Bharat Bhushan wrote:
>
>
> > -Original Message-
> > From: Jarkko Sakkinen
> > Sent: Tuesday, May 21, 2024 8:47 AM
> > To: Herbert Xu
> > Cc: linux-integr...@vger.kernel.org; keyri...@vger.kernel.org;
> > andreas.fu...@infineon.com; James Prestwood ;
>
On Tue May 21, 2024 at 8:36 AM EEST, Bharat Bhushan wrote:
> > - data_len -= 2;
> > + (*data++) = _tag(UNIV, PRIM, INT);
>
> Just for my clarification:
> First index of "data" is updated here with tag and data pointer
> incremented.
> Next comment for continuation
>
> > + data_l
> -Original Message-
> From: Jarkko Sakkinen
> Sent: Tuesday, May 21, 2024 8:47 AM
> To: Herbert Xu
> Cc: linux-integr...@vger.kernel.org; keyri...@vger.kernel.org;
> andreas.fu...@infineon.com; James Prestwood ;
> David Woodhouse ; Eric Biggers
> ; James Bottomley
> ; Jarkko Sakkinen
ength (adjusted by routine)
> + * @len: length to encode
> + *
> + * This routine can encode lengths up to 65535 using the ASN.1 rules.
> + * It will accept a negative length and place a zero length tag
> + * instead (to keep the ASN.1 valid). This convention allows other
> + * enco
On Mon May 20, 2024 at 11:36 PM EEST, Jarkko Sakkinen wrote:
> On Mon May 20, 2024 at 9:47 PM EEST, Jarkko Sakkinen wrote:
> > ## Overview
> >
> > Introduce tpm2_key_rsa implementing asymmetric TPM RSA key. This key type
> > can be enabled with CONFIG_ASYMMETRIC_TPM2_KEY_RSA_SUBTYPE config option.
On Mon May 20, 2024 at 9:47 PM EEST, Jarkko Sakkinen wrote:
> ## Overview
>
> Introduce tpm2_key_rsa implementing asymmetric TPM RSA key. This key type
> can be enabled with CONFIG_ASYMMETRIC_TPM2_KEY_RSA_SUBTYPE config option.
> Carves groundwork for similar modules in future, such as tpm2_key_ecd
On Sat, May 18, 2024 at 03:03:51PM +0800, Herbert Xu wrote:
> 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
On Sun May 19, 2024 at 3:25 AM EEST, Jarkko Sakkinen wrote:
> ## 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 rsa204
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
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
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 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 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 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 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 Fri, May 17, 2024 at 07:48:48PM +0300, Jarkko Sakkinen wrote:
> On Fri May 17, 2024 at 7:22 PM EEST, Nícolas F. R. A. Prado wrote:
> > On Fri, May 17, 2024 at 07:25:40AM -0700, James Bottomley wrote:
> > > On Fri, 2024-05-17 at 15:43 +0200, Ard Biesheuvel wrote:
> > > > On Fri, 17 May 2024 at 15
On Fri May 17, 2024 at 7:22 PM EEST, Nícolas F. R. A. Prado wrote:
> On Fri, May 17, 2024 at 07:25:40AM -0700, James Bottomley wrote:
> > On Fri, 2024-05-17 at 15:43 +0200, Ard Biesheuvel wrote:
> > > On Fri, 17 May 2024 at 15:35, James Bottomley
> > > wrote:
> > [...]
> > > > Thanks for the analy
On Fri, May 17, 2024 at 07:25:40AM -0700, James Bottomley wrote:
> On Fri, 2024-05-17 at 15:43 +0200, Ard Biesheuvel wrote:
> > On Fri, 17 May 2024 at 15:35, James Bottomley
> > wrote:
> [...]
> > > Thanks for the analysis. If I look at how CRYPTO_ECC does it, that
> > > selects CRYPTO_RNG_DEFAUL
On Fri, 2024-05-17 at 15:43 +0200, Ard Biesheuvel wrote:
> On Fri, 17 May 2024 at 15:35, James Bottomley
> wrote:
[...]
> > Thanks for the analysis. If I look at how CRYPTO_ECC does it, that
> > selects CRYPTO_RNG_DEFAULT which pulls in CRYPTO_DRBG, so the fix
> > would be the attached. Does tha
On Fri, 17 May 2024 at 15:35, James Bottomley
wrote:
>
> On Fri, 2024-05-17 at 09:20 +0200, Ard Biesheuvel wrote:
> > On Fri, 17 May 2024 at 03:59, James Bottomley
> > wrote:
> > >
> > > On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
> > ...
> > > > KernelCI has identified a new
On Fri, 2024-05-17 at 09:20 +0200, Ard Biesheuvel wrote:
> On Fri, 17 May 2024 at 03:59, James Bottomley
> wrote:
> >
> > On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
> ...
> > > KernelCI has identified a new warning and I tracked it down to
> > > this
> > > commit. It
> > > w
On Fri May 17, 2024 at 10:20 AM EEST, Ard Biesheuvel wrote:
> On Fri, 17 May 2024 at 03:59, James Bottomley
> wrote:
> >
> > On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
> ...
> > > KernelCI has identified a new warning and I tracked it down to this
> > > commit. It
> > > was o
On Fri, 17 May 2024 at 03:59, James Bottomley
wrote:
>
> On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
...
> > KernelCI has identified a new warning and I tracked it down to this
> > commit. It
> > was observed on the following platforms:
> > * mt8183-kukui-jacuzzi-juniper-sku16
On Thu May 16, 2024 at 7:14 AM EEST, Herbert Xu wrote:
> On Wed, May 15, 2024 at 06:02:10PM +0300, Jarkko Sakkinen wrote:
> > 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
On Wed, May 15, 2024 at 06:02:10PM +0300, Jarkko Sakkinen wrote:
> 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.
>
> Later rsa_lookup
On Tue Apr 30, 2024 at 3:03 PM EEST, David Gstir wrote:
> Hi Jarkko,
>
> > On 30.04.2024, at 13:48, Kshitiz Varshney wrote:
> >
> > Hi David,
> >
> >> -Original Message-
> >> From: David Gstir
> >> Sent: Monday, April 29, 2024 5:05 PM
> >> To: Kshitiz Varshney
>
>
> >>
> >> Did you ge
Hi Jarkko,
> On 30.04.2024, at 13:48, Kshitiz Varshney wrote:
>
> Hi David,
>
>> -Original Message-
>> From: David Gstir
>> Sent: Monday, April 29, 2024 5:05 PM
>> To: Kshitiz Varshney
>>
>> Did you get around to testing this?
>> I’d greatly appreciate a Tested-by for this. :-)
>>
hard Weinberger ; David
> Oberhollenzer ; Varun Sethi
> ; Gaurav Jain ; Pankaj Gupta
>
> Subject: Re: [EXT] [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new
> trust source
>
> Caution: This is an external email. Please take care when clicking links or
> opening att
On Mon, Mar 25, 2024 at 03:01:56PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally.
>
> Use the `__struct_group()` helper to separate the flexible array
> from the rest of the members in flexible `struct nx842
rnel.org; linux-crypto@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-security-
>> mod...@vger.kernel.org; Richard Weinberger ; David
>> Oberhollenzer
>> Subject: [EXT] Re: [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new
>>
On Mon, Apr 22, 2024 at 04:05:34PM +0800, kernel test robot wrote:
> [ 235.998172][T1] Kernel panic - not syncing: Certs selftest 0:
> pkcs7_verify() = -65
Thanks! The problem is that CONFIG_FIPS_SIGNATURE_SELFTEST is missing
dependencies on the algorithms it uses.
https://lore.kernel.org/r
On Fri Apr 12, 2024 at 9:26 AM EEST, Herbert Xu wrote:
> On Wed, Apr 03, 2024 at 06:47:51PM +0300, Jarkko Sakkinen wrote:
> >
> > Reviewed-by: Jarkko Sakkinen
> >
> > I can only test that this does not break a machine without the
> > hardware feature.
>
> Please feel free to take this through you
; linux-crypto@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-security-
> > mod...@vger.kernel.org; Richard Weinberger ; David
> > Oberhollenzer
> > Subject: [EXT] Re: [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new
On Wed, Apr 03, 2024 at 06:47:51PM +0300, Jarkko Sakkinen wrote:
>
> Reviewed-by: Jarkko Sakkinen
>
> I can only test that this does not break a machine without the
> hardware feature.
Please feel free to take this through your tree.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana
ngutronix Kernel Team ;
> Tejun Heo ; linux-integr...@vger.kernel.org; Shawn Guo
> ; Varun Sethi
> Subject: Re: [EXT] [PATCH v8 3/6] KEYS: trusted: Introduce NXP DCP-backed
> trusted keys
>
> Caution: This is an external email. Please take care when clicking links or
> ope
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
>
Hi David,
> -Original Message-
> From: David Gstir
> Sent: Wednesday, April 3, 2024 12:51 PM
> To: Mimi Zohar ; James Bottomley
> ; Jarkko Sakkinen ; Herbert Xu
> ; David S. Miller
> Cc: David Gstir ; Shawn Guo ;
> Jonathan Corbet ; Sascha Hauer
> ; Pengutronix Kernel Team
> ; Fabio Este
gt; (Google) ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-integr...@vger.kernel.org;
> keyri...@vger.kernel.org; linux-crypto@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-security-
> mod...@vger.kernel.org; Richard Weinberger
> On Apr 4, 2024, at 4:40 PM, Mimi Zohar wrote:
>
> Hi Eric,
>
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index 9de610bf1f4b..b647be49f6e0 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -426,3 +426,32 @@ void __init set_platform_trusted_key
Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally.
>
> Use the `__struct_group()` helper to separate the flexible array
> from the rest of the members in flexible `struct qat_alg_buf_list`,
> through tagged `struct qa
Hi Eric,
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 9de610bf1f4b..b647be49f6e0 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -426,3 +426,32 @@ void __init set_platform_trusted_keys(struct key
> *keyring)
> platform_trusted_keys = keyrin
On Wed, 13 Mar 2024 13:53:13 +0100, Luca Weiss wrote:
> Add the required bits to support Inline Crypto Engine on SC7280 SoC with
> UFS.
>
>
Applied, thanks!
[2/2] arm64: dts: qcom: sc7280: Add inline crypto engine
commit: dfd5ee7b34bb7611d4d2f4f3cb37152baeaae96d
Best regards,
--
Bjorn
On Wed Apr 3, 2024 at 10:21 AM EEST, David Gstir wrote:
> Update the documentation for trusted and encrypted KEYS with DCP as new
> trust source:
>
> - Describe security properties of DCP trust source
> - Describe key usage
> - Document blob format
>
> Co-developed-by: Richard Weinberger
> Signed-
On Wed, Apr 03, 2024 at 09:21:22AM +0200, David Gstir wrote:
> diff --git a/Documentation/security/keys/trusted-encrypted.rst
> b/Documentation/security/keys/trusted-encrypted.rst
> index e989b9802f92..f4d7e162d5e4 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentat
On Mon, Mar 25, 2024 at 02:44:55PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally.
>
> Use the `__struct_group()` helper to separate the flexible array
> from the rest of the members in flexible `struct qat_a
On Thu Mar 28, 2024 at 8:47 PM EET, Jarkko Sakkinen wrote:
> On Thu Mar 28, 2024 at 10:05 AM EET, David Gstir wrote:
> > Jarkko,
> >
> > > On 27.03.2024, at 16:40, Jarkko Sakkinen wrote:
> > >
> > > On Wed Mar 27, 2024 at 10:24 AM EET, David Gstir wrote:
> > >> Update the documentation for truste
On Thu Mar 28, 2024 at 10:05 AM EET, David Gstir wrote:
> Jarkko,
>
> > On 27.03.2024, at 16:40, Jarkko Sakkinen wrote:
> >
> > On Wed Mar 27, 2024 at 10:24 AM EET, David Gstir wrote:
> >> Update the documentation for trusted and encrypted KEYS with DCP as new
> >> trust source:
> >>
> >> - Desc
On Wed, Mar 13, 2024 at 01:53:14PM +0100, Luca Weiss wrote:
> Document the compatible used for the inline crypto engine found on
> SC7280.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
> 1 file changed, 1 insertion(+)
Patch
On Tue, Mar 05, 2024 at 01:57:56PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally. So, we are deprecating flexible-array
> members in the middle of another structure.
>
> There is currently an object (`header
Jarkko,
> On 27.03.2024, at 16:40, Jarkko Sakkinen wrote:
>
> On Wed Mar 27, 2024 at 10:24 AM EET, David Gstir wrote:
>> Update the documentation for trusted and encrypted KEYS with DCP as new
>> trust source:
>>
>> - Describe security properties of DCP trust source
>> - Describe key usage
>> -
On Wed Mar 27, 2024 at 10:24 AM EET, David Gstir wrote:
> Update the documentation for trusted and encrypted KEYS with DCP as new
> trust source:
>
> - Describe security properties of DCP trust source
> - Describe key usage
> - Document blob format
>
> Co-developed-by: Richard Weinberger
> Signed-
On Wed Mar 27, 2024 at 10:24 AM EET, David Gstir wrote:
> Document the kernel parameters trusted.dcp_use_otp_key
> and trusted.dcp_skip_zk_test for DCP-backed trusted keys.
>
> Co-developed-by: Richard Weinberger
> Signed-off-by: Richard Weinberger
> Co-developed-by: David Oberhollenzer
> Signed
On Wed Mar 27, 2024 at 10:24 AM EET, David Gstir wrote:
> Enabling trusted keys requires at least one trust source implementation
> (currently TPM, TEE or CAAM) to be enabled. Currently, this is
> done by checking each trust source's config option individually.
> This does not scale when more trust
On Mon, 19 Feb 2024 11:16:02 +0100, Luca Weiss wrote:
> Add crypto engine (CE) and CE BAM related nodes and definitions for this
> SoC.
>
> For reference:
>
> [2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 5.5.1
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sm6350
#regzbot title: SHA1 support removal breaks iwd's ability to connect to eduroam
#regzbot monitor:
https://lore.kernel.org/all/20240313233227.56391-1-ebigg...@kernel.org/
#regzbot monitor:
https://lore.kernel.org/all/czshruij4rkl.34t4easv5d...@matfyz.cz/
#regzbot link:
https://lore.kernel.org/iwd
On Thu, 14 Mar 2024 at 21:20, Eric Biggers wrote:
>
> On Thu, Mar 14, 2024 at 04:52:47AM -0700, James Prestwood wrote:
> > IWD uses AF_ALG/keyctl for _all_ its crypto, cipher, and checksum needs.
> > Anything that wifi requires as far as crypto goes IWD uses the kernel,
> > except ECC is the only
On Thu, Mar 14, 2024 at 04:52:47AM -0700, James Prestwood wrote:
> IWD uses AF_ALG/keyctl for _all_ its crypto, cipher, and checksum needs.
> Anything that wifi requires as far as crypto goes IWD uses the kernel,
> except ECC is the only exception. The entire list of crypto requirements
> (for full
On Thu, 2024-03-14 at 04:52 -0700, James Prestwood wrote:
> I'm also not entirely sure why this stuff continues to be removed
> from the kernel. First MD4, then it got reverted, then this (now
> reverted, thanks). Both cases there was not clear justification of
> why it was being removed.
I think
Hi,
On 3/13/24 4:06 PM, Eric Biggers wrote:
On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
On 3/13/2024 3:10 PM, Eric Biggers wrote:
On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
Hi,
On 3/13/24 1:22 PM, Eric Biggers wrote:
On Wed, Mar 13, 2024 at 01:12:54PM
On Wed, Mar 13, 2024 at 04:06:11PM -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
> > On 3/13/2024 3:10 PM, Eric Biggers wrote:
> > > On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> > >> Hi,
> > >>
> > >> On 3/13/24 1:22 PM, Eric Bigger
On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
> On 3/13/2024 3:10 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> >> Hi,
> >>
> >> On 3/13/24 1:22 PM, Eric Biggers wrote:
> >>> On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood w
On 3/13/2024 3:10 PM, Eric Biggers wrote:
> On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
>> Hi,
>>
>> On 3/13/24 1:22 PM, Eric Biggers wrote:
>>> On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
Hi,
On 3/13/24 12:44 PM, Eric Biggers wrote:
> On
On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 1:22 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > On 3/13/24 12:44 PM, Eric Biggers wrote:
> > > > On Wed, Mar 13, 2024 at 10:26:06AM -0700,
Hi,
On 3/13/24 1:22 PM, Eric Biggers wrote:
On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
Hi,
On 3/13/24 12:44 PM, Eric Biggers wrote:
On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
Hi,
On 3/13/24 1:56 AM, Johannes Berg wrote:
Not sure why you're CC'ing
On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 12:44 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > On 3/13/24 1:56 AM, Johannes Berg wrote:
> > > > Not sure why you're CC'ing the world, but
Hi,
On 3/13/24 12:44 PM, Eric Biggers wrote:
On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
Hi,
On 3/13/24 1:56 AM, Johannes Berg wrote:
Not sure why you're CC'ing the world, but I guess adding a few more
doesn't hurt ...
On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote
Thank you all for your feedback so far.
Since it seems that this really is a regression on the kernel side, let
me add the appropriate list to Cc and tag this:
#regzbot introduced: 16ab7cb5825f
Best regards,
K. B.
On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 1:56 AM, Johannes Berg wrote:
> > Not sure why you're CC'ing the world, but I guess adding a few more
> > doesn't hurt ...
> >
> > On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote:
> > > and I use iwd
> >
Hi
This came in via the iwd mailing list, and I would like to add some small a
detail as I also experience this issue on my university eduroam network. I've
verified that the certificate chain doesn't contain SHA-1 signed certificates,
so the update breaks more than just SHA-1.
Michael
On
Hi,
On 3/13/24 1:56 AM, Johannes Berg wrote:
Not sure why you're CC'ing the world, but I guess adding a few more
doesn't hurt ...
On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote:
and I use iwd
This is your problem, the wireless stack in the kernel doesn't use any
kernel crypto code for
On 13/03/2024 13:53, Luca Weiss wrote:
> Document the compatible used for the inline crypto engine found on
> SC7280.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 3/13/24 13:53, Luca Weiss wrote:
Add the ICE found on sc7280 and link it to the UFS node.
For reference:
[0.261424] qcom-ice 1d88000.crypto: Found QC Inline Crypto Engine (ICE)
v3.2.0
Signed-off-by: Luca Weiss
---
Reviewed-by: Konrad Dybcio
Konrad
Not sure why you're CC'ing the world, but I guess adding a few more
doesn't hurt ...
On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote:
>
> and I use iwd
This is your problem, the wireless stack in the kernel doesn't use any
kernel crypto code for 802.1X.
I suppose iwd wants to use the kern
Dimitri, Johannes,
ever since upgrading to Linux v6.7 I am unable to connect to a 802.1X
wireless network (specifically, eduroam). In my dmesg, the following
messages appear:
[ 68.161621] wlan0: authenticate with xx:xx:xx:xx:xx:xx (local
address=xx:xx:xx:xx:xx:xx)
[ 68.163733
On Mon Mar 11, 2024 at 11:31 PM EET, Eric Snowberg wrote:
>
>
> > On Mar 11, 2024, at 1:18 PM, Jarkko Sakkinen wrote:
> >
> > On Mon Mar 11, 2024 at 6:11 PM EET, Eric Snowberg wrote:
> >> + return -1;
> >
> > Missed this one: why a magic number?
>
> Good point, I'll change this to return -ENOKEY
> On Mar 11, 2024, at 8:45 PM, Randy Dunlap wrote:
>
> On 3/11/24 09:11, Eric Snowberg wrote:
>> In the future it is envisioned this LSM could be enhanced to provide
>> access control for UEFI Secure Boot Advanced Targeting (SBAT). Using
>> the same clavis= boot param and storing the additiona
> -Original Message-
> From: Eric Snowberg
> Sent: Monday, March 11, 2024 9:41 PM
> To: linux-security-mod...@vger.kernel.org
> Cc: dhowe...@redhat.com; dw...@infradead.org;
> herb...@gondor.apana.org.au; da...@davemloft.net; a...@kernel.org;
> jar...@kernel.org; p...@paul-moore.com; jm
On 3/11/24 09:11, Eric Snowberg wrote:
> In the future it is envisioned this LSM could be enhanced to provide
> access control for UEFI Secure Boot Advanced Targeting (SBAT). Using
> the same clavis= boot param and storing the additional contents within
> the new RT UEFI var, SBAT restrictions
> On Mar 11, 2024, at 1:18 PM, Jarkko Sakkinen wrote:
>
> On Mon Mar 11, 2024 at 6:11 PM EET, Eric Snowberg wrote:
>> + return -1;
>
> Missed this one: why a magic number?
Good point, I'll change this to return -ENOKEY. Thanks.
> On Mar 11, 2024, at 1:16 PM, Jarkko Sakkinen wrote:
>
> On Mon Mar 11, 2024 at 6:11 PM EET, Eric Snowberg wrote:
>> Introduce a new function to allow a keyring to link to a key contained
>> within one of the system keyrings (builtin, secondary, or platform).
>> Depending on how the kernel is
On Fri Mar 8, 2024 at 9:17 AM EET, David Gstir wrote:
> Hi Jarkko,
>
> > On 07.03.2024, at 20:30, Jarkko Sakkinen wrote:
>
> [...]
>
> >> +
> >> +static int trusted_dcp_init(void)
> >> +{
> >> + int ret;
> >> +
> >> + if (use_otp_key)
> >> + pr_info("Using DCP OTP key\n");
> >> +
> >> + ret = test
On Mon Mar 11, 2024 at 6:11 PM EET, Eric Snowberg wrote:
> + return -1;
Missed this one: why a magic number?
BR, Jarkko
On Mon Mar 11, 2024 at 6:11 PM EET, Eric Snowberg wrote:
> Introduce a new function to allow a keyring to link to a key contained
> within one of the system keyrings (builtin, secondary, or platform).
> Depending on how the kernel is built, if the machine keyring is
> available, it will be checked
Hi Jarkko,
> On 07.03.2024, at 20:30, Jarkko Sakkinen wrote:
[...]
>> +
>> +static int trusted_dcp_init(void)
>> +{
>> + int ret;
>> +
>> + if (use_otp_key)
>> + pr_info("Using DCP OTP key\n");
>> +
>> + ret = test_for_zero_key();
>> + if (ret) {
>> + pr_err("Test for zero'ed keys failed: %i\n"
On Thu Mar 7, 2024 at 5:38 PM EET, David Gstir wrote:
> Document the kernel parameters trusted.dcp_use_otp_key
> and trusted.dcp_skip_zk_test for DCP-backed trusted keys.
>
> Co-developed-by: Richard Weinberger
> Signed-off-by: Richard Weinberger
> Co-developed-by: David Oberhollenzer
> Signed-o
On Thu Mar 7, 2024 at 5:38 PM EET, David Gstir wrote:
> DCP (Data Co-Processor) is the little brother of NXP's CAAM IP.
> Beside of accelerated crypto operations, it also offers support for
> hardware-bound keys. Using this feature it is possible to implement a blob
> mechanism similar to what CAAM
On Thu Mar 7, 2024 at 5:38 PM EET, David Gstir wrote:> DCP (Data Co-Processor)
is the little brother of NXP's CAAM IP.
> Beside of accelerated crypto operations, it also offers support for
> hardware-bound keys. Using this feature it is possible to implement a blob
> mechanism similar to what CAAM
On Thu Mar 7, 2024 at 5:38 PM EET, David Gstir wrote:
> Enabling trusted keys requires at least one trust source implementation
> (currently TPM, TEE or CAAM) to be enabled. Currently, this is
> done by checking each trust source's config option individually.
> This does not scale when more trust s
On Thu Mar 7, 2024 at 5:38 PM EET, David Gstir wrote:
> DCP (Data Co-Processor) is able to derive private keys for a fused
> random seed, which can be referenced by handle but not accessed by
> the CPU. Similarly, DCP is able to store arbitrary keys in four
> dedicated key slots located in its secu
Jarkko,
> On 04.03.2024, at 23:48, Jarkko Sakkinen wrote:
>
> On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
>> This covers trusted keys backed by NXP's DCP (Data Co-Processor) chip
>> found in smaller i.MX SoCs.
>>
>> Signed-off-by: David Gstir
>> ---
>> MAINTAINERS | 9 +
>> 1
On Tue Dec 19, 2023 at 2:45 AM EET, Paul Moore wrote:
> On Fri, Dec 15, 2023 at 6:07 AM David Gstir wrote:
> >
> > This is a revival of the previous patch set submitted by Richard Weinberger:
> > https://lore.kernel.org/linux-integrity/20210614201620.30451-1-rich...@nod.at/
> >
> > v4 is here:
> >
On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
> This covers trusted keys backed by NXP's DCP (Data Co-Processor) chip
> found in smaller i.MX SoCs.
>
> Signed-off-by: David Gstir
> ---
> MAINTAINERS | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINE
On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
> DCP (Data Co-Processor) is the little brother of NXP's CAAM IP.
> Beside of accelerated crypto operations, it also offers support for
Why acronym is not opened already in the first patch? Also, that does
not mean it could not be opened also
On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
> Checking if at least one valid trust source is selected does not scale
> and becomes hard to read. This improves this in preparation for the DCP
> trust source.
This commit needs a complete rewrite and I do not have time and
energy to propos
101 - 200 of 7575 matches
Mail list logo
