On Thu, Jun 20, 2024 at 08:59:11PM -0400, Stefan Berger wrote:
> From: Stefan Berger
>
> Disable testing provider support on Debian:latest and AltLinux:sisyphus
> since both now get stuck while running OpenSSL provider-related tests.
> This is most likely due to an update in a dependency (OpenSSL
On Fri, Jun 21, 2024 at 06:24:38AM -0400, Mimi Zohar wrote:
> On Fri, 2024-06-21 at 11:03 +0100, Jonathan McDowell wrote:
> > On Thu, Jun 20, 2024 at 08:59:11PM -0400, Stefan Berger wrote:
> > > From: Stefan Berger
> > >
> > > Disable testing p
On Fri, Jun 21, 2024 at 04:34:33PM -0400, Mimi Zohar wrote:
> On Fri, 2024-06-21 at 12:44 +0100, Jonathan McDowell wrote:
> > On Fri, Jun 21, 2024 at 06:24:38AM -0400, Mimi Zohar wrote:
> > > On Fri, 2024-06-21 at 11:03 +0100, Jonathan McDowell wrote:
> > > > On T
On Tue, Jul 16, 2024 at 09:52:24PM +0300, Jarkko Sakkinen wrote:
> tpm_buf_append_name() has the following snippet in the beginning:
>
> if (!tpm2_chip_auth(chip)) {
> tpm_buf_append_u32(buf, handle);
> /* count the number of handles in the upper bits of flags */
uldn't see the timeouts at all, and
I'm still trying to work on getting to the bottom of these, which are
generally infrequent, but happening enough across our fleet that we were
able to observe this handle leak.)
From: Jonathan McDowell
tpm_dev_transmit prepares the TPM space befor
From: Jonathan McDowell
tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed
On Thu, Oct 03, 2024 at 06:25:14PM -0400, Stefan Berger wrote:
> On 10/3/24 5:59 PM, Stefan Berger wrote:
> > On 10/2/24 1:04 PM, Jonathan McDowell wrote:
> > > (I'm still in the process of testing this to confirm it fixes the
> > > errata I've seen, but I
On Wed, Oct 02, 2024 at 10:31:34AM -0700, James Bottomley wrote:
> 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-integr
We have been seeing a large number of TPM transmit problems across our
fleet, with frequent
tpm tpm0: tpm_try_transmit: send(): error -62
errors being logged. I don't have an on-demand reproducer, which makes
diagnosis difficult. In almost all cases it's a transient issue, and a
subsequent attemp
Y sequence. The work around
is to retry the command submission. Add appropriate logic to do this in
the send path.
Signed-off-by: Jonathan McDowell
---
drivers/char/tpm/tpm_tis_core.c | 24 +++-
drivers/char/tpm/tpm_tis_core.h | 1 +
include/linux/tpm.h | 1 +
On Sat, Feb 08, 2025 at 10:29:55PM +0200, Jarkko Sakkinen wrote:
> On Fri, Feb 07, 2025 at 09:26:16AM +0000, Jonathan McDowell wrote:
> > > The whole arithmetic with timeout_a/b/c is mostly gibberish and could
> > > be replaced with a single "max" constant without
On Fri, Feb 07, 2025 at 10:58:15AM +0100, Michal Suchánek wrote:
> On Fri, Feb 07, 2025 at 09:47:13AM +0000, Jonathan McDowell wrote:
> > On Fri, Feb 07, 2025 at 10:40:16AM +0100, Michal Suchánek wrote:
> > > On Fri, Feb 07, 2025 at 09:26:16AM +, Jonathan McDowell wrote:
ed with another chip type as well:
>
> localhost kernel: tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id
> 22)
>
> TPM Device
> Vendor ID: IFX
> Specification Version: 2.0
> Firmware Revision: 7.83
> Description: TPM 2.0, ManufacturerID:
On Thu, Feb 06, 2025 at 10:35:32PM +0200, Jarkko Sakkinen wrote:
> On Wed, Feb 05, 2025 at 02:29:36PM +0000, Jonathan McDowell wrote:
> > Interesting. TPM2_CC_CONTEXT_LOAD (353) / TPM2_CC_FLUSH_CONTEXT (357) /
> > TPM2_CC_CONTEXT_SAVE (354) I kinda expect to maybe take a bit
On Fri, Feb 07, 2025 at 10:40:16AM +0100, Michal Suchánek wrote:
> On Fri, Feb 07, 2025 at 09:26:16AM +0000, Jonathan McDowell wrote:
> > So just to clarify, this more recent patch is working around a situation
> > where the status register gets stuck and needs a complete retry of
On Wed, Jan 29, 2025 at 05:20:33PM +0100, Michal Suchánek wrote:
> On Wed, Jan 29, 2025 at 04:02:49PM +0000, Jonathan McDowell wrote:
> > On Wed, Jan 29, 2025 at 04:27:15PM +0100, Michal Suchánek wrote:
> > > there is a problem report that booting a specific type of system about
On Wed, Jan 29, 2025 at 04:27:15PM +0100, Michal Suchánek wrote:
> there is a problem report that booting a specific type of system about
> 0.1% of the time encrypted volume (using a PCR to release the key) fails
> to unlock because of TPM operation timeout.
>
> Minimizing the test case failed so
ri, Mar 07, 2025 at 12:25:23PM +, Jonathan McDowell wrote:
From: Jonathan McDowell
Lazy flushing of TPM auth sessions can interact badly with IMA + kexec,
resulting in loaded session handles being leaked across the kexec and
not cleaned up. Fix by ensuring any active auth session is ended befo
From: Jonathan McDowell
Lazy flushing of TPM auth sessions was introduced to speed up IMA
measurments into the TPM. Make use of it in tpm2_get_random as well,
which has the added benefit of not needlessly cleaning up the session
that IMA is using when there are no userspace accesses taking place
Auth sessions are lazily flushed since commit df745e25098dc ("tpm:
Lazily flush the auth session"), so it's expected that we might try to
start a new session when one is still active.
Signed-off-by: Jonathan McDowell
---
drivers/char/tpm/tpm2-sessions.c | 1 -
1 file chan
On Fri, Mar 07, 2025 at 12:23:11AM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 06, 2025 at 09:00:56AM +0000, Jonathan McDowell wrote:
> > From: Jonathan McDowell
> >
> > Some Infineon devices have a issue where the status register will get
> > stuck with a quick
From: Jonathan McDowell
Lazy flushing of TPM auth sessions can interact badly with IMA + kexec,
resulting in loaded session handles being leaked across the kexec and
not cleaned up. Fix by ensuring any active auth session is ended before
the TPM is told about the shutdown, matching what is done
On Fri, Mar 07, 2025 at 06:36:02PM +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 07, 2025 at 10:56:44AM +0000, Jonathan McDowell wrote:
> > Auth sessions are lazily flushed since commit df745e25098dc ("tpm:
> > Lazily flush the auth session"), so it's expected that w
From: Jonathan McDowell
Some Infineon devices have a issue where the status register will get
stuck with a quick REQUEST_USE / COMMAND_READY sequence. This is not
simply a matter of requiring a longer timeout; the work around is to
retry the command submission. Add appropriate logic to do this
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 sessions is already active when it
is called.
Investigating I think this is because tpm2_pcr_extend() calls
tpm_buf_append_hmac_session() whic
From: Jonathan McDowell
Some Infineon devices have a issue where the status register will get
stuck with a quick REQUEST_USE / COMMAND_READY sequence. This is not
simply a matter of requiring a longer timeout; the work around is to
retry the command submission. Add appropriate logic to do this
.
Cc: sta...@vger.kernel.org # v6.4+
Fixes: e87fcf0dc2b4 ("tpm, tpm_tis: Only handle supported interrupts")
Signed-off-by: Jonathan McDowell
Reviewed-by: Michal Suchánek
Reviewed-by: Lino Sanfilippo
---
v2: Reword commit message
Don't needlessly wrap line
drivers/char/tp
From: Jonathan McDowell
The change to only use interrupts to handle supported status changes,
then switch to polling for the rest, inverted the status test and sleep
such that we can end up sleeping beyond our timeout and not actually
checking the status. This can result in spurious TPM timeouts
e
related, and matches up with some of our internal metrics that showed an
increase in timeouts in 6.4 onwards.
commit 79041fba797d0fe907e227012767f56dd93fac32
Author: Jonathan McDowell
Date: Wed Feb 19 16:20:44 2025 -0600
tpm, tpm_tis: Fix timeout handling when waiting for TPM status
On Thu, Feb 20, 2025 at 09:42:28AM +0100, Michal Suchánek wrote:
> On Wed, Feb 19, 2025 at 10:29:45PM +0000, Jonathan McDowell wrote:
> > On Wed, Jan 29, 2025 at 04:27:15PM +0100, Michal Suchánek wrote:
> > > Hello,
> > >
> > > there is a problem report th
On Fri, Apr 04, 2025 at 11:10:12AM +0300, Jarkko Sakkinen wrote:
On Fri, Apr 04, 2025 at 09:51:29AM +0200, Michal Suchánek wrote:
On Thu, Apr 03, 2025 at 09:43:19PM +0100, Jonathan McDowell wrote:
> On Thu, Apr 03, 2025 at 09:45:21PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Apr 02, 2
wrote:
From: Jonathan McDowell
[ Upstream commit 1dbf74e00a5f882b04b398399b6def65cd51ef21 ]
Lazy flushing of TPM auth sessions can interact badly with IMA + kexec,
resulting in loaded session handles being leaked across the kexec and
not cleaned up. Fix by ensuring any active auth session is
GAIN" - the "-" sign has somehow been lost.
Apologies for this, let me know what's easiest for you in terms of
resolving it.
On Mon, Mar 10, 2025 at 12:19:55PM +, Jonathan McDowell wrote:
From: Jonathan McDowell
Some Infineon devices have a issue where the status register wi
On Thu, Apr 03, 2025 at 09:45:21PM +0300, Jarkko Sakkinen wrote:
On Wed, Apr 02, 2025 at 06:45:40PM +0100, Jonathan McDowell wrote:
On Wed, Apr 02, 2025 at 07:21:30PM +0200, Michal Suchanek wrote:
> With some Infineon chips the timeouts in tpm_tis_send_data (both B and
> C) can reach
On Wed, Apr 02, 2025 at 10:07:39PM +0200, Michal Suchánek wrote:
On Wed, Apr 02, 2025 at 06:45:40PM +0100, Jonathan McDowell wrote:
On Wed, Apr 02, 2025 at 07:21:30PM +0200, Michal Suchanek wrote:
> With some Infineon chips the timeouts in tpm_tis_send_data (both B and
> C) can reach
On Thu, Apr 03, 2025 at 01:56:37PM +0200, Michal Suchánek wrote:
On Thu, Apr 03, 2025 at 12:00:36PM +0100, Jonathan McDowell wrote:
On Wed, Apr 02, 2025 at 10:07:39PM +0200, Michal Suchánek wrote:
> On Wed, Apr 02, 2025 at 06:45:40PM +0100, Jonathan McDowell wrote:
> > On Wed, Apr 02
On Wed, Apr 02, 2025 at 07:21:30PM +0200, Michal Suchanek wrote:
With some Infineon chips the timeouts in tpm_tis_send_data (both B and
C) can reach up to about 2250 ms.
Extend the timeout duration to accommodate this.
The problem here is the bump of timeout_c is going to interact poorly
with
On Wed, Jun 11, 2025 at 04:25:24PM +, Orlov, Ivan wrote:
The current implementation of timeout detection works in the following
way:
1. Read completion status. If completed, return the data
2. Sleep for some time (usleep_range)
3. Check for timeout using current jiffies value. Return an erro
On Fri, Jun 20, 2025 at 06:08:31PM +, Orlov, Ivan wrote:
The current implementation of timeout detection works in the following
way:
1. Read completion status. If completed, return the data
2. Sleep for some time (usleep_range)
3. Check for timeout using current jiffies value. Return an erro
On Wed, Jun 25, 2025 at 07:43:07PM +0300, Jarkko Sakkinen wrote:
On Sun, Jun 22, 2025 at 09:52:58PM +0100, Jonathan McDowell wrote:
On Fri, Jun 20, 2025 at 06:08:31PM +, Orlov, Ivan wrote:
> The current implementation of timeout detection works in the following
> way:
>
> 1. Rea
On Fri, Jul 04, 2025 at 04:39:20PM +0100, Orlov, Ivan wrote:
On 04/07/2025 16:16, Jarkko Sakkinen wrote:
On Fri, Jul 04, 2025 at 10:02:33AM +0100, Jonathan McDowell wrote:
On Wed, Jun 25, 2025 at 07:43:07PM +0300, Jarkko Sakkinen wrote:
On Sun, Jun 22, 2025 at 09:52:58PM +0100, Jonathan
h with an open coded repeated check, instead of
the check function) in our fleet now. It hasn't rolled out to enough
machines for me to confirm it definitely fixes the problem we see, but:
Reviewed-By: Jonathan McDowell
---
V1 -> V2:
- Exclude the jiffies -> ktime change from the p
42 matches
Mail list logo
