Date: Sun, 18 May 2008 21:15:49 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Rui Paulo <rpaulo@freebsd.org> Cc: freebsd-hackers@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: rdmsr from userspace Message-ID: <20080518181549.GZ18958@deviant.kiev.zoral.com.ua> In-Reply-To: <48304F9D.9030406@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--PUO5JmOx8Q3B5DV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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= =20 > >>>>>privilege level and thus is not permitted from userland. Maybe we=20 > >>>>>should provide something like Linux /dev/cpu/msr? > >>>>>I don't like interface of that device, I think that ioctl approach= =20 > >>>>>would be preferable in this case. > >>>>>Something like create /dev/cpuN and allow some ioctls on it:=20 > >>>>>ioctl(cpu_fd, CPU_RDMSR, arg). > >>>>>What do you think? > >>>>> > >>>>While I think this (devcpu) is good for testing and development, I=20 > >>>>prefer having a device driver to handle that specific MSR than a=20 > >>>>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 o= f=20 > >>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. >=20 > Input validation is my main concern here. Regarding to your two last=20 > points, I would prefer to have a microcode driver than a microcode=20 > 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. --PUO5JmOx8Q3B5DV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgwclUACgkQC3+MBN1Mb4jcEACdEkxr4HlQQPcam9OvnXz4CGvv vOUAoOt2qNPEMPskskz1Pb3U08S0H/uE =yqm4 -----END PGP SIGNATURE----- --PUO5JmOx8Q3B5DV1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080518181549.GZ18958>