| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Y+vBHXbxPBgHxzGY@work-vm>
Date: Tue, 14 Feb 2023 17:13:01 +0000
From: "Dr. David Alan Gilbert" <dgilbert@...hat.com>
To: Suzuki K Poulose <suzuki.poulose@....com>
Cc: linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, kvmarm@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
Alexandru Elisei <alexandru.elisei@....com>,
Andrew Jones <andrew.jones@...ux.dev>,
Catalin Marinas <catalin.marinas@....com>,
Chao Peng <chao.p.peng@...ux.intel.com>,
Christoffer Dall <christoffer.dall@....com>,
Fuad Tabba <tabba@...gle.com>,
James Morse <james.morse@....com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
Joey Gouly <Joey.Gouly@....com>, Marc Zyngier <maz@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Oliver Upton <oliver.upton@...ux.dev>,
Paolo Bonzini <pbonzini@...hat.com>,
Quentin Perret <qperret@...gle.com>,
Sean Christopherson <seanjc@...gle.com>,
Steven Price <steven.price@....com>,
Thomas Huth <thuth@...hat.com>, Will Deacon <will@...nel.org>,
Zenghui Yu <yuzenghui@...wei.com>, kvmarm@...ts.cs.columbia.edu
Subject: Re: [RFC] Support for Arm CCA VMs on Linux
* Suzuki K Poulose (suzuki.poulose@....com) 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
for Realms - if there were, it would make life easy for us, since we
can share some user space stuff with other CoCo systems.
Dave
> RME introduces a new security state "Realm world", in addition to the
> traditional Secure and Non-Secure states. The Arm CCA defines a new component,
> Realm Management Monitor (RMM) that runs at R-EL2. This is a standard piece of
> firmware, verified, installed and loaded by the EL3 firmware (e.g, TF-A), at
> system boot.
>
> The RMM provides standard interfaces - Realm Management Interface (RMI) - to the
> Normal world hypervisor to manage the VMs running in the Realm world (also called
> Realms in short). These are exposed via SMC and are routed through the EL3
> firmwre.
> The RMI interface includes:
> - Move a physical page from the Normal world to the Realm world
> - Creating a Realm with requested parameters, tracked via Realm Descriptor (RD)
> - Creating VCPUs aka Realm Execution Context (REC), with initial register state.
> - Create stage2 translation table at any level.
> - Load initial images into Realm Memory from normal world memory
> - Schedule RECs (vCPUs) and handle exits
> - Inject virtual interrupts into the Realm
> - Service stage2 runtime faults with pages (provided by host, scrubbed by RMM).
> - Create "shared" mappings that can be accessed by VMM/Hyp.
> - Reclaim the memory allocated for the RAM and RTTs (Realm Translation Tables)
>
> However v1.0 of RMM specifications doesn't support:
> - Paging protected memory of a Realm VM. Thus the pages backing the protected
> memory region must be pinned.
> - Live migration of Realms.
> - Trusted Device assignment.
> - Physical interrupt backed Virtual interrupts for Realms
>
> RMM also provides certain services to the Realms via SMC, called Realm Service
> Interface (RSI). These include:
> - Realm Guest Configuration.
> - Attestation & Measurement services
> - Managing the state of an Intermediate Physical Address (IPA aka GPA) page.
> - Host Call service (Communication with the Normal world Hypervisor)
>
> The specifications for the RMM software is currently at *v1.0-Beta2* and the
> latest version is available here [1].
>
> The Trusted Firmware foundation has an implementation of the RMM - TF-RMM -
> available here [3].
>
> Implementation
> =================
>
> This version of the stack is based on the RMM specification v1.0-Beta0[2], with
> following exceptions :
> - TF-RMM/KVM currently doesn't support the optional features of PMU,
> SVE and Self-hosted debug (coming soon).
> - The RSI_HOST_CALL structure alignment requirement is reduced to match
> RMM v1.0 Beta1
> - RMI/RSI version numbers do not match the RMM spec. This will be
> resolved once the spec/implementation is complete, across TF-RMM+Linux stack.
>
> We plan to update the stack to support the latest version of the RMMv1.0 spec
> in the coming revisions.
>
> This release includes the following components :
>
> a) Linux Kernel
> i) Host / KVM support - Support for driving the Realms via RMI. This is
> dependent on running in the Kernel at EL2 (aka VHE mode). Also provides
> UABI for VMMs to manage the Realm VMs. The support is restricted to 4K page
> size, matching the Stage2 granule supported by RMM. The VMM is responsible
> for making sure the guest memory is locked.
>
> TODO: Guest Private memory[10] integration - We have been following the
> series and support will be added once it is merged upstream.
>
> ii) Guest support - Support for a Linux Kernel to run in the Realm VM at
> Realm-EL1, using RSI services. This includes virtio support (virtio-v1.0
> only). All I/O are treated as non-secure/shared.
>
> c) kvmtool - VMM changes required to manage Realm VMs. No guest private memory
> as mentioned above.
> d) kvm-unit-tests - Support for running in Realms along with additional tests
> for RSI ABI.
>
> Running the stack
> ====================
>
> To run/test the stack, you would need the following components :
>
> 1) FVP Base AEM RevC model with FEAT_RME support [4]
> 2) TF-A firmware for EL3 [5]
> 3) TF-A RMM for R-EL2 [3]
> 4) Linux Kernel [6]
> 5) kvmtool [7]
> 6) kvm-unit-tests [8]
>
> Instructions for building the firmware components and running the model are
> available here [9]. Once, the host kernel is booted, a Realm can be launched by
> invoking the `lkvm` commad as follows:
>
> $ lkvm run --realm \
> --measurement-algo=["sha256", "sha512"] \
> --disable-sve \
> <normal-vm-options>
>
> Where:
> * --measurement-algo (Optional) specifies the algorithm selected for creating the
> initial measurements by the RMM for this Realm (defaults to sha256).
> * GICv3 is mandatory for the Realms.
> * SVE is not yet supported in the TF-RMM, and thus must be disabled using
> --disable-sve
>
> You may also run the kvm-unit-tests inside the Realm world, using the similar
> options as above.
>
>
> Links
> ============
>
> [0] Arm CCA Landing page (See Key Resources section for various documentations)
> https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture
>
> [1] RMM Specification Latest
> https://developer.arm.com/documentation/den0137/latest
>
> [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@linux.intel.com
>
> Cc: Alexandru Elisei <alexandru.elisei@....com>
> Cc: Andrew Jones <andrew.jones@...ux.dev>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Chao Peng <chao.p.peng@...ux.intel.com>
> Cc: Christoffer Dall <christoffer.dall@....com>
> Cc: Fuad Tabba <tabba@...gle.com>
> Cc: James Morse <james.morse@....com>
> Cc: Jean-Philippe Brucker <jean-philippe@...aro.org>
> Cc: Joey Gouly <Joey.Gouly@....com>
> Cc: Marc Zyngier <maz@...nel.org>
> Cc: Mark Rutland <mark.rutland@....com>
> Cc: Oliver Upton <oliver.upton@...ux.dev>
> Cc: Paolo Bonzini <pbonzini@...hat.com>
> Cc: Quentin Perret <qperret@...gle.com>
> Cc: Sean Christopherson <seanjc@...gle.com>
> Cc: Steven Price <steven.price@....com>
> Cc: Thomas Huth <thuth@...hat.com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Zenghui Yu <yuzenghui@...wei.com>
> To: linux-coco@...ts.linux.dev
> To: kvmarm@...ts.linux.dev
> Cc: kvmarm@...ts.cs.columbia.edu
> Cc: linux-arm-kernel@...ts.infradead.org
> To: linux-kernel@...r.kernel.org
> To: kvm@...r.kernel.org
>
--
Dr. David Alan Gilbert / dgilbert@...hat.com / Manchester, UK
Powered by blists - more mailing lists