Re: [PATCH v3] rust: make mutually exclusive with CFI_CLANG

From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Conor Dooley <conor@kernel.org>,
	linux-riscv@lists.infradead.org,
	 Conor Dooley <conor.dooley@microchip.com>,
	stable@vger.kernel.org,  Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	 Wedson Almeida Filho <wedsonaf@gmail.com>,
	linux-kernel@vger.kernel.org,  rust-for-linux@vger.kernel.org,
	Sami Tolvanen <samitolvanen@google.com>,
	 Kees Cook <keescook@chromium.org>,
	llvm@lists.linux.dev
Subject: Re: [PATCH v3] rust: make mutually exclusive with CFI_CLANG
Date: Thu, 4 Apr 2024 20:42:48 +0200	[thread overview]
Message-ID: <CANiq72kSfC2j07mAaV591i4kDwejWRYcFTvASgQmNnHVe5ZwCw@mail.gmail.com> (raw)
In-Reply-To: <20240404153258.GA852748@dev-arch.thelio-3990X>

On Thu, Apr 4, 2024 at 5:33 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Acked-by: Nathan Chancellor <nathan@kernel.org>

Thanks!

> It seems like this won't be forgotten about but if there is not already
> an issue open for this somewhere, it would be good to have one, since we
> obviously want this for both C and Rust code.

We track the unstable feature(s) at
https://github.com/Rust-for-Linux/linux/issues/2 (I just moved this
one there since it is close to ready, but it was in #355 previously,
and cleaned things up a bit).

On the Rust side, I think the main one is
https://github.com/rust-lang/rust/issues/89653.

It includes KCFI, but it is missing Matthew's PRs for KCFI etc. I
added a link to get those issues/PRs (or hopefully most of them):
https://github.com/rust-lang/rust/pulls?q=is%3Apr+cfi+label%3APG-exploit-mitigations+-label%3Arollup

We could create an explicit/concrete issue for removing the `depends
on !` when Matthew sends the patches, though.

> As a general meta comment not directed at anyone in particualr, I think
> these 'depends on !' should all have some sort of comment or description
> as to why they are disabled. I can infer from most of them but it would
> still be good to be explicit, especially since someone might want to
> work on fixing the ones that are due to missing support and such.

That is definitely a good idea. An alternative could be linking an
issue instead (perhaps concrete ones for that, i.e. your other idea
above) so that we can update the status etc. easily.

Cheers,
Miguel