Re: [PATCH] arm64: rsi: Add automatic arm-cca-guest module loading

[Jeremy Linton]

Hi,

On 10/30/24 5:48 PM, Gavin Shan wrote:
> Hi Jeremy,
>
> On 10/31/24 1:16 AM, Jeremy Linton wrote:
> > 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.
>
> Thanks for the explanation and details. The module won't be 
> automatically loaded if
> udev daemon isn't in place or the DEV_ADD event is ignored for whatever 
> reasons. For
> example the corresponding ACTION for DEV_ADD of this particular device 
> is null in the
> udev rules. So it's not guranteed that the module can be automatically 
> loaded until udev
> is in place and udev rules have been configured properly. It's a best- 
> effort attempt
> if I don't miss anything.

This functionality has been standard in all but the most deeply 
enmbedded linux systems for a couple decades now (AFAIK). The platform 
and modalias logic should largely just work everywhere that its 
appropriate to be building this as a module. And to be clear that is 
without updating any of the existing rules.

> Could you please update the change log to mention the automatic module 
> loading depends
> on udev and its rules? In this way, readers will know it's a best-effort 
> attempt at least.
>
> Thanks,
> Gavin