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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, 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 7DC51C38A2A for ; Thu, 7 May 2020 15:29:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 44F93207DD for ; Thu, 7 May 2020 15:29:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="vA8vAmiw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44F93207DD 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+infradead-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=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:References: To:Subject:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LfHI2ccmiGVqRx9s66/Nso8wGdaSI8i2edTdDsiTM5Y=; b=vA8vAmiwj3bsQaXVmdUm7hSBe Xg7aJ2WFVi63r8P8wEjMCs2xlqLCuV73E9mDQXmRsaPy6vXNmPRDE5ZUKnPiAOX8OEwdK1ctV94/+ nvQHm5zbLns9YNmcxkJjjf70GT4uB3hjZcDJboB5pF/NOK0fRstQFQ+aFDi9nxldGnZAc4k5hgaTS ajZoFfqU/BTvk18f4UrHEK7BwH4lpgob+ZwyUhGfN0OZM3Bk/gp+yUGoDusu9g5L4cexW7k5R4FbU n24eEOMcpLrZ1G6T8YbZa6MX/yUVFEqNEfEDD5ES2/WVW2gGy+l5CCnCt0dbxU5rmObOT72+qTisN NsUpdTBww==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jWiSg-0005TU-1j; Thu, 07 May 2020 15:29:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jWiSc-0005Sm-Az for linux-arm-kernel@lists.infradead.org; Thu, 07 May 2020 15:29:19 +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 A8BDB1FB; Thu, 7 May 2020 08:29:17 -0700 (PDT) Received: from [10.57.23.221] (unknown [10.57.23.221]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F4443F68F; Thu, 7 May 2020 08:29:14 -0700 (PDT) From: Amit Kachhap Subject: Re: [PATCH v2 2/4] arm64: ptrauth: add pointer authentication Armv8.6 enhanced feature To: Catalin Marinas References: <1586842314-19527-1-git-send-email-amit.kachhap@arm.com> <1586842314-19527-3-git-send-email-amit.kachhap@arm.com> <20200506163155.GG2878@gaia> Message-ID: Date: Thu, 7 May 2020 20:58:51 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20200506163155.GG2878@gaia> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200507_082918_464955_6E153C94 X-CRM114-Status: GOOD ( 27.53 ) 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 , Kristina Martsenko , Mark Brown , James Morse , Vincenzo Frascino , Will Deacon , Dave Martin , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 5/6/20 10:01 PM, Catalin Marinas wrote: > On Tue, Apr 14, 2020 at 11:01:52AM +0530, Amit Daniel Kachhap wrote: >> This patch add changes for Pointer Authentication enhanced features >> mandatory for Armv8.6. These features are, >> >> * Uses 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. > > Sorry if it was discussed before. Was there any reasoning behind > choosing ILL_ILLOPN vs something else like ILL_ILLADR? No it was not discussed earlier. I used it as I thought that autiasp failed here due to incorrect operands provided (sp, key, lr). Although sp and lr are addresses. > >> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c >> index cf402be5c573..0ef9e9880194 100644 >> --- a/arch/arm64/kernel/traps.c >> +++ b/arch/arm64/kernel/traps.c >> @@ -411,6 +411,23 @@ void do_undefinstr(struct pt_regs *regs) >> } >> NOKPROBE_SYMBOL(do_undefinstr); >> >> +void do_ptrauth_fault(struct pt_regs *regs, unsigned long esr) >> +{ >> + const char *desc; >> + >> + BUG_ON(!user_mode(regs)); >> + >> + /* Even if we chose not to use PTRAUTH, the hardware might still trap */ >> + if (unlikely(!(system_supports_address_auth()))) { > > Nitpick: no need for braces around system_supports_address_auth(). ok > >> + force_signal_inject(SIGILL, ILL_ILLOPC, regs->pc); >> + return; >> + } > > So when do we execute this path? Is it on a big.LITTLE system where some > CPUs don't have the 8.6 behaviour? It's the same AUT instruction that > triggered it, so I don't think we should report a different ILL code. > > It's a bit unfortunate that this new ptrauth feature doesn't have an > opt-in, so user-space would have to cope with both behaviours. In this > case I don't see why we need to differentiate on > system_supports_address_auth(). I was referring to some similar checks present in do_sve_acc in file arch/arm64/kernel/fpsimd.c to gaurd some unknown situations. Anyway I should probably drop this as EC value is already matched. > > While the new behaviour is a lot more useful in practice, I wonder > whether we could still emulate the old one by setting regs->pc to a > faulting address and returning to user. However even if we set regs->pc to the faulting lr address but this lr may not be same as earlier one as theoretically there can be two autia instructions so I am not sure if complete emulation is possible. Also other work will be change ESR value, set error pattern in the faulting address etc when the error pattern is itself not defined. > >> + >> + desc = "pointer authentication fault"; >> + arm64_notify_die(desc, regs, SIGILL, ILL_ILLOPN, (void __user *)regs->pc, esr); > > Nitpick: you could pass the string directly, no need for an additional > variable. ok Amit > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel