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=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 E4512C433E0 for ; Tue, 23 Jun 2020 14:47:50 +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 AA73C20720 for ; Tue, 23 Jun 2020 14:47:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="d6X8RNFU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA73C20720 Authentication-Results: mail.kernel.org; dmarc=none (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=movCtZlS7+6HEcZMz1dS+3yJrtJ0dzeVHHzcIOkrBuw=; b=d6X8RNFUMgFeRqLV1flXqzK8i LjjZSlDG5wAEsPgPRSiJSGYuyzRmKtUR5Wh8REQAjpkdTH2XDYFFepRlAofWTbtBwVrSZPDAdFUuE /O4O1k2JWK7QD57vugwNgHeRgVE4WfYs1oqXm4owwmzNyepJ7I87PgCW4cOnyBqfgZYrkI3rAIAYX Gm//mTd0Cnm2aNLSKQEVVUne7Tk5ec/jipIgOQYBET3y5t9pPyHtNrtNMFCoDl2yM3cpcOkyyqLkT cG3B9bujRE+vsPWQxFB57XN04rZEdiZAk+MMDJGiTzGBwnE/Ql5E6a27/JQYq6Cr2JQTvK1gWTWnY EQ//jyfnA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnkBW-0000Th-Dz; Tue, 23 Jun 2020 14:46:02 +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 1jnkBT-0000Si-04 for linux-arm-kernel@lists.infradead.org; Tue, 23 Jun 2020 14:46:00 +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 9158C31B; Tue, 23 Jun 2020 07:45:58 -0700 (PDT) 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 283233F6CF; Tue, 23 Jun 2020 07:45:57 -0700 (PDT) Date: Tue, 23 Jun 2020 15:45:55 +0100 From: Dave Martin To: Amit Daniel Kachhap Subject: Re: [PATCH v3 1/3] arm64: ptrauth: add pointer authentication Armv8.6 enhanced feature Message-ID: <20200623144554.GY25945@arm.com> References: <1592457029-18547-1-git-send-email-amit.kachhap@arm.com> <1592457029-18547-2-git-send-email-amit.kachhap@arm.com> <20200622142255.GS25945@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mark Rutland , Kees Cook , Suzuki K Poulose , Catalin Marinas , Kristina Martsenko , Mark Brown , James Morse , Vincenzo Frascino , Will Deacon , linux-arm-kernel@lists.infradead.org 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, Jun 23, 2020 at 06:46:28PM +0530, Amit Daniel Kachhap wrote: > Hi, > > On 6/22/20 7:52 PM, Dave Martin wrote: > >On Thu, Jun 18, 2020 at 10:40:27AM +0530, Amit Daniel Kachhap wrote: > >>This patch add changes for Pointer Authentication enhanced features > >>mandatory for Armv8.6. These features are, > >> > >>* An enhanced PAC generation logic which hardens finding the correct > >> PAC value of the authenticated pointer. However, no code change done > >> for this. > >> > >>* Fault(FPAC) is generated now when the ptrauth authentication instruction > >> fails in authenticating the PAC present in the address. This is different > >> from earlier case when such failures just adds an error code in the top > >> byte and waits for subsequent load/store to abort. The ptrauth > >> instructions which may cause this fault are autiasp, retaa etc. > >> > >>The above features are now represented by additional configurations > >>for the Address Authentication cpufeature. > >> > >>The fault received in the kernel due to FPAC is treated as Illegal > >>instruction and hence signal SIGILL is injected with ILL_ILLOPN as the > >>signal code. Note that this is different from earlier ARMv8.3 ptrauth > >>where signal SIGSEGV is issued due to Pointer authentication failures. > > > >Seems reasonable. It's a little unfortunate that the behaviour changes > >here, but I don't see what alternative we have. And getting a > >sunchronous fault is certainly better for debugging. > > > >> > >>Signed-off-by: Amit Daniel Kachhap [...] > >>diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c > >>index 3dbdf9752b11..08a4805a5cca 100644 > >>--- a/arch/arm64/kernel/entry-common.c > >>+++ b/arch/arm64/kernel/entry-common.c > >>@@ -66,6 +66,13 @@ static void notrace el1_dbg(struct pt_regs *regs, unsigned long esr) > >> } > >> NOKPROBE_SYMBOL(el1_dbg); > >>+static void notrace el1_fpac(struct pt_regs *regs, unsigned long esr) > >>+{ > >>+ local_daif_inherit(regs); > >>+ do_ptrauth_fault(regs, esr); > >>+} > >>+NOKPROBE_SYMBOL(el1_fpac); > >>+ > >> asmlinkage void notrace el1_sync_handler(struct pt_regs *regs) > >> { > >> unsigned long esr = read_sysreg(esr_el1); > >>@@ -92,6 +99,9 @@ asmlinkage void notrace el1_sync_handler(struct pt_regs *regs) > >> case ESR_ELx_EC_BRK64: > >> el1_dbg(regs, esr); > >> break; > >>+ case ESR_ELx_EC_FPAC: > >>+ el1_fpac(regs, esr); > >>+ break; > >> default: > >> el1_inv(regs, esr); > >> } > >>@@ -227,6 +237,14 @@ static void notrace el0_svc(struct pt_regs *regs) > >> } > >> NOKPROBE_SYMBOL(el0_svc); > >>+static void notrace el0_fpac(struct pt_regs *regs, unsigned long esr) > >>+{ > >>+ user_exit_irqoff(); > >>+ local_daif_restore(DAIF_PROCCTX); > >>+ do_ptrauth_fault(regs, esr); > >>+} > >>+NOKPROBE_SYMBOL(el0_fpac); > >>+ > >> asmlinkage void notrace el0_sync_handler(struct pt_regs *regs) > >> { > >> unsigned long esr = read_sysreg(esr_el1); > >>@@ -272,6 +290,9 @@ asmlinkage void notrace el0_sync_handler(struct pt_regs *regs) > >> case ESR_ELx_EC_BRK64: > >> el0_dbg(regs, esr); > >> break; > >>+ case ESR_ELx_EC_FPAC: > >>+ el0_fpac(regs, esr); > >>+ break; > >> default: > >> el0_inv(regs, esr); > >> } > >>@@ -335,6 +356,9 @@ asmlinkage void notrace el0_sync_compat_handler(struct pt_regs *regs) > >> case ESR_ELx_EC_BKPT32: > >> el0_dbg(regs, esr); > >> break; > >>+ case ESR_ELx_EC_FPAC: > >>+ el0_fpac(regs, esr); > >>+ break; > > > >Can this exception ever happen? I thought ptrauth doesn't exist for > >AArch32. > > This path will be taken during FPAC fault from userspace(EL0). Am I missing > something here? I thought AArch32 doesn't have pointer auth at all, due to a lack of spare address bits. el0_sync_compat_handler() is presumably only for exceptions coming from AArch32? > > > > >> default: > >> el0_inv(regs, esr); > >> } > >>diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > >>index 50cc30acf106..f596ef585560 100644 > >>--- a/arch/arm64/kernel/traps.c > >>+++ b/arch/arm64/kernel/traps.c > >>@@ -479,6 +479,14 @@ void do_bti(struct pt_regs *regs) > >> } > >> NOKPROBE_SYMBOL(do_bti); > >>+void do_ptrauth_fault(struct pt_regs *regs, unsigned long esr) > >>+{ > >>+ BUG_ON(!user_mode(regs)); > > > >Doesn't el1_fpac() call this? How does this interact with in-kernel > >pointer auth? > > Yes called from el1_fpac. Currently we crash the kernel when this fpac > occurs. This is similar to do_undefinstr implementation. Anyway it can be > crashed from el1_fpac also. OK, might be worth a comment saying what this is checking -- or simply replace the body of el1_fpac() with a BUG() and remove the BUG_ON() here? In its current form, this looks like this function should not be called in a kernel context, but el1_fpac() explicitly does make such a call. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel