linux-stable.git/arch/x86/kernel/setup.c, branch linux-6.6.y

x86/kexec: add a sanity check on previous kernel's ima kexec buffer

2026-06-19T11:39:14+00:00

[ Upstream commit c5489d04337b47e93c0623e8145fcba3f5739efd ]

When the second-stage kernel is booted via kexec with a limiting command
line such as "mem=", 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.

Without carrying the measurement list across kexec, the attestation
would fail.

Link: https://lkml.kernel.org/r/20251231061609.907170-4-harshit.m.mogalapalli@oracle.com
Signed-off-by: Harshit Mogalapalli 
Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
Reported-by: Paul Webb 
Reviewed-by: Mimi Zohar 
Cc: Alexander Graf 
Cc: Ard Biesheuvel 
Cc: Baoquan He 
Cc: Borislav Betkov 
Cc: guoweikang 
Cc: Henry Willard 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jiri Bohac 
Cc: Joel Granados 
Cc: Jonathan McDowell 
Cc: Mike Rapoport 
Cc: Sohil Mehta 
Cc: Sourabh Jain 
Cc: Thomas Gleinxer 
Cc: Yifei Liu 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Wenshan Lan 
Signed-off-by: Sasha Levin

Revert "x86/kexec: add a sanity check on previous kernel's ima kexec buffer"

2026-03-05T14:56:36+00:00

This reverts commit c5489d04337b47e93c0623e8145fcba3f5739efd.

The commit introduces a call to ima_validate_range() in
arch/x86/kernel/setup.c, but the function declaration is not available
in the 6.12 stable tree, resulting in build failures due to implicit
function declaration errors across multiple stable branches.

Signed-off-by: Sasha Levin

x86/kexec: add a sanity check on previous kernel's ima kexec buffer

2026-03-04T12:21:12+00:00

[ Upstream commit c5489d04337b47e93c0623e8145fcba3f5739efd ]

When the second-stage kernel is booted via kexec with a limiting command
line such as "mem=", 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.

Without carrying the measurement list across kexec, the attestation
would fail.

Link: https://lkml.kernel.org/r/20251231061609.907170-4-harshit.m.mogalapalli@oracle.com
Signed-off-by: Harshit Mogalapalli 
Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec")
Reported-by: Paul Webb 
Reviewed-by: Mimi Zohar 
Cc: Alexander Graf 
Cc: Ard Biesheuvel 
Cc: Baoquan He 
Cc: Borislav Betkov 
Cc: guoweikang 
Cc: Henry Willard 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jiri Bohac 
Cc: Joel Granados 
Cc: Jonathan McDowell 
Cc: Mike Rapoport 
Cc: Sohil Mehta 
Cc: Sourabh Jain 
Cc: Thomas Gleinxer 
Cc: Yifei Liu 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

Revert "x86, crash: wrap crash dumping code into crash related ifdefs"

2025-01-10T13:31:36+00:00

This reverts commit e5b1574a8ca28c40cf53eda43f6c3b016ed41e27 which is
commit a4eeb2176d89fdf2785851521577b94b31690a60 upstream.

When this change is backported to the 6.6.y tree, it can cause build
errors on some configurations when KEXEC is not enabled, so revert it
for now.

Reported-by: Ignat Korchagin 
Link: https://lore.kernel.org/r/3DB3A6D3-0D3A-4682-B4FA-407B2D3263B2@cloudflare.com
Reported-by: Lars Wendler 
Link: https://lore.kernel.org/r/20250110103328.0e3906a8@chagall.paradoxon.rec
Reported-by: Chris Clayton 
Link: https://lore.kernel.org/r/10c7be00-b1f8-4389-801b-fb2d0b22468d@googlemail.com
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Dexuan Cui 
Cc: Eric W. Biederman 
Cc: Hari Bathini 
Cc: Klara Modin 
Cc: Michael Kelley 
Cc: Michael Kelley 
Cc: Naman Jain 
Cc: Nathan Chancellor 
Cc: Pingfan Liu 
Cc: Sasha Levin 
Cc: Stephen Rothwell 
Cc: Wei Liu 
Cc: Yang Li 
Signed-off-by: Greg Kroah-Hartman

x86, crash: wrap crash dumping code into crash related ifdefs

2025-01-09T12:31:49+00:00

[ Upstream commit a4eeb2176d89fdf2785851521577b94b31690a60 ]

Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on x86 with some adjustments.

Here, also change some ifdefs or IS_ENABLED() check to more appropriate
ones, e,g
 - #ifdef CONFIG_KEXEC_CORE -> #ifdef CONFIG_CRASH_DUMP
 - (!IS_ENABLED(CONFIG_KEXEC_CORE)) - > (!IS_ENABLED(CONFIG_CRASH_RESERVE))

[bhe@redhat.com: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope]
  Link: https://lore.kernel.org/all/SN6PR02MB4157931105FA68D72E3D3DB8D47B2@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u
Link: https://lkml.kernel.org/r/20240124051254.67105-7-bhe@redhat.com
Signed-off-by: Baoquan He 
Cc: Al Viro 
Cc: Eric W. Biederman 
Cc: Hari Bathini 
Cc: Pingfan Liu 
Cc: Klara Modin 
Cc: Michael Kelley 
Cc: Nathan Chancellor 
Cc: Stephen Rothwell 
Cc: Yang Li 
Signed-off-by: Andrew Morton 
Stable-dep-of: bcc80dec91ee ("x86/hyperv: Fix hv tsc page based sched_clock for hibernation")
Signed-off-by: Sasha Levin

x86/coco: Require seeding RNG with RDRAND on CoCo systems

2024-04-10T14:36:03+00:00

commit 99485c4c026f024e7cb82da84c7951dbe3deb584 upstream.

There are few uses of CoCo that don't rely on working cryptography and
hence a working RNG. Unfortunately, the CoCo threat model means that the
VM host cannot be trusted and may actively work against guests to
extract secrets or manipulate computation. Since a malicious host can
modify or observe nearly all inputs to guests, the only remaining source
of entropy for CoCo guests is RDRAND.

If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole
is meant to gracefully continue on gathering entropy from other sources,
but since there aren't other sources on CoCo, this is catastrophic.
This is mostly a concern at boot time when initially seeding the RNG, as
after that the consequences of a broken RDRAND are much more
theoretical.

So, try at boot to seed the RNG using 256 bits of RDRAND output. If this
fails, panic(). This will also trigger if the system is booted without
RDRAND, as RDRAND is essential for a safe CoCo boot.

Add this deliberately to be "just a CoCo x86 driver feature" and not
part of the RNG itself. Many device drivers and platforms have some
desire to contribute something to the RNG, and add_device_randomness()
is specifically meant for this purpose.

Any driver can call it with seed data of any quality, or even garbage
quality, and it can only possibly make the quality of the RNG better or
have no effect, but can never make it worse.

Rather than trying to build something into the core of the RNG, consider
the particular CoCo issue just a CoCo issue, and therefore separate it
all out into driver (well, arch/platform) code.

  [ bp: Massage commit message. ]

Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Elena Reshetova 
Reviewed-by: Kirill A. Shutemov 
Reviewed-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240326160735.73531-1-Jason@zx2c4.com
Signed-off-by: Greg Kroah-Hartman

x86/sev: Skip ROM range scans and validation for SEV-SNP guests

2024-04-03T13:29:03+00:00

commit 0f4a1e80989aca185d955fcd791d7750082044a2 upstream.

SEV-SNP requires encrypted memory to be validated before access.
Because the ROM memory range is not part of the e820 table, it is not
pre-validated by the BIOS. Therefore, if a SEV-SNP guest kernel wishes
to access this range, the guest must first validate the range.

The current SEV-SNP code does indeed scan the ROM range during early
boot and thus attempts to validate the ROM range in probe_roms().
However, this behavior is neither sufficient nor necessary for the
following reasons:

* With regards to sufficiency, if EFI_CONFIG_TABLES are not enabled and
  CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK is set, the kernel will
  attempt to access the memory at SMBIOS_ENTRY_POINT_SCAN_START (which
  falls in the ROM range) prior to validation.

  For example, Project Oak Stage 0 provides a minimal guest firmware
  that currently meets these configuration conditions, meaning guests
  booting atop Oak Stage 0 firmware encounter a problematic call chain
  during dmi_setup() -> dmi_scan_machine() that results in a crash
  during boot if SEV-SNP is enabled.

* With regards to necessity, SEV-SNP guests generally read garbage
  (which changes across boots) from the ROM range, meaning these scans
  are unnecessary. The guest reads garbage because the legacy ROM range
  is unencrypted data but is accessed via an encrypted PMD during early
  boot (where the PMD is marked as encrypted due to potentially mapping
  actually-encrypted data in other PMD-contained ranges).

In one exceptional case, EISA probing treats the ROM range as
unencrypted data, which is inconsistent with other probing.

Continuing to allow SEV-SNP guests to use garbage and to inconsistently
classify ROM range encryption status can trigger undesirable behavior.
For instance, if garbage bytes appear to be a valid signature, memory
may be unnecessarily reserved for the ROM range. Future code or other
use cases may result in more problematic (arbitrary) behavior that
should be avoided.

While one solution would be to overhaul the early PMD mapping to always
treat the ROM region of the PMD as unencrypted, SEV-SNP guests do not
currently rely on data from the ROM region during early boot (and even
if they did, they would be mostly relying on garbage data anyways).

As a simpler solution, skip the ROM range scans (and the otherwise-
necessary range validation) during SEV-SNP guest early boot. The
potential SEV-SNP guest crash due to lack of ROM range validation is
thus avoided by simply not accessing the ROM range.

In most cases, skip the scans by overriding problematic x86_init
functions during sme_early_init() to SNP-safe variants, which can be
likened to x86_init overrides done for other platforms (ex: Xen); such
overrides also avoid the spread of cc_platform_has() checks throughout
the tree.

In the exceptional EISA case, still use cc_platform_has() for the
simplest change, given (1) checks for guest type (ex: Xen domain status)
are already performed here, and (2) these checks occur in a subsys
initcall instead of an x86_init function.

  [ bp: Massage commit message, remove "we"s. ]

Fixes: 9704c07bf9f7 ("x86/kernel: Validate ROM memory before accessing when SEV-SNP is active")
Signed-off-by: Kevin Loughlin 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://lore.kernel.org/r/20240313121546.2964854-1-kevinloughlin@google.com
Signed-off-by: Kevin Loughlin 
Signed-off-by: Greg Kroah-Hartman

x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer()

2023-09-18T07:24:15+00:00

The code calling ima_free_kexec_buffer() runs long after the memblock
allocator has already been torn down, potentially resulting in a use
after free in memblock_isolate_range().

With KASAN or KFENCE, this use after free will result in a BUG
from the idle task, and a subsequent kernel panic.

Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid
that bug.

Fixes: fee3ff99bc67 ("powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c")
Suggested-by: Mike Rappoport 
Signed-off-by: Rik van Riel 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20230817135558.67274c83@imladris.surriel.com

x86/apic: Provide apic_update_callback()

2023-08-09T19:00:46+00:00

There are already two variants of update mechanism for particular callbacks
and virtualization just writes into the data structure.

Provide an interface and use a shadow data structure to preserve callbacks
so they can be reapplied when the APIC driver is replaced.

The extra data structure is intentional as any new callback needs to be
also updated in the core code. This also prepares for static calls.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Dave Hansen 
Acked-by: Peter Zijlstra (Intel) 
Tested-by: Michael Kelley 
Tested-by: Sohil Mehta 
Tested-by: Juergen Gross  # Xen PV (dom0 and unpriv. guest)

x86/apic: Mop up *setup_apic_routing()

2023-08-09T18:58:26+00:00

default_setup_apic_routing() is a complete misnomer. On 64bit it does the
actual APIC probing and on 32bit it is used to force select the bigsmp APIC
and to emit a redundant message in the apic::setup_apic_routing() callback.

Rename the 64bit and 32bit function so they reflect what they are doing and
remove the useless APIC callback.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Dave Hansen 
Acked-by: Peter Zijlstra (Intel) 
Tested-by: Michael Kelley 
Tested-by: Sohil Mehta 
Tested-by: Juergen Gross  # Xen PV (dom0 and unpriv. guest)