Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp883261pxb; Wed, 27 Oct 2021 14:25:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHCx0vYkC8DZiIiqjg9adCXUlDTBTkUHzWpvpT6OvG6hFBF2UPLfyGu7X2L0JU88lHtsJt X-Received: by 2002:a17:90a:4d44:: with SMTP id l4mr197300pjh.64.1635369915085; Wed, 27 Oct 2021 14:25:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635369915; cv=none; d=google.com; s=arc-20160816; b=YtKoqsB/U99n6eaeQzrugURPGQ8mPBVbHK7MibXD2Y/QLCnzxkx5YokonsZrx1zHAa /DfsTvQGpdZueUd7ww+8WeIkQURJI3GkRkq7WPICUH1QYDsduIszkKP0yvqsDClfzMik fIjaycC1kOhKvVXnH95IB5q2/r2y738Cwmz4qMs0YgJj4riNZnb9a6tHzwtBtXHYPpe+ PFAGBFHiKqEYoudrehFDcj2c+Ac25gts4jHnpGZWdRVcYdKjlUhSXWs71FAkzrNVZHlS mpRVFg2sES1ZcuhZGCZodKnhn1XxcOPAX+eVKx+Ufx+xoePJaIBB9r875OPnUQM6eUS1 a8CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=XYtkLsgibhEjQcSNm38eqbWpVxqYJ5WzCbpa1Acr4rs=; b=W9amOmSWnDRJoPlcevjcj1WeSG4yI1M4eS9UVEKfWs3xcc7gpwWPa05QBZWRJ5Vhsn ydar5fZyemVj8qtYcUWyDObaHF2bdmoEit2Q45yNw3y/J8iFN53pXk3S/YTBQ5txXBfN +803dA9yfPG45Ko0qTJsMQDJfXrDLl55tnoV7fc2H7t+5nOfUZcyuuF4Fm1EylxM5V4t X+ITkc8xRDBPwDvcdKiaNKnXlUwk2ooqruoMeneBZzihDo6ztMpPDZNycovOnoHJspuy E7hXJQInu15F5NIlgcNQxEWlI8U8kqevoLwChgzbSW/U2YEtALKDI4UTPFm05gL0+rqS w4ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h9si1430052pgs.569.2021.10.27.14.25.02; Wed, 27 Oct 2021 14:25:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242082AbhJ0NUE (ORCPT + 97 others); Wed, 27 Oct 2021 09:20:04 -0400 Received: from foss.arm.com ([217.140.110.172]:43176 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236464AbhJ0NUD (ORCPT ); Wed, 27 Oct 2021 09:20:03 -0400 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 7ACB2ED1; Wed, 27 Oct 2021 06:17:37 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.72.240]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 407D63F73D; Wed, 27 Oct 2021 06:17:34 -0700 (PDT) Date: Wed, 27 Oct 2021 14:17:30 +0100 From: Mark Rutland To: David Laight Cc: Peter Zijlstra , Sami Tolvanen , "x86@kernel.org" , Kees Cook , Josh Poimboeuf , Nathan Chancellor , Nick Desaulniers , Sedat Dilek , Steven Rostedt , "linux-hardening@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "llvm@lists.linux.dev" , "ardb@kernel.org" Subject: Re: [PATCH v5 00/15] x86: Add support for Clang CFI Message-ID: <20211027131730.GF54628@C02TD0UTHF1T.local> References: <20211013181658.1020262-1-samitolvanen@google.com> <20211026201622.GG174703@worktop.programming.kicks-ass.net> <20211027120515.GC54628@C02TD0UTHF1T.local> <456321a9fc5245408fc0d2798e497fe0@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456321a9fc5245408fc0d2798e497fe0@AcuMS.aculab.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 12:55:17PM +0000, David Laight wrote: > From: Mark Rutland > > Sent: 27 October 2021 13:05 > ... > > Taking a step back, it'd be nicer if we didn't have the jump-table shim > > at all, and had some SW landing pad (e.g. a NOP with some magic bytes) > > in the callees that the caller could check for. Then function pointers > > would remain callable in call cases, and we could explcitly add landing > > pads to asm to protect those. I *think* that's what the grsecurity folk > > do, but I could be mistaken. > > It doesn't need to be a 'landing pad'. > The 'magic value' could be at 'label - 8'. Sure; I'd intended to mean the general case of something at some fixed offset from the entrypoint, either before or after, potentially but not necessarily inline in the executed instruction stream. Mark.