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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 288DAC63798 for ; Wed, 18 Nov 2020 17:19:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E29E7248B5 for ; Wed, 18 Nov 2020 17:19:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728367AbgKRRTw (ORCPT ); Wed, 18 Nov 2020 12:19:52 -0500 Received: from foss.arm.com ([217.140.110.172]:60164 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbgKRRTv (ORCPT ); Wed, 18 Nov 2020 12:19:51 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 256E31534; Wed, 18 Nov 2020 09:19:51 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 81EAC3F718; Wed, 18 Nov 2020 09:19:49 -0800 (PST) Date: Wed, 18 Nov 2020 17:19:45 +0000 From: Dave Martin To: Florian Weimer Cc: Peter Collingbourne , libc-alpha@sourceware.org, Catalin Marinas , Kevin Brodsky , linux-api@vger.kernel.org, Kostya Serebryany , Evgenii Stepanov , Andrey Konovalov , Vincenzo Frascino , Will Deacon , Linux ARM Subject: Re: [PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Message-ID: <20201118171945.GG6882@arm.com> References: <20201014055106.25164-1-pcc@google.com> <87blfv6fj3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87blfv6fj3.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Nov 17, 2020 at 06:48:16PM +0100, Florian Weimer wrote: > * Peter Collingbourne: > > > This prctl allows the user program to control which PAC keys are enabled > > in a particular task. The main reason why this is useful is to enable a > > userspace ABI that uses PAC to sign and authenticate function pointers > > and other pointers exposed outside of the function, while still allowing > > binaries conforming to the ABI to interoperate with legacy binaries that > > do not sign or authenticate pointers. > > > > The idea is that a dynamic loader or early startup code would issue > > this prctl very early after establishing that a process may load legacy > > binaries, but before executing any PAC instructions. > > I thought that the silicon did not support this? > > What exactly does this switch on and off? The signing itself (so that > the bits are zero again), or just the verification? > > I do not know how easy it will be to adjust the glibc dynamic linker > to this because I expect it to use PAC instructions itself. (It is an > interesting target, I suppose, so this makes sense to me.) The loader > code used for initial process setup and later dlopen is the same. > Worst case, we could compile the loader twice. I don't think this would matter if only the B key is turned on and off, since the compiler and libc should only be using the A key (or no key at all) when built standard compiler options. IIUC the default compiler options when using PAC will only use the A key, and only use the PAC instructions that execute as NOPs when the affected key is disabled (precisely so that the code still runs on non- PAC supporting hardware). But you can't simply flip it on and off while there are function frames on the stack that assume it's either on or off. However, the kernel interface should not assume any particular userspace environment, so the controls offered should be general. There are plenty of other prctl()s (as well as regular syscalls) that will confuse or break glibc; this is not really any different. [...] Cheers ---Dave 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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 D0A6CC5519F for ; Wed, 18 Nov 2020 17:21:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4806A248B5 for ; Wed, 18 Nov 2020 17:21:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="gw9G4oei" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4806A248B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZAbzGCcfUlknh4fk56MjByDgL8yNurk739MtCX69OqY=; b=gw9G4oeix280UpA5Rjh1K2ttr Je/umHLG2GbKkqnxo6ImM/UJwZb4xhTMD5ldNQaVMxAU++MtWSov3vYZue+1XFc6mRezUa5hXkttP 74EQf3hu/YSs0/hV9Pa9EoXhheDv7OBLVkrSS0bM630M930Ps3NuqDfIB1KyApsvSAAdFRTyfVXeT B0lGp20+1fn28Be2KT7qu6F/Cm2AMEEv3Io0w7NQOzPUcLD0qv18RcX/tg/iQVZEQU3a5wxvu1dfF u1co7rlDzaKTbAXuraayKVmWv/IF925qcEMlR/0Fm73WloiqG+KDzX4Y25XOka9GStM6aB25d/Lc1 WEDP6o7vA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfR7b-0003WC-H2; Wed, 18 Nov 2020 17:19:55 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfR7Z-0003Vl-0s for linux-arm-kernel@lists.infradead.org; Wed, 18 Nov 2020 17:19:53 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 256E31534; Wed, 18 Nov 2020 09:19:51 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 81EAC3F718; Wed, 18 Nov 2020 09:19:49 -0800 (PST) Date: Wed, 18 Nov 2020 17:19:45 +0000 From: Dave Martin To: Florian Weimer Subject: Re: [PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Message-ID: <20201118171945.GG6882@arm.com> References: <20201014055106.25164-1-pcc@google.com> <87blfv6fj3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87blfv6fj3.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201118_121953_140170_06D9BE1B X-CRM114-Status: GOOD ( 23.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libc-alpha@sourceware.org, Will Deacon , linux-api@vger.kernel.org, Kevin Brodsky , Andrey Konovalov , Kostya Serebryany , Linux ARM , Catalin Marinas , Vincenzo Frascino , Peter Collingbourne , Evgenii Stepanov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 17, 2020 at 06:48:16PM +0100, Florian Weimer wrote: > * Peter Collingbourne: > > > This prctl allows the user program to control which PAC keys are enabled > > in a particular task. The main reason why this is useful is to enable a > > userspace ABI that uses PAC to sign and authenticate function pointers > > and other pointers exposed outside of the function, while still allowing > > binaries conforming to the ABI to interoperate with legacy binaries that > > do not sign or authenticate pointers. > > > > The idea is that a dynamic loader or early startup code would issue > > this prctl very early after establishing that a process may load legacy > > binaries, but before executing any PAC instructions. > > I thought that the silicon did not support this? > > What exactly does this switch on and off? The signing itself (so that > the bits are zero again), or just the verification? > > I do not know how easy it will be to adjust the glibc dynamic linker > to this because I expect it to use PAC instructions itself. (It is an > interesting target, I suppose, so this makes sense to me.) The loader > code used for initial process setup and later dlopen is the same. > Worst case, we could compile the loader twice. I don't think this would matter if only the B key is turned on and off, since the compiler and libc should only be using the A key (or no key at all) when built standard compiler options. IIUC the default compiler options when using PAC will only use the A key, and only use the PAC instructions that execute as NOPs when the affected key is disabled (precisely so that the code still runs on non- PAC supporting hardware). But you can't simply flip it on and off while there are function frames on the stack that assume it's either on or off. However, the kernel interface should not assume any particular userspace environment, so the controls offered should be general. There are plenty of other prctl()s (as well as regular syscalls) that will confuse or break glibc; this is not really any different. [...] Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel