Re: [PATCH] io_uring: zero remained bytes when reading to fixed kernel buffer

[Ming Lei <ming.lei@redhat.com>]

On Sat, Mar 22, 2025 at 11:52:20AM -0600, Keith Busch wrote:
> On Sat, Mar 22, 2025 at 09:50:37PM +0800, Ming Lei wrote:
> > On Sat, Mar 22, 2025 at 12:02:02PM +0000, Pavel Begunkov wrote:
> > > On 3/22/25 07:56, Ming Lei wrote:
> > > > So far fixed kernel buffer is only used for FS read/write, in which
> > > > the remained bytes need to be zeroed in case of short read, otherwise
> > > > kernel data may be leaked to userspace.
> > > 
> > > Can you remind me, how that can happen? Normally, IIUC, you register
> > > a request filled with user pages, so no kernel data there. Is it some
> > > bounce buffers?
> > 
> > For direct io, it is filled with user pages, but it can be buffered IO,
> > and the page can be mapped to userspace.
> 
> I may missing something here because that doesn't sound specific to
> kernel registered bvecs. Is page cache memory not already zeroed out to
> protect against short reads?

Not sure if mm/fs will do that for short read.

At least some drivers do zero data for short read, such as loop,
erofs_fileio_ki_complete(), null_blk...

> 
> I can easily wire up a flakey device that won't fill the requested
> memory. What do I need to do to observe this data leak?

You can observe non-zero data in this way.

Wrt. zero copy, the device need to be trusted, that is why both USER_COPY
and ZERO_COPY features can't be available for unprivileged mode.

Thinking of further, this patch isn't needed because ublk driver does
handle short READ by requeuing request.


Thanks,
Ming