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 6792BC4332F for ; Thu, 14 Apr 2022 11:20:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242600AbiDNLWm (ORCPT ); Thu, 14 Apr 2022 07:22:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242646AbiDNLWi (ORCPT ); Thu, 14 Apr 2022 07:22:38 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A10A27FE2; Thu, 14 Apr 2022 04:20:11 -0700 (PDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id E861BB82931; Thu, 14 Apr 2022 11:20:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 531A6C385A1; Thu, 14 Apr 2022 11:20:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649935208; bh=eTpWQLD9rr23+ee1ohaCLL6Wia7a8J0Io+jqTPdu7O4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=hUCoKV0oQZ1mmZcwEkGsl19vxtLiI1VrOYjPyrvJs5T2lIWNA9O+cTL5Ekay7XDWd cG/1e6LkBfCmW0KJXVvb6d4IkvXSzXozn0hEtIxz+lgq83xMZ+Y7GI753MmsjTRUP7 3ZQvXWBV089KName3Uu9UBXGLrKNUyz3JxjvLLjCrv/F+un4FRcU+Er39hW0uMK7xD WrhpiztpnndkJPKtKJxi95sS3i9NSvGNQEBcmOtVlxPbW2dwRijRbmEs3X1S/8jHTa KiP9FfmPuX9uHMQuCEcwiFbSx8ud7WpKhvCSl5u0XvApXmwKKO6CdzluUM4cMXXg2s Ugc+XgBZf1Nqw== Message-ID: <9abbecc124d61843c27217bf183d7447a281c297.camel@kernel.org> Subject: Re: [PATCH V4 15/31] x86/sgx: Support restricting of enclave page permissions From: Jarkko Sakkinen To: Reinette Chatre , dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de, luto@kernel.org, mingo@redhat.com, linux-sgx@vger.kernel.org, x86@kernel.org, shuah@kernel.org, linux-kselftest@vger.kernel.org Cc: seanjc@google.com, kai.huang@intel.com, cathy.zhang@intel.com, cedric.xing@intel.com, haitao.huang@intel.com, mark.shanahan@intel.com, vijay.dhanraj@intel.com, hpa@zytor.com, linux-kernel@vger.kernel.org Date: Thu, 14 Apr 2022 14:19:00 +0300 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2022-04-13 at 14:10 -0700, Reinette Chatre wrote: > In the initial (SGX1) version of SGX, pages in an enclave need to be > created with permissions that support all usages of the pages, from the > time the enclave is initialized until it is unloaded. For example, > pages used by a JIT compiler or when code needs to otherwise be > relocated need to always have RWX permissions. >=20 > SGX2 includes a new function ENCLS[EMODPR] that is run from the kernel > and can be used to restrict the EPCM permissions of regular enclave > pages within an initialized enclave. >=20 > Introduce ioctl() SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS to support > restricting EPCM permissions. With this ioctl() the user specifies > a page range and the EPCM permissions to be applied to all pages in > the provided range. ENCLS[EMODPR] is run to restrict the EPCM > permissions followed by the ENCLS[ETRACK] flow that will ensure > no cached linear-to-physical address mappings to the changed > pages remain. >=20 > It is possible for the permission change request to fail on any > page within the provided range, either with an error encountered > by the kernel or by the SGX hardware while running > ENCLS[EMODPR]. To support partial success the ioctl() returns an > error code based on failures encountered by the kernel as well > as two result output parameters: one for the number of pages > that were successfully changed and one for the SGX return code. >=20 > The page table entry permissions are not impacted by the EPCM > permission changes. VMAs and PTEs will continue to allow the > maximum vetted permissions determined at the time the pages > are added to the enclave. The SGX error code in a page fault > will indicate if it was an EPCM permission check that prevented > an access attempt. >=20 > No checking is done to ensure that the permissions are actually > being restricted. This is because the enclave may have relaxed > the EPCM permissions from within the enclave without the kernel > knowing. An attempt to relax permissions using this call will > be ignored by the hardware. >=20 > Signed-off-by: Reinette Chatre Reviewed-by: Jarkko Sakkinen BR, Jarkko