All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Ramon de C Valle <rcvalle@google.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
	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: Fri, 5 Apr 2024 00:41:02 +0200	[thread overview]
Message-ID: <CAOcBZOS2kPyH0Dm7Fuh4GC3=v7nZhyzBj_-dKu3PfAnrHZvaxg@mail.gmail.com> (raw)
In-Reply-To: <CANiq72kSfC2j07mAaV591i4kDwejWRYcFTvASgQmNnHVe5ZwCw@mail.gmail.com>

>
> 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).

Sorry about that, I should've done this already. In addition to the
link you added above, here's a tracking issue for KCFI support for
Rust:
https://github.com/rust-lang/rust/issues/123479

There are still a few unresolved questions that I'd like to hear from
you as you experiment with it, which the tl,dr. is: KCFI support for
Rust shares most of its implementation with the CFI support, with some
key differences:

KCFI performs type tests differently and are implemented as different
LLVM passes than CFI to not require LTO.
KCFI has the limitation that a function or method may have one type id
assigned only.

Because of limitation listed above (2), the current KCFI
implementation (not CFI) does reifying of types (i.e., adds
shims/trampolines for indirect calls in these cases) for:

Supporting casting between function items, closures, and Fn trait objects.
Supporting methods being cast as function pointers.

There may be possible costs of these added levels of indirections for
KCFI for cache coherence/locality and performance, possible
introduction of gadgets or KCFI bypasses, and increased
artifact/binary sizes, which haven't been looked at yet, and I'm
honestly not super happy about it (but it's better than the original
proposal of adding shims/trampolines to every virtual call in the Rust
compiler), so I'd be interested in any performance results or
regressions you may have while experimenting with it, more
specifically:

Linux Kernel without KCFI vs Linux Kernel with KCFI vs Linux Kernel
with Rust and KCFI, possibly isolated to the code of a driver that has
an implementation in C vs an alternative implementation in Rust.

WARNING: multiple messages have this Message-ID (diff)
From: Ramon de C Valle <rcvalle@google.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
	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: Fri, 5 Apr 2024 00:41:02 +0200	[thread overview]
Message-ID: <CAOcBZOS2kPyH0Dm7Fuh4GC3=v7nZhyzBj_-dKu3PfAnrHZvaxg@mail.gmail.com> (raw)
In-Reply-To: <CANiq72kSfC2j07mAaV591i4kDwejWRYcFTvASgQmNnHVe5ZwCw@mail.gmail.com>

>
> 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).

Sorry about that, I should've done this already. In addition to the
link you added above, here's a tracking issue for KCFI support for
Rust:
https://github.com/rust-lang/rust/issues/123479

There are still a few unresolved questions that I'd like to hear from
you as you experiment with it, which the tl,dr. is: KCFI support for
Rust shares most of its implementation with the CFI support, with some
key differences:

KCFI performs type tests differently and are implemented as different
LLVM passes than CFI to not require LTO.
KCFI has the limitation that a function or method may have one type id
assigned only.

Because of limitation listed above (2), the current KCFI
implementation (not CFI) does reifying of types (i.e., adds
shims/trampolines for indirect calls in these cases) for:

Supporting casting between function items, closures, and Fn trait objects.
Supporting methods being cast as function pointers.

There may be possible costs of these added levels of indirections for
KCFI for cache coherence/locality and performance, possible
introduction of gadgets or KCFI bypasses, and increased
artifact/binary sizes, which haven't been looked at yet, and I'm
honestly not super happy about it (but it's better than the original
proposal of adding shims/trampolines to every virtual call in the Rust
compiler), so I'd be interested in any performance results or
regressions you may have while experimenting with it, more
specifically:

Linux Kernel without KCFI vs Linux Kernel with KCFI vs Linux Kernel
with Rust and KCFI, possibly isolated to the code of a driver that has
an implementation in C vs an alternative implementation in Rust.

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

  reply	other threads:[~2024-04-04 22:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-04 14:17 [PATCH v3] rust: make mutually exclusive with CFI_CLANG Conor Dooley
2024-04-04 14:17 ` Conor Dooley
2024-04-04 14:33 ` Miguel Ojeda
2024-04-04 14:33   ` Miguel Ojeda
2024-04-04 15:25   ` Matthew Maurer
2024-04-04 15:25     ` Matthew Maurer
2024-04-04 15:55     ` Conor Dooley
2024-04-04 15:55       ` Conor Dooley
2024-04-04 17:47     ` Miguel Ojeda
2024-04-04 17:47       ` Miguel Ojeda
2024-04-04 15:32 ` Nathan Chancellor
2024-04-04 15:32   ` Nathan Chancellor
2024-04-04 18:42   ` Miguel Ojeda
2024-04-04 18:42     ` Miguel Ojeda
2024-04-04 22:41     ` Ramon de C Valle [this message]
2024-04-04 22:41       ` Ramon de C Valle
     [not found]     ` <CAOcBZOTuqzwQncS8rMUMoOj3zE+FnLxPY6O=4EEaOP2xuFG9Vg@mail.gmail.com>
2024-04-05 10:30       ` Miguel Ojeda
2024-04-05 10:30         ` Miguel Ojeda
2024-04-07 20:02 ` Miguel Ojeda
2024-04-07 20:02   ` Miguel Ojeda

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='CAOcBZOS2kPyH0Dm7Fuh4GC3=v7nZhyzBj_-dKu3PfAnrHZvaxg@mail.gmail.com' \
    --to=rcvalle@google.com \
    --cc=alex.gaynor@gmail.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=keescook@chromium.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=nathan@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samitolvanen@google.com \
    --cc=stable@vger.kernel.org \
    --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.