Intel Plans To Release Chips That Have Built-in Meltdown and Spectre Protections Later This Year (businessinsider.com) 154
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."
Fool me thrice (Score:2, Insightful)
From the people who brought you F00F, FDIV, and now Meltdown? No thanks.
Obligatory: Intel CPU Backdoor Report (Jan 1 2018) (Score:1)
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 [youtube.com]
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag [events.ccc.de]:
"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 [win-raid.com] 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 [github.io] using the me_cleaner [github.com] 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 [ptsecurity.com], use me_cleaner [github.com] with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit [github.com].
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode) [ptsecurity.com]
me_cleaner: Set HAP AltMeDisable bit with -S option [github.com]
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine [blackhat.com]
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it [eff.org]
Sakaki's EFI Install Guide/Disabling the Intel Management Engine [gentoo.org]
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws. [zdnet.com]
CVE-2017-5689 [cvedetails.com]: An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs
CVE-2017-5705 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Manageability Engine Firmware
CVE-2017-5706 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Server Platform Services Firmware
CVE-2017-5707 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Trusted Execution Engine Firmware
CVE-2017-5708 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Manageability Engine Firmware
CVE-2017-5709 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Server Platform Services Firmware
CVE-2017-5710 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Trusted Execution Engine Firmware
CVE-2017-5711 [cvedetails.com]: Multiple buffer overflows in Active Management Technology (AMT)
CVE-2017-5712 [cvedetails.com]: Buffer overflow in Active Management Technology (AMT)
Useful links (Added 2017):
The Intel ME subsystem can take over your machine, can't be audited [ycombinator.com]
REcon 2014 - Intel Management Engine Secrets [youtube.com]
Untrusting the CPU (33c3) [youtube.com]
Towards (reasonably) trustworthy x86 laptops [youtube.com]
30C3 To Protect And Infect - The militarization of the Internet [youtube.com]
30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software [youtube.com]
1. Introduction, what is Intel ME
Short version, from Intel staff:
Re: What Intel CPUs lack Intel ME secondary processor? [intel.com]
Amy_Intel Feb 8, 2016 9:27 AM
The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current Intel chipsets, I even checked with the engineering department and they confirmed it.
Long version:
ME: Management Engine [libreboot.org]
The Intel Management Engine (ME) is a separate computing environment physically located in the MCH chip or PCH chip replacing ICH.
The ME consists of an individual processor core, code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system's memory as well as to reserve a region of protected external memory to supplement the ME's limited internal RAM. The ME also has network access with its own MAC address through the Intel Gigabit Ethernet Controller integrated in the southbridge (ICH or PCH).
The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can't be ignored.
ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ignition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.
Quotes on Intel backdoors:
A message from RMS [fsf.org]
by Richard Stallman on Dec 29, 2016 09:45 AM
The current generation of Intel and AMD processor chips are designed with vicious back doors that users cannot shut off. (In Intel processors, it's the "management engine".)
No users should trust those processors.
2. The backdoor is next to impossible to de
Intel: Years of insufficient management. (Score:4, Insightful)
Intel has had many years of insufficient management, in my opinion. [slashdot.org]
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 [cnbc.com]
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?
Re: (Score:1)
I am... (Score:1)
I am Pentium of Borg. Division is futile. You will be approximated.
Ah. That never gets old.
So in the end (Score:5, Insightful)
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
Re:So in the end (Score:5, Interesting)
Re: (Score:3, Interesting)
Re: So in the end (Score:1)
My i7 8700K crashes like crazy with 3466 mhz cl16 ram from motherboard qvl so don't worry about ryzen just doing 3200 mhz.
Also new models in April. Threadripper seem to have better support than ryzen.
Re: (Score:2)
You may have missed that Ryzen can go up beyond DDR4-3600 memory now. The new AGESA 1.0.0.0a isn't perfect yet, but the platform has been seeing some nice improvements.
Re: (Score:1)
My point really is that enabling XMP on the ASUS Z370-F Strix motherboard claiming support for up to 4000 MHz memory OC depending on the processor with an i7 8700K and Corsair Vengeance RGB 3466 MHz CL 16 2x8 GB kit on the QVL list of the Z370-F and with Samsung B-die chips AFAIK doesn't work reliably and generate memory errors in memtest86 within seconds-minutes on test 6 (block move) and crashes on a daily bases at normal use.
So clearly 3466 MHz with the i7 8700K I happen to have didn't worked either.
I ha
Re: (Score:2)
Also waiting for Zen+ to see it they will deliver enough performance to justify a change from my current CPU.
Why wait? Posting from a Ryzen 1700 with 32GB. This is a budget build that arguably out-muscles high end Intel workstations. It's not just the multi-core performance that rocks, but energy sipping power performance. And single threading performance is far from shabby. Intel can't match this for the money, and maybe can't match it even if money isn't a factor.
Next step up for me will be the Threadripper refresh. Not a budget proposition but the value is there, and currently is the performance king. Budget mo
Re: (Score:2)
Re: (Score:2)
Why wait? I am waiting because if is to pay a lot then I'll pick up something that has Threadripper performance for multitasking and also has more gaming performance than my current config, and maybe Zen+ or Zen2 will fulfill that goal.
You don't pay a lot for Ryzen right now, a 1700 costs $290 and a decent AM4 board runs around $90. That gets you into a highly respectable box that no doubt makes your current one look old and feeble, including in game performance. Your box is five years old, right? Has half the cores and one quarter the threads of Ryzen? You will be moving from DDR3 1333 to DDR4 2400 or better. Seems like a no-brainer.
To get into Threadripper you triple the cost at least, and you get a best on the block enthusiast machine,
Re: (Score:3)
Re:So in the end (Score:4, Informative)
Re: (Score:2)
Let's say that my current desktop has "X" performance, I've defined to myself that I should only change when new hardware is at least 50% better than the current one (a i7 4930K@4GHz). When the Threadripper appeared I thought I had found the ideal candidate, and in fact in multitasking applications it is several times better than my current desktop.
However, the TR performance on games (esp
Re: (Score:2)
Re: (Score:2)
Re: So in the end (Score:3)
Re: (Score:2)
amd needs boards with IPMI for the E-3 class of c (Score:2)
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.
Re: (Score:2)
I have seen nothing but game bugs, graphics corruption, instability and unoptimised drivers from ATI/AMD GPUs.
Hello, wizened story teller. Neolithic age called and wants you back.
Re: (Score:2)
Re: (Score:3)
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
That was most of Slashdot's initial reading on the situation:
Their stock is going nowhere but up. The time it takes them to correct their architecture is far lower than the time it will take all their customers to migrate to a different architecture.
Re: (Score:2)
The time it takes them to correct their architecture is far lower than the time it will take all their customers to migrate to a different architecture.
Is that really true? They're struggling just to get out a patch, in spite of being considered highly competent at programming what with their compiler being so good and all. (And also so good at making code that doesn't run quickly on AMD processors even though it can do so — use gcc or even Microsoft's compiler instead for superior results on amd64! But I digress.) They're considered highly competent at making CPUs, but they don't actually seem to be as competent as their competitors. So will they ac
Re: (Score:2)
Re: (Score:2)
Pretty much every CPU maker was affected by Spectre. It was an oversight in how speculative execution could be abused and thus affected all CPU designs, it wasn't an accidental implementation bug like the FDIV bug.
Meltdown was more specific to Intel, and fixing it eliminates a good chunk of Intel's performance advantage over AMD. So it will cost them in lost CPU sales to AMD.
Apparently, Meltdown is neither "an oversight" nor "an accidental implementation bug". It's more like "fuck security, let's make this fast". Meanwhile, AMD is left looking like the square, nerdy kid who did everything right in a world of loudmouth salespeople, and we can only hope he gets the girl before the end titles.
Re: (Score:2)
Note: have not read TFA. But the headline is "built-in meltdown and spectre protection"
That doesn't sound like "fixed" - that sounds like "mitigated" or "avoided"
This is a hardware hack, not a proper fix.
Re: (Score:1)
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.
Re: (Score:2)
Re: Wat (Score:2)
Hopefully it will be secure by default... (Score:5, Insightful)
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.
Re: (Score:2)
Since actual fixes would impact performance, that hope is slim. It will be the least they can get away with calling "a fix".
Re: (Score:2)
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.
Re:Flush (Score:4, Interesting)
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... [medium.com]
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
Re:Flush (Score:4, Informative)
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.
Re: (Score:2)
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... [stackexchange.com]
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 vir
Re: (Score:2)
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 compete
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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... [stackexchange.com]
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
Re: (Score:2)
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 w
Re: (Score:2)
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.
Re: (Score:2)
Uh, yeah. I do.
Re: (Score:2)
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.
Re: (Score:1)
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 can only assume that you are on copious amounts of drugs.
Intel hasn't gotten where they are by doing what's best for the consumer. In fact, at every given opportunity, they have taken the distinctly customer-butt-violating path instead.
Re:Hopefully it will be secure by default... (Score:5, Funny)
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.)
Which is effectively the VW-emissions-scandal school of benchmarking.
Comment removed (Score:5, Funny)
Re: (Score:2)
Let me correct this for them...
assigned some of our very best marketing minds minds to sell suckers entirely new chips with built in protections disabled by default
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
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.
Translation (Score:4, Funny)
Re: (Score:2)
I read somewhere you can get your battery replaced for 29$ for the the hardware fix.
wtf article? (Score:5, Informative)
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.
Re: (Score:3)
What. the. FUCK! That couldn't be further from the truth. It's like Intel wrote this garbage piece of shit "article" for them.
Troy Wolverton and BI are both on G+, so I went over there and plus-tagged them both in a complaint about it. Incompetence all around. If only BI were qualified to comment upon this issue, they would have had an editor who could catch that error.
Re:wtf article? (Score:5, Informative)
No. No they have not. Meltdown is an Intel-only thing except possibly for a few exotic ARMs.
Spectre affects everyone.
Re: (Score:2)
And IBM Power8 and Power9 are also affected by Meltdown, and Oracle has refused to talk about any SPARC systems which are not currently in support.
Re: (Score:2)
Power7 and later,
IBM has said that there will be further communication on older processors. Some suggest that G3 and G4 are safe, but that still leaves POWER5 and POWER6
Re: wtf article? (Score:2)
You're still fooled by Intel's Jedi^H^H^H^Hmarketing mind tricks. Spectre does not affect everyone. Many ARM cores used in tablets and smart phones lack speculative execution features in order to save battery power. Without speculative execution, there is no Spectre. Only the higher performance ARM's implement speculative execution.
Fuck off cunt, Meltdown is Intel only (Score:2, Insightful)
Intel cheated to get better benchmarks, AMD didn't.
Re: (Score:2)
I don't actually think they got any measurable performance increase.
And Intel ME? (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:1)
Who needs credibility when you can just purchase the journalist? Why would they mention that the ME exists when they don't have plans to fix it?
Re: (Score:2)
But how about removing the bug-ridden, back-door infested Intel ME?
They why would businesses buy Intel? If they have to spend extra money on enterprise management they may just as well go to AMD.
Re: (Score:2)
Actually, it is ALREADY capable of being disabled. Both at the motherboard BIOS level, and at the ME level itself. Disabling it at the ME level is quite the pain in the ass, however.
They should dedicate a pin to this, so that you can have a physical ME disable jumper. They could lie about whether it works, but at least you wouldn't have to worry about software lying to you, only hardware.
It's part of the plan (Score:1)
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.
Why only now ? (Score:4, Insightful)
This was know about at least 7 months ago, there have been stories about side channels [arstechnica.com] longer than that. So: why have they only got their 'best minds' working on it now ?
Stop phrasing this shit like Intel PR (Score:5, Interesting)
How delicate! (Score:2)
Are you seriously "planning"?
I thought it was a mandatory move to be done as priority 1 over everything else!
You insensitive silicon clod!
"protections" (Score:2)
... 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.
Re: (Score:2)
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.
You don't understand Spectre. Reading protected memory through speculative execution by itself is no problem. Using the data in a way that leaves a trace (like using it to form an address and reading from that address) is the problem.
Re: (Score:2)
Reading protected memory through speculative execution by itself is no problem.
It's a problem if you have memory mapped I/O, and reading it causes something to happen.
For example, status registers frequently auto-clear when read.
Re: (Score:2)
Neither of these flaws allows reading protected memory without permission.
Sometimes you don't need to read protected memory to cause problems, you just need it to be read.
Newspeak (Score:2)
[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".
I think we're missing an opportunity here... (Score:1)
Will cost more; will be slower. (Score:2)
or as Intel will try to frame it - next-gen performance and security!!
Modern computing (Score:2)
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
Intel To Release Chips With Built-in Meltdown and (Score:2)
Exactly what kind of fix? (Score:2)
"we're acutely aware we have more to do" (Score:1)
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.
On
Re: (Score:2)
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.