From owner-freebsd-current@freebsd.org Wed Jan 3 01:12:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 913C4E8A356 for ; Wed, 3 Jan 2018 01:12:01 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67E9D7C64F for ; Wed, 3 Jan 2018 01:12:01 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WXb4ezcPTS7BpWXb6eNok1; Tue, 02 Jan 2018 18:12:00 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=zxA2vyXaAAAA:8 a=D19gQVrFAAAA:8 a=HoJSghi9AAAA:8 a=6I5d2MoRAAAA:8 a=1GLJFC1j3x44-mMT14YA:9 a=QEXdDO2ut3YA:10 a=nK2txNHJmq7TfjpuLlwI:22 a=W4TVW4IDbPiebHqcZpNg:22 a=LeoNfjWMn6diZIv87PBK:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [10.168.3.109] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 81E25371; Tue, 2 Jan 2018 17:11:58 -0800 (PST) Date: Tue, 02 Jan 2018 17:11:54 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <5787e63c-9a88-c807-c132-572e8454a4d0@protected-networks.net> References: <20180103001949.6AF4F2C9@spqr.komquats.com> <5787e63c-9a88-c807-c132-572e8454a4d0@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Michael Butler , Cy Schubert , Warner Losh CC: FreeBSD Current From: Cy Schubert Message-ID: <227070B7-561C-420E-BE0B-F75DD3D4D6EE@cschubert.com> X-CMAE-Envelope: MS4wfEaww4TNgu/cO1yMy1VRkodCUzpP1e9xM9re0vmoLODXtSuZDtvXISmzgNjppPf38KcUXvN658F14biebGVs5rgwRx3/UUgwiSjQOhzNqnkaDIRaIn5W U6K6Pejb0d2nR7AzZOS0blb5BFxQsnXFrodxgfx8jwRL9yvj0+5oXVexqz7qcghMvJJXhKEZApjxxpRfolav6vpSfqSqXMWolaw3gOk/STgYt4ppp4x/+aFd LHQfciRvMVRQa9i8mKQ/g2nwle51BqR01ubZBcc102U= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Wed, 03 Jan 2018 01:12:01 -0000 On January 2, 2018 4:56:48 PM PST, Michael Butler wrote: >On 01/02/18 19:20, Cy Schubert wrote: >> This Linux commit gives us a hint=2E >>=20 >> https://lkml=2Eorg/lkml/2017/12//27/2 > >Sadly, the articles I've read to date make no mention of which Intel >silicon revs are vulnerable=2E However, the use of the PCID feature, >which >is only available on more recent CPUs, does seem to afford a slightly >lesser performance hit when completely splitting the kernel and user >address space mappings :-( > > imb Yes=2E You can see if your cpu supports pcid using cpuinfo from ports=2E Then loo= k at input line 0x07 in the hexdump=2E Bit 0x0a of rbx will indicate if in= vpcid is available=2E We simply need to manipulate a copy of cr3 and reload= it=2E My amd gear in my basement isn't affected but my laptop is=2E It supports = pcid but not invpcid=2E There will be a performance hit=2E Looking at the Linux patch, looks like = the workaround is optional=2E I would suspect not through a sysctl, that wo= uld be silly=2E --- Cy Schubert or -- small keyboard in use, apologies for typos and autocorrect --