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]

Message-Id: <20151124142521.e6d23e44a8b2c24c044c2dec@linux-foundation.org>
Date:	Tue, 24 Nov 2015 14:25:21 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	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
Subject: Re: [PATCH v2 2/2] restrict /dev/mem to idle io memory ranges

On Mon, 23 Nov 2015 16:06:04 -0800 Dan Williams <dan.j.williams@...el.com> 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 don't think I'm sufficiently understanding what this is all needed
for, sorry.  A better changelog would help: what's wrong with the
current code, how you propose it be changed, how the kernel's
externally-visible behaviour is altered, etc.

Please pay particular attention to the back-compatibility issues which
will be encountered when people enable these options.

Perhaps when all that material is described, I'll understand why the
heck we're doing this with a build-time switch rather than a runtime
one...

> Persistent memory presents a large "mistake surface" to /dev/mem as now
> accidental writes can corrupt a filesystem.

Is that the motivation?  root can come in and accidentally alter
persistent memory contents?  If so, 

- why do we care?  There are all sorts of ways in which root can muck
  up the persistent memory, starting with dd(1).  What's special about
  /dev/mem?

- why is the patch mucking with access to PCI and BIOS space?  Is the
  persistent memory even mappable in those regions?  Or is the concern
  that userspace can access control registers associated with the
  persistent memory?  What is the problem scenario?


IOW, a very good description of the problem-being-solved would help out
a lot here...

--
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/