> On Jan 3, 2018, at 11:59 AM, Eric van Gyzen <vangy...@freebsd.org> wrote:
>
> On 01/03/2018 14:48, Ronald F. Guilmette wrote:
>>
>> In message <477ab39d-286d-d9a2-d31e-fd5f7f167...@sentex.net>,
>> Mike Tancsa <m...@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
_______________________________________________
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
