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?
