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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0CE53C433EF for ; Sun, 6 Feb 2022 18:47:09 +0000 (UTC) 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=RhctqlmGHL96uVjPRP18afie7HvsbhV9odIbeBHwp2U=; b=qWrBGNjLPmRxFI URh1X6j49gRx2ir2MHb8Zep15tG58DvptLDjB+1GoRXlv5+8kSegeLMTT7r1b/u8OnZ6am4G0l7Yv ADTGYUF78IHDmx5Lk7LjfbUJEU+IxOrKKTiZDpE3YQrsQzOdsFu/jb6Eo68MLybNeR0Wvr4O7IxB9 FOrqxa36D84KsT5x7xlaCU382X2Z93SdxGB7BcnzIX3Wa5NFXuSqv+/8m8ZURC1eMQsG2mDwThRNW +ZUPTb6ZqvPYxweJ3EHDabrIVNlsKeGvSYJl0vhC2PNapn90+jgViNvuXNdXNJo4VfR5FOgNYvw2P DupTZrjv/3y7WslsqVrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nGmXJ-008X9D-BV; Sun, 06 Feb 2022 18:45:21 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nGmXF-008X8O-K0 for linux-arm-kernel@lists.infradead.org; Sun, 06 Feb 2022 18:45:19 +0000 Received: by mail-pf1-x42c.google.com with SMTP id u130so9808635pfc.2 for ; Sun, 06 Feb 2022 10:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=g99EK4RBFIcLjOA2xsAgfPy/FWBWvPsPH9rm8hJWuN4=; b=biHHkqKY9Ho6lpFnUvZwHS3Q5oqNdHnItOI0AX5F4NU6WRtoewrftBfJOMU6myFuVw +M3wYhBHPiacfrFCkY7wbQ5phlQLfD6QNZM/QDckqZyMqFBKPudW+ryJ+gMTIWn8VS/A cRGemeQFuDF4522ZQFDF57DgekBIK9wYHAWPI= 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=g99EK4RBFIcLjOA2xsAgfPy/FWBWvPsPH9rm8hJWuN4=; b=MpdI30mdp/T53uXneYlC3UK5T80/+2j017f/DIGCEHRYhAFupt090Jz8nCMx3Tdcss IevlbDTrec9G9pSI9FM5GNbhzdNEC5BzDmn7xYz7rmGE01UPh5+54Ebl+OVtt3pruslb Ni4E8vxDLsTnXgzJ47yjzg3GsyBUWGKcid0Z/QZYHxKHpUNXConE0tMvSiiCGiwO4t6O pyCAm8vfCM5Zete/YbeF804+GX6Bq+EWoZTHPxrHJznGsWLBGhsV/GZp6rLj05VqDtH7 h9Zj+nnW0LAc9tWKnQvaeFnj36M4PC9ZnHZBYTfPc0DnhsVw7qUVHX274RuJszwO+tDN Iuvg== X-Gm-Message-State: AOAM533/vFKtneTyFzTN3GopJvv+xE6t8t9nAUThlL6X5vGL0VdkEU+P moZDAPGpsUszzHaP9hPFyF8YDKMg3b6tFQ== X-Google-Smtp-Source: ABdhPJwsGxmyQ5I5YdyWqLxqzGVpFwSbHqBQWHaTvyZjbtd3CV9mMg9vZBIckMMYD9dBGO8G2KeEOA== X-Received: by 2002:a62:ce83:: with SMTP id y125mr12588532pfg.6.1644173116776; Sun, 06 Feb 2022 10:45:16 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id bv22sm8729991pjb.31.2022.02.06.10.45.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Feb 2022 10:45:16 -0800 (PST) Date: Sun, 6 Feb 2022 10:45:15 -0800 From: Kees Cook To: Sami Tolvanen Cc: Sean Christopherson , Peter Zijlstra , LKML , linux-arm-kernel , kvmarm , kvm@vger.kernel.org, Will McVicker Subject: Re: [PATCH v4 09/17] perf/core: Use static_call to optimize perf_guest_info_callbacks Message-ID: <202202061011.A255DE55B@keescook> References: <20211111020738.2512932-1-seanjc@google.com> <20211111020738.2512932-10-seanjc@google.com> 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-20220206_104517_700707_38754BC2 X-CRM114-Status: GOOD ( 23.16 ) 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 On Fri, Feb 04, 2022 at 09:35:49AM -0800, Sami Tolvanen wrote: > On Wed, Feb 2, 2022 at 10:43 AM Sean Christopherson wrote: > > > +DEFINE_STATIC_CALL_RET0(__perf_guest_state, *perf_guest_cbs->state); > > > +DEFINE_STATIC_CALL_RET0(__perf_guest_get_ip, *perf_guest_cbs->get_ip); > > > +DEFINE_STATIC_CALL_RET0(__perf_guest_handle_intel_pt_intr, *perf_guest_cbs->handle_intel_pt_intr); > > > > Using __static_call_return0() makes clang's CFI sad on arm64 due to the resulting > > function prototype mistmatch, which IIUC, is verified by clang's __cfi_check() > > for indirect calls, i.e. architectures without CONFIG_HAVE_STATIC_CALL. > > > > We could fudge around the issue by using stubs, massaging prototypes, etc..., but > > that means doing that for every arch-agnostic user of __static_call_return0(). > > > > Any clever ideas? Can we do something like generate a unique function for every > > DEFINE_STATIC_CALL_RET0 for CONFIG_HAVE_STATIC_CALL=n, e.g. using typeof() to > > get the prototype? > > I'm not sure there's a clever fix for this. On architectures without > HAVE_STATIC_CALL, this is an indirect call to a function with a > mismatching type, which CFI is intended to catch. > > The obvious way to solve the problem would be to use a stub function > with the correct type, which I agree, isn't going to scale. You can > alternatively check if .func points to __static_call_return0 and not > make the indirect call if it does. If neither of these options are > feasible, you can disable CFI checking in the functions that have > these static calls using the __nocfi attribute. > > Kees, any thoughts? I'm digging through the macros to sort this out, but IIUC, an example of the problem is: perf_guest_cbs->handle_intel_pt_intr is: unsigned int (*handle_intel_pt_intr)(void); The declaration for this starts with: DECLARE_STATIC_CALL(__perf_guest_handle_intel_pt_intr, *perf_guest_cbs->handle_intel_pt_intr); which produces: extern struct static_call_key STATIC_CALL_KEY(__perf_guest_handle_intel_pt_intr); extern typeof(*perf_guest_cbs->handle_intel_pt_intr) STATIC_CALL_TRAMP(__perf_guest_handle_intel_pt_intr); and the last line becomes: extern unsigned int (*__SCT____perf_guest_handle_intel_pt_intr)(void); with !HAVE_STATIC_CALL, when perf_guest_handle_intel_pt_intr() does: return static_call(__perf_guest_handle_intel_pt_intr)(); it is resolving static_call() into: ((typeof(STATIC_CALL_TRAMP(name))*)(STATIC_CALL_KEY(name).func)) so the caller is expecting "unsigned int (*)(void)" but the prototype of __static_call_return0 is "long (*)(void)": long __static_call_return0(void); Could we simply declare a type-matched ret0 trampoline too? #define STATIC_CALL_TRAMP_RET0_PREFIX __SCT__ret0__ #define STATIC_CALL_TRAMP_RET0(name) __PASTE(STATIC_CALL_TRAMP_RET0_PREFIX, name) #define DEFINE_STATIC_CALL_RET0(name, _func) \ static typeof(_func) STATIC_CALL_TRAMP_RET0(name) { return 0; } \ __DEFINE_STATIC_CALL(name, _func, STATIC_CALL_TRAMP_RET0(name)); static_call_update(__perf_guest_handle_intel_pt_intr, (void *)&STATIC_CALL_TRAMP_RET0(__perf_guest_handle_intel_pt_intr)) -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel