Date: Wed, 3 Jan 2018 13:43:08 -0900 From: "David M. Syzdek" <david.syzdek@acsalaska.net> To: Eric van Gyzen <vangyzen@FreeBSD.org> Cc: "Ronald F. Guilmette" <rfg@tristatelogic.com>, "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: Intel hardware bug Message-ID: <7C58A6DB-0760-4E5A-B65D-2ED6A6B7AAD2@acsalaska.net> In-Reply-To: <02563ce4-437c-ab96-54bb-a8b591900ba0@FreeBSD.org> References: <19097.1515012519@segfault.tristatelogic.com> <02563ce4-437c-ab96-54bb-a8b591900ba0@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 3, 2018, at 11:59 AM, Eric van Gyzen <vangyzen@FreeBSD.org> = wrote: >=20 > On 01/03/2018 14:48, Ronald F. Guilmette wrote: >>=20 >> In message <477ab39d-286d-d9a2-d31e-fd5f7f1679a8@sentex.net>, >> Mike Tancsa <mike@sentex.net> 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 = <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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C58A6DB-0760-4E5A-B65D-2ED6A6B7AAD2>