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

[Pavel Machek]

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?

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: signature.asc
Description: Digital signature