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: Thu, 4 Apr 2024 20:42:48 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Conor Dooley <conor@...nel.org>, linux-riscv@...ts.infradead.org, 
	Conor Dooley <conor.dooley@...rochip.com>, stable@...r.kernel.org, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, Sami Tolvanen <samitolvanen@...gle.com>, 
	Kees Cook <keescook@...omium.org>, llvm@...ts.linux.dev
Subject: Re: [PATCH v3] rust: make mutually exclusive with CFI_CLANG

On Thu, Apr 4, 2024 at 5:33 PM Nathan Chancellor <nathan@...nel.org> wrote:
>
> Acked-by: Nathan Chancellor <nathan@...nel.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ