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 S1163351AbbKTUCx (ORCPT <rfc822;w@1wt.eu>);
	Fri, 20 Nov 2015 15:02:53 -0500
Received: from mout.kundenserver.de ([212.227.17.24]:52965 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1162910AbbKTUCv (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 20 Nov 2015 15:02:51 -0500
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Dan Williams <dan.j.williams@intel.com>, linux-kernel@vger.kernel.org,
        Russell King <linux@arm.linux.org.uk>,
        Kees Cook <keescook@chromium.org>, linux-nvdimm@ml01.01.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        Will Deacon <will.deacon@arm.com>, Ingo Molnar <mingo@redhat.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH] restrict /dev/mem to idle io memory ranges
Date: Fri, 20 Nov 2015 21:00:29 +0100
Message-ID: <4325714.tYNkapC69P@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <20151120173133.24259.97028.stgit@dwillia2-desk3.jf.intel.com>
References: <20151120173133.24259.97028.stgit@dwillia2-desk3.jf.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:TRUmSvmHiWGw1IHkeEJRHiKJnhopynJIm+FEDu5B4r+w+u8bzrs
 TAj0JdMbD9n7+yrnOz2RpeYV1snc/s56dDHUk8Ni4zZOYcXzeNhTxEyahVVEoiubbzjYDoC
 ksO1lQJ3/wsvFR95ahWWlfcpx1n45lQKd0DG35XGjzOjco9nIz3Zj9Xx46ppH9azwg2aY+C
 +znJqRdfJPg+R34vtlojQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:nfRpM14lmak=:mJjow6w33I5MobcjzrvC54
 vvhbtjaEgWs3fI+DspsfvwHUh28vu6lrpbzomL/Crix9JjSRy+pG/I7x4qySNZjxl6lRFnk1b
 1zniddAAANljzc5aHkTxGUemTP7zMi/0V6hVXrDZhtPT97DhEzd7urBBTs+45bk8YImjUXm26
 1vOT+ZLyRN+KC/QCaQBOpEV1UxNF03YjURHuCHl2cp7RqfQT9/7erpa4A0iZmS9OFo9DXGWdN
 Ew8MB9RPk6vA50vDxW4KIJssklp/nmNTMiwqLjQz7YBespJIufXX4aUqm271ty02RpTl+Gto1
 R6QxX593zffiHMY3ShQ1fPFdGKfEvXkj1vAfMgcEdbPmFAXatBsYB0Yx4qTyr0C5Oc6cd9mqB
 dEC6ldJVaMbe6/hH246bhWngNmli6fhsoeEMz6lgcktrDb8p8lnzqSe3x+UCAbKLZ+Nm3WKIL
 /cro6HB9yG2RQMRtEUUkRjhvNEYIXBFU4NJz0ijoaUSSa1PRJS8gjnYw+vZQpiCXeKTnIzba+
 9VR8mna9oQjLMUaw6MunFxs5Nk6iaSLZYXgfULejJRhr4bk0KBTrQtWl69eFSAEmwCUowiSJm
 Ysc8KxojP987lxYou051AK6jqom0cQBwx3kNfHtPMmyeUo5h6glerwvHGEussXyNEIwTkjSsX
 KiMvmW0JxxjGXLJZsYa2LNa9rrA5hAmqhYCHsxjbD36NhbFVpLS5NhvYo9Kk1XAmVXCKftSOj
 gdvrMRzN5Bs9oZBw
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Friday 20 November 2015 09:31:33 Dan Williams wrote:
> This effectively promotes IORESOURCE_BUSY to IORESOURCE_EXCLUSIVE
> semantics by default.  If userspace really believes it is safe to access
> the memory region it can also perform the extra step of disabling an
> active driver.  This protects device address ranges with read side
> effects and otherwise directs userspace to use the driver.
> 
> Persistent memory presents a large "mistake surface" to /dev/mem as now
> accidental writes can corrupt a filesystem.
> 
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> 

I like the idea.

Maybe split the change up into two patches, where the first one
just does the trivial move of the Kconfig option, and the second
one that changes behavior is small?

There is also a question of whether we actually need two options
or if we can safely make the existing option stricter.

	Arnd