Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp690157ybt; Mon, 6 Jul 2020 20:38:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzczn1Bg6IWOF8eYHdOBSYpZlGx0UcTGayTxCZ6m2SQiTl7DDu86HDoR02bcgilNrNyemGQ X-Received: by 2002:aa7:c3d8:: with SMTP id l24mr51361716edr.97.1594093098919; Mon, 06 Jul 2020 20:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594093098; cv=none; d=google.com; s=arc-20160816; b=TcN6pmdAU0ZNcbHmoAs49iAwFKxfSm8BsVMskd2ayNDbLBeZU3ZoomyXQ5e0qIzInO CpV/UvJ5jW7diwFG17UzejebMXRwoEFZ/ipGVNbw+HRSBdyD1YwL6DS5E7iZtBhBhXQj 0Y9ZPt2wSwmeGpWj1cOdtYvIoFGx3zYT6iNP381PwurXa9hk+Iv2O3KqnIQ3Wn1g16MT qXCn5JxULvcHxndFQB9hUDIy4Nj7r88SFa3WgiKMFMh5ztanjjeC5x9kcsyvy0H7xtzt fdzhfoLjyKHAWPz0WM0OMK8M11D4A8aSbH6+F2gYg63JHSOqRPdP0dBuA+UnRPk0f3kG eKrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Hp0xGFRg77TXwsB3gqqzb9MGA43cz2VdahzAAJzi0C8=; b=VjVfYyhw6XOEURn0yt8SshciRWBRtjnoNM+qhEPu1wg6UWikAj8LYCFZoDYg5t2fsf cu5V7HG6f3T7breuj/Mkr+FF+Ynk1L1NPb0tDVLM4HUOFsKLomDEJr34uGfKdDKxUi9q lz4BCXtRHQoNAoTPDTptRXyoOilYlTpYLrHJEVm7dfPlhF/B/4aGBvnZpqG/STD3QYeS kL7vcHYe7Oyay8mAvBl633Vylpdc0J3YSjGxoyGdzY4f8BznwIsbczYtsviXPReHypyy wjUhhDSnYaKjCY+9TOLRHw0SDvYxaB0Lha1ugGpVSMdla4nlVxUBW5kkYiecjnil0knQ 6ewQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=UfU43NEe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t7si14231965ejx.225.2020.07.06.20.37.55; Mon, 06 Jul 2020 20:38:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=UfU43NEe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728143AbgGGDgX (ORCPT + 99 others); Mon, 6 Jul 2020 23:36:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726869AbgGGDgX (ORCPT ); Mon, 6 Jul 2020 23:36:23 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AD4FC061755; Mon, 6 Jul 2020 20:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Hp0xGFRg77TXwsB3gqqzb9MGA43cz2VdahzAAJzi0C8=; b=UfU43NEeuLUEoytxjSntGO6Gzk sbsi6DFnUdK6kq9AJR9S6DyW32HokIEIiN5sBJoZWDyC9V2Ai7hBtERKDxE8NKOm7AZB/EYHjEfwy h5Kyzez1BnSeBHbU9x/NaAcg+O9lQxh6g0NlmF0T/1bIR9mKnpRu1anZkc6VYFlzXdlSbYSxXYEi9 vIs14/VkgGfHev3oXyqUrMEzEQk5bQkDmYKRedOkVWhyAaotklO41woLgoC5ea+ZLzWesOa6sLY3E tYHCICPTdXK+mxfEd2nht15OvfmGseeOLgBQnfXCfBl9b12Hp7roXNarZXRi9OMvi6Vm8WhNrkKZA c7P2G+UA==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jseP3-0003v8-VO; Tue, 07 Jul 2020 03:36:18 +0000 Date: Tue, 7 Jul 2020 04:36:17 +0100 From: Matthew Wilcox To: Jarkko Sakkinen Cc: x86@kernel.org, linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Jethro Beekman , Haitao Huang , Chunyang Hui , Jordan Hand , Nathaniel McCallum , Seth Moore , Sean Christopherson , Suresh Siddha , andriy.shevchenko@linux.intel.com, asapek@google.com, bp@alien8.de, cedric.xing@intel.com, chenalexchen@google.com, conradparker@google.com, cyhanish@google.com, dave.hansen@intel.com, haitao.huang@intel.com, josh@joshtriplett.org, kai.huang@intel.com, kai.svahn@intel.com, kmoy@google.com, ludloff@google.com, luto@kernel.org, nhorman@redhat.com, puiterwijk@redhat.com, rientjes@google.com, tglx@linutronix.de, yaozhangx@google.com Subject: Re: [PATCH v34 11/24] x86/sgx: Add SGX enclave driver Message-ID: <20200707033617.GF25523@casper.infradead.org> References: <20200707030204.126021-1-jarkko.sakkinen@linux.intel.com> <20200707030204.126021-12-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200707030204.126021-12-jarkko.sakkinen@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 07, 2020 at 06:01:51AM +0300, Jarkko Sakkinen wrote: > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that > can be used by applications to set aside private regions of code and > data. The code outside the SGX hosted software entity is disallowed to s/disallowed to/prevented from/ > access the memory inside the enclave enforced by the CPU. We call these s/enforced// > entities enclaves. > > Add a driver that provides an ioctl API to construct and run enclaves. > Enclaves are constructed from pages residing in reserved physical memory > areas. The contents of these pages can only be accessed when they are > mapped as part of an enclave, by a hardware thread running inside the > enclave. > > The starting state of an enclave consists of a fixed measured set of > pages that are copied to the EPC during the construction process by > using ENCLS leaf functions and Software Enclave Control Structure (SECS) > that defines the enclave properties. > > Enclaves are constructed by using ENCLS leaf functions ECREATE, EADD and > EINIT. ECREATE initializes SECS, EADD copies pages from system memory to > the EPC and EINIT checks a given signed measurement and moves the enclave > into a state ready for execution. What's a leaf function? Is it like a CPU instruction? > The mmap() permissions are capped by the contained enclave page > permissions. The mapped areas must also be opaque, i.e. each page address > must contain a page. This logic is implemented in sgx_encl_may_map(). do you mean "populated" instead of "opaque"? > + atomic_set(&encl->flags, 0); > + kref_init(&encl->refcount); > + INIT_RADIX_TREE(&encl->page_tree, GFP_KERNEL); Why are you using a radix tree instead of an xarray? > +int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start, > + unsigned long end, unsigned long vm_prot_bits) > +{ > + unsigned long idx, idx_start, idx_end; > + struct sgx_encl_page *page; > + > + /* > + * Disallow RIE tasks as their VMA permissions might conflict with the > + * enclave page permissions. > + */ > + if (!!(current->personality & READ_IMPLIES_EXEC)) > + return -EACCES; > + > + idx_start = PFN_DOWN(start); > + idx_end = PFN_DOWN(end - 1); > + > + for (idx = idx_start; idx <= idx_end; ++idx) { > + mutex_lock(&encl->lock); > + page = radix_tree_lookup(&encl->page_tree, idx); > + mutex_unlock(&encl->lock); > + > + if (!page || (~page->vm_max_prot_bits & vm_prot_bits)) > + return -EACCES; You should really use an iterator here instead of repeated lookups. xas_for_each() will probably be what you want.