What a strange response.
>many types of computing devices — with many different vendors’ processors
Really? Like who?
Intel Responds to Security Research Findings
61–70 of 245 posts
Re: Intel Responds to Security Research Findings
#62Earlier quoted context omitted.
> their calling attention to the fact that many other processor vendors have been incorporating this flaw into their designs for while. You have a source for this claim? Because besides for Intel's press release I can't find any evidence that other manurfacture's processors are vulnerable to this bug.
The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel.
> The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel.
Is there a commit you can point to? Or a LKML discussion about this?
Re: Intel Responds to Security Research Findings
#63Do we know the actual bug yet? I sort of assumed it was a timing attack on KASLR rather than a leak of traditional kernel data. Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...
It's true nobody knows what the actual bug is, but I was working with what Ars Technica described: "If the problem were just that it enabled the derandomization of ASLR, this probably wouldn't be a huge disaster... The industry reaction... suggests that it's not just ASLR that's defeated and that a more general ability to leak information from the kernel has been developed." https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
Re: Intel Responds to Security Research Findings
#64Earlier quoted context omitted.
We won't know until we know what the actual bug is. All we know is that people are writing patches for Intel chips, and what those patches do. It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.
We know that AMD is not affected: https://lkml.org/lkml/2017/12/27/2
We know that people think that AMD is not affected by this permutation of the attack. Intel may know differently; I'd withhold sweeping claims.
Re: Intel Responds to Security Research Findings
#65Do we know the actual bug yet? I sort of assumed it was a timing attack on KASLR rather than a leak of traditional kernel data. Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...
Bigger than KASLR it seems.
https://twitter.com/brainsmoke/status/948561799875502080
Not good.
Re: Intel Responds to Security Research Findings
#66It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on. > 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. A rather bizarre s…
>Presumably the statement was hastily put together
I don't think so. Given that both *nix and MS seems to have been working on this for at least a month already it can't have come as a surprise.
Re: Intel Responds to Security Research Findings
#67Earlier quoted context omitted.
We won't know until we know what the actual bug is. All we know is that people are writing patches for Intel chips, and what those patches do. It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.
We know that AMD is not affected: https://lkml.org/lkml/2017/12/27/2
[deleted]
Re: Intel Responds to Security Research Findings
#68Re: Intel Responds to Security Research Findings
#69> 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. Given the lack of any facts, evidence, or details in the press release, how is anyone supposed to take Intel seriously?
Devils advocate.
Workload dependence... average user... not significant:
A lot of users probably see "30%" and will assume the worst. There really isn't a lot of evidence of how much an average consumer will be affected. Pretty sure your average consumer isn't running pgbench all day. Hell, I'm willing to bargain 90% of servers (I really want to say more) are over-provisioned by 30% or more.
Mitigated over time:
Kernels are getting out safe patches ASAP, performance be damned. With more time to be careful, performance can be clawed back. And/or CPUs are upgrade and features such as PCID mitigate perf losses.
Re: Intel Responds to Security Research Findings
#70It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on. > 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. A rather bizarre s…
“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch? Quoting ARM and AMD is really a bit pathetic too, IMHO, especi…
> What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?
Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable.
Not saying this is the right interpretation, just another possibility.