5 ms·
Yea... and what about every other chip maker who also have the same exploits? Can someone explain whether AMD and Qualcomm licensed this tech or if they also in
by ethani 9y ago
Yea... and what about every other chip maker who also have the same exploits? Can someone explain whether AMD and Qualcomm licensed this tech or if they also independently made the same mistakes? Either way, we really haven't seen much activity from them either.
- bipson 9y agohttps://en.m.wikipedia.org/wiki/Whataboutism https://en.m.wikipedia.org/wiki/Whataboutism
- StudentStuff 9y agoThere are fewer people trying to attack AMD's chips, they comprise such a small chunk of the installed CPU base out there that most attacker's won't be going after a system containing a CPU from AMD. This may change in the next year or two though, at which point the vulns that are likely in their Platform Security Processor may bite them in the ass. Qualcomm on the other hand has taken the "fuck security" approach and failed to clean up their code and get it mainlined for nearly all of their common SoCs. Hence why Android phones are often trapped on old versions of Android when launched or shortly thereafter, long term security through the device lifecycle is a bad joke when Qualcomm and most other ARM vendors are involved.
- nolok 9y ago> Hence why Android phones are often trapped on old versions of Android when launched or shortly thereafter The reason why most android phones don't get upgrades (or only one) to newer android versions has absolutely nothing to do with qualcomm lack of care regarding their cpu's security.
- izacus 9y agoActually it's one of the major reasons. When Qualcomm stops providing support for a SoC, the OEMs can't update the device even if they wanted to. It's not the only reason, but it is a very major blocker.
- DiabloD3 9y agoIt has been quoted by Google developers on why Nexus 5 fell off the support track so early, around the same time Nexus 4 did: it took a herculean effort to get the binary drivers to even remotely work right on Android 6 due to being unable to drag in newer kernels. This is partially why Treble is being worked on, to just completely disconnect the actual Linux-based HAL from "the OS", thus trying to negate a lot of the oblate stupidity from vendors like Qualcomm and have a shim in-between your actual phone, and Android itself, in hopes to fix stuff. We seriously need more phone SoC vendors.
- acover 9y agoHow am I running Oreo on my Nexus 5 with lineage os?
- aexaey 9y agoLineageOS (ex-CyanogenMod)'s flavour of Android 7 works just fine [1] on Nexus 5. On the other hand - yes, hammerhead is stuck on Linux kernel 3.4, which is no longer maintained, and current best effort to forward-port to mainline kernel [2] is far from complete. Among other things this means that there is no workaround for Meltdown on this hardware, which it is likely vulnerable to. [3] [1] https://download.lineageos.org/hammerhead https://download.lineageos.org/hammerhead [2] https://wiki.postmarketos.org/wiki/Google_Nexus_5_(lg-hammerhead)#Component_support_table https://wiki.postmarketos.org/wiki/Google_Nexus_5_(lg-hammer... [3] "11 stage integer pipeline with 3-way decode and 4-way out-of-order speculative issue superscalar execution" - from https://en.wikipedia.org/wiki/Krait_(CPU) https://en.wikipedia.org/wiki/Krait_(CPU)
- pjmlp 9y agoThat is just an excuse from Google that many blindly accept. First, of all there are legal obligations known as contracts. If Google was serious about Nexus 5 support from OEMs, it would have had contract in place that would assure the necessary support regardless of what OEMs would decide. Secondly, Treble is yet another solution that will die, because Google, again, decided to leave to OEMs the task of delivering Treble updates, without any kind of legal obligation. Additionally Android devices that get upgraded to Oreo aren't obliged to be fully Treble compliant, only the ones released with Oreo. So, many new devices planned to be released in 2018, are based on Android 7.0.
- fooker 9y agoNice whattaboutism there.
- CodeWriter23 9y agoYou’re conflating Spectre with Meltdown. Linus’ response is specific to Meltdown, which applies only to Intel chips. Spectre applies to numerous other architectures.
- cthalupa 9y agoUh, Linus is very specifically talking primarily about Spectre. IBRS, IPBP, and retpoline are all Spectre specific mitigations. The Meltdown mention is a sidenote.
- mannykannot 9y agoThe issue is how Intel is handling these problems. If other vendors handle their issues similarly, they may deserve a similar response, though Intel, as the market leader in x86-64, has a special responsibility (and corresponding culpability), as other vendors may have to conform to remain competitive, as the marketplace is capricious in rewarding virtue.