From patchwork Fri Jul 24 02:57:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Gibson X-Patchwork-Id: 11681929 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E4214722 for ; Fri, 24 Jul 2020 02:58:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD256207FC for ; Fri, 24 Jul 2020 02:58:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.b="C5PGevUJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726957AbgGXC6D (ORCPT ); Thu, 23 Jul 2020 22:58:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726784AbgGXC5u (ORCPT ); Thu, 23 Jul 2020 22:57:50 -0400 Received: from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78C3EC0619D3 for ; Thu, 23 Jul 2020 19:57:50 -0700 (PDT) Received: by ozlabs.org (Postfix, from userid 1007) id 4BCYlv1BKjz9sRN; Fri, 24 Jul 2020 12:57:47 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1595559467; bh=g66FwVz1r6nGsK6XJ5UcsyTZuDIgWFh7d1+V/6AC+0I=; h=From:To:Cc:Subject:Date:From; b=C5PGevUJgzVOgAIu9G1YJhVIdy5YZzXT+TIXBMNYd8rze8zDPZv1/8gf29OGzcCak ATvVaZzSVokHz9AhNsJE1rtRAYtsBidm6G0Lzm0Tm4MbDJ8y+aiBC7OIzzEzqzEBN8 qbj5gC930eEbwMu5xJee3GuQS/SvIHYplFgh53EY= From: David Gibson To: dgilbert@redhat.com, frankja@linux.ibm.com, pair@us.ibm.com, qemu-devel@nongnu.org, pbonzini@redhat.com, brijesh.singh@amd.com Cc: ehabkost@redhat.com, marcel.apfelbaum@gmail.com, "Michael S. Tsirkin" , qemu-ppc@nongnu.org, kvm@vger.kernel.org, pasic@linux.ibm.com, qemu-s390x@nongnu.org, David Gibson , David Hildenbrand , Christian Borntraeger , Richard Henderson , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , mdroth@linux.vnet.ibm.com, Thomas Huth , Cornelia Huck Subject: [for-5.2 v4 00/10] Generalize memory encryption models Date: Fri, 24 Jul 2020 12:57:34 +1000 Message-Id: <20200724025744.69644-1-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org A number of hardware platforms are implementing mechanisms whereby the hypervisor does not have unfettered access to guest memory, in order to mitigate the security impact of a compromised hypervisor. AMD's SEV implements this with in-cpu memory encryption, and Intel has its own memory encryption mechanism. POWER has an upcoming mechanism to accomplish this in a different way, using a new memory protection level plus a small trusted ultravisor. s390 also has a protected execution environment. The current code (committed or draft) for these features has each platform's version configured entirely differently. That doesn't seem ideal for users, or particularly for management layers. AMD SEV introduces a notionally generic machine option "machine-encryption", but it doesn't actually cover any cases other than SEV. This series is a proposal to at least partially unify configuration for these mechanisms, by renaming and generalizing AMD's "memory-encryption" property. It is replaced by a "host-trust-limitation" property pointing to a platform specific object which configures and manages the specific details. Please apply. Changes since v3: * Rebased * Added first cut at handling of s390 protected virtualization Changes since RFCv2: * Rebased * Removed preliminary SEV cleanups (they've been merged) * Changed name to "host trust limitation" * Added migration blocker to the PEF code (based on SEV's version) Changes since RFCv1: * Rebased * Fixed some errors pointed out by Dave Gilbert David Gibson (10): host trust limitation: Introduce new host trust limitation interface host trust limitation: Handle memory encryption via interface host trust limitation: Move side effect out of machine_set_memory_encryption() host trust limitation: Rework the "memory-encryption" property host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM host trust limitation: Add Error ** to HostTrustLimitation::kvm_init spapr: Add PEF based host trust limitation spapr: PEF: block migration host trust limitation: Alter virtio default properties for protected guests s390: Recognize host-trust-limitation option accel/kvm/kvm-all.c | 40 ++------ accel/kvm/sev-stub.c | 7 +- accel/stubs/kvm-stub.c | 10 -- backends/Makefile.objs | 2 + backends/host-trust-limitation.c | 29 ++++++ hw/core/machine.c | 61 +++++++++-- hw/i386/pc_sysfw.c | 6 +- hw/s390x/pv.c | 61 +++++++++++ include/exec/host-trust-limitation.h | 72 +++++++++++++ include/hw/boards.h | 2 +- include/qemu/typedefs.h | 1 + include/sysemu/kvm.h | 17 --- include/sysemu/sev.h | 4 +- target/i386/sev.c | 148 ++++++++++++--------------- target/ppc/Makefile.objs | 2 +- target/ppc/pef.c | 89 ++++++++++++++++ 16 files changed, 387 insertions(+), 164 deletions(-) create mode 100644 backends/host-trust-limitation.c create mode 100644 include/exec/host-trust-limitation.h create mode 100644 target/ppc/pef.c