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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67F12C433EF for ; Fri, 4 Mar 2022 01:33:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236122AbiCDBd7 (ORCPT ); Thu, 3 Mar 2022 20:33:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232050AbiCDBd6 (ORCPT ); Thu, 3 Mar 2022 20:33:58 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45A2CC8F91; Thu, 3 Mar 2022 17:33:12 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 96931CE2847; Fri, 4 Mar 2022 01:33:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28D25C004E1; Fri, 4 Mar 2022 01:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646357588; bh=nGe3jryB3rTORQsc41kPbM4YtWTR3W7aJ8j9zSH1rLk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ohZhG/QNzyeh8WONTYPwGwZLtYBuZh0N6Sp6SZ+jcJdkFqmJDld+j0dYero1OxcyL jG423u8RElthurPOxf2bmC3GS508Z20W9fHqA4TNC+rRO6PCKeEfrmHHiWOBF9Xivv ecIkz1zCMCog9eTuNMedqTH39prW5rn0vKtN1b4HgCWNnbj0ZovVzT1XyDflVVnHxP 0laSptah2m45t9M2JfY2KMAah6r2Y+36hKPV/FwoxV14q10e4hQQG7iYuMIOlZnhI4 C1SXftIiJixp+3kdera++cUj5//9pSl4PAOuCRgytVSm+kNjsy6T2EDStvX3fGCuO3 Vsa1isYQKzlfw== Date: Fri, 4 Mar 2022 03:32:28 +0200 From: Jarkko Sakkinen To: linux-sgx@vger.kernel.org Cc: Reinette Chatre , Nathaniel McCallum , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [PATCH] x86/sgx: Do not limit EAUG'd pages by pre-initialization policy Message-ID: References: <20220304011636.327511-1-jarkko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Fri, Mar 04, 2022 at 03:25:38AM +0200, Jarkko Sakkinen wrote: > On Fri, Mar 04, 2022 at 03:16:35AM +0200, Jarkko Sakkinen wrote: > > Pre-initialization policy is meant for EADD'd pages because they are > > part of the enclave identity. It's a good practice to not let touch the > > permissions after initialization, and does provide guarantees to e.g. > > LSM's about the enclave. > > > > For EAUG'd pages it should be sufficient to let mmap(), mprotect() and > > SGX opcodes to control the permissions. Thus effectively disable > > pre-initialization policy by setting vm_max_prot_bit and > > vm_run_prot_bits to RWX. > > > > Cc: Reinette Chatre > > Cc: Nathaniel McCallum > > Signed-off-by: Jarkko Sakkinen > > --- > > arch/x86/kernel/cpu/sgx/encl.c | 8 +------- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c > > index 5fe7189eac9d..17feb6fa5578 100644 > > --- a/arch/x86/kernel/cpu/sgx/encl.c > > +++ b/arch/x86/kernel/cpu/sgx/encl.c > > @@ -200,13 +200,7 @@ static vm_fault_t sgx_encl_eaug_page(struct vm_area_struct *vma, > > encl_page->desc = addr; > > encl_page->encl = encl; > > > > - /* > > - * Adding a regular page that is architecturally allowed to only > > - * be created with RW permissions. > > - * TBD: Interface with user space policy to support max permissions > > - * of RWX. > > - */ > > - prot = PROT_READ | PROT_WRITE; > > + prot = PROT_READ | PROT_WRITE | PROT_EXEC; > > encl_page->vm_run_prot_bits = calc_vm_prot_bits(prot, 0); > > encl_page->vm_max_prot_bits = encl_page->vm_run_prot_bits; > > > > -- > > 2.35.1 > > > > This does not break any existing ABI and at least makes the current > patch set usable. Also it would be a sane limitation to deny EMODPR and EMODT completely for EADD'd pages. Then, you can discard vm_run_prot_bits. It's not needed for anything anymore. This should make implementation considerably less obfuscated. BR, Jarkko