linux-kernel - Re: [PATCH v2 2/2] restrict /dev/mem to idle io memory ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Nov 2015 10:54:08 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arch@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	Kees Cook <keescook@...omium.org>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/2] restrict /dev/mem to idle io memory ranges

On Tue, Nov 24, 2015 at 5:28 PM, Dan Williams <dan.j.williams@...el.com> wrote:
> On Tue, Nov 24, 2015 at 4:47 PM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
>> On Tue, 24 Nov 2015 16:34:19 -0800 Dan Williams <dan.j.williams@...el.com> wrote:
>>
>>> > IOW, a very good description of the problem-being-solved would help out
>>> > a lot here...
>>>
>>> I'll fold the eventual result of this discussion into the changelog if
>>> I can convince you it's worth moving forward.
>>
>> I'm easily convinced ;) Please let's get all the info into the right
>> place, make sure it answers the thus-far-asked questions (at least) and
>> we'll take it from there.
>>
>> And please do have a think about switching as much as possible over to
>> runtime-configurability.  Because "please echo foo > /proc" is a heck
>> of a lot nicer than "please reboot with iomem=" which is a heck of a lot
>> nicer than "please ask vendor for a new kernel".
>
> Actually, we already have runtime configuration.  For example, if you
> want to muck with pmem via /dev/mem, just do this first:
>
>     echo namespace0.0 > /sys/bus/nd/drivers/nd_pmem/unbind

Here's the summary of the thread that I will add to the changelog:

---

In general if a device driver is busily using a memory region it
already informs other parts of the kernel to not touch it via
request_mem_region().  /dev/mem should honor the same safety
restriction by default.  Debugging a device driver from userspace
becomes more
difficult with this enabled.  Any application using /dev/mem or mmap
of sysfs pci resources will now need to perform the extra step of
either:

1/ Disabling the driver, for example:

  echo <device id> > /dev/bus/<parent bus>/drivers/<driver name>/unbind

2/ Rebooting with "iomem=relaxed" on the command line

3/ Recompiling with CONFIG_IO_STRICT_DEVMEM=n

Traditional users of /dev/mem like dosemu are unaffected because the
first 1MB of memory is not subject to the IO_STRICT_DEVMEM
restriction.
Legacy X configurations use /dev/mem to talk to graphics hardware, but
that functionality has since moved to kernel graphics drivers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/