From owner-freebsd-security@freebsd.org Fri Jan 5 19:17:50 2018 Return-Path: Delivered-To: freebsd-security@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 D8CBFEBAD87 for ; Fri, 5 Jan 2018 19:17:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (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 AFB6A78FEE for ; Fri, 5 Jan 2018 19:17:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id XXUyeEy0kS7BpXXUzeXYtg; Fri, 05 Jan 2018 12:17:49 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=Kt-rIzu-m2MUlLpCDwcA:9 a=bMKrX4mhllEezhu-:21 a=voBcHpuCykQ4YtwT:21 a=CjuIK1q_8ugA:10 a=WMYLbQpIgYqX9OSb0ygA:9 a=b1KAiWStALnyaQGC:21 a=ohZIoiNbPYEWRb7s:21 a=6C0gAyBXFrrH8m29:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [10.168.3.146] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id EC625365; Fri, 5 Jan 2018 11:17:47 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel hardware bug Date: Fri, 5 Jan 2018 11:17:52 -0800 To: Eric McCorkle , "freebsd-security@freebsd.org" Message-Id: <20180105191747.EC625365@spqr.komquats.com> X-CMAE-Envelope: MS4wfGhzU5jB4p6aaBICJEOQzVtRRN/s0Vm/43K0Bh6oFyGk/MDk1TqMvsS/caYh2tro5Aqwc5b+vQHGW2xVGD8m/n3Lrfp39bP24JpAoWY9b549FBtev7Oz 8qoW4lAE6u7ZD08BJ2iLfeAUPhxer++j2ff9oR6Gg88a2ahLPFt1Z/vAWGGFHr8EbxpJXahpOeLRa5mzTr7W98FmXVU9N+a0K+0= X-Mailman-Approved-At: Fri, 05 Jan 2018 19:49:04 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 19:17:50 -0000 SPARC definitely does out of order execution. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Eric McCorkle Sent: 05/01/2018 10:45 To: freebsd-security@freebsd.org Subject: Re: Intel hardware bug On 01/05/2018 11:40, Nathan Whitehorn wrote: > POWER has the same thing. It's actually stronger separation, since user > processes don't share addresses either -- all processes, including the > kernel, have windowed access to an 80-bit address space, so no process > can even describe an address in another process's address space. There > are ways, of course, in which IBM could have messed up the > implementation, so the fact that it *should* be secure does not mean it > *is*. That's interesting, as it conflicts with Red Hat's vulnerability disclosure. It that because the silicon is buggy, or because Linux somehow ends up being vulnerable when it need not be? >=20 > SPARC avoids the issue because almost all implementations are in-order. Definitely not true of the post-Oracle models. I saw a tech talk on the core once. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"