From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03AB868 for ; Wed, 3 Nov 2021 19:32:22 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0119D60E98; Wed, 3 Nov 2021 19:32:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635967942; bh=4qyxgIZ8GahpT4Sx5VxjvY6yAitch4aqfKANRfXfzMI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=EKzUbtoGqYXQueNAw9ZofMWdyM20C6hoDsDrIihAbSiPwPBiAixcBRRgEW+61eaVs eDLg9Bnxx08k5drs1IIe6VTgd16lttUteHvP1KTcQz6AevIViqmgpqsd1VAkOhZVvh XMMPP1gjStSmb3Gn2GL9nnEIVNUMDF/qH4q9kYm+eq43WmaNB4fVS0yNtVyz2VmHud aPI1adU/N6rIUQhNP6WQUt9cZpbyX156mJDG7vlBM8qbQa0movjufKGwSLuNpz8oqk S7aoSwSj3Lf70aPD7Rd62uIqhDZuZ8ldy468agzN0Ree8DVkZy0rMxj3xsZJ9vv44x 96etEcHyZSo3w== Message-ID: Date: Wed, 3 Nov 2021 12:32:20 -0700 Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH] static_call,x86: Robustify trampoline patching Content-Language: en-US To: Peter Zijlstra Cc: Kees Cook , Ard Biesheuvel , Sami Tolvanen , Mark Rutland , the arch/x86 maintainers , Josh Poimboeuf , Nathan Chancellor , Nick Desaulniers , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, Linux Kernel Mailing List , llvm@lists.linux.dev References: <20211101090155.GW174703@worktop.programming.kicks-ass.net> <202111021040.6570189A5@keescook> <90a14299-ce56-41d5-9df9-f625aae1ac70@www.fastmail.com> <202111021603.EDE5780FE@keescook> <20211103083559.GB174703@worktop.programming.kicks-ass.net> From: Andy Lutomirski In-Reply-To: <20211103083559.GB174703@worktop.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/3/21 01:35, Peter Zijlstra wrote: > On Tue, Nov 02, 2021 at 05:20:05PM -0700, Andy Lutomirski wrote: >> I think that's a big mistake -- any sane ENDBR-using scheme would >> really prefer that ENDBR to be right next to the actual function body, >> and really any scheme would benefit due to better cache locality. > > Agreed, IBT/BTI want the landing pad in front of the actual function. > >> But, more importantly, IMO any sane ENDBR-using scheme wants to >> generate the indirect stub as part of code gen for the actual >> function. > > Sorta, I really want to be able to not have a landing pad for functions > whose address is never taken. At that point it doesn't matter if it gets > generated along with the function and then stripped/poisoned later, or > generated later. Stripping is conceptually straightforward even without LTO. foo.indirect: ENDBR foo: ... and the linker learns (using magic function sections?) that, if foo.indirect is not referenced, then it should not be generated. Or a very straightforward walk over all the relocations in an object to poison the unused .indirect entries could be done. Making this work with DSOs, EXPORT_SYMBOL, etc will be somewhat nontrivial, but not impossible. --Andy