linux-kernel - Re: [PATCH] Compiler Attributes: Add __kcfi

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: <CANiq72kPmb+7Ygk_Qvsiq+22EJVSPjjwn4whdLuTGCPwvTAssQ@mail.gmail.com>
Date: Thu, 17 Jul 2025 11:51:09 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: Bill Wendling <morbo@...gle.com>, Andrew Cooper <andrew.cooper3@...rix.com>, 
	Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Justin Stitt <justinstitt@...gle.com>, 
	llvm@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH] Compiler Attributes: Add __kcfi_salt

On Thu, Jul 17, 2025 at 10:53 AM Kees Cook <kees@...nel.org> wrote:
>
> Add support for Clang's coming "kcfi_salt" attribute, which is designed
> to allow for KCFI prototype hashes to be separated[1]. For example,
> normally two "void func(void)" functions would have the same KCFI hash,
> but if they wanted their indirect calls to be distinguishable by KCFI,
> one could add __kcfi_salt("foo").

It would be nice to have a quick sentence inline summarizing how it
will be used, e.g. what kind of functions will need to be annotated.

> To test the result, add a corresponding LKDTM test, CFI_FORWARD_SALT.

Sounds good.

> + * clang: https://clang.llvm.org/docs/AttributeReference.html#kcfi-salt

I guess this anchor will eventually work -- I see you asked about it at:

    https://github.com/llvm/llvm-project/pull/141846#discussion_r2209236363

>From what I see, this still has to land in LLVM, right? So I guess
there is still time to land this (and the discussion started years
ago), but if you need to take it quickly as a base for some other work
or similar:

Acked-by: Miguel Ojeda <ojeda@...nel.org>

Cheers,
Miguel