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 S1754044AbbKWJiS (ORCPT <rfc822;w@1wt.eu>);
	Mon, 23 Nov 2015 04:38:18 -0500
Received: from mail-wm0-f42.google.com ([74.125.82.42]:33940 "EHLO
	mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750941AbbKWJiQ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 23 Nov 2015 04:38:16 -0500
Date: Mon, 23 Nov 2015 10:38:12 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        linux-nvdimm <linux-nvdimm@ml01.01.org>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        Will Deacon <will.deacon@arm.com>, Ingo Molnar <mingo@redhat.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] restrict /dev/mem to idle io memory ranges
Message-ID: <20151123093812.GA28212@gmail.com>
References: <20151120173133.24259.97028.stgit@dwillia2-desk3.jf.intel.com>
 <20151120201207.GH8644@n2100.arm.linux.org.uk>
 <CAPcyv4hagUwc3AJuDHvBy+YR1Khv+5uUL0HZawO9R0r-EZLVHg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPcyv4hagUwc3AJuDHvBy+YR1Khv+5uUL0HZawO9R0r-EZLVHg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Dan Williams <dan.j.williams@intel.com> wrote:

> On Fri, Nov 20, 2015 at 12:12 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Nov 20, 2015 at 09:31:33AM -0800, 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.
> >
> > I'm happy with this as long as we retain the option to disable this
> > new behaviour.
> >
> > The reason being, when developing a driver, it is _very_ useful to
> > be able to poke around in the device's (and system memory) address
> > spaces with tools like devmem2 to work out what's going on when
> > things go wrong.
> >
> > To put it another way, I think it's a good idea to disable access to
> > these regions on production systems, but for driver development, we
> > want to retain the ability to poke around in physical address space
> > in any way we so desire.
> >
> 
> Sounds ok to me, but I do think it's a good idea to default it to the
> same value as STRICT_DEVMEM.  Perhaps:
> 
> bool "Filter I/O access to /dev/mem" if EXPERT
> default STRICT_DEVMEM

Agreed, STRICT_DEVMEM=y should grandfather in this new (and very sensible) 
restriction.

Thanks,

	Ingo