Re: [RFC] Support for Arm CCA VMs on Linux

[Suzuki K Poulose]

On 02/03/2023 16:46, Dr. David Alan Gilbert wrote:
> * Suzuki K Poulose (suzuki.poulose@xxxxxxx) wrote:
> > Hi Dave
> >
> > Thanks for your response, and apologies for the delay. Response, in line.
> >
> > On 14/02/2023 17:13, Dr. David Alan Gilbert wrote:
> > > * Suzuki K Poulose (suzuki.poulose@xxxxxxx) wrote:
> > > > We are happy to announce the early RFC version of the Arm
> > > > Confidential Compute Architecture (CCA) support for the Linux
> > > > stack. The intention is to seek early feedback in the following areas:
> > > >    * KVM integration of the Arm CCA
> > > >    * KVM UABI for managing the Realms, seeking to generalise the operations
> > > >      wherever possible with other Confidential Compute solutions.
> > > >      Note: This version doesn't support Guest Private memory, which will be added
> > > >      later (see below).
> > > >    * Linux Guest support for Realms
> > > >
> > > > Arm CCA Introduction
> > > > =====================
> > > >
> > > > The Arm CCA is a reference software architecture and implementation that builds
> > > > on the Realm Management Extension (RME), enabling the execution of Virtual
> > > > machines, while preventing access by more privileged software, such as hypervisor.
> > > > The Arm CCA allows the hypervisor to control the VM, but removes the right for
> > > > access to the code, register state or data that is used by VM.
> > > > More information on the architecture is available here[0].
> > > >
> > > >       Arm CCA Reference Software Architecture
> > > >
> > > >           Realm World    ||    Normal World   ||  Secure World  ||
> > > >                          ||        |          ||                ||
> > > >    EL0 x-------x         || x----x | x------x ||                ||
> > > >        | Realm |         || |    | | |      | ||                ||
> > > >        |       |         || | VM | | |      | ||                ||
> > > >    ----|  VM*  |---------||-|    |---|      |-||----------------||
> > > >        |       |         || |    | | |  H   | ||                ||
> > > >    EL1 x-------x         || x----x | |      | ||                ||
> > > >            ^             ||        | |  o   | ||                ||
> > > >            |             ||        | |      | ||                ||
> > > >    ------- R*------------------------|  s  -|---------------------
> > > >            S             ||          |      | ||                ||
> > > >            I             ||          |  t   | ||                ||
> > > >            |             ||          |      | ||                ||
> > > >            v             ||          x------x ||                ||
> > > >    EL2    RMM*           ||              ^    ||                ||
> > > >            ^             ||              |    ||                ||
> > > >    ========|=============================|========================
> > > >            |                             | SMC
> > > >            x--------- *RMI* -------------x
> > > >
> > > >    EL3                   Root World
> > > >                          EL3 Firmware
> > > >    ===============================================================
> > > > Where :
> > > >    RMM - Realm Management Monitor
> > > >    RMI - Realm Management Interface
> > > >    RSI - Realm Service Interface
> > > >    SMC - Secure Monitor Call
> > >
> > > Hi,
> > >     It's nice to see this full stack posted - thanks!
> > >
> > > Are there any pointers to information on attestation and similar
> > > measurement things?  In particular, are there any plans for a vTPM
> >
> > The RMM v1.0 provides attestation and measurement services to the Realm,
> > via Realm Service Interface (RSI) calls.
>
> Can you point me at some docs for that?

It is part of the RMM specification [1], linked below.
Please see "Chapter A7. Realm Measurement and Attestation"

[1] https://developer.arm.com/documentation/den0137/latest

> > However, there is no support
> > for partitioning the Realm VM with v1.0. This is currently under
> > development and should be available in the near future.
> >
> > With that in place, a vTPM could reside in a partition of the Realm VM along
> > side the OS in another. Does that answer your question ?
>
> Possibly; it would be great to be able to use a standard vTPM interface
> here rather than have to do anything special.  People already have this
> working on AMD SEV-SNP.

Ok.

> Dave

...

> > > > [1] RMM Specification Latest
> > > >       https://developer.arm.com/documentation/den0137/latest


Suzuki



> > > > [2] RMM v1.0-Beta0 specification
> > > >       https://developer.arm.com/documentation/den0137/1-0bet0/
> > > >
> > > > [3] Trusted Firmware RMM - TF-RMM
> > > >       https://www.trustedfirmware.org/projects/tf-rmm/
> > > >       GIT: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git
> > > >
> > > > [4] FVP Base RevC AEM Model (available on x86_64 / Arm64 Linux)
> > > >       https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms
> > > >
> > > > [5] Trusted Firmware for A class
> > > >       https://www.trustedfirmware.org/projects/tf-a/
> > > >
> > > > [6] Linux kernel support for Arm-CCA
> > > >       https://gitlab.arm.com/linux-arm/linux-cca
> > > >       Host Support branch:	cca-host/rfc-v1
> > > >       Guest Support branch:	cca-guest/rfc-v1
> > > >
> > > > [7] kvmtool support for Arm CCA
> > > >       https://gitlab.arm.com/linux-arm/kvmtool-cca cca/rfc-v1
> > > >
> > > > [8] kvm-unit-tests support for Arm CCA
> > > >       https://gitlab.arm.com/linux-arm/kvm-unit-tests-cca  cca/rfc-v1
> > > >
> > > > [9] Instructions for Building Firmware components and running the model, see
> > > >       section 4.19.2 "Building and running TF-A with RME"
> > > >       https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-management-extension.html#building-and-running-tf-a-with-rme
> > > >
> > > > [10] fd based Guest Private memory for KVM
> > > >      https://lkml.kernel.org/r/20221202061347.1070246-1-chao.p.peng@xxxxxxxxxxxxxxx
> > > >
> > > > Cc: Alexandru Elisei <alexandru.elisei@xxxxxxx>
> > > > Cc: Andrew Jones <andrew.jones@xxxxxxxxx>
> > > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
> > > > Cc: Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx>
> > > > Cc: Christoffer Dall <christoffer.dall@xxxxxxx>
> > > > Cc: Fuad Tabba <tabba@xxxxxxxxxx>
> > > > Cc: James Morse <james.morse@xxxxxxx>
> > > > Cc: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx>
> > > > Cc: Joey Gouly <Joey.Gouly@xxxxxxx>
> > > > Cc: Marc Zyngier <maz@xxxxxxxxxx>
> > > > Cc: Mark Rutland <mark.rutland@xxxxxxx>
> > > > Cc: Oliver Upton <oliver.upton@xxxxxxxxx>
> > > > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> > > > Cc: Quentin Perret <qperret@xxxxxxxxxx>
> > > > Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
> > > > Cc: Steven Price <steven.price@xxxxxxx>
> > > > Cc: Thomas Huth <thuth@xxxxxxxxxx>
> > > > Cc: Will Deacon <will@xxxxxxxxxx>
> > > > Cc: Zenghui Yu <yuzenghui@xxxxxxxxxx>
> > > > To: linux-coco@xxxxxxxxxxxxxxx
> > > > To: kvmarm@xxxxxxxxxxxxxxx
> > > > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx
> > > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > > > To: linux-kernel@xxxxxxxxxxxxxxx
> > > > To: kvm@xxxxxxxxxxxxxxx