linux-hardening - Re: [PATCH v5 03/15] linkage: Add DECLARE_NOT_CALLED_FROM

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Oct 2021 19:57:30 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        the arch/x86 maintainers <x86@...nel.org>
Cc:     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 17:55, Thomas Gleixner wrote:
> On Thu, Oct 14 2021 at 19:51, Andy Lutomirski wrote:
>> On Wed, Oct 13, 2021, at 11:16 AM, Sami Tolvanen wrote:
> That still tells me:
>
>     1) This is a function
>     
>     2) It has a regular argument which is expected to be in RDI
>
> which even allows to do analyis of e.g. the alternative call which
> invokes that function.
>
> DECLARE_NOT_CALLED_FROM_C(clear_page_erms);
>
> loses these properties and IMO it's a tasteless hack.

Look:

SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head,
                size_t, len)

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.

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.

You could to that with macros as well, but thats not what you offered.

Seriously, if you want to sell me that stuff, then you really should
offer me something which has a value on its own and makes it palatable
to me. That's not something new. See:

  https://lore.kernel.org/lkml/alpine.LFD.2.00.1001251002430.3574@localhost.localdomain/

That said, I still want to have a coherent technical explanation why the
compiler people cannot come up with a sensible annotation for these
things.

I'm tired of this attitude, that they add features and then ask us to
make our code more ugly.

It's not a well hidden secret that the kernel uses these kind of
constructs. So why on earth can't they be bothered to think about these
things upfront and offer us something nice and useful?

Thanks,

        tglx