From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Matthew Wilcox <willy@infradead.org>,
lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
rust-for-linux@vger.kernel.org,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Alice Ryhl <aliceryhl@google.com>,
Wedson Almeida Filho <wedsonaf@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Kees Cook <keescook@chromium.org>, Gary Guo <gary@garyguo.net>,
Dave Chinner <dchinner@redhat.com>,
David Howells <dhowells@redhat.com>,
Ariel Miculas <amiculas@cisco.com>,
Paul McKenney <paulmck@kernel.org>
Subject: Re: [LSF/MM TOPIC] Rust
Date: Thu, 25 Jan 2024 16:30:01 -0500 [thread overview]
Message-ID: <fafee46bae1a1fc378eb48f808376fd10564088c.camel@HansenPartnership.com> (raw)
In-Reply-To: <dd7w7t42m2mckgal7sl5azop6tlue4wog7yxz52g2val77fye7@hm5gvdkwzw23>
On Thu, 2024-01-25 at 04:24 -0500, Kent Overstreet wrote:
> On Wed, Jan 24, 2024 at 10:47:22PM -0500, James Bottomley wrote:
> > On Wed, 2024-01-24 at 14:57 -0500, Kent Overstreet wrote:
> > > On Wed, Jan 24, 2024 at 02:43:21PM -0500, James Bottomley wrote:
> > > > On Wed, 2024-01-24 at 13:50 -0500, Kent Overstreet wrote:
> > > > > > To illustrate the problem with cryptography in rust: just
> > > > > > because it's rust safe doesn't mean its correct or bug
> > > > > > free. Crypto functions are the most difficult to get right
> > > > > > (algorithmically, regardless of memory safety). Look at
> > > > > > this Medium report on the top ten bugs in blockchain:
> > > > > >
> > > > > > https://medium.com/rektoff/top-10-vulnerabilities-in-substrate-based-blockchains-using-rust-d454279521ff
> > > > > >
> > > > > > Number 1 is a rust crypto vulnerability due to insecure
> > > > > > randomness in a random number generating function (note it
> > > > > > was rust safe code just not properly checked for
> > > > > > algorithmic issues by a cryptographer).
> > > > > >
> > > > > > The reason for using the kernel functions is that they are
> > > > > > vetted by cryptographers and crafted for our environment.
> > > > >
> > > > > Are you arguing that typical kernel code is more secure than
> > > > > typical Rust code?
> > > >
> > > > For crypto code? Absolutely, that's what the example above
> > > > showed. It's pretty much impossible to use an insecure rng in
> > > > the kernel if you plug into one of our existing APIs. That's
> > > > obviously not necessarily true if you pull a random one from
> > > > crates.io.
> > > >
> > > > James
> > >
> > > I can just as easily use prandom.h instead of random.h in the
> > > kernel;
> >
> > Neither of which would be insecure ...
>
> Are you claiming that
>
> /* Pseudo random number generator from numerical recipes. */
> static inline u32 next_pseudo_random32(u32 seed)
> {
> return seed * 1664525 + 1013904223;
> }
>
> is a secure RNG?
It's the best linear congruence generator for 32 bits, yes; it's
straight out of Knuth. However, I assume you picked that one becuase
you know it's only used in testing to generate a repeatable series of
numbers. The actual prandom_ API is based on an internally seeded
linear feedback shift register algorithm.
The trick to using PRNGs correctly is 1) knowing you can use them and
don't need cryptographic randomness and 2) seeding them correctly,
which is where the rust problem came from and which you can't get wrong
in Linux because it's done directly from the entropy pool.
James
next prev parent reply other threads:[~2024-01-25 21:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 4:23 [LSF/MM TOPIC] Rust Kent Overstreet
2024-01-23 19:09 ` Matthew Wilcox
2024-01-23 21:04 ` Boqun Feng
2024-01-24 14:26 ` James Bottomley
2024-01-24 15:43 ` Matthew Wilcox
2024-01-24 16:04 ` James Bottomley
2024-01-24 18:50 ` Kent Overstreet
2024-01-24 19:23 ` Morten Linderud
2024-01-24 19:43 ` James Bottomley
2024-01-24 19:57 ` Kent Overstreet
2024-01-25 3:47 ` James Bottomley
2024-01-25 9:24 ` Kent Overstreet
2024-01-25 21:30 ` James Bottomley [this message]
2024-01-23 22:58 ` David Howells
2024-01-24 3:57 ` Boqun Feng
2024-01-24 21:20 ` Kent Overstreet
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=fafee46bae1a1fc378eb48f808376fd10564088c.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=aliceryhl@google.com \
--cc=amiculas@cisco.com \
--cc=brauner@kernel.org \
--cc=dchinner@redhat.com \
--cc=dhowells@redhat.com \
--cc=gary@garyguo.net \
--cc=keescook@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=paulmck@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).