On Jan 10, 2019, at 8:04 PM, Dave Chinner [off-list ref] wrote:

quoted

On Thu, Jan 10, 2019 at 06:18:16PM -0800, Linus Torvalds wrote:

quoted

On Thu, Jan 10, 2019 at 6:03 PM Dave Chinner [off-list ref] wrote:

quoted

On Thu, Jan 10, 2019 at 02:11:01PM -0800, Linus Torvalds wrote:
And we *can* do sane things about RWF_NOWAIT. For example, we could
start async IO on RWF_NOWAIT, and suddenly it would go from "probe the
page cache" to "probe and fill", and be much harder to use as an
attack vector..

We can only do that if the application submits the read via AIO and
has an async IO completion reporting mechanism.

Oh, no, you misunderstand.

RWF_NOWAIT has a lot of situations where it will potentially return
early (the DAX and direct IO ones have their own), but I was thinking
of the one in generic_file_buffered_read(), which triggers when you
don't find a page mapping. That looks like the obvious "probe page
cache" case.

But we could literally move that test down just a few lines. Let it
start read-ahead.

.. and then it will actually trigger on the *second* case instead, where we have

               if (!PageUptodate(page)) {
                       if (iocb->ki_flags & IOCB_NOWAIT) {
                               put_page(page);
                               goto would_block;
                       }

and that's where RWF_MNOWAIT would act.

It would still return EAGAIN.

But it would have started filling the page cache. So now the act of
probing would fill the page cache, and the attacker would be left high
and dry - the fact that the page cache now exists is because of the
attack, not because of whatever it was trying to measure.

See?

Except for fadvise(POSIX_FADV_RANDOM) which triggers this code in
page_cache_sync_readahead():

       /* be dumb */
       if (filp && (filp->f_mode & FMODE_RANDOM)) {
               force_page_cache_readahead(mapping, filp, offset, req_size);
               return;
       }

So it will only read the single page we tried to access and won't
perturb the rest of the message encoded into subsequent pages in
file.

There are two types of attacks.  One is an intentional side channel where two cooperating processes communicate. This is, under some circumstances, a problem, but it’s not one we’re about to solve in general. The other is an attacker monitoring an unwilling process. I think we care a lot more about that, and Linus’ idea will help.