rdmsr from userspace
Rui Paulo
rpaulo at FreeBSD.org
Sun May 18 15:47:50 UTC 2008
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.
Regards,
--
Rui Paulo
More information about the freebsd-hackers
mailing list