[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1494344803.20270.27.camel@redhat.com>
Date: Tue, 09 May 2017 11:46:43 -0400
From: Rik van Riel <riel@...hat.com>
To: zhong jiang <zhongjiang@...wei.com>
Cc: David Rientjes <rientjes@...gle.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
Andrew Morton <akpm@...ux-foundation.org>, arnd@...db.de,
hannes@...xchg.org, kirill@...temov.name,
mgorman@...hsingularity.net, hughd@...gle.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Xishi Qiu <qiuxishi@...wei.com>
Subject: Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write
mem
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.
>
> The invalid physical address means that it is used as
> io mapped. not in system ram region. /dev/mem is not
> access 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?
> >
>
> your suggestion is to let the issue along without any protection.
> just 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.
--
All rights reversed
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists