Received-SPF: pass (google.com: domain of linux-kernel+bounces-38678-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 25 Jan 2024 13:45:05 +0000
From: Conor Dooley <conor.dooley@microchip.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
CC: Conor Dooley <conor@kernel.org>, <linux-riscv@lists.infradead.org>, Miguel
 Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida
 Filho <wedsonaf@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, Gary Guo
	<gary@garyguo.net>, =?iso-8859-1?Q?Bj=F6rn?= Roy Baron
	<bjorn3_gh@protonmail.com>, Jonathan Corbet <corbet@lwn.net>, Paul Walmsley
	<paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Nathan
 Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>, <rust-for-linux@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<llvm@lists.linux.dev>, Matthew Maurer <mmaurer@google.com>, Ramon de C Valle
	<rcvalle@google.com>, Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH v1 0/2] RISC-V: enable rust
Message-ID: <20240125-lazy-thrower-744aacc6632a@wendy>
References: <20230307102441.94417-1-conor.dooley@microchip.com>
 <20230608-dispatch-sneer-aa09bd7b2eb8@wendy>
 <CANiq72nnph7LS1fLRtHz8NJ91PWXPaUnm0EuoV3wrbvK398AnA@mail.gmail.com>
 <20230608-spiritism-gonad-5f5aff4c3a24@wendy>
 <20240117-swiftly-parasail-618d62972d6e@spud>
 <CANiq72mVKCOAuK4Qe+8AHmpkFwyJsVfx8AqB7ccGi3DYpSSWcw@mail.gmail.com>
 <20240118-implode-delirium-eefdd86e170e@spud>
 <CANiq72nx1s_nyvPW86jL7eiOxROr18LfOJqNtw8L42CP+gkhRg@mail.gmail.com>
 <20240125-bucked-payroll-47f82077b262@wendy>
 <CANiq72k7n0aZrifRRU08N8qLkNe+2EZwijZy5sM7M56n2xYHgQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="GuHppkpX7NvgOUA9"
Content-Disposition: inline
In-Reply-To: <CANiq72k7n0aZrifRRU08N8qLkNe+2EZwijZy5sM7M56n2xYHgQ@mail.gmail.com>

--GuHppkpX7NvgOUA9
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 25, 2024 at 01:50:05PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 25, 2024 at 1:31=E2=80=AFPM Conor Dooley <conor.dooley@microc=
hip.com> wrote:

> > > Recently, there has been a thread in our Zulip and a couple people are
> > > experimenting: https://rust-for-linux.zulipchat.com/#narrow/stream/28=
8089-General/topic/Bindgen.20--.20GCC.20backend.20port
> >
> > That link for me goes to a message on 22/01, so later than the email you
> > sent.
>=20
> Zulip seems to scroll to the latest message in the topic -- you should
> be able to scroll a bit up, but if that doesn't work, this link should
> go to the first message:
> https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/=
Bindgen.20--.20GCC.20backend.20port/near/412609074

Ah, thanks for the direct link :)

>=20
> > That said, I gave things another spin today, in a different environment,
> > as a final check before sending and found an issue causing kernel
> > panics. RISC-V (and x86/arm64) supports kcfi (CFI_CLANG) but enabling

I mention x86 and arm64 here, because my grepping didn't see the flag
being set for x86 (in tree) or arm64 (in that series) if CFI_CLANG was
set or any mutual exclusion. Has noone tried CFI_CLANG + RUST there or
just not run into any issues?

> > sanitisers seems to be a nightly only option for rustc. The kernel I
> > built today had CFI_CLANG enabled and that caused panics when the rust
> > samples were loaded.
> >
> > The CFI_CLANG Kconfig entry has a cc-option test for whether the option
> > is supported, but from a quick check I don't see a comparable test to
> > use for rust. Even if a test was added, the current flag is an unstable
> > one, so I am not sure if testing for it is the right call in the first
> > place, given the stabilised flag would be entirely different?
>=20
> Yeah, KCFI and other mitigations is WIP -- Cc'ing Ramon and Matthew
> who may be able to tell us the latest status.

Also CC Sami I guess, since he is the one who added the CFI_CLANG bits
to the kernel, and can probably comment on the suitability of adding a
check etc.

> Testing for unstable flags is fine, i.e. we only support a single
> compiler, so we can change the name when we do the upgrade.

Actually, thinking about it for a moment - if only a single compiler
version is supported (the minimum, right?) then you could just add the
-Zsanitizer=3Dkcfi flag whenever CFI_CLANG and RUST are both set.

I'm not sure if that is a better option though. It's a choice between
CFI_CLANG being disabled if the check is not updated when the toolchain
is bumped versus being enabled for C and not for RUST. I think I prefer
the former though, tracking down the cause of the latter I would rather
not wish on a user.

I vote for having the check, even if it can only ever be true at the
moment.

Cheers,
Conor.

--GuHppkpX7NvgOUA9
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZbJl4QAKCRB4tDGHoIJi
0r2YAP9Kbj4u//RY0nIROcBBxVP3ucR5cgnfxPjsXpqrdOu6FgD/ef8EVCC207/s
Jy65DzLCk1V5UGLDXdSuKcxvD/qEngw=
=6p43
-----END PGP SIGNATURE-----

--GuHppkpX7NvgOUA9--