Re: [RFC PATCH] restrict /dev/mem to idle io memory ranges

From: Kees Cook
Date: Fri Nov 20 2015 - 15:45:11 EST

On Fri, Nov 20, 2015 at 12:26 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> On Fri, Nov 20, 2015 at 12:12 PM, Russell King - ARM Linux
> <linux@xxxxxxxxxxxxxxxx> 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
> When this in do we even need IORESOURCE_EXCLUSIVE? It's barely used.

Let's leave it for now to give us the debugging granularity Russell
mentioned. If it turns out it's never used, we can drop it in the


Kees Cook
Chrome OS Security
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at