On 10/29/24 7:23 PM, Gavin Shan wrote:
On 10/30/24 12:11 AM, Jeremy Linton wrote:
The TSM module provides both guest identification as well as
attestation when a guest is run in CCA mode. Lets assure by creating a
dummy platform device that the module is automatically loaded during
boot. Once it is in place it can be used earlier in the boot process
to say decrypt a LUKS rootfs.
Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
---
arch/arm64/include/asm/rsi.h | 2 ++
arch/arm64/kernel/rsi.c | 15 +++++++++++++++
drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 7 +++++++
3 files changed, 24 insertions(+)
I don't understand how the TSM module is automatically loaded and arm_cca_guest_init()
is triggered because of the newly introduced platform device. Could you please provide
more details? Apart from it, some nick-picks as below.
I think your asking how the module boilerplate here works, AKA how the standard uevent/udev/modalias/kmod stuff works? The short version is that the platform bus uevents an add device with a modalias and userspace udev + kmod finds matching modules, and their dependencies, and loads them which triggers the module_init() calls.
The suse folks have a detailed description of how this works:
https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-udev.html#sec-udev-kernel
So, this is a fairly common misuse of the platform bus, in this case to avoid needing a HWCAP. Assuring the module exists in the initrd will then result in it being loaded along any other modules required for the rootfs pivot.