linux-kernel - Re: [PATCH] x86/acpi: fix panic while AP online later with kernel parameter maxcpus=1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 26 Jun 2024 15:17:14 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Zhiquan Li <zhiquan1.li@...el.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, rafael@...nel.org, hpa@...or.com, 
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/acpi: fix panic while AP online later with kernel
 parameter maxcpus=1

On Wed, Jun 26, 2024 at 03:39:20PM +0800, Zhiquan Li wrote:
> The issue was found on the platform that using "Multiprocessor Wakeup
> Structure"[1] to startup secondary CPU, which is usually used by
> encrypted guest.   When restrict boot time CPU to 1 with the kernel

Nit: too many spaces after period.

> parameter "maxcpus=1" and bring other CPUs online later, there will be
> a kernel panic as below.
> 
> The variable acpi_mp_wake_mailbox to hold the virtual address of MP
> Wakeup Structure mailbox will be set as readonly after initialization.

  The variable acpi_mp_wake_mailbox, which holds the virtual address of
  the MP Wakeup Structure mailbox, will be set as read-only after init.

> If the first AP is brought online laster, the attemption to update it
> results in panic.

  If the first AP gets online later, after init, the attempt to update
  the variable results in panic.

> Not like the physical address of MP Wakeup Structure mailbox, the
> readonly attribute is not necessary for its virtual address.

This sentence doesn't make sense to me. Just drop it.

> [1] Details about the MP Wakeup structure can be found in ACPI v6.4, in
>     the "Multiprocessor Wakeup Structure" section.
> 
>   BUG: unable to handle page fault for address: ffffffff83086978
>   #PF: supervisor write access in kernel mode
>   #PF: error_code(0x0003) - permissions violation
>   PGD 3832067 P4D 3833067 PUD 3834063 PMD 80000000030001a1
>   Oops: Oops: 0003 [#1] PREEMPT SMP NOPTI
>   CPU: 0 PID: 175 Comm: systemd-udevd Not tainted 6.10.0-rc4+ #14
>   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
>   RIP: 0010:acpi_wakeup_cpu+0xb2/0xe0
>   Call Trace:
>    <TASK>
>    ? __die+0x20/0x70
>    ? page_fault_oops+0x80/0x140
>    ? exc_page_fault+0xdc/0x180
>    ? asm_exc_page_fault+0x22/0x30
>    ? _raw_read_unlock+0x18/0x40
>    ? acpi_wakeup_cpu+0xb2/0xe0
>    do_boot_cpu+0xeb/0x1f0
>    native_kick_ap+0xcb/0x150
>    ? __pfx_cpuhp_kick_ap_alive+0x10/0x10
>    cpuhp_invoke_callback+0x2d0/0x480
>    ? __pfx_trace_rb_cpu_prepare+0x10/0x10
>    __cpuhp_invoke_callback_range+0x78/0xe0
>    cpuhp_up_callbacks+0x28/0x100
>    _cpu_up+0xb9/0x120
>    cpu_up+0x91/0xe0
>    cpu_subsys_online+0x4d/0xe0
>    device_online+0x5f/0x80
>    online_store+0x8f/0xc0
>    kernfs_fop_write_iter+0x125/0x1c0
>    vfs_write+0x35c/0x480
>    ksys_write+0x5f/0xe0
>    do_syscall_64+0x63/0x170
>    entry_SYSCALL_64_after_hwframe+0x76/0x7e

The stack dump doesn't add value to the commit message. Drop it.

But it is worth noting that the memremap() function that initializes the
variable cannot be moved into acpi_parse_mp_wake() because memremap() is
not yet functional at this point in the boot process.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov