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: Tue, 3 May 2022 15:35:34 -0700 From: Peter Collingbourne <pcc@...gle.com> To: Peter Zijlstra <peterz@...radead.org> Cc: Sami Tolvanen <samitolvanen@...gle.com>, Kees Cook <keescook@...omium.org>, Mark Rutland <mark.rutland@....com>, Josh Poimboeuf <jpoimboe@...hat.com>, Will Deacon <will@...nel.org>, Catalin Marinas <catalin.marinas@....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>, LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>, linux-hardening@...r.kernel.org, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, llvm@...ts.linux.dev Subject: Re: [RFC PATCH 00/21] KCFI support On Mon, May 2, 2022 at 1:02 PM Peter Zijlstra <peterz@...radead.org> wrote: > > On Mon, May 02, 2022 at 08:22:57AM -0700, Sami Tolvanen wrote: > > > > Anyway, I think I hate that __builtin, I'd *much* rather see a variable > > > attribute or qualifier for this, such that one can mark a function > > > pointer as not doing CFI. > > > > > > I simply doesn't make sense to have a builtin that operates on an > > > expression. The whole thing is about indirect calls, IOW function > > > pointers. > > > > I also thought an attribute would be more convenient, but the compiler > > folks prefer a built-in: > > > > https://reviews.llvm.org/D122673 > > That seems to mostly worry about C++ things (overload sets, template > specialization, name mangling) we kernel folks don't seem to much care > about. > > I'll stick with saying type system makes more sense to me though. I'd say it's not only the C++ issues but more the "action at a distance" that's implied by having this be part of the type system. With this being in the function type it's hard to tell whether any particular call will have CFI disabled, without needing to go and look at how the function pointer is defined. On the other hand, if we explicitly mark up the calls with CFI disabled, the code becomes easier to audit (think Rust "unsafe" blocks). Does it seem any better to you to have this be marked up via the function expression, rather than the call? The idea is that this would always compile to a check-free function call, no matter what "func" is: __builtin_kcfi_call_unchecked(func)(args) We already have this, to some degree, with KCFI as implemented: CFI checks are disabled if the function expression refers to a declared function. The builtin would allow overriding the decision to also disable CFI checks for function expressions that use the builtin. It also wouldn't preclude a type based system later on (the builtin would become effectively a cast to the "unchecked" type). Peter
Powered by blists - more mailing lists