rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benno Lossin <benno.lossin@proton.me>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: rust-for-linux@vger.kernel.org, linux-crypto@vger.kernel.org,
	alex.gaynor@gmail.com, herbert@gondor.apana.org.au,
	ebiggers@kernel.org
Subject: Re: [PATCH v2 2/3] rust: crypto abstractions for random number generator API
Date: Fri, 14 Jul 2023 16:20:42 +0000	[thread overview]
Message-ID: <-xQIPlnP549kG6X754m3g70WVVQE7-ihc6XyZfhT7wxHDQiQZ2fr8JorXfRoNvK2-5pGlYWVPqBbkXXLSPRCjtLtMnoPCfau5n8P8AVqqi8=@proton.me> (raw)
In-Reply-To: <20230710102225.155019-3-fujita.tomonori@gmail.com>

> This patch adds basic abstractions for random number generator API,
> wrapping crypto_rng structure.
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
> ---
>  rust/bindings/bindings_helper.h |   1 +
>  rust/helpers.c                  |  12 ++++
>  rust/kernel/crypto.rs           |   1 +
>  rust/kernel/crypto/rng.rs       | 101 ++++++++++++++++++++++++++++++++
>  4 files changed, 115 insertions(+)
>  create mode 100644 rust/kernel/crypto/rng.rs
> 
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 2f198c6d5de5..089ac38c6461 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -7,6 +7,7 @@
>   */
> 
>  #include <crypto/hash.h>
> +#include <crypto/rng.h>
>  #include <linux/errname.h>
>  #include <linux/slab.h>
>  #include <linux/refcount.h>
> diff --git a/rust/helpers.c b/rust/helpers.c
> index 7966902ed8eb..e4dcd611738f 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -19,6 +19,7 @@
>   */
> 
>  #include <crypto/hash.h>
> +#include <crypto/rng.h>
>  #include <linux/bug.h>
>  #include <linux/build_bug.h>
>  #include <linux/err.h>
> @@ -52,6 +53,17 @@ int rust_helper_crypto_shash_init(struct shash_desc *desc) {
>  	return crypto_shash_init(desc);
>  }
>  EXPORT_SYMBOL_GPL(rust_helper_crypto_shash_init);
> +
> +void rust_helper_crypto_free_rng(struct crypto_rng *tfm) {
> +	crypto_free_rng(tfm);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_crypto_free_rng);
> +
> +int rust_helper_crypto_rng_generate(struct crypto_rng *tfm, const u8 *src,
> +	unsigned int slen, u8 *dst, unsigned int dlen) {
> +	return crypto_rng_generate(tfm, src, slen, dst, dlen);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_crypto_rng_generate);
>  #endif
> 
>  __noreturn void rust_helper_BUG(void)
> diff --git a/rust/kernel/crypto.rs b/rust/kernel/crypto.rs
> index f80dd7bd3381..a1995e6c85d4 100644
> --- a/rust/kernel/crypto.rs
> +++ b/rust/kernel/crypto.rs
> @@ -3,3 +3,4 @@
>  //! Cryptography.
> 
>  pub mod hash;
> +pub mod rng;
> diff --git a/rust/kernel/crypto/rng.rs b/rust/kernel/crypto/rng.rs
> new file mode 100644
> index 000000000000..683f5ee464ce
> --- /dev/null
> +++ b/rust/kernel/crypto/rng.rs
> @@ -0,0 +1,101 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Random number generator.
> +//!
> +//! C headers: [`include/crypto/rng.h`](../../../../include/crypto/rng.h)
> +
> +use crate::{
> +    error::{code::EINVAL, from_err_ptr, to_result, Result},
> +    str::CStr,
> +};
> +
> +/// Type of Random number generator.
> +///
> +/// # Invariants
> +///
> +/// The pointer is valid.
> +enum RngType {
> +    /// Uses `crypto_default_rng`
> +    // We don't need to keep an pointer for the default but simpler.
> +    Default(*mut bindings::crypto_rng),
> +
> +    /// Allocated via `crypto_alloc_rng.
> +    Allocated(*mut bindings::crypto_rng),
> +}

You could also do this:
```
enum RngType {
    Default,
    Allocated(NonNull<bindings::crypto_rng>),
}
```

Assuming that `crypto_alloc_rng` never returns null.
Then this definition will the same size as a plain pointer.

> +
> +/// Corresponds to the kernel's `struct crypto_rng`.
> +pub struct Rng(RngType);
> +
> +impl Drop for Rng {
> +    fn drop(&mut self) {
> +        match self.0 {
> +            RngType::Default(_) => {
> +                // SAFETY: it's safe because `crypto_get_default_rng()` was called during
> +                // the initialization.
> +                unsafe {
> +                    bindings::crypto_put_default_rng();
> +                }
> +            }
> +            RngType::Allocated(ptr) => {
> +                // SAFETY: The type invariants of `RngType` guarantees that the pointer is valid.
> +                unsafe { bindings::crypto_free_rng(ptr) };
> +            }
> +        }
> +    }
> +}
> +
> +impl Rng {
> +    /// Creates a [`Rng`] instance.
> +    pub fn new(name: &CStr, t: u32, mask: u32) -> Result<Self> {
> +        // SAFETY: There are no safety requirements for this FFI call.
> +        let ptr = unsafe { from_err_ptr(bindings::crypto_alloc_rng(name.as_char_ptr(), t, mask)) }?;
> +        // INVARIANT: `ptr` is valid and non-null since `crypto_alloc_rng`
> +        // returned a valid pointer which was null-checked.
> +        Ok(Self(RngType::Allocated(ptr)))
> +    }
> +
> +    /// Creates a [`Rng`] instance with a default algorithm.
> +    pub fn new_with_default() -> Result<Self> {
> +        // SAFETY: There are no safety requirements for this FFI call.
> +        to_result(unsafe { bindings::crypto_get_default_rng() })?;
> +        // INVARIANT: The C API guarantees that `crypto_default_rng` is valid until
> +        // `crypto_put_default_rng` is called.
> +        Ok(Self(RngType::Default(unsafe {
> +            bindings::crypto_default_rng

You are accessing a `mut static`, this is `unsafe` (hence the need
for an `unsafe` block) and needs a safety comment, why is it safe to
access this mutable static? What synchronizes the access (is it not needed)?

> +        })))
> +    }
> +
> +    /// Get a random number.
> +    pub fn generate(&mut self, src: &[u8], dst: &mut [u8]) -> Result {
> +        if src.len() > u32::MAX as usize || dst.len() > u32::MAX as usize {
> +            return Err(EINVAL);
> +        }
> +        let ptr = match self.0 {
> +            RngType::Default(ptr) => ptr,
> +            RngType::Allocated(ptr) => ptr,
> +        };
> +        // SAFETY: The type invariants of `RngType' guarantees that the pointer is valid.
> +        to_result(unsafe {
> +            bindings::crypto_rng_generate(
> +                ptr,
> +                src.as_ptr(),
> +                src.len() as u32,
> +                dst.as_mut_ptr(),
> +                dst.len() as u32,
> +            )
> +        })
> +    }
> +
> +    /// Re-initializes the [`Rng`] instance.
> +    pub fn reset(&mut self, seed: &[u8]) -> Result {
> +        if seed.len() > u32::MAX as usize {
> +            return Err(EINVAL);
> +        }
> +        let ptr = match self.0 {
> +            RngType::Default(ptr) => ptr,
> +            RngType::Allocated(ptr) => ptr,
> +        };
> +        // SAFETY: The type invariants of `RngType' guarantees that the pointer is valid.
> +        to_result(unsafe { bindings::crypto_rng_reset(ptr, seed.as_ptr(), seed.len() as u32) })

If I read this correctly, then if I have to threads each with a `Default`
crypto rng, then one could be reset as the other is concurrently
generating some random numbers, right? This *should* be fine, but does
it make sense to do it? Or should there only be one thread accessing
the default crypto rng?

--
Cheers,
Benno

> +    }
> +}
> --
> 2.34.1
> 


  reply	other threads:[~2023-07-14 16:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10 10:22 [PATCH v2 0/3] Rust abstractions for Crypto API FUJITA Tomonori
2023-07-10 10:22 ` [PATCH v2 1/3] rust: crypto abstractions for synchronous message digest API FUJITA Tomonori
2023-07-14 16:19   ` Benno Lossin
2023-07-10 10:22 ` [PATCH v2 2/3] rust: crypto abstractions for random number generator API FUJITA Tomonori
2023-07-14 16:20   ` Benno Lossin [this message]
2023-07-10 10:22 ` [PATCH v2 3/3] MAINTAINERS: add Rust crypto abstractions files to the CRYPTO API entry FUJITA Tomonori

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='-xQIPlnP549kG6X754m3g70WVVQE7-ihc6XyZfhT7wxHDQiQZ2fr8JorXfRoNvK2-5pGlYWVPqBbkXXLSPRCjtLtMnoPCfau5n8P8AVqqi8=@proton.me' \
    --to=benno.lossin@proton.me \
    --cc=alex.gaynor@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.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 NNTP newsgroup(s).