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
next prev parent reply other threads:[~2026-08-29 6:12 UTC|newest]
Thread overview: 31+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox