Re: rfc: a driver to access MSRs on i386

[Andrew Doran <ad%NetBSD.org@localhost>]

On Sun, Jan 24, 2010 at 06:32:32PM +0100, Marc Balmer wrote:

> While porting the xf86-video-geode X.Org driver to NetBSD I also needed 
> to implement the amdmsr(4) driver I wrote for OpenBSD.  The issue here 
> is, that xf86-video-geode needs access to several MSRs of the AMD Geode 
> LX CPU to program the graphics processor. amdmsr(4) is a driver that 
> allows you todo just this.  It is bound to this specific type of CPU, 
> whence the strange name.
>
> One problem of the driver is, that once it has matched, it allows access 
> to all MSRs, which can be a security risk (but then, it only attaches on 
> a AMD Geode LX CPU that has the graphics processor).
>
> I want to extend this on NetNSD, making this a more general and thus  
> more useable driver.  This is what I have in mind:
>
> - Rename the driver to msr(4)
> - Attach always
> - Disable access to MSRs by default
> - Integrate with kauth(9) much in the way gpio(4) does:
>  * Access to MSRs must be defined (MSR address or range, read or write 
> access) at a "low securelevel"  (of course, we don't have a securelevel, 
> but the kauht(9) equivalent thereof).  Once the "securelevel" has been 
> raised, only the defined MSRs can be accessed.
>  * It is also possible to enable access to all MSRs (wildcard), useful 
> for e.g. eval boards or general tinkering with the system.
> - Access to MSRs is via a set of ioctls()
> - A command msrctl(8) in /sbin allows the configuration of msr(4) at the 
> "low securelevel" and also to access the (configured) MSRs
>
> Comments and ideas welcome.

I would strongly prefer a way to accomplish what you want that does not
provide general purpose access to MSRs unless a big debug switch is turned
on.

What is wrong with seek+read/write?