Re: [PATCH v5 02/22] cc_platform: Add new attribute to prevent ACPI CPU hotplug
From: Binbin Wu
Date: Tue Aug 02 2022 - 23:41:21 EST
On 2022/6/27 13:05, Kai Huang wrote:
On Fri, 2022-06-24 at 11:57 -0700, Dave Hansen wrote:
On 6/22/22 04:15, Kai Huang wrote:
Platforms with confidential computing technology may not support ACPI
CPU hotplug when such technology is enabled by the BIOS. Examples
include Intel platforms which support Intel Trust Domain Extensions
(TDX).
If the kernel ever receives ACPI CPU hotplug event, it is likely a BIOS
bug. For ACPI CPU hot-add, the kernel should speak out this is a BIOS
bug and reject the new CPU. For hot-removal, for simplicity just assume
the kernel cannot continue to work normally, and BUG().
So, the kernel is now declaring ACPI CPU hotplug and TDX to be
incompatible and even BUG()'ing if we see them together. Has anyone
told the firmware guys about this? Is this in a spec somewhere? When
the kernel goes boom, are the firmware folks going to cry "Kernel bug!!"?
This doesn't seem like something the kernel should be doing unilaterally.
TDX doesn't support ACPI CPU hotplug (both hot-add and hot-removal) is an
architectural behaviour. The public specs doesn't explicitly say it, but it is
implied:
1) During platform boot MCHECK verifies all logical CPUs on all packages that
they are TDX compatible, and it keeps some information, such as total CPU
packages and total logical cpus at some location of SEAMRR so it can later be
used by P-SEAMLDR and TDX module. Please see "3.4 SEAMLDR_SEAMINFO" in the P-
SEAMLDR spec:
https://cdrdv2.intel.com/v1/dl/getContent/733584
2) Also some SEAMCALLs must be called on all logical CPUs or CPU packages that
the platform has (such as such as TDH.SYS.INIT.LP and TDH.SYS.KEY.CONFIG),
otherwise the further step of TDX module initialization will fail.
Unfortunately there's no public spec mentioning what's the behaviour of ACPI CPU
hotplug on TDX enabled platform. For instance, whether BIOS will ever get the
ACPI CPU hot-plug event, or if BIOS gets the event, will it suppress it. What I
got from Intel internally is a non-buggy BIOS should never report such event to
the kernel, so if kernel receives such event, it should be fair enough to treat
it as BIOS bug.
But theoretically, the BIOS isn't in TDX's TCB, and can be from 3rd party..
Also, I was told "CPU hot-plug is a system feature, not a CPU feature or Intel
architecture feature", so Intel doesn't have an architectural specification for
CPU hot-plug.
At the meantime, I am pushing Intel internally to add some statements regarding
to the TDX and CPU hotplug interaction to the BIOS write guide and make it
public. I guess this is the best thing we can do.
Regarding to the code change, I agree the BUG() isn't good. I used it because:
1) this basically on a theoretical problem and shouldn't happen in practice; 2)
because there's no architectural specification regarding to the behaviour of TDX
when CPU hot-removal, so I just used BUG() in assumption that TDX isn't safe to
use anymore.
host kernel is also not in TDX's TCB either, what would happen if kernel
doesn't
do anything in case of buggy BIOS? How does TDX handle the case to
enforce the
secure of TDs?
But Rafael doesn't like current code change either. I think maybe we can just
disable CPU hotplug code when TDX is enabled by BIOS (something like below):
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -707,6 +707,10 @@ bool acpi_duplicate_processor_id(int proc_id)
void __init acpi_processor_init(void)
{
acpi_processor_check_duplicates();
+
+ if (cc_platform_has(CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED))
+ return;
+
acpi_scan_add_handler_with_hotplug(&processor_handler, "processor");
acpi_scan_add_handler(&processor_container_handler);
}
This approach is cleaner I think, but we won't be able to report "BIOS bug" when
ACPI CPU hotplug happens. But to me it's OK as perhaps it's arguable to treat
it as BIOS bug (as theoretically BIOS can be from 3rd party).
What's your opinion?