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
| ||
|
Date: Wed, 06 Oct 2021 00:45:45 +1100 From: Daniel Axtens <dja@...ens.net> To: keescook@...omium.org Cc: catalin.marinas@....com, clang-built-linux@...glegroups.com, hca@...ux.ibm.com, jarmo.tiitto@...il.com, linux-kernel@...r.kernel.org, lukas.bulwahn@...il.com, mark.rutland@....com, masahiroy@...nel.org, maskray@...gle.com, morbo@...gle.com, nathan@...nel.org, ndesaulniers@...gle.com, oberpar@...ux.ibm.com, ojeda@...nel.org, peterz@...radead.org, samitolvanen@...gle.com, torvalds@...ux-foundation.org, wcw@...gle.com, will@...nel.org Subject: Re: ARCH_WANTS_NO_INSTR (Re: [GIT PULL] Clang feature updates for v5.14-rc1) > Kconfig: Introduce ARCH_WANTS_NO_INSTR and CC_HAS_NO_PROFILE_FN_ATTR > > We don't want compiler instrumentation to touch noinstr functions, > which are annotated with the no_profile_instrument_function function > attribute. Add a Kconfig test for this and make GCOV depend on it, and > in the future, PGO. > > If an architecture is using noinstr, it should denote that via this > Kconfig value. That makes Kconfigs that depend on noinstr able to express > dependencies in an architecturally agnostic way. > > However, things in generic code (such as rcu_nmi_enter) are tagged with > `noinstr`, so I'm worried that this commit subtly breaks things like KASAN on > platforms that haven't opted in yet. (I stumbled across this while developing > KASAN on ppc64, but at least riscv and ppc32 have KASAN but not > ARCH_WANTS_NO_INSTR already.) Hmm, so it looks like the commit doesn't affect how noinstr is compiled (which means I have another different issue to contend with!), but... > As I said, I haven't been able to find the original thread - is there any reason > this shouldn't be always on? Why would an arch not opt in? What's the motivation > for ignoring the noinstr markings? > > Should generic KASAN/KCSAN/anything else marked in noinstr also have markings > requring ARCH_WANTS_NO_INSTR? AFAICT they should, right? I'm still curious about all of these questions. I get CC_HAS_NO_PROFILE_FN_ATTR, but I don't get ARCH_WANTS_NO_INSTR. Kind regards, Daniel > > Kind regards, > Daniel
Powered by blists - more mailing lists