Re: [RFC PATCH v1 11/38] KVM: arm64: CCA: register host tsm platform device

[Jeremy Linton]

Hi,

On 10/10/25 5:34 PM, Jason Gunthorpe wrote:
> On Fri, Oct 10, 2025 at 11:44:04AM -0700, dan.j.williams@xxxxxxxxx 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