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

[Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>]

> 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 still think your restrictive /dev/mem model is wrong. I think it comes
about because your /dev/mem restrictions are for multiple conflicting
purposes.

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.

Now the root kit writer one has minimal credence now as it seems the root
kit writers already adapted. The hardware hacking people have uio
frameworks and should yes be encouraged to use proper drivers.

So there isn't a real reason to make it compile time. Far saner would be
for the /dev/mem restrictions to be flags in sysfs. Even if you stick to
the view about making life harder for rootkit authors then it should be
sysfs restrictions with an irrevocability bit (eg 0 = off 1 = on , 2 = on
(forever))

A flag per feature of this kind then lets you set the different policies
including the highly useful '/dev/mem, I don't think so' policy flag for
server boxes.
--
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/