| Message ID | 20241107112054.28448-1-tiwai@suse.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | tpm/eventlog: Use kvmalloc() for event log buffer | expand |
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
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
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.
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. > >
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
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
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
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
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
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
> 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
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
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 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(-)