ACPI tables are (mostly) controlled by the host and only passed through the TDVF (see TDX guest virtual firmware for more information). They are measured into TDX attestation registers, and therefore can be remotely attested and therefore can be considered trusted. However, we cannot expect that an attesting entity fully understands what causes the Linux kernel to open security holes based on some particular AML. Then a malicious hypervisor might be able to attack the guest based on attack surfaces exposed by the non-malicious and attested ACPI tables. The main concern here is the tables and methods that configure some functionality in the kernel, such as initializing drivers. In addition potentially need to look into hardening of AML interpreter.
Solution
Ideally we want to pass from a host to CoCo guest a minimal set of known/secure ACPI tables (with minimal set of AML objects). However it is not clear if this is a realistic deployment assumption.
Problem
ACPI tables are (mostly) controlled by the host and only passed through the TDVF (see TDX guest virtual firmware for more information). They are measured into TDX attestation registers, and therefore can be remotely attested and therefore can be considered trusted. However, we cannot expect that an attesting entity fully understands what causes the Linux kernel to open security holes based on some particular AML. Then a malicious hypervisor might be able to attack the guest based on attack surfaces exposed by the non-malicious and attested ACPI tables. The main concern here is the tables and methods that configure some functionality in the kernel, such as initializing drivers. In addition potentially need to look into hardening of AML interpreter.
Solution
Ideally we want to pass from a host to CoCo guest a minimal set of known/secure ACPI tables (with minimal set of AML objects). However it is not clear if this is a realistic deployment assumption.