From owner-freebsd-current@FreeBSD.ORG Sun Jun 15 19:28:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4691C1065670 for ; Sun, 15 Jun 2008 19:28:51 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id D4BC48FC17 for ; Sun, 15 Jun 2008 19:28:50 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA08.westchester.pa.mail.comcast.net with comcast id eHBa1Z00E0QuhwU5808200; Sun, 15 Jun 2008 19:28:49 +0000 Received: from mail.cokane.org ([24.60.133.163]) by OMTA02.westchester.pa.mail.comcast.net with comcast id eKUp1Z0043Xh0XL3NKUpwa; Sun, 15 Jun 2008 19:28:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=s8X_vqkLaPIA:10 a=fHXOHqj8bjYA:10 a=F-Y6h51ZAAAA:8 a=QEWukttbLcHj2cL-j1gA:9 a=KtkOjNPflsNQnrEXStoA:7 a=qs6qeCx_UhHVTtpl_8E7vHDSijwA:4 a=OxEx4ZASVOIA:10 a=LY0hPdMaydYA:10 a=Xy_DcEZCVNQGTW6-w-0A:9 a=yOe5c3L0g2HXTLIfLXEJp1qF2MkA:4 a=rPt6xJ-oxjAA:10 Received: by mail.cokane.org (Postfix, from userid 103) id 33B4835A7D5; Sun, 15 Jun 2008 15:28:49 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cokane.org (Postfix) with ESMTP id 4703D35A7D4; Sun, 15 Jun 2008 15:28:33 -0400 (EDT) From: Coleman Kane To: Stanislav Sedov In-Reply-To: <20080615230250.7f3efae4.stas@FreeBSD.org> References: <20080606020927.8d6675e1.stas@FreeBSD.org> <10261.1212703949@critter.freebsd.dk> <20080606025533.8322ee08.stas@FreeBSD.org> <1212758604.1904.33.camel@localhost> <20080615230250.7f3efae4.stas@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9AWGgl6Mt8h4oK4E0sZM" Organization: FreeBSD Project Date: Sun, 15 Jun 2008 15:26:39 -0400 Message-Id: <1213557999.1816.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port Cc: Rui Paulo , Poul-Henning Kamp , kib@FreeBSD.org, current@FreeBSD.org, Peter Jeremy Subject: Re: cpuctl(formely devcpu) patch test request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2008 19:28:51 -0000 --=-9AWGgl6Mt8h4oK4E0sZM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-06-15 at 23:02 +0400, Stanislav Sedov wrote: > On Fri, 06 Jun 2008 09:23:24 -0400 > Coleman Kane mentioned: >=20 > > What about using the API in priv(9) or similar, such as is done in the > > mlock(2)/munlock(2) code in sys/vm/vm_mmap.c ? > >=20 >=20 > This is really a good idea. I've added a bunch of priv checks to cpuctl > code, namely PRIV_CPUCTL_RDMSR, PRIV_CPUCTL_WRMSR and PRIV_CPUCTL_UPDATE. > Names are self-describing. CPUID ioctl doesn't need that check as this > operation are entirely safe and doesn't disclose any sensitive informatio= n. > In fact it might be even performed from userland if one will find a way > to bind the process to a specific cpu. >=20 >=20 > On Fri, 6 Jun 2008 09:14:13 +1000 > Peter Jeremy mentioned: >=20 > > ENOSYS generally means "system call not implemented". You need a respo= nse > > implying that the requested operation isn't supported on the hardware. > > IMHO, ENODEV comes closest to that. > > >=20 > Yeah, it seems that ENODEV is a better choice. > =20 > > I also agree with phk@ that serious thought needs to be given to the > > foot-shooting capability offered by this patch before it is implemented= . > > Maybe add a sysctl to enable the write (at least) functionality - eg > > hw.cpuctl.wrmsr_enable and hw.cpuctl.update_enable (both defaulting to > > disabled). This at least adds a safety catch. I'm not sure if RDMSR > > is dangerous - if so, possibly there should be an enable for it as well= . >=20 > I don't think that extra anti foot-shooting checks are needed: you can't > easily fire up your system via ioctl(2) interface. At least, a little > programming exercise is required. What's regarding microcode updates -=20 > there's a lot of checks if the microcode image valid in update utility, > also the cpu itself checks the microcode CRC before applying update. I think the anti-foot-shooting measures referred to above were also taking into consideration for security reasons. It might be valuable for someone to be able to configure this feature to be rdmsr-only, thereby limiting potential harm vectors in the event that an attacker is likely to crack access to the system for supervisory privileges. This would be a legitimate consideration to make, especially so that the module could at least provide a sane "safe operating mode" to those that would benefit from read-only access. So, for example, I would consider most crackers to be skilled enough to inject an ioctl call somewhere, even if the primary user of the system is not so skilled., but they want to use software written by others that makes use of this interface. >=20 > The latest version of the patch against recent HEAD is available at > ftp://ftp.SpringDaemons.com/dustheap/cpuctl.3.diff >=20 > Thanks! >=20 --=20 Coleman Kane --=-9AWGgl6Mt8h4oK4E0sZM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhVbOsACgkQcMSxQcXat5fDkQCfZ2kkzL7POnBUz4L07tVTEAzL rPcAn1w5BpodYPEYXdNMp9rMj+V45qMO =UZBd -----END PGP SIGNATURE----- --=-9AWGgl6Mt8h4oK4E0sZM--