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: <86b2aef1-8926-47c8-8a33-9f02e3dd7d72@arm.com>
Date: Wed, 30 Oct 2024 21:08:50 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: Gavin Shan <gshan@...hat.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,

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

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
>