Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp373392pxh; Wed, 10 Nov 2021 03:12:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJx8/iG4wIlHDPXyWKuTOWN65mAoNQ1h/SZzrdKHOp43aNbsC5dQzDrc7DiQVfrZBNOTf31r X-Received: by 2002:a17:90b:1e0e:: with SMTP id pg14mr15662135pjb.143.1636542759154; Wed, 10 Nov 2021 03:12:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636542759; cv=none; d=google.com; s=arc-20160816; b=HqXZ3G+/qp0V3p2offmhf41V32BTJZKo4oqpE2jc7W/mDYshQUt+h0a/xgieR9BQOp imB4m86ezFmogYwLmgWS1NAQskTazA8cUwIuBTcPiwXobLkygjGV3Go7JggsVMyXJw75 BQLLxh6jRLcec9W7aeVuw/kNxPOt16na7S5/UQCSyRnpn2s52ac90jjN5mDN2RhiQ7SE 8uFoxss8HoYFSIvcJnJYxgR7RHD5Wx2raHxlk5jrYQ7+DX/xiigGVuTNIfWXPTrsWpTY 1inCqBV0mpnL2GdgHoiw5+EzBVSXu6AI8lbghz0pwrSWiuuyclQmlk2J3uPMwUUO/Yx8 /Cmg== 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=xFNvy4OqPrjA4un75iHr5hRhPkTQPs2Wyc3x8szvmIc=; b=mFp6rcPozepENkMGKvZg58YsLzc8Pbr8PbSp0ZwpVJnH+1+d9AEEGN0/IDl8UUQ62s 2BbOkM8quY/2/xn6/OCXBXaKNtl2k+4UL5R2ENiC7buQ692zyURdZ0+YZ7RtVRe4DrHY PLAT/0ott4GQ9yhwUhMMBTnV/Zoyhu1/BfalA6+7juwA2hrLC/MKgLOKEdenOhb2xu8/ OnzS9iVjpDBMtfaxWoy8AuakGE+uy3H5xGCwmvPlYlnYQf7P1gRqLRDZoPCCwu7He151 eKYKLvHCbvJf/k7S9NU3DPX+Y9886S2nXrvawv+t3Ge9mPoKz6sW2EBhqRlbRzrCa2fg uRxQ== 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 n3si39642787pgv.117.2021.11.10.03.12.26; Wed, 10 Nov 2021 03:12:39 -0800 (PST) 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 S231263AbhKJLMk (ORCPT + 99 others); Wed, 10 Nov 2021 06:12:40 -0500 Received: from foss.arm.com ([217.140.110.172]:45032 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231158AbhKJLMj (ORCPT ); Wed, 10 Nov 2021 06:12:39 -0500 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 55F0D101E; Wed, 10 Nov 2021 03:09:52 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.59.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 256323F718; Wed, 10 Nov 2021 03:09:50 -0800 (PST) Date: Wed, 10 Nov 2021 11:09:40 +0000 From: Mark Rutland To: Quentin Perret Cc: Ard Biesheuvel , Linux ARM , Linux Kernel Mailing List , Catalin Marinas , James Morse , Will Deacon , Frederic Weisbecker , Peter Zijlstra , Kees Cook , Sami Tolvanen , Andy Lutomirski , Josh Poimboeuf , Steven Rostedt Subject: Re: [PATCH v6 2/2] arm64: implement support for static call trampolines Message-ID: References: <20211105145917.2828911-1-ardb@kernel.org> <20211105145917.2828911-3-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Nov 09, 2021 at 07:02:21PM +0000, Quentin Perret wrote: > On Tuesday 09 Nov 2021 at 19:09:21 (+0100), Ard Biesheuvel wrote: > > Android relies heavily on tracepoints for vendor hooks, and given the > > performance impact of CFI on indirect calls, there has been interest > > in enabling static calls to replace them. Hhmm.... what exactly is a "vendor hook" in this context, and what is it doing with a tracepoint? From an upstream perspective that sounds somewhat fishy usage. > > Quentin, anything to add here? > > Yes, Android should definitely benefit from static calls. > > Modules attaching to tracepoints cause a measurable overhead w/ CFI as > the jump target is a bit harder to verify if it is not in-kernel. Where does that additional overhead come from when the target is not in-kernel? I hope that I am wrong in understanding that __cfi_slowpath_diag() means we're always doing an out-of-line check when calling into a module? If that were the case, that would seem to be a much more general problem with the current clang CFI scheme, and my fear here is that we're adding fragility and complexity in specific plces to work around general problems with the CFI scheme. Thanks, Mark. > But sadly that's a common pattern for GKI. The current 'workaround' in > Android has been to just plain disable CFI around all tracepoints in the > kernel, which is a bit sad from a security PoV. But there was really no other > option at the time, and we needed the performance back. Static calls would be > a far superior solution as they would avoid much of the CFI overhead, and are > not vulnerable in the CFI sense (that is, the branch target can't be easily > overridden with a random OOB write from a dodgy driver). So yes, we'd really > like to have those please :) > > Thanks, > Quentin