From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754533AbdEIPqt (ORCPT ); Tue, 9 May 2017 11:46:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59890 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754123AbdEIPqs (ORCPT ); Tue, 9 May 2017 11:46:48 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1CD514E34D Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1CD514E34D Message-ID: <1494344803.20270.27.camel@redhat.com> Subject: Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem From: Rik van Riel To: zhong jiang Cc: David Rientjes , Bjorn Helgaas , Yoshinori Sato , Rich Felker , Andrew Morton , arnd@arndb.de, hannes@cmpxchg.org, kirill@shutemov.name, mgorman@techsingularity.net, hughd@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xishi Qiu Date: Tue, 09 May 2017 11:46:43 -0400 In-Reply-To: <590A91DF.8030004@huawei.com> References: <1493293775-57176-1-git-send-email-zhongjiang@huawei.com> <1493837167.20270.8.camel@redhat.com> <590A91DF.8030004@huawei.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-JjPeVIH5pRCjcTegOcOj" Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 09 May 2017 15:46:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-JjPeVIH5pRCjcTegOcOj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-05-04 at 10:28 +0800, zhong jiang wrote: > On 2017/5/4 2:46, Rik van Riel wrote: > > However, it is not as easy as simply checking the > > end against __pa(high_memory). Some systems have > > non-contiguous physical memory ranges, with gaps > > of invalid addresses in-between. >=20 > =C2=A0The invalid physical address means that it is used as > =C2=A0io mapped. not in system ram region. /dev/mem is not > =C2=A0access to them , is it right? Not necessarily. Some systems simply have large gaps in physical memory access. Their memory map may look like this: |MMMMMM|IO|MMMM|..................|MMMMMMMM| Where M is memory, IO is IO space, and the dots are simply a gap in physical address space with no valid accesses at all. > > At that point, is the complexity so much that it no > > longer makes sense to try to protect against root > > crashing the system? > >=20 >=20 > =C2=A0your suggestion is to let the issue along without any protection. > =C2=A0just root user know what they are doing. Well, root already has other ways to crash the system. Implementing validation on /dev/mem may make sense if it can be done in a simple way, but may not be worth it if it becomes too complex. --=20 All rights reversed --=-JjPeVIH5pRCjcTegOcOj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJZEeRjAAoJEM553pKExN6DmXMH/2QGr93b4ksbbP3Pn9+9FIhL ze+PSXp3QZ0bly2qjNrYyfDgD9xrmMcrUyBCC3WJW8vSQCdtFNB++wVUJDiy6kST irs2Sk75SpNI3eLiczAsyam8YG/HeeT1qvGrETSAEVPakq44iG420MH1Z3Ybwhan acPgZ5HogIVjAwCv7Lf0NZIvTty3FvtVIIuNY2AdKVp9QIVZ23yaChWYH4CjiFwG oKm7eA4sp7+NtYayaDkhVqN/zeW7qFYDbPEvJYd7yYmntCniERTcGg7rkNaFQMP5 mGuz2PQimAJeKFxlVsaAfQHtjgVkIwBbDoVRmHNsSoV5wMN5+YZI2h7ZoIdlYBo= =zwKo -----END PGP SIGNATURE----- --=-JjPeVIH5pRCjcTegOcOj--