From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932628AbdCIRQV (ORCPT ); Thu, 9 Mar 2017 12:16:21 -0500 Received: from mail.kernel.org ([198.145.29.136]:50730 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754526AbdCIRQT (ORCPT ); Thu, 9 Mar 2017 12:16:19 -0500 MIME-Version: 1.0 In-Reply-To: <1489039396.30766.0@smtp.gmail.com> References: <1489039396.30766.0@smtp.gmail.com> From: Andy Lutomirski Date: Thu, 9 Mar 2017 08:22:18 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [intel-sgx-kernel-dev] SGX notes from KS/LPC To: Kai Huang Cc: Andy Lutomirski , intel-sgx-kernel-dev@ml01.01.org, Josh Triplett , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 8, 2017 at 10:03 PM, Kai Huang wrote: > === Virtualization considerations === At some point, someone will need to > decide what restrictions if any KVM should impose on its guests' use of SGX. > For example, should KVM limit the set of SGXLEPUBKEYHASH values that its > guests can use? Should KVM intercept EINIT and filter enclaves directly? You must be using one of those newfangled gmail apps that totally screws up quoting. Sigh. I need to switch away from gmail myself -- they keep regressing basic text editing functionality :( > > > Hi Andy, > > Thank you very much for the informative notes. It is very helpful! > > For virtualization considerations, would you elaborate why we should impose > restrictions on the guests use of SGX? I think in general virtualization > only *virtualize* the hardware behavior but doesn't impose restrictions from > software's perspective. For example, we cannot restrict a physical machine > to only run launch enclave provided by RedHat (am I right?), so if we > virtualize a machine with SGX supported, we should not restrict that the > virtual machine to be only able to run launch enclave from RedHat. Good question. In general, I agree with you, but there are a couple of SGX-specific considerations here. 1. Assuming that Launch Control serves a purpose at all, the best legitimate purpose is to enforce some kind of policy on what enclaves may run. On Linux, this policy will primarily be configured by the kernel. If the kernel were to be configured so as to only allow some subset of enclaves but KVM didn't restrict what guests could do, then KVM could be used to do an end run around the kernel policy. We don't know what kinds of kernel policies will be useful, so I doubt it's clear to anyone as to whether this matters. 2. Since Intel didn't provide a way for a hypervisor to make keys derived by EGETKEY in guests different from keys derived in the host, enclaves in a guest are effectively running at full host privilege and with the host's identity. This means, for example, that a provisioning enclave running in the guest will be able to convince a third part that it represents the *host*. This may be a bad thing and I can see some cause for preventing provisioning enclaves from running in guests unless explicitly opted-in by the host admin. Similarly, normal enclaves in the guest get the same sealing key that they would get in other guests on the same host, which could break certain security assumptions. I'm not sure how to address this without Intel's help, but constraining what guests can do would be a start.