[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f69e08167d8354db31013018edf064a2876f8d1c.camel@kernel.org>
Date: Fri, 11 Oct 2024 17:06:53 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: linux-integrity@...r.kernel.org
Cc: James.Bottomley@...senPartnership.com, roberto.sassu@...wei.com,
mapengyu@...il.com, Mimi Zohar <zohar@...ux.ibm.com>, David Howells
<dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, James Morris
<jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Peter Huewe
<peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/5] Lazy flush for the auth session
On Sat, 2024-09-21 at 15:08 +0300, 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.org/linux-integrity/20240918203559.192605-1-jarkko@kernel.org/
> v3:
> https://lore.kernel.org/linux-integrity/20240917154444.702370-1-jarkko@kernel.org/
> v2:
> https://lore.kernel.org/linux-integrity/20240916110714.1396407-1-jarkko@kernel.org/
> v1:
> https://lore.kernel.org/linux-integrity/20240915180448.2030115-1-jarkko@kernel.org/
>
> Jarkko Sakkinen (5):
> tpm: Return on tpm2_create_null_primary() failure
> tpm: Implement tpm2_load_null() rollback
> tpm: flush the null key only when /dev/tpm0 is accessed
> tpm: Allocate chip->auth in tpm2_start_auth_session()
> tpm: flush the auth session only when /dev/tpm0 is open
>
> drivers/char/tpm/tpm-chip.c | 14 ++++
> drivers/char/tpm/tpm-dev-common.c | 8 +++
> drivers/char/tpm/tpm-interface.c | 10 ++-
> drivers/char/tpm/tpm2-cmd.c | 3 +
> drivers/char/tpm/tpm2-sessions.c | 109 ++++++++++++++++++----------
> --
> include/linux/tpm.h | 2 +
> 6 files changed, 102 insertions(+), 44 deletions(-)
The summarize some discussions:
1. I'll address Stefan's remarks.
2. We know that these patches address the desktop boot.
3. IMA is too slow => add a boot option for IMA default off. I.e.
IMA will not use the feature unless you specifically ask.
4. Random generation can be optimized a lot with or without
encryption. Not sure if I have time to do ths right now
but I have already patch planned for this.
What is blocking me is the James' request to not include
functional fixes. The problem with that is that if comply
to that request I will have to postpone all the performacne
fixes and send a patch set with only functional fixes and
go all review rounds with that before moving forward.
This is just how priorities go in kernel and doing by the
book. Is that really necessary?
Since I've just started in a new job any patches can be
expected earliest next week. That's why I was rushing with
the patch set in the first place because I knew that there
will be otherwise a few week delay but we'll get there :-)
BR, Jarkko
Powered by blists - more mailing lists