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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 30C02C5519F for ; Mon, 16 Nov 2020 10:32:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 ACE8D2227F for ; Mon, 16 Nov 2020 10:32:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1q/ZibXg"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mp/K/OX+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACE8D2227F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GwmbWYRncB/1xrwUjmqeE5Rw8CapJLsjRUqM+TXC4iQ=; b=1q/ZibXgAI8EENK+m5YuwuM6z Hp8uDBj2aRmsCEx2Jh+UvlIOBKtkWA7c5QrKjDbGu+Ci7xwQnrn7+ScITY7L0XrJfIwD6dwZ6M36S GZHgLm7qqnpdQAVbT5eSjeV450nD/2AdTb7KKBPVqGODRIf6PEGugXf4UF05MN8+bjY41MVL6tt73 WvGsooKghwlAbCGSP5ciiSp5DuUm5NpgDJYEx3Ys6sOuqS9e5y9PXZedkROYQZe+FlfwC/tacddP/ Xn5vy3k2xt2PXUoWCK2vjS9mYrwT8BsPfW+E1kFbbnV2vk4zPTUsKIz7vWckGIQGA7FdhBhXl3qLR M3ZR5UdhQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kebnD-0003Vz-Nm; Mon, 16 Nov 2020 10:31:27 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kebnB-0003Un-65 for linux-arm-kernel@lists.infradead.org; Mon, 16 Nov 2020 10:31:26 +0000 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 096ED22245 for ; Mon, 16 Nov 2020 10:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605522684; bh=E6Ae8Lp/yYCqhTh4+2hNgWEb2PqbLhsfXM+q4GzYZf0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Mp/K/OX+eJxVETfvvMDqan4sk48Fh6SExdV1anRf0DeIz1iTqqUIAAOE8cLReqf9H inVsdBEM+wnFviRoseMqC+eWQFxDcaHXd1tXXbcX4B9JUassQE9K0HFF65vnleR2kX rftg08+xkW46H9Fxbz0/8kXXE5gaaD7QIAHQULSU= Received: by mail-ot1-f49.google.com with SMTP id 79so15470474otc.7 for ; Mon, 16 Nov 2020 02:31:24 -0800 (PST) X-Gm-Message-State: AOAM533aaz09TOYShpcdHf3RBWLo2xkJZPQUtbe+W8RRqZmGvmI+xZt8 EkhIPTMRkLZC4FMtTy3j0OOR0oSTdViiQUX81ic= X-Google-Smtp-Source: ABdhPJzUAFlBcimazGPO/zCx+LnEK7h+OYUKE4PCVLHvgqCEMZmZ8QUpvvopsDJ09Kg7X4kfNq/iCmyxQVND/wezg54= X-Received: by 2002:a9d:62c1:: with SMTP id z1mr9913905otk.108.1605522683219; Mon, 16 Nov 2020 02:31:23 -0800 (PST) MIME-Version: 1.0 References: <20201028184114.6834-1-ardb@kernel.org> <20201029112747.GA4090840@google.com> <20201029115442.GA4092571@google.com> <20201116101802.GA3908597@google.com> In-Reply-To: <20201116101802.GA3908597@google.com> From: Ard Biesheuvel Date: Mon, 16 Nov 2020 11:31:10 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] arm64: implement support for static call trampolines To: Quentin Perret X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201116_053125_499070_3FBC2853 X-CRM114-Status: GOOD ( 30.91 ) 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: Mark Rutland , Peter Zijlstra , Catalin Marinas , James Morse , Will Deacon , Linux ARM 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 On Mon, 16 Nov 2020 at 11:18, Quentin Perret wrote: > > On Thursday 29 Oct 2020 at 11:54:42 (+0000), Quentin Perret wrote: > > The reason I'm interested in this is because Android makes heavy use of > > trace points/hooks, so any potential improvement in this area would be > > welcome. Now I agree we need numbers to show the benefit is real before > > this can be considered for inclusion in the kernel. I'll try and see if > > we can get something. > > Following up on this as we've just figured out what was causing > performance issues in our use-case. Basically, we have a setup where > some modules attach to trace hooks for a few things (e.g. the pelt > scheduler hooks + other Android-specific hooks), and that appeared to > cause up ~6% perf regression on the Androbench benchmark. > > The bulk of the regression came from a feature that is currently > Android-specific but should hopefully make it upstream (soon?): Control > Flow Integrity (CFI) -- see [1] for more details. In essence CFI is a > software-based cousin of BTI, which is basically about ensuring the > target of an indirect function call has a compatible prototype. This can > be relatively easily checked for potential targets that are known at > compile-time, but is a little harder when the targets are dynamically > loaded, hence causing extra overhead when the target is in a module. > > Anyway, I don't think any of the above is particularly relevant to > upstream just yet, but I figured this would interesting to share. The > short-term fix for Android was to locally disable CFI checks around the > trace hooks that cause the perf regression, but I think static-calls > would be a preferable alternative to that (I'll try to confirm that > experimentally). And when/if CFI makes it upstream, then that may become > relevant to upstream as well, though the integration of CFI and > static-calls is not very clear yet. > OK, so that would suggest that having at least the out-of-line trampoline would help with CFI, but only because the indirect call is decorated with CFI checks, not because the indirect call itself is any slower. So that suggests that something like bti c ldr x16, 0f br x16 0:.quad may well be sufficient in the arm64 case - it is hidden from the assembler, so we don't get the CFI overhead, and since it is emitted as .text (and therefore requires code patching to be updated), it does not need the same level of protection that CFI offers elsewhere when it comes to indirect calls. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel