Re: [PATCH v4 0/4] Untrusted Data API

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

On Thu Aug 14, 2025 at 5:42 PM CEST, Greg KH wrote:
> On Thu, Aug 14, 2025 at 05:22:57PM +0200, Benno Lossin wrote:
>> On Thu Aug 14, 2025 at 4:37 PM CEST, Greg KH wrote:
>> > On Thu, Aug 14, 2025 at 02:44:12PM +0200, Benno Lossin wrote:
>> >> I didn't have too much time to spend on this API, so this is mostly a
>> >> resend of v3. There are some changes in the last commit, updating to the
>> >> latest version of Alice's iov_iter patche series [1] & rebasing on top
>> >> of v6.17-rc1.
>> >> 
>> >> I think we should just merge the first two patches this cycle in order
>> >> to get the initial, bare-bones API into the kernel and have people
>> >> experiment with it. The validation logic in the third patch still needs
>> >> some work and I'd need to find some time to work on that (no idea when I
>> >> find it though).
>> >
>> > Nice, thanks for reviving this!
>> >
>> > And we should at least add an example using it, otherwise it's not going
>> > to help out much here.  Add it to the misc device driver api?
>> 
>> You mean `rust/kernel/miscdevice.rs`? What parts of that API are
>> untrusted? 
>
> mmap() is, but you can't do anything about that...

Which parameter is untrusted there and why can't I do anything about it?

> ioctl() is the callback that is taking untrusted data from userspace.
> That's one place we have had more kernel buffer overflows then I can
> count and ALWAYS needs to be properly verified before anything can be
> done with the data there.

Are the `cmd` & `arg` parameters the untrusted part? If so we probably
should have a single parameter so users can verify them at the same
time. Or am I thinking of the wrong thing to verify? (`file` should be
already in kernel memory, right?)

> And if write() ever gets implemented, that would be as well (but the io
> iter stuff should cover that).

Sounds good.

---
Cheers,
Benno