Re: [PATCH v3 1/2] uaccess: rust: add strncpy_from_user

[Boqun Feng <boqun.feng@gmail.com>]

On Mon, May 05, 2025 at 04:30:05PM +0200, Greg Kroah-Hartman wrote:
[...]
> > +
> > +/// Reads a nul-terminated string into `buf` and returns the length.
> > +///
> > +/// This reads from userspace until a NUL byte is encountered, or until `buf.len()` bytes have been
> > +/// read. Fails with [`EFAULT`] if a read happens on a bad address (some data may have been
> > +/// copied). When the end of the buffer is encountered, no NUL byte is added, so the string is
> > +/// *not* guaranteed to be NUL-terminated when `Ok(buf.len())` is returned.
> > +///
> > +/// # Guarantees
> > +///
> > +/// When this function returns `Ok(len)`, it is guaranteed that the first `len` of `buf` bytes are
> > +/// initialized and non-zero. Furthermore, if `len < buf.len()`, then `buf[len]` is a NUL byte.
> > +/// Unsafe code may rely on these guarantees.
> > +#[inline]
> > +#[expect(dead_code)]
> > +fn raw_strncpy_from_user(ptr: UserPtr, buf: &mut [MaybeUninit<u8>]) -> Result<usize> {
> 
[...]
> Also, it's not your fault, but we don't have any type of __user tag for
> data coming from userspace yet to track this type of thing?  The

I think the type `UserPtr` is supposed to track this information, i.e.
Rust can only get a `UserPtr` from an input from userspace, and of
course Rust code cannot treat `UserPtr` as a normal pointer. For
example, the following would fall because of this:

    pub fn foo(ptr: *mut u8, ...) {
        raw_strncpy_from_user(ptr, ...);
    }

Regards,
Boqun

> compiler (well sparse) can catch this type of thing in C, any hints on
> what we could do in Rust for the same type of guarantee (i.e. don't
> touch user data before it's been copied, and then we need to treat it as
> "unverified" but that's a different patch series...)
> 
> thanks,
> 
> greg k-h