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]
Message-Id: <20230124193334.161057-1-ojeda@kernel.org>
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(-)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ