Slashdot Mirror
Intel Plans To Release Chips That Have Built-in Meltdown and Spectre Protections Later This Year (businessinsider.com)
Intel plans to release chips that have built-in protections against the Spectre and Meltdown attacks later this year, company CEO Brian Krzanich said during company's quarterly earnings call this week. From a report: The company has "assigned some of our very best minds" to work on addressing the vulnerability that's exploited by those attacks, Krzanich said on a conference call following Intel's quarterly earnings announcement. That will result in "silicon-based" changes to the company's future chips, he said. "We've been working around clock" to address the vulnerability and attacks, Krzanich said. But, he added, "we're acutely aware we have more to do."
So in the end, Intel is going to make a shitton of money on Meltdown and Spectre because everybody is supposed to buy their new, fixed CPUs
CLI paste? paste.pr0.tips!
I a reminded of Torvald's scathing emails about Intel, their proposed patch sets, and how they pointed toward intel wanting to make future chips "Fast but insecure" by default, and requiring the BIOS or OS to tell the CPU "No bitch, secure mode only please", just so they could continue to claim benchmark scores (naturally, with the anti-spectre and meltdown patches disabled so the chip runs really fast.)
Hopefully these silicon level fixes are *ACTUAL* fixes to the methodology used by the speculative execution implementation of the chip, so that speculative execution still is active, but the chip no longer leaves bits and pieces in the processor cache that can be exploited, and that it does this by default.
Hopefully.
INTEL: we've assigned some of our very best minds to developing new chips with built in protections
Slashdotters: what about the 8 generations of chips that do not have such protections and in fact require massive performance losses to protect?
INTEL: very...best...minds.
Good people go to bed earlier.
Our CPUs cannot be fixed with software. You are going to need to buy a new CPU.
The Meltdown attack also affects chips from AMD and those based on ARM designs and, in turn, nearly every PC, smartphone and tablet made in recent years.
What. the. FUCK! That couldn't be further from the truth. It's like Intel wrote this garbage piece of shit "article" for them.
And of course, because they are serious about security, they won't be including the Intel Management Engine in computers that don't need it, RIGHT????? Fixing Meltdown and Spectre isn't news - everyone knew that they would jump on that one. But how about removing the bug-ridden, back-door infested Intel ME? THAT is what we should insist on every time they try to claim security credibility.
This was know about at least 7 months ago, there have been stories about side channels longer than that. So: why have they only got their 'best minds' working on it now ?
Spectre works by getting speculatively executed code access kernel mode memory. So they'd need to do protection checks before the speculative code did the access.
https://medium.com/@mattklein1...
1. In the first line, a âoeprobe arrayâ is allocated. This is memory in our process which is used as a side channel to retrieve data from the kernel. How this is done will become apparent soon.
2. Following the allocation, the attacker makes sure that none of the memory in the probe array is cached. There are various ways of accomplishing this, the simplest of which includes CPU-specific instructions to clear a memory location from cache.
3. The attacker then proceeds to read a byte from the kernelâ(TM)s address space. Remember from our previous discussion about virtual memory and page tables that all modern kernels typically map the entire kernel virtual address space into the user process. Operating systems rely on the fact that each page table entry has permission settings, and that user mode programs are not allowed to access kernel memory. Any such access will result in a page fault. That is indeed what will eventually happen at step 3.
4. However, modern processors also perform speculative execution and will execute ahead of the faulting instruction. Thus, steps 3â"5 may execute in the CPUâ(TM)s pipeline before the fault is raised. In this step, the byte of kernel memory (which ranges from 0â"255) is multiplied by the page size of the system, which is typically 4096.
5. In this step, the multiplied byte of kernel memory is then used to read from the probe array into a dummy value. The multiplication of the byte by 4096 is to avoid a CPU feature called the âoeprefetcherâ from reading more data than we want into into the cache.
6. By this step, the CPU has realized its mistake and rolled back to step 3. However, the results of the speculated instructions are still visible in cache. The attacker uses operating system functionality to trap the faulting instruction and continue execution (e.g., handling SIGFAULT).
7. In step 7, the attacker iterates through and sees how long it takes to read each of the 256 possible bytes in the probe array that could have been indexed by the kernel memory. The CPU will have loaded one of the locations into cache and this location will load substantially faster than all the other locations (which need to be read from main memory). This location is the value of the byte in kernel memory.
Using the above technique, and the fact that it is standard practice for modern operating systems to map all of physical memory into the kernel virtual address space, an attacker can read the computerâ(TM)s entire physical memory.
Now, you might be wondering: âoeYou said that page tables have permission bits. How can it be that user mode code was able to speculatively access kernel memory?â The reason is this is a bug in Intel processors. In my opinion, there is no good reason, performance or otherwise, for this to be possible. Recall that all virtual memory access must occur through the TLB. It is easily possible during speculative execution to check that a cached mapping has permissions compatible with the current running privilege level. Intel hardware simply does not do this. Other processor vendors do perform a permission check and block speculative execution. Thus, as far as we know, Meltdown is an Intel only vulnerability.
Edit: It appears that at least one ARM processor is also susceptible to Meltdown as indicated here and here.
Seems like there are two options. One is to do privilege checks before speculative code is executed. Another would be roll back the state of the cache on a protection fault.
The later one appeals actually. In a GP fault handler you could just invalidate the cache line to foil step 7. And you don't need to slow down the common case where speculative
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
We don't need "built in protection" we need a "design which isn't vulnerable", if the former is truly their strategy then the analogue is anti-virus inside your CPU... You people who write headline need to stop playing into Intel PR's incredulous attitude to their own fucking design flaw. Meltdown and Spectre are not inevitable, they need to be designed out not paved over. Intel: stop treating everyone like morons or suffer the consequences.
Seems like there are two options. One is to do privilege checks before speculative code is executed. Another would be roll back the state of the cache on a protection fault.
The later one appeals actually. In a GP fault handler you could just invalidate the cache line to foil step 7. And you don't need to slow down the common case where speculative execution doesn't execute code which causes a GP fault.
That should work great on uniprocessor single-threaded. However it should be possible to let another core or hardware thread watch whether the cache line gets locked by carefully timing access, and that probably gives the adversary some of the same information. By the time the cache line is invalidated, the adversary already got what they wanted.
Even if I'm wrong and this attack is infeasible, you have only prevented Meltdown, not Spectre.
Spectre hits you when you try to execute untrusted code such as JavaScript in a VM. The VM runs at the same privilege level as the untrusted code, so the CPU does not have any protection boundaries to stop it from speculatively executing into the wrong area. There will be no protection fault, the CPU will just realize that oops the speculation was wrong and do the unwind. You will have to extend your proposal to do cache invalidation on all unwinds, not just protection faults.
Finally! A year of moderation! Ready for 2019?
"From the people who brought you F00F, FDIV, and now Meltdown? No thanks."
Intel has had many years of insufficient management, in my opinion.
It is not difficult to find evidence of insufficient management at Intel. Yesterday I got 2 poorly considered, poorly written marketing emails from Intel.
More evidence of insufficient management: Intel's CEO reportedly sold shares after the company already knew about massive security flaws
Will Intel be allowed to PROFIT from many years of producing processors with vulnerabilities? Will Intel be treated like U.S. banks in 2008, when many banks profited and many finance system managers got bonuses after the financial crash?
If vulnerabilities are profitable, would Intel deliberately allow vulnerabilities in its products? Were the previous vulnerabilities deliberate? Maybe the CEO didn't previously know about the vulnerabilities. Did someone else at Intel profit from the vulnerabilities?