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 2DF25C8A for ; Mon, 14 Feb 2022 22:26:08 +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=f/paFFi8ufHomtVkkIHsbIUzgUGS321z86EhHSKUzpg=; b=cSLyqezxlVj6YcVj8ksrGIfyRy zp+gEpDoF2+qY7IQYgoCKOeDftiDWPa4W4BYKCRZvDVqkTq1aorArhMEg5qFtB5cEfoH9pEQi48HC Ji5izZf2YdQ2a410McGgfqD8PxVE4GOVlH4En6N3PGDVxT54SWC+s+kez6rpO4QOxbK0OmJrRPBZp Hk2MyWkNXqoLNagbOCTZUH3wDIU/mFUKHeKHa4geZVxyagyEgaMeJr86Ai9EAKYdsrLBWArEv8ORL Xg+lU8o3Mk1g77XKka8HnrjQj6mQCf3iVyIlHIu2aABz6CWBysY0dQSPzqMzYiUaafj58Zriu9SoY RqreVo0g==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJjn6-00DJNQ-KX; Mon, 14 Feb 2022 22:25:52 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id D00D998194C; Mon, 14 Feb 2022 23:25:50 +0100 (CET) Date: Mon, 14 Feb 2022 23:25:50 +0100 From: Peter Zijlstra To: Sami Tolvanen Cc: Joao Moreira , Kees Cook , X86 ML , hjl.tools@gmail.com, Josh Poimboeuf , andrew.cooper3@citrix.com, LKML , Nick Desaulniers , llvm@lists.linux.dev Subject: Re: [RFC][PATCH 6/6] objtool: Add IBT validation / fixups Message-ID: <20220214222550.GB23216@worktop.programming.kicks-ass.net> References: <20211122170301.764232470@infradead.org> <20211122170805.338489412@infradead.org> <6ebb0ab131c522f20c094294d49091fc@overdrivepizza.com> <202202081541.900F9E1B@keescook> <202202082003.FA77867@keescook> <9ea50c51ee8db366430c9dc697a83923@overdrivepizza.com> <20220211133803.GV23216@worktop.programming.kicks-ass.net> 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: On Mon, Feb 14, 2022 at 01:38:18PM -0800, Sami Tolvanen wrote: > On Fri, Feb 11, 2022 at 5:38 AM Peter Zijlstra wrote: > > I think we'll end up with something related to KCFI, but with distinct > > differences: > > > > - 32bit immediates for smaller code > > Sure, I don't see issues with that. Based on a quick test with > defconfig, this reduces vmlinux size by 0.30%. > > > - __kcfi_check_fail() is out for smaller code > > I'm fine with adding a trap mode that's used by default, but having > more helpful diagnostics when something fails is useful even in > production systems in my experience. This change results in a vmlinux > that's another 0.92% smaller. You can easily have the exception generate a nice warning, you can even have it continue. You really don't need a call for that. > > Which then yields: > > > > caller: > > cmpl $0xdeadbeef, -0x4(%rax) # 7 bytes > > je 1f # 2 bytes > > ud2 # 2 bytes > > 1: call __x86_indirect_thunk_rax # 5 bytes > > Note that the compiler might not emit this *exact* sequence of > instructions. For example, Clang generates this for events_sysfs_show > with the modified KCFI patch: > > 2274: cmpl $0x4d7bed9e,-0x4(%r11) > 227c: jne 22c0 > 227e: call 2283 > 227f: R_X86_64_PLT32 __x86_indirect_thunk_r11-0x4 > ... > 22c0: ud2 > > In this case the function has two indirect calls and Clang seems to > prefer to emit just one ud2. That will not allow you to recover from the exception. UD2 is not an unconditional fail. It should have an out-going edge in this case too. Heck, most of the WARN_ON() things are UD2 instructions. Also, you really should add a CS prefix to the retpoline thunk call if you insist on using r11 (or any of the higher regs). > > .align 16 > > .byte 0xef, 0xbe, 0xad, 0xde # 4 bytes > > func: > > endbr # 4 bytes > > Here func is no longer aligned to 16 bytes, in case that's important. The idea was to have the hash and the endbr in the same cacheline. > > Did I miss anything? Got anything wrong? > > How would you like to deal with the 4-byte hashes in objtool? We > either need to annotate all function symbols in the kernel, or we need > a way to distinguish the hashes from random instructions, so we can > also have functions that don't have a type hash. Easiest would be to create a special section with all the hash offsets in I suppose. A bit like -mfentry-section=name.