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=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,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 09552C28CC0 for ; Thu, 30 May 2019 08:40:15 +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 C606C251F9 for ; Thu, 30 May 2019 08:40:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZOJvg/h2"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="skt9pOox" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C606C251F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=E6q7RX93NMgqQejDl3ggSS+iYqlFETlDvK2fs4nGlt0=; b=ZOJvg/h2U7A8fX kNoqunUtBpW8cO4hWx4ZvGMhDJweiTxeC71ILXdiUIHM253+jK2QIRMvRxonOfeS4WpfXZNpSfwJL UKuoBxQ6JIDaXpz40FKsDlLFB2VOUyQ/LHf1OxRiQ8GPmIsDeTrezlY97wuaBI3a8EcUk7xsNujfE WT892sKl9Am6tOPWn5+Ws0pIlAdBRxN23wdd1rWkuoCWr6DA/AgJdmE/YeRR94UdJFzMFVyk2IqnK SpnCkbQUv0XIjLFj06fU7zziHsnaAxe5F2uHrQT6xu9lL35+xf3kATuVYGro+hnC2plIuQwgM/ZdG 0/Ae/EEFFF6RIEdPgHqQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWGbY-0007pv-LR; Thu, 30 May 2019 08:40:08 +0000 Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWGbV-0006fL-Ig for linux-arm-kernel@lists.infradead.org; Thu, 30 May 2019 08:40:07 +0000 Received: by mail-io1-xd43.google.com with SMTP id k20so4335786ios.10 for ; Thu, 30 May 2019 01:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0yPOg5CsdvGUDXMEkqmczrpkN4gx0yc0jrVSpMWadHY=; b=skt9pOoxVg5bz08kvzYPH+Sq20Aln9bZ/ovReyUuE/+HDsuhO0Qt2B0LD0S7s4ByOI izEBdLjHgPCp/QKLiDrvk68h9hbP9wZNN+v6mzeJYVA7l9DYmJPfCBXX0Hi3wzMekQIp OlHDcRn9yNTwYc77evcd7meq+kQh/Bw3UdOZtH8cztWPG1AoxRcNgSUKAnpIic36ek4/ zGpUWhXUC0cbJRwzstNpWiNghfWmlO0hxN3un22Spmo1i2/hrt0HVzZqZkqbkXOZO84g dn1RzqBvFyu45CSK/mWO/BtXvkxE71pjg9buDToHlmBG6DHoZZbeFH4CrbIOs4kUM8+E uEyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0yPOg5CsdvGUDXMEkqmczrpkN4gx0yc0jrVSpMWadHY=; b=cWPxqqNJLreeJO+OpURMEnYZFzHxzu784Gta3XeKqf5D+DOtENo9KT4qGLfDecqhse oOHk/I4dIOXQ0RY4yTl/7WHJ2nqPuHTFT0F2+XTWsdKxCV3GPnBFifujQfM//F7ZuN+D M1K9J78gfQIuJIkLY6TbFU0z4u/R5v55uKAGfpGTLJua4ztkKaZ2sPAlrNBma5wvWIrW mWhVG5MAW6+TEB0ftDulZAcZ2N5rv8RLLxkKsrmNmx0XeRXnbvJE/jGhNNDtJNutcNWJ HZpED04/QF0WiWcpaxX/lyfJ96OJRlMwtjb/+SsJpdxdySNjKKBBOQfvg3QQCJGexN9l o9SA== X-Gm-Message-State: APjAAAXM8L97TZLxWn18jaAiNFicPkWjDe8o2TvboatIluGUS8fdTso/ neGKRDNj7VK65hGl5IYJmzAxQ/FRAaRpHr/EfJeaoNAw X-Google-Smtp-Source: APXvYqwTcw6c0hHTlL5qLbImZc4WYUWeS5wGNpP/zFlXddWkKH7XkJNWOVlQic8DzKb68X5KYJOuurVxln769g86IOw= X-Received: by 2002:a5d:968e:: with SMTP id m14mr1766407ion.49.1559205601412; Thu, 30 May 2019 01:40:01 -0700 (PDT) MIME-Version: 1.0 References: <20190529190332.29753-1-kristina.martsenko@arm.com> <201905292004.3809FBAA66@keescook> <20190530072507.GA9955@brain-police> In-Reply-To: <20190530072507.GA9955@brain-police> From: Ard Biesheuvel Date: Thu, 30 May 2019 10:39:48 +0200 Message-ID: Subject: Re: [RFC v2 0/7] arm64: return address signing To: Will Deacon X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190530_014005_678942_BF311813 X-CRM114-Status: GOOD ( 18.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Kees Cook , "Diogo N. Sampaio" , Luke Cheeseman , Catalin Marinas , Suzuki K Poulose , Kristina Martsenko , Ramana Radhakrishnan , Amit Kachhap , Dave Martin , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 30 May 2019 at 09:25, Will Deacon wrote: > > On Wed, May 29, 2019 at 08:09:23PM -0700, Kees Cook wrote: > > On Wed, May 29, 2019 at 08:03:25PM +0100, Kristina Martsenko wrote: > > > This series improves function return address protection for the arm64 kernel, by > > > compiling the kernel with ARMv8.3 Pointer Authentication instructions. This > > > should help protect the kernel against attacks using return-oriented > > > programming. > > > > Can you speak to whether this feature should be enalbed in addition to > > or instead of the standard stack canary option? > > Hmm. That's a really interesting question. Given that PAC is optional in the > hardware and behaves as NOPs on older CPUs, I've have thought that we'd need > to continue enabling stack canaries regardless. However, that then raises > the obvious question as to whether we could patch out the canary code if we > detect PAC at runtime, which probably needs compiler help... > > Then again, perhaps there's benefit in having both features enabled. > > So I think I agree with your question :) > PAC only protects the return address, which is arguably the most vulnerable piece of data in the stack frame, but not the only one. So one question is whether we should take the hit of protecting ourselves from stack buffer overrun exploits that manage to overwrite something else in the stack frame while leaving the return address alone. I don't think doing that adds any value. Or if you are paranoid, you could argue that the stack protector also protects against a leak of the PAC key. And obviously, you need hardware from the future to use PAC :-) So while we think we should retain it for the single kernel image, I don't see why you would enable the stack protector on, e.g., android images built specifically for SOCs that enable PAC in the kernel. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel