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,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 E46C6C433DB for ; Thu, 4 Feb 2021 03:19:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B35D264F4C for ; Thu, 4 Feb 2021 03:19:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233533AbhBDDTL (ORCPT ); Wed, 3 Feb 2021 22:19:11 -0500 Received: from mga06.intel.com ([134.134.136.31]:49845 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232779AbhBDDTK (ORCPT ); Wed, 3 Feb 2021 22:19:10 -0500 IronPort-SDR: t7F1O7UDT1amNr1gblbvvFI/EvqVjJRrVRc+XQA4cLQ8Y2sni4gbieDRobKa5ZNfYH9OTWfCkZ OgYLpE14ziuw== X-IronPort-AV: E=McAfee;i="6000,8403,9884"; a="242671759" X-IronPort-AV: E=Sophos;i="5.79,400,1602572400"; d="scan'208";a="242671759" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2021 19:18:26 -0800 IronPort-SDR: XFK3FLCZUz9UMJggKHFnlvZMSpksYPiPiTOMyTBIWGKihY+iuN9dVuyTRJQ4MqNmdKTUlBenwl okH2EKAgh0yw== X-IronPort-AV: E=Sophos;i="5.79,400,1602572400"; d="scan'208";a="583042825" Received: from hgheewal-mobl2.amr.corp.intel.com ([10.254.80.158]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2021 19:18:20 -0800 Message-ID: <5bd3231e05911bc64f5c51e1eddc3ed1f6bfe6c4.camel@intel.com> Subject: Re: [RFC PATCH v3 00/27] KVM SGX virtualization support From: Kai Huang To: Sean Christopherson Cc: Dave Hansen , 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: Thu, 04 Feb 2021 16:18:17 +1300 In-Reply-To: References: <99135352-8e10-fe81-f0dc-8d552d73e3d3@intel.com> <475c5f8b-efb7-629d-b8d2-2916ee150e4f@redhat.com> <44b5a747aaf1d42fb8ef388bd28f49614d42cd50.camel@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: linux-sgx@vger.kernel.org On Wed, 2021-02-03 at 16:28 -0800, Sean Christopherson wrote: > On Thu, Feb 04, 2021, Kai Huang wrote: > > On Wed, 2021-02-03 at 15:37 -0800, Dave Hansen wrote: > > > On 2/3/21 3:32 PM, Sean Christopherson wrote: > > > > > > > Yeah, special casing KVM is almost always the wrong thing to do. > > > > > > > Anything that KVM can do, other subsystems will do as well. > > > > > > Agreed. Thwarting ioremap itself seems like the right way to go. > > > > > This sounds irrelevant to KVM SGX, thus I won't include it to KVM SGX series. > > > > I would say it's relevant, but a pre-existing bug. Same net effect on what's > > > > needed for this series.. > > > > > > > > I say it's a pre-existing bug, because I'm pretty sure KVM can be coerced into > > > > accessing the EPC by handing KVM a memslot that's backed by an enclave that was > > > > created by host userspace (via /dev/sgx_enclave). > > > > > > Dang, you beat me to it. I was composing another email that said the > > > exact same thing. > > > > > > I guess we need to take a closer look at the KVM fallout from this. > > > It's a few spots where it KVM knew it might be consuming garbage. It > > > just get extra weird stinky garbage now. > > > > I don't quite understand how KVM will need to access EPC memslot. It is *guest*, but > > not KVM, who can read EPC from non-enclave. And if I understand correctly, there will > > be no place for KVM to use kernel address of EPC to access it. To KVM, there's no > > difference, whether EPC backend is from /dev/sgx_enclave, or /dev/sgx_vepc. And we > > really cannot prevent guest from doing anything. > > > > So how memremap() of EPC section is related to KVM SGX? For instance, the > > implementation of this series needs to be modified due to this? > > See kvm_vcpu_map() -> __kvm_map_gfn(), which blindly uses memremap() when the > resulting pfn isn't a "valid" pfn. KVM doesn't need access to an EPC memslot, > we're talking the case where a malicious userspace/guest hands KVM a GPA that > resolves to the EPC. E.g. nested VM-Enter with the L1->L2 MSR bitmap pointing > at EPC. L0 KVM will intercept VM-Enter and then read L1's bitmap to merge it's > desires with L0 KVM's requirements. That read will hit the EPC, and thankfully > for KVM, return garbage. Right. I missed __kvm_map_gfn(). I am not quite sure returning all ones can be treated as garbage, since one can means true for a boolean, or one bit in bitmap as you said. But since this only happens when guest/userspace is malicious, so causing misbehavior to the guest is fine? Do we see any security risk here? And I also agree that denying memremap() for EPC is desirable. But I am not sure whether this should be addressed before KVM SGX series, or KVM SGX series should take care of it.