tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rfc: a driver to access MSRs on i386

Am 25.01.10 22:50, schrieb Andrew Doran:
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

that is what this driver does. amdmsr(4) is very specific to a certain CPU type. msr(4) as described.

why a debug switch? this is for production systems. X.Org needs it for AMD Geode LX CPUs

What is wrong with seek+read/write?

seek+read/write?? what do you mean with that? the linux drivers approach? what would that change? the ioctl() approach is cleaner.

Home | Main Index | Thread Index | Old Index