From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 314797D8AA for ; Mon, 10 Dec 2018 07:47:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726262AbeLJHrj (ORCPT ); Mon, 10 Dec 2018 02:47:39 -0500 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:45791 "EHLO relay8-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726202AbeLJHrj (ORCPT ); Mon, 10 Dec 2018 02:47:39 -0500 X-Originating-IP: 50.39.174.102 Received: from localhost (50-39-174-102.bvtn.or.frontiernet.net [50.39.174.102]) (Authenticated sender: josh@joshtriplett.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 387411BF215; Mon, 10 Dec 2018 07:47:19 +0000 (UTC) Date: Sun, 9 Dec 2018 23:47:17 -0800 From: Josh Triplett To: Pavel Machek Cc: Jarkko Sakkinen , x86@kernel.org, platform-driver-x86@vger.kernel.org, dave.hansen@intel.com, sean.j.christopherson@intel.com, nhorman@redhat.com, npmccallum@redhat.com, Alexei Starovoitov , Andi Kleen , Andrew Morton , Andy Lutomirski , Borislav Petkov , "David S. Miller" , David Woodhouse , Greg Kroah-Hartman , "H. Peter Anvin" , Ingo Molnar , "open list:INTEL SGX" , Janakarajan Natarajan , "Kirill A. Shutemov" , Konrad Rzeszutek Wilk , "open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)" , Len Brown , Linus Walleij , "open list:CRYPTO API" , "open list:DOCUMENTATION" , open list , "open list:SPARSE CHECKER" , Mauro Carvalho Chehab , Peter Zijlstra , "Rafael J. Wysocki" , Randy Dunlap , Ricardo Neri , Thomas Gleixner , Tom Lendacky , Vikas Shivappa Subject: Re: [PATCH v11 00/13] Intel SGX1 support Message-ID: <20181210074717.GA9880@localhost> References: <20180608171216.26521-1-jarkko.sakkinen@linux.intel.com> <20180612105011.GA26931@amd> <20180619145943.GC8034@linux.intel.com> <20180619200414.GA3143@amd> <20180619214833.GA5873@localhost> <20181209200600.GA11608@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181209200600.GA11608@amd> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sun, Dec 09, 2018 at 09:06:00PM +0100, Pavel Machek wrote: ... > > > > The default permissions for the device are 600. > > > > > > Good. This does not belong to non-root. > > > > There are entirely legitimate use cases for using this as an > > unprivileged user. However, that'll be up to system and distribution > > policy, which can evolve over time, and it makes sense for the *initial* > > kernel permission to start out root-only and then adjust permissions via > > udev. > > Agreed. > > > Building a software certificate store. Hardening key-agent software like > > ssh-agent or gpg-agent. Building a challenge-response authentication > > system. Providing more assurance that your server infrastructure is > > uncompromised. Offloading computation to a system without having to > > fully trust that system. > > I think you can do the crypto stuff... as crypto already verifies the > results. But I don't think you can do the computation offload. You can, as long as you can do attestation. > > As one of many possibilities, imagine a distcc that didn't have to trust > > the compile nodes. The compile nodes could fail to return results at > > all, but they couldn't alter the results. > > distcc on untrusted nodes ... oh yes, that would be great. > > Except that you can't do it, right? :-). > > First, AFAICT it would be quite hard to get gcc to run under SGX. But > maybe you have spare month or three and can do it. Assuming you don't need to #include files, gcc seems quite simple to run in an enclave: data in, computation inside, data out.