Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp142649yba; Fri, 19 Apr 2019 22:45:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTo8N8FyEBCwknyt6Whre9ZHq3KWNTs7YTvXnAaWu2NoofcjLi2j4Xg2fqBFf1hrpxgtXj X-Received: by 2002:a62:1194:: with SMTP id 20mr8155221pfr.224.1555739101262; Fri, 19 Apr 2019 22:45:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555739101; cv=none; d=google.com; s=arc-20160816; b=LWuoUz0DMvpCEJi7iVrvPhTv2A4o41Zr5Mx9BwYpJF2pi9naX11DMA2g9DBeemz/Jd n2dmv42WDs6/QIncjWctieGtvgFACbkCchzgPzeyPsvFCVAxw3hJhkW/gqljsOdx2Sn0 Z6p6/LOYU0EHsVQbdd6JXKJFSe9MVeFlLrIcuHLL10lBzKZ2pjAi71ibhW+ovOHvS/sg fxj4/gnjbKBgL6M4ZrOIjJChxPvBamhU6VBSfuydF3IUGKQFvB/YwHtO2PtHNiOPq+aO g1TGQAP623MfAPyuglyVNej0mSoAo/7cQjStwWFsTkMeY6GSu8DJyEP8h/4sgU43thrO xv6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=2jCEQn/bk6r/fTgqH9WMKbupKKvyK1YaptNVNZK4oio=; b=x0ns8FF4UjxL9LD8UPvlDrCVSlSY9MX+ava5O5CglWHbSR5IzWhkyQq5nF7d9p+8Fr lM59oj6Ab3Gbu9C20Xwgy3p+9KK1+OEwSaw9M4pKtYW4MyyZnEPaAKhWRaecrmI6uSoI 6ANF7E45rZd/nqC77B1eM76xBXwIP4NPgYW2FBQRmUewmKTgUMDNCAYRz+cEZbZK2523 WG59/RdSGou5keTGq7WNdhjw4cGTuzPL33p+JROalHJQb7DNJRj6BfLkjetBS2DAD49j knOvWZwmFhp1NTrPzfHiNiidUGR26hB15hdeLwOZCgeZZH+Vs5/KwpiWgH5uJOQATFeH nYaw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c12si6657810pgj.461.2019.04.19.22.44.43; Fri, 19 Apr 2019 22:45:01 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726075AbfDTFm2 (ORCPT + 99 others); Sat, 20 Apr 2019 01:42:28 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:42806 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725884AbfDTFm1 (ORCPT ); Sat, 20 Apr 2019 01:42:27 -0400 Received: from pd9ef12d2.dip0.t-ipconnect.de ([217.239.18.210] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hHilT-0002pw-F9; Sat, 20 Apr 2019 07:42:15 +0200 Date: Sat, 20 Apr 2019 07:42:13 +0200 (CEST) From: Thomas Gleixner To: Jethro Beekman cc: Andy Lutomirski , Andy Lutomirski , "Dr. Greg" , Dave Hansen , Jarkko Sakkinen , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "Christopherson, Sean J" , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Subject: Re: [PATCH v20 00/28] Intel SGX1 support In-Reply-To: <5854e66a-950e-1b12-5393-d9cdd15367dc@fortanix.com> Message-ID: References: <20190417103938.7762-1-jarkko.sakkinen@linux.intel.com> <20190418171059.GA20819@wind.enjellic.com> <09ebfa1d-c03d-c1fe-ff0f-d99287b6ec3c@intel.com> <20190419141732.GA2269@wind.enjellic.com> <43aa8fdd-e777-74cb-e3f0-d36805ffa18b@fortanix.com> <8c5133bc-1301-24ca-418d-7151a6eac0e2@fortanix.com> <2AE80EA3-799E-4808-BBE4-3872F425BCF8@amacapital.net> <49b28ca1-6e66-87d9-2202-84c58f13fb99@fortanix.com> <444537E3-4156-41FB-83CA-57C5B660523F@amacapital.net> <5854e66a-950e-1b12-5393-d9cdd15367dc@fortanix.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Apr 2019, Jethro Beekman wrote: > On 2019-04-19 14:34, Thomas Gleixner wrote: > > And how so? You create writeable AND executable memory. That's a nono and > > you can argue in circles, that's not going to change with any of your > > proposed changes. > > On 2019-04-19 14:38, Thomas Gleixner wrote: > > You are working around LSM nothing else and that's just not going to fly. > > Based on your comments, I'm still unsure if we're on the same page with > regards to what I'm proposing. > > Here's a regular non-SGX flow that LSM would likely prevent: > > mmap(PROT_READ|PROT_WRITE) > memcpy() > mmap(PROT_READ|PROT_EXEC) <-- denied by LSM > > Or just something based on regular PT permissions: > > mmap(PROT_READ|PROT_EXEC) > memcpy() <-- SIGSEGV > > Now, the equivalent for SGX: > > mmap(PROT_READ|PROT_WRITE) > ioctl(EADD) > mmap(PROT_READ|PROT_EXEC) <-- denied by LSM This is completely irrelevant, really. The point is that the SGX driver loads and executes arbitrary data which is handed in from user space via an ioctl w/o any chance of verifying where that comes from. What Andy proposed is to open a file with the SGX payload and hand in the file descriptor. That way LSM can decide whether this is allowed or denied based on the file descriptor and whatever the security model/policy is in a particular setup. Right know the SGX driver and its proposed API prevent any form of LSM auditing and whatever permission checks you had in mind won't change that at all. Thanks, tglx