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

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]

Message-ID: <98b47e47-9014-45d1-86c7-4b78ff36bf54@redhat.com>
Date: Thu, 31 Oct 2024 08:48:05 +1000
From: Gavin Shan <gshan@...hat.com>
To: Jeremy Linton <jeremy.linton@....com>,
 linux-arm-kernel@...ts.infradead.org
Cc: steven.price@....com, suzuki.poulose@....com, catalin.marinas@....com,
 will@...nel.org, sami.mujawar@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: rsi: Add automatic arm-cca-guest module loading

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@....com>
>>> ---
>>>   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.

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