Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp40883imu; Thu, 10 Jan 2019 17:34:49 -0800 (PST) X-Google-Smtp-Source: ALg8bN4yXaOSvTX3ac7tq9CsWBowNEzW/63df4rwJgBgxhSGIjRoVOmUob7FQEeVMDY8vhICEjOL X-Received: by 2002:a63:62c4:: with SMTP id w187mr10629679pgb.230.1547170489825; Thu, 10 Jan 2019 17:34:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547170489; cv=none; d=google.com; s=arc-20160816; b=O3Yq/hw51/AznGazcQoCoqQJY8eVyLwshGIyN0ZdPfYpINlwrUc8exLjJgW8vrNqiP 3D0UrsMlmIn22mJsfiqK86UZCrdqdwEucoBS61e+BPH2t9ueSCN8HyfurniGsMmC0lFx xU9WUfFQDJDH7Bxn/m3B/OufRotKw9F085VOx/o8Snk9PfR/eQ/Ue0Su3A3T1KQU2sdy djOQtrwtWEEcoHpn711BK0BuUhxmIjN5iyGCetwplF7ziut4TYGuLyT9gI0AZFYDeQX1 IXMTfL3GH8jxhb9eLAsiyNZIuHITXKsah/f/UE5MKk76oQzofIsd4OyTastLs5+H23wo lE+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=tc8oerJVnx0z22rZsUhPJzSlDquRjJ5fXqP2XEhxLBA=; b=W985FeEltxeiD1MQH7Xyxr4QdhgbTVGo/LmRL1qF3G+txmW8jD4LelsHhCJXDolZ+5 h5yW+PLXAvKkUTMwcEL/A/XlOK0TjH1owJbvV/zDJepWK6bdDSEHV4K/IWTxWIcHCAEJ 91pFMoqMxXEgrWlCypzgVlRr/YuA6n+Tqs8cZMeFyUP4nypD6uk7qjv/y8N7hK2jLhJ3 eOfJOxsfzu8ERkw3B9l9e+W/6Jaa2UFuaCf8PCm9XevolVfQaPkl3/HbfEHCiYgd42SC DbhUCuXcbBvQHhO4oQhKm4WS2a9dH2sn7jkHHYl5sHOuBlKByeP9hUbpeQ0vcLEeBKzH 5kUQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r77si23284422pfa.186.2019.01.10.17.34.33; Thu, 10 Jan 2019 17:34:49 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729403AbfAKBcK (ORCPT + 99 others); Thu, 10 Jan 2019 20:32:10 -0500 Received: from mga04.intel.com ([192.55.52.120]:30710 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726369AbfAKBcJ (ORCPT ); Thu, 10 Jan 2019 20:32:09 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2019 17:32:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,463,1539673200"; d="scan'208";a="266250032" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.154]) by orsmga004.jf.intel.com with ESMTP; 10 Jan 2019 17:32:08 -0800 Date: Thu, 10 Jan 2019 17:32:08 -0800 From: Sean Christopherson To: Andy Lutomirski Cc: "Huang, Kai" , 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: <20190111013208.GC2365@linux.intel.com> References: <20181219144515.GA30909@linux.intel.com> <20181221162825.GB26865@linux.intel.com> <105F7BF4D0229846AF094488D65A0989355A45B6@PGSMSX112.gar.corp.intel.com> <20190108220946.GA30462@linux.intel.com> <20190109163135.GA1821@linux.intel.com> <20190110235406.GB2365@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 10, 2019 at 04:30:06PM -0800, Andy Lutomirski wrote: > On Thu, Jan 10, 2019 at 3:54 PM Sean Christopherson > wrote: > > > > Sort of. A guest that is running under KVM (i.e. VMX) is much more > > contained than a random userspace program. A rogue enclave in a VMX > > guest can attack the guest kernel/OS, but barring a bug (or more likely, > > several major bugs) elsewhere in the virtualization stack the enclave > > can't do anything nasty to the host. An enclave would let someone hide > > code, but enclaves are even more restricted than cpl3, i.e. there's not > > a lot it can do without coordinating with unencrypted code in the guest. > > > > And if someone has sufficient permissions to run a KVM guest, they're > > much more likely to do something malcious in the guest kernel, not an > > enclave. > > Are you sure? On my laptop, /dev/kvm is 0666, and that's the distro > default. I don't think this is at all unusual. Wow, that's suprising. A quick search suggests that this may be Debian specific[1], e.g. my Ubuntu systems have: crw-rw---- 1 root kvm 10, 232 Jan 9 09:30 /dev/kvm [1] https://bugzilla.redhat.com/show_bug.cgi?id=1431876 > I'm not particularly > concerned about a guest attacking itself, but it's conceptually > straightforward to bypass whatever restrictions the host has by simply > opening /dev/kvm and sticking your enclave in a VM. VMs by nature allow a user to bypass all sorts of restrictions, e.g. the kernel doesn't let userspace run arbitrary cpl0 code, but launch a VM and voila. It's what you can do with the new privileges that matters. > > All that aside, I don't see any justification for singling out SGX for > > extra scrutiny, there are other ways for a user with KVM permissions to > > hide malicious code in guest (and at cpl0!), e.g. AMD's SEV{-ES}. > > I'm not singling out SGX. I'm just saying that the KVM should not > magically bypass host policy. If you want to assign a virtual > function on your NIC to a KVM guest, you need to give your QEMU > process that privilege. Similarly, if someone has a MAC policy that > controls which processes can launch which enclaves and they want to > run Windows with full SGX support in a VM guest, then they should > authorize that in their MAC policy by giving QEMU unrestricted launch > privileges. MAC systems exist to protect assets, and IMO an enclave isn't an asset. E.g. AppArmor (via LSM) isn't protecting files, it's protecting the contents of the file or what can be done with the file. And the MAC is only part of the overall protection scheme, e.g. userspace is also relying on the kernel to not screw up the page tables. In SGX terms, a LSM hook might use enclave signatures to protect some asset 'X', e.g. access to persistent identifier. But that doesn't mean that whitelisting enclave signatures is the only way to protect 'X'. > Similarly, if access to a persistent provisioning identifier is > restricted, access to /dev/kvm shouldn't magically bypass it. Just > give the QEMU process the relevant privileges. Agreed, but that's not same as applying a host's whitelist against a guest's enclaves.