Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp205197ybs; Tue, 26 May 2020 07:16:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCJsgLEUKItBGiUW1+m0oC6sLFYogP64NYFi79X1pOBPmwNJnodJy8fj3rLAfHyo4LNMMB X-Received: by 2002:a17:906:16c9:: with SMTP id t9mr1371362ejd.253.1590502594534; Tue, 26 May 2020 07:16:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590502594; cv=none; d=google.com; s=arc-20160816; b=wKheOBMUoHf6t+0bO5M3AyKrjct3JY0cDTzkrh+f0WgpOHac0ln6TC3b3zd90uwznr rGdxaamfUoCFB7j9XTwyHQREyaYBJAP3/pZAoc8TJEomixqcxZHZFUDThh5UsM+8T4dF jHvxMVhJqHptPmn6yZYxs/IfjbDtUwFhwDRreszHN6bOmV7H47MJQfRlXn+QdePVYKEC HWqMPX5QiDmcIpQUab/KXC7npRwSATkLNEM4FNBhhWm3BxF3wrJHls7P0cXY/YQhxfcx TxdcHvEpJuYqyG5ZRHmyQZTw9y1jc57ocdAgca57tfYLSVa8dC+ykYOzeLcTFlv5EX59 li1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ZGH6cJ+EMFRFX4aplnDSD+DpMuQLo38Ps+fJV82VzCI=; b=SCsuIu/819eeReLbBpuoBP4/xbQzKhdL4g7NBR0439Q+DQ4c4amkEcjdb6zz2jVgCt ECC8MKm9lixW4e334MibMThv4bX67fQ/A/3D3nkLMw9rQOOeDuTljOXwXj7icjrs7s57 hkKW4mOFxBTToDiJtfM3fJftWOicCD4DxvZVuMnW/ZF/toDQ37EWoIrcL2LkrD8rVH9r jPiCPAgAxpzhzy0ns12owQFb8S39bQSCOK1nvXIKmo9t58IUk9c9IsWprw38mSneQNOJ nVEzViuULqm4hCv1F++Ad4+XL4+Wra7rWDN2Egq6qfIBYdiZyX9b/YaDCXh5wJJzuV73 loug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=qlSo2Zbx; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w23si10954344edr.260.2020.05.26.07.16.10; Tue, 26 May 2020 07:16:34 -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=pass header.i=@alien8.de header.s=dkim header.b=qlSo2Zbx; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729337AbgEZMwV (ORCPT + 99 others); Tue, 26 May 2020 08:52:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726882AbgEZMwU (ORCPT ); Tue, 26 May 2020 08:52:20 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76D1FC03E96D; Tue, 26 May 2020 05:52:20 -0700 (PDT) Received: from zn.tnic (p200300ec2f0f910029cc1ac058818593.dip0.t-ipconnect.de [IPv6:2003:ec:2f0f:9100:29cc:1ac0:5881:8593]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id CD3C51EC0118; Tue, 26 May 2020 14:52:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1590497538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZGH6cJ+EMFRFX4aplnDSD+DpMuQLo38Ps+fJV82VzCI=; b=qlSo2ZbxzQoEd46ObhBqeRWPa6sLsZbdFDMdO6sqoBqhzSgPMMxW0dZvXVV9mMQ/2l//1O sHyXBTNiS43qkWgA9OkgGUuAzdGy61Wu2libvEx7SeFNdr3MH860Ee7RdoT/YGbR1ryt4V VUppJQiINcI6WieHJiReA+PRI0FpEB0= Date: Tue, 26 May 2020 14:52:08 +0200 From: Borislav Petkov To: Jarkko Sakkinen Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org, akpm@linux-foundation.org, dave.hansen@intel.com, sean.j.christopherson@intel.com, nhorman@redhat.com, npmccallum@redhat.com, haitao.huang@intel.com, andriy.shevchenko@linux.intel.com, tglx@linutronix.de, kai.svahn@intel.com, josh@joshtriplett.org, luto@kernel.org, kai.huang@intel.com, rientjes@google.com, cedric.xing@intel.com, puiterwijk@redhat.com, Jethro Beekman Subject: Re: [PATCH v30 08/20] x86/sgx: Add functions to allocate and free EPC pages Message-ID: <20200526125207.GE28228@zn.tnic> References: <20200515004410.723949-1-jarkko.sakkinen@linux.intel.com> <20200515004410.723949-9-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200515004410.723949-9-jarkko.sakkinen@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 15, 2020 at 03:43:58AM +0300, Jarkko Sakkinen wrote: > Add functions for allocating page from Enclave Page Cache (EPC). A page is pages > allocated by going through the EPC sections and returning the first free > page. > > When a page is freed, it might have a valid state, which means that the > callee has assigned it to an enclave, which are protected memory ares used areas although explaining what enclaves are has already happened so probably not needed here too. > to run code protected from outside access. The page is returned back to the > invalid state with ENCLS[EREMOVE] [1]. > > [1] Intel SDM: 40.3 INTELĀ® SGX SYSTEM LEAF FUNCTION REFERENCE > > Co-developed-by: Sean Christopherson > Signed-off-by: Sean Christopherson > Acked-by: Jethro Beekman > Signed-off-by: Jarkko Sakkinen > --- > arch/x86/kernel/cpu/sgx/main.c | 60 ++++++++++++++++++++++++++++++++++ > arch/x86/kernel/cpu/sgx/sgx.h | 3 ++ > 2 files changed, 63 insertions(+) > > diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c > index 38424c1e8341..60d82e7537c8 100644 > --- a/arch/x86/kernel/cpu/sgx/main.c > +++ b/arch/x86/kernel/cpu/sgx/main.c > @@ -13,6 +13,66 @@ > struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS]; > int sgx_nr_epc_sections; > > +static struct sgx_epc_page *__sgx_try_alloc_page(struct sgx_epc_section *section) > +{ > + struct sgx_epc_page *page; > + > + if (list_empty(§ion->page_list)) > + return NULL; > + > + page = list_first_entry(§ion->page_list, struct sgx_epc_page, list); > + list_del_init(&page->list); > + return page; > +} > + > +/** > + * sgx_try_alloc_page() - Allocate an EPC page Uuh, this is confusing. Looking forward into the patchset, you guys have sgx_alloc_page() sgx_alloc_va_page() and this here sgx_try_alloc_page() So this one here should be called sgx_alloc_epc_page() if we're going to differentiate *what* it is allocating. But then looking at sgx_alloc_page(): + * sgx_alloc_page() - Allocate an EPC page ... + struct sgx_epc_page *sgx_alloc_page(void *owner, bool reclaim) this one returns a struct sgx_epc_page * too. The former "allocates" from the EPC cache so I'm thinking former should not have "alloc" in its name at all. It should be called something like sgx_get_epc_page() or so. Now, looking at sgx_alloc_page(), it does call this one - sgx_try_alloc_page() to get a page from the page list but it does not allocate anything. The actual allocation happens in sgx_alloc_epc_section() which actually does the k*alloc(). Which sounds to me like those functions should not use "alloc" and "free" in their names but "get" and "put" to denote that they're simply getting pages from lists and returning them back to those lists. IMNSVHO. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette