linux-kernel - Re: [PATCH 4.19 053/105] mm/mincore.c: make mincore() more conservative

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190523091822.GA18121@ip-172-31-14-16>
Date:   Thu, 23 May 2019 09:18:22 +0000
From:   Kevin Easton <kevin@...rana.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Pavel Machek <pavel@...x.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jiri Kosina <jkosina@...e.cz>,
        Vlastimil Babka <vbabka@...e.cz>,
        Josh Snyder <joshs@...flix.com>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Chinner <david@...morbit.com>,
        Matthew Wilcox <willy@...radead.org>,
        Cyril Hrubis <chrubis@...e.cz>, Tejun Heo <tj@...nel.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Daniel Gruss <daniel@...ss.cc>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dominique Martinet <asmadeus@...ewreck.org>
Subject: Re: [PATCH 4.19 053/105] mm/mincore.c: make mincore() more
 conservative

On Wed, May 22, 2019 at 11:21:11AM +0200, Michal Hocko wrote:
> On Wed 22-05-19 10:57:41, Pavel Machek wrote:
> > Hi!
> > 
> > > commit 134fca9063ad4851de767d1768180e5dede9a881 upstream.
> > > 
> > > The semantics of what mincore() considers to be resident is not
> > > completely clear, but Linux has always (since 2.3.52, which is when
> > > mincore() was initially done) treated it as "page is available in page
> > > cache".
> > > 
> > > That's potentially a problem, as that [in]directly exposes
> > > meta-information about pagecache / memory mapping state even about
> > > memory not strictly belonging to the process executing the syscall,
> > > opening possibilities for sidechannel attacks.
> > > 
> > > Change the semantics of mincore() so that it only reveals pagecache
> > > information for non-anonymous mappings that belog to files that the
> > > calling process could (if it tried to) successfully open for writing;
> > > otherwise we'd be including shared non-exclusive mappings, which
> > > 
> > >  - is the sidechannel
> > > 
> > >  - is not the usecase for mincore(), as that's primarily used for data,
> > >    not (shared) text
> > 
> > ...
> > 
> > > @@ -189,8 +205,13 @@ static long do_mincore(unsigned long add
> > >  	vma = find_vma(current->mm, addr);
> > >  	if (!vma || addr < vma->vm_start)
> > >  		return -ENOMEM;
> > > -	mincore_walk.mm = vma->vm_mm;
> > >  	end = min(vma->vm_end, addr + (pages << PAGE_SHIFT));
> > > +	if (!can_do_mincore(vma)) {
> > > +		unsigned long pages = DIV_ROUND_UP(end - addr, PAGE_SIZE);
> > > +		memset(vec, 1, pages);
> > > +		return pages;
> > > +	}
> > > +	mincore_walk.mm = vma->vm_mm;
> > >  	err = walk_page_range(addr, end, &mincore_walk);
> > 
> > We normally return errors when we deny permissions; but this one just
> > returns success and wrong data.
> > 
> > Could we return -EPERM there? If not, should it at least get a
> > comment?
> 
> This was a deliberate decision AFAIR. We cannot return failure because
> this could lead to an unexpected userspace failure. We are pretendeing
> that those pages are present because that is the safest option -
> e.g. consider an application which tries to refault until the page is
> present...

Yes, in particular several userspace applications I found used mincore()
to find out whether a particular range is mapped at all or not, treating
any error as "unmapped" and any non-error return as "mapped".

    - Kevin