On 11/4/24 13:35, Ming Lei wrote:
On Mon, Nov 04, 2024 at 01:24:09PM +0000, Pavel Begunkov wrote:
...
any private data, then the buffer should've already been initialised by
the time it was lease. Initialised is in the sense that it contains no
For block IO the practice is to zero the remainder after short read, please
see example of loop, lo_complete_rq() & lo_read_simple().
It's more important for me to understand what it tries to fix, whether
we can leak kernel data without the patch, and whether it can be exploited
even with the change. We can then decide if it's nicer to zero or not.
I can also ask it in a different way, can you tell is there some security
concern if there is no zeroing? And if so, can you describe what's the exact
way it can be triggered?
Firstly the zeroing follows loop's handling for short read
Secondly, if the remainder part of one page cache buffer isn't zeroed, it might
be leaked to userspace via another read() or mmap() on same page.
What kind of data this leaked buffer can contain? Is it uninitialised
kernel memory like a freshly kmalloc'ed chunk would have? Or is it private
data of some user process?
Yes, the page may be uninitialized, and might contain random kernel data.
I see now, the user is obviously untrusted, but you're saying the ublk
server user space is trusted enough to see that kind of kernel data.
Sounds like a security concern, is there a precedent allowing such? Is
it what ublk normally does even without this zero copy proposal?
--
Pavel Begunkov
