All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	"Björn 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
Date: Thu, 25 Jan 2024 13:45:05 +0000	[thread overview]
Message-ID: <20240125-lazy-thrower-744aacc6632a@wendy> (raw)
In-Reply-To: <CANiq72k7n0aZrifRRU08N8qLkNe+2EZwijZy5sM7M56n2xYHgQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]

On Thu, Jan 25, 2024 at 01:50:05PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 25, 2024 at 1:31 PM Conor Dooley <conor.dooley@microchip.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/288089-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.
> 
> 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 :)

> 
> > 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?
> 
> 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=kcfi 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
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>,
	"Björn 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
Date: Thu, 25 Jan 2024 13:45:05 +0000	[thread overview]
Message-ID: <20240125-lazy-thrower-744aacc6632a@wendy> (raw)
In-Reply-To: <CANiq72k7n0aZrifRRU08N8qLkNe+2EZwijZy5sM7M56n2xYHgQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2869 bytes --]

On Thu, Jan 25, 2024 at 01:50:05PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 25, 2024 at 1:31 PM Conor Dooley <conor.dooley@microchip.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/288089-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.
> 
> 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 :)

> 
> > 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?
> 
> 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=kcfi 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2024-01-25 13:46 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 10:24 [PATCH v1 0/2] RISC-V: enable rust Conor Dooley
2023-03-07 10:24 ` Conor Dooley
2023-03-07 10:24 ` [PATCH v1 1/2] scripts: generate_rust_target: enable building on RISC-V Conor Dooley
2023-03-07 10:24   ` Conor Dooley
2023-03-07 11:21   ` Miguel Ojeda
2023-03-07 11:21     ` Miguel Ojeda
2023-03-07 10:24 ` [PATCH v1 2/2] RISC-V: enable building 64-bit kernels with rust support Conor Dooley
2023-03-07 10:24   ` Conor Dooley
2023-03-07 10:56   ` Miguel Ojeda
2023-03-07 10:56     ` Miguel Ojeda
2023-03-07 11:01     ` Conor Dooley
2023-03-07 11:01       ` Conor Dooley
2023-03-07 11:56       ` Miguel Ojeda
2023-03-07 11:56         ` Miguel Ojeda
2023-03-07 12:51         ` Conor Dooley
2023-03-07 12:51           ` Conor Dooley
2023-03-07 11:07 ` [PATCH v1 0/2] RISC-V: enable rust Miguel Ojeda
2023-03-07 11:07   ` Miguel Ojeda
2023-03-30  8:23   ` Conor Dooley
2023-03-30  8:23     ` Conor Dooley
2023-03-30  9:11     ` Conor Dooley
2023-03-30  9:11       ` Conor Dooley
2023-04-03 16:35       ` Miguel Ojeda
2023-04-03 16:35         ` Miguel Ojeda
2023-04-03 17:14         ` Conor Dooley
2023-04-03 17:14           ` Conor Dooley
2023-04-05 21:18           ` Conor Dooley
2023-04-05 21:18             ` Conor Dooley
2023-04-03 16:32     ` Miguel Ojeda
2023-04-03 16:32       ` Miguel Ojeda
2023-06-08  7:01 ` Conor Dooley
2023-06-08  7:01   ` Conor Dooley
2023-06-08  7:10   ` Conor Dooley
2023-06-08  7:10     ` Conor Dooley
2023-06-08  7:50   ` Kwanghoon Son
2023-06-08  7:50     ` Kwanghoon Son
2023-06-08  7:50     ` Kwanghoon Son
2023-06-08 11:52   ` Miguel Ojeda
2023-06-08 11:52     ` Miguel Ojeda
2023-06-08 12:28     ` Conor Dooley
2023-06-08 12:28       ` Conor Dooley
2024-01-17 11:30       ` Conor Dooley
2024-01-17 11:30         ` Conor Dooley
2024-01-17 18:23         ` Miguel Ojeda
2024-01-17 18:23           ` Miguel Ojeda
2024-01-18 15:49           ` Conor Dooley
2024-01-18 15:49             ` Conor Dooley
2024-01-18 16:09             ` Miguel Ojeda
2024-01-18 16:09               ` Miguel Ojeda
2024-01-25 12:30               ` Conor Dooley
2024-01-25 12:30                 ` Conor Dooley
2024-01-25 12:50                 ` Miguel Ojeda
2024-01-25 12:50                   ` Miguel Ojeda
2024-01-25 13:45                   ` Conor Dooley [this message]
2024-01-25 13:45                     ` Conor Dooley
2024-01-26 21:00                     ` Miguel Ojeda
2024-01-26 21:00                       ` Miguel Ojeda
2024-01-26 22:00                       ` Conor Dooley
2024-01-26 22:00                         ` Conor Dooley
2024-01-27 13:46                         ` Miguel Ojeda
2024-01-27 13:46                           ` Miguel Ojeda
2024-02-09 15:18                           ` Conor Dooley
2024-02-09 15:18                             ` Conor Dooley
2024-02-10  8:13                             ` Trevor Gross
2024-02-10  8:13                               ` Trevor Gross
2024-02-12 19:03                               ` Ramon de C Valle
2024-02-12 19:03                                 ` Ramon de C Valle
2024-02-12 20:36                                 ` Sami Tolvanen
2024-02-12 20:36                                   ` Sami Tolvanen
2024-02-13 20:08                                   ` Ramon de C Valle
2024-02-13 20:08                                     ` Ramon de C Valle
2024-02-14  3:14                                     ` Trevor Gross
2024-02-14  3:14                                       ` Trevor Gross
     [not found]                               ` <CAOcBZORDaHHH3jTL3GO7OsDubhhyQE0Uy2uAjJpiRzrKBgqaOw@mail.gmail.com>
2024-02-12 19:11                                 ` Miguel Ojeda
2024-02-12 19:11                                   ` Miguel Ojeda
2024-02-12 20:17                                   ` Conor Dooley
2024-02-12 20:17                                     ` Conor Dooley
2024-02-12 20:37                                     ` Conor Dooley
2024-02-12 20:37                                       ` Conor Dooley
2024-02-13 20:09                                       ` Ramon de C Valle
2024-02-13 20:09                                         ` Ramon de C Valle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240125-lazy-thrower-744aacc6632a@wendy \
    --to=conor.dooley@microchip.com \
    --cc=alex.gaynor@gmail.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=conor@kernel.org \
    --cc=corbet@lwn.net \
    --cc=gary@garyguo.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mmaurer@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rcvalle@google.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samitolvanen@google.com \
    --cc=trix@redhat.com \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.