Stopped out with 9% gain, no complaints. But it’s creeping up again after hours.
Honestly, it looks like Intel’s stock may have already bottomed out at this morning’s open. It bounced up about 3% starting at 10:30. There might be some good upside, but I still think it’s too risky in the short term.
Yeah, this has made my life much more difficult. Someone really fucked up.
What should I, as an average user be doing? I have an older MacBook pro (circa 2011) and an iPhone 6.
Keep the OS patched (assuming Apple is patching ones that old). Otherwise, there’s nothing the consumer can do.
And realistically, there isn’t much risk with your own devices. This risk to you is cloud platforms that have your data. There’s nothing you can do there except hope the service providers take appropriate action for Meltdown, and hope the hackers don’t figure out good ways to exploit Spectre.
That was my feeling on this too, but I was a little hesitant to come out and say it.
For users of standalone devices, the exploit is still a risk, but I think you’d have to have some malicious code running locally to actually be bitten by it - so as long as you stay patched, keep your AV up to date, practise safe Internet habits etc, the risks are about the same size as they are for any other kind of malware.
I’m worried a bit about cloud-based password keepers - but even then, I don’t think the content is being decrypted until it’s at my end, right?
Sorry, keep worrying!
http://www.zdnet.com/article/onelogin-hit-by-data-breached-exposing-sensitive-customer-data/
Mostly the same advice for any user: keep your software updated, don’t download software from untrusted sources.
Installing NoScript and adblockers on your browser is a good idea, too. The biggest source of untrusted code we run on our computers is javascript from random websites (and the ads that they serve). NoScript and adblock make it a little more work to browse the web (you’ll probably have to disable them for a few trusted sites to make them work properly), but they will make you safer, not just from this threat but from many others.
Out of curiousity, can anyone explain the low level details of how something like this works? I’m an EE with some experience in chip design but that was decades ago when things were much simpler. It would seem like all the calculations done for the not-taken branch would be trashed once the branch wasn’t taken and wouldn’t show up in any user level accessible registers. Is the off-limits memory somehow getting loaded into a cache line that the CPU could then peek into? I would think accessing the low level cache registers would require kernel level access but, then again, I haven’t been messing with these things for a long, long time.
I vote we all go back to the 6502. It’s the only way to be sure.
Meltdown is surprisingly subtle and non-intuitive. It uses several innocuous features of modern CPU designs to allow data to be “leaked” from an otherwise secure system. The Wikipedia article has a pretty thorough step-by-step explanationof how it works>.
Basically, the contents of normally inaccessible memory is deduced, using cache hit-or-miss timing differences to indicate the content of the memory.
I found this to be a pretty straightforward explanation for the technically minded. It’s basically a pretty clever exploitation of speculative processing in combination with cache timing.
Not an EE, but my less-than-completely-technical nickel summary:
It took me a while to wrap my head around it myself, but I hope that’s a suitably sort-of-technical description that’s reasonably accurate.
Assuming that I understand this correctly:
You’ve got the start of it. The branch is indeed being loaded into cache before it is discarded, with some fairly simple instructions that would use the results. The design flaw is that this cache is not cleared (for performance reasons).
As for how it peeks in, it doesn’t do so normally. It uses a timing based attack. It’s based on two things: the fact that data is a lot faster if you get it from cache instead of memory, and that instructions exist that use one memory address to go to another memory address. So if a memory check is fast enough, and you know the value of the possible target memory addresses, you can determine the contents of the cache.
lda 0001
adc 0001
sta
It’s a bit more complicated than that, as it’s impossible for a process to have access to some location in a cache line but not other parts. The way that the Spectre attack works is that they find some code in the victim process that they can get the processor to speculatively execute that will load data from cache line A if a certain bit of private memory is set and load data from cache line B is that bit is clear. If cache lines A and B are accessible by the attacking process, then it can time how long it takes to read from one of those cache lines to check whether it was loaded into cache, and therefore determine whether the bit was 0 or 1.
Repeat this process for as many bits as you need to access to read a password or whatever secret you’re looking for.
Currently the attack is pretty crude and is a lot scarier in theory than in practice. It requires a very specific set of code sequences in the victim process to exploit. As I understand it, it’s only been exploited so far via an interface in the Linux kernel that basically allows you to inject sandboxed code into the kernel and run it. Spectre allows the sandboxing to be defeated and arbitrary memory to be read. That’s bad, but it only affects a very specific Linux kernel configuration at the moment. It isn’t yet a general attack that works against anything.
However the next obvious target, and a far scarier one, is the Javascript engines in modern browsers. The paper has a proof-of-concept attack but it’s not clear to me that they’ve been able to demonstrate that they can steal important information like your banking password yet.
Thanks everyone. I get it now and to be honest, I can certainly see how Intel would miss something like this. I imagine this is going to really hurt Purley sales but help the next generation as everyone will need to upgrade their cpus.
I’m asking here, because this directly relates to the Intel chip security vulnerability.
My current work laptop is 4 years old, and it is time for a new one. The primary reason to replace it is because it is limited to 12GBs of RAM, and because I frequently run VMs. My plan was to wait until after CES, and then pick something to buy. I’ve been leaning towards the Dell XPS 15.
When I get something, I will be keeping it for 3-4 years, which locks me into a chip with the vulnerabilities, and the performance reducing workarounds.
My choices seem to be:
[ul]
[li]Buy whatever I want and don’t worry about the problems. Whatever I get will probably have 32GBs of RAM and a PCIe SSD, so I’ll see a usability improvement in that I can run multiple VMs simultaneously.[/li][li]Put things off a year. My current laptops is mostly fine, but I can only use one VM at a time due to memory constraints.[/li][li]Only consider the one or two laptops based on the AMD Ryzen mobile chip, and hope it doesn’t turn out to be vulnerable to meltdown after all.[/li][/ul]
Anyway, I’m interested in thoughts other people have.
As has been mentioned the vulnerability is of more concern for processors on the cloud, assuming you are careful to only run trusted code. Ditto for the performance hit. Spectre might not be fixed in a year. Given product life cycles, I’d also say a year might be cutting in close to get the new chips out. If I were Intel I’d fix the chops used for servers before I fixed the ones used for mobile devices.
So, especially if your current machine is bothersome, I’d tend to buy now - but you might wait to see if Intel gives out discounts to try to keep sales up.
How much of the cost of a PC is the CPU?
Worst case scenario is that meltdown is exploitable with javascript, in which case any computer that is used for browsing needs to be hardened. It looks like browsers will probably be updated to protect against this, but the effectiveness of any of these hardening techniques are only theoretical until real non-example exploits start showing up in the wild.
I’ve updated my current Linux systems with the KPTI kernels, and I’m not noticing any particular performance problems. I don’t feel like doing a bunch of benchmarks to test the difference between regular and nopti, because it doesn’t matter, it is what it is, and I don’t have a choice.
Spectre – the worst and most difficult to mitigate of the two problems – is not unique to Intel. It apparently exists for any CPU from any vendor which does speculative execution and branch prediction. That includes AMD Ryzen, ARM, IBM Power8, Power9, the System Z CPUs used in IBM mainframes, and possibly Oracle (formerly Sun) SPARC CPUs. It might include older CPUs such as the DEC Alpha 21264 and even the Motorola 68060, since I think they both use branch predictors and speculative execution.
Upgrading to a newer Intel or other brand CPU likely won’t fix this, although specific hardware mitigations might lessen the impact or narrow the exposure. Research is ongoing but it’s possible a complete fix without software “crutches” might require a total, fundamental redesign of all modern CPUs.
Ironically it appears the unsuccessful Intel Itanium CPU might be immune to Spectre.
Long term, the main issue to be resolved is whether adding another layer of architectural patches on top of current CPUs will provide sufficient immunity to Spectre, or if all CPUs must be fundamentally redesigned and all software rewritten.
Depends on the CPU and the configuration of the PC, of course. This will give you an idea of possibilities.