Date: Sun, 18 May 2008 16:47:41 +0100 From: Rui Paulo <rpaulo@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: rdmsr from userspace Message-ID: <48304F9D.9030406@FreeBSD.org> In-Reply-To: <20080517175312.GM18958@deviant.kiev.zoral.com.ua> References: <482E93C0.4070802@icyb.net.ua> <482EFBA0.30107@FreeBSD.org> <482F1191.70709@icyb.net.ua> <482F1529.5080409@FreeBSD.org> <20080517175312.GM18958@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48304F9D.9030406>