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: > > On 01/03/2018 14:48, Ronald F. Guilmette wrote: >> >> In message <477ab39d-286d-d9a2-d31e-fd5f7f1679a8@sentex.net>, >> Mike Tancsa <mike@sentex.net> wrote: >> >>> I am guessing this will impact FreeBSD as well ? >>> >>> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ >> >> Swell. Just swell. >> >> 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? >> >> Geeeesssh! > > Wait until Tuesday before you explode. Intel are now saying that it's > not a "bug" in Intel CPUs. > > https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ > > Eric It looks more like they are playing fast and loose with words. From 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 “bug” or a “flaw” and are unique to Intel products are incorrect. They did not say it is *NOT* a bug, just that it is not a bug unique to Intel. I’ve not seen speculation regarding the “bug” being able to corrupt, modify, or delete data, I’ve 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’s 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 “workloads” 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’s 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’s hardware instead of Intel is one of many vendors whose product has this bug (though this remains to be seen). —David M. Syzdek
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C58A6DB-0760-4E5A-B65D-2ED6A6B7AAD2>