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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 3BDD1C43387 for ; Tue, 8 Jan 2019 22:09:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11DD72146F for ; Tue, 8 Jan 2019 22:09:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730077AbfAHWJs (ORCPT ); Tue, 8 Jan 2019 17:09:48 -0500 Received: from mga04.intel.com ([192.55.52.120]:47409 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728041AbfAHWJs (ORCPT ); Tue, 8 Jan 2019 17:09:48 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 14:09:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,455,1539673200"; d="scan'208";a="308699544" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.154]) by fmsmga006.fm.intel.com with ESMTP; 08 Jan 2019 14:09:47 -0800 Date: Tue, 8 Jan 2019 14:09:47 -0800 From: Sean Christopherson To: "Huang, Kai" Cc: Andy Lutomirski , Jethro Beekman , Jarkko Sakkinen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , Dave Hansen , Peter Zijlstra , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-sgx@vger.kernel.org" , Josh Triplett , Haitao Huang , "Dr . Greg Wettstein" Subject: Re: x86/sgx: uapi change proposal Message-ID: <20190108220946.GA30462@linux.intel.com> References: <20181214215729.4221-1-sean.j.christopherson@intel.com> <7706b2aa71312e1f0009958bcab24e1e9d8d1237.camel@linux.intel.com> <598cd050-f0b5-d18c-96a0-915f02525e3e@fortanix.com> <20181219091148.GA5121@linux.intel.com> <613c6814-4e71-38e5-444a-545f0e286df8@fortanix.com> <20181219144515.GA30909@linux.intel.com> <20181221162825.GB26865@linux.intel.com> <105F7BF4D0229846AF094488D65A0989355A45B6@PGSMSX112.gar.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <105F7BF4D0229846AF094488D65A0989355A45B6@PGSMSX112.gar.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote: > > > > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just > > > opening a new instance of /dev/sgx for each encalve? > > > > Directly associating /dev/sgx with an enclave means /dev/sgx can't be used > > to provide ioctl()'s for other SGX-related needs, e.g. to mmap() raw EPC and > > expose it a VM. Proposed layout in the link below. I'll also respond to > > Jarkko's question about exposing EPC through /dev/sgx instead of having > > KVM allocate it on behalf of the VM. > > > > https://lkml.kernel.org/r/20181218185349.GC30082@linux.intel.com > > Hi Sean, > > Sorry for replying to old email. But IMHO it is not a must that Qemu > needs to open some /dev/sgx and allocate/mmap EPC for guest's virtual > EPC slot, instead, KVM could create private slot, which is not visible > to Qemu, for virtual EPC, and KVM could call core-SGX EPC allocation > API directly. That's possible, but it has several downsides. - Duplicates a lot of code in KVM for managing memory regions. - Artificially restricts userspace to a single EPC region, unless even more code is duplicated to handle multiple private regions. - Requires additional ioctls() or capabilities to probe EPC support - Does not fit with Qemu/KVM's memory model, e.g. all other types of memory are exposed to a guest through KVM_SET_USER_MEMORY_REGION. - Prevents userspace from debugging a guest's enclave. I'm not saying this is a likely scenario, but I also don't think we should preclude it without good reason. - KVM is now responsible for managing the lifecycle of EPC, e.g. what happens if an EPC cgroup limit is lowered on a running VM and KVM can't gracefully reclaim EPC? The userspace hypervisor should ultimately decide how to handle such an event. - SGX logic is split between SGX and KVM, e.g. VA page management for oversubscription will likely be common to SGX and KVM. From a long term maintenance perspective, this means that changes to the EPC management could potentially need to be Acked by KVM, and vice versa. > I am not sure what's the good of allowing userspace to alloc/mmap a > raw EPC region? Userspace is not allowed to touch EPC anyway, expect > enclave code. > > To me KVM creates private EPC slot is cleaner than exposing /dev/sgx/epc > and allowing userspace to map some raw EPC region. Cleaner in the sense that it's faster to get basic support up and running since there are fewer touchpoints, but there are long term ramifications to cramming EPC management in KVM. And at this point I'm not stating any absolutes, e.g. how EPC will be handled by KVM. What I'm pushing for is to not eliminate the possibility of having the SGX subsystem own all EPC management, e.g. don't tie /dev/sgx to a single enclave. > > Thanks, > -Kai