Message-ID: <ef4c0cbc-bf5e-4e55-b495-8bafa8a84c32@arm.com>
Date: Mon, 13 Oct 2025 15:42:50 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: Jason Gunthorpe <jgg@...pe.ca>, dan.j.williams@...el.com
Cc: Greg KH <gregkh@...uxfoundation.org>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>, linux-coco@...ts.linux.dev,
 kvmarm@...ts.linux.dev, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, aik@....com, lukas@...ner.de,
 Samuel Ortiz <sameo@...osinc.com>, Xu Yilun <yilun.xu@...ux.intel.com>,
 Suzuki K Poulose <Suzuki.Poulose@....com>,
 Steven Price <steven.price@....com>,
 Catalin Marinas <catalin.marinas@....com>, Marc Zyngier <maz@...nel.org>,
 Will Deacon <will@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>
Subject: Re: [RFC PATCH v1 11/38] KVM: arm64: CCA: register host tsm platform
 device

Hi,

On 10/10/25 5:34 PM, Jason Gunthorpe wrote:
> On Fri, Oct 10, 2025 at 11:44:04AM -0700, dan.j.williams@...el.com wrote:
>> Jeremy Linton wrote:
>>> On 10/10/25 10:30 AM, Jason Gunthorpe wrote:
>>>> On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote:
>>>>
>>>>>> So you could use auxiliary_device, you'd consider SMC itself to be the
>>>>>> shared HW block and all the auxiliary drivers are per-subsystem
>>>>>> aspects of that shared SMC interface. It is not a terrible fit for
>>>>>> what it was intended for at least.
>>>>>
>>>>> Turns out that changing any of this, will at the moment break systemd's
>>>>> confidential vm detection, because they wanted the earliest indicator the
>>>>> guest was capable and that turned out to be this platform device.
>>>>
>>>> Having systemd detect a software created platform device sounds
>>>> compltely crazy, don't do that. Make a proper sysfs uapi for such a
>>>> general idea please.
>>>
>>> Yes, I agree, its just at the time the statment was around what is the
>>> most reliable early indicator, and since there isn't a hwcap or anything
>>> that ended up being the choice, as disgusting as it is.
>>>
>>> Presumably once all this works out the sysfs/api surface will be more
>>> 'defined'
>>
>> It has definition today.
>>
>> All guest-side TSM drivers currently call tsm_report_register(), that
>> establishes /sys/kernel/config/tsm/report which is the common cross-arch
>> transport for retrieving CVM launch attestation reports.
> 
> I suspect this ins't a TSM question but an existing question if any of
> the underlying CC frameworks are enabled.
> 
> It is this stuff:
> 
> https://github.com/systemd/systemd/blob/main/src/basic/confidential-virt.c
> https://github.com/systemd/systemd/commit/2572bf6a39b6c548acef07fd25f461c5a88560af
> 
>    Like the s390 detection logic, the sysfs path being checked is not labeled
>    as ABI, and may change in the future. It was chosen because its
>    directly tied to the kernel's detection of the realm service interface
>    rather to the Trusted Security Module (TSM) which is what is being
>    triggered by the device entry.
> 
> Maybe a /sys/firmware/smc/rsi file might be appropriate?

Except that you can see from the code that this problem is being solved 
in a hw platform dependent way for 4+ platforms now.

Ideally the sysfs node would be common across all those hw platforms and 
reflect the vm capabilities so the code doesn't' need #ifdef's. Meaning 
it shouldn't have the smc/rsi arm'ism in the name, and maybe shouldn't 
be in /sys/firmware


Thanks,

> 
> Given how small a deployed fooprint ARM CCA has right now (ie none) it
> would be good to fix this ASAP so it doesn't become entrenched.
> 
> Jason

Powered by blists - more mailing lists