Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp224129ybm; Wed, 22 May 2019 02:00:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqziTeH8DWPedWnSODAjZKDuxfrUsa+GkWzJC5zXze0JW2pF6vM1zytvJnXvCbfDjxjwEd/7 X-Received: by 2002:a17:902:24c7:: with SMTP id l7mr39453302plg.192.1558515610121; Wed, 22 May 2019 02:00:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558515610; cv=none; d=google.com; s=arc-20160816; b=iUxd7I1Do4BeVsBR35m9+llKq09YOsy7LST35cYskhVTs0DvsgQ6cYcHKJ1Tc0cqa9 CkunfYAEeSowKdeOyIMhk3sBH4CUd95ezwq2qLK+xjHB0XthKvIN1QF0X9jWSEU8fRxD i4R88MbyUFjEg1Pl9TrydsBpnd6CPBTbNkbRNArANmpxKQrqhQr6lodlvVoge9pdN7Fm PDjgppjaY/aMuTd2h/b09CAIOoopDMTM2ZzPqMnaeQzqPDlh0Kin7E0jvhvID0+HJ6Hn S8JfEcPNhAS7KmPCFbN+WYMgdhK1CqfCP0Oh8c4xuuDQwiIXDMZG9/SUVEnSsRp2R919 viAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=k1z0Lnhw3rAFJVSTehuWsHwhBKuWSFVYHjfaZOc7IM0=; b=CyB/PrgHGCiuQdV/bqFw2gQKLwRzceyqaTOlDFnmlalcvi1kPqY8+MiIwQo++zkovV bJKbzZMpW8kisXNKNjfWL5UMH4eELsYqYJ20M2GQbDdpu59eZO/iejjzyt8sgzz5QML3 aXLP8VmPoHTZdvYMwEEahnH3Vg1a6UgbQjFIHOf435Pwafybt+YXOX34PRwCgjvhKv8b UehjpqKeKybtoJdS8zvUJf9mQ5ZzeCg0rqXFsmzwr80JDBDRC1bx02mUX/17jAb3wqHN iXVUBJoPfioziXnEw8ZJ6mAAy2HZOSCdcdKt+lzYIH81Om+c6XLyRIElGYwq8CPUjg73 o+vg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si17370419pgs.285.2019.05.22.01.59.55; Wed, 22 May 2019 02:00:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728725AbfEVI5o (ORCPT + 99 others); Wed, 22 May 2019 04:57:44 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:42197 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727796AbfEVI5o (ORCPT ); Wed, 22 May 2019 04:57:44 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 32B6D8036B; Wed, 22 May 2019 10:57:32 +0200 (CEST) Date: Wed, 22 May 2019 10:57:41 +0200 From: Pavel Machek To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jiri Kosina , Vlastimil Babka , Josh Snyder , Michal Hocko , Andy Lutomirski , Dave Chinner , Kevin Easton , Matthew Wilcox , Cyril Hrubis , Tejun Heo , "Kirill A. Shutemov" , Daniel Gruss , Andrew Morton , Linus Torvalds , Dominique Martinet Subject: Re: [PATCH 4.19 053/105] mm/mincore.c: make mincore() more conservative Message-ID: <20190522085741.GB8174@amd> References: <20190520115247.060821231@linuxfoundation.org> <20190520115250.721190520@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <20190520115250.721190520@linuxfoundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > commit 134fca9063ad4851de767d1768180e5dede9a881 upstream. >=20 > 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". >=20 > 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. >=20 > 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 >=20 > - is the sidechannel >=20 > - is not the usecase for mincore(), as that's primarily used for data, > not (shared) text =2E.. > @@ -189,8 +205,13 @@ static long do_mincore(unsigned long add > vma =3D find_vma(current->mm, addr); > if (!vma || addr < vma->vm_start) > return -ENOMEM; > - mincore_walk.mm =3D vma->vm_mm; > end =3D min(vma->vm_end, addr + (pages << PAGE_SHIFT)); > + if (!can_do_mincore(vma)) { > + unsigned long pages =3D DIV_ROUND_UP(end - addr, PAGE_SIZE); > + memset(vec, 1, pages); > + return pages; > + } > + mincore_walk.mm =3D vma->vm_mm; > err =3D 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 --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlzlDwUACgkQMOfwapXb+vJ7DgCgoJghRiZhuM2meVZZe3AI4324 /AQAniFOm3l9roHXffisa47JlKVApofW =OIIc -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a--