linux-kernel - Re: RFC: banning device driver reserved resources from /dev/mem

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: <20081006153825.66e50770@lxorguk.ukuu.org.uk>
Date:	Mon, 6 Oct 2008 15:38:25 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: RFC: banning device driver reserved resources from /dev/mem

> I'll add a "share resource with userland" option to allow us to make
> this desire explicit for the cases we want this (and can tolerate
> concurrent accesses)

For debug tools that would be almost all drivers, and for distribution
use that needs to be a runtime selection.

For the non share-resource-with case what occurs if /dev/mem is active
when the driver is loaded ?

> for me it is a goal to have /dev/mem do as little as possible while
> allowing the "normal" uses. This is to help SELinux to have sane policy
> rather than "X still has perms to own the whole box" etc.

Then it should be runtime configurable

> it came out of chasing e1000e with the "eh who maps our e1000e bar from
> userspace" scare. Followed by thinking "if the driver requests
> exclusivity the kernel should try to grant that".

Only if you can then configure that *policy* decision at runtime in user
space. Otherwise you create shackles that simply harm debug work and make
it harder for distributions to ship the feature enabled by default (which
is the ideal case).

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