[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rfc: a driver to access MSRs on i386
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
What is wrong with seek+read/write?
Main Index |
Thread Index |