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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 89BF3C43441 for ; Tue, 13 Nov 2018 16:17:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5B7D122360 for ; Tue, 13 Nov 2018 16:17:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B7D122360 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-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730800AbeKNCP6 (ORCPT ); Tue, 13 Nov 2018 21:15:58 -0500 Received: from foss.arm.com ([217.140.101.70]:58944 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726517AbeKNCP6 (ORCPT ); Tue, 13 Nov 2018 21:15:58 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 943E5A78; Tue, 13 Nov 2018 08:17:12 -0800 (PST) Received: from [10.1.197.21] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CC193F5CF; Tue, 13 Nov 2018 08:17:09 -0800 (PST) Subject: Re: [PATCH 00/17] ARMv8.3 pointer authentication support To: Kees Cook Cc: linux-arm-kernel , Adam Wallis , Amit Kachhap , Andrew Jones , Ard Biesheuvel , Arnd Bergmann , Catalin Marinas , Christoffer Dall , Dave P Martin , Jacob Bramley , Marc Zyngier , Mark Rutland , Ramana Radhakrishnan , "Suzuki K . Poulose" , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arch , LKML References: <20181005084754.20950-1-kristina.martsenko@arm.com> From: Kristina Martsenko Message-ID: Date: Tue, 13 Nov 2018 16:17:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Sorry for the really late response!) On 15/10/2018 23:42, Kees Cook wrote: > On Fri, Oct 5, 2018 at 1:47 AM, Kristina Martsenko > wrote: >> This series adds support for the ARMv8.3 pointer authentication >> extension. The series contains Mark's original patches to enable pointer >> authentication for userspace [1], followed by early RFC patches using >> pointer authentication in the kernel. > > It wasn't obvious to me where the PAC mismatch exceptions will be > caught. I'm mainly curious to compare the PAC exception handling to > the existing stack-protector panic(). Can you point me to which > routines manage that? (Perhaps I just missed it in the series...) 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. 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. Thanks, Kristina