rdmsr from userspace

[Kostik Belousov]

On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote:
> Kostik Belousov wrote:
> >On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
> >>Andriy Gapon wrote:
> >>>on 17/05/2008 18:37 Rui Paulo said the following:
> >>>>Andriy Gapon wrote:
> >>>>>It seems that rdmsr instruction can be executed only at the highest 
> >>>>>privilege level and thus is not permitted from userland. Maybe we 
> >>>>>should provide something like Linux /dev/cpu/msr?
> >>>>>I don't like interface of that device, I think that ioctl approach 
> >>>>>would be preferable in this case.
> >>>>>Something like create /dev/cpuN and allow some ioctls on it: 
> >>>>>ioctl(cpu_fd, CPU_RDMSR, arg).
> >>>>>What do you think?
> >>>>>
> >>>>While I think this (devcpu) is good for testing and development, I 
> >>>>prefer having a device driver to handle that specific MSR than a 
> >>>>generic /dev/cpuN where you can issue MSRs.
> >>>>Both for security and reliability reasons.
> >>>What about /dev/pci, /dev/io? Aren't they a precedent?
> >>They are, but, IMHO, we should no longer continue to create this type of 
> >>interfaces.
> >
> >Why ? Are developers some kind of the second-class users ?
> >
> >I would have no opinion on providing /dev/cpu by the loadable module, not
> >compiled into GENERIC. But the interface itself is useful at least for
> >three things:
> >- CPU identification (see x86info or whatever it is called);
> >- CPU tweaking for bugs workaround without patching the kernel;
> >- updating the CPU microcode.
> >None of these is limited to the developers only.
> 
> Input validation is my main concern here. Regarding to your two last 
> points, I would prefer to have a microcode driver than a microcode 
> userland utility that relies on devcpu.
Did you looked at the code ? It does exactly what you described.

Driver has four basic operations:
read/write msr
perform cpu id work
update microcode.

The later is done as a whole operation, with the microcode blob supplied
by the userspace.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080518/fd283f39/attachment.pgp