From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 18:16:05 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6D0106566C; Sun, 18 May 2008 18:16:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id CB2CE8FC0A; Sun, 18 May 2008 18:16:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JxnQR-000BxE-D3; Sun, 18 May 2008 21:16:03 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4IIFpUF025605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 May 2008 21:15:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4IIFnEW090884; Sun, 18 May 2008 21:15:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4IIFnDT090883; Sun, 18 May 2008 21:15:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 May 2008 21:15:49 +0300 From: Kostik Belousov To: Rui Paulo Message-ID: <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PUO5JmOx8Q3B5DV1" Content-Disposition: inline In-Reply-To: <48304F9D.9030406@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: b565934a9b6505813531773f2f5625c7 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2835 [May 13 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: rdmsr from userspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 18:16:05 -0000 --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--