On Tue, 2025-07-01 at 17:51 +0300, Jarkko Sakkinen wrote:
> Repeal and replace tpm_buf_init() and tpm_buf_init_sized() with
> tpm_buf_alloc(), which returns a buffer of memory with the struct
> tpm_buf header at the beginning of the returned buffer. This leaves
> 4090 bytes of free space for the p
[+cc linux-coco]
On Mon, 2025-06-30 at 20:59 +0800, GONG Ruiqi wrote:
[...]
> This patch set provides an implementation of the aforementioned IMA
> RoT framework, which can facilitate easier adaptation for new devices
> such as Intel TDX and Huawei VirtCCA, as well as the classic TPM, to
> be an Ro
On Thu, 2025-06-26 at 13:19 +0300, Jarkko Sakkinen wrote:
> From: Jarkko Sakkinen
>
> Create a cleanup class for struct tpm_buf using DEFINE_CLASS(), which
> will guarantee that the heap allocated memory will be freed
> automatically for the transient instances of this structure, when
> they go o
On Wed, 2025-04-09 at 13:31 +0200, Borislav Petkov wrote:
> On Wed, Apr 09, 2025 at 12:43:01PM +0200, Stefano Garzarella wrote:
> > Sorry, maybe I missed something.
> >
> > tpm_svsm.c registers the driver with
> > module_platform_driver_probe().
> >
> > Someone (the platform I guess) has to regis
On Sun, 2025-03-23 at 15:09 +0100, Nicolai Stange wrote:
> PCR reads aren't currently authenticated even with
> CONFIG_TCG_TPM2_HMAC=y yet.
The reason being TPM2_PCR_Read can only support an audit session, so it
has even more overhead than the usual HMAC session for something you
don't care about
On Mon, 2025-03-31 at 15:23 -0700, Dionna Amalie Glaze wrote:
> On Mon, Mar 31, 2025 at 2:26 PM James Bottomley
> wrote:
> >
> > On Mon, 2025-03-31 at 13:56 -0700, Dionna Amalie Glaze wrote:
> > [...]
> > > I might be unclear on how I should be testing this, but
On Mon, 2025-03-31 at 13:56 -0700, Dionna Amalie Glaze wrote:
[...]
> I might be unclear on how I should be testing this, but I do see
> /dev/tpm0 and /dev/tpmrm0 when I build with CONFIG_TCG_SVSM=y, but I
> don't see the event log in securityfs. What am I missing?
The vtpm driver for EDK2/OVMF I
On Thu, 2025-03-27 at 15:23 +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 27, 2025 at 10:58:00AM +0100, Stefano Garzarella wrote:
[...]
> > > @@ -65,6 +89,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> > > *chip, void *buf, size_t bufsiz)
> > > ssize_t len = 0;
> > > u32 count, ordinal;
>
On Sun, 2025-03-23 at 15:09 +0100, Nicolai Stange wrote:
> Normally IMA would extend a template hash of each bank's associated
> algorithm into a PCR. However, if a bank's hash algorithm is
> unavailable to the kernel at IMA init time, it would fallback to
> extending padded SHA1 hashes instead.
>
On Mon, 2025-03-24 at 21:03 -0400, Mimi Zohar wrote:
> On Sun, 2025-03-23 at 17:18 -0400, James Bottomley wrote:
[...]
> > Instead of any of that, why not do what the TCG tells us to do for
> > unsupported banks and simply cap them with 0x record
> > EV_SEPARATOR and s
On Fri, 2025-03-21 at 15:13 +0800, lee joey wrote:
> Hi Lennart,
>
> Lennart Poettering 於 2025年3月20日 週四 下午8:02寫道：
> >
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> >
> > This original commit this reverts creates a strange situation: it
> > ensures more restrictive behaviou
On Thu, 2025-03-06 at 13:59 -0500, Mimi Zohar wrote:
> On Thu, 2025-03-06 at 15:15 +, Jonathan McDowell wrote:
> > We're seeing a lot of:
> >
> > tpm tpm0: auth session is active
> >
> > messages in our logs. This is emitted (once per boot) by
> > tpm2_start_auth_session() if the auth sessio
On Sun, 2024-12-22 at 17:33 +0200, Jarkko Sakkinen wrote:
> On Sun Dec 22, 2024 at 5:23 PM EET, Jarkko Sakkinen wrote:
> > On Sun Dec 22, 2024 at 5:00 PM EET, James Bottomley wrote:
> > > If event logs grow to greater than KMALLOC_MAX_SIZE then
> > > absolutely it make
On Sat, 2024-12-21 at 22:11 +0200, Jarkko Sakkinen wrote:
> On Sat Dec 21, 2024 at 7:16 PM EET, James Bottomley wrote:
> > On Sat, 2024-12-21 at 17:04 +0100, Ard Biesheuvel wrote:
> > > On Sat, 21 Dec 2024 at 12:33, Jarkko Sakkinen
> > > wrote:
> > > >
>
On Sat, 2024-12-21 at 17:04 +0100, Ard Biesheuvel wrote:
> On Sat, 21 Dec 2024 at 12:33, Jarkko Sakkinen
> wrote:
> >
> > The following failure was reported:
> >
> > [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3,
> > rev-id 0)
> > [ 10.848132][ T1] [ cut here
On Thu, 2024-12-12 at 16:30 +0100, Stefano Garzarella wrote:
> On Thu, Dec 12, 2024 at 09:35:46AM -0500, James Bottomley wrote:
> > On Thu, 2024-12-12 at 10:51 +0100, Stefano Garzarella wrote:
> > > On Tue, Dec 10, 2024 at 03:34:21PM +0100, Stefano Garzarella
> > > wrote
On Thu, 2024-12-12 at 10:51 +0100, Stefano Garzarella wrote:
> On Tue, Dec 10, 2024 at 03:34:21PM +0100, Stefano Garzarella wrote:
[...]
> > +static int tpm_platform_recv(struct tpm_chip *chip, u8 *buf,
> > size_t len)
> > +{
> > + struct tpm_resp *resp = (struct tpm_resp *)buffer;
> > +
> >
On Wed, 2024-12-11 at 10:30 -0600, Tom Lendacky wrote:
> On 12/10/24 08:34, Stefano Garzarella wrote:
[...]
> > +static bool is_svsm_vtpm_send_command_supported(void)
> > +{
> > + struct svsm_call call = {};
> > + u64 send_cmd_mask = 0;
> > + u64 platform_cmds;
> > + u64 fea
On Tue, 2024-12-10 at 10:40 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 10, 2024 at 03:34:23PM +0100, Stefano Garzarella wrote:
>
> > + if (platform_device_add_data(&tpm_device, &pops,
> > sizeof(pops)))
> > + return -ENODEV;
> > + if (platform_dev
On Thu, 2024-11-14 at 00:56 +0100, Christoph Anton Mitterer wrote:
> On Wed, 2024-11-13 at 07:47 -0800, James Bottomley wrote:
> > That could be more significant, especially with this in the log:
> >
> > > Nov 13 12:33:06 heisenberg kernel: tpm tpm0: NULL Seed name
On Wed, 2024-11-13 at 07:47 -0800, James Bottomley wrote:
> On Wed, 2024-11-13 at 15:44 +0100, Christoph Anton Mitterer wrote:
> > Hey.
> >
> > Forwarding myself from:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087331
> >
> > Since 6.11.7 (might
On Wed, 2024-11-13 at 15:44 +0100, Christoph Anton Mitterer wrote:
> Hey.
>
> Forwarding myself from:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087331
>
> Since 6.11.7 (might have also happened with .6, which I've skipped,
> but
> wasn't the case at least in 6.11.5).
>
> I get:
> Nov
On Thu, 2024-11-07 at 00:26 +0200, Jarkko Sakkinen wrote:
> On Tue Oct 15, 2024 at 10:39 PM EEST, Mimi Zohar wrote:
> > The initial TPM2 HMAC session capability added HMAC authentication
> > to each and every TPM communication making the pcr_extend
> > performance abysmal for HW TPMs. Further, the
On Mon, 2024-11-04 at 11:34 -0500, Daniel P. Smith wrote:
[...]
> In case the question comes up from those not familiar, the kexec does
> an GETSEC[SEXIT] which closes off access to Localities 1 and 2, thus
> locking the DRTM PCR values. It brings the CPUs out of SMX mode so
> the target kernel do
On Mon, 2024-11-04 at 07:19 -0500, Daniel P. Smith wrote:
> On 11/4/24 06:55, 'Ard Biesheuvel' via trenchboot-devel wrote:
[...]
> > I was referring specifically to the read-write sysfs node that
> > permits user space to update the default TPM locality. Does it need
> > to be writable? And does it
On Mon, 2024-10-28 at 07:50 +0200, Jarkko Sakkinen wrote:
[...]
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -915,33 +915,37 @@ static int tpm2_parse_start_auth_session(struct
> tpm2_auth *auth,
>
> static int tpm2_load_null(struct tpm_chip *chip, u32 *n
On Wed, 2024-10-02 at 18:03 +0100, Jonathan McDowell wrote:
[...]
> First, I've seen James' post extending the TPM timeouts back in 2018
> (
> https://lore.kernel.org/linux-integrity/1531329074.3260.9.camel@Hansen
> Partnership.com/), which doesn't seem to have been picked up. Was an
> alternative
On Mon, 2024-09-30 at 10:09 -0400, Mimi Zohar wrote:
> On Fri, 2024-09-27 at 10:15 -0400, James Bottomley wrote:
> > On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> > > On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > > > Hi all
> > > &
On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > Hi all
> >
> > when running the benchmark on my new component, the Integrity
> > Digest
> > Cache, I ran into a serious performance issue.
> >
> > The benchmark is extending a TPM
On Wed, 2024-09-25 at 00:35 +0300, Jarkko Sakkinen wrote:
> On Tue Sep 24, 2024 at 9:40 PM EEST, James Bottomley wrote:
> > On Tue, 2024-09-24 at 21:07 +0300, Jarkko Sakkinen wrote:
> > > On Tue Sep 24, 2024 at 4:43 PM EEST, James Bottomley wrote:
> > > > On Sat, 202
On Tue, 2024-09-24 at 21:07 +0300, Jarkko Sakkinen wrote:
> On Tue Sep 24, 2024 at 4:43 PM EEST, James Bottomley wrote:
> > On Sat, 2024-09-21 at 15:08 +0300, Jarkko Sakkinen wrote:
> > > Instead of flushing and reloading the auth session for every
> > > single transac
On Tue, 2024-09-24 at 19:29 +0300, Jarkko Sakkinen wrote:
> On Tue Sep 24, 2024 at 4:48 PM EEST, James Bottomley wrote:
[...]
> > Patch 3 is completely unnecessary: the null key is only used to
> > salt the session and is not required to be resident while the
> > session is us
On Sun, 2024-09-22 at 20:51 +0300, Jarkko Sakkinen wrote:
> On Sat Sep 21, 2024 at 3:08 PM EEST, Jarkko Sakkinen wrote:
> > This patch set aims to fix:
> > https://bugzilla.kernel.org/show_bug.cgi?id=219229.
> >
> > The baseline for the series is the v6.11 tag.
> >
> > v4:
> > https://lore.kernel
33,6 +333,9 @@ void tpm_buf_append_hmac_session(struct tpm_chip
> *chip, struct tpm_buf *buf,
> }
>
> #ifdef CONFIG_TCG_TPM2_HMAC
> + /* The first write to /dev/tpm{rm0} will flush the session.
> */
> + attributes |= TPM2_SA_CONTINUE_SESSION;
> +
> /*
> * The Architecture Guide requires us to strip trailing zeros
> * before computing the HMAC
Code is fine, with the change log update, you can add
Reviewed-by: James Bottomley
;
> tpm_buf_destroy(&buf);
>
> - if (rc)
> - goto out;
> + if (rc == TPM2_RC_SUCCESS) {
> + chip->auth = auth;
> + return 0;
> + }
>
> - out:
> +err:
> + kfree(auth);
> return rc;
> }
> EXPORT_SYMBOL(tpm2_start_auth_session);
> @@ -1371,10 +1382,6 @@ int tpm2_sessions_init(struct tpm_chip *chip)
> if (rc)
> return rc;
>
> - chip->auth = kmalloc(sizeof(*chip->auth), GFP_KERNEL);
> - if (!chip->auth)
> - return -ENOMEM;
> -
> return rc;
> }
> #endif /* CONFIG_TCG_TPM2_HMAC */
Other than the comment above
Reviewed-by: James Bottomley
On Sun, 2024-09-15 at 17:50 +0300, Jarkko Sakkinen wrote:
> On Sun Sep 15, 2024 at 4:59 PM EEST, James Bottomley wrote:
> > On Sun, 2024-09-15 at 13:07 +0300, Jarkko Sakkinen wrote:
> > > On Sun Sep 15, 2024 at 12:43 PM EEST, Jarkko Sakkinen wrote:
> > > > When it c
On Sun, 2024-09-15 at 13:07 +0300, Jarkko Sakkinen wrote:
> On Sun Sep 15, 2024 at 12:43 PM EEST, Jarkko Sakkinen wrote:
> > When it comes to boot we should aim for one single
> > start_auth_session during boot, i.e. different phases would leave
> > that session open so that we don't have to load t
On Thu, 2024-09-12 at 15:36 +0200, Roberto Sassu wrote:
> On Thu, 2024-09-12 at 09:26 -0400, James Bottomley wrote:
> > On Thu, 2024-09-12 at 16:16 +0300, Jarkko Sakkinen wrote:
> > > On Wed Sep 11, 2024 at 3:21 PM EEST, James Bottomley wrote:
> > > > On Wed, 2024
On Thu, 2024-09-12 at 16:16 +0300, Jarkko Sakkinen wrote:
> On Wed Sep 11, 2024 at 3:21 PM EEST, James Bottomley wrote:
> > On Wed, 2024-09-11 at 10:53 +0200, Roberto Sassu wrote:
[...]
> > > I made few measurements. I have a Fedora 38 VM with TPM
> > > passthrough.
>
On Wed, 2024-09-11 at 10:53 +0200, Roberto Sassu wrote:
> On Tue, 2024-09-10 at 16:28 +0300, Jarkko Sakkinen wrote:
> > On Tue Sep 10, 2024 at 3:57 PM EEST, James Bottomley wrote:
> > > On Tue, 2024-09-10 at 15:48 +0300, Jarkko Sakkinen wrote:
> > > > On Tue Sep 10
On Tue, 2024-09-10 at 15:48 +0300, Jarkko Sakkinen wrote:
> On Tue Sep 10, 2024 at 3:39 PM EEST, Jarkko Sakkinen wrote:
> > On Tue Sep 10, 2024 at 12:05 PM EEST, Roberto Sassu wrote:
> > > On Tue, 2024-09-10 at 11:01 +0200, Linux regression tracking
> > > (Thorsten
> > > Leemhuis) wrote:
> > > > Hi
On Tue, 2024-09-10 at 11:01 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker.
>
> James, Jarkoo, I noticed a report about a regression in
> bugzilla.kernel.org that appears to be caused by this change of
> yours:
>
> 6519fea6fd
On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> Hi all
>
> when running the benchmark on my new component, the Integrity Digest
> Cache, I ran into a serious performance issue.
>
> The benchmark is extending a TPM PCR with 12313 entries of the IMA
> measurement list, and calculating the
On Mon, 2024-08-05 at 00:28 +0300, Jarkko Sakkinen wrote:
[...]
> > --- a/src/include/intel-tss.h
> > +++ b/src/include/intel-tss.h
> > @@ -251,14 +251,6 @@ intel_sess_helper(TSS_CONTEXT *tssContext,
> > TPM_HANDLE auth, TPMA_SESSION flags)
> > TPMA_SESSION_CONTINU
On Sun, 2024-08-04 at 09:42 -0400, James Bottomley wrote:
> The design of the intel-tss shim is to hide the difference between
> the
> internal and the external handles by doing the internal to external
> transform on entry. Unfortunately, the NULL handle (TPM_RH_NULL,
> 40
a handle number.
Signed-off-by: James Bottomley
---
v2: reword commit message
---
src/include/intel-tss.h | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/src/include/intel-tss.h b/src/include/intel-tss.h
index 1870b4e..5b8db20 100644
--- a/src/include/in
On Sat, 2024-08-03 at 22:31 +0300, Jarkko Sakkinen wrote:
> On Sat Aug 3, 2024 at 8:51 PM EEST, James Bottomley wrote:
> > On Sat, 2024-08-03 at 20:08 +0300, Jarkko Sakkinen wrote:
> > > On Fri Aug 2, 2024 at 11:25 PM EEST, James Bottomley wrote:
> > > > Now that we
On Sat, 2024-08-03 at 20:08 +0300, Jarkko Sakkinen wrote:
> On Fri Aug 2, 2024 at 11:25 PM EEST, James Bottomley wrote:
> > Now that we're going to be using the NULL primary to salt sessions,
> > the Intel TSS shim needs fixing to cope with this. In the Intel
> > T
Signed-off-by: James Bottomley
---
tests/attestation.sh | 30 ++
tests/check_importable.sh | 3 +--
tests/engine/Makefile.am | 3 ++-
tests/provider/Makefile.am | 3 ++-
tests/seal_unseal.sh | 3 +--
tests/start_sw_tpm.sh | 2 ++
6 files
Signed-off-by: James Bottomley
---
src/tools/Makefile.am | 5 +-
src/tools/attest_tpm2_primary.1.in | 103 +
2 files changed, 106 insertions(+), 2 deletions(-)
create mode 100644 src/tools/attest_tpm2_primary.1.in
diff --git a/src/tools/Makefile.am b
new file mode 100644
index 000..cb252fe
--- /dev/null
+++ b/src/tools/attest_tpm2_primary.c
@@ -0,0 +1,842 @@
+/*
+ *
+ * Copyright (C) 2024 James Bottomley
+ *
+ * SPDX-License-Identifier: LGPL-2.1-only
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
Although for usual operation we only need the standard template to
create the keys, for EK operations we need to create the EK from the
exact EK template (of which there are a few), so add a new function to
allow the creation of a primary from any given template.
Signed-off-by: James Bottomley
tpm2_Certify is used to verify that a given object is resident in the
TPM. tpm2_ActivateCredential is used to decrypt a challenge from a
privacyCA and constructing the high template for the EK to use with
this requires PolicyOR.
Signed-off-by: James Bottomley
---
src/include/ibm-tss.h | 84
Signed-off-by: James Bottomley
---
src/include/tpm2-common.h | 5 +
src/libcommon/tpm2-common.c | 16
2 files changed, 21 insertions(+)
diff --git a/src/include/tpm2-common.h b/src/include/tpm2-common.h
index 97b60f2..0e0f28a 100644
--- a/src/include/tpm2-common.h
+++ b
e the signing key template to tpm2_load_srk().
Signed-off-by: James Bottomley
---
src/include/tpm2-common.h | 1 +
src/libcommon/tpm2-common.c | 23 ++-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/include/tpm2-common.h b/src/include/tpm2-common.h
does mean no value. However, for the NULL primary
handle we must use ESYS_TR_RH_NULL, so check for that specific case
and fix it. Additionally remove the intel_handle() code which was
supposed to do this: it's unused because 0 is never passed in as a
handle number.
Signed-off-by: James
fication succeeds. If the
certification fails, all TPM functions should be considered
compromised. Whether boot should continue even with a compromised TPM
is a user policy decision.
James
---
James Bottomley (8):
tss: Fix handling of TPM_RH_NULL in intel-tss
libcommon: add ability to
On Thu, 2024-07-18 at 14:24 +0200, Mickaël Salaün wrote:
> On Wed, Jul 17, 2024 at 07:08:17PM -0700, Jeff Xu wrote:
> > On Wed, Jul 17, 2024 at 3:01 AM Mickaël Salaün
> > wrote:
> > > On Tue, Jul 16, 2024 at 11:33:55PM -0700, Jeff Xu wrote:
[...]
> > > > I'm still thinking execveat(AT_CHECK) vs f
On Tue, 2024-07-16 at 17:07 +0300, Jarkko Sakkinen wrote:
> On Tue Jul 16, 2024 at 2:53 PM EEST, Jarkko Sakkinen wrote:
> > > - u8 name[AUTH_MAX_NAMES][2 + SHA512_DIGEST_SIZE];
> > > + u8 name[AUTH_MAX_NAMES][2 + HASH_MAX_DIGESTSIZE];
>
> Ouch, we definitely do not want 2-dimensional a
On Tue, 2024-07-16 at 21:52 +0300, Jarkko Sakkinen wrote:
[...]
> Further, 'handles' was incorrectly place to struct tpm_buf, as tpm-
> buf.c does manage its state. It is easy to grep that only piece of
> code that actually uses the field is tpm2-sessions.c.
>
> Address the issues by moving the va
On Tue, 2024-07-16 at 17:57 +0200, Roberto Sassu wrote:
> But the Clip OS 4 patch does not cover the redirection case:
>
> # ./bash < /root/test.sh
> Hello World
>
> Do you have a more recent patch for that?
How far down the rabbit hole do you want to go? You can't forbid a
shell from executing
On Mon, 2024-07-15 at 14:25 +0300, Jarkko Sakkinen wrote:
> On Tue Jul 9, 2024 at 5:33 AM EEST, Hao Ge wrote:
> > From: Hao Ge
> >
> > We shouldn't dereference "auth" until after we have checked that it
> > is
> > non-NULL.
> >
> > Fixes: 7ca110f2679b ("tpm: Address !chip->auth in
> > tpm_buf_ap
On Thu, 2024-07-04 at 10:07 -0700, Linus Torvalds wrote:
> On Wed, 3 Jul 2024 at 13:11, James Bottomley
> wrote:
> >
> > if (__and(IS_ENABLED(CONFIG_TCG_TPM2_HMAC), chip->auth))
>
> Augh. Please don't do this.
>
> That "__and()" thing may w
On Wed, 2024-07-03 at 21:24 +0300, Jarkko Sakkinen wrote:
[...]
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 21a67dc9efe8..2844fea4a12a 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -211,8 +211,8 @@ struct tpm_chip {
> u8 null_key_name[TPM2_NAME_SIZ
On Fri, 2024-06-28 at 10:54 +1000, Michael Ellerman wrote:
> Stefan Berger writes:
> > 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
> > [
On Mon, 2024-06-17 at 15:56 -0400, Stefan Berger wrote:
>
>
> On 6/17/24 15:42, James Bottomley wrote:
> > 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
> > > t
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
On Tue, 2024-05-28 at 02:17 +0300, Jarkko Sakkinen wrote:
> On Tue May 28, 2024 at 12:36 AM EEST, James Bottomley wrote:
> > On Mon, 2024-05-27 at 22:53 +0300, Jarkko Sakkinen wrote:
> > > On Mon May 27, 2024 at 8:57 PM EEST, James Bottomley wrote:
> > > > On Mon, 202
On Mon, 2024-05-27 at 22:53 +0300, Jarkko Sakkinen wrote:
> On Mon May 27, 2024 at 8:57 PM EEST, James Bottomley wrote:
> > On Mon, 2024-05-27 at 18:34 +0300, Jarkko Sakkinen wrote:
[...]
> > > While looking at code I started to wanted what was the reasoning
> > &g
On Mon, 2024-05-27 at 18:34 +0300, Jarkko Sakkinen wrote:
> On Mon May 27, 2024 at 6:12 PM EEST, Jarkko Sakkinen wrote:
> > On Mon May 27, 2024 at 6:01 PM EEST, Jarkko Sakkinen wrote:
> > > On Mon May 27, 2024 at 5:51 PM EEST, Jarkko Sakkinen wrote:
> > > > On Thu May 23, 2024 at 10:59 AM EEST, Vit
On Sat, 2024-05-25 at 15:36 +0300, Jarkko Sakkinen wrote:
> tpm2_load_cmd incorrectly checks options->keyhandle also for the
> legacy format, as also implied by the inline comment. Check
> options->keyhandle when ASN.1 is loaded.
No that's not right. keyhandle must be specified for the old format
On Fri, 2024-05-24 at 16:34 +0300, Jarkko Sakkinen wrote:
> On Fri May 24, 2024 at 3:59 PM EEST, James Bottomley wrote:
[...]
> > diff --git a/include/linux/oid_registry.h
> > b/include/linux/oid_registry.h
> > index 51421fdbb0ba..87a6bcb2f5c0 100644
> > --- a/i
available signed policies
in first to last order and loads the key when one of them succeeds.
This code allows the kernel to process signed policy keys correctly,
it does not allow the kernel to create them.
Signed-off-by: James Bottomley
---
drivers/char/tpm/tpm2-sessions.c | 6
t offset 8 in the timer structure,
and the <= comparision operand is 9, so a policy set to expire after the
TPM has been up for 100 seconds would look like
016d000f42480009
Where 0x16d is the counter timer policy code and 0xf4240 is 100 000 in
hex.
Signed-off-by: Ja
like this, most require special
handling which must be added to the kernel policy construction
routine.
Signed-off-by: James Bottomley
---
.../security/keys/trusted-encrypted.rst | 17 +-
security/keys/trusted-keys/tpm2-policy.c | 53 +++
security/keys/trusted-keys/tpm
1
pcrinfo=000b030166687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925"
@u
Signed-off-by: James Bottomley
---
.../security/keys/trusted-encrypted.rst | 53 ++-
include/keys/trusted-type.h | 5 +-
include/linux/tpm.h | 16 +
ixed sha256 one. Note that while this
affects most of the code, the KDFe algorithm still uses a fixed sha256
algorithm because it is define to follow the name algorithm of the
salt encryption key (which is a key we derive from the null seed and
set its name algorithm to sha256).
Signed-off-by:
a single consolidated place in tpm.h so the
policy code can use it as is.
Signed-off-by: James Bottomley
---
drivers/char/tpm/tpm2-cmd.c | 8
include/linux/tpm.h | 52 ++-
security/keys/trusted-keys/trusted_tpm2.c | 20 +
3
patches add specific policy statement
implementations.
James
---
James Bottomley (6):
tpm: consolidate TPM to crypto hash algorithm conversion
tpm: add policy sessions
KEYS: trusted: add PCR policy to TPM2 keys
KEYS: trusted: add ability to specify arbitrary policy
KEYS: trusted: implement
This has been replaced by encode_OID from the OID_registry. To use,
consumers must make sure the OID is present in enum OID in
oid_registry.h and then use encode_OID with the enum.
Signed-off-by: James Bottomley
---
include/linux/asn1_encoder.h | 3 --
lib/asn1_encoder.c | 91
The new routine takes the OID enum instead of needing the u32 OID
array explicitly which reduces duplication and the potential for
mistakes.
Signed-off-by: James Bottomley
---
security/keys/trusted-keys/trusted_tpm2.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a
encoding. This is easy because the OID registry
table already has the binary encoded form for comparison.
Signed-off-by: James Bottomley
---
include/linux/oid_registry.h | 1 +
lib/oid_registry.c | 29 +
2 files changed, 30 insertions(+)
diff --git a/include
The relacement removes the requirement for consumers to maintain free
form OIDs in their code and instead requires all OIDs encoded to be in
the linux OID registry.
Note patch 2/3 needs fixing up for the tpm2_key_encode memory leak fix.
James
---
James Bottomley (3):
lib/oid_registry: add
On Wed, 2024-05-22 at 17:11 +0300, Jarkko Sakkinen wrote:
> For tpm_crb we should actually disable HMAC at some point. It is
> essentially a performance regression for it.
You'd think that, because of the shared buffer and no bus, but you
never quite know. For instance several confidential comput
On Wed, 2024-05-22 at 09:18 +0100, Vitor Soares wrote:
> On Tue, 2024-05-21 at 08:33 -0400, James Bottomley wrote:
> > On Tue, 2024-05-21 at 10:10 +0300, Jarkko Sakkinen wrote:
> > > This benchmark could be done in user space using /dev/tpm0.
> >
> > Let's
On Tue, 2024-05-21 at 17:35 +0300, Jarkko Sakkinen wrote:
> On Tue May 21, 2024 at 5:26 PM EEST, Jarkko Sakkinen wrote:
> > On Tue May 21, 2024 at 5:13 PM EEST, James Bottomley wrote:
> > > On Tue, 2024-05-21 at 17:02 +0300, Jarkko Sakkinen wrote:
> > > > Secondly, it
On Tue, 2024-05-21 at 17:02 +0300, Jarkko Sakkinen wrote:
> Secondly, it also roots to the null key if a parent is not given. So
> it covers all the basic features of the HMAC patch set.
I don't think that can work. The key file would be wrapped to the
parent and the null seed (and hence the wrap
if not default on a particular arch.
>
> Cc: James Bottomley
> Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation")
> Closes:
> https://lore.kernel.org/linux-integrity/d1fcapjsylts.r9vc1cxdc...@kernel.org/
> Signed-off-by: Jarkko Sakkinen
> ---
> drivers/cha
On Tue, 2024-05-21 at 10:10 +0300, Jarkko Sakkinen wrote:
> This benchmark could be done in user space using /dev/tpm0.
Let's actually try that. If you have the ibmtss installed, the command
to time primary key generation from userspace on your tpm is
time tsscreateprimary -hi n -ecc nistp256
On Sat, 2024-05-18 at 14:34 +0300, Jarkko Sakkinen wrote:
> Causes performance drop in initialization so needs to be opt-in.
> Distributors are capable of opt-in enabling this. Could be also
> handled by kernel-command line in the future.
>
> Reported-by: Vitor Soares
> Closes:
> https://lore.ker
On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
> On Mon, Apr 29, 2024 at 04:28:07PM -0400, James Bottomley wrote:
> > If some entity is snooping the TPM bus, they can see the random
> > numbers we're extracting from the TPM and do prediction attacks
> &g
On Tue, 2024-05-14 at 16:38 +0100, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 4:30 PM James Bottomley
> wrote:
> >
> > On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> > > * if someone steals one of the disks - we don't want them to
> >
On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> * if someone steals one of the disks - we don't want them to see it
> has encrypted data (no LUKS header)
What is the use case that makes this important? In usual operation
over the network, the fact that we're setting up encryption is
On Tue, 2024-05-14 at 10:50 +0100, Ignat Korchagin wrote:
> On Mon, May 13, 2024 at 11:33 PM James Bottomley
> wrote:
> >
> > On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
> > [...]
> > > TPM derived keys attempt to address the above use cases
On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
[...]
> TPM derived keys attempt to address the above use cases by allowing
> applications to deterministically derive unique cryptographic keys
> for their own purposes directly from the TPM seed in the owner
> hierarchy. The idea is that w
On Mon, 2024-05-13 at 12:16 +0200, Samuel Ortiz wrote:
> On Fri, May 10, 2024 at 10:57:37PM -0400, James Bottomley wrote:
> > I'm not really sure where to hang this, since there's no posted
> > agenda
> > or materials for the CCC meeting today.
>
> The agen
I'm not really sure where to hang this, since there's no posted agenda
or materials for the CCC meeting today. I'm afraid I also don't have a
copy of the presentation to point people who weren't at the meeting to.
However, it struck me you missed a third option: use the ima log
format. This has t
On Wed, 2024-05-01 at 00:48 +0300, Jarkko Sakkinen wrote:
> On Tue Apr 30, 2024 at 10:23 PM EEST, James Bottomley wrote:
> > On Tue, 2024-04-30 at 01:22 +0300, Jarkko Sakkinen wrote:
[...]
> > > Since I could not find the email subthread I neither have the
> > > patch n
On Tue, 2024-04-30 at 01:22 +0300, Jarkko Sakkinen wrote:
> On Mon Apr 29, 2024 at 11:27 PM EEST, James Bottomley wrote:
> > The interest in securing the TPM against interposers, both active
> > and
> > passive has risen to fever pitch with the demonstration of key
> &g
because it is likely to have suffered a reset
attack.
Signed-off-by: James Bottomley
---
drivers/char/tpm/tpm-chip.c | 3 ++
drivers/char/tpm/tpm2-sessions.c | 77 +---
drivers/char/tpm/tpm2-space.c| 3 ++
include/linux/tpm.h | 4 +-
4 files changed
1 - 100 of 216 matches
Mail list logo
