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 8C0E1C433F5 for ; Tue, 1 Mar 2022 13:26:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233056AbiCAN0x (ORCPT ); Tue, 1 Mar 2022 08:26:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230374AbiCAN0w (ORCPT ); Tue, 1 Mar 2022 08:26:52 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F37FF9D044; Tue, 1 Mar 2022 05:26:11 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 8ED796144F; Tue, 1 Mar 2022 13:26:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4705DC340EE; Tue, 1 Mar 2022 13:26:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646141171; bh=q9GySkEXj2qOEws7WQOcFqhKLJ1DJ8LgqDRm04SdGeU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PPYvYuyueG6EFv2fYzIoq3il0/n2kYnPiWjDUpOFBNjDQrEULzkYVHw1eyjRD2VGv rJeF0aqQPQM6AeIBatbJhFQ5vxhYSFPKqUQlEJCvYAv4lLD7TMxD32gi1RUzBLikt0 NbF4B03o3T8Il98RCGPWG+TeM4yPwRE9uvPwaJVdv8EVcaDO3GgsHrld3/0odUqSx5 seGKIta13pTceYFRVUsn4gxpO0B6dLdW6ias4B3eN2HywOMApIMIQOKAK3Ozqg2zFk EfzDGJbSgVGb1OkOUuWXPJUHik54imQfdglXde2ZN03nr6pbWYcj6z2Xpg0gTS6mXF XOl30WceJBOhQ== Date: Tue, 1 Mar 2022 14:26:48 +0100 From: Jarkko Sakkinen To: Dave Hansen Cc: "Dhanraj, Vijay" , "Chatre, Reinette" , "dave.hansen@linux.intel.com" , "tglx@linutronix.de" , "bp@alien8.de" , "Lutomirski, Andy" , "mingo@redhat.com" , "linux-sgx@vger.kernel.org" , "x86@kernel.org" , "Christopherson,, Sean" , "Huang, Kai" , "Zhang, Cathy" , "Xing, Cedric" , "Huang, Haitao" , "Shanahan, Mark" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH V2 16/32] x86/sgx: Support restricting of enclave page permissions Message-ID: References: <4ce06608b5351f65f4e6bc6fc87c88a71215a2e7.1644274683.git.reinette.chatre@intel.com> 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 Mon, Feb 28, 2022 at 07:16:22AM -0800, Dave Hansen wrote: > On 2/28/22 04:24, Jarkko Sakkinen wrote: > >> Regarding the recent update of splitting the page permissions change > >> request into two IOCTLS (RELAX and RESTRICT), can we combine them into > >> one? That is, revert to how it was done in the v1 version? > > They are logically separate complex functionalities: > > > > 1. "restrict" calls EMODPR and requires EACCEPT > > 2. "relax" increases permissions up to vetted ("EADD") and could be > > combined with EMODPE called inside enclave. > > It would be great to have a _slightly_ better justification than that. > Existing permission interfaces like chmod or mprotect() don't have this > asymmetry. > > I think you're saying that the underlying hardware implementation is > asymmetric, so the interface should be too. I don't find that argument > very convincing. If the hardware interface is arcane and we can make it > look more sane in the ioctl() layer, we should that, asymmetry or not. That is my argument, yes. > If we can't make it any more sane, let's say why the ioctl() must or > should be asymmetric. Perhaps underling this asymmetry in kdoc would be enough. > The SGX2 page permission mechanism is horribly counter intuitive. > *Everybody* that looks at it thinks that it's wrong. That means that we > have a lot of work ahead of us to explain the interfaces that get > layered on top. I fully agree on this :-) With EACCEPTCOPY (kudos to Mark S. for reminding me of this version of EACCEPT @ chat.enarx.dev) it is possible to make R and RX pages but obviously new RX pages are now out of the picture: /* * 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; encl_page->vm_run_prot_bits = calc_vm_prot_bits(prot, 0); encl_page->vm_max_prot_bits = encl_page->vm_run_prot_bits; If that TBD is left out to the final version the page augmentation has a risk of a API bottleneck, and that risk can realize then also in the page permission ioctls. I.e. now any review comment is based on not fully known territory, we have one known unknown, and some unknown unknowns from unpredictable effect to future API changes. BR, Jarkko