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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37D55C3271E for ; Mon, 8 Jul 2024 17:53:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 971EA6B0099; Mon, 8 Jul 2024 13:53:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FAB96B009A; Mon, 8 Jul 2024 13:53:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74B6F6B009B; Mon, 8 Jul 2024 13:53:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 53B9D6B0099 for ; Mon, 8 Jul 2024 13:53:31 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 07C741614A0 for ; Mon, 8 Jul 2024 17:53:31 +0000 (UTC) X-FDA: 82317332622.09.FA89241 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf18.hostedemail.com (Postfix) with ESMTP id C028C1C0016 for ; Mon, 8 Jul 2024 17:53:28 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf18.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720461187; a=rsa-sha256; cv=none; b=Njag+SQhhw9NZdTdrK7mwu+Da1liBygZOD/yubL0IAw5QdaFxLy8yc102EZKziIsRA/v9a eCAp3DlJwZfzsy5LWUynM3+VCYsD9/x64T8kNzxGUrCFQzawtp+VSrlrncs9QnIY9Srz4+ ILw++KMx4kaLiggwBK+s6fjRLMF2jIw= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf18.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720461187; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=V4XtVRb86+HP57I5vb3BJkqQ5J3RUIvx5SdQFnZdkzw=; b=Hn0e38dDN3gjvt6i2h3hHB3vhuBaj9T5wUJC2vBE9pvez2nInwj1pbLkapmQesK/8oy/7Y 3zNBIjeUlzHSQ9XFs2CKxCGn6wdY+oADC51T3q0MRS4HjhBvUjo1kpdUHC17NCLOmmp1NZ F4swWB0v7hXpsV6+/GDmHnOg+MZ3Bos= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 984B2CE0EAA; Mon, 8 Jul 2024 17:53:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AD02C116B1; Mon, 8 Jul 2024 17:53:20 +0000 (UTC) Date: Mon, 8 Jul 2024 18:53:18 +0100 From: Catalin Marinas To: Szabolcs Nagy Cc: Florian Weimer , Joey Gouly , dave.hansen@linux.intel.com, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, bp@alien8.de, broonie@kernel.org, christophe.leroy@csgroup.eu, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, tglx@linutronix.de, will@kernel.org, x86@kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 17/29] arm64: implement PKEYS support Message-ID: References: <20240503130147.1154804-1-joey.gouly@arm.com> <20240503130147.1154804-18-joey.gouly@arm.com> <20240531152138.GA1805682@e124191.cambridge.arm.com> <87a5jj4rhw.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: C028C1C0016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: hdrogwdd1audidmjwg43uqd83mcwojc8 X-HE-Tag: 1720461208-285851 X-HE-Meta: U2FsdGVkX1+S85GKEBryIjnWAj1ph3iR/Dgirxihvb1bvI6FkvJ6ILu6wrs5q/Yf1iDRbbfRRCCWXypXtAfUM1QbdE0r253nuA07N8rkQf6QVsUCPIHIH9X5wBFPnu+VBjgWzgugMDIVzo9Nthxx5nR2KwTm7QoocOv0es5xuGpPIUUMah+tOXgSQodGTd4i32fGbQYS/cgKpd1Y8RVoGSboetbxTTKZ7hcKrvWT0bN5ew+UPsCpNjQenHxG/TYOo/J8VhyBybqsbUjMYCfjYyJQtbQyXVBe95f54w7nZN+ambjrCtr62ZnvAQ/rxzbfRMk9MM5d5g7/l+7N5Q6q4KTlMNzcO+9489jgsHTM/NbatnGdGqXSM4w9QId898qTdgFlLkMCE2BzIkD0MiFnSdo5vxE7ho/FpIaYJ8xSV4PPRyqPUENZ2TVj7j77Bc+3bl1XiG//NTTxywOYFUidSPVc3/OFe60Gx2uTLkKSXxvDWInbkRmZ4izzUd3tePUlieStkoPOwFzm+LcEW9eLBYcE7ttM2q4uhrbmI8UpTQD/7NyAfpGBt46lVO197eWmWbOMxExLb2BOdFnQxO3/AtDcdk8P6BlarV7ze77SFOF8lpqTIN00+ThGDQFSbesBEpqfcT+1DTmuU0b93ZBKWMrGZI5xcQxbAozEr/1QFqMYe9ltGWpiCCVtWfSLPwBBxEJ5LlC+ecVAS9pmJmyVQRY79EUBn5cV5ZY2F6+0QvxISLiZ+PB5Avb6DZv/2E9TH5RSazPSLjj3gGfvNf5dNlDbl/r/HDg+Cyn7H5TmSPsf5SyX1P2HMTgCe2XjxfwJNPvTfRXcJAZXs/3Ncj+fNgJ0UOt0jOOqnwjVGjsHjWbCXHqqoG61DAuI9q8HfF0TbfTYEtiDCbiarAH7HTDYiuGniu2IQ1Ewoq9+6coNO7zOAJ2aUtlyntWn+SMa57gHxFD5+67636soMGEvCgQ Lx4PC7oI C6kqIiJMDNm4E3aWjh78ZijwowR3GDDdyX3nb+/8SpQSJ4CNqf8DNg2OJ6X3j2TPu2OQvXnxNIwWVsQahJt+NTcIetPGyBHKM7p7fWfhmVD6xNdQ1hq5CP0wWun9m6rFyyhESYLEcc7hm/yKeThSnlXbKB5Z4FA/A2WTBXJYRkibL9zLg6qUhsQVlEpYJTPhrYlZKfYw5UpeELLl4zMpU2RVU0yGzluL7cHgSBUShulSy03/ZEZyjh1MHp7TCgOelEERjovOpqR15mei5sRD4+7KuOTpL/XRi7XqT8ER53On9P6UzYIJOIRIep2n8HLaIpau6pfcyX3DIlUKFB3S7wbLKXswckrjpWg8u 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: List-Subscribe: List-Unsubscribe: Hi Szabolcs, On Mon, Jun 17, 2024 at 03:51:35PM +0100, Szabolcs Nagy wrote: > The 06/17/2024 15:40, Florian Weimer wrote: > > >> A user can still set it by interacting with the register directly, but I guess > > >> we want something for the glibc interface.. > > >> > > >> Dave, any thoughts here? > > > > > > adding Florian too, since i found an old thread of his that tried > > > to add separate PKEY_DISABLE_READ and PKEY_DISABLE_EXECUTE, but > > > it did not seem to end up upstream. (this makes more sense to me > > > as libc api than the weird disable access semantics) > > > > I still think it makes sense to have a full complenent of PKEY_* flags > > complementing the PROT_* flags, in a somewhat abstract fashion for > > pkey_alloc only. The internal protection mask register encoding will > > differ from architecture to architecture, but the abstract glibc > > functions pkey_set and pkey_get could use them (if we are a bit > > careful). > > to me it makes sense to have abstract > > PKEY_DISABLE_READ > PKEY_DISABLE_WRITE > PKEY_DISABLE_EXECUTE > PKEY_DISABLE_ACCESS > > where access is handled like > > if (flags&PKEY_DISABLE_ACCESS) > flags |= PKEY_DISABLE_READ|PKEY_DISABLE_WRITE; > disable_read = flags&PKEY_DISABLE_READ; > disable_write = flags&PKEY_DISABLE_WRITE; > disable_exec = flags&PKEY_DISABLE_EXECUTE; > > if there are unsupported combinations like > disable_read&&!disable_write then those are rejected > by pkey_alloc and pkey_set. > > this allows portable use of pkey apis. > (the flags could be target specific, but don't have to be) On powerpc, PKEY_DISABLE_ACCESS also disables execution. AFAICT, the kernel doesn't define a PKEY_DISABLE_READ, only PKEY_DISABLE_ACCESS so for powerpc there's no way to to set an execute-only permission via this interface. I wouldn't like to diverge from powerpc. However, does it matter much? That's only for the initial setup, the user can then change the permissions directly via the sysreg. So maybe we don't need all those combinations upfront. A PKEY_DISABLE_EXECUTE together with the full PKEY_DISABLE_ACCESS would probably suffice. Give that on x86 the PKEY_ACCESS_MASK will have to stay as PKEY_DISABLE_ACCESS|PKEY_DISABLE_WRITE, we'll probably do the same as powerpc and define an arm64 specific PKEY_DISABLE_EXECUTE with the corresponding PKEY_ACCESS_MASK including it. We can generalise the masks with some ARCH_HAS_PKEY_DISABLE_EXECUTE but it's probably more hassle than just defining the arm64 PKEY_DISABLE_EXECUTE. I assume you'd like PKEY_DISABLE_EXECUTE to be part of this series, otherwise changing PKEY_ACCESS_MASK later will cause potential ABI issues. -- Catalin