Re: [PATCH v4 2/2] uaccess: rust: add UserSliceReader::strcpy_into_buf

["Benno Lossin" <lossin@kernel.org>]

On Sat May 31, 2025 at 3:25 PM CEST, Alice Ryhl wrote:
> On Fri, May 30, 2025 at 8:16 PM Benno Lossin <lossin@kernel.org> wrote:
>> On Tue May 27, 2025 at 2:34 PM CEST, Alice Ryhl wrote:
>> > This patch adds a more convenient method for reading C strings from
>> > userspace. Logic is added to NUL-terminate the buffer when necessary so
>> > that a &CStr can be returned.
>> >
>> > Note that we treat attempts to read past `self.length` as a fault, so
>> > this returns EFAULT if that limit is exceeded before `buf.len()` is
>> > reached.
>> >
>> > Reviewed-by: Danilo Krummrich <dakr@kernel.org>
>> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>> > ---
>> >  rust/kernel/uaccess.rs | 56 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> >  1 file changed, 55 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
>> > index 9b1e4016fca2c25a44a8417c7e35e0fcf08aa959..e6534b52a1920254d61f8349426d4cdb38286089 100644
>> > --- a/rust/kernel/uaccess.rs
>> > +++ b/rust/kernel/uaccess.rs
>> > @@ -293,6 +293,61 @@ pub fn read_all<A: Allocator>(mut self, buf: &mut Vec<u8, A>, flags: Flags) -> R
>> >          unsafe { buf.set_len(buf.len() + len) };
>> >          Ok(())
>> >      }
>> > +
>> > +    /// Read a NUL-terminated string from userspace and return it.
>> > +    ///
>> > +    /// The string is read into `buf` and a NUL-terminator is added if the end of `buf` is reached.
>> > +    /// Since there must be space to add a NUL-terminator, the buffer must not be empty. The
>> > +    /// returned `&CStr` points into `buf`.
>> > +    ///
>> > +    /// Fails with [`EFAULT`] if the read happens on a bad address (some data may have been
>> > +    /// copied).
>> > +    #[doc(alias = "strncpy_from_user")]
>> > +    pub fn strcpy_into_buf<'buf>(self, buf: &'buf mut [u8]) -> Result<&'buf CStr> {
>> > +        if buf.is_empty() {
>> > +            return Err(EINVAL);
>> > +        }
>> > +
>> > +        // SAFETY: The types are compatible and `strncpy_from_user` doesn't write uninitialized
>> > +        // bytes to `buf`.
>> > +        let mut dst = unsafe { &mut *(buf as *mut [u8] as *mut [MaybeUninit<u8>]) };
>> > +
>> > +        // We never read more than `self.length` bytes.
>> > +        if dst.len() > self.length {
>> > +            dst = &mut dst[..self.length];
>> > +        }
>> > +
>> > +        let mut len = raw_strncpy_from_user(dst, self.ptr)?;
>> > +        if len < dst.len() {
>> > +            // Add one to include the NUL-terminator.
>> > +            len += 1;
>> > +        } else if len < buf.len() {
>> > +            // This implies that `len == dst.len() < buf.len()`.
>> > +            //
>> > +            // This means that we could not fill the entire buffer, but we had to stop reading
>> > +            // because we hit the `self.length` limit of this `UserSliceReader`. Since we did not
>> > +            // fill the buffer, we treat this case as if we tried to read past the `self.length`
>> > +            // limit and received a page fault, which is consistent with other `UserSliceReader`
>> > +            // methods that also return page faults when you exceed `self.length`.
>> > +            return Err(EFAULT);
>> > +        } else {
>> > +            // This implies that len == buf.len().
>> > +            //
>> > +            // This means that we filled the buffer exactly. In this case, we add a NUL-terminator
>> > +            // and return it. Unlike the `len < dst.len()` branch, don't modify `len` because it
>> > +            // already represents the length including the NUL-terminator.
>> > +            //
>> > +            // SAFETY: Due to the check at the beginning, the buffer is not empty.
>> > +            unsafe { *buf.last_mut().unwrap_unchecked() = 0 };
>>
>> In this case you're overwriting the last character read. Should we give
>> `raw_strncpy_from_user` access to one less byte and then write NUL into
>> that?
>
> Why? I'm not interested in changing the implementation just because.
> It needs to be significantly simpler, and I do not think it is.

Sure, but then I think we should document this behavior.

---
Cheers,
Benno