From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCD7B8C11 for ; Thu, 2 Mar 2023 16:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677775596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lLg+isOMCHZkiVhSyoPQMgYoduyOmcvENKIL4gkpJhM=; b=hZ8wF0UAAJUhTnKWcW/nCyTk1up8VINVZjFubAycJg17jzGZJJR403ayrxbmlJz2Kng8+I e2C6f0rkWOX07T+TBf+Gd4eTy9u1g+9PW5jL9Dnu0YRhr+zJn1BU6bKyCK5AdnyWjR5oAF 34ORk6JU2/zy3oXayDrSmwdwMKOSR4I= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-244-QIlfFvD6O0m9t9PF1tLkFg-1; Thu, 02 Mar 2023 11:46:35 -0500 X-MC-Unique: QIlfFvD6O0m9t9PF1tLkFg-1 Received: by mail-wm1-f72.google.com with SMTP id n27-20020a05600c3b9b00b003e9ca0f4677so1325887wms.8 for ; Thu, 02 Mar 2023 08:46:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lLg+isOMCHZkiVhSyoPQMgYoduyOmcvENKIL4gkpJhM=; b=v9OiJpuD4QRJgLbp6ByTYSQ3eKBfvzEW8STLM7Xuz8iSG7Bzp+DLoiOTNk9jyVImr8 r2hgloBQWbattwQSN7xL0MxVE2/TXPq6EO8HNAgbej1mvsfFULKEYDBJnEOkRU0sKLxl REc3cFLNYuiVuB0hw4899W+kmCViWkLZSx5N3B53+MwgDflCpLp5oADCyumN77qOiyq5 MK3EHleAlL6dPtZBlSfX0akyGAFGIDP5RFdMv5QVW1qk5YB/CsLF/e0VygGoyJib2RIt qJe0vex1r55yqR6Ai5mOB29Kv+UZGr3nePk/rdjpfp79xTMLDlb/t9Z4WoEKwTiYVTCy NtIw== X-Gm-Message-State: AO0yUKXvIMUs5OwYuSSORegvfdFaeDR3iCXzi7179aWlYSIkbp09CbcW 6+O9rOyiIwKJpCaptMwbMDx4QbG7hgbUcMOfiTS7O6q3Em82+cvPzTijOqNn/oNBMARhUYDTXfA /e6c5aykSHoNbsCcl1k1AgQ== X-Received: by 2002:adf:f483:0:b0:2c7:d7ca:4c89 with SMTP id l3-20020adff483000000b002c7d7ca4c89mr8274688wro.58.1677775594401; Thu, 02 Mar 2023 08:46:34 -0800 (PST) X-Google-Smtp-Source: AK7set9nqcUj0DG2V25cBfi7wWAS/JoQpydUrneW2VUGoMwFlnC+w/vA12/xJeUWP3Lu3V74j1it1A== X-Received: by 2002:adf:f483:0:b0:2c7:d7ca:4c89 with SMTP id l3-20020adff483000000b002c7d7ca4c89mr8274652wro.58.1677775594024; Thu, 02 Mar 2023 08:46:34 -0800 (PST) Received: from work-vm (ward-16-b2-v4wan-166627-cust863.vm18.cable.virginm.net. [81.97.203.96]) by smtp.gmail.com with ESMTPSA id e15-20020a5d594f000000b002c5d3f0f737sm15639925wri.30.2023.03.02.08.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 08:46:33 -0800 (PST) Date: Thu, 2 Mar 2023 16:46:30 +0000 From: "Dr. David Alan Gilbert" To: Suzuki K Poulose Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andrew Jones , Catalin Marinas , Chao Peng , Christoffer Dall , Fuad Tabba , James Morse , Jean-Philippe Brucker , Joey Gouly , Marc Zyngier , Mark Rutland , Oliver Upton , Paolo Bonzini , Quentin Perret , Sean Christopherson , Steven Price , Thomas Huth , Will Deacon , Zenghui Yu , kvmarm@lists.cs.columbia.edu Subject: Re: [RFC] Support for Arm CCA VMs on Linux Message-ID: References: <20230127112248.136810-1-suzuki.poulose@arm.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Suzuki K Poulose (suzuki.poulose@arm.com) 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@arm.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 > > 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? > 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. Dave > Kind regards > Suzuki > > > > 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 \ > > > > > > > > > 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 > > > Cc: Andrew Jones > > > Cc: Catalin Marinas > > > Cc: Chao Peng > > > Cc: Christoffer Dall > > > Cc: Fuad Tabba > > > Cc: James Morse > > > Cc: Jean-Philippe Brucker > > > Cc: Joey Gouly > > > Cc: Marc Zyngier > > > Cc: Mark Rutland > > > Cc: Oliver Upton > > > Cc: Paolo Bonzini > > > Cc: Quentin Perret > > > Cc: Sean Christopherson > > > Cc: Steven Price > > > Cc: Thomas Huth > > > Cc: Will Deacon > > > Cc: Zenghui Yu > > > To: linux-coco@lists.linux.dev > > > To: kvmarm@lists.linux.dev > > > Cc: kvmarm@lists.cs.columbia.edu > > > Cc: linux-arm-kernel@lists.infradead.org > > > To: linux-kernel@vger.kernel.org > > > To: kvm@vger.kernel.org > > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C6C99C87FDC for ; Thu, 2 Mar 2023 16:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wve9a5zRK0/epxlcCbIgEHrydkbnzrT6m+gvlV9zg3E=; b=BXAyFZp5YPHMRO Fa9rxx/JPQNoiRQgp2Dom86HClBabAq52/dFbl1RY6GkzuHjidz/yoe3QbC46nyEvRozHxEY0z5pO hPunYpIVk5+oRMYZzcQBFMjZvSbuqEk84e4BMd9V/yZQaVgQoFZOASm5LJbrRpNTXoakr9r1taLh/ lpVv663RbxtLaez63p7ACLs5tAoDWko0EWZM+f/H6k1BgWYaMaUpEVFOSJ67VFefEdoIThVCXhKIy /OGUlj7bnTPR+S23py4dKrfjXJQutkFOAGlBLUdi2oQTDO54iUBQqOWV1I19R32ipXJff3fv+e3Rp TBPBDx15HSJSQogro6rw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pXm4u-002t18-00; Thu, 02 Mar 2023 16:46:48 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pXm4p-002sz9-Dg for linux-arm-kernel@lists.infradead.org; Thu, 02 Mar 2023 16:46:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677775597; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lLg+isOMCHZkiVhSyoPQMgYoduyOmcvENKIL4gkpJhM=; b=d2SpNJ4W1DLKkXY7WZKKa2JynR1uYZit117+DiixGBFEUcFJrQRoXXkHO0VckLa4gQCl/2 JUN9N3QqTE1xmGskJYF1ux2R/lzeXu64XxXWiTfD9GdxuC0ADvakfyqXdN4hgeA5T8XVCj pZMnzuIoP/FXVZhr0/2/VqHgfY0Jy0o= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-224-UhEBHFUwO0ajVm3r_G9L6Q-1; Thu, 02 Mar 2023 11:46:35 -0500 X-MC-Unique: UhEBHFUwO0ajVm3r_G9L6Q-1 Received: by mail-wm1-f72.google.com with SMTP id l16-20020a05600c1d1000b003e77552705cso1329056wms.7 for ; Thu, 02 Mar 2023 08:46:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lLg+isOMCHZkiVhSyoPQMgYoduyOmcvENKIL4gkpJhM=; b=li/KjxXQK9cjcl4ukVykA4GUy78YnBKV8Uaj0Q7ltj5DbLGPUyxHdAc8j+ktlDQ5p0 6Bsba6flFhkbzxuoKzDBVsG3IQXGHo1bulGnGYT0RVa/sOykT2MHnCXTJn92VPm4TuLK 9gCVcwaKa8EKz/Ncx/Xx8+hS+IOpoU7ANC8ygoriEOA4OfYmZWZUrxw+U1nm2UQMucFJ fOt0V9Ey5SAqEe6HXChkthD0jRKfnGBlLFKSvNjfZVk7FjB9ZhqSoXj+L8rdI6/XvVi0 2bi5sLOBkEDLxRvm/emqoMtg4USOd/wdEjZOVwjCAHqdKBXBEJnzM7j7llxCnBuRwG2m jsnw== X-Gm-Message-State: AO0yUKVtaui4HXLTYpG5SGQGjCsydvREQ4U/sDt0lvt7xw8qv6GJ0LCV wKPOR4q3MvZvrIMrbD0LtdVqerx/B8fPwgldzYdCpgHpP/UPs96JvMe7ozjlFA5DrXzojY5IYRB 1k0lu9yc6nJa7sQwzHNMuYu95iMuTUd3DaAI= X-Received: by 2002:adf:f483:0:b0:2c7:d7ca:4c89 with SMTP id l3-20020adff483000000b002c7d7ca4c89mr8274679wro.58.1677775594401; Thu, 02 Mar 2023 08:46:34 -0800 (PST) X-Google-Smtp-Source: AK7set9nqcUj0DG2V25cBfi7wWAS/JoQpydUrneW2VUGoMwFlnC+w/vA12/xJeUWP3Lu3V74j1it1A== X-Received: by 2002:adf:f483:0:b0:2c7:d7ca:4c89 with SMTP id l3-20020adff483000000b002c7d7ca4c89mr8274652wro.58.1677775594024; Thu, 02 Mar 2023 08:46:34 -0800 (PST) Received: from work-vm (ward-16-b2-v4wan-166627-cust863.vm18.cable.virginm.net. [81.97.203.96]) by smtp.gmail.com with ESMTPSA id e15-20020a5d594f000000b002c5d3f0f737sm15639925wri.30.2023.03.02.08.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 08:46:33 -0800 (PST) Date: Thu, 2 Mar 2023 16:46:30 +0000 From: "Dr. David Alan Gilbert" To: Suzuki K Poulose Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andrew Jones , Catalin Marinas , Chao Peng , Christoffer Dall , Fuad Tabba , James Morse , Jean-Philippe Brucker , Joey Gouly , Marc Zyngier , Mark Rutland , Oliver Upton , Paolo Bonzini , Quentin Perret , Sean Christopherson , Steven Price , Thomas Huth , Will Deacon , Zenghui Yu , kvmarm@lists.cs.columbia.edu Subject: Re: [RFC] Support for Arm CCA VMs on Linux Message-ID: References: <20230127112248.136810-1-suzuki.poulose@arm.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230302_084643_662584_1E069FF1 X-CRM114-Status: GOOD ( 53.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Suzuki K Poulose (suzuki.poulose@arm.com) 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@arm.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 > > 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? > 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. Dave > Kind regards > Suzuki > > > > 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 \ > > > > > > > > > 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 > > > Cc: Andrew Jones > > > Cc: Catalin Marinas > > > Cc: Chao Peng > > > Cc: Christoffer Dall > > > Cc: Fuad Tabba > > > Cc: James Morse > > > Cc: Jean-Philippe Brucker > > > Cc: Joey Gouly > > > Cc: Marc Zyngier > > > Cc: Mark Rutland > > > Cc: Oliver Upton > > > Cc: Paolo Bonzini > > > Cc: Quentin Perret > > > Cc: Sean Christopherson > > > Cc: Steven Price > > > Cc: Thomas Huth > > > Cc: Will Deacon > > > Cc: Zenghui Yu > > > To: linux-coco@lists.linux.dev > > > To: kvmarm@lists.linux.dev > > > Cc: kvmarm@lists.cs.columbia.edu > > > Cc: linux-arm-kernel@lists.infradead.org > > > To: linux-kernel@vger.kernel.org > > > To: kvm@vger.kernel.org > > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel