From: Joao Moreira <joao@overdrivepizza.com> To: Peter Zijlstra <peterz@infradead.org> Cc: Kees Cook <keescook@chromium.org>, Sami Tolvanen <samitolvanen@google.com>, linux-kernel@vger.kernel.org, Josh Poimboeuf <jpoimboe@redhat.com>, x86@kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Sedat Dilek <sedat.dilek@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 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 Date: Tue, 17 May 2022 01:32:31 -0700 [thread overview] Message-ID: <141870fac344a671029e2684f84bc828@overdrivepizza.com> (raw) In-Reply-To: <YoNXPVQRvIFS81aW@hirez.programming.kicks-ass.net> >> 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. > +1 here. If you can't keep W^X, both approaches are equally doomed. Yet, there is a relevant detail here. ENDBR has a pre-defined/fixed opcode, which means that it is predictable from the binary perspective. Because of that, compilers already do security optimizations and prevent for example the emission of ENDBR's opcode as immediate operands. This very same approach can be used by JIT stuff, preventing ENDBRs to be emitted as unintended gadgets. Because KCFI hashes aren't predictable, you can't (or at least I can't think of a way to) prevent these from being emitted as operands, which means that if you have an IBT-able machine, you will want to enable it even if you have KCFI. With this said, the instrumentation for KCFI on IBT-enabled machines should be of at least 9 bytes (5 for the hash/mov and 4 for ENDBR, not counting the additional 4 bytes we asked for). >> - 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). As per the above-analysis, if we can make FineIBT instrumentation fit in 12 bytes, this means that the 9 bytes required for KCFI+IBT plus three bytes would suffice for having FineIBT (again, if we can make it fit). And this would make that call go away. > > 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). - Callee-side checks allow you to make an specific function coarse-grained without making an indirect call instruction coarse-grained. I.e: If you have a binary blob or some function that for whatever reason can't have a hash, you just disable the check in this function, making it reachable by every indirect call in the binary but being reasonably able to measure the risks behind it. If you make an indirect call coarse-grained, this means that now this indirect call can reach all functions in the binary, including functions like "disable_cet" and "disable_super_nice_security_feature". The risk impacts of these latter relaxations are much harder to measure, imho (yet, I would enjoy hearing counter-arguments, if any). > > 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 :-) We have that for IBT in clang already (I implemented and upstreamed it back when you were trying ibt-seal in objtool). I did not find the time to test it with the final IBT support but it is in my todo list to take a look and perhaps send a RFC here. FWIIW, https://reviews.llvm.org/D116070 > > I've been doing that with objtool for the IBT builds.
WARNING: multiple messages have this Message-ID (diff)
From: Joao Moreira <joao@overdrivepizza.com> To: Peter Zijlstra <peterz@infradead.org> Cc: Kees Cook <keescook@chromium.org>, Sami Tolvanen <samitolvanen@google.com>, linux-kernel@vger.kernel.org, Josh Poimboeuf <jpoimboe@redhat.com>, x86@kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Sedat Dilek <sedat.dilek@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 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 Date: Tue, 17 May 2022 01:32:31 -0700 [thread overview] Message-ID: <141870fac344a671029e2684f84bc828@overdrivepizza.com> (raw) In-Reply-To: <YoNXPVQRvIFS81aW@hirez.programming.kicks-ass.net> >> 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. > +1 here. If you can't keep W^X, both approaches are equally doomed. Yet, there is a relevant detail here. ENDBR has a pre-defined/fixed opcode, which means that it is predictable from the binary perspective. Because of that, compilers already do security optimizations and prevent for example the emission of ENDBR's opcode as immediate operands. This very same approach can be used by JIT stuff, preventing ENDBRs to be emitted as unintended gadgets. Because KCFI hashes aren't predictable, you can't (or at least I can't think of a way to) prevent these from being emitted as operands, which means that if you have an IBT-able machine, you will want to enable it even if you have KCFI. With this said, the instrumentation for KCFI on IBT-enabled machines should be of at least 9 bytes (5 for the hash/mov and 4 for ENDBR, not counting the additional 4 bytes we asked for). >> - 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). As per the above-analysis, if we can make FineIBT instrumentation fit in 12 bytes, this means that the 9 bytes required for KCFI+IBT plus three bytes would suffice for having FineIBT (again, if we can make it fit). And this would make that call go away. > > 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). - Callee-side checks allow you to make an specific function coarse-grained without making an indirect call instruction coarse-grained. I.e: If you have a binary blob or some function that for whatever reason can't have a hash, you just disable the check in this function, making it reachable by every indirect call in the binary but being reasonably able to measure the risks behind it. If you make an indirect call coarse-grained, this means that now this indirect call can reach all functions in the binary, including functions like "disable_cet" and "disable_super_nice_security_feature". The risk impacts of these latter relaxations are much harder to measure, imho (yet, I would enjoy hearing counter-arguments, if any). > > 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 :-) We have that for IBT in clang already (I implemented and upstreamed it back when you were trying ibt-seal in objtool). I did not find the time to test it with the final IBT support but it is in my todo list to take a look and perhaps send a RFC here. FWIIW, https://reviews.llvm.org/D116070 > > 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
next prev parent reply other threads:[~2022-05-17 8:44 UTC|newest] Thread overview: 174+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-13 20:21 [RFC PATCH v2 00/21] KCFI support Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-13 20:21 ` [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:42 ` Kees Cook 2022-05-14 21:42 ` Kees Cook 2022-05-16 15:44 ` Sami Tolvanen 2022-05-16 15:44 ` Sami Tolvanen 2022-05-13 20:21 ` [RFC PATCH v2 02/21] arm64/vdso: " Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:42 ` Kees Cook 2022-05-14 21:42 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 03/21] kallsyms: Ignore __kcfi_typeid_ Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:43 ` Kees Cook 2022-05-14 21:43 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:43 ` Kees Cook 2022-05-14 21:43 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 05/21] cfi: Drop __CFI_ADDRESSABLE Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:44 ` Kees Cook 2022-05-14 21:44 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:46 ` Kees Cook 2022-05-14 21:46 ` Kees Cook 2022-05-15 3:41 ` Kees Cook 2022-05-15 3:41 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 07/21] cfi: Add type helper macros Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:49 ` Kees Cook 2022-05-14 21:49 ` Kees Cook 2022-05-16 12:28 ` Rasmus Villemoes 2022-05-16 12:28 ` Rasmus Villemoes 2022-05-16 16:23 ` Sami Tolvanen 2022-05-16 16:23 ` Sami Tolvanen 2022-05-16 16:04 ` Sami Tolvanen 2022-05-16 16:04 ` Sami Tolvanen 2022-05-13 20:21 ` [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:50 ` Kees Cook 2022-05-14 21:50 ` Kees Cook 2022-05-16 15:44 ` Sami Tolvanen 2022-05-16 15:44 ` Sami Tolvanen 2022-05-17 8:47 ` Mark Rutland 2022-05-17 8:47 ` Mark Rutland 2022-05-13 20:21 ` [RFC PATCH v2 09/21] arm64: Add types to indirect called assembly functions Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:50 ` Kees Cook 2022-05-14 21:50 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 10/21] arm64: Add CFI error handling Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:51 ` Kees Cook 2022-05-14 21:51 ` Kees Cook 2022-05-16 16:24 ` Sami Tolvanen 2022-05-16 16:24 ` Sami Tolvanen 2022-05-13 20:21 ` [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:54 ` Kees Cook 2022-05-14 21:54 ` Kees Cook 2022-05-16 16:28 ` Sami Tolvanen 2022-05-16 16:28 ` Sami Tolvanen 2022-05-13 20:21 ` [RFC PATCH v2 12/21] treewide: Drop function_nocfi Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:54 ` Kees Cook 2022-05-14 21:54 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 13/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:54 ` Kees Cook 2022-05-14 21:54 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 14/21] treewide: Drop __cficanonical Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:56 ` Kees Cook 2022-05-14 21:56 ` Kees Cook 2022-05-16 16:32 ` Sami Tolvanen 2022-05-16 16:32 ` Sami Tolvanen 2022-05-13 20:21 ` [RFC PATCH v2 15/21] objtool: Don't warn about __cfi_ preambles falling through Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:56 ` Kees Cook 2022-05-14 21:56 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 16/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:57 ` Kees Cook 2022-05-14 21:57 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 17/21] x86: Add types to indirectly called assembly functions Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:58 ` Kees Cook 2022-05-14 21:58 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 18/21] x86/purgatory: Disable CFI Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:58 ` Kees Cook 2022-05-14 21:58 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 19/21] x86/vdso: " Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 21:58 ` Kees Cook 2022-05-14 21:58 ` Kees Cook 2022-05-13 20:21 ` [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 22:02 ` Kees Cook 2022-05-14 22:02 ` Kees Cook 2022-05-16 18:57 ` Sami Tolvanen 2022-05-16 18:57 ` Sami Tolvanen 2022-05-15 3:19 ` Kees Cook 2022-05-15 3:19 ` Kees Cook 2022-05-16 8:32 ` David Laight 2022-05-16 8:32 ` David Laight 2022-05-16 16:39 ` Sami Tolvanen 2022-05-16 16:39 ` Sami Tolvanen 2022-05-16 21:32 ` David Laight 2022-05-16 21:32 ` David Laight 2022-05-16 21:44 ` Peter Zijlstra 2022-05-16 21:44 ` Peter Zijlstra 2022-05-16 22:03 ` Sami Tolvanen 2022-05-16 22:03 ` Sami Tolvanen 2022-05-17 6:44 ` Peter Zijlstra 2022-05-17 6:44 ` Peter Zijlstra 2022-05-17 20:36 ` Sami Tolvanen 2022-05-17 20:36 ` Sami Tolvanen 2022-05-17 7:56 ` David Laight 2022-05-17 7:56 ` David Laight 2022-05-16 9:54 ` Peter Zijlstra 2022-05-16 9:54 ` Peter Zijlstra 2022-05-16 11:45 ` Peter Zijlstra 2022-05-16 11:45 ` Peter Zijlstra 2022-05-16 12:58 ` Peter Zijlstra 2022-05-16 12:58 ` Peter Zijlstra 2022-05-20 13:49 ` Matthew Wilcox 2022-05-20 13:49 ` Matthew Wilcox 2022-05-16 17:15 ` Sami Tolvanen 2022-05-16 17:15 ` Sami Tolvanen 2022-05-16 18:30 ` Peter Zijlstra 2022-05-16 18:30 ` Peter Zijlstra 2022-05-16 19:39 ` Sami Tolvanen 2022-05-16 19:39 ` Sami Tolvanen 2022-05-16 20:37 ` Peter Zijlstra 2022-05-16 20:37 ` Peter Zijlstra 2022-05-25 20:02 ` Kees Cook 2022-05-25 20:02 ` Kees Cook 2022-05-16 22:59 ` Kees Cook 2022-05-16 22:59 ` Kees Cook 2022-05-17 8:05 ` Peter Zijlstra 2022-05-17 8:05 ` Peter Zijlstra 2022-05-17 8:32 ` Joao Moreira [this message] 2022-05-17 8:32 ` Joao Moreira 2022-05-17 8:40 ` Peter Zijlstra 2022-05-17 8:40 ` Peter Zijlstra 2022-05-17 8:48 ` David Laight 2022-05-17 8:48 ` David Laight 2022-05-17 9:38 ` Peter Zijlstra 2022-05-17 9:38 ` Peter Zijlstra 2022-05-13 20:21 ` [RFC PATCH v2 21/21] init: Drop __nocfi from __init Sami Tolvanen 2022-05-13 20:21 ` Sami Tolvanen 2022-05-14 22:03 ` Kees Cook 2022-05-14 22:03 ` Kees Cook 2022-05-16 17:16 ` Sami Tolvanen 2022-05-16 17:16 ` Sami Tolvanen [not found] ` <CA+icZUWr+-HjMvY1VZf+nqjTadxSTDciux0Y5Y-+p_j4o7CmXg@mail.gmail.com> 2022-05-16 17:57 ` [RFC PATCH v2 00/21] KCFI support Sami Tolvanen 2022-05-16 17:57 ` Sami Tolvanen 2022-05-17 7:33 ` Sedat Dilek 2022-05-17 7:33 ` Sedat Dilek 2022-05-17 18:49 ` Nathan Chancellor 2022-05-17 18:49 ` Nathan Chancellor 2022-05-19 9:01 ` Sedat Dilek 2022-05-19 9:01 ` Sedat Dilek 2022-05-19 20:26 ` Nathan Chancellor 2022-05-19 20:26 ` Nathan Chancellor 2022-05-19 20:41 ` Sami Tolvanen 2022-05-19 20:41 ` Sami Tolvanen 2022-05-17 8:57 ` Peter Zijlstra 2022-05-17 8:57 ` Peter Zijlstra 2022-05-17 20:25 ` Sami Tolvanen 2022-05-17 20:25 ` Sami Tolvanen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=141870fac344a671029e2684f84bc828@overdrivepizza.com \ --to=joao@overdrivepizza.com \ --cc=catalin.marinas@arm.com \ --cc=jpoimboe@redhat.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=llvm@lists.linux.dev \ --cc=mark.rutland@arm.com \ --cc=nathan@kernel.org \ --cc=ndesaulniers@google.com \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=samitolvanen@google.com \ --cc=sedat.dilek@gmail.com \ --cc=will@kernel.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.