Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1029105pxb; Fri, 15 Apr 2022 18:54:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy7pWGIE7OC5LE0l77IV6mgeH0oOBfrXl1v16JSyJ0odG2Zl9XEW2Hr7ek3eWl3cMXnjbGw X-Received: by 2002:a17:90a:410a:b0:1cb:a279:6679 with SMTP id u10-20020a17090a410a00b001cba2796679mr7083590pjf.211.1650074051489; Fri, 15 Apr 2022 18:54:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650074051; cv=none; d=google.com; s=arc-20160816; b=v3nmhXtN0D8NK1SEOIOlPtIBkGeTBWwIVn0eT08XlzZbBI41cnFL/AQKgo1p6eKu9M w+S/aTf+AlDwX1ElpBoKS+vJijh7MnGO+YAqs2jsCGjKz04EXF8of7h7vwwHc8hsp8Vn p9MNec1/eAnrPvINQPVHAzlYP2ZZ0NWe/AkrIJT1OLqw/4VhsO7SD4mrvfcN8L69j3NL rLVbTz82iV0hCDIfBFNFkwTKUVZ564rjiD/1DqiCgtu7i0BBNMwUa8U8VflImcpBr2In Fs0QvDNwGLsDRpxc4cVp+HL4vGeRT+KeUJDSjGLTUfuDYGnbRq7Wqzou00fhYwdQcm6+ sAmQ== 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:dkim-signature; bh=htAtH74QLNG2Pf9ve+yTGgjemLxhIEb+MZlCbbE3qLs=; b=lwlmQgotZH2saOVSMVFmqQiJ2OXDkQ3N4nfEjps3kszEyY4Tv9Vo/771v9Flf7zyD6 aYytLb1bKfVTMUgqOHd+yUaGxNciqLNutu3FxEChOUuIHKk2VVFEdqTl1L0bq/zaSp0p 3P7+mD6/xCHiiYXsALvDDVs2EWB+YFzPOiQy+9+nuqY4iFRD3iMm8Oy7+VM3RjFoMMzY yhBuvnVdg3poVKY4LRB5K3cXyhLrUiSPkdHiGk6dv3KUt6KAcv28i3ysQ2Yv1Ky4SAi1 XessBOKLMeLGgqTL3yFgx0utCXJyADCCroJVfAzjM5Kc8/tFIgrcQ4weC7j8D5fP0mQu uJgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=osof88Xv; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p20-20020a17090a931400b001cd57ed2fa8si2800453pjo.39.2022.04.15.18.54.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:54:11 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=osof88Xv; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2542B198950; Fri, 15 Apr 2022 18:15:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343523AbiDNSw0 (ORCPT + 99 others); Thu, 14 Apr 2022 14:52:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229781AbiDNSwY (ORCPT ); Thu, 14 Apr 2022 14:52:24 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CC06B0D32 for ; Thu, 14 Apr 2022 11:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=htAtH74QLNG2Pf9ve+yTGgjemLxhIEb+MZlCbbE3qLs=; b=osof88Xv953F6ijLPdEtg5vkLD U6ChiSv17EqlP/tWlUhobobjxbmOWc4y11sFg0oeXs8BXDC+Or7zO8eqwHUsPTZKbDCBkZ7SfL4Ju iHHpaHaGgP+1vPGEqtampmXsLlIAXrDpzGuvGx0cvLANl84W7Sc1jLqCfsruxk05V5u78lt+6+oe/ FcBlslM5sTTpqiLe15hdQAcPT9DRLliV2BP5SdNURwqvXoGoRUtAT3zT0FvBgn9ijr/Tea+QkQ3ps fjvxqHCSW0n1HG83HZdQv7PMT+MYLX6cWRIsnwBcWtmBclNeuGK7yYdnpI5PH3Yjq4O5nPKtGHVMa S9wu3/Lw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nf4XO-00FQ7y-RI; Thu, 14 Apr 2022 18:49:50 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id B203E30027B; Thu, 14 Apr 2022 20:49:48 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 931A432328638; Thu, 14 Apr 2022 20:49:48 +0200 (CEST) Date: Thu, 14 Apr 2022 20:49:48 +0200 From: Peter Zijlstra To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Miroslav Benes Subject: Re: [PATCH 10/18] objtool: Extricate ibt from stack validation Message-ID: References: <44a73f724b51c4a994edc43536b7a7ee5e972b40.1649891421.git.jpoimboe@redhat.com> <20220414154449.5moa7xsczwybbqhd@treble> <20220414170550.v2jmdfhmz7zbuug6@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220414170550.v2jmdfhmz7zbuug6@treble> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2022 at 10:05:50AM -0700, Josh Poimboeuf wrote: > On Thu, Apr 14, 2022 at 06:38:16PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 14, 2022 at 08:44:49AM -0700, Josh Poimboeuf wrote: > > > > > Ok. That was subtle, it needs a comment or two. I had the distinct > > > feeling I was introducing a bug, then I got distracted ;-) > > > > Right, lemme try and not forget to write one ;-) > > I'm rewriting the code anyway, I'll add some comments. > > > > Doesn't the compiler give those special cases ENDBR anyway? Just > > > wondering why we avoid the warning for those. > > > > Sure, but this is about not scribbling that ENDBR with a NOP. > > Right, but it only prints warnings for data sections, despite marking > others: > > - dest = validate_ibt_reloc(file, reloc); > - if (is_data && dest && !dest->noendbr) > - warn_noendbr("data ", sec, reloc->offset, dest); > Right, so validate_ibt_reloc() does two things: - it removes the instruction from the seal list (if it was still on it) - it returns the dest instruction if it isn't ENDBR (or a static call trampoline, which we know will never be indirectly called). So that first thing is always important; we should not seal too many things (.initcall and .ksymtab would be bad etc..), that second thing is only useful if there is potential control flow. That is, .ksymtab is not used for control flow (directly), it's the symbol table for the module linker. OTOH .initcall does have control flow, but it is 100% control flow. In neither case does it really make sense to warn (then again, they also should not trigger warns I suppose). .data/.rodata otoh is more questionable, typically a code reference there is a function pointer and we really want an ENDBR there, but it's not always the case, hence the warns from there. Now, I have some vague memories of getting a lot of noise from some other sections, but I can't really remember now :-/