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

[Arjan van de Ven]

On Mon, 6 Oct 2008 15:14:11 +0100
Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

> > no argument, except that the kernel doesn't do request_region() on
> > it to expect exclusivity (so the patch doesn't do anything on this
> > region)
> 
> Its on the TODO list for the vt fixes
> 
> > Now having said that, if the DRM layer does request_region on the
> > MMIO bars, we might need a flag that explicitly says "this is
> > intended for sharing with userspace" for this known case; not too
> > hard, I'll check with Dave Airlie.
> 
> DRM isn't the problem. In the DRM case the DRM can provide the
> mappings and manage them. In the non DRM case its messier but for the
> moment probably happens by luck to be ok

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)

> 
> I still think your restrictive /dev/mem model is wrong. I think it
> comes about because your /dev/mem restrictions are for multiple
> conflicting purposes.

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.

> 
> The root of that is the 'vaguely annoy root kit writers for 5 minutes'
> reasoning which erroneously leads to trying to a compile time option,
> combined some would argue with a 'screw people hacking hardware in
> userspace who should provide drivers' view.

this patch absolutely has nothing to do with rootkits; really.
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".

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/