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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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