All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: linux-coco@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Jeremy Linton <jeremy.linton@arm.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will@kernel.org>,
	Steven Price <steven.price@arm.com>,
	Suzuki K Poulose <Suzuki.Poulose@arm.com>,
	Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH v9 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
Date: Sat, 29 Aug 2026 11:42:20 +0530	[thread overview]
Message-ID: <yq5ald9ptpyz.fsf@kernel.org> (raw)
In-Reply-To: <178794567780.4159892.17969556982711821646.b4-review@b4>

Jason Gunthorpe <jgg@nvidia.com> writes:

>> [ ... 43 lines skipped ... ]
>> @@ -94,6 +95,12 @@ static const struct smccc_device_info smccc_devices[] __initconst = {
>>  		.requires_smc   = false,
>>  		.device_name    = "arm-smccc-trng",
>>  	},
>> +
>> +	{
>> +		.func_id        = SMC_RSI_ABI_VERSION,
>  [Severity: High]
>  Does this new entry cause uninitialized registers to be passed to the
>  firmware?
>
>  Looking at smccc_probe_smccc_device():
>
>  	arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
>
>  The invocation only passes the func_id, leaving r1 uninitialized. Since the
>  SMC_RSI_ABI_VERSION ABI requires r1 to hold the requested version parameter,
>  does this leak uninitialized kernel register state to the firmware and pass
>  a garbage ABI version?
>

Yes. This even can result in error return from firmware like

[   rmm ] SMC_RMI_VERSION                   6 > RMI_RMI_ERROR_INPUT


>
> This seems like a good point.. Several other APIs had this 'pass a
> thing in' as part of their version contract too.
>
> There is ABI incompatabilitiy here right? It would make sense to break
> up the really different versions into different device strings if
> possible. eg v1 and v2?
>

The goal is only to check whether the firmware function is supported,
hence the explicit check for SMCCC_RET_NOT_SUPPORTED.

	arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
	ret = res.a0;

	if (ret == SMCCC_RET_NOT_SUPPORTED)
		return false;


>
> ...
>
>  [Severity: High]
>  Could this also execute an SMC64 call on 32-bit ARM (AArch32) systems?
>
>  The smccc_devices array unconditionally includes SMC_RSI_ABI_VERSION, which
>  is an SMC64 call. Executing an SMC64 function identifier from an AArch32
>  execution state is architecturally unpredictable and could cause a crash
>  or hang on 32-bit hardware.
>
> No idea if sashiko is right , but it is what I was wondering about in
> the rng patch...
>

I will check whether issuing an SMC64 call on 32-bit ARM is a problem.

>
>> [ ... 44 lines skipped ... ]
>> +static void unregister_cca_tsm_report(void *data)
>> +{
>> +	tsm_report_unregister(&arm_cca_tsm_report_ops);
>> +}
>> +
>> +static int cca_tsm_probe(struct arm_smccc_device *sdev)
>>  {
>>  	int ret;
>>  
>> @@ -178,30 +175,33 @@ static int __init arm_cca_guest_init(void)
>>  		return -ENODEV;
>>  
>>  	ret = tsm_report_register(&arm_cca_tsm_report_ops, NULL);
>> -	if (ret < 0)
>> -		pr_err("Error %d registering with TSM\n", ret);
>> +	if (ret < 0) {
>> +		dev_err_probe(&sdev->dev, ret, "Error registering with TSM\n");
>> +		return ret;
>> +	}
>>  
>> -	return ret;
>> +	ret = devm_add_action_or_reset(&sdev->dev, unregister_cca_tsm_report,
>> +				       NULL);
>> +	if (ret < 0) {
>
> Can just make unregister the remove function. Don't need to use devm
> for everything.
>

IIUC, you are suggesting to do the below?

static void cca_tsm_remove(struct arm_smccc_device *sdev)
{
        tsm_report_unregister(&arm_cca_tsm_report_ops);
}

static struct arm_smccc_driver cca_tsm_driver = {
        .driver_name = "arm_cca_tsm",
        .probe = cca_tsm_probe,
        .remove = cca_tsm_remove,
        ...

-aneesh


  reply	other threads:[~2026-08-29  6:12 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  6:32 [PATCH v9 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Aneesh Kumar K.V (Arm)
2026-08-05  6:32 ` [PATCH v9 1/7] firmware: smccc: Add an Arm " Aneesh Kumar K.V (Arm)
2026-08-28 19:34   ` Jason Gunthorpe
2026-09-03  8:52     ` Aneesh Kumar K.V
2026-09-03 12:57       ` Jason Gunthorpe
2026-09-03 14:13         ` Sudeep Holla
2026-09-03 14:29           ` Jason Gunthorpe
2026-09-03 14:35         ` Aneesh Kumar K.V
2026-09-03 15:46           ` Jason Gunthorpe
2026-09-03 16:18             ` Sudeep Holla
2026-09-03 18:21               ` Jason Gunthorpe
2026-09-04  5:50                 ` Aneesh Kumar K.V
2026-09-04 10:02                 ` Sudeep Holla
2026-09-04 13:53                   ` Jason Gunthorpe
2026-09-04 14:27                     ` Sudeep Holla
2026-09-04 17:50                       ` Jason Gunthorpe
2026-08-05  6:32 ` [PATCH v9 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device Aneesh Kumar K.V (Arm)
2026-08-05 11:08   ` Catalin Marinas
2026-08-28 19:34   ` Jason Gunthorpe
2026-08-29  5:54     ` Aneesh Kumar K.V
2026-08-29 19:11       ` Jason Gunthorpe
2026-08-05  6:32 ` [PATCH v9 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64 Aneesh Kumar K.V (Arm)
2026-08-05 11:21   ` Catalin Marinas
2026-08-05 13:05     ` Aneesh Kumar K.V
2026-08-10 10:03   ` Suzuki K Poulose
2026-08-28 19:34   ` Jason Gunthorpe
2026-08-29  5:58     ` Aneesh Kumar K.V
2026-08-05  6:32 ` [PATCH v9 4/7] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-08-10 10:12   ` Suzuki K Poulose
2026-08-10 12:15     ` Aneesh Kumar K.V
2026-08-05  6:32 ` [PATCH v9 5/7] virt: coco: arm-cca-guest: Rename TSM report source file Aneesh Kumar K.V (Arm)
2026-08-28 19:34   ` Jason Gunthorpe
2026-08-29  6:02     ` Aneesh Kumar K.V
2026-08-29 19:07       ` Jason Gunthorpe
2026-08-05  6:32 ` [PATCH v9 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device Aneesh Kumar K.V (Arm)
2026-08-28 19:34   ` Jason Gunthorpe
2026-08-29  6:12     ` Aneesh Kumar K.V [this message]
2026-08-29 19:13       ` Jason Gunthorpe
2026-08-05  6:32 ` [PATCH v9 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI Aneesh Kumar K.V (Arm)
2026-08-28 19:34   ` Jason Gunthorpe
2026-08-05  9:51 ` [PATCH v9 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Catalin Marinas
2026-08-05 12:22   ` Aneesh Kumar K.V
2026-08-10  9:35     ` Aneesh Kumar K.V
2026-08-10 10:24       ` Will Deacon

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=yq5ald9ptpyz.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=Suzuki.Poulose@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeremy.linton@arm.com \
    --cc=jgg@nvidia.com \
    --cc=jic23@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.