On Thu, May 22, 2025 at 10:26:34AM +0200, Stefano Garzarella wrote:
> On Wed, 21 May 2025 at 18:42, Jarkko Sakkinen wrote:
> >
> > On Wed, May 21, 2025 at 01:12:20PM +0300, Jarkko Sakkinen wrote:
> > > > I tried, but the last patch (this one) is based on the series mer
On Wed, May 21, 2025 at 01:12:20PM +0300, Jarkko Sakkinen wrote:
> > I tried, but the last patch (this one) is based on the series merged
> > on the tip tree, where I introduced tpm_svsm.
> > I can see that series in linux-next merged with commit
> > 16a56ee59ab8ee05
On Wed, May 21, 2025 at 09:13:34AM +0200, Stefano Garzarella wrote:
> On Tue, 20 May 2025 at 22:02, Jarkko Sakkinen wrote:
> > On Tue, May 20, 2025 at 06:06:50PM +0200, Stefano Garzarella wrote:
> > > On Thu, 15 May 2025 at 03:45, Jarkko Sakkinen wrote:
> > > > On W
On Tue, May 20, 2025 at 06:06:50PM +0200, Stefano Garzarella wrote:
> On Thu, 15 May 2025 at 03:45, Jarkko Sakkinen wrote:
> >
> > On Wed, May 14, 2025 at 03:46:30PM +0200, Stefano Garzarella wrote:
> > > From: Stefano Garzarella
> > >
> > > This driver
On Wed, May 14, 2025 at 03:46:30PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella
>
> This driver does not support interrupts, and receiving the response is
> synchronous with sending the command.
>
> Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
> ->send() a
resolve a checkpatch warning:
> WARNING: Unnecessary space before function pointer arguments
> #66: FILE: include/linux/tpm.h:90:
> + int (*send) (struct tpm_chip *chip, u8 *buf, size_t cmd_len,
>
> Suggested-by: Jarkko Sakkinen
> Signed-off-by: Stefano Garzarella
>
On Tue, May 06, 2025 at 02:56:54PM +0200, Stefano Garzarella wrote:
> On Wed, Apr 30, 2025 at 06:39:58PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Apr 14, 2025 at 04:56:50PM +0200, Stefano Garzarella wrote:
> > > From: Stefano Garzarella
> > >
> > > In prepar
On Mon, Apr 14, 2025 at 04:56:53PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella
>
> This driver does not support interrupts, and receiving the response is
> synchronous with sending the command.
>
> So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
> return respon
On Mon, Apr 14, 2025 at 04:56:52PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella
>
> This driver does not support interrupts, and receiving the response is
> synchronous with sending the command.
>
> So we can set TPM_CHIP_FLAG_SYNC to support synchronous send() and
"Enable synchr
send the command and receive the response on the same buffer
> synchronously. In that case send() return the number of bytes of the
> response on success, or -errno on failure.
>
> Suggested-by: Jason Gunthorpe
> Suggested-by: Jarkko Sakkinen
> Signed-off-by: Stefano Garz
> #66: FILE: include/linux/tpm.h:90:
> + int (*send) (struct tpm_chip *chip, u8 *buf, size_t cmd_len,
>
> Suggested-by: Jarkko Sakkinen
> Signed-off-by: Stefano Garzarella
> ---
> include/linux/tpm.h | 3 ++-
> drivers/char/tpm/st33zp24/st33zp24.c | 2
send the command and receive the response on the same buffer
> synchronously. In that case send() return the number of bytes of the
> response on success, or -errno on failure.
>
> Suggested-by: Jason Gunthorpe
> Suggested-by: Jarkko Sakkinen
> Signed-off-by: Stefano Garzare
On Wed Nov 6, 2024 at 8:32 PM EET, Rob Herring wrote:
> On Wed, Nov 6, 2024 at 12:19 PM Jarkko Sakkinen wrote:
> >
> > On Wed Nov 6, 2024 at 8:17 PM EET, Jarkko Sakkinen wrote:
> > > > Whatever happened to this? Can you please apply my patch if you don't
> >
On Wed Nov 6, 2024 at 8:17 PM EET, Jarkko Sakkinen wrote:
> > Whatever happened to this? Can you please apply my patch if you don't
> > have the time for further rework.
>
> Sorry unintentional.
>
> I applied with
>
> -static void __iomem * atmel_get
On Wed Nov 6, 2024 at 4:50 PM EET, Rob Herring wrote:
> On Thu, Jul 18, 2024 at 11:01 AM Jarkko Sakkinen
> wrote:
> >
> > On Thu Jul 18, 2024 at 5:57 PM EEST, Rob Herring wrote:
> > > On Wed, Jul 17, 2024 at 6:14 AM Jarkko Sakkinen
> > > wrote:
> >
On Wed Oct 16, 2024 at 12:15 AM EEST, Jarkko Sakkinen wrote:
> On Mon Oct 14, 2024 at 5:16 PM EEST, Stefan Berger wrote:
> > Set the TPM_OPS_AUTO_STARTUP on the driver so that the ibmvtpm driver now
> > uses tpm2_auto_startup and tpm1_auto_startup like many other drivers
> -
> - if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> - rc = tpm2_get_cc_attrs_tbl(chip);
> - if (rc)
> - goto init_irq_cleanup;
> -
> - rc = tpm2_sessions_init(chip);
> - if (rc)
> - goto init_irq_cleanup;
> - }
> -
> return tpm_chip_register(chip);
> init_irq_cleanup:
> do {
Not much to say about this ;-)
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Fri Sep 6, 2024 at 8:02 PM EEST, Stefan Berger wrote:
>
>
> On 9/5/24 10:26 AM, Jarkko Sakkinen wrote:
> > On Thu Sep 5, 2024 at 11:52 AM EEST, Kexy Biscuit wrote:
> >> Commit 08d08e2e9f0a ("tpm: ibmvtpm: Call tpm2_sessions_init() to
> >> ini
-sessions.c
> index d3521aadd43e..44f60730cff4 100644
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -1362,4 +1362,5 @@ int tpm2_sessions_init(struct tpm_chip *chip)
>
> return rc;
> }
> +EXPORT_SYMBOL(tpm2_sessions_init);
> #endif /* CONFIG_TCG_TPM2_HMAC */
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Mon Jul 29, 2024 at 4:29 PM EEST, Stefan Berger wrote:
> Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced
> CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the
> following message appears in the kernel log due to a missing call to
> tpm2_sessions_init().
>
> [
On Mon Jul 29, 2024 at 4:29 PM EEST, Stefan Berger wrote:
> Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced
> CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the
> following message appears in the kernel log due to a missing call to
> tpm2_sessions_init().
>
> [
c)
> + goto init_irq_cleanup;
> }
>
> return tpm_chip_register(chip);
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Thu Jul 18, 2024 at 5:57 PM EEST, Rob Herring wrote:
> On Wed, Jul 17, 2024 at 6:14 AM Jarkko Sakkinen
> wrote:
> >
> > On Wed Jul 17, 2024 at 3:08 PM EEST, Jarkko Sakkinen wrote:
> > > On Tue Jul 2, 2024 at 7:10 PM EEST, Rob Herring (Arm) wrote:
> > >
On Wed Jul 17, 2024 at 3:08 PM EEST, Jarkko Sakkinen wrote:
> On Tue Jul 2, 2024 at 7:10 PM EEST, Rob Herring (Arm) wrote:
> > The PPC64 specific MMIO setup open codes DT address functions rather
> > than using standard address parsing functions. The open-coded version
> >
- /* verify that it is an Atmel part */
> - if (tpm_read_index(TPM_ADDR, 4) != 'A' ||
> - tpm_read_index(TPM_ADDR, 5) != 'T' ||
> - tpm_read_index(TPM_ADDR, 6) != 'M' ||
> - tpm_read_index(TPM_ADDR, 7) != 'L')
> -
On Wed Jul 3, 2024 at 3:48 AM EEST, Jarkko Sakkinen wrote:
> On Wed Jul 3, 2024 at 3:34 AM EEST, Jarkko Sakkinen wrote:
> > https://lore.kernel.org/linux-integrity/20240703003033.19057-1-jar...@kernel.org/T/#u
> >
> > There's also bunch of other drivers than tpm_ibmvtpm
On Wed Jul 3, 2024 at 3:34 AM EEST, Jarkko Sakkinen wrote:
> https://lore.kernel.org/linux-integrity/20240703003033.19057-1-jar...@kernel.org/T/#u
>
> There's also bunch of other drivers than tpm_ibmvtpm so better
> to limit it to known good drivers.
>
> I can take at the
On Wed Jul 3, 2024 at 2:57 AM EEST, Jarkko Sakkinen wrote:
> On Wed, 2024-07-03 at 02:48 +0300, Jarkko Sakkinen wrote:
> > On Mon, 2024-07-01 at 15:14 -0400, Stefan Berger wrote:
> > > Applying it is probably the better path forward than restricting HMAC to
> > > x86_
On Wed, 2024-07-03 at 02:48 +0300, Jarkko Sakkinen wrote:
> On Mon, 2024-07-01 at 15:14 -0400, Stefan Berger wrote:
> > Applying it is probably the better path forward than restricting HMAC to
> > x86_64 now and enabling it on a per-architecture basis afterwards ...
>
> Why
On Tue, 2024-07-02 at 10:10 -0600, Rob Herring (Arm) wrote:
> The PPC64 specific MMIO setup open codes DT address functions rather
> than using standard address parsing functions. The open-coded version
> fails to handle any address translation and is not endian safe.
>
> I haven't found any evide
On Mon, 2024-07-01 at 15:14 -0400, Stefan Berger wrote:
> Applying it is probably the better path forward than restricting HMAC to
> x86_64 now and enabling it on a per-architecture basis afterwards ...
Why is this here and not in the associated patch?
Any, what argue against is already done for
On Mon Jul 1, 2024 at 6:29 PM UTC, Stefan Berger wrote:
>
>
> On 7/1/24 11:22, Jarkko Sakkinen wrote:
> > On Fri, 2024-06-28 at 17:00 +0200, Linux regression tracking (Thorsten
> > Leemhuis) wrote:
> >> [CCing the regression list]
> >>
> >> On 2
On Fri, 2024-06-28 at 17:00 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> [CCing the regression list]
>
> On 20.06.24 00:34, Stefan Berger wrote:
> > Jarkko,
> > are you ok with this patch?
>
> Hmmm, hope I did not miss anythng, but looks like nothing happened for
> about 10 da
On Wed, 2024-06-19 at 18:34 -0400, Stefan Berger wrote:
> Jarkko,
> are you ok with this patch?
Nope :-) It masks a bug, does not fix it.
BR, Jarkko
On Mon, 2024-06-17 at 15:34 -0400, Stefan Berger wrote:
> Fix the following type of error message caused by a missing call to
> tpm2_sessions_init() in the IBM vTPM driver:
>
> [ 2.987131] tpm tpm0: tpm2_load_context: failed with a TPM error 0x01C4
> [ 2.987140] ima: Error Communicating to T
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
On Thu Apr 25, 2024 at 6:09 PM EEST, Sean Christopherson wrote:
> + __TEST_REQUIRE(kvm_has_cap(KVM_CAP_USER_MEMORY2),
> + "KVM selftests from v6.8+ require
> KVM_SET_USER_MEMORY_REGION2");
This would work also for casual (but not seasoned) visitor in KVM code
as additio
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.
>
>
On Tue Apr 9, 2024 at 12:48 PM EEST, Kshitiz Varshney wrote:
> Hi Jarkko,
>
>
> > -Original Message-
> > From: Jarkko Sakkinen
> > Sent: Wednesday, April 3, 2024 9:18 PM
> > To: David Gstir ; Mimi Zohar ;
> > James Bottomley ; Herbert Xu
> > ;
tored in the key blob.
> + *
> + * Whenever a new trusted key using DCP is generated, we generate a random
> 128-bit
> + * blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to
> + * encrypt the trusted key payload using AES-128-GCM.
> + *
> + * The BEK
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
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
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-
. E.g. in testing
> + scenarios.
> +
> tsc=Disable clocksource stability checks for TSC.
> Format:
> [x86] reliable: mark tsc clocksource as reliable, this
Nicely documented, i.e. even I can understand what is said here :-)
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
OB_GEN
> default y
> + select HAVE_TRUSTED_KEYS
> help
> Enable use of NXP's Cryptographic Accelerator and Assurance Module
> (CAAM) as trusted key backend.
>
> -if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE && !TRUSTED_KEYS_CAAM
> -comment "No trust source selected!"
> +if !HAVE_TRUSTED_KEYS
> + comment "No trust source selected!"
> endif
Tested-by: Jarkko Sakkinen # for TRUSTED_KEYS_TPM
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Tue Mar 12, 2024 at 1:11 PM EET, Lukas Wunner wrote:
> On Mon, Mar 11, 2024 at 09:20:29AM -0400, Stefan Berger wrote:
> > Add linux,sml-log, which carries the firmware TPM log in a uint8-array, to
> > the properties. Either this property is required or both linux,sml-base and
> > linux,sml-size
On Tue Mar 12, 2024 at 12:35 PM EET, Michael Ellerman wrote:
> Stefan Berger writes:
> > On 3/7/24 15:00, Jarkko Sakkinen wrote:
> >> On Thu Mar 7, 2024 at 9:57 PM EET, Jarkko Sakkinen wrote:
> >>> in short summary: s/Use/use/
> >>>
> >>>
On Mon Mar 11, 2024 at 10:33 PM EET, Stefan Berger wrote:
>
>
> On 3/11/24 16:25, Jarkko Sakkinen wrote:
> > On Mon Mar 11, 2024 at 3:20 PM EET, Stefan Berger wrote:
> >> If linux,sml-log is available use it to get the TPM log rather than the
> >> pointer found in
On Mon Mar 11, 2024 at 3:20 PM EET, Stefan Berger wrote:
> If linux,sml-log is available use it to get the TPM log rather than the
> pointer found in linux,sml-base. This resolves an issue on PowerVM and KVM
> on Power where after a kexec the memory pointed to by linux,sml-base may
> have become in
On Mon Mar 11, 2024 at 3:20 PM EET, Stefan Berger wrote:
> linux,sml-base holds the address of a buffer with the TPM log. This
> buffer may become invalid after a kexec. To avoid accessing an invalid
> address or corrupted buffer, embed the whole TPM log in the device tree
> property linux,sml-log.
On Fri Mar 8, 2024 at 2:17 PM EET, Stefan Berger wrote:
>
>
> On 3/7/24 15:00, Jarkko Sakkinen wrote:
> > On Thu Mar 7, 2024 at 9:57 PM EET, Jarkko Sakkinen wrote:
> >> in short summary: s/Use/use/
> >>
> >> On Wed Mar 6, 2024 at 5:55 PM EET, Stef
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;
> >> +
> >>
On Wed Mar 6, 2024 at 5:55 PM EET, Stefan Berger wrote:
> linux,sml-base holds the address of a buffer with the TPM log. This
> buffer may become invalid after a kexec and therefore embed the whole TPM
> log in linux,sml-log. This helps to protect the log since it is properly
> carried across a kex
On Thu Mar 7, 2024 at 9:57 PM EET, Jarkko Sakkinen wrote:
> in short summary: s/Use/use/
>
> On Wed Mar 6, 2024 at 5:55 PM EET, Stefan Berger wrote:
> > If linux,sml-log is available use it to get the TPM log rather than the
> > pointer found in linux,sml-base. This resolve
in short summary: s/Use/use/
On Wed Mar 6, 2024 at 5:55 PM EET, Stefan Berger wrote:
> If linux,sml-log is available use it to get the TPM log rather than the
> pointer found in linux,sml-base. This resolves an issue on PowerVM and KVM
> on Power where after a kexec the memory pointed to by linux,
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
0;
> +out:
> + return ret;
> +}
> +
> +static int test_for_zero_key(void)
> +{
> + static const u8 bad[] = {0x9a, 0xda, 0xe0, 0x54, 0xf6, 0x3d, 0xfa, 0xff,
> + 0x5e, 0xa1, 0x8e, 0x45, 0xed, 0xf6, 0xea,
> 0x6f};
> + void *buf = NULL;
> + int ret = 0;
> +
> + if (skip_zk_test)
> + goto out;
> +
> + buf = kmalloc(AES_BLOCK_SIZE, GFP_KERNEL);
> + if (!buf) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + memset(buf, 0x55, AES_BLOCK_SIZE);
> +
> + ret = do_dcp_crypto(buf, buf, true);
> + if (ret)
> + goto out;
> +
> + if (memcmp(buf, bad, AES_BLOCK_SIZE) == 0) {
> + pr_err("Device neither in secure nor trusted mode!\n");
> + ret = -EINVAL;
> + }
> +out:
> + kfree(buf);
> + return ret;
> +}
> +
> +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", ret);
> +
> + return -EINVAL;
> + }
> +
> + return register_key_type(&key_type_trusted);
> +}
> +
> +static void trusted_dcp_exit(void)
> +{
> + unregister_key_type(&key_type_trusted);
> +}
> +
> +struct trusted_key_ops dcp_trusted_key_ops = {
> + .exit = trusted_dcp_exit,
> + .init = trusted_dcp_init,
> + .seal = trusted_dcp_seal,
> + .unseal = trusted_dcp_unseal,
> + .migratable = 0,
> +};
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
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
_cbc_decrypt,
> + .ivsize = AES_BLOCK_SIZE,
> + .init = mxs_dcp_paes_init_tfm,
> },
> };
>
> diff --git a/include/soc/fsl/dcp.h b/include/soc/fsl/dcp.h
> new file mode 100644
> index ..3ec335d8ca8b
> --- /dev/null
> +++ b/include/soc/fsl/dcp.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2021 sigma star gmbh
> + *
> + * Specifies paes key slot handles for NXP's DCP (Data Co-Processor) to be
> used
> + * with the crypto_skcipher_setkey().
> + */
> +
> +#ifndef MXS_DCP_H
> +#define MXS_DCP_H
> +
> +#define DCP_PAES_KEYSIZE 1
> +#define DCP_PAES_KEY_SLOT0 0x00
> +#define DCP_PAES_KEY_SLOT1 0x01
> +#define DCP_PAES_KEY_SLOT2 0x02
> +#define DCP_PAES_KEY_SLOT3 0x03
> +#define DCP_PAES_KEY_UNIQUE 0xfe
> +#define DCP_PAES_KEY_OTP 0xff
> +
> +#endif /* MXS_DCP_H */
Looks to good enough to me:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
t/
> >
> > v4 is here:
> > https://lore.kernel.org/keyrings/20231024162024.51260-1-da...@sigma-star.at/
> >
> > v4 -> v5:
> > - Make Kconfig for trust source check scalable as suggested by Jarkko
> > Sakkinen
> > - Add Acked-By from Herbert Xu to
gt; +M: David Gstir
> +R: sigma star Kernel Team
> +L: linux-integr...@vger.kernel.org
> +L: keyri...@vger.kernel.org
> +S: Supported
> +F: include/keys/trusted_dcp.h
> +F: security/keys/trusted-keys/trusted_dcp.c
> +
> KEYS-TRUSTED-TEE
> M: Sumit Garg
&
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
Further remarks.
On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
> DCP is capable of performing AES with two hardware-bound keys:
>
> - The one-time programmable (OTP) key which is burnt via on-chip fuses
> - The unique key (UK) which is derived from the OTP key
>
> In addition to the two h
On Fri Dec 15, 2023 at 1:06 PM EET, David Gstir wrote:
> DCP is capable of performing AES with two hardware-bound keys:
>
> - The one-time programmable (OTP) key which is burnt via on-chip fuses
> - The unique key (UK) which is derived from the OTP key
This is somewhat cryptic explanation for the
On Mon Feb 26, 2024 at 12:20 AM EET, Richard Weinberger wrote:
> Mimi, James, Jarkko, David,
>
> you remained silent for a whole release cycle.
> Is there anything we can do to get this forward?
>
> Thanks,
> //richard
Thanks for reminding.
>From my side, I've had pretty busy month as I've adapte
On Tue Oct 24, 2023 at 7:20 PM EEST, 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 CA
On Tue Oct 24, 2023 at 7:20 PM EEST, David Gstir wrote:
> DCP is capable of performing AES with two hardware-bound keys:
>
> - The one-time programmable (OTP) key which is burnt via on-chip fuses
> - The unique key (UK) which is derived from the OTP key
>
> In addition to the two hardware-bound key
On Wed Sep 27, 2023 at 9:25 AM EEST, David Gstir wrote:
> Jarkko,
>
> > On 25.09.2023, at 17:22, Jarkko Sakkinen wrote:
> >
> > On Mon Sep 18, 2023 at 5:18 PM EEST, David Gstir wrote:
> >> DCP is capable to performing AES with hardware-bound keys.
> >>
On Mon Sep 18, 2023 at 5:18 PM 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 Mon Sep 18, 2023 at 5:18 PM EEST, 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 just like CAAM o
On Mon Sep 18, 2023 at 5:18 PM EEST, David Gstir wrote:
> DCP is capable to performing AES with hardware-bound keys.
> These keys are not stored in main memory and are therefore not directly
> accessible by the operating system.
>
> So instead of feeding the key into DCP, we need to place a
> refer
On Tue Sep 12, 2023 at 10:22 PM EEST, Mimi Zohar wrote:
> On Tue, 2023-09-12 at 12:49 +0300, Jarkko Sakkinen wrote:
> > On Tue Sep 12, 2023 at 10:41 AM EEST, Michal Suchánek wrote:
> > > On Mon, Sep 11, 2023 at 11:39:38PM -0400, Nayna wrote:
> > > >
> > > &
On Tue Sep 12, 2023 at 2:11 PM EEST, 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 just like CAAM o
On Tue Sep 12, 2023 at 2:11 PM EEST, David Gstir wrote:
> @@ -101,6 +102,7 @@ struct dcp_async_ctx {
> struct crypto_skcipher *fallback;
> unsigned intkey_len;
> uint8_t key[AES_KEYSIZE_128];
> + bool
On Tue Sep 12, 2023 at 2:11 PM EEST, David Gstir wrote:
> DCP is capable to performing AES with hardware-bound keys.
> These keys are not stored in main memory and are therefore not directly
> accessible by the operating system.
>
> So instead of feeding the key into DCP, we need to place a
> refer
On Tue Sep 12, 2023 at 6:39 AM EEST, Nayna wrote:
>
> On 9/7/23 13:32, Michal Suchánek wrote:
> > Adding more CC's from the original patch, looks like get_maintainers is
> > not that great for this file.
> >
> > On Thu, Sep 07, 2023 at 06:52:19PM +0200, Michal Suchanek wrote:
> >> No other platform
On Tue Sep 12, 2023 at 10:41 AM EEST, Michal Suchánek wrote:
> On Mon, Sep 11, 2023 at 11:39:38PM -0400, Nayna wrote:
> >
> > On 9/7/23 13:32, Michal Suchánek wrote:
> > > Adding more CC's from the original patch, looks like get_maintainers is
> > > not that great for this file.
> > >
> > > On Th
On Mon Aug 21, 2023 at 6:26 PM EEST, Greg Joyce wrote:
> On Wed, 2023-08-16 at 23:41 +0300, Jarkko Sakkinen wrote:
> > On Wed Aug 16, 2023 at 10:45 PM EEST, Greg Joyce wrote:
> > > It's been almost 4 weeks since the last resend and there haven't
> > > been
On Thu Aug 17, 2023 at 12:06 AM EEST, Mimi Zohar wrote:
> On Wed, 2023-08-16 at 23:36 +0300, Jarkko Sakkinen wrote:
> > On Tue Aug 15, 2023 at 2:27 PM EEST, Nayna Jain wrote:
> > > On secure boot enabled PowerVM LPAR, third party code signing keys are
> > > needed
On Wed Aug 16, 2023 at 3:58 PM EEST, Mimi Zohar wrote:
> On Mon, 2023-08-14 at 20:38 +0300, Jarkko Sakkinen wrote:
> > On Sun Aug 13, 2023 at 5:15 AM EEST, Nayna Jain wrote:
> > > On non-UEFI platforms, handle restrict_link_by_ca failures differently.
> > >
> > &g
ock/Kconfig | 2 +
> > block/opal_proto.h | 4 +
> > block/sed-opal.c | 252
> > +-
> > include/linux/sed-opal.h | 5 +
> > include/uapi/linux/sed-opal.h | 25 +++-
> > 5 files changed, 282 insertions(+), 6 deletions(-)
> >
> >
> > base-commit: 1341c7d2ccf42ed91aea80b8579d35bc1ea381e2
I can give because it looks good to me to all patches:
Acked-by: Jarkko Sakkinen
... but should not probably go to my tree.
BR, Jarkko
ata);
> }
>
> + data = get_cert_list("moduledb", 9, &dsize);
> + if (!data) {
> + pr_info("Couldn't get moduledb list from firmware\n");
> + } else if (IS_ERR(data)) {
> + rc = PTR_ERR(data);
> + pr_err("Error reading moduledb from firmware: %d\n", rc);
extract_esl(trustedca, data, dsize, offset);
> +
> + rc = parse_efi_signature_list("powerpc:trustedca", trustedca,
> dsize,
> + get_handler_for_ca_keys);
> + if (rc)
> + pr_err("Couldn't parse trustedcadb signatures: %d\n",
> rc);
> + kfree(data);
> + }
> +
> return rc;
> }
> late_initcall(load_powerpc_certs);
> --
> 2.31.1
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Sun Aug 13, 2023 at 5:15 AM EEST, Nayna Jain wrote:
> On secure boot enabled PowerVM LPAR, third party code signing keys are
> needed during early boot to verify signed third party modules. These
> third party keys are stored in moduledb object in the Platform
> KeyStore(PKS).
>
> Load third par
Y_PLATFORM_KEYRING))
> rc = integrity_load_cert(INTEGRITY_KEYRING_PLATFORM, source,
> data, len, perm);
>
> --
> 2.31.1
Acked-by: Jarkko Sakkinen
BR, Jarkko
On Sun Aug 13, 2023 at 5:15 AM EEST, Nayna Jain wrote:
> Keys that derive their trust from an entity such as a security officer,
> administrator, system owner, or machine owner are said to have "imputed
> trust". CA keys with imputed trust can be loaded onto the machine keyring.
> The mechanism for
On Wed Aug 9, 2023 at 10:53 PM EEST, Nayna Jain wrote:
> On secure boot enabled PowerVM LPAR, third party code signing keys are
> needed during early boot to verify signed third party modules. These
> third party keys are stored in moduledb object in the Platform
> KeyStore(PKS).
^ space
ct INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS
> + select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS
> help
>If set, provide a keyring to which Machine Owner Keys (MOK) may
>be added. This keyring shall contain just MOK keys. Unlike keys
> --
> 2.31.1
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
st_mok = false;
>
> if (uefi_check_trust_mok_keys())
> trust_mok = true;
Nice catch.
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
On Wed Jul 19, 2023 at 2:44 AM EEST, Sean Christopherson wrote:
> /* Huge pages aren't expected to be modified without first being
> zapped. */
> - WARN_ON(pte_huge(range->pte) || range->start + 1 != range->end);
> + WARN_ON(pte_huge(range->arg.pte) || range->start + 1 != range->end)
.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include "tpm.h"
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c
> b/drivers/char/tpm/tpm_tis_spi_main.c
> index 1f5207974a17..c6101914629d 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -28,7 +28,7 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
>
> diff --git a/drivers/char/tpm/tpm_tis_synquacer.c
> b/drivers/char/tpm/tpm_tis_synquacer.c
> index 49278746b0e2..7f9b4bfceb6e 100644
> --- a/drivers/char/tpm/tpm_tis_synquacer.c
> +++ b/drivers/char/tpm/tpm_tis_synquacer.c
> @@ -9,7 +9,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include "tpm.h"
> #include "tpm_tis_core.h"
> --
> 2.40.1
drivers/char/tpm/**
Acked-by: Jarkko Sakkinen
BR, Jarkko
On Wed Jul 12, 2023 at 12:39 PM UTC, Michael Ellerman wrote:
> Jarkko Sakkinen writes:
> > On Tue, 2023-07-11 at 08:47 -0400, Stefan Berger wrote:
> >> On 7/10/23 17:23, Jarkko Sakkinen wrote:
> >> > On Thu, 2023-06-15 at 22:37 +1000, Michael Ellerman w
On Tue, 2023-07-11 at 08:47 -0400, Stefan Berger wrote:
>
> On 7/10/23 17:23, Jarkko Sakkinen wrote:
> > On Thu, 2023-06-15 at 22:37 +1000, Michael Ellerman wrote:
> > > There's code in prom_instantiate_sml() to do a "SML handover" (Stored
> > > Me
On Thu, 2023-06-15 at 22:37 +1000, Michael Ellerman wrote:
> There's code in prom_instantiate_sml() to do a "SML handover" (Stored
> Measurement Log) from OF to Linux, before Linux shuts down Open
> Firmware.
>
> This involves creating a buffer to hold the SML, and creating two device
> tree prope
On Fri, 2023-06-09 at 14:49 -0400, Stefan Berger wrote:
>
> On 6/9/23 14:18, Jarkko Sakkinen wrote:
> > On Thu May 25, 2023 at 1:56 AM EEST, Jerry Snitselaar wrote:
> > > On Tue, Apr 18, 2023 at 09:44:07AM -0400, Stefan Berger wrote:
> > > > Simplify tpm_read_log
On Fri Jun 9, 2023 at 9:49 PM EEST, Stefan Berger wrote:
>
>
> On 6/9/23 14:18, Jarkko Sakkinen wrote:
> > On Thu May 25, 2023 at 1:56 AM EEST, Jerry Snitselaar wrote:
> >> On Tue, Apr 18, 2023 at 09:44:07AM -0400, Stefan Berger wrote:
> >>> Simplify tpm_read_
; used also for kexec support. Call the new of_tpm_get_sml_parameters()
> > function from the TPM Open Firmware driver.
> >
> > Signed-off-by: Stefan Berger
> > Cc: Jarkko Sakkinen
> > Cc: Jason Gunthorpe
> > Cc: Rob Herring
> > Cc: Frank Rowand
> > R
if (IS_ERR(dbx)) {
> - rc = PTR_ERR(dbx);
> + } else if (IS_ERR(data)) {
> + rc = PTR_ERR(data);
> pr_err("Error reading dbx from firmware: %d\n", rc);
> return rc;
> } else {
> - rc = parse_ef
1 - 100 of 191 matches
Mail list logo
