Between Intel's numerous CPU bugs that they refused to refund customers for and ME, it's crystal clear what Intel thinks about their customers.
My next home PC will be Ryzen 2 at some point this year.
I know my box is overkill for my needs now, but upgradeability is a big plus for me; I'm only using 16GB of RAM, but could up that to 128GB, and maybe I might swap out the CPU for a 64-core Zen4+ in 2022. For reference, my last dev box is from 2010[1](!) which I upgraded over time and this strategy has served me well. YMMV.
1. Westmere - 1st Gen 'Intel Core'
This bug and Intel's response is very good timing for AMD though.
Unfortunately the legal process was far too slow and the penalties were a pittance compared to the profits.
It benefits all of us to have a competitive market for x86 CPUs.
ouch, that is definitiv not a good issue... but well my mbp late 2013" gets hot as well.
It's not getting particularly hot in general, entirely depends on the use case. When I max out the cores or run a game? Quite hot. Otherwise: Mostly fine..
It's just unwieldy, big and heavy, hence not really useful on a lap..
Not a home-built thing, but not what you'd call a laptop (portable, battery life) either..
How do you propose this could work?
Are side channel vulnerabilities in CPUs really bugs?
Modern process isolation is not flawless, therefore it is not modern process isolation.
Before one makes such a statement, one has to define "modern process isolation" in a very formal way, so that not anybody (neither Intel nor the customer) can redefine the meaning as they desire. I am not aware that Intel gave such a formal definition that they claim to obey to (but perhaps fail). So any operating system can only rely on very weak guarantees for the processor to provide "isolation" (using quotes since I have not defined the term "isolation" formally). Thus the OS has to implement stronger isolation primitives that it desires by itself (by using the weak primitives that the processor provides).
I would have expected, if I thought to ask, that items were not added to the cache or were removed from the cache if the branch was not retired.
Intel isn't being sneaky, speculative reading was a standard and accepted feature for out of order processors for over 20 years (remember it affects ARM,AMD,Apple,IBM etc as well). Speculative reading privileged memory while unprivileged was a big mistake though.
Shipping or not, it illustrates, that Intel was not unique.
https://www.amd.com/en/corporate/speculative-execution
https://googleprojectzero.blogspot.co.uk/2018/01/reading-pri...
It's also not the scariest variant, it's easily fixed (performance degradation aside), doesn't require a microcode update to be fixed hence is 100% software mitigated, doesn't allow you to cross between guest and host memory address spaces and isn't remotely exploitable.
On the other hand variant 1 and 2 are much scarier because they are the complete opposite of Meltdown.
And Meltdown was the easiest to exploit. Spectre is "bad" because it affects everyone, but it's less exploitable than Intel's Meltdown.
Meltdown is the easiest to exploit and the easiest to fix it’s also the least scary one as far as compromises go.
While it's more easily exploited, it's also patchable with minimal performance impact, unlike Spectre in general.
Let's not throw the baby out with the bathwater here. I don't think the problem is that speculative execution is not as invisible as it was once believed. The problem is more of awareness and documentation. If there was an option to disable speculative execution and awareness of the associated security issues from the beginning, I don't think anyone would have a problem with using it for a performance boost where it was safe to do so. The problem is there was an industry wide assumption that it wasn't a problem that turned out to be wrong.