Date: Sun, 18 May 2008 12:47:07 -0700 From: Suleiman Souhlal <ssouhlal@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Rui Paulo <rpaulo@freebsd.org>, Andriy Gapon <avg@icyb.net.ua> Subject: Re: rdmsr from userspace Message-ID: <821D2BD4-4C79-49B6-ADD9-2C5EA16B852A@FreeBSD.org> In-Reply-To: <20080518181549.GZ18958@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> <48304F9D.9030406@FreeBSD.org> <20080518181549.GZ18958@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 18, 2008, at 11:15 AM, Kostik Belousov wrote: > 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 For what it's worth, CPUID is not a privileged instruction, so this doesn't need to be done in the kernel (as long as you have a way to pin a userland thread to a cpu, which I believe we have, now). I would personally would *really* to see stas's driver committed as well, as it's really useful. (I had a similar driver (but only for MSRs) that I was about to commit to 7.0 a few months ago, but re@ asked that I add a manpage, and I never got around to doing it: http://people.freebsd.org/~ssouhlal/testing/msr-20070707.diff It's slightly different from devcpu in that it works with lseek + read/write instead of ioctl). -- Suleiman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?821D2BD4-4C79-49B6-ADD9-2C5EA16B852A>