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."
From the people who brought you F00F, FDIV, and now Meltdown? No thanks.
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.
I assume they will built in a check for what memory is accessed, just like AMD already have.
So.. I guess it's .. ARM for you or something.
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.
They should be happy enough with a Zilog. Just slip them a TI 83 or similar under the basement door and run away quickly.
There is no XUL, only WebExtensions...
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.
Make insecure chips but fast, use ahh didn't realize security issue marketing, slow down chips, resale chips with the same performance level, profit.
Much cheaper than actually coming up with faster chipsets to purchase.
Uplink Hosting - Web/email at an affordable price with high performance - https://uplinkhosting.ca/link.php?id=3
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 ?
From what I understand about the vulnerability, all they need to do is flush the execution pipelines and cache after a context switch
Which is already the most expensive operation on an Intel CPU, and happens all the time in our current workloads.
The cesspool just got a check and balance.
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?
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
me_cleaner: Set HAP AltMeDisable bit with -S option
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could ga
Intel cheated to get better benchmarks, AMD didn't.
Comment removed based on user account deletion
Comment removed based on user account deletion
"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?
Uh, yeah. I do.
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;
amd needs boards with IPMI for the E-3 class of cpus (aka desktop) that they have. Not all servers needs an 8 ram channel 128 pci-e high end system.
Are you seriously "planning"?
I thought it was a mandatory move to be done as priority 1 over everything else!
You insensitive silicon clod!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache. So you could clean up that in the GP fault handler before you return to the process, do a context switch or execute any untrusted code.
Actually you could do this in software. Which makes me wonder why no one has thought of it, because it seems a bit obvious. Maybe it's flawed in someway.
A bit of Googling turns up this
https://security.stackexchange...
Fixing Meltdown is relatively easy (compared to Spectre), although it probably can't be done with a microcode update. As well as setting a fault-if/when-this-reaches-retirement bit on the uop, a TLB lookup could gate the page-address bits (to all ones) with the privilege-check. e.g. a load in user-space from any kernel page could micro-architecturally execute as a load from the very top physical page. (And systems with less than the max amount of RAM wouldn't have any physical RAM at that physical address.)
Or a failed privilege check could maybe still allow the load to happen microarchitecturally, but mask the result to all-zero in the load port. (Remember, the Meltdown problem isn't that an unprivileged load can bring kernel data into cache, it's that the secret data load result can be used to make another load with a data-dependent address. Continuing speculative execution with a zero result for any under-privileged load that hits in the TLB wouldn't allow any data-dependent microarchitectural effects).
I.e. you do the virtual to physical translation using the TLB but you make invalid addresses map to an address with all ones. Since you have to do the V to P translation anyway, that seems like a good option.
I'm guessing Intel will do something in the next generation batch of chips out - basically hack the current generation with the fix. With a bit of luck Meltdown has put the ph3ar of the h@xx0rz into them and they'll do that at top priority.
It still means it's not a good time to buy a new PC though - anything you buy now will need KPTI or the equivalent enabled. It's claimed that on chips with PCID support KPTI isn't too bad, but that is dependent on what you're doing with the machine.
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;
... built-in protections against the Spectre and Meltdown attacks ...
Hey Intel! It's not an attack, it's a demonstration of why your design is broken.
It's fundamentally broken to read protected memory without permission.
If your chip can read protected memory without permission at any time, for any reason, it's broken.
Don't try to mitigate the "attack", just fix your damn broken design.
[quote]Intel Plans To Release Chips That Have Built-in Meltdown and Spectre Protections Later This Year [/quote]
Translation: Intel Plans To Releas Chips That Have Fixed The Meltdown and Spectre Bugs Later This Year.
These are not added protection. This is not some feature. This is repairing a mistake in all chips released while continuing to sell broken products up to "Later This Year".
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache. So you could clean up that in the GP fault handler before you return to the process, do a context switch or execute any untrusted code.
You cannot clean it up in the GP fault handler because the hardware thread running at the same time can detect the cache changes before you clean up.
Your solution only works in the single-core single-socket non-threaded case, and most single-core single-socket non-threaded CPUs today do not do speculative execution. Besides, AMD has proven that there is very little performance loss from simply doing the access check properly while speculating. Meltdown is simply not a problem if the chip designer is competent.
You are focusing on fixing the easy case. The hard case, Spectre, is when the speculative execution does not cross a privilege boundary.
Finally! A year of moderation! Ready for 2019?
Now security is important. But, otoh, Intel has already manufactured a lot of these flawed chips. Following the news about these vulnerabilities the demand for these chips is going to drop. This should open up a window of opportunity to snap up these chips at some steeply discounted prices and use them for workloads and in environments where the chips' design flaw isn't going to be an issue (just avoid applying the mitigation patches that slow everything down).
Ah - that's trivial since the 486: just insert a WBINVD instruction in the context switch code - done!
Hope you like slow computers though - that instruction flushes all caches and is slow as a glued snail.
Fixing silicon is "creap" - a lot of cash and a lot of time (making masks and manufacturing the chips).
Verifying that the fix is correct will probably be very expensive.
or as Intel will try to frame it - next-gen performance and security!!
Pain is merely failure leaving the body
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
Not at all. Speculative access to data outside your own process is no problem. But the data read is (kind of) poisoned - it must not be used for anything that leaves detectable side affects, like evicting a cache line and loading a different cache line.
Spectre hits you when you try to execute untrusted code such as JavaScript in a VM.
The problem with Spectre is that it hits you if you run malware on your computer, whereas before you were in trouble if you ran malware in your user space.
For cloud servers, this is absolutely fatal, because a different user running code on the same computer could attack you.
If you have a Mac, PC, or Linux computer running VMs, and there is malware on those VMs, then with Spectre you're in trouble; before Spectre you were not.
But if you are an ordinary Mac or Windows users, Spectre doesn't make much difference: If you have malware on your computer, then the single user is in trouble. Spectre or no Spectre. Spectre doesn't make things worse.
The exception is malware in Javascript, which can always happen. Safari protects you from most things through sandboxing, but cannot protect you from Spectre. Their solution is that all access to timers is made artificially inaccurate when running JavaScript. I suppose other browsers do the same.
It would be poetic justice if Intel had to license AMD'S implementation protection.
There are three main types of computing environment:
- Monolithic single process,
- Complex single process,
- Mixed processes
MSP: written in a low-level language (asm, c, c++), typically a very finely tuned process that may use CPU threads for parallelism in a very carefully managed way, probably implementing its own scheduling etc. Non-deterministic operations like OS/Kernel interactions are generally very, very carefully supervised, custom memory management all over the place, etc, this is the core focus of the system and every effort is made to strip the OS down to preserve cache and determinism,
CSP: possibly written in a less high-level language or one that uses a VM, or incorporates lots of disparate libraries, less to no focus on determinism, often heavy interaction with the os (file access, etc), non-organized thread organization (typically task-specific threads), cache/memory efficiency may be optimized for algorithms or routines but the overhead multitasking isn't a major factor,
Mixed: The system is expected to run a large number of processes/services and the process has no expectation of determinism, everything from assembly to python-implemented-in-bash.
The design of Windows means that it's hard to build an MSP on Windows but it's feasible now with some of the server versions. These are usually extreme cases like High Frequency Trading but also all kinds of realtime systems.
CSPs are your "performant" industrial server process, from game servers to web servers. They probably take huge amounts of RAM for granted, but you'd probably get fired if you logged in on one and started using CPU.
Mixed: everything from your mundane intranet server, mail machine, firewall, to desktop computer. There's a ton of stuff running and unless someone logs in and uses 100% cpu for a couple hours people probably wouldn't notice even high amounts of contention.
For all of these solutions we follow one model: Everything competes for time on the same CPU: Scheduler, Kernel, OS and Processes.
We've moved some tasks out to co-processors which have been reabsorbed into the CPU: MMU, FPU...
Now we have complex chips with multiple cores and ... thread assignment is done in code, in competition with the code-threads that should be running?
In the MSP case: The OS is essentially a forced hit you have to take on your processor availability: you know that every so often it's going to pop in and steal some cycles determining that ... you should carry on doing what you were doing, sorry for messing up your cache line.
In the other cases, especially when there are a lot of processes, you get a gradual degradation caused by the system taking longer to make decisions about what is fair, while it is, itself, obstructing work from being done.
We need the ability to have a Kernel-Core or a Scheduler-Core with custom instructions that can do things like tell memory to go zero a page for us rather than writing zeros to memory... That can get special state information about the CPU cores to make smart decisions about what to run, instructions only available on those cores.
Putting the kernel on its own core gives us a security barrier, and again allows us to dedicate instructions.
We're over due for this architecture. We're already trying to do this with containers and hypervisors, but CPU vendors are just like "*shrug* we'll sell you more of the same"...
-- A change is as good as a reboot.
Slashdot subject size limitation helps to find out the truth.
Slashdot, fix the reply notifications... You won't get away with it...
I am Pentium of Borg. Division is futile. You will be approximated.
Ah. That never gets old.
I think Spectre is much more difficult to fix (or at least try to mitigate) in hardware so here I think it is more likely the microcode update is simply built in. It could be there are some tweaks here and there that might make the new features exposed to the operating system work better etc. but I doubt it is fully mitigated in hardware, at most it is some evolutionary change on top of the microcode update fix.
But given Meltdown has the biggest performance impact, it is also the most important to fix. And as mentioned, I think that is very feasible.
The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache.
Speculated accesses do not fault because they are rolled back by being ignored at instruction retirement.
But, at least on Intel's microarchitecture, they still affect the cache, which is the reason Meltdown works.
It's different on AMD's microarchitecture.
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;
But, at least on Intel's microarchitecture, they still affect the cache, which is the reason Meltdown works.
It's different on AMD's microarchitecture.
It is not that Intel's microarchitecture allows speculative loads to affect the cache but that it allows speculative instructions to operate on data which would otherwise generate a protection fault when accessed.
Did AMD block speculative loads or block speculative instructions which operate on protected data? Either should prevent Meltdown.
AMD seems to have done it right with the latest designs, they're available now, and their performance is competitive...
Ryzen is a beast, and runs so cool. Bye Intel.
When all you have is a hammer, every problem starts to look like a thumb.
AMD apparently do a privilege check which either stops the speculated code running or at least makes it side effect free.
I found this interesting comment on how Intel could fix it
https://security.stackexchange...
Fixing Meltdown is relatively easy (compared to Spectre), although it probably can't be done with a microcode update. As well as setting a fault-if/when-this-reaches-retirement bit on the uop, a TLB lookup could gate the page-address bits (to all ones) with the privilege-check. e.g. a load in user-space from any kernel page could micro-architecturally execute as a load from the very top physical page. (And systems with less than the max amount of RAM wouldn't have any physical RAM at that physical address.)
I.e. you do the virtual to physical translation using the TLB but you make invalid addresses map to an address with all ones. Since you have to do the V to P translation anyway, that seems like a good option.
So illegal addresses would map to address (all ones). So that address would be loaded into the cache but the operation would later fault. Since all the addresses you don't have access to map to (all ones) you can't later do a side channel attack to find out if they're cached. And you have to do the virtual to physical translation anyway, so it doesn't cost you anything.
Very elegant.
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;
Yes you do.
How about offering some compensation to people, who bought your chips with the flaws, for the drops in the performance created by the patches? You did receive semi-monopoly prices for them, so coughing some of that up would be only fair, as we're left up with something that doesn't perform as good as advertised.
Now if only avoiding Intel on notebooks would be easier. There will be some potentially good stuff coming up this year, such as Ryzen powered Thinkpads, but there just isn't much choice. ... vote with your wallets people!
On the desktops or workstations however