From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C845DC4363C for ; Mon, 5 Oct 2020 03:06:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12269207C4 for ; Mon, 5 Oct 2020 03:06:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12269207C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DA1096B005D; Sun, 4 Oct 2020 23:06:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D521B8E0001; Sun, 4 Oct 2020 23:06:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3F846B0068; Sun, 4 Oct 2020 23:06:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 94C826B005D for ; Sun, 4 Oct 2020 23:06:33 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 24C371EE6 for ; Mon, 5 Oct 2020 03:06:33 +0000 (UTC) X-FDA: 77336383866.22.maid04_0b0108d271ba Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id F3DAF18038E60 for ; Mon, 5 Oct 2020 03:06:32 +0000 (UTC) X-HE-Tag: maid04_0b0108d271ba X-Filterd-Recvd-Size: 5106 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 03:06:31 +0000 (UTC) IronPort-SDR: CO4vV792YhzchiUCZ9R0UTVsgXcCU1JC0uewvZg5uDPIDp0rFBJgtTp0nOxxf+Xfxjm/Cm5GVC 4HnKGPURT6VA== X-IronPort-AV: E=McAfee;i="6000,8403,9764"; a="224942390" X-IronPort-AV: E=Sophos;i="5.77,337,1596524400"; d="scan'208";a="224942390" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2020 20:06:29 -0700 IronPort-SDR: 5NaMJ8KMuA5SAX+NZz4ygdetZ7eGAwZ6u7txBeQp4rS5Yiye3bU7BjuORBvq4iQfrKatMh8qVf 78Ud5EQMsiJg== X-IronPort-AV: E=Sophos;i="5.77,337,1596524400"; d="scan'208";a="523209843" Received: from sidorovd-mobl1.ccr.corp.intel.com (HELO localhost) ([10.252.48.68]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2020 20:06:21 -0700 Date: Mon, 5 Oct 2020 06:06:19 +0300 From: Jarkko Sakkinen To: Matthew Wilcox 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 , Darren Kenny , 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, 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, mikko.ylinen@intel.com Subject: Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver Message-ID: <20201005030619.GA126283@linux.intel.com> References: <20201003045059.665934-1-jarkko.sakkinen@linux.intel.com> <20201003045059.665934-12-jarkko.sakkinen@linux.intel.com> <20201003195440.GD20115@casper.infradead.org> <20201004215049.GA43926@linux.intel.com> <20201004222750.GI20115@casper.infradead.org> <20201004234153.GA49415@linux.intel.com> <20201005013053.GJ20115@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201005013053.GJ20115@casper.infradead.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 05, 2020 at 02:30:53AM +0100, Matthew Wilcox wrote: > > In my Geminilake NUC the maximum size of the address space is 64GB for > > an enclave, and it is not fixed but can grow in microarchitectures > > beyond that. > > > > That means that in (*artificial*) worst case the locks would be kept for > > 64*1024*1024*1024/4096 = 16777216 iterations. > > Oh, there's support for that on the XArray API too. > > xas_lock_irq(&xas); > xas_for_each_marked(&xas, page, end, PAGECACHE_TAG_DIRTY) { > xas_set_mark(&xas, PAGECACHE_TAG_TOWRITE); > if (++tagged % XA_CHECK_SCHED) > continue; > > xas_pause(&xas); > xas_unlock_irq(&xas); > cond_resched(); > xas_lock_irq(&xas); > } > xas_unlock_irq(&xas); Assuming we can iterate the array without encl->lock, I think this would translate to: /* * Not taking encl->lock because: * 1. page attributes are not written. * 2. the only page attribute read is set before it is put to the array * and stays constant throughout the enclave life-cycle. */ xas_lock(&xas); xas_for_each_marked(&xas, page, idx_end) { if (++tagged % XA_CHECK_SCHED) continue; xas_pause(&xas); xas_unlock(&xas); /* * Attributes are not protected by the xa_lock, so I'm assuming * that this is the legit place for the check. */ if (!page || (~page->vm_max_prot_bits & vm_prot_bits)) return -EACCES; cond_resched(); xas_lock(&xas); } xas_unlock(&xas); Obviously, we cannot use this pattern by taking the encl->lock inside the loop (ABBA and encl->lock is a mutex). Let's enumerate: A. sgx_encl_add_page(): uses xa_insert() and xa_erase(). B. sgx_encl_load_page(): uses xa_load(). C. sgx_encl_may_map(): is broken (for the moment). A and B implicitly the lock and if a page exist at all we only access a pure constant. Also, since the open file keeps the instance alive, nobody is going to pull carpet under our feet. OK, I've just concluded tha we don't need to take encl->lock in this case. Great. /Jarkko