Intel hardware bug

David M. Syzdek david.syzdek at acsalaska.net
Wed Jan 3 22:48:45 UTC 2018




> On Jan 3, 2018, at 11:59 AM, Eric van Gyzen <vangyzen at FreeBSD.org> wrote:
> 
> On 01/03/2018 14:48, Ronald F. Guilmette wrote:
>> 
>> In message <477ab39d-286d-d9a2-d31e-fd5f7f1679a8 at sentex.net>,
>> Mike Tancsa <mike at 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




More information about the freebsd-security mailing list