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 v10 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
Date: Wed, 09 Sep 2026 13:07:18 +0530	[thread overview]
Message-ID: <yq5atsnyeuz5.fsf@kernel.org> (raw)
In-Reply-To: <178855077571.693280.17942746234757215326.b4-review@b4>

Jason Gunthorpe <jgg@nvidia.com> writes:

>> [ ... 42 lines skipped ... ]
>> @@ -94,6 +95,11 @@ static const struct smccc_device_info smccc_devices[] __initconst = {
>>  		.requires_smc   = false,
>>  		.device_name    = "arm-smccc-trng",
>>  	},
>> +	{
>> +		.func_id        = SMC_RSI_ABI_VERSION,
>> +		.requires_smc   = true,
>> +		.device_name    = "arm-rsi",
>> +	},
>>  };
>>  
>>  static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
>
>    [Severity: High]
>    When this new entry is probed by smccc_probe_smccc_device(), does
>    arm_smccc_1_1_invoke() pass uninitialized registers to the firmware?
>
>    Looking at smccc_probe_smccc_device() during system initialization:
>
>    drivers/firmware/smccc/smccc.c:smccc_probe_smccc_device() {
>        ...
> 	   arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
>        ...
>    }
>
>    Since arm_smccc_1_1_invoke() is a variadic macro, providing only the func_id
>    leaves x1/r1 uninitialized in the SMC inline assembly.
>
>    For SMC_RSI_ABI_VERSION, the RMM uses x1 as the requested interface revision
>    to determine supported revisions.
>
>    Could this pass a garbage requested interface revision to the RMM,
>    potentially causing probe failures or returning an unsupported boundary?
>
>    Could this also leak kernel register state to EL2?
>
> Sashiko still has this to say, I think it should pass 0 as the x1
> 'requested version' instead of unpredictable garbage.
>

To handle 

> Could this also leak kernel register state to EL2?
>

Should we instead do

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

There is no standard defining how the various SMCCC VERSION calls are
expected to work. For example, ARM_SMCCC_TRNG_VERSION does not use x1,
while SMC_RSI_ABI_VERSION does. Another VERSION call could use both x1
and x2. The only consistent behavior is to return
SMCCC_RET_NOT_SUPPORTED when the SMCCC function ID is not supported.

-aneesh


  reply	other threads:[~2026-09-09  7:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  9:49 [PATCH v10 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Aneesh Kumar K.V (Arm)
2026-09-04  9:49 ` [PATCH v10 1/7] firmware: smccc: Add an Arm " Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe
2026-09-04  9:49 ` [PATCH v10 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe
2026-09-04  9:49 ` [PATCH v10 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64 Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe
2026-09-04  9:49 ` [PATCH v10 4/7] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe
2026-09-04  9:49 ` [PATCH v10 5/7] virt: coco: arm-cca-guest: Rename TSM report source file Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe
2026-09-04  9:49 ` [PATCH v10 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe
2026-09-09  7:37     ` Aneesh Kumar K.V [this message]
2026-09-09 12:05       ` Jason Gunthorpe
2026-09-11 14:55       ` Suzuki K Poulose
2026-09-11 14:59         ` Jason Gunthorpe
2026-09-04  9:50 ` [PATCH v10 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI Aneesh Kumar K.V (Arm)
2026-09-04 19:39   ` Jason Gunthorpe

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=yq5atsnyeuz5.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.