This change disables the TCG_TPM2_HMAC feature by default to resolve
some driver initialization failures (with certain TPMs) and performance
regressions (with all TPMs). See "Security remarks" below for why this
does not meaningfully downgrade security.

When the TCG_TPM2_HMAC feature fails to initialize the "null key" (see
tpm-security.rst), it will cause tpm_tis_core_init to bail out early and
skip device registration, causing all userspace requests to /dev/tpm0 to
return ENODEV ("No such device").

TCG_TPM2_HMAC depends on the following being implemented in the TPM:

- TPM_RH_NULL
- TPM2_CreatePrimary
- TPM2_ContextSave
- ECDH-P256
- AES-128-CFB

While the majority of TPMs in the ecosystem conform to the PC Client
Platform TPM Profile, which currently mandates most of these, not all
versions of that profile did, and not all other TPM profiles (e.g.,
Mobile, Automotive, Server) will. The TPM 2.0 specification itself is a
"Library" specification and does not mandate any particular commands
(and very few features) in order to maximize flexibility for
implementors.

The TPM driver should not break userspace for a TPM that conforms to an
atypical profile, therefore this change makes TCG_TPM2_HMAC disabled by
default. It also adds a remark about what will happen if this feature is
enabled and used with a non-supporting TPM to the Kconfig.

Some real-world public examples of problems posed by this feature:

TPMs that do not support the feature result in broken userspace starting
from 6.10:

https://wiki.archlinux.org/title/Trusted_Platform_Module\

Significant (around 200%) boot up latency due to all the added TPM
private key operations:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2080322

Security remarks:

tpm-security.rst describes the threat model of the TPM2_HMAC feature,
wherein an active interposer adversary on the TPM (e.g., SPI) bus
tampers with TPM commands and/or responses to interfere with the booting
or running system. The TPM2_HMAC feature uses something called "salted
sessions" to establish per-request keys that can be used to protect TPM
traffic.

Because the kernel does not have a priori knowledge of a cryptographic
identity for the correct TPM for the system, and because the kernel does
not have any cryptographic identity of its own with which to
authenticate itself to the TPM, the session is established using a
one-sided, unauthenticated key establishment protocol, wherein the
kernel asks the TPM for the so-called "null key" and uses it to
establish the shared session secret.

This poses a serious problem for the threat model of the TCG_TPM2_HMAC
feature, which it resolves by asserting that userspace will attest to
the "null key" using the EK after boot and compare it to the contents of
/sys/class/tpm/tpm0/null_name, exposed by the TPM driver. However, this
creates a trust cycle: we do not trust userspace to perform this action
correctly, because we do not trust that kernel correctly measured
userspace, because nobody has checked the null key yet. An implicitly
trusted remote attestation verifier also cannot be relied upon to do
this check, because it has no way of knowing for certain which key the
kernel actually used to establish the TPM sessions during the boot.

This should probably be discussed in tpm-security.rst in the future.

Signed-off-by: Chris Fenner <cfenn@google.com>
---
 drivers/char/tpm/Kconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index dddd702b2454..ad419ca97b8d 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -29,7 +29,7 @@ if TCG_TPM
 
 config TCG_TPM2_HMAC
 	bool "Use HMAC and encrypted transactions on the TPM bus"
-	default X86_64
+	default n
 	select CRYPTO_ECDH
 	select CRYPTO_LIB_AESCFB
 	select CRYPTO_LIB_SHA256
@@ -39,7 +39,10 @@ config TCG_TPM2_HMAC
 	  communicating with the TPM to prevent or detect bus snooping
 	  and interposer attacks (see tpm-security.rst).  Saying Y
 	  here adds some encryption overhead to all kernel to TPM
-	  transactions.
+	  transactions.  If the TPM does not implement a command or
+	  algorithm required by the feature, it will not be registered
+	  during initialization, and userspace will fail to open the
+	  TPM with ENODEV.
 
 config HW_RANDOM_TPM
 	bool "TPM HW Random Number Generator support"
-- 
2.51.0.rc0.215.g125493bb4a-goog

On Thu, Aug 14, 2025 at 09:22:52AM -0700, Chris Fenner wrote:
> This change disables the TCG_TPM2_HMAC feature by default to resolve
> some driver initialization failures (with certain TPMs) and performance
> regressions (with all TPMs). See "Security remarks" below for why this
> does not meaningfully downgrade security.
> 
> When the TCG_TPM2_HMAC feature fails to initialize the "null key" (see
> tpm-security.rst), it will cause tpm_tis_core_init to bail out early and
> skip device registration, causing all userspace requests to /dev/tpm0 to
> return ENODEV ("No such device").
> 
> TCG_TPM2_HMAC depends on the following being implemented in the TPM:
> 
> - TPM_RH_NULL
> - TPM2_CreatePrimary
> - TPM2_ContextSave
> - ECDH-P256
> - AES-128-CFB
> 
> While the majority of TPMs in the ecosystem conform to the PC Client
> Platform TPM Profile, which currently mandates most of these, not all
> versions of that profile did, and not all other TPM profiles (e.g.,
> Mobile, Automotive, Server) will. The TPM 2.0 specification itself is a
> "Library" specification and does not mandate any particular commands
> (and very few features) in order to maximize flexibility for
> implementors.
> 
> The TPM driver should not break userspace for a TPM that conforms to an
> atypical profile, therefore this change makes TCG_TPM2_HMAC disabled by
> default. It also adds a remark about what will happen if this feature is
> enabled and used with a non-supporting TPM to the Kconfig.
> 
> Some real-world public examples of problems posed by this feature:
> 
> TPMs that do not support the feature result in broken userspace starting
> from 6.10:
> 
> https://wiki.archlinux.org/title/Trusted_Platform_Module\
> 
> Significant (around 200%) boot up latency due to all the added TPM
> private key operations:
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2080322
> 
> Security remarks:
> 
> tpm-security.rst describes the threat model of the TPM2_HMAC feature,
> wherein an active interposer adversary on the TPM (e.g., SPI) bus
> tampers with TPM commands and/or responses to interfere with the booting
> or running system. The TPM2_HMAC feature uses something called "salted
> sessions" to establish per-request keys that can be used to protect TPM
> traffic.
> 
> Because the kernel does not have a priori knowledge of a cryptographic
> identity for the correct TPM for the system, and because the kernel does
> not have any cryptographic identity of its own with which to
> authenticate itself to the TPM, the session is established using a
> one-sided, unauthenticated key establishment protocol, wherein the
> kernel asks the TPM for the so-called "null key" and uses it to
> establish the shared session secret.
> 
> This poses a serious problem for the threat model of the TCG_TPM2_HMAC
> feature, which it resolves by asserting that userspace will attest to
> the "null key" using the EK after boot and compare it to the contents of
> /sys/class/tpm/tpm0/null_name, exposed by the TPM driver. However, this
> creates a trust cycle: we do not trust userspace to perform this action
> correctly, because we do not trust that kernel correctly measured
> userspace, because nobody has checked the null key yet. An implicitly
> trusted remote attestation verifier also cannot be relied upon to do
> this check, because it has no way of knowing for certain which key the
> kernel actually used to establish the TPM sessions during the boot.

All we care here is actually the external verifier scenario because most
of this type of crypto where software must attest breaks without that,
including all confidential computing technologies.

It's true that in the current form the whole feature is at most defense
in depth. It could be e.g. extended with persistent keys and productized
more in the future (e.g., trusted keys were mostly useless for multiple
years).

I'd personally would like to keep it on at least on my own laptop and
there's a risk that there's a group of people who would either:

1. want to have that small amount defense in depth.
2. want to refine the feature.

It's by practical means already "relaxed" but outcomes are objectively
plain wrong (as you stated) so I'd take a bit more conservative approach
on changing the mainline and propose three state option:

1. off: fully turn off
2. relaxed: mark just a info or at most marning to klog that hmac
   encryption is not enable. Keep timeout short as ECC generation
   does not take long (if it is working) (at least according to
   my tests). It should also address the lack of TPM2_ContextSave.
   We really should probe that anyhow in the driver init and
   disable also /dev/tpmrm0 accordingly.
3. strict: enforce. This is good to have albeit now not really
   useful

The 'relaxed' is of course default.

BR, Jarkko

Thanks Jarkko,

By the way, I noticed you and James (in your earlier version of this
patch from 2024, see [1]) both characterized the TCG_TPM2_HMAC feature
as being cheap or free, since ECC primary key generation is pretty
fast (few hundred ms depending on the TPM). I think this analysis
might be missing some of the hidden costs of the feature. Under the
hood, it looks to me like the kernel is doing an ECDH session
establishment with the TPM on _each_ PCR extension (see the call to
tpm2_start_auth_session inside tpm2_pcr_extend). Each ECDH handshake
means the TPM is performing an ECC private key operation, which is
significantly slower than the PCR extension itself. On top of that,
you have the overhead of shuffling the context around.

To illustrate some of the hidden costs of the TCG_TPM2_HMAC solution
(and perhaps explain why people are complaining about severe boot time
impact), I created a small tool at [2] that you can use to profile
salted session PCR extension on any TPM.

I have a Linux machine with a standard off-the-shelf Infineon SLB9670
TPM. Without the session salting, each PCR extension takes just 4-5
ms. With session salting, it takes:
* 30ms to load the null key from its context blob
* 108ms to start the auth session and extend the PCR inside it
* 1ms to flush the null key

for an overhead of about 2880%. Depending on the configuration of the
kernel/IMA and how many PCR measurements it's making, this could add
up to a good chunk of time and explain reports like [3] where people
are noting that turning this feature on adds minutes to or triples the
boot time.

Personally, I would recommend disabling the feature by default until
someone finds the time to fix it (perhaps as you described, with a
tri-state; perhaps the performance characteristics can be improved as
well). I am personally skeptical of any defense-in-depth benefits
since it is not hard for the interposer attacker to also interpose the
session salting, but everyone's threat model varies.

Since the feature breaks userspace (for atypical TPM hardware), slows
down boot (for all TPM hardware), and has unclear security value,
Google has already disabled the feature in our Kconfigs. I sent this
patch in case it can help save others some trouble. Understood if
that's not the way the team would prefer to go with this.

[1] https://lore.kernel.org/linux-integrity/aJ8iNLwlf4PAC0h1@kernel.org/T/#t
[2] https://github.com/chrisfenner/salty
[3] https://lore.kernel.org/linux-integrity/bf67346ef623ff3c452c4f968b7d900911e250c3.camel@gmail.com/#t

Thanks
Chris


On Fri, Aug 15, 2025 at 5:04 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Thu, Aug 14, 2025 at 09:22:52AM -0700, Chris Fenner wrote:
> > This change disables the TCG_TPM2_HMAC feature by default to resolve
> > some driver initialization failures (with certain TPMs) and performance
> > regressions (with all TPMs). See "Security remarks" below for why this
> > does not meaningfully downgrade security.
> >
> > When the TCG_TPM2_HMAC feature fails to initialize the "null key" (see
> > tpm-security.rst), it will cause tpm_tis_core_init to bail out early and
> > skip device registration, causing all userspace requests to /dev/tpm0 to
> > return ENODEV ("No such device").
> >
> > TCG_TPM2_HMAC depends on the following being implemented in the TPM:
> >
> > - TPM_RH_NULL
> > - TPM2_CreatePrimary
> > - TPM2_ContextSave
> > - ECDH-P256
> > - AES-128-CFB
> >
> > While the majority of TPMs in the ecosystem conform to the PC Client
> > Platform TPM Profile, which currently mandates most of these, not all
> > versions of that profile did, and not all other TPM profiles (e.g.,
> > Mobile, Automotive, Server) will. The TPM 2.0 specification itself is a
> > "Library" specification and does not mandate any particular commands
> > (and very few features) in order to maximize flexibility for
> > implementors.
> >
> > The TPM driver should not break userspace for a TPM that conforms to an
> > atypical profile, therefore this change makes TCG_TPM2_HMAC disabled by
> > default. It also adds a remark about what will happen if this feature is
> > enabled and used with a non-supporting TPM to the Kconfig.
> >
> > Some real-world public examples of problems posed by this feature:
> >
> > TPMs that do not support the feature result in broken userspace starting
> > from 6.10:
> >
> > https://wiki.archlinux.org/title/Trusted_Platform_Module\
> >
> > Significant (around 200%) boot up latency due to all the added TPM
> > private key operations:
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2080322
> >
> > Security remarks:
> >
> > tpm-security.rst describes the threat model of the TPM2_HMAC feature,
> > wherein an active interposer adversary on the TPM (e.g., SPI) bus
> > tampers with TPM commands and/or responses to interfere with the booting
> > or running system. The TPM2_HMAC feature uses something called "salted
> > sessions" to establish per-request keys that can be used to protect TPM
> > traffic.
> >
> > Because the kernel does not have a priori knowledge of a cryptographic
> > identity for the correct TPM for the system, and because the kernel does
> > not have any cryptographic identity of its own with which to
> > authenticate itself to the TPM, the session is established using a
> > one-sided, unauthenticated key establishment protocol, wherein the
> > kernel asks the TPM for the so-called "null key" and uses it to
> > establish the shared session secret.
> >
> > This poses a serious problem for the threat model of the TCG_TPM2_HMAC
> > feature, which it resolves by asserting that userspace will attest to
> > the "null key" using the EK after boot and compare it to the contents of
> > /sys/class/tpm/tpm0/null_name, exposed by the TPM driver. However, this
> > creates a trust cycle: we do not trust userspace to perform this action
> > correctly, because we do not trust that kernel correctly measured
> > userspace, because nobody has checked the null key yet. An implicitly
> > trusted remote attestation verifier also cannot be relied upon to do
> > this check, because it has no way of knowing for certain which key the
> > kernel actually used to establish the TPM sessions during the boot.
>
> All we care here is actually the external verifier scenario because most
> of this type of crypto where software must attest breaks without that,
> including all confidential computing technologies.
>
> It's true that in the current form the whole feature is at most defense
> in depth. It could be e.g. extended with persistent keys and productized
> more in the future (e.g., trusted keys were mostly useless for multiple
> years).
>
> I'd personally would like to keep it on at least on my own laptop and
> there's a risk that there's a group of people who would either:
>
> 1. want to have that small amount defense in depth.
> 2. want to refine the feature.
>
> It's by practical means already "relaxed" but outcomes are objectively
> plain wrong (as you stated) so I'd take a bit more conservative approach
> on changing the mainline and propose three state option:
>
> 1. off: fully turn off
> 2. relaxed: mark just a info or at most marning to klog that hmac
>    encryption is not enable. Keep timeout short as ECC generation
>    does not take long (if it is working) (at least according to
>    my tests). It should also address the lack of TPM2_ContextSave.
>    We really should probe that anyhow in the driver init and
>    disable also /dev/tpmrm0 accordingly.
> 3. strict: enforce. This is good to have albeit now not really
>    useful
>
> The 'relaxed' is of course default.
>
> BR, Jarkko
>
>

On Fri, Aug 15, 2025 at 08:45:06AM -0700, Chris Fenner wrote:
> I have a Linux machine with a standard off-the-shelf Infineon SLB9670
> TPM. Without the session salting, each PCR extension takes just 4-5
> ms. With session salting, it takes:
> * 30ms to load the null key from its context blob
> * 108ms to start the auth session and extend the PCR inside it
> * 1ms to flush the null key
> 
> for an overhead of about 2880%. Depending on the configuration of the
> kernel/IMA and how many PCR measurements it's making, this could add
> up to a good chunk of time and explain reports like [3] where people
> are noting that turning this feature on adds minutes to or triples the
> boot time.

I'll with shoot another proposal. Let's delete null primary creation
code and add a parameter 'tpm.integrity_handle', which will refers to
persistent primary handle:

1. It simplifies the code considerably.
2. It makes whole a lot more sense especially given that there's
   ambiguity with the key. This comes from earlier off-list
   discussion where you made this argument, and I'll buy that.
   I.e. even if we could certify null primary we cannot certify
   it is "unambiguousness".
3. Update tpm-security documentation accordingly.

I think this might be "the long-term fix" that could be done right noW.

BR, Jarkko

On Fri, Aug 15, 2025 at 9:27 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:

> I'll with shoot another proposal. Let's delete null primary creation
> code and add a parameter 'tpm.integrity_handle', which will refers to
> persistent primary handle:

I'm not yet sure I understand which handle you mean, or what you're
proposing to do with it. Could you elaborate?

Thanks
Chris

On Fri, Aug 15, 2025 at 10:06:36AM -0700, Chris Fenner wrote:
> On Fri, Aug 15, 2025 at 9:27 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:
> 
> > I'll with shoot another proposal. Let's delete null primary creation
> > code and add a parameter 'tpm.integrity_handle', which will refers to
> > persistent primary handle:
> 
> I'm not yet sure I understand which handle you mean, or what you're
> proposing to do with it. Could you elaborate?

Primary key persistent handle.

In tpm2_start_auth_session() there's

	/* salt key handle */
	tpm_buf_append_u32(&buf, null_key);

Which would become

	/* salt key handle */
	tpm_buf_append_u32(&buf, integrity_handle);

And in beginning of exported functions from tpm2-sessions.c:

	if (!integrity_handle)
		return 0;

And delete from same file:

	1. tpm2_create_*()
	2. tpm2_load_null()

That way the feature makes sense and does not disturb the user who don't
want it as PCRs and random numbers will be integrity proteced agains an
unambiguous key that can be certified.

> 
> Thanks
> Chris

BR, Jarkko

On Fri, Aug 15, 2025 at 08:45:48PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 15, 2025 at 10:06:36AM -0700, Chris Fenner wrote:
> > On Fri, Aug 15, 2025 at 9:27 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:
> > 
> > > I'll with shoot another proposal. Let's delete null primary creation
> > > code and add a parameter 'tpm.integrity_handle', which will refers to
> > > persistent primary handle:
> > 
> > I'm not yet sure I understand which handle you mean, or what you're
> > proposing to do with it. Could you elaborate?
> 
> Primary key persistent handle.
> 
> In tpm2_start_auth_session() there's
> 
> 	/* salt key handle */
> 	tpm_buf_append_u32(&buf, null_key);
> 
> Which would become
> 
> 	/* salt key handle */
> 	tpm_buf_append_u32(&buf, integrity_handle);
> 
> And in beginning of exported functions from tpm2-sessions.c:
> 
> 	if (!integrity_handle)
> 		return 0;
> 
> And delete from same file:
> 
> 	1. tpm2_create_*()
> 	2. tpm2_load_null()
> 
> That way the feature makes sense and does not disturb the user who don't
> want it as PCRs and random numbers will be integrity proteced agains an
> unambiguous key that can be certified.

E.g., for example that will unquestionably harden IMA exactly for the
same reasons why some user space software might to choose to use HMAC
based integrity protection.

At data center, there's guards and guns but for appliences, but there
is also the market appliances, home server products etc. They are not
mobile but neither they are protected in the same as e.g., a data
center is.

This is not to admit that right now the feature is no good to anyone
but in a selected set of use cases with this modification it would
make e.g., IMA's security *worse* than it would be with the feature
enabled.

BR, Jarkko

On Fri, Aug 15, 2025 at 08:52:35PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 15, 2025 at 08:45:48PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Aug 15, 2025 at 10:06:36AM -0700, Chris Fenner wrote:
> > > On Fri, Aug 15, 2025 at 9:27 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:
> > > 
> > > > I'll with shoot another proposal. Let's delete null primary creation
> > > > code and add a parameter 'tpm.integrity_handle', which will refers to
> > > > persistent primary handle:
> > > 
> > > I'm not yet sure I understand which handle you mean, or what you're
> > > proposing to do with it. Could you elaborate?
> > 
> > Primary key persistent handle.
> > 
> > In tpm2_start_auth_session() there's
> > 
> > 	/* salt key handle */
> > 	tpm_buf_append_u32(&buf, null_key);
> > 
> > Which would become
> > 
> > 	/* salt key handle */
> > 	tpm_buf_append_u32(&buf, integrity_handle);
> > 
> > And in beginning of exported functions from tpm2-sessions.c:
> > 
> > 	if (!integrity_handle)
> > 		return 0;
> > 
> > And delete from same file:
> > 
> > 	1. tpm2_create_*()
> > 	2. tpm2_load_null()
> > 
> > That way the feature makes sense and does not disturb the user who don't
> > want it as PCRs and random numbers will be integrity proteced agains an
> > unambiguous key that can be certified.
> 
> E.g., for example that will unquestionably harden IMA exactly for the
> same reasons why some user space software might to choose to use HMAC
> based integrity protection.
> 
> At data center, there's guards and guns but for appliences, but there
> is also the market appliances, home server products etc. They are not
> mobile but neither they are protected in the same as e.g., a data
> center is.
> 
> This is not to admit that right now the feature is no good to anyone
> but in a selected set of use cases with this modification it would
> make e.g., IMA's security *worse* than it would be with the feature
> enabled.

One product example would be "blockchain node as a box" i.e., it carries
momentary value inside. I could imagine this type of products exist or
to be created (especially given proof-of-stake blockchains).

In such product, you don't have much to measure but you wan to take all
of the security that you have to harden the protection of that small
amount of data.

BR, Jarkko

On Fri, Aug 15, 2025 at 08:58:06PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 15, 2025 at 08:52:35PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Aug 15, 2025 at 08:45:48PM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Aug 15, 2025 at 10:06:36AM -0700, Chris Fenner wrote:
> > > > On Fri, Aug 15, 2025 at 9:27 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:
> > > > 
> > > > > I'll with shoot another proposal. Let's delete null primary creation
> > > > > code and add a parameter 'tpm.integrity_handle', which will refers to
> > > > > persistent primary handle:
> > > > 
> > > > I'm not yet sure I understand which handle you mean, or what you're
> > > > proposing to do with it. Could you elaborate?
> > > 
> > > Primary key persistent handle.
> > > 
> > > In tpm2_start_auth_session() there's
> > > 
> > > 	/* salt key handle */
> > > 	tpm_buf_append_u32(&buf, null_key);
> > > 
> > > Which would become
> > > 
> > > 	/* salt key handle */
> > > 	tpm_buf_append_u32(&buf, integrity_handle);
> > > 
> > > And in beginning of exported functions from tpm2-sessions.c:
> > > 
> > > 	if (!integrity_handle)
> > > 		return 0;
> > > 
> > > And delete from same file:
> > > 
> > > 	1. tpm2_create_*()
> > > 	2. tpm2_load_null()
> > > 
> > > That way the feature makes sense and does not disturb the user who don't
> > > want it as PCRs and random numbers will be integrity proteced agains an
> > > unambiguous key that can be certified.
> > 
> > E.g., for example that will unquestionably harden IMA exactly for the
> > same reasons why some user space software might to choose to use HMAC
> > based integrity protection.
> > 
> > At data center, there's guards and guns but for appliences, but there
> > is also the market appliances, home server products etc. They are not
> > mobile but neither they are protected in the same as e.g., a data
> > center is.
> > 
> > This is not to admit that right now the feature is no good to anyone
> > but in a selected set of use cases with this modification it would
> > make e.g., IMA's security *worse* than it would be with the feature
> > enabled.
> 
> One product example would be "blockchain node as a box" i.e., it carries
> momentary value inside. I could imagine this type of products exist or
> to be created (especially given proof-of-stake blockchains).
> 
> In such product, you don't have much to measure but you wan to take all
> of the security that you have to harden the protection of that small
> amount of data.

I'm happy to make patch next week for this change too. So probably this
where I align myself to. It's just the best average IMHO. Everyone gets
exactly what they want, right?

BR, Jarkko

On Fri, Aug 15, 2025 at 10:45 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:

> Primary key persistent handle.

I see, thanks. I think this might make it easier to ensure the driver
fails-open in the "relaxed" case, but I don't think it would resolve
much of the performance drawbacks (really we'd just cut out the
ContextLoads, which in my testing constitute around 30ms of the total
135ms of overhead). I still don't think it really solves the threat
model since the adversary can just make sure to interpose all the
requests instead of just some of them.

That said, it really seems prudent to disable the (seems to be?
broken) feature by default for now, then re-enable it once this is
confirmed working.

On Fri, Aug 15, 2025 at 10:52 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:

> This is not to admit that right now the feature is no good to anyone
> but in a selected set of use cases with this modification it would
> make e.g., IMA's security *worse* than it would be with the feature
> enabled.

Under what specific threat model would IMA's security be worse in this
case? Either there is an interposer, or there isn't, right? If there
is an interposer, then they can interpose all the commands including
the CreatePrimary and session establishment(s) and defeat the current
and proposed version of TCG_TPM2_HMAC. If there is not an interposer,
then this is moot (I think).

Philosophically, I think there is no such thing as "more secure";
there is only "solves a stronger threat model." For example, you could
construct something called "AES-129" that you could argue is "more
secure" than AES-128, but since nobody's threat model has attackers
that can break 128-bit keys but not 129-bit keys, we don't use it. I
try to apply this reasoning to everything I build: all security
features trade-off against performance, usability, and compatibility,
and I strive to justify these trade-offs with whatever specific
threats that they resolve.

On Fri, Aug 15, 2025 at 11:04 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:

> I'm happy to make patch next week for this change too. So probably this
> where I align myself to. It's just the best average IMHO. Everyone gets
> exactly what they want, right?

To be clear: I already have what I want (the ability to disable this
feature because it seems broken to me), I'm just making
recommendations as a TPM abyssal domain expert. I hope my feedback is
of some use on this -- the work of dealing with interposer attackers
is quite important and I appreciate the effort already put in by the
team.

Thanks
Chris

On Fri, Aug 15, 2025 at 11:09:07AM -0700, Chris Fenner wrote:
> > I'm happy to make patch next week for this change too. So probably this
> > where I align myself to. It's just the best average IMHO. Everyone gets
> > exactly what they want, right?
> 
> To be clear: I already have what I want (the ability to disable this
> feature because it seems broken to me), I'm just making
> recommendations as a TPM abyssal domain expert. I hope my feedback is
> of some use on this -- the work of dealing with interposer attackers
> is quite important and I appreciate the effort already put in by the
> team.

So, if the feature is locked into persistent handle, the net effect
meets the same goals. I'll pursue on a patch.

> 
> Thanks
> Chris

BR, Jarkko