From: Alice Ryhl <aliceryhl@google.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uaccess: rust: add strncpy_from_user
Date: Fri, 25 Apr 2025 09:43:30 +0000 [thread overview]
Message-ID: <aAtZQkre4KRU2kr1@google.com> (raw)
In-Reply-To: <680a5f5d.050a0220.2035d2.545b@mx.google.com>
On Thu, Apr 24, 2025 at 08:57:13AM -0700, Boqun Feng wrote:
> On Thu, Apr 24, 2025 at 03:17:48PM +0000, Alice Ryhl wrote:
> > This is needed for ioctls that operate on a user-provided string.
> >
> > It is somewhat unfortunate that strncpy_from_user does not nul-terminate
> > the string when the end of `buf` is reached. This implies that we can't
> > return a &CStr from the function, since the buffer may not always be
> > nul-terminated.
> >
> > That said, we could add more convenient helpers on top that add a NUL
> > byte in that case.
> >
> > This method isn't defined on UserSliceReader because it complicates the
> > semantics. The UserSliceReader type also has its own maximum length, so
> > we would have to limit the read by that length too.
> >
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> > rust/kernel/uaccess.rs | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
> > index 80a9782b1c6e98ed6eae308ade8551afa7adc188..1bd82045e81ea887008e30241bd6de27f096b639 100644
> > --- a/rust/kernel/uaccess.rs
> > +++ b/rust/kernel/uaccess.rs
> > @@ -369,3 +369,30 @@ pub fn write<T: AsBytes>(&mut self, value: &T) -> Result {
> > Ok(())
> > }
> > }
> > +
> > +/// Reads a nul-terminated string into `buf` and returns the length.
> > +///
> > +/// Fails with [`EFAULT`] if the read happens on a bad address. If the end of `buf` is reached,
> > +/// then the buffer will not be nul-terminated.
> > +#[inline]
> > +pub fn strncpy_from_user(ptr: UserPtr, buf: &mut [u8]) -> Result<usize> {
>
> Sorry maybe there is an email I'm missing, but could you provide more
> context of the usage?
>
> First the function name is a bit weird, because the 'n' in "strncpy"
> means the parameters should have an 'n' (i.e. length) in it, but there
> is none in the Rust version.
There is a length! It's the length of `buf`. It's pretty normal that C
methods with a pointer and length become a Rust method with a slice.
The distinction between strcpy and strncpy in my eyes is that strcpy
reads until you find a NUL byte, whereas strncpy reads until you find a
NUL byte *or* you read a user-specified number of bytes. This method is
in the latter category.
> Also, we don't need to replicate the
> semantics of C here, we could just do a strncpy_from_user(..., ..., len
> - 1), where `len` is the len of the `buf`, and then we would always have
> a nul-terminated string. But maybe I'm missing something from the usage
> side, so this is not doable?
Well, I guess that probably does make sense. I'll update this to always
add a nul-terminator.
Alice
next prev parent reply other threads:[~2025-04-25 9:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 15:17 [PATCH] uaccess: rust: add strncpy_from_user Alice Ryhl
2025-04-24 15:57 ` Boqun Feng
2025-04-25 9:43 ` Alice Ryhl [this message]
2025-04-25 13:39 ` Boqun Feng
2025-04-25 13:52 ` Greg Kroah-Hartman
2025-04-25 14:35 ` Boqun Feng
2025-04-25 14:45 ` Greg Kroah-Hartman
2025-04-24 16:32 ` Danilo Krummrich
2025-04-25 9:44 ` Alice Ryhl
2025-04-25 14:14 ` Danilo Krummrich
2025-04-24 16:38 ` Miguel Ojeda
2025-04-25 9:45 ` Alice Ryhl
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=aAtZQkre4KRU2kr1@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=viro@zeniv.linux.org.uk \
/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.