Forgive me. I thought the discussion was about Intel is trying to deflect blame by naming AMD in their press release about the bug the KPTI patchset addresses.
I thought it was relevant because ARM64 appears to have the same flaw, with corresponding kernel work, and AMD's Opteron-A is an ARM64 chip (one which I respect a lot, actually).
Perhaps we are agreeing with each other?!? KAISER (now named KPTI now) is a patch set to preserve the effectiveness of the kernel's address space layout randomization... without KASLR, rowhammer is a lot more dangerous.
Will's branch is is now named "kpti", and has been updated since the link I pasted earlier. (Still nearly a month since the last commit, though)
I won't claim to know the arch-specific ARM code, but they're doing a lot of work on the Kernel Address Space Layout Randomization code, which is what the kernel page table isolation is trying to protect. (That and the name of the branch certainly indicates it's addressing the same issue)
Releasing details for a serious bug before making a fix available is the definition of a zero-day, and is a pretty stupid thing for Microsoft, or the Linux Foundation to do.
There appears to be an embargo on the details until the fix is distributed; grumblings have it pegged as mid-January before it's lifted.
Intel will soon be announcing a $29 CPU replacement program for qualifying customers.
...speaking of $29 to fix the battery (to speed up Apple's iPhones): Since ARM64 is also affected, every iOS device since the iPhone 5s (late 2013), as well as Android devices of similar vintage will also be seeing a slowdown from this.
Here's the hard reality: It takes roughly a year to go from tape-out (end of chip development) to a fabricated chip. That doesn't count manufacturing time, integration into designs, physical distribution, and so on.
Even if Intel (or any of the ARM64 makers) were to find and fix the problem when it first came to light six months ago, we won't see fixes until the next Presidential primaries are getting started in mid to late 2019.
Because other CPU manufacturers are pumping out devices that have this issue, and have done so for years.
ARM64 is also affected - and includes chips made by virtually every silicon maker, including AMD, Apple, Samsung, Texas Instruments, Renesas, STMircro, Microchip, Broadcomm, Qualcomm, and others. They are in virtually every recent tablet or smartphone.
Even the decidedly non-Intel Raspberry Pi 3 is affected.
AMD's AMD64 may be unaffected, but AMD's Opteron-A processors are absolutely affected.
I think this is the exact same excuse they've used for all their previous screw ups too.
You don't have to accept Intel's excuse, but it's important to recognize that the problem is actually more widespread than Intel's chips. This has caught pretty much the entire semiconductor industry flat-footed (largely because everybody and their dog makes ARM64 chips).
Everybody makes ARM64 chips - AMD, Apple, Intel, Samsung, Texas Instruments... the even the decidedly Non-Intel Raspberry Pi 3 is affected by this bug.
We're going to see the same problem for virtually all recent Android and iOS devices.
For that matter, my car's factory radio system is probably affected, as is my new TV.
ARM64 is also affected, which means pretty much any phone or tablet made in the past 3-4 years.
ARM64 is not only a different chip maker -- but an entirely different architecture, which is produced by many vendors -- AMD, Samsung, LG, Qualcomm, Apple, Microchip, Broadcom, Renesas, STMicro, Texas Instruments, and many, many others.
The CPUs will run just as fast as the day you bought them -- they're not changing at all, and they remain functional.
Third-party software (the Linux Kernel and Microsoft Windows) will give the CPU more work to do, not slowing down the processor.
The car analogy would be suing a car manufacturer because its performance driving uphill isn't the same as on level ground. Nothing has changed on the car -- it's the road that changed.
This bug has been known and reported about since early November; the original paper was presented in July of 2017, and code has been in Github since Feburary.
Motley Fool is just noting that the Intel CEO isn't holding any more stock than he needs to.
And there are good reasons:
* AMD is back from the dead. * Intel's GPU hasn't been that successful -- they've even teamed up with AMD to put Radeon GPU's in the same die as an Intel CPU. * PC sales are declining as consumers shift from Intel PC's to using ARM-powered tablets & phones instead. * ARM is making inroads into the "desktop and laptop computer" marketplace. * ARM is powering most consumer electronics as well (TV's, Blu-ray players, Smart Speakers, etc) * Intel is absolutely nowhere in the mobile world. Mobile has one ARM to rule them all. * Intel missed the boat for the current generation of XBOX and PlayStation consoles.
Intel is looking more and more like a one trick pony, and its competitors are beginning to do that one trick better too.
Nah, GP didn't configure the kernel's settings properly.
There's more to running without swap than not enabling a swap file/partition. You have to configure swappiness, the oom_adj_score for what to kill when memory runs out, and so on.
If you read one of the original articles about the KAISER patch set: a commenter asked about microkernels, and the reply is that since it's a hardware issue, both microkernels & monolithic kernels have to pay the same price.
Refusing to pay tithes isn't a very convincing argument for the fire, especially in a gold rush boom town a century before the idea of a fire code came into being.
"refusing to tithe" was (and is) common throughout the history of the church. It's still common, with fewer than half even claiming to pay it now.
Hell, the Mormon strictures against Alcohol, Coffee, Tea, and Tobacco didn't begin to be enforced until the 1920's.
A large ISP is insane if they dodn't use automation to configure their hardware -- it guarantees consistency across the network, which reduces their overhead.
At that point, adding a "new" router is no different from updating the configuration on an existing router.
I guess Apple is safe, then. The battery isn't glued in on iOS devices; I've replaced the battery in every phone my wife and I have ever had.
iOS devices are clearly designed to be serviced. Much like a watch, requires tools and more skill than a two year old.
Seriously, your "non-replacable battery" is pure bullshit. As with any machine, you need to use the right tools for the job.
Even on the glued-in MacBook batteries, Apple has always had a solvent to release the glue for servicing, and (shocker), it's even been reverse-engineered by the folks at iFixit.
If you're not willing to use the correct tools, find somebody who will -- which is pretty much why Apple replaces the batteries at cost (with the main cost being the guy willing to use the correct tools.)
Slashdot Mirror
And when I read the git commit log, I see a more recent commit that enables it by default.
Which is a bummer: I personally use ARM devices more than x86_64, so I'm not exactly looking forward to the performance hit.
Forgive me. I thought the discussion was about Intel is trying to deflect blame by naming AMD in their press release about the bug the KPTI patchset addresses.
I thought it was relevant because ARM64 appears to have the same flaw, with corresponding kernel work, and AMD's Opteron-A is an ARM64 chip (one which I respect a lot, actually).
Perhaps we are agreeing with each other?!? KAISER (now named KPTI now) is a patch set to preserve the effectiveness of the kernel's address space layout randomization... without KASLR, rowhammer is a lot more dangerous.
Will's branch is is now named "kpti", and has been updated since the link I pasted earlier. (Still nearly a month since the last commit, though)
I won't claim to know the arch-specific ARM code, but they're doing a lot of work on the Kernel Address Space Layout Randomization code, which is what the kernel page table isolation is trying to protect. (That and the name of the branch certainly indicates it's addressing the same issue)
Show me a real POC, then we can panic.
Releasing details for a serious bug before making a fix available is the definition of a zero-day, and is a pretty stupid thing for Microsoft, or the Linux Foundation to do.
There appears to be an embargo on the details until the fix is distributed; grumblings have it pegged as mid-January before it's lifted.
Microsoft's Azure cloud has a scheduled reboot of all of their VM's on Jan 10th
, so we probably won't get any details until at least then.
I imagine Linux 4.15 will be released around the same timeframe.
arm64: Unmap the kernel whilst running in userspace (KAISER)
ARM engineers are supplying the patches for ARM64.
KAISER is the original name of the patch set.
What are you smoking?
ARM engineers (not Intel's) are supplying the patches for ARM64.
AMD's AMD64 chips don't have the flaw.
AMD's Opteron-A, however, is an ARM64 chip which does have the flaw.
The AMD Opteron-A, that's why.
Intel will soon be announcing a $29 CPU replacement program for qualifying customers.
...speaking of $29 to fix the battery (to speed up Apple's iPhones): Since ARM64 is also affected, every iOS device since the iPhone 5s (late 2013), as well as Android devices of similar vintage will also be seeing a slowdown from this.
Here's the hard reality: It takes roughly a year to go from tape-out (end of chip development) to a fabricated chip. That doesn't count manufacturing time, integration into designs, physical distribution, and so on.
Even if Intel (or any of the ARM64 makers) were to find and fix the problem when it first came to light six months ago, we won't see fixes until the next Presidential primaries are getting started in mid to late 2019.
Because other CPU manufacturers are pumping out devices that have this issue, and have done so for years.
ARM64 is also affected - and includes chips made by virtually every silicon maker, including AMD, Apple, Samsung, Texas Instruments, Renesas, STMircro, Microchip, Broadcomm, Qualcomm, and others. They are in virtually every recent tablet or smartphone.
Even the decidedly non-Intel Raspberry Pi 3 is affected.
AMD's AMD64 may be unaffected, but AMD's Opteron-A processors are absolutely affected.
I think this is the exact same excuse they've used for all their previous screw ups too.
You don't have to accept Intel's excuse, but it's important to recognize that the problem is actually more widespread than Intel's chips. This has caught pretty much the entire semiconductor industry flat-footed (largely because everybody and their dog makes ARM64 chips).
Everybody makes ARM64 chips - AMD, Apple, Intel, Samsung, Texas Instruments... the even the decidedly Non-Intel Raspberry Pi 3 is affected by this bug.
We're going to see the same problem for virtually all recent Android and iOS devices.
For that matter, my car's factory radio system is probably affected, as is my new TV.
ARM64 is also affected, which means pretty much any phone or tablet made in the past 3-4 years.
ARM64 is not only a different chip maker -- but an entirely different architecture, which is produced by many vendors -- AMD, Samsung, LG, Qualcomm, Apple, Microchip, Broadcom, Renesas, STMicro, Texas Instruments, and many, many others.
AMD also makes ARM64 chips (Opteron-A), so AMD absolutely has affected products.
The CPUs will run just as fast as the day you bought them -- they're not changing at all, and they remain functional.
Third-party software (the Linux Kernel and Microsoft Windows) will give the CPU more work to do, not slowing down the processor.
The car analogy would be suing a car manufacturer because its performance driving uphill isn't the same as on level ground. Nothing has changed on the car -- it's the road that changed.
It's not a slam-dunk case to litigate.
This bug has been known and reported about since early November; the original paper was presented in July of 2017, and code has been in Github since Feburary.
Motley Fool is just noting that the Intel CEO isn't holding any more stock than he needs to.
And there are good reasons:
* AMD is back from the dead.
* Intel's GPU hasn't been that successful -- they've even teamed up with AMD to put Radeon GPU's in the same die as an Intel CPU.
* PC sales are declining as consumers shift from Intel PC's to using ARM-powered tablets & phones instead.
* ARM is making inroads into the "desktop and laptop computer" marketplace.
* ARM is powering most consumer electronics as well (TV's, Blu-ray players, Smart Speakers, etc)
* Intel is absolutely nowhere in the mobile world. Mobile has one ARM to rule them all.
* Intel missed the boat for the current generation of XBOX and PlayStation consoles.
Intel is looking more and more like a one trick pony, and its competitors are beginning to do that one trick better too.
I'm curious how much Cannon Lake and Ice Lake CPU architectures are going to be delayed.
I'm going to go out on a limb and say "not at all"
CPU design pipelines are pretty long; generally requiring at least a year to go from "Tape Out" to fabrication.
Releasing no chip (and staying with an even slower current generation) is just not an option.
Cannon Lake and Ice lake are still an improvement on Intel's current offering, and can still compete against AMD's offering.
Intel managed to move on after the (even more dire) disasterous NetBurst architecture; there's no reason to believe they won't get past this issue.
It's nice to see that AMD is finally back in the race.
An older link, about the KAISER patch set
Nah, GP didn't configure the kernel's settings properly.
There's more to running without swap than not enabling a swap file/partition. You have to configure swappiness, the oom_adj_score for what to kill when memory runs out, and so on.
Nice catch.
I guess that's what I get for reading articles about the issue, rather than LKML...
Nice catch.
If you read one of the original articles about the KAISER patch set: a commenter asked about microkernels, and the reply is that since it's a hardware issue, both microkernels & monolithic kernels have to pay the same price.
It's not unique to Intel CPU's. It affects the entire x86 architecture family, including AMD64.
It's not unique to x86 either: ARM64 has patches for the same vulerability.
Linux Weekly News has been covering this for quite a while.
5% slowdown on average, with up to 30% for some particularly bad network operations.
ARM64 is also affected, so it's not just intel
Refusing to pay tithes isn't a very convincing argument for the fire, especially in a gold rush boom town a century before the idea of a fire code came into being.
"refusing to tithe" was (and is) common throughout the history of the church. It's still common, with fewer than half even claiming to pay it now.
Hell, the Mormon strictures against Alcohol, Coffee, Tea, and Tobacco didn't begin to be enforced until the 1920's.
if you talk about the number of routers a large ISP has, it becomes a lot of work.
Configuring large numbers of routers isn't an unsolved problem, even if you roll your own automation.
A large ISP is insane if they dodn't use automation to configure their hardware -- it guarantees consistency across the network, which reduces their overhead.
At that point, adding a "new" router is no different from updating the configuration on an existing router.
I guess Apple is safe, then. The battery isn't glued in on iOS devices; I've replaced the battery in every phone my wife and I have ever had.
iOS devices are clearly designed to be serviced. Much like a watch, requires tools and more skill than a two year old.
Seriously, your "non-replacable battery" is pure bullshit. As with any machine, you need to use the right tools for the job.
Even on the glued-in MacBook batteries, Apple has always had a solvent to release the glue for servicing, and (shocker), it's even been reverse-engineered by the folks at iFixit.
If you're not willing to use the correct tools, find somebody who will -- which is pretty much why Apple replaces the batteries at cost (with the main cost being the guy willing to use the correct tools.)