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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BCB4C433F5 for ; Wed, 10 Nov 2021 12:06:51 +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 05CF76115A for ; Wed, 10 Nov 2021 12:06:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 05CF76115A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=KLnz7/iraeIFnzPDdeZZQ7WWSFZ1sAqiC2wv6YSTsOU=; b=QPQcuQ1ShZe3ZK HNMVs3bU5gLNMLUjOE0oZCZE0HvNlyEi2z/TimJGKp7ydrEFIEcK0h5sn1GrPvtV07arQI4KTzbTO 28zahnLh7QEzb2RG90ZRygM8d4PaNvLxAUOZEqhNv4NSXgCAfiIoVOLZHIRU/DRaRAiSLfRPZ2K2u wdbsnv2jz3NvOzB8qbmlQXbZZuEHDgjYl1quOpHPqqlT3E/8xfGX68yRnyqDemhbRES1ydIjI74RN LupWPguHdtABcjtoVuTZiZu/vUI1s1jon6H8bF0XAf8QQZBwr1mPYNN83XOzL/JFOttIfhFPEWGzi sYkSts0r+ToOPgqVGhVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkmM4-005LLA-Ay; Wed, 10 Nov 2021 12:05:28 +0000 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkmM0-005LJi-DJ for linux-arm-kernel@lists.infradead.org; Wed, 10 Nov 2021 12:05:26 +0000 Received: by mail-wm1-x32f.google.com with SMTP id o4-20020a1c7504000000b0032cab7473caso3438137wmc.1 for ; Wed, 10 Nov 2021 04:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Gp5rF8yIUfEk3D/39XMLxjenQ09E3dvkpobT9kmUxww=; b=ZuAmRBXN2yYIdS8TNdXiMd17bwWuChKDUIB39IGbVqOmwPMTWW2J+8zM8U0imxsSWS i8cUQSDUb4YHT/+J1gIPjm9BT1TjMmnvh3QUZi7piLSZtDRkDE2lP5bievtqDB4FYL6q Fx3SGkbL1FxMKm6wqTiG2bYP0B/X++d12o83uKYNIEC8jmU+iYTbuZ22fGSIufC3khgG z2BQAlOx4a7yaDEOb8HCcwp5SUT13zdLbiyVkgGq2jRbNizN3pawUwumkSdF614u+dS1 9khpn3xwORMRYJRJ4tPt6R1l3pFDr+P4iU+Y0FJjPSLY9rNrHgFYh/Ek7PHKvqSj5k2e J17g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Gp5rF8yIUfEk3D/39XMLxjenQ09E3dvkpobT9kmUxww=; b=MpJjvGRphVwZGCb4bRtAXZunQgSYUFMmJ9lE56r/Chk98tI6iVhz+TZSBhT6dcqg/r htScvI0KzN88A1w+v63I1nAvcfd1Z2KISKaSxiEnPlha9J7ybdwGkvPKXqEV87U+Klnf Z6MLR8xZa28I8EPYyHkRxVzYbYEIPfb1iSOyDY1c8JzOMyIkMB7gt95Jp53PneoB9r3h UhM/v7n6gXXUFfKEPGCsXkY0+AyHjb+ZGQruilFc/P5qOYiYv0yHYSec5l6Vng9KX3oj AplmxZJlK3z8CJyu52yAn1yy25Gxa2pO7yHQtkFwvcL6yId9r3OP0I/lPXjcN4sDBLbc 7SKA== X-Gm-Message-State: AOAM5323MqA5MVS/rjHl3anXxd0K2RI/pYdDRG/zM1u5gwEU2LIlVtXJ 8j40VZtSbhiIQA/RkYKW4JsBbA== X-Google-Smtp-Source: ABdhPJyHB1Cmc0IyyFsJN+8na5IKBcgh2XeNV67jprvvWNgmkAoKH7FEF1/MMcCL/n5MB/rlEuiKrA== X-Received: by 2002:a1c:9814:: with SMTP id a20mr15700347wme.18.1636545922081; Wed, 10 Nov 2021 04:05:22 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:51e4:1de2:67ff:91bd]) by smtp.gmail.com with ESMTPSA id r68sm372697wmr.45.2021.11.10.04.05.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 04:05:21 -0800 (PST) Date: Wed, 10 Nov 2021 12:05:18 +0000 From: Quentin Perret To: Mark Rutland 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211110_040524_476022_BC4F3E22 X-CRM114-Status: GOOD ( 32.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mark, On Wednesday 10 Nov 2021 at 11:09:40 (+0000), Mark Rutland wrote: > 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. Right, 'vendor hooks' are an ugly Android-specific hack that I hope we will be able to get rid off overtime. And I don't think upstream should care about any of this TBH. But it's not the only use-case in Android for having modules attached to tracepoints, and the other is a bit more relevant to upstream. So I'd day it makes sense to have that discussion here. Specifically, we've got a bunch of 'empty' tracepoints *upstream* in e.g. the scheduler that don't have any trace events associated with them (see the exported TPs at the top of kernel/sched/core.c for instance). They're exported with no in-kernel user on purpose. The only reason they exist is to allow people to attach modules to them, and do whatever they need from there (collect stats, write to the trace buffer, ...). That way the kernel doesn't commit to any userspace ABI, and the maintenance burden falls on whoever maintains the module instead. But nowadays virtually every vendor/OEM in the Android world attaches to those TPs, in production, to gather stats and whatnot. And given that some of them are hooked in scheduler hot paths, we'd really like those to be low overhead. I wouldn't be surprised if other distros get the same issues at some point FWIW -- they all collect SCHED_DEBUG stats and such. > > > > 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? Nope, I think you're right. > 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. Right, no objection from me if we want to optimize the CFI slowpath instead if we can find a way to do that. A few thoughts: - attaching and detaching to TPs is a very infrequent operation, so having to do CFI checks (however cheap) before every call is a bit sad as the target doesn't change; - so far the CFI overhead has been visible in practice mainly for tracepoints and not really anywhere else. The cost of a kernel-to-module indirect calls for e.g. driver operations seems to often (though not always) be somewhat small compared to the work done by the driver itself. And I think that module-to-kernel calls should be mostly unaffected as we will either resolve them with PC-relative instructions if within range, or via the module PLT which doesn't include CFI checks IIRC. Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel