Intel to shut down renegade Skylake overclocking with microcode update
arstechnica.com
arstechnica.com
-On one hand Intel is disabling a "Feature" of their cpus
as a way of preventing users to get "More expensive
performance" without paying for it; you can think of it
like intel is just covering their back; we can assume the
difference on their cpus is just related to binning [0]
and they are just protecting their customers by not
allowing less performant cpus perform better therefore
increasing reliability.
-on the other hand you can see how hardware is not
anymore something you buy and expect to behave in a
certain way.
For those paranoid... would this mean they can also alter
how instructions behave? **cough**security**cough**
What worries me more is something like Nvidia's Denver architecture because that's actually a full abstraction above machine code.
What relieves me is that RISC-V is demonstrating that opensource hardware can be a reality. This will provide people with a concrete alternative to Intel and ARM chips that does away with (closed) microcode and shadowy marketing/security procedures.
Yes, we are far away from FPGA-ing our CPUs, but I see the years 2010 as the years 1980 for FLOSS code. In the '80s a bunch of people sent around tapes with copies of EMACS, cp and mkdir; 20 years later multibillion dollars infrastructures rely on open source.
Today we use Intel microprocessors fearing that their ME components will spy on us and that secure boot will lock us in. In some years we will just install our Debian-for-HW and be done with it. It is a liberating thought.
I'm not sure that just having the hardware design makes much of a difference either as it'd be the equivalent of shipping a binary blob then making the source available without the compiler used or a way to decompile because the tools required are so expensive.
In CPU land have ARM which is probably as close as we can practically get to open source but IMO the real problem is still verification of the shipped product and without third parties auditing the design I'm not sure we could ever be sure source or not.
In that vein, there is a lot about a modern FPGA that's a "binary blob". Do you fully trust Xilinx? Do you fully trust Altera?
Do you continue to trust Altera now that they are a subsidiary of Intel? If so, why don't you just trust Intel directly? Perhaps it's turtles all the way down? :)
* https://semiaccurate.com/2015/11/18/arm-charts-path-printed-...
If you're using TXT, maybe the NSA can still do that by getting the ACM signing keys from Intel. But that's still an improvement from just the standard FDE setup most people use, which could be trivially hacked by someone with the skill of an average university student.
¹ Make that 15min if you have a BIOS password and a static boot order that disallows booting on any kind of external device. It just requires a bit more preparation, but on most laptops it's not hard to put a clip on the NVRAM that stores BIOS settings and reset what needs to be reset.
TXT extends the chain of trust to the BIOS/UEFI by having the CPU take charge of some of the verification, secure boot supported UEFI's (if they meet the UEFI standard version 2.3.1c or higher) can also extend the protection envelope beyond the OS/MBR but the main function of TXT is to protect tampering with low level firmware not OS/bootloaders.
"Intel TXT uses a Trusted Platform Module (TPM) and cryptographic techniques to provide measurements of software and platform components so that system software as well as local and remote management applications may use those measurements to make trust decisions. This technology is based on an industry initiative by the Trusted Computing Group (TCG) to promote safer computing. It defends against software-based attacks aimed at stealing sensitive information by corrupting system and/or BIOS code, or modifying the platform's configuration."
What it does is centralizes all of the measurements in one place and adds DRM.
It's not bad in any way but it's also not required to run a secure boot encryption setup.
My 9 year old HP Compaq 6910p Centrino with TPM can offer almost the same level of protection as any modern Intel vPro laptop.
Case for Bitlocker (one of the few FDE's that actually has good integrity checks)
BIOS / UEFI modification (Update, revision, settings change etc.) - both will trigger recovery mode
-Boot loader modification - both will trigger recovery mode
-Boot order change - both will trigger recovery mode
-Boot attempt number does match between TPM & HDD (e.g. when the HDD was removed and attempted to be booted in another device, or when the machine was booted not from the HDD) - both will trigger recovery mode
-Data partition changed - both will trigger recovery mode
The only difference is that if my device is in either S4 and S5 mode TXT can still continue to make measurements, and the measurements that TXT allows you to do are very generic unlike standard TPM/Secureboot which only checks for specific parameters.
You also need to understand that FDE is not designed to protect your information in such cases where you lose control of the physical security of the device and do not treat it as untrustworthy afterwards, it's more or less excellent at protecting your data while it's in rest if the device is lost or stolen but that's it. And while yes secure boot can be bypassed and TPM's could also potentially be broken (which invalidates TXT as well since it uses the TPM as the cryptographic storage device for the signatures) an adversary that can bypass one could most likely bypass the others (you also need to remember that with TXT the measurement plan is stored in the UEFI flash/ram/nvram not in the TPM) and with any system your overall level of confidence should be as high as the weakest component.
Then it all boils down to BIOS security. With physical WP pins on flash chips it ought to be possible to make BIOS reflashing a reasonable PITA, especially for someone who wasn't prepared for such surprise.
I personally use cryptsetup (dm-crypt/LUKS) on my laptop running Arch Linux just in case it were stolen. Are you saying that bypassing the bootloader with a live USB, etc, could give an attacker access to the data stored on the encrypted drive (outside of the boot partition, of course)? That seems like it would defeat the purpose of full disk encryption. Note: I understand that this is assuming that the attacker does not gain access to the system while it is up and running.
No, of course not. (Well, disregarding cold boot attacks).
But it gives access to data stored inside the boot partition, allowing for fun things like patching your kernel to send dm-crypt keys to http://fbi.gov/submit_key.cgi - makes sense now?
There are various protection mechanism that rely on software alone (bootloader), software + hardware (TPM), software + firmware and software + hardware + firmware.
The question is always what do you want besides encrypting the main partition mainly in terms of integrity checks.
And older BIOS with a TPM or a modern UEFI with or without a TPM can provide additional integrity check for both the host configuration (BIOS/Device settings) as well as storage device specific integrity checks.
TXT basically allows you to measure various elements using the UEFI and more importantly for OEM's at least TXT has extensive DRM capabilities that can restrict the user from installing "untrusted" operating systems or making modifications to the host it self (e.g. chaging bios settings).
Beyond that TXT gives only a slight improvement as far as actual security goes against cold boot attacks as it allows you to take measurement when switching between S4 and S5 power states (soft off and hibernate) it still doesn't allow any measurement for S1-S3 states which are legacy sleep mode.
A modern UEFI with or without a TPM can ensure that the OS will not boot or will boot into recovery mode if any changes were made to the hardware or firmware configurations as well as if any tampering was done to the bootloader (secure boot keys) with a TPM you can be slightly more assured that no one tampered with anything since the TPM is a better cryptographic storage than the UEFI's ram/nvram.
I got bitten by this when I built up a system and picked a Core 2 Quad Q8200, only to discover after powering it on that it did NOT have virtualization support.
The problem is only worse now; is that i7-xxxx dual-core or quad-core? Should I get i5-yyyy instead?
http://ark.intel.com/products/36547/Intel-Core2-Quad-Process...
EDIT: I hit the post limit... Yes, I do think it was TSX
When it works, you get support for database-like transactions on RAM (only small transactions, it isn't black magic).
When it fails, you get all kinds of random crashes at random times.
Introduced in Haswell, turned out to be buggy and Intel famously disabled it with ucode update. Since then, they quietly disabled it also for several Broadwells and Skylakes which didn't fare much better than Haswell.
edit: it seems I misread parent's post as "what is TSX"
http://techreport.com/news/26911/errata-prompts-intel-to-dis...
Really can't blame them for that one. Disabling a feature that causes frequent CPU lockups when used is a good thing.
https://www.reddit.com/r/hardware/comments/44k218/intel_disa...
Also some Skylake i5s and i7s had TSX issues, but I don't know whether Intel managed to fix them or is going to disable TSX. So far ARK lists them as supported.
Side note (from comments) -- apparently Intel paired this microcode update with a patch to fix CPUs freezing during Prime95. Not cool.
Seeing as AMD are getting back into the game with their new Zen architecture, I think this is a very unwise move by Intel.
They advertised it as non-overclockable, but some users found out it was -- why bother patching? To force those users to buy the more expensive 'unlocked' chips for something that used to be free.
Do you mean like embedded backdoors?
They are much hardier than we give them credit for.
Many CPUs can achieve a significant overclock without raising the voltage.
Raising either voltage or frequency increases power dissipated. P = C V^2 f, where C is a constant that depends on the physical structure of the gate, V is the voltage, and f is the frequency that the gate's logic state is changing.
Thanks for the correction.
Prime95 slowly cooked several PCs that I had the pleasure of supporting through my years in college.
I love what Prime95 wants to do, but consumer PCs are not usually designed/maintained with 100% CPU usage in mind.
And the better solution is to finally ditch backwards compatibility with the 8086 and implement a sane instruction set that isn't just a virtualized layer à la x86
The virtualized instruction set enables the performance gains by executing portions of instructions in parallel, re-ordering to avoid pipeline stalls, better branch prediction, execution shortcuts depending on operanda, etc. without compiler support. RISC architectures like ARM do this as well. On a modern Cortex part with multiple execution units, the processor is not a textbook pipelined RISC processor like this community seems to yearn for. So if you look at machine code for some reason, yes the instruction set is simple, but it's still a facade over complexity.
I don't understand the constant cry that processors are complex. To gain performance against the frequency limit, complexity increased. This happens with software all the time.
Also, for those that want direct control over all the elements of the processor, go buy an Itanium... oh wait... no one did.
If you're advocating for a whole new instruction set, good luck with that. May as well go outside and yell at the clouds.
If it was advertised with no ability to overclock, you should assume it can't overclock and if you are able, don't assume it will work or will stick around forever.
"Note that Intel paired this with a bug fix for the freezing during Prime95 - if you want the bug fix, you have to let them lock down your clock. "
Also you can try to separate the Prime95 bugfix from the clock lockdown. Good luck :-)
"While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates during boot."
-- https://wiki.archlinux.org/index.php/microcode
now, do you update your kernel more or less often than the BIOS?
I agree with the first part, but no with the second. I don't like manufacturers deliberately breaking products which have already been sold, especially in cases when the sale wouldn't have happened if the product weren't better than specified.
Today it's Intel removing not advertised features, tomorrow it'll be Sony removing advertised ones (or had they already done that?)
On the other hand, if I remember correctly one of the mobo makers soon figured out how to use both the new microcode and the old one to get the best of both worlds; it might've been AsRock too...
Now, How much of that is true I don't know but that's what I remember reading at the time. A friend of mine did succesfully unlock his triple and ran for a long time.
It's called "binning", and it's not just for defects. CPUs from the same chain can have different tolerances, one will reach 3.5GHz easy and the next one won't be stable beyond 2.8. Those are also put in different bins and sold as different models.
> Now, How much of that is true I don't know but that's what I remember reading at the time.
It's completely correct. Selling a model from the exact corresponding bin is ideal, but if you have more demand than the bin provides you get parts from higher bins and gate them. A few years ago that got very very common with Intel parts as they reached tremendously low defect rates, and more or less any CPU you bought would come from the highest bins gated and undermultiplied to whichever model you'd buy.
Floorsweeps are done when a part of a chip isn't passing tests. The defective part gets fused off and the chip gets sold as a dual core instead of a quad core, for example.
Binning is orthogonal. It's a qualitative measurement of (the part of) a chip that passes all tests. The electrical and thermal properties of a chip are tested, e.g. the leakage current and temperature are measured at different clock speeds and voltages (this is infinitely more complex for a battery powered device where voltages and currents fluctuate). The ones that pass with best results are sold as a premium product and the rest are clocked down and sold for less.
So a "K" model Intel chip comes from the best bin. An i3 chip dual core is a floorswept quad core i5. (This is what I assume, I don't work for Intel and don't know the details)
But these chips may not sell in the proportion they get manufactured in, which means that some perfectly functional quad cores get fused to dual cores and sold for cheaper. If you're lucky, you're getting one of these (and un-fusing, if possible, will work).
Floorsweeping and binning are required because the tolerances of modern semiconductor manufacturing are so tight. To get the best bin to perform well, the manufacturing process is really pushed to the extreme, which means that there will be chips that have manufacturing defects as well as lower performing chips.
The "stand alone" math co-processor you could add to an SX based system to gain h/w floating point was actually a full blown 486 dx CPU with a different pin layout (one extra pin) so it couldn't be used as CPU and could therefore be priced differently.
I can build a large project in NetBeans as fast on this system as on a hex-core FX-6100 (and I can watch my CPU monitor clearly showing all four cores running during the build).
CPU temperatures stay well within limits with the stock cooler.
I am curious which AMD chips had the unlocking disabled?
I am still rocking AsRock 970 MB with AMD B50 which actually is an Athlon II X3 unlocked into a full blown Phenom II X4 (3 cores with no L3 cache into 4 cores with unlocked L3 cache).
It used to be that at least you could depend on the hardware staying the same unless you chose to apply patches yourself.
Is it theoretically possible to change the microcode to actually add more features instead of disabling them?
Let's say Zen actually comes out better than expected and then Intel miraculously releases another update which re-enables OC ability?
I know some recent Intel parts can't even run the EFI firmware without first getting a microcode update, but is Skylake like this too or can the EFI bootloader run without first getting microcode downloaded?
Remember the Haswell mess when a microcode patch disabled TSX ? If you applied it after user code (glibc) detected TSX support, boom.
Paradox :)
Probably it'll reset conveniently so that you can restore default BIOS settings.
They can't let it run because that wouldn't change anything and I'm not sure if the microcode has a way to reliably switch some off-chip clock generator back to 100MHz.
Workaround is renaming/deleting mcupdate_GenuineIntel.dll and not updating BIOS ever again to avoid new microcode, all to keep cheapest 4.4GHz single thread cpu money can get.
It breaks integrated graphics, turbo boost, all power saving states, temperature sensing, and cripples the performance of AVX instructions for some reason.
http://overclocking.guide/intel-skylake-non-k-overclocking-b...
I'd upgrade if I could get my hands on an AM4 motherboard. Hopefully we'll see something like the FX-6300 on AM4 early this year, so I can at least get ready to upgrade next year.
It is interesting though how Intel waited so far (not even a statement?) , probably just to sell more CPUs overall.
You cannot load old microcode anywhere. The CPU won't let you.
The OS feeds the CPU a blob, the CPU checks that it's signed by Intel (to prevent modifications), and it additionally checks that the version number is newer than the currently-running code. If it's not, it won't be loaded.
If you have a CPU with the old microcode versions, you can keep it around, but if you update your BIOS you'll find it will bring the new microcode in and you can't downgrade after boot. If you're lucky the BIOS manufacturer wasn't too careful with signing their BIOS and you can replace the microcode blob, but that's a huge hassle.
Usually the system firmware will include a recent-ish microcode and automatically update on boot. Many OSs also bundle microcode updates and install them on boot.
Did you read the last paragraph of my message? Because you're not really disputing anything I said. (to clarify, when I say "You cannot load old microcode anywhere", I define "old" to mean "older than the currently running microcode", I.E. you cannot downgrade it at runtime after it's gotten a new one loaded to RAM.
If you're willing to run outdated system firmware (with associated bugs, security vulnarbilities, etc), you can do it - just like I said in the message you're replying to. But that's not what I'd call a good solution.
Some of the non-overclockable cpus might work fine after overclocking, some might not. Intel definitely doesn't want the negative press when some kids decides to overclock their non-K CPU and break it during the process. So I understand the decision.
There would be no negative press for intel. Everyone with the shlightest knowledge about overclocking knows that overclocking can damage your parts. And like stated, parts breaking without voltage increase is highly unlikely. But still: Assume I buy an Intel Non-K processor, base-overclock it and it breaks. How on earth would I be able to produce negative press for Intel by publishing that?
It's simply a profit optimization. K-processors cost more, people who want to overclock had the option to buy non-K, that reduced sale numbers of the K line. Also the i7-6700 is clocked way below the i7-6700K, it was a nice option to get the cheaper version and up it to K level, saving 100€ for some time (prices changed).
Behavior like that is why I buy AMD.
It is not necessarily about damaging your parts; that would be the least of their worries. Unreliability of the CPU is the real problem. Your CPU might be 20% faster, but if it incorrectly computes some number in your spreadsheet, corrupts the file, or, worse, corrupts your file system without immediate consequences, or, even worse, makes hardware (drone, self-driving car, nuclear facility) behave incorrectly, they will not just have angry customers, but likely also lawsuits started against them (yes, they might win them, but not necessarily easily; people would complain that they should have closed that hole, given that they knew it was misused)
Also, that 'everybody with the slightest knowledge about overclocking knows' is only relevant as long as overclocking remains a niche thing. If it were mainstream, many of its users would not have 'the slightest knowledge about overclocking'. This microcode update helps keep it that way.
Which is why they've prevented over-clocking the whole time, except they haven't.
Their chips that allow over-clocking and the chips that don't are physically the same chips, there's nothing special about them. Intel is doing this only so that you can't buy a cheaper processor and get a more expensive processors performance.
I bought a 600MHz Celeron once, when the range was around 600MHz-1GHz. It overclocked stably to 900MHz. In essence I got a much faster processor for a much lower price. That is what Intel is fighting against, not some mythical lawsuit over life and limb.
Have you participated much in the overclocking community? The whole point is that every CPU chip is different and can be overclocked by different amounts, some almost not at all. There is no "negative press", since anything past stock speed is a bonus which is what overclockers are trying to get. If CPUs were not working at stock speeds, that would be a reason for "negative press".
On the other hand, there is no way that you can actually determine how far a CPU can be overclocked and still maintain full functionality, so it might be best to limit overclocking to systems that will not be used for something of high financial or safety value.
The problem is that fundamentally the hardware is still analog. Digital is an abstraction on top of the underlying analog system. In the digital abstraction, a signal changes instantaneously from 1 to 0 or from 0 to 1. In the underlying analog system, the components carrying the signal have capacitance and resistance. Changing the high voltage that represents 1 to the low voltage that represents 0, or vice versa, involves discharging or charging that capacitance through that resistance, and that takes time.
This sets an upper limit on how quickly that signal at that particular point in the circuit can change digital state.
There are also other ways the analog nature of the underlying circuit leaks into the digital realm. Neighboring components that are in the digital abstraction completely isolated from each other (except through intentional connections) might be coupled by stray capacitances and inductances. This can let signals on one cause noise on the other, or the state of one could change how fast the other can change state.
When a chip is designed the designers can figure out what areas are the most vulnerable to potential analog problems. They can incorporate into their tests checks to make sure that these areas are OK when the chip is operated in spec.
The ideal scenario is that if you clock a chip fast enough to break something, the chip blatantly fails and so you find out right away, and can slow it down a bit.
The frightening scenario is a data dependent glitch, where you end up with something like if the ALU has just completed a division with a negative numerator and an odd denominator and there has just been a branch prediction miss, then the zero flag will be set incorrectly.
If you run any hardware outside specifications, you expect it to fail. People brick phones and ruin engines but there isn't a backlash against people trying to jailbreak their phone or modify their cars. If anything, the people that matter —the enthusiast market for these devices— are demanding that their devices be more customisable. The press and other consumers don't give two hoots about little Jimmy trying to rice 5GHz out of his $100 CPU and turning it into liquid magma. Stupid kid was stupid.
The opposite is true though. If lil Jim manages to get a $5000 part for $100, other consumers are going to factor that into their purchasing decisions.
What is most concerning is that this is a part that has been out and about for a little while. There are dozens of guides recommending certain CPUs for this that Intel are going to patch up now. The articles and their recommendations will remain out there though. It's false advertising by the back door.