[PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Takashi Iwai]

The TPM2 ACPI table may request a large size for the event log, and it
may be over the max size of kmalloc().  When this happens, the driver
spews the kernel WARNING at the probe time, but the error is
eventually ignored in the caller side, and it results in the missing
TPM event log exposure.

This patch replaces the devm_kmalloc() call with kvmalloc() to allow
larger sizes.  Since there is no devm variant for kvmalloc(), now it's
managed manually via devres_alloc() and devres_add().

Reported-and-tested-by: Andy Liang <andy.liang@hpe.com>
Cc: jenifer.golmitz@hpe.com
Link: https://bugzilla.suse.com/show_bug.cgi?id=1232421
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 drivers/char/tpm/eventlog/acpi.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/eventlog/acpi.c b/drivers/char/tpm/eventlog/acpi.c
index 69533d0bfb51..56f7d73fa6bf 100644
--- a/drivers/char/tpm/eventlog/acpi.c
+++ b/drivers/char/tpm/eventlog/acpi.c
@@ -63,6 +63,13 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)
 	return n == 0;
 }
 
+static void bios_event_log_release(struct device *dev, void *res)
+{
+	void **logp = res;
+
+	kvfree(*logp);
+}
+
 /* read binary bios log */
 int tpm_read_log_acpi(struct tpm_chip *chip)
 {
@@ -71,6 +78,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
 	void __iomem *virt;
 	u64 len, start;
 	struct tpm_bios_log *log;
+	void **logp;
 	struct acpi_table_tpm2 *tbl;
 	struct acpi_tpm2_phy *tpm2_phy;
 	int format;
@@ -136,9 +144,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
 	}
 
 	/* malloc EventLog space */
-	log->bios_event_log = devm_kmalloc(&chip->dev, len, GFP_KERNEL);
-	if (!log->bios_event_log)
+	logp = devres_alloc(bios_event_log_release, sizeof(*logp), GFP_KERNEL);
+	if (!logp)
 		return -ENOMEM;
+	devres_add(&chip->dev, logp);
+	log->bios_event_log = kvmalloc(len, GFP_KERNEL);
+	if (!log->bios_event_log) {
+		ret = -ENOMEM;
+		goto err;
+	}
+	*logp = log->bios_event_log;
 
 	log->bios_event_log_end = log->bios_event_log + len;
 
@@ -164,7 +179,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
 	return format;
 
 err:
-	devm_kfree(&chip->dev, log->bios_event_log);
+	devres_release(&chip->dev, bios_event_log_release, NULL, NULL);
 	log->bios_event_log = NULL;
 	return ret;
 }
-- 
2.43.0

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Paul Menzel]

Dear Takashi,


Thank you for the patch.

Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> The TPM2 ACPI table may request a large size for the event log, and it
> may be over the max size of kmalloc().  When this happens, the driver

What is kmalloc()’s maximum size?

> spews the kernel WARNING at the probe time, but the error is
> eventually ignored in the caller side, and it results in the missing
> TPM event log exposure.
> 
> This patch replaces the devm_kmalloc() call with kvmalloc() to allow
> larger sizes.  Since there is no devm variant for kvmalloc(), now it's
> managed manually via devres_alloc() and devres_add().

As the access to the bug report is restricted, are you at liberty to 
share the system you’ve seen this on?

> Reported-and-tested-by: Andy Liang <andy.liang@hpe.com>
> Cc: jenifer.golmitz@hpe.com
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1232421
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>   drivers/char/tpm/eventlog/acpi.c | 21 ++++++++++++++++++---
>   1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/char/tpm/eventlog/acpi.c b/drivers/char/tpm/eventlog/acpi.c
> index 69533d0bfb51..56f7d73fa6bf 100644
> --- a/drivers/char/tpm/eventlog/acpi.c
> +++ b/drivers/char/tpm/eventlog/acpi.c
> @@ -63,6 +63,13 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)
>   	return n == 0;
>   }
>   
> +static void bios_event_log_release(struct device *dev, void *res)
> +{
> +	void **logp = res;
> +
> +	kvfree(*logp);
> +}
> +
>   /* read binary bios log */
>   int tpm_read_log_acpi(struct tpm_chip *chip)
>   {
> @@ -71,6 +78,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
>   	void __iomem *virt;
>   	u64 len, start;
>   	struct tpm_bios_log *log;
> +	void **logp;
>   	struct acpi_table_tpm2 *tbl;
>   	struct acpi_tpm2_phy *tpm2_phy;
>   	int format;
> @@ -136,9 +144,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
>   	}
>   
>   	/* malloc EventLog space */
> -	log->bios_event_log = devm_kmalloc(&chip->dev, len, GFP_KERNEL);
> -	if (!log->bios_event_log)
> +	logp = devres_alloc(bios_event_log_release, sizeof(*logp), GFP_KERNEL);
> +	if (!logp)
>   		return -ENOMEM;
> +	devres_add(&chip->dev, logp);
> +	log->bios_event_log = kvmalloc(len, GFP_KERNEL);
> +	if (!log->bios_event_log) {
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +	*logp = log->bios_event_log;
>   
>   	log->bios_event_log_end = log->bios_event_log + len;
>   
> @@ -164,7 +179,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
>   	return format;
>   
>   err:
> -	devm_kfree(&chip->dev, log->bios_event_log);
> +	devres_release(&chip->dev, bios_event_log_release, NULL, NULL);
>   	log->bios_event_log = NULL;
>   	return ret;
>   }

The diff looks good to me.


Kind regards,

Paul

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Takashi Iwai]

On Thu, 07 Nov 2024 13:17:33 +0100,
Paul Menzel wrote:
> 
> Dear Takashi,
> 
> 
> Thank you for the patch.
> 
> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> > The TPM2 ACPI table may request a large size for the event log, and it
> > may be over the max size of kmalloc().  When this happens, the driver
> 
> What is kmalloc()’s maximum size?

128kB or so, IIRC.
And according Andy, the table can be over 4MB.

> > spews the kernel WARNING at the probe time, but the error is
> > eventually ignored in the caller side, and it results in the missing
> > TPM event log exposure.
> > 
> > This patch replaces the devm_kmalloc() call with kvmalloc() to allow
> > larger sizes.  Since there is no devm variant for kvmalloc(), now it's
> > managed manually via devres_alloc() and devres_add().
> 
> As the access to the bug report is restricted, are you at liberty to
> share the system you’ve seen this on?

Likely yes, as it was reported to SLE15.  Sorry for that.

Basically the info provided there was almost what I put in the
description; the driver got the kernel WARNING and Andy tested my
patch.

If any further info is required, at best ask HPE people here in Cc.


thanks,

Takashi


> > Reported-and-tested-by: Andy Liang <andy.liang@hpe.com>
> > Cc: jenifer.golmitz@hpe.com
> > Link: https://bugzilla.suse.com/show_bug.cgi?id=1232421
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> >   drivers/char/tpm/eventlog/acpi.c | 21 ++++++++++++++++++---
> >   1 file changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/eventlog/acpi.c b/drivers/char/tpm/eventlog/acpi.c
> > index 69533d0bfb51..56f7d73fa6bf 100644
> > --- a/drivers/char/tpm/eventlog/acpi.c
> > +++ b/drivers/char/tpm/eventlog/acpi.c
> > @@ -63,6 +63,13 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)
> >   	return n == 0;
> >   }
> >   +static void bios_event_log_release(struct device *dev, void *res)
> > +{
> > +	void **logp = res;
> > +
> > +	kvfree(*logp);
> > +}
> > +
> >   /* read binary bios log */
> >   int tpm_read_log_acpi(struct tpm_chip *chip)
> >   {
> > @@ -71,6 +78,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
> >   	void __iomem *virt;
> >   	u64 len, start;
> >   	struct tpm_bios_log *log;
> > +	void **logp;
> >   	struct acpi_table_tpm2 *tbl;
> >   	struct acpi_tpm2_phy *tpm2_phy;
> >   	int format;
> > @@ -136,9 +144,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
> >   	}
> >     	/* malloc EventLog space */
> > -	log->bios_event_log = devm_kmalloc(&chip->dev, len, GFP_KERNEL);
> > -	if (!log->bios_event_log)
> > +	logp = devres_alloc(bios_event_log_release, sizeof(*logp), GFP_KERNEL);
> > +	if (!logp)
> >   		return -ENOMEM;
> > +	devres_add(&chip->dev, logp);
> > +	log->bios_event_log = kvmalloc(len, GFP_KERNEL);
> > +	if (!log->bios_event_log) {
> > +		ret = -ENOMEM;
> > +		goto err;
> > +	}
> > +	*logp = log->bios_event_log;
> >     	log->bios_event_log_end = log->bios_event_log + len;
> >   @@ -164,7 +179,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
> >   	return format;
> >     err:
> > -	devm_kfree(&chip->dev, log->bios_event_log);
> > +	devres_release(&chip->dev, bios_event_log_release, NULL, NULL);
> >   	log->bios_event_log = NULL;
> >   	return ret;
> >   }
> 
> The diff looks good to me.
> 
> 
> Kind regards,
> 
> Paul

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Stefan Berger]

On 11/7/24 7:38 AM, Takashi Iwai wrote:
> On Thu, 07 Nov 2024 13:17:33 +0100,
> Paul Menzel wrote:
>>
>> Dear Takashi,
>>
>>
>> Thank you for the patch.
>>
>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
>>> The TPM2 ACPI table may request a large size for the event log, and it
>>> may be over the max size of kmalloc().  When this happens, the driver
>>
>> What is kmalloc()’s maximum size?
> 
> 128kB or so, IIRC.
> And according Andy, the table can be over 4MB.

Can you copy the contents of the file on that machine and tell us what 
size it has:

cp /sys/kernel/security/tpm0/binary_bios_measurements ./

I wonder what the BIOS on that system writes into this file and wouldn't 
exclude a buggy BIOS indicating wrong size and producing a much smaller log.

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Stefan Berger]

On 11/7/24 2:06 PM, Stefan Berger wrote:
> 
> 
> On 11/7/24 7:38 AM, Takashi Iwai wrote:
>> On Thu, 07 Nov 2024 13:17:33 +0100,
>> Paul Menzel wrote:
>>>
>>> Dear Takashi,
>>>
>>>
>>> Thank you for the patch.
>>>
>>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
>>>> The TPM2 ACPI table may request a large size for the event log, and it
>>>> may be over the max size of kmalloc().  When this happens, the driver
>>>
>>> What is kmalloc()’s maximum size?
>>
>> 128kB or so, IIRC.
>> And according Andy, the table can be over 4MB.
> 
> Can you copy the contents of the file on that machine and tell us what 
> size it has:
> 
> cp /sys/kernel/security/tpm0/binary_bios_measurements ./

Actually, you may need to have the contents parsed by a user space tool 
since the driver does not detect where the actual end may be:

  tsseventextend -if ./binary_bios_measurements -sim -v

This may give you a feeling for how much is in that file and then you'd 
have to truncate it into half for example and see whether it still 
parses the same. My point is that we haven't seen such excessive-sized 
logs so far and following the parsing above we may find something like 
this more useful than allocating possibly large amounts of memory that a 
buggy ACPI table indicates (+ notify manufacturer):

   if (len > MAX_TPM_LOG_SIZE) {
       dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d 
bytes\n", len);
       len = MAX_TPM_LOG_SIZE;
   }

If you send me the log I'd look at it.


> 
> I wonder what the BIOS on that system writes into this file and wouldn't 
> exclude a buggy BIOS indicating wrong size and producing a much smaller 
> log.
> 
> 

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Takashi Iwai]

On Thu, 07 Nov 2024 20:31:37 +0100,
Stefan Berger wrote:
> 
> 
> 
> On 11/7/24 2:06 PM, Stefan Berger wrote:
> > 
> > 
> > On 11/7/24 7:38 AM, Takashi Iwai wrote:
> >> On Thu, 07 Nov 2024 13:17:33 +0100,
> >> Paul Menzel wrote:
> >>> 
> >>> Dear Takashi,
> >>> 
> >>> 
> >>> Thank you for the patch.
> >>> 
> >>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> >>>> The TPM2 ACPI table may request a large size for the event log, and it
> >>>> may be over the max size of kmalloc().  When this happens, the driver
> >>> 
> >>> What is kmalloc()’s maximum size?
> >> 
> >> 128kB or so, IIRC.
> >> And according Andy, the table can be over 4MB.
> > 
> > Can you copy the contents of the file on that machine and tell us
> > what size it has:
> > 
> > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
> 
> Actually, you may need to have the contents parsed by a user space
> tool since the driver does not detect where the actual end may be:
> 
>  tsseventextend -if ./binary_bios_measurements -sim -v
> 
> This may give you a feeling for how much is in that file and then
> you'd have to truncate it into half for example and see whether it
> still parses the same. My point is that we haven't seen such
> excessive-sized logs so far and following the parsing above we may
> find something like this more useful than allocating possibly large
> amounts of memory that a buggy ACPI table indicates (+ notify
> manufacturer):
> 
>   if (len > MAX_TPM_LOG_SIZE) {
>       dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d
> bytes\n", len);
>       len = MAX_TPM_LOG_SIZE;
>   }
> 
> If you send me the log I'd look at it.

It's rather a question Andy; could you check give the requested info?


thanks,

Takashi

RE: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Liang, Andy (Linux Ecosystem Engineering)]

> On Thu, 07 Nov 2024 20:31:37 +0100,
> Stefan Berger wrote:
> > 
> > 
> > 
> > On 11/7/24 2:06 PM, Stefan Berger wrote:
> > > 
> > > 
> > > On 11/7/24 7:38 AM, Takashi Iwai wrote:
> > >> On Thu, 07 Nov 2024 13:17:33 +0100, Paul Menzel wrote:
>>  >>> 
>>  >>> Dear Takashi,
>>  >>> 
>>  >>> 
>>  >>> Thank you for the patch.
>>  >>> 
>>  >>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
>>  >>>> The TPM2 ACPI table may request a large size for the event log, 
>>  >>>> and it may be over the max size of kmalloc().  When this happens, 
>>  >>>> the driver
>>  >>> 
>>  >>> What is kmalloc()’s maximum size?
>>  >> 
>>  >> 128kB or so, IIRC.
>>  >> And according Andy, the table can be over 4MB.
>>  > 
>>  > Can you copy the contents of the file on that machine and tell us 
>>  > what size it has:
>>  > 
>>  > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
>>  
>>  Actually, you may need to have the contents parsed by a user space 
>>  tool since the driver does not detect where the actual end may be:
>>  
>>   tsseventextend -if ./binary_bios_measurements -sim -v
>>  
>>  This may give you a feeling for how much is in that file and then 
>>  you'd have to truncate it into half for example and see whether it 
>>  still parses the same. My point is that we haven't seen such 
>>  excessive-sized logs so far and following the parsing above we may 
>>  find something like this more useful than allocating possibly large 
>>  amounts of memory that a buggy ACPI table indicates (+ notify
>> manufacturer):
>>  
>>    if (len > MAX_TPM_LOG_SIZE) {
>>        dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d 
>>  bytes\n", len);
>>       len = MAX_TPM_LOG_SIZE;
>>    }
>>  
>>  If you send me the log I'd look at it.

> It's rather a question Andy; could you check give the requested info?


https://elixir.bootlin.com/linux/v6.8/source/arch/x86/include/asm/page_types.h#L10
#define PAGE_SHIFT 12
#define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT)
 
https://elixir.bootlin.com/linux/v6.8/source/include/linux/mmzone.h#L30
#define MAX_PAGE_ORDER 10
 
https://elixir.bootlin.com/linux/v6.8/source/include/linux/slab.h#L309
#define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX)
The max size  = (1UL <<  MAX_PAGE_ORDER + PAGE_SHIFT) = ( 1UL << (10 + 12)) = 2^22 =4,194,304 (4MB)

For the x86, the max size is 4MB. 

> thanks,

> Takashi

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Takashi Iwai]

On Fri, 08 Nov 2024 09:48:38 +0100,
Liang, Andy (Linux Ecosystem Engineering) wrote:
> 
> 
> > On Thu, 07 Nov 2024 20:31:37 +0100,
> > Stefan Berger wrote:
> > > 
> > > 
> > > 
> > > On 11/7/24 2:06 PM, Stefan Berger wrote:
> > > > 
> > > > 
> > > > On 11/7/24 7:38 AM, Takashi Iwai wrote:
> > > >> On Thu, 07 Nov 2024 13:17:33 +0100, Paul Menzel wrote:
> >>  >>> 
> >>  >>> Dear Takashi,
> >>  >>> 
> >>  >>> 
> >>  >>> Thank you for the patch.
> >>  >>> 
> >>  >>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> >>  >>>> The TPM2 ACPI table may request a large size for the event log, 
> >>  >>>> and it may be over the max size of kmalloc().  When this happens, 
> >>  >>>> the driver
> >>  >>> 
> >>  >>> What is kmalloc()’s maximum size?
> >>  >> 
> >>  >> 128kB or so, IIRC.
> >>  >> And according Andy, the table can be over 4MB.
> >>  > 
> >>  > Can you copy the contents of the file on that machine and tell us 
> >>  > what size it has:
> >>  > 
> >>  > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
> >>  
> >>  Actually, you may need to have the contents parsed by a user space 
> >>  tool since the driver does not detect where the actual end may be:
> >>  
> >>   tsseventextend -if ./binary_bios_measurements -sim -v
> >>  
> >>  This may give you a feeling for how much is in that file and then 
> >>  you'd have to truncate it into half for example and see whether it 
> >>  still parses the same. My point is that we haven't seen such 
> >>  excessive-sized logs so far and following the parsing above we may 
> >>  find something like this more useful than allocating possibly large 
> >>  amounts of memory that a buggy ACPI table indicates (+ notify
> >> manufacturer):
> >>  
> >>    if (len > MAX_TPM_LOG_SIZE) {
> >>        dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d 
> >>  bytes\n", len);
> >>       len = MAX_TPM_LOG_SIZE;
> >>    }
> >>  
> >>  If you send me the log I'd look at it.
> 
> > It's rather a question Andy; could you check give the requested info?
> 
> 
> https://elixir.bootlin.com/linux/v6.8/source/arch/x86/include/asm/page_types.h#L10
> #define PAGE_SHIFT 12
> #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT)
>  
> https://elixir.bootlin.com/linux/v6.8/source/include/linux/mmzone.h#L30
> #define MAX_PAGE_ORDER 10
>  
> https://elixir.bootlin.com/linux/v6.8/source/include/linux/slab.h#L309
> #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX)
> The max size  = (1UL <<  MAX_PAGE_ORDER + PAGE_SHIFT) = ( 1UL << (10 + 12)) = 2^22 =4,194,304 (4MB)
> 
> For the x86, the max size is 4MB. 

Thanks, it was already corrected by Jarkko :)
But what I meant was about the requests:

> cp /sys/kernel/security/tpm0/binary_bios_measurements ./

and

>   tsseventextend -if ./binary_bios_measurements -sim -v

mentioned in the above.  Could you provide the info?


thanks,

Takashi

RE: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Liang, Andy (Linux Ecosystem Engineering)]

> On Fri, 08 Nov 2024 09:48:38 +0100,
> Liang, Andy (Linux Ecosystem Engineering) wrote:
> > 
> > 
> > > On Thu, 07 Nov 2024 20:31:37 +0100,
> > > Stefan Berger wrote:
> > > > 
> > > > 
> > > > 
> > > > On 11/7/24 2:06 PM, Stefan Berger wrote:
> > > > > 
> > > > > 
> > > > > On 11/7/24 7:38 AM, Takashi Iwai wrote:
> > > > >> On Thu, 07 Nov 2024 13:17:33 +0100, Paul Menzel wrote:
> > >>  >>>
> > >>  >>> Dear Takashi,
> > >>  >>>
> > >>  >>>
> > >>  >>> Thank you for the patch.
> > >>  >>>
> > >>  >>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> > >>  >>>> The TPM2 ACPI table may request a large size for the event 
> > >> log,  >>>> and it may be over the max size of kmalloc().  When this 
> > >> happens,  >>>> the driver  >>>  >>> What is kmalloc()’s maximum 
> > >> size?
> > >>  >>
> > >>  >> 128kB or so, IIRC.
> > >>  >> And according Andy, the table can be over 4MB.
> > >>  >
> > >>  > Can you copy the contents of the file on that machine and tell 
> > >> us  > what size it has:
> > >>  >
> > >>  > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
> > >>  
> > >>  Actually, you may need to have the contents parsed by a user space  
> > >> tool since the driver does not detect where the actual end may be:
> > >>  
> > >>   tsseventextend -if ./binary_bios_measurements -sim -v
> > >>  
> > >>  This may give you a feeling for how much is in that file and then  
> > >> you'd have to truncate it into half for example and see whether it  
> > >> still parses the same. My point is that we haven't seen such  
> > >> excessive-sized logs so far and following the parsing above we may  
> > >> find something like this more useful than allocating possibly large  
> > >> amounts of memory that a buggy ACPI table indicates (+ notify
> > >> manufacturer):
> > >>  
> > >>    if (len > MAX_TPM_LOG_SIZE) {
> > >>        dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d  
> > >> bytes\n", len);
> > >>       len = MAX_TPM_LOG_SIZE;
> > >>    }
> > >>  
> > >>  If you send me the log I'd look at it.
> > 
> > > It's rather a question Andy; could you check give the requested info?
> > 
> > 
> > https://elixir.bootlin.com/linux/v6.8/source/arch/x86/include/asm/page
> > _types.h#L10
> > #define PAGE_SHIFT 12
> > #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT)
> >  
> > https://elixir.bootlin.com/linux/v6.8/source/include/linux/mmzone.h#L3
> > 0
> > #define MAX_PAGE_ORDER 10
> >  
> > https://elixir.bootlin.com/linux/v6.8/source/include/linux/slab.h#L309
> > #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX) The max size  = 
> > (1UL <<  MAX_PAGE_ORDER + PAGE_SHIFT) = ( 1UL << (10 + 12)) = 2^22 
> > =4,194,304 (4MB)
> > 
> > For the x86, the max size is 4MB. 
>
> Thanks, it was already corrected by Jarkko :) But what I meant was about the requests:
>
> > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
>
> and
>
> >   tsseventextend -if ./binary_bios_measurements -sim -v
>
> mentioned in the above.  Could you provide the info?

Please check the attached file. The file has also been uploaded to the SUSE Bugzilla.
Thank you.

> thanks,
>
> Takashi

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Jarkko Sakkinen]

On Mon Nov 11, 2024 at 10:43 AM EET, Andy (Linux Ecosystem Engineering) Liang wrote:
> > On Fri, 08 Nov 2024 09:48:38 +0100,
> > Liang, Andy (Linux Ecosystem Engineering) wrote:
> > > 
> > > 
> > > > On Thu, 07 Nov 2024 20:31:37 +0100,
> > > > Stefan Berger wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 11/7/24 2:06 PM, Stefan Berger wrote:
> > > > > > 
> > > > > > 
> > > > > > On 11/7/24 7:38 AM, Takashi Iwai wrote:
> > > > > >> On Thu, 07 Nov 2024 13:17:33 +0100, Paul Menzel wrote:
> > > >>  >>>
> > > >>  >>> Dear Takashi,
> > > >>  >>>
> > > >>  >>>
> > > >>  >>> Thank you for the patch.
> > > >>  >>>
> > > >>  >>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> > > >>  >>>> The TPM2 ACPI table may request a large size for the event 
> > > >> log,  >>>> and it may be over the max size of kmalloc().  When this 
> > > >> happens,  >>>> the driver  >>>  >>> What is kmalloc()’s maximum 
> > > >> size?
> > > >>  >>
> > > >>  >> 128kB or so, IIRC.
> > > >>  >> And according Andy, the table can be over 4MB.
> > > >>  >
> > > >>  > Can you copy the contents of the file on that machine and tell 
> > > >> us  > what size it has:
> > > >>  >
> > > >>  > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
> > > >>  
> > > >>  Actually, you may need to have the contents parsed by a user space  
> > > >> tool since the driver does not detect where the actual end may be:
> > > >>  
> > > >>   tsseventextend -if ./binary_bios_measurements -sim -v
> > > >>  
> > > >>  This may give you a feeling for how much is in that file and then  
> > > >> you'd have to truncate it into half for example and see whether it  
> > > >> still parses the same. My point is that we haven't seen such  
> > > >> excessive-sized logs so far and following the parsing above we may  
> > > >> find something like this more useful than allocating possibly large  
> > > >> amounts of memory that a buggy ACPI table indicates (+ notify
> > > >> manufacturer):
> > > >>  
> > > >>    if (len > MAX_TPM_LOG_SIZE) {
> > > >>        dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d  
> > > >> bytes\n", len);
> > > >>       len = MAX_TPM_LOG_SIZE;
> > > >>    }
> > > >>  
> > > >>  If you send me the log I'd look at it.
> > > 
> > > > It's rather a question Andy; could you check give the requested info?
> > > 
> > > 
> > > https://elixir.bootlin.com/linux/v6.8/source/arch/x86/include/asm/page
> > > _types.h#L10
> > > #define PAGE_SHIFT 12
> > > #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT)
> > >  
> > > https://elixir.bootlin.com/linux/v6.8/source/include/linux/mmzone.h#L3
> > > 0
> > > #define MAX_PAGE_ORDER 10
> > >  
> > > https://elixir.bootlin.com/linux/v6.8/source/include/linux/slab.h#L309
> > > #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX) The max size  = 
> > > (1UL <<  MAX_PAGE_ORDER + PAGE_SHIFT) = ( 1UL << (10 + 12)) = 2^22 
> > > =4,194,304 (4MB)
> > > 
> > > For the x86, the max size is 4MB. 
> >
> > Thanks, it was already corrected by Jarkko :) But what I meant was about the requests:
> >
> > > cp /sys/kernel/security/tpm0/binary_bios_measurements ./
> >
> > and
> >
> > >   tsseventextend -if ./binary_bios_measurements -sim -v
> >
> > mentioned in the above.  Could you provide the info?
>
> Please check the attached file. The file has also been uploaded to the SUSE Bugzilla.
> Thank you.

Please create a bug to kernel bugzilla and attach the file on that.

BR, Jarkko

RE: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Liang, Andy (Linux Ecosystem Engineering)]

> On Mon Nov 11, 2024 at 10:43 AM EET, Andy (Linux Ecosystem Engineering) Liang wrote:
>>> On Fri, 08 Nov 2024 09:48:38 +0100,
>>> Liang, Andy (Linux Ecosystem Engineering) wrote:
>>>>
>>>>
>>>>> On Thu, 07 Nov 2024 20:31:37 +0100,
>>>>> Stefan Berger wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/7/24 2:06 PM, Stefan Berger wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/7/24 7:38 AM, Takashi Iwai wrote:
>>>>>>>> On Thu, 07 Nov 2024 13:17:33 +0100, Paul Menzel wrote:
>>>>>>>>>
>>>>>>>>> Dear Takashi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you for the patch.
>>>>>>>>>
>>>>>>>>> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
>>>>>>>>>> The TPM2 ACPI table may request a large size for the event
>>>>>> log,  >>>> and it may be over the max size of kmalloc().  When this
>>>>>> happens,  >>>> the driver  >>>  >>> What is kmalloc()’s maximum
>>>>>> size?
>>>>>>>>
>>>>>>>> 128kB or so, IIRC.
>>>>>>>> And according Andy, the table can be over 4MB.
>>>>>>>
>>>>>>> Can you copy the contents of the file on that machine and tell
>>>>>> us  > what size it has:
>>>>>>>
>>>>>>> cp /sys/kernel/security/tpm0/binary_bios_measurements ./
>>>>>>
>>>>>> Actually, you may need to have the contents parsed by a user space 
>>>>>> tool since the driver does not detect where the actual end may be:
>>>>>>
>>>>>>  tsseventextend -if ./binary_bios_measurements -sim -v
>>>>>>
>>>>>> This may give you a feeling for how much is in that file and then 
>>>>>> you'd have to truncate it into half for example and see whether it 
>>>>>> still parses the same. My point is that we haven't seen such 
>>>>>> excessive-sized logs so far and following the parsing above we may 
>>>>>> find something like this more useful than allocating possibly large 
>>>>>> amounts of memory that a buggy ACPI table indicates (+ notify
>>>>>> manufacturer):
>>>>>>
>>>>>>   if (len > MAX_TPM_LOG_SIZE) {
>>>>>>       dev_err(&chip->dev, "Truncated excessive-sized TPM log of %d 
>>>>>> bytes\n", len);
>>>>>>      len = MAX_TPM_LOG_SIZE;
>>>>>>   }
>>>>>>
>>>>>> If you send me the log I'd look at it.
>>>>
>>>>> It's rather a question Andy; could you check give the requested info?
>>>>
>>>>
>>>> https://elixir.bootlin.com/linux/v6.8/source/arch/x86/include/asm/page
>>>> _types.h#L10
>>>> #define PAGE_SHIFT 12
>>>> #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT)
>>>>
>>>> https://elixir.bootlin.com/linux/v6.8/source/include/linux/mmzone.h#L3
>>>> 0
>>>> #define MAX_PAGE_ORDER 10
>>>>
>>>> https://elixir.bootlin.com/linux/v6.8/source/include/linux/slab.h#L309
>>>> #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX) The max size  =
>>>> (1UL <<  MAX_PAGE_ORDER + PAGE_SHIFT) = ( 1UL << (10 + 12)) = 2^22
>>>> =4,194,304 (4MB)
>>>>
>>>> For the x86, the max size is 4MB.
>>>
>>> Thanks, it was already corrected by Jarkko :) But what I meant was about the requests:
>>>
>>>> cp /sys/kernel/security/tpm0/binary_bios_measurements ./
>>>
>>> and
>>>
>>>>  tsseventextend -if ./binary_bios_measurements -sim -v
>>>
>>> mentioned in the above.  Could you provide the info?
>>
>> Please check the attached file. The file has also been uploaded to the SUSE Bugzilla.
>> Thank you.
>
> Please create a bug to kernel bugzilla and attach the file on that.
>
> BR, Jarkko

I created a ticket at below. Thank you.

https://bugzilla.kernel.org/show_bug.cgi?id=219495

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Jarkko Sakkinen]

On Thu Nov 7, 2024 at 2:17 PM EET, Paul Menzel wrote:
> Dear Takashi,
>
>
> Thank you for the patch.
>
> Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> > The TPM2 ACPI table may request a large size for the event log, and it
> > may be over the max size of kmalloc().  When this happens, the driver
>
> What is kmalloc()’s maximum size?

For reference: https://elixir.bootlin.com/linux/v6.11.6/source/include/linux/slab.h#L367

So it would be 1UL << 22 i.e. 4 MB at least. Not sure if MAX_PAGE_ORDER
is larger than 10 on x86-64.

BR, Jarkko

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Takashi Iwai]

On Thu, 07 Nov 2024 21:42:50 +0100,
Jarkko Sakkinen wrote:
> 
> On Thu Nov 7, 2024 at 2:17 PM EET, Paul Menzel wrote:
> > Dear Takashi,
> >
> >
> > Thank you for the patch.
> >
> > Am 07.11.24 um 12:18 schrieb Takashi Iwai:
> > > The TPM2 ACPI table may request a large size for the event log, and it
> > > may be over the max size of kmalloc().  When this happens, the driver
> >
> > What is kmalloc()’s maximum size?
> 
> For reference: https://elixir.bootlin.com/linux/v6.11.6/source/include/linux/slab.h#L367
> 
> So it would be 1UL << 22 i.e. 4 MB at least. Not sure if MAX_PAGE_ORDER
> is larger than 10 on x86-64.

Ah thanks, it has been changed.


Takashi

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Jarkko Sakkinen]

On Thu Nov 7, 2024 at 1:18 PM EET, Takashi Iwai wrote:
> The TPM2 ACPI table may request a large size for the event log, and it
> may be over the max size of kmalloc().  When this happens, the driver
> spews the kernel WARNING at the probe time, but the error is
> eventually ignored in the caller side, and it results in the missing
> TPM event log exposure.


TPM2 ACPI table is data structure ;-) Just to make the commit message
less confusing, please refer to active actors.


>
> This patch replaces the devm_kmalloc() call with kvmalloc() to allow
> larger sizes.  Since there is no devm variant for kvmalloc(), now it's
> managed manually via devres_alloc() and devres_add().
>
> Reported-and-tested-by: Andy Liang <andy.liang@hpe.com>
> Cc: jenifer.golmitz@hpe.com
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1232421

"You are not authorized to access bug #1232421. To see this bug, you must
first log in to an account with the appropriate permissions."

Please remove  this link as it gives no information without login
access, *or* make it available w/o acocunt, *or* repost a bug to the
kernel bugzilla.

I've been cursing SUSE accounts for over a year now. Never been able
to successfully get either to the bugzilla or forums (still I get
some weekly spam about the forums). And no, no interest to recall
or figure out this problem.

> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  drivers/char/tpm/eventlog/acpi.c | 21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tpm/eventlog/acpi.c b/drivers/char/tpm/eventlog/acpi.c
> index 69533d0bfb51..56f7d73fa6bf 100644
> --- a/drivers/char/tpm/eventlog/acpi.c
> +++ b/drivers/char/tpm/eventlog/acpi.c
> @@ -63,6 +63,13 @@ static bool tpm_is_tpm2_log(void *bios_event_log, u64 len)
>  	return n == 0;
>  }
>  
> +static void bios_event_log_release(struct device *dev, void *res)
> +{
> +	void **logp = res;
> +
> +	kvfree(*logp);
> +}
> +
>  /* read binary bios log */
>  int tpm_read_log_acpi(struct tpm_chip *chip)
>  {
> @@ -71,6 +78,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
>  	void __iomem *virt;
>  	u64 len, start;
>  	struct tpm_bios_log *log;
> +	void **logp;
>  	struct acpi_table_tpm2 *tbl;
>  	struct acpi_tpm2_phy *tpm2_phy;
>  	int format;
> @@ -136,9 +144,16 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
>  	}
>  
>  	/* malloc EventLog space */
> -	log->bios_event_log = devm_kmalloc(&chip->dev, len, GFP_KERNEL);
> -	if (!log->bios_event_log)
> +	logp = devres_alloc(bios_event_log_release, sizeof(*logp), GFP_KERNEL);
> +	if (!logp)
>  		return -ENOMEM;

How big is it?

> +	devres_add(&chip->dev, logp);
> +	log->bios_event_log = kvmalloc(len, GFP_KERNEL);
> +	if (!log->bios_event_log) {
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +	*logp = log->bios_event_log;
>  
>  	log->bios_event_log_end = log->bios_event_log + len;
>  
> @@ -164,7 +179,7 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
>  	return format;
>  
>  err:
> -	devm_kfree(&chip->dev, log->bios_event_log);
> +	devres_release(&chip->dev, bios_event_log_release, NULL, NULL);
>  	log->bios_event_log = NULL;
>  	return ret;
>  }

BR, Jarkko

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Jarkko Sakkinen]

On Thu Nov 7, 2024 at 10:32 PM EET, Jarkko Sakkinen wrote:
> >
> > This patch replaces the devm_kmalloc() call with kvmalloc() to allow
> > larger sizes.  Since there is no devm variant for kvmalloc(), now it's
> > managed manually via devres_alloc() and devres_add().
> >
> > Reported-and-tested-by: Andy Liang <andy.liang@hpe.com>
> > Cc: jenifer.golmitz@hpe.com
> > Link: https://bugzilla.suse.com/show_bug.cgi?id=1232421
>
> "You are not authorized to access bug #1232421. To see this bug, you must
> first log in to an account with the appropriate permissions."
>
> Please remove  this link as it gives no information without login
> access, *or* make it available w/o acocunt, *or* repost a bug to the
> kernel bugzilla.
>
> I've been cursing SUSE accounts for over a year now. Never been able
> to successfully get either to the bugzilla or forums (still I get
> some weekly spam about the forums). And no, no interest to recall
> or figure out this problem.

Just a personal recommendation but I'd create a bug to kernel bugzilla
and link that to the SUSE bug, and call it a day ;-) It would be the
least friction approach.

BR, Jarkko

Re: [PATCH] tpm/eventlog: Use kvmalloc() for event log buffer

[Takashi Iwai]

On Thu, 07 Nov 2024 21:44:17 +0100,
Jarkko Sakkinen wrote:
> 
> On Thu Nov 7, 2024 at 10:32 PM EET, Jarkko Sakkinen wrote:
> > >
> > > This patch replaces the devm_kmalloc() call with kvmalloc() to allow
> > > larger sizes.  Since there is no devm variant for kvmalloc(), now it's
> > > managed manually via devres_alloc() and devres_add().
> > >
> > > Reported-and-tested-by: Andy Liang <andy.liang@hpe.com>
> > > Cc: jenifer.golmitz@hpe.com
> > > Link: https://bugzilla.suse.com/show_bug.cgi?id=1232421
> >
> > "You are not authorized to access bug #1232421. To see this bug, you must
> > first log in to an account with the appropriate permissions."
> >
> > Please remove  this link as it gives no information without login
> > access, *or* make it available w/o acocunt, *or* repost a bug to the
> > kernel bugzilla.
> >
> > I've been cursing SUSE accounts for over a year now. Never been able
> > to successfully get either to the bugzilla or forums (still I get
> > some weekly spam about the forums). And no, no interest to recall
> > or figure out this problem.
> 
> Just a personal recommendation but I'd create a bug to kernel bugzilla
> and link that to the SUSE bug, and call it a day ;-) It would be the
> least friction approach.

Andy, care to open a new entry on bugzilla.kernel.org?


thanks,

Takashi