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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22615ECAAA1 for ; Mon, 31 Oct 2022 19:14:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229945AbiJaTON (ORCPT ); Mon, 31 Oct 2022 15:14:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229744AbiJaTOK (ORCPT ); Mon, 31 Oct 2022 15:14:10 -0400 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AB50120BD for ; Mon, 31 Oct 2022 12:14:09 -0700 (PDT) Received: (Authenticated sender: joao@overdrivepizza.com) by mail.gandi.net (Postfix) with ESMTPA id 52DBF240004; Mon, 31 Oct 2022 19:13:50 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 31 Oct 2022 12:13:50 -0700 From: Joao Moreira To: Kees Cook Cc: Peter Zijlstra , x86@kernel.org, Sami Tolvanen , linux-kernel@vger.kernel.org, Mark Rutland , Josh Poimboeuf Subject: Re: [PATCH] x86/ibt: Implement FineIBT In-Reply-To: <202210182218.56AD2871@keescook> References: <202210181020.79AF7F7@keescook> <202210182218.56AD2871@keescook> Message-ID: X-Sender: joao@overdrivepizza.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-10-18 22:19, Kees Cook wrote: > On Tue, Oct 18, 2022 at 09:48:42PM -0700, Joao Moreira wrote: >> > > Is it useful to get the compiler to emit 0xcc with >> > > -fpatchable-function-entry under any circumstance? I can probably >> > > change >> > > that quickly if needed/useful. >> > >> > Having it emit 0xcc for the bytes in front of the symbol might be >> > interesting. It would mean a few kernel changes, but nothing too hard. Should I push for this within clang? I have the patch semi-ready (below) and would have some cycles this week for polishing it. >> > >> > That is, -fpatchable-function-entry=N,M gets us N-M bytes in at the >> > start of the symbol and M bytes in front of it. The N-M bytes at the >> > start of the function *are* executed and should obviously not become >> > 0xcc (GCC keeps them 0x90 while LLVM makes them large NOPs). >> >> Uhum, all makes sense. I drafted something here: >> >> https://github.com/lvwr/llvm-project/commits/joao/int3 >> >> Let me know if this works for you or if there is something that should >> be >> tweaked, like adding a specific flag and such. This currently emits >> 0xcc >> instead of 0x90 for the nops before the function entry symbol for >> kernel >> code on x86-64. It seems to be working (see generated snippet below), >> but >> let me know otherwise: >> >> Generated with -fpatchable-function-entry=10,5 >> >> Disassembly of section .text: >> >> 0000000000000000 : >> 0: cc int3 >> 1: cc int3 >> 2: cc int3 >> 3: cc int3 >> 4: cc int3 >> >> 0000000000000005 : >> 5: 0f 1f 44 00 08 nopl 0x8(%rax,%rax,1) >> a: 41 57 push %r15 >> c: 41 56 push %r14 > > Cool! I like that. Assuming objtool doesn't freak out, that seems like > a > nice way to go.