From owner-freebsd-security@freebsd.org Wed Jan 3 22:48:45 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 15A4FEB397B for ; Wed, 3 Jan 2018 22:48:45 +0000 (UTC) (envelope-from david.syzdek@acsalaska.net) Received: from smtp22.nwc.acsalaska.net (smtp22.nwc.acsalaska.net [209.112.142.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBA046A6C1; Wed, 3 Jan 2018 22:48:44 +0000 (UTC) (envelope-from david.syzdek@acsalaska.net) Received: from 10-0-10-67.prv.acsalaska.net (10-0-10-67.prv.acsalaska.net [10.0.10.67]) by smtp22.nwc.acsalaska.net (8.14.9/8.14.9) with ESMTP id w03Mh8bX032186; Wed, 3 Jan 2018 13:43:08 -0900 From: "David M. Syzdek" Message-Id: <7C58A6DB-0760-4E5A-B65D-2ED6A6B7AAD2@acsalaska.net> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Intel hardware bug Date: Wed, 3 Jan 2018 13:43:08 -0900 In-Reply-To: <02563ce4-437c-ab96-54bb-a8b591900ba0@FreeBSD.org> Cc: "Ronald F. Guilmette" , "freebsd-security@freebsd.org" To: Eric van Gyzen References: <19097.1515012519@segfault.tristatelogic.com> <02563ce4-437c-ab96-54bb-a8b591900ba0@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 03 Jan 2018 23:15:34 +0000 Content-Type: text/plain; charset=utf-8 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: Wed, 03 Jan 2018 22:48:45 -0000 > On Jan 3, 2018, at 11:59 AM, Eric van Gyzen = wrote: >=20 > On 01/03/2018 14:48, Ronald F. Guilmette wrote: >>=20 >> In message <477ab39d-286d-d9a2-d31e-fd5f7f1679a8@sentex.net>, >> Mike Tancsa wrote: >>=20 >>> I am guessing this will impact FreeBSD as well ? >>>=20 >>> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ >>=20 >> Swell. Just swell. >>=20 >> Why couldn't this have been announced the week -before- I bought an = Intel >> processor and motherboard to replace my aging AMD rig, rather than = the week >> -after- I did so? >>=20 >> Geeeesssh! >=20 > Wait until Tuesday before you explode. Intel are now saying that it's > not a "bug" in Intel CPUs. >=20 > = https://newsroom.intel.com/news/intel-responds-to-security-research-findin= gs/ >=20 > Eric It looks more like they are playing fast and loose with words. =46rom = the article you linked: Intel believes these exploits do not have the potential to = corrupt, modify or delete data. and Recent reports that these exploits are caused by a =E2=80=9Cbug=E2= =80=9D or a =E2=80=9Cflaw=E2=80=9D and are unique to Intel products are = incorrect.=20 They did not say it is *NOT* a bug, just that it is not a bug unique to = Intel. I=E2=80=99ve not seen speculation regarding the =E2=80=9Cbug=E2=80=9D= being able to corrupt, modify, or delete data, I=E2=80=99ve only seen = speculation that the bug allows unprivileged processes to see privileged = memory/cache. Additionally, they indirectly imply that both AMD and ARM chips are = affected by the same bug, however this is, at least in AMD=E2=80=99s = case, appears to be directly refuted by a patch submitted to the Linux = kernel by AMD: https://lkml.org/lkml/2017/12/27/2 = AMD processors are not subject to the types of attacks that the = kernel page table isolation feature protects against. The AMD = microarchitecture does not allow memory references, including speculative = references, that access higher privileged data when running in a lesser = privileged mode when that access would result in a page fault. Disable page table isolation by default on AMD processors by not = setting the X86_BUG_CPU_INSECURE feature, which controls whether = X86_FEATURE_PTI is set. Since other statements are misleading, it could be that the = =E2=80=9Cworkloads=E2=80=9D being described could be a hibernated = laptop; a halted firewall (where the firewall/routing rules are still = running in the kernel); a lightweight user who only uses e-mail and = facebook; etc: Contrary to some reports, any performance impacts are = workload-dependent, and, for the average computer user, should not be significant = and will be mitigated over time. Finally their belief of being the most secure products in the world and = actual reality may differ: Intel believes its products are the most secure in the world and = that, with the support of its partners, the current solutions to this issue provide the = best possible security for its customers. I generally read a company=E2=80=99s press releases in response to = negative publicity with the assumption that they are not lying, but are = obfuscating the truth or dancing around an issue in order to cast = themselves in the best possible light. The proof that this tactic works = is that Eric interpreted the release to say that there is not a bug in = Intel=E2=80=99s hardware instead of Intel is one of many vendors whose = product has this bug (though this remains to be seen). =E2=80=94David M. Syzdek