MIME-Version: 1.0
In-Reply-To: <20151120201207.GH8644@n2100.arm.linux.org.uk>
References: <20151120173133.24259.97028.stgit@dwillia2-desk3.jf.intel.com>
	<20151120201207.GH8644@n2100.arm.linux.org.uk>
Date: Fri, 20 Nov 2015 12:26:13 -0800
Message-ID: <CAPcyv4hagUwc3AJuDHvBy+YR1Khv+5uUL0HZawO9R0r-EZLVHg@mail.gmail.com>
Subject: Re: [RFC PATCH] restrict /dev/mem to idle io memory ranges
From: Dan Williams <dan.j.williams@intel.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "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>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1556
Lines: 35

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

When this in do we even need IORESOURCE_EXCLUSIVE?  It's barely used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/