Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp157429imm; Thu, 21 Jun 2018 15:50:56 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIAng0MOavJohoXMHR0is7L+ARBC93HFEpPIcbkspug5xHKqUsLD5Kww13emrjly0SdhV/I X-Received: by 2002:a17:902:f83:: with SMTP id 3-v6mr30058117plz.282.1529621456212; Thu, 21 Jun 2018 15:50:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529621456; cv=none; d=google.com; s=arc-20160816; b=yDU+lORNHt20Dq2AMnwr+/OBTHzmN3SY3l1m4H9zRVeyBYlnEMD3nvGhosIQwBsJQ5 rjqtVYjN/I95f/9dcEYyTAcDQHHbPIaa2jeJ4HgOEoM6shtxKDtq6zMrcw3hO0eH1sLY 9c+zOtmFjWZ41MMQ6AUpfiVBUxpOlyMyLrg5cAkzsiTBMv8Wf/IpcMDBqZ9S5pr3Pljn u+/iN0sAHz/+6sC2G57Sk3OyPUubw9E+DwK/Fyb65Gnd96el6WBPzdoscD++VeW8Tm/y FWebl8vCcngp8Pd9aamTyK0+QtIdafVhvZeut4ZYr6K53Q6b7w2CFMmOZJuvMz3RXES/ dWSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=wnL8/kUMD03NCENmGhlFF12JfpNXuS+DhJ9O30sRt1g=; b=xZq1bCjow2Wn4mg0l0uXSZOac9RgS29EtjaHfw/elntzF4vCNW1t441FgHl57gABir X2Y0fgQul1NPCpKjVeUsQuP5kq6qUGYnuNgygTK4uql4l1ytJ14LPyNGneNE/yVL3KSU rTPEraPfs7G4nGiPNB5fVVQe+TvMPj1xBsVdT0D+dGQoef/mGTdYjs7HQD50UlHxltG5 MS6y92i8GBSezMYFpyHeV0vIcNPWYXYqlWEswRPmCUlbsIaNxzyGgXIdKh8MX0WjyBDH wkD62snxzZO6vBdz4PKgEtYeylx6RzC7z/BMMIgDUU9RxDAxm6ZRwMHQQc24mYIuAqmR 5tJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xMWi0K+i; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v18-v6si5591177pff.248.2018.06.21.15.50.41; Thu, 21 Jun 2018 15:50:56 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=xMWi0K+i; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934034AbeFUWtE (ORCPT + 99 others); Thu, 21 Jun 2018 18:49:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:51380 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933828AbeFUWtC (ORCPT ); Thu, 21 Jun 2018 18:49:02 -0400 Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 07EA022522 for ; Thu, 21 Jun 2018 22:49:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1529621342; bh=C7ZnpsE+Bvumge+SIQm9IA73k80yAdSl5exqjZJJT54=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=xMWi0K+iSDJ8uYU8drnVWcJGXZyVeC4ptvbvIP9GzFC4Rc5yFDFwCew6sw25LCsgd YqzUlsOItGiCf7FLe8BAIy3YcCNLYVSUFT7pMvOydATmtEq2pFNpnZMejWIiiMGfEr v4fXBxtIJFGTIPcSez+vEi6QfrGWl0gqhO69MDDI= Received: by mail-wm0-f54.google.com with SMTP id v131-v6so330015wma.1 for ; Thu, 21 Jun 2018 15:49:01 -0700 (PDT) X-Gm-Message-State: APt69E3yHpvyFVMafQdxKXyNU/yPQ7x7xKtqIBNufonGVdtevCNYAKRE ckj+cqLPCq25y2mHGwm8UoqnGHCNZev7YqtSRgy09w== X-Received: by 2002:a1c:f902:: with SMTP id x2-v6mr6148668wmh.116.1529621340396; Thu, 21 Jun 2018 15:49:00 -0700 (PDT) MIME-Version: 1.0 References: <20180611115255.GC22164@hmswarspite.think-freely.org> <20180612174535.GE19168@hmswarspite.think-freely.org> <20180620210158.GA24328@linux.intel.com> <20180621152903.GB1324@hmswarspite.think-freely.org> In-Reply-To: From: Andy Lutomirski Date: Thu, 21 Jun 2018 15:48:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave To: npmccallum@redhat.com Cc: nhorman@redhat.com, "Christopherson, Sean J" , Jethro Beekman , Andrew Lutomirski , Jarkko Sakkinen , X86 ML , Platform Driver , LKML , Ingo Molnar , intel-sgx-kernel-dev@lists.01.org, "H. Peter Anvin" , Darren Hart , Thomas Gleixner , andy@infradead.org, Peter Jones Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum wrote: > > If this is acceptable for everyone, my hope is the following: > > 1. Intel would split the existing code into one of the following > schemas (I don't care which): > A. three parts: UEFI module, FLC-only kernel driver and user-space > launch enclave > B. two parts: UEFI module (including launch enclave) and FLC-only > kernel driver > > 2. Intel would release a reproducible build of the GPL UEFI module > sources signed with a SecureBoot trusted key and provide an > acceptable[0] binary redistribution license. > > 3. The kernel community would agree to merge the kernel driver given > the above criteria (and, obviously, acceptable kernel code). > > The question of how to distribute the UEFI module and possible launch > enclave remains open. I see two options: independent distribution and > bundling it in linux-firmware. The former may be a better > technological fit since the UEFI module will likely need to be run > before the kernel (and the boot loader; and shim). However, the latter > has the benefit of already being a well-known entity to our downstream > distributors. I could go either way on this. This is a lot of complication and effort for a gain that is not entirely clear. I really really really do *not* want to see Intel or anyone else start enforcing policy on which programs can and cannot run using this mechanism. (This is exactly why non-FLC systems aren't about to be supported upstream.) So my preference is to not merge anything that supports this type of use case unless there is compelling evidence that it is (a) genuinely useful, (b) will be used to improve security and (c) won't be abused for, say, revenue purposes. --Andy