From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751470AbdEJCPw (ORCPT <rfc822;w@1wt.eu>);
        Tue, 9 May 2017 22:15:52 -0400
Received: from szxga03-in.huawei.com ([45.249.212.189]:5935 "EHLO
        szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751118AbdEJCPt (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 9 May 2017 22:15:49 -0400
Message-ID: <591277AE.80908@huawei.com>
Date: Wed, 10 May 2017 10:15:10 +0800
From: Xishi Qiu <qiuxishi@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Rik van Riel <riel@redhat.com>
CC: zhong jiang <zhongjiang@huawei.com>,
        David Rientjes <rientjes@google.com>,
        Bjorn Helgaas <bhelgaas@google.com>,
        Yoshinori Sato <ysato@users.sourceforge.jp>,
        Rich Felker <dalias@libc.org>,
        Andrew Morton <akpm@linux-foundation.org>, <arnd@arndb.de>,
        <hannes@cmpxchg.org>, <kirill@shutemov.name>,
        <mgorman@techsingularity.net>, <hughd@google.com>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write
 mem
References: <1493293775-57176-1-git-send-email-zhongjiang@huawei.com>   <alpine.DEB.2.10.1705021350510.116499@chino.kir.corp.google.com>  <1493837167.20270.8.camel@redhat.com> <590A91DF.8030004@huawei.com> <1494344803.20270.27.camel@redhat.com>
In-Reply-To: <1494344803.20270.27.camel@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.25.179]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A090205.591277BD.00AE,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2014-11-16 11:51:01,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 30990fa4a53bbb90ffa765342b414b0a
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2017/5/9 23:46, Rik van Riel wrote:

> 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.
>

Hi Rik,

Do you mean IO space is allowed to access from mmap /dev/mem?

Thanks,
Xishi Qiu

 
>>> 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.
>