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 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 BE6C3C28CC0 for ; Thu, 30 May 2019 18:05: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 95ABA25F06 for ; Thu, 30 May 2019 18:05: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="BGjwSLGr"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="iyaWguzN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95ABA25F06 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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: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=n+R6twVkQHk5f+Bg6mlSg6iz3UDbBMCvRvy5E8AgqCo=; b=BGjwSLGrbULCYw In+HQ1jRzdVgD6xdSUpcCqjYs0tK2ZwZssQWm5ayQVXEHqr8QfrvdCiIqJ+cmpQHyt4mRl9HxghCp 4HfW6lpI4hLPwJZGTRBo+so45g25zNqDz7QqOioK2AzDghLV6x61soI/J4hQpLJpWS1wn0sv+8uhM dLwQOUXYDcm3ezMaYiEx8ktF2CiQrkSKAmCWPYiEH3slrUMZepy2fw1mx/mhMrvAZNnfIUXz9QRKw FnOMfn8s3XFCnJoslmaWRXQ6+X85WObGJ761PPaFgPyqqF53dtk1s5MDjIPtT7A0oRhxIDztSwdjF YA3Pj0hT4w34DoACE6nA==; 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 1hWPQX-0006LU-94; Thu, 30 May 2019 18:05:21 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWPQV-0006L8-5e for linux-arm-kernel@lists.infradead.org; Thu, 30 May 2019 18:05:20 +0000 Received: by mail-pg1-x536.google.com with SMTP id h2so2476314pgg.1 for ; Thu, 30 May 2019 11:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=i2BiFNHqSJYQ1M5Sbp+c4F+mSlPAwsmPkoY/aA3nXDk=; b=iyaWguzNCqfift/Do9pSYHkHVU+pf7uadvPAWSuancxJZr4FwDDqtt1Sn2OgmcvFBy pN9edGFJxvg/9q4CiwJJHpxszxCtP+SQxUf5Epv6d2MRXkVHqEVT5OM6M6PQmGOQYEDH jXEjwu0uUNwu4xdmB0RJawkXQiwdr1iIkTFLA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=i2BiFNHqSJYQ1M5Sbp+c4F+mSlPAwsmPkoY/aA3nXDk=; b=hBQZH8qjZPtX5/71ospfSMK1Z/9SsJNJZq+jLdgzY5Boqn6NWYehhVhOkZFvZp2oMx XQyNaw2Wce3wEEEP4s5vtY5YYWX2UxLgKxqoDv0kDu+U/vodD9Uvll1zyjSTVFnIB0bv 3cp0dE2asZff2P+p8OoFilketoo06Np28uIf+IfptPuu0ezXQoPwx6ZU1uCQeCtD0eLa 86IzyLKE6w/GvBv3P5Jiak+WmvX/k7Ag9iUq4OsicQF/fBHZbvHG5QNMWH67MH/UmLRo TWqmpR6G8mT5iihPU6iXuY14HdLbwNPwvkwDwv/oewvQYFYAoky7z0/hpfH2fzQ1h1sN 3bdQ== X-Gm-Message-State: APjAAAV9nGGbzWp+Ct6OAjOqBeJNMe5kzbgZeGie3+Dr1OkL4GSRv0m3 QR5/MQNivC8N8Ach4LEG+GfxFBYAMyo= X-Google-Smtp-Source: APXvYqw2AQpyri6Q0Wv7liGOJz7ZaSWWuOf3WqwkjfTkebq8PxxiME8LDV+dYhJULar+3+XnoBH84w== X-Received: by 2002:a63:fc08:: with SMTP id j8mr4683557pgi.432.1559239517392; Thu, 30 May 2019 11:05:17 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id q17sm4597337pfq.74.2019.05.30.11.05.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 May 2019 11:05:16 -0700 (PDT) Date: Thu, 30 May 2019 11:05:15 -0700 From: Kees Cook To: Luke Cheeseman Subject: Re: [RFC v2 0/7] arm64: return address signing Message-ID: <201905301058.CA55245A0@keescook> References: <20190529190332.29753-1-kristina.martsenko@arm.com> <201905292004.3809FBAA66@keescook> <201905300851.4A68705B0@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190530_110519_238126_576C4F07 X-CRM114-Status: GOOD ( 15.17 ) 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 , Diogo Sampaio , Ard Biesheuvel , Catalin Marinas , Luke Cheeseman , Will Deacon , Kristina Martsenko , Ramana Radhakrishnan , Amit Kachhap , Kristof Beyls , Christof Douma , Suzuki Poulose , Dave P Martin , "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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 30, 2019 at 04:55:08PM +0000, Luke Cheeseman wrote: > The semantics of this attribute are straightforward enough but it > raises some questions. One question being why would I want to turn off > BTI (also controlled by this option) for one function in a file? Which > gets a bit odd. It's about leaving very early CPU startup functions in the kernel from getting marked up (since they are running before or during the PAC setup). > I don't know if the alternatives have been suggested but it's > possible to achieve the result you seem to be after (a function without > return address signing) in a couple of ways. First and foremost, > separating the function out into it's own file and compiling with > -mbranch-protection=none. Alternatively, writing the function in assembly > or perhaps even a naked function with inline assembly. Fair enough. :) Thanks for the clarification. Yeah, split on compilation unit could work. (In the future, though, having the attribute flexibility would be nice.) Kristina, would it be feasible to split these functions into a separate source file? (There doesn't seem to be a need to inline them, given they're not performance sensitive and only used once, etc?) -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel