lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 16 May 2022 09:04:44 -0700 From: Sami Tolvanen <samitolvanen@...gle.com> To: Kees Cook <keescook@...omium.org> Cc: linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>, Peter Zijlstra <peterz@...radead.org>, x86@...nel.org, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>, Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Joao Moreira <joao@...rdrivepizza.com>, Sedat Dilek <sedat.dilek@...il.com>, Steven Rostedt <rostedt@...dmis.org>, linux-hardening@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, llvm@...ts.linux.dev Subject: Re: [RFC PATCH v2 07/21] cfi: Add type helper macros On Sat, May 14, 2022 at 2:49 PM Kees Cook <keescook@...omium.org> wrote: > > On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote: > > With CONFIG_CFI_CLANG, assembly functions called indirectly > > from C code must be annotated with type identifiers to pass CFI > > checking. The compiler emits a __kcfi_typeid_<function> symbol for > > each address-taken function declaration in C, which contains the > > expected type identifier. Add typed versions of SYM_FUNC_START and > > SYM_FUNC_START_ALIAS, which emit the type identifier before the > > function. > > > > Signed-off-by: Sami Tolvanen <samitolvanen@...gle.com> > > And the reason to not make this change universally (i.e. directly in > SYM_FUNC_START) is to minimize how many of these symbol annotations get > emitted? (And to more directly indicate which asm is called indirectly?) The reason not to add this to SYM_FUNC_START is that the compiler doesn't emit the type symbols for all functions. It currently emits them for all address-taken function declarations in each translation unit. We could potentially further limit this by emitting them only for function declarations with a specific attribute, for example, but that's something we can optimize later. > What happens if an asm function is called indirectly and it doesn't have > this annotation? It will fail the CFI check. > (Is this case detectable at compile-time?) It's not. I'll update the commit message in the next version to clarify these points. Sami
Powered by blists - more mailing lists