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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS 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 8BE14C433DB for ; Fri, 15 Jan 2021 21:34:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B7FF2065D for ; Fri, 15 Jan 2021 21:34:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726361AbhAOVe0 (ORCPT ); Fri, 15 Jan 2021 16:34:26 -0500 Received: from mga04.intel.com ([192.55.52.120]:54870 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbhAOVeZ (ORCPT ); Fri, 15 Jan 2021 16:34:25 -0500 IronPort-SDR: HOCA39CoV4BiPjovxh1Sez5jMr5/t+9TGq5bKF5N9nuSIlu0N9B2j7xm2Uju24+P+DE6oSXIt3 BiHjnQT+udLQ== X-IronPort-AV: E=McAfee;i="6000,8403,9865"; a="176032069" X-IronPort-AV: E=Sophos;i="5.79,350,1602572400"; d="scan'208";a="176032069" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2021 13:33:44 -0800 IronPort-SDR: dJtW2dWTT9lzuk9HegV3DKjG/PYzTiisz7M1bF3Id20+LquKwQQnko/vRzTqOfxCkutOeh5dQb Vk17wSsIDQhQ== X-IronPort-AV: E=Sophos;i="5.79,350,1602572400"; d="scan'208";a="572731711" Received: from stsmyth-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.231.187]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2021 13:33:41 -0800 Date: Sat, 16 Jan 2021 10:33:39 +1300 From: Kai Huang To: Dave Hansen Cc: , , , , , , , , , , , Subject: Re: [RFC PATCH 03/23] x86/sgx: Introduce virtual EPC for use by KVM guests Message-Id: <20210116103339.0e36349cbde63ee8beba03e4@intel.com> In-Reply-To: References: <2e424ff3-51cb-d6ed-6c5f-190e1d4fe21a@intel.com> <20210107144203.589d4b2a7a2d2b53c4af7560@intel.com> <20210116030713.276e48c023330172cded174c@intel.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Fri, 15 Jan 2021 07:39:44 -0800 Dave Hansen wrote: > On 1/15/21 6:07 AM, Kai Huang wrote: > >>From virtual EPC's perspective, if we don't force this in kernel, then > > *theoretically*, userspace can use fork() to make multiple VMs map to the > > same physical EPC, which will potentially cause enclaves in all VMs to behave > > abnormally. So to me, from this perspective, it's better to enforce in kernel > > so that only first VM can use this virtual EPC instance, because EPC by > > architectural design cannot be shared. > > > > But as Sean said, KVM doesn't support VM across multiple mm structs. And if I > > read code correctly, KVM doesn't support userspace to use fork() to create new > > VM. For instance, when creating VM, KVM grabs current->mm and keeps it in > > 'struct kvm' for bookkeeping, and kvm_vcpu_ioctl() and kvm_device_ioctl() will > > refuse to work if kvm->mm doesn't equal to current->mm. So in practice, I > > believe w/o enforcing this in kernel, we should also have no problem here. > > > > Sean, please correct me if I am wrong. > > > > Dave, if above stands, do you think it is reasonable to keep current->mm in > > epc->mm and enforce in sgx_virt_epc_mmap()? > > Everything you wrote above tells me the kernel should not be enforcing > the behavior. You basically said that it's only a theoretical problem, > and old if someone goes and does something with KVM that's nobody can do > today. > > You've 100% convinced me that having the kernel enforce this is > *un*reasonable. Sean, I'll remove epc->mm, unless I see your further objection. Thanks to you both.