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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 B3D66C433E0 for ; Fri, 5 Feb 2021 12:36:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66DFB64FB5 for ; Fri, 5 Feb 2021 12:36:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232172AbhBEMgL (ORCPT ); Fri, 5 Feb 2021 07:36:11 -0500 Received: from mga03.intel.com ([134.134.136.65]:46470 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232148AbhBEMdm (ORCPT ); Fri, 5 Feb 2021 07:33:42 -0500 IronPort-SDR: mSiTMEPLWrL85gMbWrnX3fTz5ghv0GFNiUkNqwanWs6tmH1L4m677nXefYqJXAQ5bOJ2RZO5tl TveCGvnZknHw== X-IronPort-AV: E=McAfee;i="6000,8403,9885"; a="181490635" X-IronPort-AV: E=Sophos;i="5.81,154,1610438400"; d="scan'208";a="181490635" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2021 04:33:00 -0800 IronPort-SDR: /RP21vhYieDly6c3NcARWjOrNa+aVTRf6m5/uYOoNbjVkzUbnRJWQgHssxtWMsp8HMs32Mx1eX PywILmtIIRFQ== X-IronPort-AV: E=Sophos;i="5.81,154,1610438400"; d="scan'208";a="508523273" Received: from nadams-mobl1.amr.corp.intel.com ([10.254.96.120]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2021 04:32:56 -0800 Message-ID: <35808048da366b7e531f291c3611c1172f988d6a.camel@intel.com> Subject: Re: [RFC PATCH v3 00/27] KVM SGX virtualization support From: Kai Huang To: Dave Hansen , Sean Christopherson Cc: Paolo Bonzini , "Edgecombe, Rick P" , "linux-sgx@vger.kernel.org" , "kvm@vger.kernel.org" , "x86@kernel.org" , "corbet@lwn.net" , "luto@kernel.org" , "jethro@fortanix.com" , "wanpengli@tencent.com" , "mingo@redhat.com" , "b.thiel@posteo.de" , "tglx@linutronix.de" , "jarkko@kernel.org" , "joro@8bytes.org" , "hpa@zytor.com" , "jmattson@google.com" , "vkuznets@redhat.com" , "bp@alien8.de" , "Huang, Haitao" Date: Sat, 06 Feb 2021 01:32:53 +1300 In-Reply-To: <635e339e-e3f5-c437-0265-b9d44c180858@intel.com> References: <475c5f8b-efb7-629d-b8d2-2916ee150e4f@redhat.com> <44b5a747aaf1d42fb8ef388bd28f49614d42cd50.camel@intel.com> <5bd3231e05911bc64f5c51e1eddc3ed1f6bfe6c4.camel@intel.com> <635e339e-e3f5-c437-0265-b9d44c180858@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 2021-02-04 at 08:48 -0800, Dave Hansen wrote: > On 2/4/21 8:28 AM, Sean Christopherson wrote: > > > Do we see any security risk here? > > Not with current CPUs, which drop writes and read all ones. If future CPUs take > > creatives liberties with the SDM, then we could have a problem, but that's why > > Dave is trying to get stronger guarantees into the SDM. > > I really don't like the idea of the abort page being used by code that > doesn't know what it's dealing with. It just seems like trouble (aka. > security risk) waiting to happen. Hi Dave, Just to confirm, you want this (disallow ioremap() for EPC) fixed in upstream kernel before KVM SGX can be merged, correct? If so, and since it seems you also agreed that better solution is to modify ioremap() to refuse to map EPC, what do you think of the sample code Sean put in his previous reply? https://www.spinics.net/lists/kvm/msg234754.html IMHO adding 'bool sgx_epc' to ioremap_desc seems not ideal, since it's not generic. Instead, we may define some new flag here, and ioremap_desc->flag can just cope with it. Btw as Sean already pointed out, SGX code uses memremap() to initialize EPC section, and we could choose to still allow this to avoid code change to SGX driver. But it seems it is a little hack here. What's your opinion? Hi Sean, If we all agree the fix is needed here, do you want to work on the patch (since you already provided your thought), or do you want me to do it, with Suggested-by you?