linux-kernel - Re: kCFI && patchable-function-entry=M,N

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]

Message-ID: <CABCJKuf=OB_3ZR_rwaG3H5kHKmTTDk+sihjJXYmyWgZjUX2yTQ@mail.gmail.com>
Date:   Fri, 21 Oct 2022 10:39:13 -0700
From:   Sami Tolvanen <samitolvanen@...gle.com>
To:     Mark Rutland <mark.rutland@....com>,
        Fangrui Song <maskray@...gle.com>
Cc:     llvm@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Joao Moreira <joao@...rdrivepizza.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: kCFI && patchable-function-entry=M,N

On Fri, Oct 21, 2022 at 8:56 AM Mark Rutland <mark.rutland@....com> wrote:
>
> Hi,
>
> For arm64, I'd like to use -fatchable-function-entry=M,N (where N > 0), for our
> ftrace implementation, which instruments *some* but not all functions.
> Unfortuntately, this doesn't play nicely with -fsanitize=kcfi, as instrumented
> and non-instrumented functions don't agree on where the type hash should live
> relative to the function entry point, making them incompatible with one another.

Yes, the current implementation assumes that if prefix nops are used,
all functions have the same number of them.

> Is there any mechanism today that we could use to solve this, or could we
> extend clang to have some options to control this behaviour?

I don't think there's a mechanism to work around the issue right now,
but we could just change where the hash is emitted on arm64.

> It would also be helpful to have a symbol before both the hash and pre-function
> NOPs so that we can filter those out of probes patching (I see that x86 does
> this with the __cfi_function symbol).

Adding a symbol before the hash isn't a problem, but if we move the
hash and want the symbol to be placed before the prefix nops as well,
we might need a flag to control this. Fangrui, what do you think?

Sami