34 ms·

Your CPU may have slowed down on Wednesday

735 points by superkuh 5y ago

BeeOnRope 5y ago
Author here, happy for any feedback! Just a note that the title should be: Your CPU May Have Slowed Down on Wednesday
- superkuh 5y ago
  It was "Your..." when I submitted it. No idea how that changed. Regardless, fixed now.
  - exikyut 5y ago
    Most likely an Arc feature. bug* feature* (bug*)
  - deleted 5y ago
    [deleted]
  - chrismorgan 5y ago
    HN does various title mangling: capitalising things, removing words like “your” and numbers from the start, that kind of thing. I strongly dislike it because it harms titles far too often. Fortunately it allows you to second-guess it by going back and editing the title after submission.
    - BostonFern 5y ago
      How did that idea pass five minutes of contemplation?
      - chrismorgan 5y ago
        I imagine that it looks more reasonable when you see all the submitted titles; there may be many that it improves—I don’t know. (I still think it should be reviewed and probably curbed or discarded, but I’m confident that there’s a reason it’s there; dang knows that it regularly does harm to titles.)
      - OJFord 5y ago
        It desensationalises/de-clickbaitises/de-Buzzfeedises a lot of stuff. The submitter can edit it, and the edit doesn't go through the same sanitisation. Also if it's popular enough for a moderator to notice/they happen to, they often fix them too (or sanitise further in other cases).
- eps 5y ago
  The title is a click-bait. Please don't do this.
  - cto_of_antifa 5y ago
    9/10 doctors do it, though
  - BeeOnRope 5y ago
    Do you think that click-bait titles are ineffective, or effective but unethical, or something else?
    - amelius 5y ago
      They are unnecessarily vague/mysterious. Instead, the title should just state what is the case: "Intel CPU-update causes slowdown" or something like that.
      - cperciva 5y ago
        I think the "on Wednesday" bit is also significant since it tells us that this was a recent change (and one we probably weren't aware of). On the whole I'd say that the original title is much better than most.
        huhtenberg 5y ago
        Should've said "... this Wednesday" then. The way it's phrased implies a periodic event, which is what makes the title clickbaity.
        BeeOnRope 5y ago
        I specifically tried to avoid implying that (periodic). I think it would have to say "on Wednesdays" (note the s) to have that meaning. The title originally said "last Wednesday" but I waited too long to publish it and was actually two Wednesdays ago...
- Taniwha 5y ago
  Vaguely relatedly: I used to design graphics accelerators for Macs (back in the 90s) we got our best performance by spending time making writing 0s (or rather solid fills) really really fast (1.5Gb/s which was lot back then) - why? because as always whatever you'd do in hardware, the software guys would piss away - for example sometimes excel would erase the background 8 times before it ever wrote a black pixel - there was little point in speeding up those black (interesting, useful) pixels when speeding up the background white ones being written over and over on top of themselves was such a win
  - psykotic 5y ago
    In a similar vein, all non-tiled GPUs do some form of lossless framebuffer compression purely as a bandwidth optimization (it doesn't save on DRAM footprint because that would mess too much on the fly with the memory layout and you'd need to allocate for the worst case anyway). The simplest case is indeed fast clears (to any color/depth/stencil value) but it also works at a finer grain. It's essential for MSAA where a single pixel on your display is resolved from up to 16 subpixel samples which most of the time are strongly correlated. E.g. 1 constant color, or 2 constant colors separated by a line (from a triangle edge). And not just color but depth: with a 16x MSAA pixel covered by a single triangle you have 16 distinct depth values but they are all coplanar, so you can compress them losslessly by just storing the plane equation's coefficients.
    - Taniwha 5y ago
      Well that's sort of a different point - what I was more generally trying to point out is that sometimes you need to optimise for stupid stuff (and win bigly) ... because people actually do stupid things
- beebeepka 5y ago
  Here's my feedback: ditch your intel gear and get a recent AMD processor. See, we can also play that bait game
  - BeeOnRope 5y ago
    It doesn't have to be either/or! I have a Zen 2 box which I'm just starting to learn about.
  - noir_lord 5y ago
    Way ahead of you, I had an 1800X at work years ago which was a beast, current PC is a 2700X (wanted the 5950X but well can't buy one and the 5900X isn't really what I want but I digress) - love them. Last laptop I bought the missus at xmas was a Ryzen 4000 and that thing screams performance wise, incredible for 800 quid.
    - beebeepka 5y ago
      I've got two 3700x because 3900x and 3950x were unavailable for quite a while here in the dark parts of Europe. Wife has a really slick 1.1kg aluminium Lenovo with a 2500u, which we plan to replace with a couple of 5800u machines
- Angostura 5y ago
  I'm glad you are here. I came into comments on the off-chance to specifically say that I loved your writing style. Refreshing, witty, clear. Keep up the good work.
johndoe0815 5y ago
All these intransparent layers of low-level software (microcode, management engine code, device firmware blobs) are a nightmare from a security, reliability and maintainability point of view.
- aetherspawn 5y ago
  They need to be held accountable for performance regression at this scale if they don’t provide BIOS options to switch back.
  - BeeOnRope 5y ago
    If you apply your microcode using the OS loader (as described in the post), you can switch back to any microcode (which is at least as new as your BIOS version) by rebuilding the initramfs with the microcode of your choice and rebooting.
    - aetherspawn 5y ago
      How do I do this on a Windows workstation with stock BIOS/boot loader though? Who knows how much slower this machine, that I wait for 5-6 hours per day, has gotten in the last few years. IMO whoever flashes the patch should be responsible for giving a toggle.
      - floatboth 5y ago
        https://www.reddit.com/r/overclocking/comments/enm8yj/how_to_actually_disable_intel_and_amd_microcode/ https://www.reddit.com/r/overclocking/comments/enm8yj/how_to...
    - nix23 5y ago
      And under Windows with the VMware CPU Microcode Update Driver.
- marcan_42 5y ago
  This is purely an artifact of poor system design. x86 platforms are notoriously bad at this. I'm reverse engineering the Apple M1 and haven't found any trustability issues yet (besides the proprietary early stage bootloaders, but everything has that). There are some 12 or so coprocessors running proprietary firmware, but all of them are safely behind OS-controlled IOMMUs and not privileged to take over the system. There is no ME, no SMM, no TrustZone, nothing running with higher privilege than the OS. Most of the coprocessors have at least inspectable firmware (except the Secure Enclave, but you can just turn it off). The ARM architecture design makes it near impossible for an early boot backdoor to, say, run your OS in an undetectable VM too. No updatable microcode. On x86 you have the ME running secret code with higher privilege than the main CPU, as well as SMM running secret code on the main CPU at a higher privilege than the OS and stealing cycles from it, as well as a rather poor track record of proper IOMMU sandboxing (especially for anything that isn't a PCI device), and secret, encrypted microcode updates.
kevingadd 5y ago
"I am not convinced that removing any optimization which can be used in a timing-based side channel is sustainable." basically boils down over two decades of JavaScript (now WebAssembly) API and language design, where one subset of the committees fervently argues against any feature or primitive that could possibly be used to acquire timing information, no matter how useful. It's tough, because they are ALSO trying to make sure any advertiser on the planet can run code on your PC without your permission, so it is pretty important to stop that code from using timing side channels to capture your credit card number or something. Once it was proven that JavaScript could trigger rowhammer (I remember having debates about this during wasm spec meetings at the time when it was still speculative), that kind of guaranteed that the side-channel people would remain in control, I think. SharedArrayBuffer is the biggest example - we basically had safe multithreaded memory access available in browsers but it got disabled due to spectre/meltdown, and we only started getting it back relatively recently with lots of additional constraints to try and make it "safe". Want high-precision timestamps? Not anymore you don't, it's a side-channel! Similarly, when a new browser update goes out it may or may not make all the web apps you rely on slower (or break them), so any web benchmarking also needs to be re-run from scratch on a regular basis. New Chrome and Firefox releases "ride the trains" every 6 weeks or so, and they quietly push changes to the browser more frequently than that which can occasionally impact perf or behavior too.
- dsign 5y ago
  Now, if it were limited to browsers, or even to desktop computers... "Security by default" affects, by default, also trusted workloads. Games, desktop editing software, word processors, spreadsheets running dumb totals in big tables, and virtualized computing workloads running in the cloud (where it has a serious financial impact for whoever pays the cloud bill). All of them pay the Javascript tax. Worse, there doesn't seem to be any solution in sight, we have become too reliant on the damn thing.
  - detaro 5y ago
    > virtualized computing workloads running in the cloud as trusted workloads?
jmakov 5y ago
mitigations=off
- BeeOnRope 5y ago
  This won't restore your performance in this case: the microcode changes the behavior of the zero store optimization without any action from the kernel. If you accept the new microcode, you get the new, slower behavior. Perhaps there is an MSR bit you can flip to set the behavior back to the old way, but none has emerged so far.
  - johnisgood 5y ago
    Thankfully I do save all of the microcodes, so I can just use an early version by simply rebuilding the initramfs. I also hold that package back on Arch, so it does not get upgraded. Might want to look for them here: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... As to how to actually use those files to get your "intel-ucode.img", just take a look at: https://archlinux.org/packages/extra/any/intel-ucode/ https://archlinux.org/packages/extra/any/intel-ucode/ For the "iucode_tool": https://gitlab.com/iucode-tool/iucode-tool/-/wikis/home https://gitlab.com/iucode-tool/iucode-tool/-/wikis/home The actual PKGBUILD for it on Arch Linux: https://github.com/archlinux/svntogit-packages/blob/packages/intel-ucode/trunk/PKGBUILD https://github.com/archlinux/svntogit-packages/blob/packages... --- cd Intel-Linux-Processor-Microcode-Data-Files-microcode-${pkgver/./} rm -f intel-ucode{,-with-caveats}/list mkdir -p kernel/x86/microcode iucode_tool --write-earlyfw=intel-ucode.img intel-ucode{,-with-caveats}/ The above gives you "intel-ucode.img". Copy it to "/boot/". Run "mkinitcpio -p linux" or the like.
- georgyo 5y ago
  This likely would not help here. It is blamed on the cpu's microcode, not the kernel's mitigations.
  - gmueckl 5y ago
    If that's the case, the microcode update happens some time during the boot process. It isn't persistent. It's either in the firmware or the OS. If it's on Linux, you can disable the boot script that performs the microcode update or patch it to update an older microcode image and you're done.
vmception 5y ago
> Is there a new crypto-coin based on who can store the most zeros You jest but…..
- theturtletalks 5y ago
  Chia Coin?
- ZephyrBlu 5y ago
  Rule 34 but for crypto.
  - vmception 5y ago
    If you can imagine it, it exists But partially because you like money and can make it exist pretty easily and cheaply
- loser777 5y ago
  A bit too close to Bitcon's proof of work scheme, of all things...
qwerty456127 5y ago
All these mitigations should really be disablable. I have a computer which is not connected to the Internet I use to run number-crunching tasks and play relatively-old single-player games, but I still update it periodically. Obviously I don't need any such performance-killing mitigations there.
- yvdriess 5y ago
  You can, to some extent. One of the side notes in the article addresses this point, the microcode version can be held back to an earlier version.
  - deleted 5y ago
    [deleted]
  - Laforet 5y ago
    Staying on an earlier version is not ideal as some of the later microcode updates actually contain useful errata beyond performance-limiting mitigations. Really wish Windows had an option like "mitigations=off" in Linux.
    - deleted 5y ago
      [deleted]
    - zamadatix 5y ago
      "mitigitations=off" doesn't disable microcode mitigations like the one in this article.
      - Laforet 5y ago
        Yes, I assume the kernel has a predetermined list of microcode to be disabled when the flag is set. The same should be doable in Windows right now but the process seems quite tedious.
        zamadatix 5y ago
0x_rs 5y ago
Older thinkpads are perfectly fine machines still today—until not. The performance blow to Sandy Bridge from all mitigations I've experienced is significant, especially so in SSD I/O speeds (still fast enough, though). A saddening state of affairs, I hope nothing like the Core-era CPUs market domination will ever happen again, I hate being struck with one option alone.
- himlion 5y ago
  ARM/M1 family will be plenty of competition I think.
  - reader_mode 5y ago
    What ARM device outside of M1 is competitive for desktop ?
    - vbezhenar 5y ago
      None that I'm aware off. But Qualcomm promises to release desktop CPU soon. I don't have high hopes and it probably won't surpass Intel, but I think that it'll be competitive enough to be interesting.
      - reader_mode 5y ago
        Qualcomm already has that Microsoft Surface X1 chip and it's terrible. They acquired a player in this space recently but from what I saw that's two years away from launching. I'd have higher hopes Samsung pulls something off with their fab but still skeptical. Apple seems to be generations ahead in this space.
        torginus 5y ago
        Imo, it's not that bad, about the level of an entry-level 8th gen Intel Core chip. The problem came with the generally sorry state of x86 emulation (and lack of native support).
varjag 5y ago
We've entered Inverse Moore's Law: every two years single core performance drops 20% as optimizations exploits are mitigated.
- admissionsguy 5y ago
  We are already there, to be honest. 20% every two years is negligible compared to growing inefficiency of software. I have to replace my computer every several years due to performance degradation, even though my workflow has remained the same for over a decade. Even editing simple text documents has become painfully slow on my 2013 Macbook Pro. M1 gives me a few years breathing space, hopefully, but I'm sure it won't be able to open a 1KB text file instantaneously in 5 years.
  - remexre 5y ago
    Isn't the solution there to use software that puts more emphasis on efficient use of resources? The corollary to Wirth's law is that as time goes on, deleting crap from your machine becomes more and more effective -- I was using Neovim on a Thinkpad T60 at work in 2018, and loving it.
    - MagnumOpus 5y ago
      I am using Office 2003 on my home computers and it is snappy and instantaneous. I wish I could use Windows XP with up-to-date hardware support and security updates, too. I remember the days of requiring on 300MHz core, 64MB of ram and 1GB of hard disk for the same functionality that Win10 now provides in a worse way.
      - dmitrygr 5y ago
        Win10LTSB + vmware workstation fullscreen + xp/2000 vm works wonderfully and is very fast!
    - ratww 5y ago
      This is one solution. Sometimes I use Sublime Text 3 on my old 2GB MB Air, to code mostly 3D graphics, sometimes backends, some web dev as well. However, on my beefy i9 work laptop I need to use Microsoft Teams and also Docker, which means the fan is on half the time and the computer can barely keep up with the workload. I've seriously considering asking for another computer just to run Teams.
5e92cb50239222b 5y ago
Thankfully, this doesn't seem to affect my Haswell machine. A microcode update was installed on 2021-06-09, but the microcode loader reports its build date as 2019-11-12. Does this vulnerability not affect older microarchitectures, or does Intel no longer bother updating them? I couldn't find any details in CVE.
- BeeOnRope 5y ago
  It isn't clear if Haswell has this optimization. As an easy test you could run the zero-fill-bench linked in the post and check the fill0 vs fill1 numbers. If they are the same, Haswell probably never had this optimization in the first place. Based on the Intel microcode release note [1] it doesn't seem like client HSW got any update this time, only HSX (Haswell Xeon). --- [1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commit/3f97690f0da8011f52209b232450a1e5c4f2e1f6#diff-e6fad0f2abbac6c9603b2e8f88fe1d151a83de708aeca1c1d93d881c958ecba4 https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
- icegreentea2 5y ago
  From the post about the original finding (https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt.html https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt...), it looks like Haswell did not have this optimization to begin with (find section Hardware Survey and look at the different architectures - specifically looking for divergence in performance at L3 and RAM between orange and blue dots).
blarg1 5y ago
Does anyone know what could potentially be accessed through these exploits? Like could we just not use the browser's password manager or use a separate browser for sensitive websites (eg banking)?
pdimitar 5y ago
Is there a way to selectively disable mitigations on Macs?
lifeisstillgood 5y ago
It seems to me that almost all optimisations (and especially the accumulation of optimisations that we want to get more performance), that all optimisations are going to be vulnerable in some way to timing attacks. After all an optimisation is designed to alter the timing. If all actions must have the same timing, optimisations fail. Do we simply offload any sesnitive processing to specialised chips? The silicon wafer seems to be developing vulnerablities like a network.
- lmm 5y ago
  We need to stop trying to do transparent caching, and instead give developers control over what happens. Itanium wasn't wrong, it was just ahead of its time.
  - pjmlp 5y ago
    I keep wishing that on an alternative reality AMD would have lost access to x86 IP, thus never coming up with x64 as cheap alternative to Itanium.
    - geogra4 5y ago
      I think x64 WAS Itanium. x86-64 is the beast we are dealing with today. In that world maybe everyone goes to PowerPc? The move from 32bit G4 to 64bit G5 cpu wasn't a big deal since the PPC had 64bit variations back in 1997 with the 620 (though apple never used it)
      - pjmlp 5y ago
        Everyone would go where Windows would go, as far as I remember PowerPC Windows NT did not got much love.
        geogra4 5y ago
        Yeah, that was kind of tongue-in-cheek. Apple knows when to leave a cpu architecture. They've done it 3 times already (M68k->PPC->x86->ARM) Though I think we're getting now to the point that we would have gotten to then. AMD bought x86 another 15 years of life.
jokoon 5y ago
Is that directly related to Spectre/Meltdown? Is that microcode fix somehow better than mitigations in the kernel? I wonder if it will allow AMD to catch up even further (even though AMD CPU were also affected).
- BeeOnRope 5y ago
  Well Spectre (not Meltdown) is a broad class of bugs, and whether something is Spectre or not often just comes down to whether the author chooses to put their side-channel attack in that bucket. That said, I don't think this is related to any of the named Spectre variants.
Aardwolf 5y ago
So many of the performance-reducing security are related to timing attacks. Would perhaps a solution to this be to have mixed cores: some cores intended for managing passwords and other secure data with all the performance reducing mitigations to avoid timing attacks. Other cores completely unlocked, no mitigations, and intended for non-secure computation (gaming, number crunching, ...). Then let the OS and programmers ensure it's known which computation is marked as secure and which is not, to decide on which cores it can be ran.
- bluGill 5y ago
  No. I've erased this reply several times as I thought of a mitigation to the problem I was going to state - but in the end nothing mitigates everything. Most of the ways to make this work are hard to get right - it is too easy to forget to mark something as unsafe, or in some other way allow data to the fast cores that the fast cores shouldn't have. Even if you figure out how to do it though, you can still fall to a double failure: your safe code doesn't leak passwords via a timing attack, but via something else (buffer overflow?) it leaks the password to the unsafe side, which in turn leaks it via a timing attack.
z3t4 5y ago
I see many comments about people wanting to turn off the mitigations. Just remember that you are currently running a virtual machine (your browser) that lets anyone (the web sites you visit) to run code on your machine.
- sp332 5y ago
  CPUs have a bajillion cores these days. Can we keep mitigations enabled for a few of them and run browsers over there, and keep the rest of the system fast?
snovv_crash 5y ago
The only way we can actually stop timing-based side channel attacks is by having deterministic (in time) execution. The only way that can happen is by running at the slowest hypothetical rate for every individual operation. So, no cache, dedicated CPU timeslices, dedicated RAM bandwidth. Luckily, we only need this for untrusted code. What really peaves me is that trusted code is now having to run slower as well.
- wffurr 5y ago
  With supply chain attacks, all code is untrusted.
  - andrewinardeer 5y ago
    Unless you mine your own silicon all hardware is untrusted.
    - FredPret 5y ago
      Only if you write every bit of code and trust every person involved in the entire value chain
      - kirubakaran 5y ago
        But even then, do you trust yourself?
        FredPret 5y ago
        Right, what if you’ve been Inception-ed by an adversary
        FranchuFranchu 5y ago
        Maybe the NSA installed a backdoor in your brain.
  - ant6n 5y ago
rvba 5y ago
Make processors which are 10% faster than competition by dubious security practices. After some time slow the processors down by 20% because various corner cutting practices are detected. First you kill AMD with "efficiency". Then you "encourage" users to upgrade, since secutity updates make this efficiency disappear. How is this even legal.
rij111 5y ago
WTF. I thought my grandma's Laptop purely catering to her Netflix addiction was just Windows glitching and spent 4 hrs downloading and installing Ubuntu on it.
yabones 5y ago
What's the sustainable solution here? Do we give up and let our performance erode back to where it was a decade ago? Do we just let the vulnerabilities pile up until somebody starts exploiting them? Or do we create an entirely new 'premium' CPU architecture that is designed from the ground up around security, and have an underclass of insecure and dangerous devices?
ajsnigrutin 5y ago
If my washing machine suddenly decided it needed longer time to wash a load of clothes, that would be a change of specifications after the fact, and I'd be able to return it to the store without issues. So... why not with CPUs?
- showsover 5y ago
  It's not a washing machine, it's a tiny motor inside the washing machine that only works with that model. What CPU are you replacing it with? Most if not all modern CPUs are vulnerable to this so changing it makes little sense. Even if you can change it, you'd need to switch motherboard as well.
  - ajsnigrutin 5y ago
    I, as a consumer, don't care... I bring the whole washing machine to the store and get my money back, because they changed the specs after i bought it. Then with that money I can do whatever I want... eg. buy an AMD washing machine... or generally a newer, faster one, becuase some time has gone by. Or go on a vacation. Or drugs and prostitutes.
  - makeitdouble 5y ago
    To parent's point, currently the risk is all pushed on the customer. We wouldn't accept that on any generic customer product. We'd recall whole fleet of cars if they had severe flaws that directly affect their performance. There might not be viable alternatives, but there should be at least something from CPU makers to help swallow the pill.
- trynumber9 5y ago
  You can still operate it with the original specifications. Do not apply the microcode if it's that important to your workload. Just remember to avoid running untrusted code.
  - ajsnigrutin 5y ago
    So i have two options: - keep the old "firmware", and risk the machine catching fire - put the new firmware on, and make it wash slower Yeah... I'll choose returning it to the store.
BuckRogers 5y ago
I just built a Rocket Lake desktop, I wonder if the architecture updates to Willow Cove removed the need for this mitigation.
e40 5y ago
My PleX server last week, running on CentOS 7 in a docker container, seemed to have trouble with streams that previously played fine. There was a kernel update for CentOS 7.x recently, too. Now I'm wondering if this is the cause. The container hasn't been rebuilt in many months (like 7) and the only thing that has changed on the machine is CentOS updates.
Avernar 5y ago
As with anything, we have to ask ourselves why are we offloading the responsibility to the OS providers to solve this, when we really have to determine for ourselves if the risk is even a risk at all on our individual systems. Do I care about this hard to exploit vulnerability on a web server that's streaming video content to the public? No. Does it matter on a DB server with important financial data? Yes it does. Applying the patch should be opt-in if you ask me. But of course, most sysadmins are hopeless. So then the OS vendors push it out, it's safer than letting the decision to uninformed people.
- Spivak 5y ago
  This "but people are stupid and uninformed" mentality has really got to stop. If you find yourself making an argument that hinges on everyone but you or some large population being idiots then you're wrong. Not only because people aren't stupid but doubly because you're specifically talking about a population of highly educated people who start as developers and get interested in infra. Sysadmins/DevOps/SREs aren't hopeless, they just have different incentives and responsibilities. Default secure with the option to let down your guard when the need is there is always always the right choice. You wouldn't have your firewall default allow with a blocklist. You wouldn't grant everyone sudo access and then maintain a list of commands they can't execute. Such a thing is impossible to maintain. For me specifically I manage too many servers to bother with this. It's going to be deployed to everything without exception and if you need more performance we'll rack more hardware. The cost of more CPUs is less than the risk that something will slip through the cracks. I don't care that your pet service doesn't execute any untrusted code, I'm not carving out exceptions when I have 20 teams constantly asking for stuff.
  - whatshisface 5y ago
    >I'm not carving out exceptions when I have 20 teams constantly asking for stuff. Sounds like your IT department is severely understaffed and is unable to meet the needs of the developers without reducing service.
    - orhmeh09 5y ago
einpoklum 5y ago
If I run vanilla Debian stable, would I have gotten this kind of an update?
zelon88 5y ago
You know, just 10 short years ago whenever someone had a problem with an AMD chip, the overwhelming response from the tech community was "dude, just get an Intel. They are way better." So pardon me, but from a lifelong AMD enthusiast, you all deserve this... "Hey guys, why are you still running Intel? That shit is like 2 generations behind my AMD in performance and reliability." Damn, that felt good.
- CyberDildonics 5y ago
  Reliability? It isn't a car, it doesn't wear out. Also why would you be a life long enthusiast of a specific company? Why not buy what works best at any point in time?
  - zelon88 5y ago
    Because Wintel has always displayed bad sportsmanship and anti competitive practices. I don't want a winner who wins because they cheat. Also, AMD almost lost everything. At one point they had to sell their own HQ and lease it back to generate cashflow and keep the doors open. If they had closed, Intel research budgets would tank. They wouldn't have nearly as much incentive to innovate. Without Dodge motor company you would still be driving a Ford Model T in black. If AMD died instead of making the original Athlon, you would still be stuck with a Pentium MMX because Intel could have stopped innovating and kept their market share.
  - R0b0t1 5y ago
    It does wear out. As a general rule everything with moving parts can wear out, and a CPU is full of moving electrons. https://en.wikipedia.org/wiki/Electromigration https://en.wikipedia.org/wiki/Electromigration It takes on the order of 100 years for well made modern CPUs to fail due to these effects, but poorly made CPUs could fail far earlier. There are likely some nonzero number of failures attributable to electromigration. There are some people who buy overclockable parts and don't overclock them because they are more robust. It's unknown exactly how or why CPUs fail. Taking them apart to check is an extremely expensive endeavor. But sometimes they do.
zelon88 5y ago
How would we know if Intel started disabling features that they explicitly marketed? I believe removing or reducing the functionality of a product that was sold under the pretense of a certain level of performance would warrant class action. That's like Ford selling a truck with 500hp and then later recalling it to detune it to 400hp. The truck I have is no longer the truck I wanted or the truck I paid for. Ford owes me what it said on the label. What if Intel wanted to sandbag existing products to promote new ones?
- efreak 5y ago
  > What if Intel wanted to sandbag existing products to promote new ones? IANAL, but I'd guess that this is maybe similar to Sony removing OtherOS in a firmware update, and that you could sue Intel for it. Or maybe not, since you can actually disable microcode updates.

735 points by superkuh 5y ago

BeeOnRope 5y ago

Author here, happy for any feedback! Just a note that the title should be: Your CPU May Have Slowed Down on Wednesday

superkuh 5y ago
It was "Your..." when I submitted it. No idea how that changed. Regardless, fixed now.
- exikyut 5y ago
  Most likely an Arc feature. bug* feature* (bug*)
- deleted 5y ago
  [deleted]
- chrismorgan 5y ago
  HN does various title mangling: capitalising things, removing words like “your” and numbers from the start, that kind of thing. I strongly dislike it because it harms titles far too often. Fortunately it allows you to second-guess it by going back and editing the title after submission.
  - BostonFern 5y ago
    How did that idea pass five minutes of contemplation?
    - chrismorgan 5y ago
      I imagine that it looks more reasonable when you see all the submitted titles; there may be many that it improves—I don’t know. (I still think it should be reviewed and probably curbed or discarded, but I’m confident that there’s a reason it’s there; dang knows that it regularly does harm to titles.)
    - OJFord 5y ago
      It desensationalises/de-clickbaitises/de-Buzzfeedises a lot of stuff. The submitter can edit it, and the edit doesn't go through the same sanitisation. Also if it's popular enough for a moderator to notice/they happen to, they often fix them too (or sanitise further in other cases).
eps 5y ago
The title is a click-bait. Please don't do this.
- cto_of_antifa 5y ago
  9/10 doctors do it, though
- BeeOnRope 5y ago
  Do you think that click-bait titles are ineffective, or effective but unethical, or something else?
  - amelius 5y ago
    They are unnecessarily vague/mysterious. Instead, the title should just state what is the case: "Intel CPU-update causes slowdown" or something like that.
    - cperciva 5y ago
      I think the "on Wednesday" bit is also significant since it tells us that this was a recent change (and one we probably weren't aware of). On the whole I'd say that the original title is much better than most.
      - huhtenberg 5y ago
        Should've said "... this Wednesday" then. The way it's phrased implies a periodic event, which is what makes the title clickbaity.
        BeeOnRope 5y ago
        I specifically tried to avoid implying that (periodic). I think it would have to say "on Wednesdays" (note the s) to have that meaning. The title originally said "last Wednesday" but I waited too long to publish it and was actually two Wednesdays ago...
Taniwha 5y ago
Vaguely relatedly: I used to design graphics accelerators for Macs (back in the 90s) we got our best performance by spending time making writing 0s (or rather solid fills) really really fast (1.5Gb/s which was lot back then) - why? because as always whatever you'd do in hardware, the software guys would piss away - for example sometimes excel would erase the background 8 times before it ever wrote a black pixel - there was little point in speeding up those black (interesting, useful) pixels when speeding up the background white ones being written over and over on top of themselves was such a win
- psykotic 5y ago
  In a similar vein, all non-tiled GPUs do some form of lossless framebuffer compression purely as a bandwidth optimization (it doesn't save on DRAM footprint because that would mess too much on the fly with the memory layout and you'd need to allocate for the worst case anyway). The simplest case is indeed fast clears (to any color/depth/stencil value) but it also works at a finer grain. It's essential for MSAA where a single pixel on your display is resolved from up to 16 subpixel samples which most of the time are strongly correlated. E.g. 1 constant color, or 2 constant colors separated by a line (from a triangle edge). And not just color but depth: with a 16x MSAA pixel covered by a single triangle you have 16 distinct depth values but they are all coplanar, so you can compress them losslessly by just storing the plane equation's coefficients.
  - Taniwha 5y ago
    Well that's sort of a different point - what I was more generally trying to point out is that sometimes you need to optimise for stupid stuff (and win bigly) ... because people actually do stupid things
beebeepka 5y ago
Here's my feedback: ditch your intel gear and get a recent AMD processor. See, we can also play that bait game
- BeeOnRope 5y ago
  It doesn't have to be either/or! I have a Zen 2 box which I'm just starting to learn about.
- noir_lord 5y ago
  Way ahead of you, I had an 1800X at work years ago which was a beast, current PC is a 2700X (wanted the 5950X but well can't buy one and the 5900X isn't really what I want but I digress) - love them. Last laptop I bought the missus at xmas was a Ryzen 4000 and that thing screams performance wise, incredible for 800 quid.
  - beebeepka 5y ago
    I've got two 3700x because 3900x and 3950x were unavailable for quite a while here in the dark parts of Europe. Wife has a really slick 1.1kg aluminium Lenovo with a 2500u, which we plan to replace with a couple of 5800u machines
Angostura 5y ago
I'm glad you are here. I came into comments on the off-chance to specifically say that I loved your writing style. Refreshing, witty, clear. Keep up the good work.

johndoe0815 5y ago

All these intransparent layers of low-level software (microcode, management engine code, device firmware blobs) are a nightmare from a security, reliability and maintainability point of view.

aetherspawn 5y ago
They need to be held accountable for performance regression at this scale if they don’t provide BIOS options to switch back.
- BeeOnRope 5y ago
  If you apply your microcode using the OS loader (as described in the post), you can switch back to any microcode (which is at least as new as your BIOS version) by rebuilding the initramfs with the microcode of your choice and rebooting.
  - aetherspawn 5y ago
    How do I do this on a Windows workstation with stock BIOS/boot loader though? Who knows how much slower this machine, that I wait for 5-6 hours per day, has gotten in the last few years. IMO whoever flashes the patch should be responsible for giving a toggle.
    - floatboth 5y ago
      https://www.reddit.com/r/overclocking/comments/enm8yj/how_to_actually_disable_intel_and_amd_microcode/ https://www.reddit.com/r/overclocking/comments/enm8yj/how_to...
  - nix23 5y ago
    And under Windows with the VMware CPU Microcode Update Driver.
marcan_42 5y ago
This is purely an artifact of poor system design. x86 platforms are notoriously bad at this. I'm reverse engineering the Apple M1 and haven't found any trustability issues yet (besides the proprietary early stage bootloaders, but everything has that). There are some 12 or so coprocessors running proprietary firmware, but all of them are safely behind OS-controlled IOMMUs and not privileged to take over the system. There is no ME, no SMM, no TrustZone, nothing running with higher privilege than the OS. Most of the coprocessors have at least inspectable firmware (except the Secure Enclave, but you can just turn it off). The ARM architecture design makes it near impossible for an early boot backdoor to, say, run your OS in an undetectable VM too. No updatable microcode. On x86 you have the ME running secret code with higher privilege than the main CPU, as well as SMM running secret code on the main CPU at a higher privilege than the OS and stealing cycles from it, as well as a rather poor track record of proper IOMMU sandboxing (especially for anything that isn't a PCI device), and secret, encrypted microcode updates.

kevingadd 5y ago

"I am not convinced that removing any optimization which can be used in a timing-based side channel is sustainable." basically boils down over two decades of JavaScript (now WebAssembly) API and language design, where one subset of the committees fervently argues against any feature or primitive that could possibly be used to acquire timing information, no matter how useful. It's tough, because they are ALSO trying to make sure any advertiser on the planet can run code on your PC without your permission, so it is pretty important to stop that code from using timing side channels to capture your credit card number or something. Once it was proven that JavaScript could trigger rowhammer (I remember having debates about this during wasm spec meetings at the time when it was still speculative), that kind of guaranteed that the side-channel people would remain in control, I think. SharedArrayBuffer is the biggest example - we basically had safe multithreaded memory access available in browsers but it got disabled due to spectre/meltdown, and we only started getting it back relatively recently with lots of additional constraints to try and make it "safe". Want high-precision timestamps? Not anymore you don't, it's a side-channel! Similarly, when a new browser update goes out it may or may not make all the web apps you rely on slower (or break them), so any web benchmarking also needs to be re-run from scratch on a regular basis. New Chrome and Firefox releases "ride the trains" every 6 weeks or so, and they quietly push changes to the browser more frequently than that which can occasionally impact perf or behavior too.

dsign 5y ago
Now, if it were limited to browsers, or even to desktop computers... "Security by default" affects, by default, also trusted workloads. Games, desktop editing software, word processors, spreadsheets running dumb totals in big tables, and virtualized computing workloads running in the cloud (where it has a serious financial impact for whoever pays the cloud bill). All of them pay the Javascript tax. Worse, there doesn't seem to be any solution in sight, we have become too reliant on the damn thing.
- detaro 5y ago
  > virtualized computing workloads running in the cloud as trusted workloads?

jmakov 5y ago

mitigations=off

BeeOnRope 5y ago
This won't restore your performance in this case: the microcode changes the behavior of the zero store optimization without any action from the kernel. If you accept the new microcode, you get the new, slower behavior. Perhaps there is an MSR bit you can flip to set the behavior back to the old way, but none has emerged so far.
- johnisgood 5y ago
  Thankfully I do save all of the microcodes, so I can just use an early version by simply rebuilding the initramfs. I also hold that package back on Arch, so it does not get upgraded. Might want to look for them here: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... As to how to actually use those files to get your "intel-ucode.img", just take a look at: https://archlinux.org/packages/extra/any/intel-ucode/ https://archlinux.org/packages/extra/any/intel-ucode/ For the "iucode_tool": https://gitlab.com/iucode-tool/iucode-tool/-/wikis/home https://gitlab.com/iucode-tool/iucode-tool/-/wikis/home The actual PKGBUILD for it on Arch Linux: https://github.com/archlinux/svntogit-packages/blob/packages/intel-ucode/trunk/PKGBUILD https://github.com/archlinux/svntogit-packages/blob/packages... --- cd Intel-Linux-Processor-Microcode-Data-Files-microcode-${pkgver/./} rm -f intel-ucode{,-with-caveats}/list mkdir -p kernel/x86/microcode iucode_tool --write-earlyfw=intel-ucode.img intel-ucode{,-with-caveats}/ The above gives you "intel-ucode.img". Copy it to "/boot/". Run "mkinitcpio -p linux" or the like.
georgyo 5y ago
This likely would not help here. It is blamed on the cpu's microcode, not the kernel's mitigations.
- gmueckl 5y ago
  If that's the case, the microcode update happens some time during the boot process. It isn't persistent. It's either in the firmware or the OS. If it's on Linux, you can disable the boot script that performs the microcode update or patch it to update an older microcode image and you're done.

vmception 5y ago

> Is there a new crypto-coin based on who can store the most zeros You jest but…..

theturtletalks 5y ago
Chia Coin?
ZephyrBlu 5y ago
Rule 34 but for crypto.
- vmception 5y ago
  If you can imagine it, it exists But partially because you like money and can make it exist pretty easily and cheaply
loser777 5y ago
A bit too close to Bitcon's proof of work scheme, of all things...

qwerty456127 5y ago

All these mitigations should really be disablable. I have a computer which is not connected to the Internet I use to run number-crunching tasks and play relatively-old single-player games, but I still update it periodically. Obviously I don't need any such performance-killing mitigations there.

yvdriess 5y ago
You can, to some extent. One of the side notes in the article addresses this point, the microcode version can be held back to an earlier version.
- deleted 5y ago
  [deleted]
- Laforet 5y ago
  Staying on an earlier version is not ideal as some of the later microcode updates actually contain useful errata beyond performance-limiting mitigations. Really wish Windows had an option like "mitigations=off" in Linux.
  - deleted 5y ago
    [deleted]
  - zamadatix 5y ago
    "mitigitations=off" doesn't disable microcode mitigations like the one in this article.
    - Laforet 5y ago
      Yes, I assume the kernel has a predetermined list of microcode to be disabled when the flag is set. The same should be doable in Windows right now but the process seems quite tedious.
      - zamadatix 5y ago

0x_rs 5y ago

Older thinkpads are perfectly fine machines still today—until not. The performance blow to Sandy Bridge from all mitigations I've experienced is significant, especially so in SSD I/O speeds (still fast enough, though). A saddening state of affairs, I hope nothing like the Core-era CPUs market domination will ever happen again, I hate being struck with one option alone.

himlion 5y ago
ARM/M1 family will be plenty of competition I think.
- reader_mode 5y ago
  What ARM device outside of M1 is competitive for desktop ?
  - vbezhenar 5y ago
    None that I'm aware off. But Qualcomm promises to release desktop CPU soon. I don't have high hopes and it probably won't surpass Intel, but I think that it'll be competitive enough to be interesting.
    - reader_mode 5y ago
      Qualcomm already has that Microsoft Surface X1 chip and it's terrible. They acquired a player in this space recently but from what I saw that's two years away from launching. I'd have higher hopes Samsung pulls something off with their fab but still skeptical. Apple seems to be generations ahead in this space.
      - torginus 5y ago
        Imo, it's not that bad, about the level of an entry-level 8th gen Intel Core chip. The problem came with the generally sorry state of x86 emulation (and lack of native support).

varjag 5y ago

We've entered Inverse Moore's Law: every two years single core performance drops 20% as optimizations exploits are mitigated.

admissionsguy 5y ago
We are already there, to be honest. 20% every two years is negligible compared to growing inefficiency of software. I have to replace my computer every several years due to performance degradation, even though my workflow has remained the same for over a decade. Even editing simple text documents has become painfully slow on my 2013 Macbook Pro. M1 gives me a few years breathing space, hopefully, but I'm sure it won't be able to open a 1KB text file instantaneously in 5 years.
- remexre 5y ago
  Isn't the solution there to use software that puts more emphasis on efficient use of resources? The corollary to Wirth's law is that as time goes on, deleting crap from your machine becomes more and more effective -- I was using Neovim on a Thinkpad T60 at work in 2018, and loving it.
  - MagnumOpus 5y ago
    I am using Office 2003 on my home computers and it is snappy and instantaneous. I wish I could use Windows XP with up-to-date hardware support and security updates, too. I remember the days of requiring on 300MHz core, 64MB of ram and 1GB of hard disk for the same functionality that Win10 now provides in a worse way.
    - dmitrygr 5y ago
      Win10LTSB + vmware workstation fullscreen + xp/2000 vm works wonderfully and is very fast!
  - ratww 5y ago
    This is one solution. Sometimes I use Sublime Text 3 on my old 2GB MB Air, to code mostly 3D graphics, sometimes backends, some web dev as well. However, on my beefy i9 work laptop I need to use Microsoft Teams and also Docker, which means the fan is on half the time and the computer can barely keep up with the workload. I've seriously considering asking for another computer just to run Teams.

5e92cb50239222b 5y ago

Thankfully, this doesn't seem to affect my Haswell machine. A microcode update was installed on 2021-06-09, but the microcode loader reports its build date as 2019-11-12. Does this vulnerability not affect older microarchitectures, or does Intel no longer bother updating them? I couldn't find any details in CVE.

BeeOnRope 5y ago
It isn't clear if Haswell has this optimization. As an easy test you could run the zero-fill-bench linked in the post and check the fill0 vs fill1 numbers. If they are the same, Haswell probably never had this optimization in the first place. Based on the Intel microcode release note [1] it doesn't seem like client HSW got any update this time, only HSX (Haswell Xeon). --- [1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commit/3f97690f0da8011f52209b232450a1e5c4f2e1f6#diff-e6fad0f2abbac6c9603b2e8f88fe1d151a83de708aeca1c1d93d881c958ecba4 https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
icegreentea2 5y ago
From the post about the original finding (https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt.html https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt...), it looks like Haswell did not have this optimization to begin with (find section Hardware Survey and look at the different architectures - specifically looking for divergence in performance at L3 and RAM between orange and blue dots).

blarg1 5y ago

Does anyone know what could potentially be accessed through these exploits? Like could we just not use the browser's password manager or use a separate browser for sensitive websites (eg banking)?

pdimitar 5y ago

Is there a way to selectively disable mitigations on Macs?

lifeisstillgood 5y ago

It seems to me that almost all optimisations (and especially the accumulation of optimisations that we want to get more performance), that all optimisations are going to be vulnerable in some way to timing attacks. After all an optimisation is designed to alter the timing. If all actions must have the same timing, optimisations fail. Do we simply offload any sesnitive processing to specialised chips? The silicon wafer seems to be developing vulnerablities like a network.

lmm 5y ago
We need to stop trying to do transparent caching, and instead give developers control over what happens. Itanium wasn't wrong, it was just ahead of its time.
- pjmlp 5y ago
  I keep wishing that on an alternative reality AMD would have lost access to x86 IP, thus never coming up with x64 as cheap alternative to Itanium.
  - geogra4 5y ago
    I think x64 WAS Itanium. x86-64 is the beast we are dealing with today. In that world maybe everyone goes to PowerPc? The move from 32bit G4 to 64bit G5 cpu wasn't a big deal since the PPC had 64bit variations back in 1997 with the 620 (though apple never used it)
    - pjmlp 5y ago
      Everyone would go where Windows would go, as far as I remember PowerPC Windows NT did not got much love.
      - geogra4 5y ago
        Yeah, that was kind of tongue-in-cheek. Apple knows when to leave a cpu architecture. They've done it 3 times already (M68k->PPC->x86->ARM) Though I think we're getting now to the point that we would have gotten to then. AMD bought x86 another 15 years of life.

jokoon 5y ago

Is that directly related to Spectre/Meltdown? Is that microcode fix somehow better than mitigations in the kernel? I wonder if it will allow AMD to catch up even further (even though AMD CPU were also affected).

BeeOnRope 5y ago
Well Spectre (not Meltdown) is a broad class of bugs, and whether something is Spectre or not often just comes down to whether the author chooses to put their side-channel attack in that bucket. That said, I don't think this is related to any of the named Spectre variants.

Aardwolf 5y ago

So many of the performance-reducing security are related to timing attacks. Would perhaps a solution to this be to have mixed cores: some cores intended for managing passwords and other secure data with all the performance reducing mitigations to avoid timing attacks. Other cores completely unlocked, no mitigations, and intended for non-secure computation (gaming, number crunching, ...). Then let the OS and programmers ensure it's known which computation is marked as secure and which is not, to decide on which cores it can be ran.

bluGill 5y ago
No. I've erased this reply several times as I thought of a mitigation to the problem I was going to state - but in the end nothing mitigates everything. Most of the ways to make this work are hard to get right - it is too easy to forget to mark something as unsafe, or in some other way allow data to the fast cores that the fast cores shouldn't have. Even if you figure out how to do it though, you can still fall to a double failure: your safe code doesn't leak passwords via a timing attack, but via something else (buffer overflow?) it leaks the password to the unsafe side, which in turn leaks it via a timing attack.

z3t4 5y ago

I see many comments about people wanting to turn off the mitigations. Just remember that you are currently running a virtual machine (your browser) that lets anyone (the web sites you visit) to run code on your machine.

sp332 5y ago
CPUs have a bajillion cores these days. Can we keep mitigations enabled for a few of them and run browsers over there, and keep the rest of the system fast?

snovv_crash 5y ago

The only way we can actually stop timing-based side channel attacks is by having deterministic (in time) execution. The only way that can happen is by running at the slowest hypothetical rate for every individual operation. So, no cache, dedicated CPU timeslices, dedicated RAM bandwidth. Luckily, we only need this for untrusted code. What really peaves me is that trusted code is now having to run slower as well.

wffurr 5y ago
With supply chain attacks, all code is untrusted.
- andrewinardeer 5y ago
  Unless you mine your own silicon all hardware is untrusted.
  - FredPret 5y ago
    Only if you write every bit of code and trust every person involved in the entire value chain
    - kirubakaran 5y ago
      But even then, do you trust yourself?
      - FredPret 5y ago
        Right, what if you’ve been Inception-ed by an adversary
      - FranchuFranchu 5y ago
        Maybe the NSA installed a backdoor in your brain.
- ant6n 5y ago

rvba 5y ago

Make processors which are 10% faster than competition by dubious security practices. After some time slow the processors down by 20% because various corner cutting practices are detected. First you kill AMD with "efficiency". Then you "encourage" users to upgrade, since secutity updates make this efficiency disappear. How is this even legal.

rij111 5y ago

WTF. I thought my grandma's Laptop purely catering to her Netflix addiction was just Windows glitching and spent 4 hrs downloading and installing Ubuntu on it.

yabones 5y ago

What's the sustainable solution here? Do we give up and let our performance erode back to where it was a decade ago? Do we just let the vulnerabilities pile up until somebody starts exploiting them? Or do we create an entirely new 'premium' CPU architecture that is designed from the ground up around security, and have an underclass of insecure and dangerous devices?

ajsnigrutin 5y ago

If my washing machine suddenly decided it needed longer time to wash a load of clothes, that would be a change of specifications after the fact, and I'd be able to return it to the store without issues. So... why not with CPUs?

showsover 5y ago
It's not a washing machine, it's a tiny motor inside the washing machine that only works with that model. What CPU are you replacing it with? Most if not all modern CPUs are vulnerable to this so changing it makes little sense. Even if you can change it, you'd need to switch motherboard as well.
- ajsnigrutin 5y ago
  I, as a consumer, don't care... I bring the whole washing machine to the store and get my money back, because they changed the specs after i bought it. Then with that money I can do whatever I want... eg. buy an AMD washing machine... or generally a newer, faster one, becuase some time has gone by. Or go on a vacation. Or drugs and prostitutes.
- makeitdouble 5y ago
  To parent's point, currently the risk is all pushed on the customer. We wouldn't accept that on any generic customer product. We'd recall whole fleet of cars if they had severe flaws that directly affect their performance. There might not be viable alternatives, but there should be at least something from CPU makers to help swallow the pill.
trynumber9 5y ago
You can still operate it with the original specifications. Do not apply the microcode if it's that important to your workload. Just remember to avoid running untrusted code.
- ajsnigrutin 5y ago
  So i have two options: - keep the old "firmware", and risk the machine catching fire - put the new firmware on, and make it wash slower Yeah... I'll choose returning it to the store.

BuckRogers 5y ago

I just built a Rocket Lake desktop, I wonder if the architecture updates to Willow Cove removed the need for this mitigation.

e40 5y ago

My PleX server last week, running on CentOS 7 in a docker container, seemed to have trouble with streams that previously played fine. There was a kernel update for CentOS 7.x recently, too. Now I'm wondering if this is the cause. The container hasn't been rebuilt in many months (like 7) and the only thing that has changed on the machine is CentOS updates.

Avernar 5y ago

As with anything, we have to ask ourselves why are we offloading the responsibility to the OS providers to solve this, when we really have to determine for ourselves if the risk is even a risk at all on our individual systems. Do I care about this hard to exploit vulnerability on a web server that's streaming video content to the public? No. Does it matter on a DB server with important financial data? Yes it does. Applying the patch should be opt-in if you ask me. But of course, most sysadmins are hopeless. So then the OS vendors push it out, it's safer than letting the decision to uninformed people.

Spivak 5y ago
This "but people are stupid and uninformed" mentality has really got to stop. If you find yourself making an argument that hinges on everyone but you or some large population being idiots then you're wrong. Not only because people aren't stupid but doubly because you're specifically talking about a population of highly educated people who start as developers and get interested in infra. Sysadmins/DevOps/SREs aren't hopeless, they just have different incentives and responsibilities. Default secure with the option to let down your guard when the need is there is always always the right choice. You wouldn't have your firewall default allow with a blocklist. You wouldn't grant everyone sudo access and then maintain a list of commands they can't execute. Such a thing is impossible to maintain. For me specifically I manage too many servers to bother with this. It's going to be deployed to everything without exception and if you need more performance we'll rack more hardware. The cost of more CPUs is less than the risk that something will slip through the cracks. I don't care that your pet service doesn't execute any untrusted code, I'm not carving out exceptions when I have 20 teams constantly asking for stuff.
- whatshisface 5y ago
  >I'm not carving out exceptions when I have 20 teams constantly asking for stuff. Sounds like your IT department is severely understaffed and is unable to meet the needs of the developers without reducing service.
  - orhmeh09 5y ago

einpoklum 5y ago

If I run vanilla Debian stable, would I have gotten this kind of an update?

zelon88 5y ago

You know, just 10 short years ago whenever someone had a problem with an AMD chip, the overwhelming response from the tech community was "dude, just get an Intel. They are way better." So pardon me, but from a lifelong AMD enthusiast, you all deserve this... "Hey guys, why are you still running Intel? That shit is like 2 generations behind my AMD in performance and reliability." Damn, that felt good.

CyberDildonics 5y ago
Reliability? It isn't a car, it doesn't wear out. Also why would you be a life long enthusiast of a specific company? Why not buy what works best at any point in time?
- zelon88 5y ago
  Because Wintel has always displayed bad sportsmanship and anti competitive practices. I don't want a winner who wins because they cheat. Also, AMD almost lost everything. At one point they had to sell their own HQ and lease it back to generate cashflow and keep the doors open. If they had closed, Intel research budgets would tank. They wouldn't have nearly as much incentive to innovate. Without Dodge motor company you would still be driving a Ford Model T in black. If AMD died instead of making the original Athlon, you would still be stuck with a Pentium MMX because Intel could have stopped innovating and kept their market share.
- R0b0t1 5y ago
  It does wear out. As a general rule everything with moving parts can wear out, and a CPU is full of moving electrons. https://en.wikipedia.org/wiki/Electromigration https://en.wikipedia.org/wiki/Electromigration It takes on the order of 100 years for well made modern CPUs to fail due to these effects, but poorly made CPUs could fail far earlier. There are likely some nonzero number of failures attributable to electromigration. There are some people who buy overclockable parts and don't overclock them because they are more robust. It's unknown exactly how or why CPUs fail. Taking them apart to check is an extremely expensive endeavor. But sometimes they do.

zelon88 5y ago

How would we know if Intel started disabling features that they explicitly marketed? I believe removing or reducing the functionality of a product that was sold under the pretense of a certain level of performance would warrant class action. That's like Ford selling a truck with 500hp and then later recalling it to detune it to 400hp. The truck I have is no longer the truck I wanted or the truck I paid for. Ford owes me what it said on the label. What if Intel wanted to sandbag existing products to promote new ones?

efreak 5y ago
> What if Intel wanted to sandbag existing products to promote new ones? IANAL, but I'd guess that this is maybe similar to Sony removing OtherOS in a firmware update, and that you could sue Intel for it. Or maybe not, since you can actually disable microcode updates.