From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 4BDA57F for ; Tue, 17 May 2022 08:05:30 +0000 (UTC) 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=0DyemnKXz49NVsbKhFdeBmhodjhpRdx89qFzJBEwqrs=; b=DY+X73C+SVWiF9bZk5hf/KqiBd YVdPIEBIoFD3Kyxr3gPXX/MhpIS/ktdIWQsQpPNfnxYAvfuE6BXBFbSRFDTFEvBJIjZ1h+sJWQ7xl ICnZikro8otJtDYXoqjmqmllfcS9McHEWfA3miP7gX2UwC2F14piBsk0e1q0DQ4d4LR5Mpl83dite SjmKztEZam4zNSu3LbGMhzKU9pGxnHvg40FtPwmYQuRVhpw2VUuU8F3gdnLMY71iX8f8X71OIZWUs cCgxIFSFxorE6E1WUe/xxRSHRn/DxBwXcSmcFh/q8XCRJiRJqxaAvw5hIWdEDjfY7GajFYM3H5qVU EobYhpDA==; 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 1nqsCl-00Aelk-T8; Tue, 17 May 2022 08:05:19 +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 804C730018E; Tue, 17 May 2022 10:05:17 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 64CD22023D64A; Tue, 17 May 2022 10:05:17 +0200 (CEST) Date: Tue, 17 May 2022 10:05:17 +0200 From: Peter Zijlstra To: Kees Cook Cc: Sami Tolvanen , linux-kernel@vger.kernel.org, Josh Poimboeuf , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Message-ID: References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> <20220516183047.GM76023@worktop.programming.kicks-ass.net> <202205161531.3339CA95@keescook> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202205161531.3339CA95@keescook> On Mon, May 16, 2022 at 03:59:41PM -0700, Kees Cook wrote: > I'm still not convinced about this, but I'm on the fence. > > Cons: > - FineIBT does callee-based hash verification, which means any > attacker-constructed memory region just has to have an endbr and nops at > "shellcode - 9". KCFI would need the region to have the hash at > "shellcode - 6" and an endbr at "shellcode". However, that hash is well > known, so it's not much protection. How would you get the ENDBR there anyway? If you can write code it's game over. > - Potential performance hit due to making an additional "call" outside > the cache lines of both caller and callee. That was all an effort to shrink and simplify, all this CFI stuff is massive bloat :/ If we use %eax instead of %r10d for the hash transfer (as per Joao), and use int3 instead of ud2, then we can shrink the fineibt sequence to: __cfi_\func: endbr # 4 xorl $0x12345678, %eax # 5 jz 1f # 2 int3 # 1 \func: ... Which is 12 bytes, and needs a larger preamble (up from 9 in the current proposal). If we do the objtool/linker fixup, such that direct calls/jumps will *never* hit ENDBR, then we can do something ugly like: kCFI FineIBT __cfi_\func: __cfi_\func: int3 endbr movl $0x12345678, %rax xorl $0x12345678, %eax int3 jz 1f int3 int3 \func: endbr __direct_\func: __direct_\func: ... ... which is 12 bytes on both sides and shrinks the preaamble to 8 bytes while additionally also supporting kCFI+IBT for those few people that don't care about speculation based attacks much. But now it's complicated again and requires significant tools work :/ (also, using int3 isn't ideal). > Pros: > - FineIBT can be done without read access to the kernel text, which will > be nice in the exec-only future. - Mostly kills SpectreBHB (because it has the hash check *after* ENDBR). So were IBT limits speculation to all sites that have ENDBR, you can still target any of them. With FineIBT you loose all sites that don't match on hash value, significantly reducing the options. > I'd kind of like the "dynamic FineIBT conversion" to be a config option, > at least at first. We could at least do performance comparisons between > them. Why would you need a config option for that? Since it is dynamic anyway a boot option works fine. Also, regardless of all this, it probably makes sense to add an LTO pass to remove all unused __cfi_ symbols and endbr instructions, less viable targets is more better :-) I've been doing that with objtool for the IBT builds. 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 4E4EAC433EF for ; Tue, 17 May 2022 08:06:40 +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=bUI59EQHICO5+o74NF8bVOGyJs4g036Fnd/7GIaddOY=; b=izJLmWN1/aBuOw p04Ooig+YNI843Jsop56Dj6LnS75j6P86FU6WzyzRyl7VRnG4YCF5KtoyvwUptuonN7KutY6mL5e/ FHOSxJ83Nzy6Sszp0QGPVQzRRY5FPEFqKaIuzehBeJ4Qrwu/j21BixiHel1QNbeBtjAeG47UrvMN4 CDctBFx0m8IxkdlKIPLadWj+4fv1/00/jphkWHHXCDiYZstSpjNVcWJskltyIsJ+IbKdwl6QEn40e mrMn8DratBPCFYGri758fYOF2Zz7dHlOh9dGL2d1Vn4eeImxe3bv0KBcZrTyWjtT48b/cw3GzudQk sBHB4kuoW588Vbvqibuw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqsCu-00CKOE-Er; Tue, 17 May 2022 08:05:28 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqsCr-00CKNF-QI for linux-arm-kernel@bombadil.infradead.org; Tue, 17 May 2022 08:05:25 +0000 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=0DyemnKXz49NVsbKhFdeBmhodjhpRdx89qFzJBEwqrs=; b=DY+X73C+SVWiF9bZk5hf/KqiBd YVdPIEBIoFD3Kyxr3gPXX/MhpIS/ktdIWQsQpPNfnxYAvfuE6BXBFbSRFDTFEvBJIjZ1h+sJWQ7xl ICnZikro8otJtDYXoqjmqmllfcS9McHEWfA3miP7gX2UwC2F14piBsk0e1q0DQ4d4LR5Mpl83dite SjmKztEZam4zNSu3LbGMhzKU9pGxnHvg40FtPwmYQuRVhpw2VUuU8F3gdnLMY71iX8f8X71OIZWUs cCgxIFSFxorE6E1WUe/xxRSHRn/DxBwXcSmcFh/q8XCRJiRJqxaAvw5hIWdEDjfY7GajFYM3H5qVU EobYhpDA==; 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 1nqsCl-00Aelk-T8; Tue, 17 May 2022 08:05:19 +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 804C730018E; Tue, 17 May 2022 10:05:17 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 64CD22023D64A; Tue, 17 May 2022 10:05:17 +0200 (CEST) Date: Tue, 17 May 2022 10:05:17 +0200 From: Peter Zijlstra To: Kees Cook Cc: Sami Tolvanen , linux-kernel@vger.kernel.org, Josh Poimboeuf , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Message-ID: References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> <20220516183047.GM76023@worktop.programming.kicks-ass.net> <202205161531.3339CA95@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <202205161531.3339CA95@keescook> 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 Mon, May 16, 2022 at 03:59:41PM -0700, Kees Cook wrote: > I'm still not convinced about this, but I'm on the fence. > > Cons: > - FineIBT does callee-based hash verification, which means any > attacker-constructed memory region just has to have an endbr and nops at > "shellcode - 9". KCFI would need the region to have the hash at > "shellcode - 6" and an endbr at "shellcode". However, that hash is well > known, so it's not much protection. How would you get the ENDBR there anyway? If you can write code it's game over. > - Potential performance hit due to making an additional "call" outside > the cache lines of both caller and callee. That was all an effort to shrink and simplify, all this CFI stuff is massive bloat :/ If we use %eax instead of %r10d for the hash transfer (as per Joao), and use int3 instead of ud2, then we can shrink the fineibt sequence to: __cfi_\func: endbr # 4 xorl $0x12345678, %eax # 5 jz 1f # 2 int3 # 1 \func: ... Which is 12 bytes, and needs a larger preamble (up from 9 in the current proposal). If we do the objtool/linker fixup, such that direct calls/jumps will *never* hit ENDBR, then we can do something ugly like: kCFI FineIBT __cfi_\func: __cfi_\func: int3 endbr movl $0x12345678, %rax xorl $0x12345678, %eax int3 jz 1f int3 int3 \func: endbr __direct_\func: __direct_\func: ... ... which is 12 bytes on both sides and shrinks the preaamble to 8 bytes while additionally also supporting kCFI+IBT for those few people that don't care about speculation based attacks much. But now it's complicated again and requires significant tools work :/ (also, using int3 isn't ideal). > Pros: > - FineIBT can be done without read access to the kernel text, which will > be nice in the exec-only future. - Mostly kills SpectreBHB (because it has the hash check *after* ENDBR). So were IBT limits speculation to all sites that have ENDBR, you can still target any of them. With FineIBT you loose all sites that don't match on hash value, significantly reducing the options. > I'd kind of like the "dynamic FineIBT conversion" to be a config option, > at least at first. We could at least do performance comparisons between > them. Why would you need a config option for that? Since it is dynamic anyway a boot option works fine. Also, regardless of all this, it probably makes sense to add an LTO pass to remove all unused __cfi_ symbols and endbr instructions, less viable targets is more better :-) I've been doing that with objtool for the IBT builds. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel