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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 AF45CC4361A for ; Fri, 4 Dec 2020 13:08:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2CA57207C8 for ; Fri, 4 Dec 2020 13:08:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2CA57207C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46004 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klApJ-0003OA-3a for qemu-devel@archiver.kernel.org; Fri, 04 Dec 2020 08:08:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klAoO-0002Wb-VD for qemu-devel@nongnu.org; Fri, 04 Dec 2020 08:07:50 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:51322) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1klAoN-0002jX-3p for qemu-devel@nongnu.org; Fri, 04 Dec 2020 08:07:48 -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 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 Received-SPF: pass client-ip=216.205.24.124; envelope-from=dgilbert@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.496, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pair@us.ibm.com, brijesh.singh@amd.com, frankja@linux.ibm.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , Richard Henderson , Marcelo Tosatti , david@redhat.com, qemu-devel@nongnu.org, Eduardo Habkost , mdroth@linux.vnet.ibm.com, pasic@linux.ibm.com, Christian Borntraeger , qemu-s390x@nongnu.org, qemu-ppc@nongnu.org, berrange@redhat.com, thuth@redhat.com, pbonzini@redhat.com, rth@twiddle.net, David Gibson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" * 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