mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
@ 2025-11-12 19:30 Harshit Mogalapalli
  2025-12-01  9:33 ` Harshit Mogalapalli
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Harshit Mogalapalli @ 2025-11-12 19:30 UTC (permalink / raw)
  To: henry.willard, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86, H. Peter Anvin, Andrew Morton,
	Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Harshit Mogalapalli,
	Mimi Zohar, Jonathan McDowell, linux-kernel
  Cc: yifei.l.liu, stable, Paul Webb

When the second-stage kernel is booted via kexec with a limiting command
line such as "mem=<size>", the physical range that contains the carried
over IMA measurement list may fall outside the truncated RAM leading to
a kernel panic.

    BUG: unable to handle page fault for address: ffff97793ff47000
    RIP: ima_restore_measurement_list+0xdc/0x45a
    #PF: error_code(0x0000) – not-present page

Other architectures already validate the range with page_is_ram(), as
done in commit: cbf9c4b9617b ("of: check previous kernel's
ima-kexec-buffer against memory bounds") do a similar check on x86.

Cc: stable@vger.kernel.org
Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
Reported-by: Paul Webb <paul.x.webb@oracle.com>
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
---
Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the
above patch works good. Paul initially reported this on 6.12 kernel but
I was able to reproduce this on 6.18, so I tried replicating how this
was fixed in drivers/of/kexec.c
---
 arch/x86/kernel/setup.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1b2edd07a3e1..fcef197d180e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
 
 int __init ima_get_kexec_buffer(void **addr, size_t *size)
 {
+	unsigned long start_pfn, end_pfn;
+
 	if (!ima_kexec_buffer_size)
 		return -ENOENT;
 
+	/*
+	 * Calculate the PFNs for the buffer and ensure
+	 * they are with in addressable memory.
+	 */
+	start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
+	end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
+	if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
+		pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",
+			ima_kexec_buffer_phys, ima_kexec_buffer_size);
+		return -EINVAL;
+	}
+
 	*addr = __va(ima_kexec_buffer_phys);
 	*size = ima_kexec_buffer_size;
 
-- 
2.50.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-11-12 19:30 [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer Harshit Mogalapalli
@ 2025-12-01  9:33 ` Harshit Mogalapalli
  2025-12-01 21:43   ` Mimi Zohar
  2025-12-01 11:22 ` Jonathan McDowell
  2025-12-01 17:20 ` Andrew Morton
  2 siblings, 1 reply; 9+ messages in thread
From: Harshit Mogalapalli @ 2025-12-01  9:33 UTC (permalink / raw)
  To: henry.willard, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86, H. Peter Anvin, Andrew Morton,
	Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Mimi Zohar,
	Jonathan McDowell, linux-kernel
  Cc: yifei.l.liu, stable, Paul Webb

Hi all,

On 13/11/25 01:00, Harshit Mogalapalli wrote:
> When the second-stage kernel is booted via kexec with a limiting command
> line such as "mem=<size>", the physical range that contains the carried
> over IMA measurement list may fall outside the truncated RAM leading to
> a kernel panic.
> 
>      BUG: unable to handle page fault for address: ffff97793ff47000
>      RIP: ima_restore_measurement_list+0xdc/0x45a
>      #PF: error_code(0x0000) – not-present page
> 
> Other architectures already validate the range with page_is_ram(), as
> done in commit: cbf9c4b9617b ("of: check previous kernel's
> ima-kexec-buffer against memory bounds") do a similar check on x86.
> 
> Cc: stable@vger.kernel.org
> Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
> Reported-by: Paul Webb <paul.x.webb@oracle.com>
> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
> ---
> Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the
> above patch works good. Paul initially reported this on 6.12 kernel but
> I was able to reproduce this on 6.18, so I tried replicating how this
> was fixed in drivers/of/kexec.c

ping on this patch.

lore URL: 
https://lore.kernel.org/all/20251112193005.3772542-1-harshit.m.mogalapalli@oracle.com/

Thanks,
Harshit


> ---
>   arch/x86/kernel/setup.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 1b2edd07a3e1..fcef197d180e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
>   
>   int __init ima_get_kexec_buffer(void **addr, size_t *size)
>   {
> +	unsigned long start_pfn, end_pfn;
> +
>   	if (!ima_kexec_buffer_size)
>   		return -ENOENT;
>   
> +	/*
> +	 * Calculate the PFNs for the buffer and ensure
> +	 * they are with in addressable memory.
> +	 */
> +	start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
> +	end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
> +	if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
> +		pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",
> +			ima_kexec_buffer_phys, ima_kexec_buffer_size);
> +		return -EINVAL;
> +	}
> +
>   	*addr = __va(ima_kexec_buffer_phys);
>   	*size = ima_kexec_buffer_size;
>   


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-11-12 19:30 [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer Harshit Mogalapalli
  2025-12-01  9:33 ` Harshit Mogalapalli
@ 2025-12-01 11:22 ` Jonathan McDowell
  2025-12-01 17:20 ` Andrew Morton
  2 siblings, 0 replies; 9+ messages in thread
From: Jonathan McDowell @ 2025-12-01 11:22 UTC (permalink / raw)
  To: Harshit Mogalapalli
  Cc: henry.willard, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86, H. Peter Anvin, Andrew Morton,
	Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Mimi Zohar,
	Jonathan McDowell, linux-kernel, yifei.l.liu, stable, Paul Webb

On Wed, Nov 12, 2025 at 11:30:02AM -0800, Harshit Mogalapalli wrote:
> > 
> When the second-stage kernel is booted via kexec with a limiting command
> line such as "mem=<size>", the physical range that contains the carried
> over IMA measurement list may fall outside the truncated RAM leading to
> a kernel panic.
> 
>     BUG: unable to handle page fault for address: ffff97793ff47000
>     RIP: ima_restore_measurement_list+0xdc/0x45a
>     #PF: error_code(0x0000) – not-present page
> 
> Other architectures already validate the range with page_is_ram(), as
> done in commit: cbf9c4b9617b ("of: check previous kernel's
> ima-kexec-buffer against memory bounds") do a similar check on x86.
> 
> Cc: stable@vger.kernel.org
> Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
> Reported-by: Paul Webb <paul.x.webb@oracle.com>
> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>

Seems legit; this applies on the loaded kernel side, so we do end up
losing the measurements but that matches what OF does.

Reviewed-by: Jonathan McDowell <noodles@meta.com>

> ---
> Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the
> above patch works good. Paul initially reported this on 6.12 kernel but
> I was able to reproduce this on 6.18, so I tried replicating how this
> was fixed in drivers/of/kexec.c
> ---
>  arch/x86/kernel/setup.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 1b2edd07a3e1..fcef197d180e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
>  
>  int __init ima_get_kexec_buffer(void **addr, size_t *size)
>  {
> +	unsigned long start_pfn, end_pfn;
> +
>  	if (!ima_kexec_buffer_size)
>  		return -ENOENT;
>  
> +	/*
> +	 * Calculate the PFNs for the buffer and ensure
> +	 * they are with in addressable memory.
> +	 */
> +	start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
> +	end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
> +	if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
> +		pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",
> +			ima_kexec_buffer_phys, ima_kexec_buffer_size);
> +		return -EINVAL;
> +	}
> +
>  	*addr = __va(ima_kexec_buffer_phys);
>  	*size = ima_kexec_buffer_size;
>  
> -- 
> 2.50.1
> 

-- 
Jonathan McDowell (he/him/his)
Production Engineer | PE Host Integrity
Meta | Facebook UK Ltd

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-11-12 19:30 [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer Harshit Mogalapalli
  2025-12-01  9:33 ` Harshit Mogalapalli
  2025-12-01 11:22 ` Jonathan McDowell
@ 2025-12-01 17:20 ` Andrew Morton
  2025-12-01 18:19   ` Borislav Petkov
  2 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2025-12-01 17:20 UTC (permalink / raw)
  To: Harshit Mogalapalli
  Cc: henry.willard, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86, H. Peter Anvin, Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Mimi Zohar,
	Jonathan McDowell, linux-kernel, yifei.l.liu, stable, Paul Webb

On Wed, 12 Nov 2025 11:30:02 -0800 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> wrote:

> When the second-stage kernel is booted via kexec with a limiting command
> line such as "mem=<size>", the physical range that contains the carried
> over IMA measurement list may fall outside the truncated RAM leading to
> a kernel panic.
> 
>     BUG: unable to handle page fault for address: ffff97793ff47000
>     RIP: ima_restore_measurement_list+0xdc/0x45a
>     #PF: error_code(0x0000) – not-present page
> 
> Other architectures already validate the range with page_is_ram(), as
> done in commit: cbf9c4b9617b ("of: check previous kernel's
> ima-kexec-buffer against memory bounds") do a similar check on x86.

Thanks.

> Cc: stable@vger.kernel.org
> Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")

That was via the x86 tree so I assume the x86 team (Boris?) will be
processing this patch.

I'll put it into mm.git's mm-hotfixes branch for now, to get a bit of
testing and to generally track its progress.

> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
>  
>  int __init ima_get_kexec_buffer(void **addr, size_t *size)
>  {
> +	unsigned long start_pfn, end_pfn;
> +
>  	if (!ima_kexec_buffer_size)
>  		return -ENOENT;
>  
> +	/*
> +	 * Calculate the PFNs for the buffer and ensure
> +	 * they are with in addressable memory.

"within" ;)

> +	 */
> +	start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
> +	end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
> +	if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
> +		pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",
> +			ima_kexec_buffer_phys, ima_kexec_buffer_size);
> +		return -EINVAL;
> +	}
> +
>  	*addr = __va(ima_kexec_buffer_phys);
>  	*size = ima_kexec_buffer_size;


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-12-01 17:20 ` Andrew Morton
@ 2025-12-01 18:19   ` Borislav Petkov
  2025-12-29  8:06     ` Harshit Mogalapalli
  0 siblings, 1 reply; 9+ messages in thread
From: Borislav Petkov @ 2025-12-01 18:19 UTC (permalink / raw)
  To: Andrew Morton, Harshit Mogalapalli
  Cc: henry.willard, Thomas Gleixner, Ingo Molnar, Dave Hansen, x86,
	H. Peter Anvin, Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Mimi Zohar,
	Jonathan McDowell, linux-kernel, yifei.l.liu, stable, Paul Webb

On Mon, Dec 01, 2025 at 09:20:20AM -0800, Andrew Morton wrote:
> On Wed, 12 Nov 2025 11:30:02 -0800 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> wrote:
> 
> > When the second-stage kernel is booted via kexec with a limiting command
> > line such as "mem=<size>", the physical range that contains the carried
> > over IMA measurement list may fall outside the truncated RAM leading to
> > a kernel panic.
> > 
> >     BUG: unable to handle page fault for address: ffff97793ff47000
> >     RIP: ima_restore_measurement_list+0xdc/0x45a
> >     #PF: error_code(0x0000) – not-present page
> > 
> > Other architectures already validate the range with page_is_ram(), as
> > done in commit: cbf9c4b9617b ("of: check previous kernel's
> > ima-kexec-buffer against memory bounds") do a similar check on x86.

Then why isn't there a ima_validate_range() function there which everyone
calls instead of the same check being replicated everywhere?

> > Cc: stable@vger.kernel.org
> > Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
> 
> That was via the x86 tree so I assume the x86 team (Boris?) will be
> processing this patch.

Yeah, it is on my to-deal-with-after-the-merge-window pile.

But since you've forced my hand... :-P

> I'll put it into mm.git's mm-hotfixes branch for now, to get a bit of
> testing and to generally track its progress.
> 
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
> >  
> >  int __init ima_get_kexec_buffer(void **addr, size_t *size)
> >  {
> > +	unsigned long start_pfn, end_pfn;
> > +
> >  	if (!ima_kexec_buffer_size)
> >  		return -ENOENT;
> >  
> > +	/*
> > +	 * Calculate the PFNs for the buffer and ensure
> > +	 * they are with in addressable memory.
> 
> "within" ;)
> 
> > +	 */
> > +	start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
> > +	end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
> > +	if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
> > +		pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",

This error message needs to be made a lot more user-friendly.

And pls do a generic helper as suggested above which ima code calls.

And by looking at the diff, there are two ima_get_kexec_buffer() functions in
the tree which could use some unification too ontop.

Right?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-12-01  9:33 ` Harshit Mogalapalli
@ 2025-12-01 21:43   ` Mimi Zohar
  2025-12-02  7:16     ` Ard Biesheuvel
  0 siblings, 1 reply; 9+ messages in thread
From: Mimi Zohar @ 2025-12-01 21:43 UTC (permalink / raw)
  To: Harshit Mogalapalli, henry.willard, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andrew Morton,
	Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Jonathan McDowell,
	linux-kernel
  Cc: yifei.l.liu, stable, Paul Webb

On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
> Hi all,
> 
> On 13/11/25 01:00, Harshit Mogalapalli wrote:
> > When the second-stage kernel is booted via kexec with a limiting command
> > line such as "mem=<size>", the physical range that contains the carried
> > over IMA measurement list may fall outside the truncated RAM leading to
> > a kernel panic.
> > 
> >      BUG: unable to handle page fault for address: ffff97793ff47000
> >      RIP: ima_restore_measurement_list+0xdc/0x45a
> >      #PF: error_code(0x0000) – not-present page
> > 
> > Other architectures already validate the range with page_is_ram(), as
> > done in commit: cbf9c4b9617b ("of: check previous kernel's
> > ima-kexec-buffer against memory bounds") do a similar check on x86.

It should be obvious that without carrying the measurement list across kexec,
that attestation will fail.  Please mentioned it here in the patch description.

> > 
> > Cc: stable@vger.kernel.org
> > Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
> > Reported-by: Paul Webb <paul.x.webb@oracle.com>
> > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>

Tested-by: Mimi Zohar <zohar@linux.ibm.com>
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-12-01 21:43   ` Mimi Zohar
@ 2025-12-02  7:16     ` Ard Biesheuvel
  2025-12-02 19:10       ` Mimi Zohar
  0 siblings, 1 reply; 9+ messages in thread
From: Ard Biesheuvel @ 2025-12-02  7:16 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Harshit Mogalapalli, henry.willard, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andrew Morton,
	Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Joel Granados,
	Alexander Graf, Sohil Mehta, Jonathan McDowell, linux-kernel,
	yifei.l.liu, stable, Paul Webb

On Mon, 1 Dec 2025 at 22:43, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
> > Hi all,
> >
> > On 13/11/25 01:00, Harshit Mogalapalli wrote:
> > > When the second-stage kernel is booted via kexec with a limiting command
> > > line such as "mem=<size>", the physical range that contains the carried
> > > over IMA measurement list may fall outside the truncated RAM leading to
> > > a kernel panic.
> > >
> > >      BUG: unable to handle page fault for address: ffff97793ff47000
> > >      RIP: ima_restore_measurement_list+0xdc/0x45a
> > >      #PF: error_code(0x0000) – not-present page
> > >
> > > Other architectures already validate the range with page_is_ram(), as
> > > done in commit: cbf9c4b9617b ("of: check previous kernel's
> > > ima-kexec-buffer against memory bounds") do a similar check on x86.
>
> It should be obvious that without carrying the measurement list across kexec,
> that attestation will fail.  Please mentioned it here in the patch description.
>

Couldn't we just use memremap() and be done with it? That will use the
direct map if the memory is mapped, or vmap() it otherwise.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-12-02  7:16     ` Ard Biesheuvel
@ 2025-12-02 19:10       ` Mimi Zohar
  0 siblings, 0 replies; 9+ messages in thread
From: Mimi Zohar @ 2025-12-02 19:10 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Harshit Mogalapalli, henry.willard, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andrew Morton,
	Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Joel Granados,
	Alexander Graf, Sohil Mehta, Jonathan McDowell, linux-kernel,
	yifei.l.liu, stable, Paul Webb, Roberto Sassu, linux-integrity

[Cc: Roberto Sassu, linux-integrity]

On Tue, 2025-12-02 at 08:16 +0100, Ard Biesheuvel wrote:
> On Mon, 1 Dec 2025 at 22:43, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
> > > Hi all,
> > > 
> > > On 13/11/25 01:00, Harshit Mogalapalli wrote:
> > > > When the second-stage kernel is booted via kexec with a limiting command
> > > > line such as "mem=<size>", the physical range that contains the carried
> > > > over IMA measurement list may fall outside the truncated RAM leading to
> > > > a kernel panic.
> > > > 
> > > >      BUG: unable to handle page fault for address: ffff97793ff47000
> > > >      RIP: ima_restore_measurement_list+0xdc/0x45a
> > > >      #PF: error_code(0x0000) – not-present page
> > > > 
> > > > Other architectures already validate the range with page_is_ram(), as
> > > > done in commit: cbf9c4b9617b ("of: check previous kernel's
> > > > ima-kexec-buffer against memory bounds") do a similar check on x86.
> > 
> > It should be obvious that without carrying the measurement list across kexec,
> > that attestation will fail.  Please mention it here in the patch description.
> > 
> 
> Couldn't we just use memremap() and be done with it? That will use the
> direct map if the memory is mapped, or vmap() it otherwise.

No, the IMA measurement list is not a continuous buffer, but a linked list of
records with varying types of fields and field sizes.  The call to
ima_dump_measurement_list() marshals the measurement list into a buffer, while
ima_restore_measurement_list() unmarshals it.

-- 
thanks,

Mimi


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer
  2025-12-01 18:19   ` Borislav Petkov
@ 2025-12-29  8:06     ` Harshit Mogalapalli
  0 siblings, 0 replies; 9+ messages in thread
From: Harshit Mogalapalli @ 2025-12-29  8:06 UTC (permalink / raw)
  To: Borislav Petkov, Andrew Morton, Jonathan McDowell
  Cc: henry.willard, Thomas Gleixner, Ingo Molnar, Dave Hansen, x86,
	H. Peter Anvin, Mike Rapoport (Microsoft),
	Jiri Bohac, Sourabh Jain, Guo Weikang, Ard Biesheuvel,
	Joel Granados, Alexander Graf, Sohil Mehta, Mimi Zohar,
	linux-kernel, yifei.l.liu, stable, Paul Webb

Hi all,

On 01/12/25 23:49, Borislav Petkov wrote:
> On Mon, Dec 01, 2025 at 09:20:20AM -0800, Andrew Morton wrote:
>> On Wed, 12 Nov 2025 11:30:02 -0800 Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> wrote:
>>
>>> When the second-stage kernel is booted via kexec with a limiting command
>>> line such as "mem=<size>", the physical range that contains the carried
>>> over IMA measurement list may fall outside the truncated RAM leading to
>>> a kernel panic.
>>>
>>>      BUG: unable to handle page fault for address: ffff97793ff47000
>>>      RIP: ima_restore_measurement_list+0xdc/0x45a
>>>      #PF: error_code(0x0000) – not-present page
>>>
>>> Other architectures already validate the range with page_is_ram(), as
>>> done in commit: cbf9c4b9617b ("of: check previous kernel's
>>> ima-kexec-buffer against memory bounds") do a similar check on x86.
> 
> Then why isn't there a ima_validate_range() function there which everyone
> calls instead of the same check being replicated everywhere?
> 

Thanks for the reviews.

Sure, have tried this, will send a V2 with a generic helper.

>>> Cc: stable@vger.kernel.org
>>> Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
>>
>> That was via the x86 tree so I assume the x86 team (Boris?) will be
>> processing this patch.
> 
> Yeah, it is on my to-deal-with-after-the-merge-window pile.
> 
> But since you've forced my hand... :-P
> 
>> I'll put it into mm.git's mm-hotfixes branch for now, to get a bit of
>> testing and to generally track its progress.
>>
>>> --- a/arch/x86/kernel/setup.c
>>> +++ b/arch/x86/kernel/setup.c
>>> @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void)
>>>   
>>>   int __init ima_get_kexec_buffer(void **addr, size_t *size)
>>>   {
>>> +	unsigned long start_pfn, end_pfn;
>>> +
>>>   	if (!ima_kexec_buffer_size)
>>>   		return -ENOENT;
>>>   
>>> +	/*
>>> +	 * Calculate the PFNs for the buffer and ensure
>>> +	 * they are with in addressable memory.
>>
>> "within" ;)
>>

Thanks for spotting.

>>> +	 */
>>> +	start_pfn = PFN_DOWN(ima_kexec_buffer_phys);
>>> +	end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1);
>>> +	if (!pfn_range_is_mapped(start_pfn, end_pfn)) {
>>> +		pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n",
> 
> This error message needs to be made a lot more user-friendly.
> 
> And pls do a generic helper as suggested above which ima code calls.
> 

Will do, thanks for the suggestion.

> And by looking at the diff, there are two ima_get_kexec_buffer() functions in
> the tree which could use some unification too ontop.
> 

In drivers/of/kexec.c we have:

int __init ima_get_kexec_buffer(void **addr, size_t *size)
{
         int ret, len;
         unsigned long tmp_addr;
         unsigned long start_pfn, end_pfn;
         size_t tmp_size;
         const void *prop;

         prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", &len);
         if (!prop)
                 return -ENOENT;

         ret = do_get_kexec_buffer(prop, len, &tmp_addr, &tmp_size);
         if (ret)
                 return ret;

         /* Do some sanity on the returned size for the ima-kexec buffer */
         if (!tmp_size)
                 return -ENOENT;

         /*
          * Calculate the PFNs for the buffer and ensure
          * they are with in addressable memory.
          */
         start_pfn = PHYS_PFN(tmp_addr);
         end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
         if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) {
                 pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond 
memory\n",
                         tmp_addr, tmp_size);
                 return -EINVAL;
         }

         *addr = __va(tmp_addr);
         *size = tmp_size;

         return 0;
}

In arch/x86/kernel/setup.c we have something like:

int __init ima_get_kexec_buffer(void **addr, size_t *size)
{
         if (!ima_kexec_buffer_size)
                 return -ENOENT;

         *addr = __va(ima_kexec_buffer_phys);
         *size = ima_kexec_buffer_size;

         return 0;
}

I will try to generalize common parts in another patch.

Will send a V2 adding ima_validate_range() helper.

Thanks,
Harshit.

> Right?
> 
> Thx.
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-12-29  8:07 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-12 19:30 [PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer Harshit Mogalapalli
2025-12-01  9:33 ` Harshit Mogalapalli
2025-12-01 21:43   ` Mimi Zohar
2025-12-02  7:16     ` Ard Biesheuvel
2025-12-02 19:10       ` Mimi Zohar
2025-12-01 11:22 ` Jonathan McDowell
2025-12-01 17:20 ` Andrew Morton
2025-12-01 18:19   ` Borislav Petkov
2025-12-29  8:06     ` Harshit Mogalapalli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®