linux-kernel - [GIT PULL] Rust fixes for 6.2

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Jan 2023 20:33:34 +0100
From:   Miguel Ojeda <ojeda@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Miguel Ojeda <ojeda@...nel.org>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [GIT PULL] Rust fixes for 6.2

Hi Linus,

This is the first "fixes" PR for Rust.

While it may be a bit early to have a "fixes" branch, I guessed it
would not hurt to start practicing how to do things for the future when
we may get actual users. And since the opportunity presented itself,
I wanted to also use this PR to bring up a "policy" topic and ideally
get kernel maintainers to think about it.

The PR contains a fix for a soundness issue, i.e. it closes a hole that
would allow somebody to write safe Rust code that is able to trigger
undefined behavior.

There are no actual cases of callers triggering this, so it is possible
to argue this is not a fix, which is fair. In other words, virtually
all C code suffers from these soundness holes, but obviously they are
not considered bugs. It is precisely this extra "layer" of protection
that Rust gives to source code that we think is valuable to the kernel.

On the other hand, others may argue they want soundness fixes to land,
and possibly even backported to stable, because they may run patched
kernels, out-of-tree modules, etc. and they may want to know if they
have a problem, even if that breaks their build.

Personally, for what is worth, I would support treating them as fixes.
But I do not want to create extra work for others until we have at
least some real users. So perhaps it should not go to stable?

The commit has been in linux-next for a week in a new branch called
rust-fixes. No conflicts expected. No changes to the C side.

Please pull -- thanks!

Cheers,
Miguel

The following changes since commit 5dc4c995db9eb45f6373a956eb1f69460e69e6d4:

  Linux 6.2-rc4 (2023-01-15 09:22:43 -0600)

are available in the Git repository at:

  https://github.com/Rust-for-Linux/linux tags/rust-fixes-6.2

for you to fetch changes up to 6618d69aa129a8fc613e64775d5019524c6f231b:

  rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks (2023-01-16 00:54:35 +0100)

----------------------------------------------------------------
Rust fixes for v6.2

A soundness fix:

 - Avoid evaluating arguments in 'pr_*' macros in 'unsafe' blocks.

----------------------------------------------------------------
Miguel Ojeda (1):
      rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks

 rust/kernel/print.rs | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)