Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1487794ybi; Sat, 27 Jul 2019 10:47:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGH32uK0dBF9U1xj31aXLdMjANpIhSq5qY1DJAm2sT24CRsHGIp5K66J9BdJ2HVUo4abKz X-Received: by 2002:a63:1743:: with SMTP id 3mr18236317pgx.435.1564249661203; Sat, 27 Jul 2019 10:47:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564249661; cv=none; d=google.com; s=arc-20160816; b=FafB5VT2HKNooQLOrTD1cmt38Wx8Yub3A6hr8BJahkQiEI2lanEPcPVwnHWghHm8MT 8jYClQNFVp9pWcXfynZbCTxmQYmTlU8qGBJGDKLW884F5QOh20wfn0c0JhE9uW53N8UQ +EmDy4D79rnKh+faYDuoC2Bb3/KbUlKNJ729TrDJter5uT0zBDM+QXQyS03Ep6C1DOc1 m/tfvXO/DybF0wzLo747tws4Z0QBJb+qf42Fp/2C6B8fLVBfKCAiqjeU/aV5m06D6XtT LfopDnU7LGlTH9q5hkjr1xhwONbVpCXTnxXVr0gmpFexos/oqO5ys6hD079MDOuXdqFS CneA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0EwR5D2RhitOid270eXyYq4pncr9bTdZYue8Eoic4wU=; b=YRrZxGF+4prQoDm3F+tKIP39DXUjFxvLrksuSHn00pNoCqOAMtHikKUE/IiPmxqPPA l+kUvvenuGvBXHdeMMLoGY0eCg1q2RVx4ypvfMT0eRaDTbxGgYCkFJE1I1Bd29255mb9 Xfi7fnHGalXbhXPBIzIFIdEsKB4YFlIeR3RwKVr5gwvwzPFPzjoifELDKKpalZx0Y2Iq YIp3CQyzy2Vc/C5cdjoAdkchkBZ13GTUcqpoO5vlXV2oh4zG8fP9uRUcS7gZ7obemPnq BLgs2qUduNx9v0vMogkJ5v/KrnbRU0bu0Z/+bL6h4azQED92/JSSwsclozQ6MwtF8kem P2bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0qJWEiy0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w21si24337107pff.263.2019.07.27.10.47.23; Sat, 27 Jul 2019 10:47:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0qJWEiy0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387714AbfG0Roi (ORCPT + 99 others); Sat, 27 Jul 2019 13:44:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:41954 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387665AbfG0Roi (ORCPT ); Sat, 27 Jul 2019 13:44:38 -0400 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A14A4208E4 for ; Sat, 27 Jul 2019 17:44:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564249476; bh=7508Hqjsp5BrZEfHjlTHq2n5lWF3Ig6ljiPlvZAE1mM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0qJWEiy0ID85IOhEb93xNtQpSEilcQaXycwDHMREppR6o76xs9ICA6qt8UOR9VLnO ECykGS4C/wgMcPq6R3kDkur/NvlDAp/aqO3HedLyj4VvqnglLf+KU6cs91oGXi/lOM 4+HP1a/RBvMk14M5IydeA/S7Z4Q5SD4f7BDBt7XI= Received: by mail-wm1-f52.google.com with SMTP id g67so45998664wme.1 for ; Sat, 27 Jul 2019 10:44:36 -0700 (PDT) X-Gm-Message-State: APjAAAVs05p5fyAb1lx1ZlY/rOaA62GbpfC3FjWKkaWu7+wkyhH5OgOz JQDCl7WAJkz9hrg+hzfX7Ga97QrWkeogo1gsu0GyMw== X-Received: by 2002:a1c:9a53:: with SMTP id c80mr30866653wme.173.1564249475144; Sat, 27 Jul 2019 10:44:35 -0700 (PDT) MIME-Version: 1.0 References: <20190727055214.9282-1-sean.j.christopherson@intel.com> <20190727055214.9282-5-sean.j.christopherson@intel.com> In-Reply-To: <20190727055214.9282-5-sean.j.christopherson@intel.com> From: Andy Lutomirski Date: Sat, 27 Jul 2019 10:44:24 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 04/21] x86/sgx: Add /dev/sgx/virt_epc device to allocate "raw" EPC for VMs To: Sean Christopherson Cc: Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , Jarkko Sakkinen , Joerg Roedel , "H. Peter Anvin" , kvm list , LKML , linux-sgx@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 26, 2019 at 10:52 PM Sean Christopherson wrote: > > Add an SGX device to enable userspace to allocate EPC without an > associated enclave. The intended and only known use case for direct EPC > allocation is to expose EPC to a KVM guest, hence the virt_epc moniker, > virt.{c,h} files and INTEL_SGX_VIRTUALIZATION Kconfig. > > Although KVM is the end consumer of EPC, and will need hooks into the > virtual EPC management if oversubscription of EPC for guest is ever > supported (see below), implement direct access to EPC in the SGX > subsystem instead of in KVM. Doing so has two major advantages: > > - Does not require changes to KVM's uAPI, e.g. EPC gets handled as > just another memory backend for guests. This is general grumbling more than useful feedback, but I wish there was a way for KVM's userspace to add a memory region that is *not* backed by a memory mapping. For SGX, this would avoid the slightly awkward situation where useless EPC pages are mapped by QEMU. For SEV, it would solve the really fairly awful situation where the SEV pages are mapped *incoherently* for QEMU. And even in the absence of fancy hardware features, it would allow the guest to have secrets in memory that are not exposed to wild reads, speculation attacks, etc coming from QEMU. I realize the implementation would be extremely intrusive, but it just might make it a lot easier to do things like making SEV pages property movable. Similarly, I could see EPC oversubscription being less nasty in this model. For one thing, it would make it more straightforward to keep track of exactly which VMs have a given EPC page mapped, whereas right now this driver only really knows which host userspace mm has the EPC page mapped.