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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 53154C433DF for ; Tue, 19 May 2020 14:55:24 +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 1412C204EF for ; Tue, 19 May 2020 14:55:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KXUXzMFm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1412C204EF 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-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=/eKPVu0kDdqI//hPlYOWc7BOHNQpcyVCTZc55yk982Q=; b=KXUXzMFm+Ou6tF 3Eo+bAA0nS1DhObqWeHFZDS+xBfRJcRCmeEXeAAVtjrS7jyZ/0WY0PDf29Rapy+IaXeQS9cIdMqX3 zTN2BmJEApW4Sg6FeGZJNH51DVbfwrw9oWoQNbHz7vch+6rE2bb73RTPTMrwPRGHKn4kpQDw/hT8/ ghkmK7E3ksnt9GxZ+5WJyJ31499kIRHvkK5mamcKa1UF1CEM3YhPYP8rfZWgaZ4NocT+WBu2/GRVY 9xtuvJ23+Mlt717Qzwdx2x1x7zKYCLl4hf1XeMJcD1JX4rFVYbQN4Nl8OblwNhvDETmudh7pMEmWt qgoMCb4ScylBSh0YiCdA==; 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 1jb3eN-00067N-NH; Tue, 19 May 2020 14:55:23 +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 1jb3eJ-00065h-CR for linux-arm-kernel@lists.infradead.org; Tue, 19 May 2020 14:55:22 +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 0413C31B; Tue, 19 May 2020 07:55:18 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1F5373F305; Tue, 19 May 2020 07:55:17 -0700 (PDT) Date: Tue, 19 May 2020 15:55:15 +0100 From: Dave Martin To: Mark Brown Subject: Re: [PATCH 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction Message-ID: <20200519145514.GH5031@arm.com> References: <20200519121818.14511-1-will@kernel.org> <20200519121818.14511-2-will@kernel.org> <20200519123843.GJ4611@sirena.org.uk> <20200519132538.GE5031@arm.com> <20200519143500.GK4611@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200519143500.GK4611@sirena.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200519_075520_742592_169B129A X-CRM114-Status: GOOD ( 12.39 ) 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: Tamas Zsoldos , Will Deacon , kernel-team@android.com, linux-arm-kernel@lists.infradead.org, Daniel Kiss 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 Tue, May 19, 2020 at 03:35:00PM +0100, Mark Brown wrote: > On Tue, May 19, 2020 at 02:25:38PM +0100, Dave Martin wrote: > > > Rather, the "ret lr" that jumps here is supposed to be authenticated via > > pointer auth in the caller. > > In which case there was an issue anyway... What issue? > > If BTI {nothing} allows this while disallowing all BR/BLR then we could > > use that (I can't remember what BTI {nothing} is useful for, if anything). > > > Otherwise, it's less clear what we should have here. > > I can't remember anything that distinguishes it from an explicit NOP. I think it rejects everything other then fallthrough execution (BTYPE==0, which includes RET). I might have misunderstood something somewhere, but sort of feels like the right thing here. I never put a lot of effort into trying to understand BTI {nothing} though. It seemed a weird, possibly useless special case. Of course, if gdb's unwinder does rely on recognising magic instruction sequences in the sigreturn trampoline even when the vdso has valid unwind information, we're probably doomed to stick for the current code forever. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel