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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <87wnme3pbv.ffs@tglx> Date: Sat, 16 Oct 2021 00:17:40 +0200 From: Thomas Gleixner <tglx@...utronix.de> To: Sami Tolvanen <samitolvanen@...gle.com> Cc: Andy Lutomirski <luto@...nel.org>, the arch/x86 maintainers <x86@...nel.org>, Kees Cook <keescook@...omium.org>, Josh Poimboeuf <jpoimboe@...hat.com>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Sedat Dilek <sedat.dilek@...il.com>, Steven Rostedt <rostedt@...dmis.org>, linux-hardening@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, llvm@...ts.linux.dev Subject: Re: [PATCH v5 03/15] linkage: Add DECLARE_NOT_CALLED_FROM_C On Fri, Oct 15 2021 at 11:42, Sami Tolvanen wrote: > On Fri, Oct 15, 2021 at 10:57 AM Thomas Gleixner <tglx@...utronix.de> wrote: >> Not beautiful, but it gives the information which is needed and it tells >> me clearly what this is about. While the above lumps everything together >> whatever it is. > > Sure, that makes sense. Ignoring the macro for a moment, how do you > feel about using incomplete structs for the non-C functions as Andy > suggested? I think I agreed with that back then when he suggested it the first time. That still allows me to do a classification: struct asm_exception struct asm_xen_hv_call .... >> Having __bikeshedme would allow to do: >> >> __hardware_call >> __xenhv_call >> __inline_asm_call >> >> or such, which clearly tells how the function should be used and it can >> even be validated by tooling. > > Previously you suggested adding a built-in function to the compiler: > > https://lore.kernel.org/lkml/877dl0sc2m.ffs@nanos.tec.linutronix.de/ > > I actually did implement this in Clang, but the feature wasn't > necessary with opaque types, so I never moved forward with those > patches. A built-in also won't make the code any cleaner, which was a > concern last time. > > I do agree that a function attribute would look cleaner, but it won't > stop anyone from mistakenly calling these functions from C code, which > was something Andy wanted to address at the same time. Do you still > prefer a function attribute over using an opaque type nevertheless? For actually callable functions, by some definition of callable, e.g. the clear_page_*() variants a proper attribute would be definitely preferred. That attribute should tell the compiler that the function is using the register arguments correctly but is not suitable for direct invocation because it clobbers registers. So the compiler can just refuse to call such a function if used directly without an inline asm wrapper which describes the clobbers, right? But thinking more about clobbers. The only "annotation" of clobbers we have today are the clobbers in the inline asm, which is fragile too. Something like __attribute__ ((clobbers ("rcx", "rax"))) might be useful by itself because it allows validation of the clobbers in the inline asm wrappers and also allows a analysis tool to look at the ASM code and check whether the above list is correct. Hmm? Thanks, tglx
Powered by blists - more mailing lists