public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: Gavin Shan <gshan@redhat.com>, linux-arm-kernel@lists.infradead.org
Cc: steven.price@arm.com, suzuki.poulose@arm.com,
	catalin.marinas@arm.com, will@kernel.org, sami.mujawar@arm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: rsi: Add automatic arm-cca-guest module loading
Date: Wed, 30 Oct 2024 10:16:43 -0500	[thread overview]
Message-ID: <b62b9ba4-eaf9-4533-9a97-7d5e2929b1e8@arm.com> (raw)
In-Reply-To: <32211eb5-eed5-4c71-b62a-362d32e1af47@redhat.com>

Hi Gavin,

Thanks for looking at this!

On 10/29/24 7:23 PM, Gavin Shan wrote:
> Hi Jeremy,
> 
> 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@arm.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.


> 
>> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
>> index 188cbb9b23f5..1b14a4c4257a 100644
>> --- a/arch/arm64/include/asm/rsi.h
>> +++ b/arch/arm64/include/asm/rsi.h
>> @@ -10,6 +10,8 @@
>>   #include <linux/jump_label.h>
>>   #include <asm/rsi_cmds.h>
>> +#define ARMV9_RSI_PDEV_NAME "arm-cca-dev"
>> +
> 
> Maybe 'ARMV9' can be avoided since RSI is the specific feature to ARMv9.
> Besides, we already had @rsi_present there. So I would suggest to rename
> it to RSI_PDEV_NAME

This and the remainder of the comments below look reasonable to me, thanks!
> 
>>   DECLARE_STATIC_KEY_FALSE(rsi_present);
>>   void __init arm64_rsi_init(void);
>> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
>> index 3031f25c32ef..ad963eb12921 100644
>> --- a/arch/arm64/kernel/rsi.c
>> +++ b/arch/arm64/kernel/rsi.c
>> @@ -8,6 +8,7 @@
>>   #include <linux/psci.h>
>>   #include <linux/swiotlb.h>
>>   #include <linux/cc_platform.h>
>> +#include <linux/platform_device.h>
>>   #include <asm/io.h>
>>   #include <asm/mem_encrypt.h>
>> @@ -140,3 +141,17 @@ void __init arm64_rsi_init(void)
>>       static_branch_enable(&rsi_present);
>>   }
>> +static struct platform_device rsi_dev = {
>> +    .name = ARMV9_RSI_PDEV_NAME,
>> +    .id = -1
>> +};
>> +
> 
>          .id = PLATFORM_DEVID_NONE,
> 
>> +static int __init rsi_init(void)
>> +{
>> +    if (is_realm_world())
>> +        if (platform_device_register(&rsi_dev))
>> +            pr_err("failed to register rsi platform device");
>> +    return 0;
>> +}
>> +
> 
> Those two checks can be connected with '&&' and '\n' seems missed in the
> error message.
> 
>          if (is_realm_world() && platform_device_register(&rsi_dev))
>              pr_err("Failed to register RSI platform device\n");
> 
>> +arch_initcall(rsi_init)
>> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/ 
>> drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
>> index 488153879ec9..e7ef3b83d5d9 100644
>> --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
>> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
>> @@ -6,6 +6,7 @@
>>   #include <linux/arm-smccc.h>
>>   #include <linux/cc_platform.h>
>>   #include <linux/kernel.h>
>> +#include <linux/mod_devicetable.h>
>>   #include <linux/module.h>
>>   #include <linux/smp.h>
>>   #include <linux/tsm.h>
>> @@ -219,6 +220,12 @@ static void __exit arm_cca_guest_exit(void)
>>   }
>>   module_exit(arm_cca_guest_exit);
>> +static const struct platform_device_id arm_cca_match[] = {
>> +    { ARMV9_RSI_PDEV_NAME, 0},
>> +    { }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(platform, arm_cca_match);
> 
> 
> /* Comments here to explain why @arm_cca_dev_ids[] is needed */
> static const struct platform_device_id arm_cca_dev_ids[] = {
>         ...
> };
> 
> MODULE_DEVICE_TABLE(platform, arm_cca_dev_ids);
> 
>>   MODULE_AUTHOR("Sami Mujawar <sami.mujawar@arm.com>");
>>   MODULE_DESCRIPTION("Arm CCA Guest TSM Driver");
>>   MODULE_LICENSE("GPL");
> 
> Thanks,
> Gavin
> 


  reply	other threads:[~2024-10-30 15:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29 14:11 [PATCH] arm64: rsi: Add automatic arm-cca-guest module loading Jeremy Linton
2024-10-30  0:23 ` Gavin Shan
2024-10-30 15:16   ` Jeremy Linton [this message]
2024-10-30 22:48     ` Gavin Shan
2024-10-31  2:08       ` Jeremy Linton
2024-10-31  3:12         ` Gavin Shan
2024-11-01 17:39 ` kernel test robot
2024-11-01 18:01 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b62b9ba4-eaf9-4533-9a97-7d5e2929b1e8@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=gshan@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sami.mujawar@arm.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox