From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged Date: Thu, 10 Jan 2019 06:50:20 -0800 Message-ID: <20190110145020.GW6310@bombadil.infradead.org> References: <20190108044336.GB27534@dastard> <20190109022430.GE27534@dastard> <20190109043906.GF27534@dastard> <20190110004424.GH27534@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190110004424.GH27534@dastard> Sender: linux-kernel-owner@vger.kernel.org To: Dave Chinner Cc: Linus Torvalds , Jiri Kosina , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API List-Id: linux-api@vger.kernel.org On Thu, Jan 10, 2019 at 11:44:24AM +1100, Dave Chinner wrote: > And, really, this would be just another band-aid over a symptom of > the information leak - it doesn't prevent users from being able to > control page cache invalidation. It just removes one method, just > like hacking mincore only removes one method of observing the page > cache. And, like mincore(), there's every chance it impacts on > userspace in a negative manner and so we need to be very careful > here. Putting the mincore() / cache timing information leak aside though, the current behaviour of XFS means that an attacker can screw up the performance of random applications just by repeatedly doing O_DIRECT reads of libc.so. Maybe O_DIRECT reads should be forbidden from files on XFS unless you also have write access to them? (eg owner).