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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13081C4361A for ; Fri, 4 Dec 2020 13:09:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD99D2251D for ; Fri, 4 Dec 2020 13:09:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727933AbgLDNJM (ORCPT ); Fri, 4 Dec 2020 08:09:12 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54866 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726257AbgLDNJM (ORCPT ); Fri, 4 Dec 2020 08:09:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607087266; 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=PoCy07Jhx9ZhLB65FF7tvAhqv4jMjLhVcKJsuwA2TV8=; b=MR6IxcSZpT3IkupSTSHirLWioMw+O/Abcq2GthPYRCt79PsL9jg7UDrq4chqgrKRqZJvW2 QdrSr/1uLjvVTajTzqTmeX78zg//pEiqikskXALoC89r6gnhaRJrDQ3A/2ekYSzSMlZEqS bxv3sBXJaW/EmCTGOgeKNU7QhyszQm8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-111-rUVhyzMJNXuJdqsgKAkCag-1; Fri, 04 Dec 2020 08:07:42 -0500 X-MC-Unique: rUVhyzMJNXuJdqsgKAkCag-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8C4211005504; Fri, 4 Dec 2020 13:07:40 +0000 (UTC) Received: from work-vm (ovpn-114-202.ams2.redhat.com [10.36.114.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 71F1F5D9CA; Fri, 4 Dec 2020 13:07:30 +0000 (UTC) Date: Fri, 4 Dec 2020 13:07:27 +0000 From: "Dr. David Alan Gilbert" To: Cornelia Huck Cc: Christian Borntraeger , David Gibson , pair@us.ibm.com, pbonzini@redhat.com, frankja@linux.ibm.com, brijesh.singh@amd.com, qemu-devel@nongnu.org, Eduardo Habkost , qemu-ppc@nongnu.org, rth@twiddle.net, thuth@redhat.com, berrange@redhat.com, mdroth@linux.vnet.ibm.com, Marcelo Tosatti , "Michael S. Tsirkin" , Marcel Apfelbaum , david@redhat.com, Richard Henderson , kvm@vger.kernel.org, qemu-s390x@nongnu.org, pasic@linux.ibm.com Subject: Re: [for-6.0 v5 00/13] Generalize memory encryption models Message-ID: <20201204130727.GD2883@work-vm> References: <20201204054415.579042-1-david@gibson.dropbear.id.au> <20201204140205.66e205da.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204140205.66e205da.cohuck@redhat.com> User-Agent: Mutt/1.14.6 (2020-07-11) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org * Cornelia Huck (cohuck@redhat.com) wrote: > On Fri, 4 Dec 2020 09:06:50 +0100 > Christian Borntraeger wrote: > > > On 04.12.20 06:44, David Gibson wrote: > > > 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 > > > "securable-guest-memory" property pointing to a platform specific > > > > Can we do "securable-guest" ? > > s390x also protects registers and integrity. memory is only one piece > > of the puzzle and what we protect might differ from platform to > > platform. > > > > I agree. Even technologies that currently only do memory encryption may > be enhanced with more protections later. There's already SEV-ES patches onlist for this on the SEV side. Perhaps 'confidential guest' is actually what we need, since the marketing folks seem to have started labelling this whole idea 'confidential computing'. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK