Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp564799rwi; Tue, 18 Oct 2022 23:08:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM79t3Ww1lJIB05SPr6FKLKc/w/S8dImvWYCrXAGuVLsx+/HGz2TJifBjJRDlS/1QzY2uGwh X-Received: by 2002:a17:906:5dce:b0:78d:ec48:6a58 with SMTP id p14-20020a1709065dce00b0078dec486a58mr5408928ejv.209.1666159738601; Tue, 18 Oct 2022 23:08:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666159738; cv=none; d=google.com; s=arc-20160816; b=g0XGfUFqSE9TyTEe0XhVajynO0UBmD0RlZrMLRHgHkKB8wvfGwmmcnIRPMpH5cd22F t7XysBNTtT6z7hCii5rOxWZ8WI9R2ImKvT6yNdzvOSOb5D9LJ3UJKhWlbVhpmBqhN2iF pYHUnWnj2HEHeG1om2VC65T8SdFDbyc/fL237LLeBrWCzDPGhiaETmW64DnznLV0VI33 CgP+SXDSWkUANK2uie/lqEkN0N6ixU3SqMJWf/8foga6Dz4a/iE91camc1p65PuMoIOt 5aCfIbJxukxbdWqeMxjzcLDezyxl9y43pcdeji62K4PCqxwXkYYS/HkIsIVwymVblIEk zdBg== 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=DWFxEAB2F9CbS75gH5wpSsFQfxQPeaI8Ne8SV0JZG80=; b=FiOZLT4nZZx3kw8581SywSNtpCzWFfcaVocJZ71iHWOOTrEUatgLr2x0oHyz7GRBzH Rkwiov4mXljq5VuLXFB7odzTYaH/4TSedZX/tR6VL8gvSJlDfAE2a7VIr3mKBK8PME+z ZdDpYNeaiWwfPBn9RmqgtzvYCv3osfuZ+CyUCCeapAFNXcoOD+lDHSAMgNjnkyVML0hS vpROwa1Ua9xdIeykXwvLb9pa3e9R7AKEBsNbjGyEU61PMhiv9dFWpPgAFxH9rw5j/Gvc 8zgzQo5DOW9ImIKQmYfYkjbql40sseX8yHV2PVngL3vofjV4fIrhkQMCspnx17QOIaTU T6Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ReRhsKvZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id eb10-20020a0564020d0a00b004537a3c4982si15526822edb.601.2022.10.18.23.08.17; Tue, 18 Oct 2022 23:08:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ReRhsKvZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbiJSFTQ (ORCPT + 99 others); Wed, 19 Oct 2022 01:19:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbiJSFTO (ORCPT ); Wed, 19 Oct 2022 01:19:14 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47BA36BCC2 for ; Tue, 18 Oct 2022 22:19:13 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id z20so15863665plb.10 for ; Tue, 18 Oct 2022 22:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=DWFxEAB2F9CbS75gH5wpSsFQfxQPeaI8Ne8SV0JZG80=; b=ReRhsKvZzOsIbmwWPB1VIdcN0lbglhKGeOT1nPGZ0vfZoJjE6oYe4sIFwHZCW0lYlO C2v7J2hSI0MNSPePVJEBO1U6nTeFIMAkzM/WWDpGDTmxKfhUwCWUcXCpXP6Mp/WoSXF3 Z2U/GQ1ui1g/HL6Ly9Uf++2TsL17Wacdr8mxg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DWFxEAB2F9CbS75gH5wpSsFQfxQPeaI8Ne8SV0JZG80=; b=LrAPoEorZ40BfP18EvPndIWm7LilQ0qjRx5agx+XpOBAFA2RIiYjaL+ZNzj4SZjIFh xo9dGMg6+qVxKcASjE7ySctiyIW1j0AANbIvmi3FDSTEbZ4jHAWu8z6AUgGL8i0n8ulW 2WuVe8B7E3gFo1E2vCBwqCai0tFhYosp+GYnp7/DpMgJHkOzBIqNAeLKKmSUdxT0RR6R zHUth1s10HhoYIACk07IMyId+mU+g2C/LD5DwQTiWZ4oPMP+ZOYonI7p9VKezl24Un1L DY/935Hl6SUmeJTkuucADxZLgDi9K1aMgGsBEPCBirwUWciZH/CsUnkb3yetcv4ZMA56 9TaA== X-Gm-Message-State: ACrzQf1J3Qc8VTXpCl7yMHDETwnlmriAnTptXrCKS5454aUhfLxlIgEi XhAPYAtY6CNw+/ahVtvTBfBkww== X-Received: by 2002:a17:902:bf08:b0:178:90fb:8cda with SMTP id bi8-20020a170902bf0800b0017890fb8cdamr6605600plb.9.1666156752757; Tue, 18 Oct 2022 22:19:12 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p14-20020a170902780e00b0017d7e5a9fa7sm5426773pll.92.2022.10.18.22.19.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 22:19:11 -0700 (PDT) Date: Tue, 18 Oct 2022 22:19:11 -0700 From: Kees Cook To: Joao Moreira Cc: Peter Zijlstra , x86@kernel.org, Sami Tolvanen , linux-kernel@vger.kernel.org, Mark Rutland , Josh Poimboeuf Subject: Re: [PATCH] x86/ibt: Implement FineIBT Message-ID: <202210182218.56AD2871@keescook> References: <202210181020.79AF7F7@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 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. > > > > 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. -- Kees Cook