From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH 00/17] ARMv8.3 pointer authentication support Date: Wed, 14 Nov 2018 21:47:02 +0000 Message-ID: <20181114214701.gdnrznakwtm76jlt@blommer> References: <20181005084754.20950-1-kristina.martsenko@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Kees Cook Cc: Kristina Martsenko , linux-arm-kernel , Adam Wallis , Amit Kachhap , Andrew Jones , Ard Biesheuvel , Arnd Bergmann , Catalin Marinas , Christoffer Dall , Dave P Martin , Jacob Bramley , Marc Zyngier , Ramana Radhakrishnan , "Suzuki K . Poulose" , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arch , LKML List-Id: linux-arch.vger.kernel.org On Tue, Nov 13, 2018 at 05:09:00PM -0600, Kees Cook wrote: > On Tue, Nov 13, 2018 at 10:17 AM, Kristina Martsenko > wrote: > > When the PAC authentication fails, it doesn't actually generate an > > exception, it just flips a bit in the high-order bits of the pointer, > > making the pointer invalid. Then when the pointer is dereferenced (e.g. > > as a function return address), it generates the usual type of exception > > for an invalid address. > > Ah! Okay, thanks. I missed that detail. :) > > What area of memory ends up being addressable with such bit flips? > (i.e. is the kernel making sure nothing executable ends up there?) > > > So when a function return fails in user mode, the exception is handled > > in __do_user_fault and a forced SIGSEGV is delivered to the task. When a > > function return fails in kernel mode, the exception is handled in > > __do_kernel_fault and the task is killed. > > > > This is different from stack protector as we don't panic the kernel, we > > just kill the task. It would be difficult to panic as we don't have a > > reliable way of knowing that the exception was caused by a PAC > > authentication failure (we just have an invalid pointer with a specific > > bit flipped). We also don't print out any PAC-related warning. > > There are other "guesses" in __do_kernel_fault(), I think? Could a > "PAC mismatch?" warning be included in the Oops if execution fails in > the address range that PAC failures would resolve into? I'd personally prefer that we didn't try to guess if a fault is due to a failed AUT*, even for logging. Presently, it's not possible to distinguish between a fault resulting from a failed AUT* and a fault which happens to have hte same bits/clear, so there are false positives. The architecture may also change the precise details of the faulting address, and we'd have false negatives in that case. Given that, I think suggesting that a fault is due to a failed AUT* is liable to make things more confusing. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:51512 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725756AbeKOHwC (ORCPT ); Thu, 15 Nov 2018 02:52:02 -0500 Date: Wed, 14 Nov 2018 21:47:02 +0000 From: Mark Rutland Subject: Re: [PATCH 00/17] ARMv8.3 pointer authentication support Message-ID: <20181114214701.gdnrznakwtm76jlt@blommer> References: <20181005084754.20950-1-kristina.martsenko@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: Kristina Martsenko , linux-arm-kernel , Adam Wallis , Amit Kachhap , Andrew Jones , Ard Biesheuvel , Arnd Bergmann , Catalin Marinas , Christoffer Dall , Dave P Martin , Jacob Bramley , Marc Zyngier , Ramana Radhakrishnan , "Suzuki K . Poulose" , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arch , LKML Message-ID: <20181114214702.rUBq8pkT0jxGadU4ksQY7td9OwQp-DMvelIww_GwhfY@z> On Tue, Nov 13, 2018 at 05:09:00PM -0600, Kees Cook wrote: > On Tue, Nov 13, 2018 at 10:17 AM, Kristina Martsenko > wrote: > > When the PAC authentication fails, it doesn't actually generate an > > exception, it just flips a bit in the high-order bits of the pointer, > > making the pointer invalid. Then when the pointer is dereferenced (e.g. > > as a function return address), it generates the usual type of exception > > for an invalid address. > > Ah! Okay, thanks. I missed that detail. :) > > What area of memory ends up being addressable with such bit flips? > (i.e. is the kernel making sure nothing executable ends up there?) > > > So when a function return fails in user mode, the exception is handled > > in __do_user_fault and a forced SIGSEGV is delivered to the task. When a > > function return fails in kernel mode, the exception is handled in > > __do_kernel_fault and the task is killed. > > > > This is different from stack protector as we don't panic the kernel, we > > just kill the task. It would be difficult to panic as we don't have a > > reliable way of knowing that the exception was caused by a PAC > > authentication failure (we just have an invalid pointer with a specific > > bit flipped). We also don't print out any PAC-related warning. > > There are other "guesses" in __do_kernel_fault(), I think? Could a > "PAC mismatch?" warning be included in the Oops if execution fails in > the address range that PAC failures would resolve into? I'd personally prefer that we didn't try to guess if a fault is due to a failed AUT*, even for logging. Presently, it's not possible to distinguish between a fault resulting from a failed AUT* and a fault which happens to have hte same bits/clear, so there are false positives. The architecture may also change the precise details of the faulting address, and we'd have false negatives in that case. Given that, I think suggesting that a fault is due to a failed AUT* is liable to make things more confusing. Thanks, Mark.