On Tue, Mar 17, 2020 at 09:08:19AM -0400, Stefan Berger wrote:
> From: Stefan Berger
>
> This patch fixes the following problem when the ibmvtpm driver
> is built as a module:
>
> ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko]
> undefined!
> make[1]: *** [scripts/Make
On Wed, Mar 18, 2020 at 03:53:54PM -0400, Stefan Berger wrote:
> On 3/18/20 3:42 PM, Jarkko Sakkinen wrote:
> > On Tue, Mar 17, 2020 at 09:08:19AM -0400, Stefan Berger wrote:
> > > From: Stefan Berger
> > >
> > > This patch fixes the following problem when th
On Wed, Mar 18, 2020 at 09:00:17PM -0400, Stefan Berger wrote:
> From: Stefan Berger
>
> This patch fixes the following problem when the ibmvtpm driver
> is built as a module:
>
> ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko]
> undefined!
> make[1]: *** [scripts/Make
On Thu, Mar 19, 2020 at 11:56:11AM -0400, Stefan Berger wrote:
> On 3/19/20 10:27 AM, Jarkko Sakkinen wrote:
> > On Wed, Mar 18, 2020 at 03:53:54PM -0400, Stefan Berger wrote:
> > > On 3/18/20 3:42 PM, Jarkko Sakkinen wrote:
> > > > On Tue, Mar 17, 2020 at 09:08:1
On Wed, Apr 01, 2020 at 02:40:30PM +0530, Sachin Sant wrote:
>
>
> > On 20-Mar-2020, at 1:27 AM, Jarkko Sakkinen
> > wrote:
> >
> > On Wed, Mar 18, 2020 at 09:00:17PM -0400, Stefan Berger wrote:
> >> From: Stefan Berger
> >>
> >>
On Tue, Apr 14, 2020 at 10:51:37AM +1000, Michael Ellerman wrote:
> Jarkko Sakkinen writes:
> > On Wed, Apr 01, 2020 at 02:40:30PM +0530, Sachin Sant wrote:
> >> > On 20-Mar-2020, at 1:27 AM, Jarkko Sakkinen
> >> > wrote:
> >> >
> >> >
On Wed, 2019-07-03 at 23:32 -0400, Nayna Jain wrote:
> The nr_allocated_banks and allocated banks are initialized as part of
> tpm_chip_register. Currently, this is done as part of auto startup
> function. However, some drivers, like the ibm vtpm driver, do not run
> auto startup during initializat
On Fri, 2019-07-05 at 13:42 +0300, Jarkko Sakkinen wrote:
> On Wed, 2019-07-03 at 23:32 -0400, Nayna Jain wrote:
> > The nr_allocated_banks and allocated banks are initialized as part of
> > tpm_chip_register. Currently, this is done as part of auto startup
> > function.
On Fri, 2019-07-05 at 11:32 -0400, Nayna wrote:
> I am not sure of the purpose of tpm_stop_chip(), so I have left it as it
> is. Jarkko, what do you think about the change ?
Stefan right. Your does not work, or will randomly work or not work
depending on the chip.
You need to turn the TPM on wit
On Fri, 2019-07-05 at 20:50 +0300, Jarkko Sakkinen wrote:
> To summarize this patch fixes one regression and introduces two
> completely new ones...
Anyway, take the time and update it. The principle is right
anyway. I'll merge it once it is in a better shape...
/Jarkko
On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote:
> +/*
> + * tpm_get_pcr_allocation() - initialize the chip allocated banks for PCRs
> + * @chip: TPM chip to use.
> + */
> +static int tpm_get_pcr_allocation(struct tpm_chip *chip)
> +{
> + int rc;
> +
> + if (chip->flags & TPM_CHIP_FLAG_
On Sat, 2019-07-06 at 20:25 -0400, Nayna wrote:
> Thanks Jarkko. I just now posted the v2 version that includes your and
> Stefan's feedbacks.
Looks almost legit :-)
/Jarkko
On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote:
> > static int tpm_get_pcr_allocation(struct tpm_chip *chip)
> > {
> > int rc;
> >
> > rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ?
> > tpm2_get_pcr_allocation(chip) :
> > tpm1_get_pcr_allocation(chi
On Mon, Jul 08, 2019 at 03:43:04PM -0700, Christoph Hellwig wrote:
> On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote:
> > > static int tpm_get_pcr_allocation(struct tpm_chip *chip)
> > > {
> > > int rc;
> > >
> > > rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ?
> > >tpm2_
;
> Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
> PCR read")
> Reported-by: Michal Suchanek
> Signed-off-by: Nayna Jain
> Reviewed-by: Mimi Zohar
> Tested-by: Sachin Sant
> Tested-by: Michal Suchánek
Reviewed-by: Jarkko Sakkinen
/Jarkko
On Thu, Jul 11, 2019 at 11:28:24PM +0300, Jarkko Sakkinen wrote:
> On Thu, Jul 11, 2019 at 12:13:35PM -0400, Nayna Jain wrote:
> > The nr_allocated_banks and allocated banks are initialized as part of
> > tpm_chip_register. Currently, this is done as part of auto startup
> &
On Mon, 2019-12-16 at 09:42 +0100, Enrico Weigelt, metux IT consult wrote:
> Remove MODULE_VERSION(), as it isn't needed at all: the only version
> making sense is the kernel version.
Take the following line away:
> See also: https://lkml.org/lkml/2017/11/22/480
And just before SOB:
Link: https
On Tue, 2019-12-17 at 13:16 +0200, Jarkko Sakkinen wrote:
> On Mon, 2019-12-16 at 09:42 +0100, Enrico Weigelt, metux IT consult wrote:
> > Remove MODULE_VERSION(), as it isn't needed at all: the only version
> > making sense is the kernel version.
>
> Take the following
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 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 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 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 (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 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 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 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:
> 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 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 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 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 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 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 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 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
.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 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)
st_mok = false;
>
> if (uefi_check_trust_mok_keys())
> trust_mok = true;
Nice catch.
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
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
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
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
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:
> 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
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
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);
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
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
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 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 Fri May 5, 2023 at 10:43 PM EEST, wrote:
> From: Greg Joyce
>
> Add read and write functions that allow SED Opal keys to stored
> in a permanent keystore.
Please be more verbose starting from "Self-Encrypting Drive (SED)",
instead of just "SED", and take time to explain what these keys are.
On Tue Jun 6, 2023 at 8:26 PM EEST, Nayna Jain wrote:
> On PowerVM guest, variable data is prefixed with 8 bytes of timestamp.
> Extract ESL by stripping off the timestamp before passing to ESL parser.
>
Cc: sta...@vger.kenrnel.org # v6.3
?
> Fixes: 4b3e71e9a34c ("integrity/powerpc: Support load
On Wed Jun 7, 2023 at 3:28 PM EEST, Nayna wrote:
>
> On 6/6/23 16:51, Jarkko Sakkinen wrote:
> > On Tue Jun 6, 2023 at 8:26 PM EEST, Nayna Jain wrote:
> >> On PowerVM guest, variable data is prefixed with 8 bytes of timestamp.
> >> Extract ESL by stripping off the t
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
; 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
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_
from the TPM Open Firmware driver.
>
> Signed-off-by: Stefan Berger
> Cc: Jarkko Sakkinen
> Cc: Jason Gunthorpe
> Cc: Rob Herring
> Cc: Frank Rowand
> Reviewed-by: Mimi Zohar
> Tested-by: Nageswara R Sastry
> Reviewed-by: Jarkko Sakkinen
> Tested-by: Coiby Xu
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 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
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:
> 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
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
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
&
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
On Mon, Feb 27, 2023 at 06:08:31PM -0500, Stefan Berger wrote:
>
>
> On 2/23/23 22:25, 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 creatin
On Tue, Feb 28, 2023 at 10:21:36PM +1100, Michael Ellerman wrote:
> Jarkko Sakkinen writes:
> > On Mon, Feb 27, 2023 at 06:08:31PM -0500, Stefan Berger wrote:
> >> On 2/23/23 22:25, Michael Ellerman wrote:
> >> > There's code in prom_instantiate_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
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
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:
> 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:
> 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
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 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
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 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 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 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 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 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 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 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
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
. 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
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 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 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
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 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
> > ;
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 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 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 Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > > wrote:
>
On Mon, Sep 28, 2020 at 08:20:18AM +0200, Ard Biesheuvel wrote:
> On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
> wrote:
> >
> >
> >
> > Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrot
rc = -ENODEV;
> dev_err(dev, "CRQ response timed out\n");
> goto init_irq_cleanup;
> }
> --
> 2.17.1
>
Acked-by: Jarkko Sakkinen
This will require reviewed by from someone who knows this driver
better.
BR, Jarkko
On Fri, Mar 18, 2022 at 09:54:46AM -0400, Stefan Berger wrote:
>
>
> On 3/18/22 02:02, Xiu Jianfeng wrote:
> > Currently it returns zero when CRQ response timed out, it should return
> > an error code instead.
> >
> > Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before
> > proc
On Sat, Apr 02, 2022 at 12:29:19PM +0200, Christophe Leroy wrote:
> powerpc's asm/prom.h brings some headers that it doesn't
> need itself.
>
> In order to clean it up, first add missing headers in
> users of asm/prom.h
>
> Signed-off-by: Christophe Leroy
I don't understand this. It changes not
On Tue, Jul 07, 2020 at 11:04:12AM -0700, Randy Dunlap wrote:
> Drop the doubled word "in".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: James Bottomley
> Cc: Jarkko Sakkinen
> Cc: Mimi Zohar
> Cc: linux-
(CONFIG_MODULES=y) in.
Cc: Andi Kleen
Suggested-by: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/arm/kernel/Makefile | 3 +-
arch/arm/kernel/module.c | 21 ---
arch/arm/kernel/text.c | 33 ++
arch/arm64/kernel/Makefile | 2 +-
arch
edded kernels (the former is my use case).
v2:
* Added the missing cover letter.
Jarkko Sakkinen (3):
module: Rename module_alloc() to text_alloc() and move to kernel
proper
module: Add lock_modules() and unlock_modules()
kprobes: Flag out CONFIG_MODULES dependent code
arch/Kc
(CONFIG_MODULES=y) in.
Cc: Andi Kleen
Suggested-by: Peter Zijlstra
Signed-off-by: Jarkko Sakkinen
---
arch/arm/kernel/Makefile | 3 +-
arch/arm/kernel/module.c | 21 ---
arch/arm/kernel/text.c | 33 ++
arch/arm64/kernel/Makefile | 2 +-
arch
On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote:
> > Rename module_alloc() to text_alloc() and module_memfree() to
> > text_memfree(), and move them to kernel/text.c, which is
On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> This patch suggests that there are other reasons why conflating
> allocation of module space and allocating text pages for other uses
> is a bad idea, but switching all users to text_alloc() is a step in
> the wrong direction. It wo
1 - 100 of 179 matches
Mail list logo
