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 2C9A4C43217 for ; Tue, 17 May 2022 08:42:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243589AbiEQImA (ORCPT ); Tue, 17 May 2022 04:42:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243625AbiEQIk5 (ORCPT ); Tue, 17 May 2022 04:40:57 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DDA9637B; Tue, 17 May 2022 01:40: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=z19aIPjW70USLBbDz8uwfQbhmVmgCMWnBLLEt2fwQnk=; b=voDMYDaCISF39VMEpWSPipKHw4 RJaugttebgQvZtxGRduIu8CzrYyHjtMiZtXJZeJXSLVHC+ZDD/t2wf6LKvmk2MPzv3SWZMwo3lGde eJd09dZ+ZdyK/cw81ZmHLGuNqJwJfOXTnDKKfpYGS3zC+tOit5o9pavUKyDuW+fAIBOg8j7CY59di XevmJRydszXBTDMJIwM5TIGA4qto7CiVmv+9xJu2gepwBfx3tazxUiO0Vjmfvt2fe9aL5GTEBjIkR zO3FmVe5j26LXpdAVEeCabxU98ftjnaU+WW5Hcm0YqEK7gHtczNWKF11XiwBDv2q0AQf0vpxmUyGB Nkg6s9zA==; 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 1nqsl0-00AgeZ-K5; Tue, 17 May 2022 08:40:42 +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)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 7EA48300642; Tue, 17 May 2022 10:40:40 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 402F22023D0E2; Tue, 17 May 2022 10:40:40 +0200 (CEST) Date: Tue, 17 May 2022 10:40:40 +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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org On Tue, May 17, 2022 at 10:05:17AM +0200, Peter Zijlstra wrote: > 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). On all that; perhaps it would be good to have a compiler option to specify the preamble size. It can enforce the minimum at 7 to have at least the required: movl $0x12345678, %eax int3 int3 but any larger number will just increase the preamble with int3 padding at the top. That can go right along with the option to supress endbr when preamble :-)