I could not find any reference to this list of processor models anywhere in the Net,
That's because the actual details of the problem have not been publicly disclosed yet.
A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug. Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes …
If people are running their servers in a virtual environment (VMware ESXi), does this issue potentially open VM to VM communication vulnerabilities, or if the hypervisor still effectively isolating privileged memory correctly between VMs? I can understand that this may still leave the issue open inside the VM OS if those are unpatched, but as long as the hypervisor is still providing isolation, the risk is restricted to issues inside the VMs themselves.
That's the best question I've heard asked here. What about Hyper-V as well? Host hypervisors themselves would have their own exposure to this bug. Hijacking a VM is one thing, hijacking the Host Hypervisor is something of a different order. I'll bet VMware and MS Hyper-V are testing the crap out of this as I type.
I took a little time in my lunch break to try and figure out what was so big that it had intel and co running scared....
I found a Video from 2017 (wow that long ago!) showing reading a EC2 instance from an EC2 instance without any kind of permissions...
Is this what the fuss is about? It looks pretty scary to me!
Intel is obviously cutting back on it's hardware validation procedures in their rush to put products on the market to compete with AMD Ryzen, Threadripper and EPYC processors.
As a for instance, AMD took almost 3 years to validate Ryzen and EPYC prior to launch. Intel seems to be taking less than a year.
Of course QC will suffer. In fact this bug has been known for several months.
When i worked at intel, apart from the fabs, which were given a pass, mainly as sod all people worked in them and they were so key to Intels profit, the rest if intel operated in a lunatuc, ranknrate, paranoia, run around hell.
Intel need to realise that their core comoetence is running software.
Presumably, knowing that the CPU's have a fundamental design flaw in them, Intel must now ask all vendors to cease selling defective processors.
It's one thing to discover a problem in your processor that requires an OS change to fix. It is entirely another to knowingly sell any more of these defective chips.
This is quite a big story as when the updates eventually get rolled out we will see significant drop in computer resource availability. I expect to see
- Websites / services becoming slow or going offline
- Lower productivity, workers waiting even longer as their computer grinds away
- Increased business cost to cover the loss of computer resource
- When the embargo is lifted and details of the bug become known, there will be a slew of new malware, especially targeting those who refuse to update
-Big jump in AMD shares price and a crash in Intel's
-But no SEC insider dealing investigation into why the Intel CEO sold his shares before Christmas
"- Websites / services becoming slow or going offline"
Good point about going offline. A server currently running under high CPU load could have its throughput reduced below the required workload and then there will be backlogs or service unavailability. This could be a headache for admins who will have to decide whether servers can tolerate the performance hit before installing the patch.
According to HotHardware.com (see https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos) the linux page table isolation is being applied to all x86 CPUs not just the intel ones with the problem - and according to the linux kernel diff log the patch was submitted by an Intel engineer (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c313ec66317d421fb5768d78c56abed2dc862264)
Haven't used AMD in a long time, but as AMD can't really be used in a hackintosh, won't be switching to AMD any time soon. Besides, I've had trouble with every AMD processor I've ever had, and not with Intel, so going to stick with Intel unless AMD gets better and can be used in a hackintosh as easily as an Intel processor.
ARM is also affected by this, has no discoverability of built in devices on many platforms, and is infested by binary blobs for many devices. Its documentation is generally appalling.
Its only saving graces are the lower power and the price. Passable for a phone that everyone accepts is landfill after two years (idiocy, but the prevailing opinion), unforgivable for general computing devices.
I can't help wonder how this will effect people who've encrypted their entire hard drive with VeraCrypt, or at least run something out of an encrypted file 24/7.
Because surely the reading and writing, not to mention the use of an encryption driver will be pretty heavy on system calls.
Drive encryption should not require more system calls than before being just further processing. But there Is the theoretical possibility of user land i.e. browser discovering your keys then somebody physically thieving the machine.
ARM may have issues but being a forty year old 8 bit micro with stuff lashed on isn’t one of them. Well it has evolved but started as a 32 bit (26 bit address limited earlier) machine.
The hypervisor is in a fuzzy way kernel so in an unqualified way I think it can leak just the same but I may be wrong.
(I rather like AMD, used them preferentially back when I was building my own kit, in P4 days. I've been thinking of building a mini-ITX with my son and was already preferring AMD's Ryzen).
Once the dust settles, this may end up more negative to Intel than positive to AMD, sadly.
- it will be a big hit on Intel's financials
- assuming that it is relatively easily to design and implement a fix in silicon, this is a massive suck on Intel's current CPU lineup, but won't affect them much once the fix is in.
- Intel won't lose OEM business on existing systems (though the OEM's sales might drop). It need not lose business on future systems once they've fixed their silicon. It's vulnerable on a narrow range of systems where the choice of CPUs is still not finalized.
- Apple's rumors of switching to ARM arch concretizing? That would be a massive hit on Intel, but would do nada for AMD.
- OEMs may not at all be happy, but at least Intel has the $ to indemnify them, should it be decide to do so, or be forced to. AMD's $400M/Q losses just wouldn't allow it.
- Intel has always won because most premade system use them. A big part of that is their Intel Inside
bribery incentive program. After this, they will just double down on spending big $ to wine and dine the OEMs and there's little AMD can do about it. Yes, massive reputational damage to Intel, but will it stick? Marketing $$$ is Intel's strength.
This will distract Intel, for sure. And it will cost them too. But will it change things a lot, much as we'd like more competition in the X86 space?
On the plus side for AMD, this couldn't have happened at a better time for them. They've had their moments when they were significantly better than Intel and right now is very much one of them. Had this happened 2 years ago, they would have had little to capitalize on.
Now, with the new Ryzens they have a much better story to tell to customers. If they can develop that into more OEM opportunities long term that'll be awesome.
Its not a flaw -- its an NSA demand! How else can they spy on the whole world easily.
Just keep in mind that all those used computers/CPUs being sold by CHina and Russia very new silicon guts with their hardware hacks. Yup innocent American set up by hardware as fifth column attackers.
Conspiracy anywhere 2 people gather. ROFLAMAO
VMS to x86 happened the first time back in the late 80s. USAF unit was working with weighed running an air combat simulation model designed for VAX on x86 hardware for about $5000 plus cheaper version of software for x86 at about $25K. Even live support was cheaper by factor of 1/3.
But as always study directors assumed General level staff would be more impressed if we ran on Genuine VAX equipment that we got an incredible bargain of about $250K plus the bonus that software on VAX hardware was x20 the price as well on government contract.
Virtualization science is approaching the point that -- soon native instruction sets will not matter much. Heck in 20 years you will probably be able to 3D print your own designed CPUs at home. Then with a little generic Virtual Mapping and kernel-hypervisor building assisted by COTS software on another computer...you can then run VMs on your own unique instruction set CPU.
Mind you for 7-10 years those VMs will probably still be running mostly x86 software. But eventually Computer Scientists and hobbyists will get their dream of running software based on whatever arbitrary symbolic operations language is currently in vogue or that they want to invent (Forth Reborn etc)...and X86, ARM and all those hardware vendor instruction sets will be dead.
But in the mean time going rogue to avoid 90% of current software invention needs more specific needs than "I hate big groups and companies" and "I want a smaller pond so I look like a bigger fish". So low cost low power embedded or supercomputing still tend to be the more common refuges from x86.
Speaking of speculative processing... I know it sounds like some wingnut conspiracy stuff but one does have to wonder if some group like the NSA (or the Russians/Chinese if you want to be really crazy) insinuated an ubiquitous yet subtle design bug into the core design back a decade+ ago during the height of the CARNIVORE craziness? This could have allowed them covert access nearly worldwide for almost any Intel based Windows, Linux, and Mac systems apparently. Just an idea from my food-for-thought processor. ;-)
I don't know the details about this bug, but if speculative execution from user to kernel mode is triggering the issue as described in this article, then wouldn't memory barriers fix the problem? Couldn't they just insert them at the start of system calls, interrupts, and context switches? There must be more to it.
I believe it's speculative execution within the kernel, resulting in information disclosure to user mode due to a timing attack on the shared processor cache which can undermine KASLR.
So they split the user/kernel page table set, which had always been shared before for performance (and only split to provide 4GB/4GB space for both on x86-32, which suffered the same kind of impact).
One interesting way to approach this might be to limit the cache allocated to certain processes, but that's an advanced feature found only on recent Xeons, and I don't think anyone's actually planning to do that - it might have an even worse impact.
I have an Intel i7 3770 and have been running the Windows Insider preview which has apparantly had the patch applied since November and I haven't noticed any performance drop in anything. Even testing since I heard of this I can't find anything more that 1-3% which can easily be for other reasons. Even gaming with a cpu intensive game (BF1 64player multiplayer on amiens) which maxes my CPU out I can't see any difference. Servers and virtualized enviroments might be different but there will be little or no effect on standard desktop use.
Gaming is pretty much unaffected - it doesn't involve the kernel, you're talking direct to the GPU. Most desktop apps are not IO intensive so you won't see a big hit. It's not great news for stuff that slams the disk and network, or works in real time - however, as we said, if you have PCID supported, the hit is minimized.
Biting the hand that feeds IT © 1998–2019