If the supermajority of viewers use this sort of security, how are ad-supported websites supposed to stay in business? Credit card transaction fees are too high (starting at 30 cents) to make a separate transaction per page practical. Nor will people who discover an article through an inbound link (search, social media sharing, or a citation in another article) be willing to buy a month's unlimited reading or a 500-pack of page views on a site for $5 just to read one article. Or are web publishers supposed to go out of business, with their staff retraining for a completely unrelated industry, such as butchering as bingoUV on Slashdot cheekily suggested?

The company has "assigned some of our very best minds" to work on addressing the vulnerability that's exploited by those attacks, Krzanich said on a conference call following Intel's quarterly earnings announcement. That will result in "silicon-based" changes to the company's future chips, he said.

What many folks (including me) expect is that "future chips" doesn't mean new steppings ("new revisions") of existing CPUs, but rather a completely new CPU series. In other words: "yes, we acknowledge the problem, it is fixed in our Series 10 CPUs / Core i1337 Series, which will require you to buy a new CPU, a new motherboard, possibly new RAM, and possibly new software or OS license(s)".

What many folks (including me) want are replacement CPUs with the bugs fixed in hardware (newer stepping), which is exactly what was done with the FDIV bug in late 1994 and the F00F bug in late 1997 (the latter of which could be worked around in OSes fairly easily, but Intel would only send you a newer stepping if you actually contacted them/asked for it -- no recall was done).

The severity of this problem strongly warrants either recalls or newer steppings released of existing Intel CPUs, and replacements offered for free. But the flaws affect a large range of CPUs (i.e. models no longer manufactured / EOL'd), so there would need to be a limit. My recommendation would be Ivy Bridge or newer, which is effectively 2012 and later. Older CPUs could use software-based fixes (both OS and/or BIOS/UEFI), which would suck but be better than nothing.

Fixing this problem in software is unacceptable as the performance impact is too severe: Intel's quoted numbers are substantially lower than what has been demonstrated in the real world. Furthermore, Microsoft, Ubuntu Linux, HP, and Dell have already botched patches at least once (HP and Dell botched BIOS/UEFI updates, because understanding and solving this problem in software is stupidly complicated).

Intel needs to bite the bullet and do what's right and most effective.

For what CPUs are affected -- not just Intel -- the Wikipedia article is pretty clear/thorough. You may also want to update your GPU drivers (for example, NVIDIA pushed out GPU driver updates; their GPUs are not susceptible to Meltdown or Spectre, yet they did something anyway -- I still don't understand their statement).

The approach I've advocated is simple: if you have a single-user system which you're extremely careful/safe with (software/application-wise), or you have servers in private/segregated environments (ex. corporate private network servers which only limited/trustworthy people in your IT department have access to), then the best choice right now is to do nothing. If you run a hypervisor/HV, own/rent a VPS server/system (i.e. guest OS), have a server in the cloud (EC2, Google, Azure, etc.), have a multi-user server, or have a system where the software being used on the system cannot be trusted, or you're just simply "extremely concerned", then you should patch and do BIOS/UEFI updates (the latter is for CPU microcode; this can be done at the OS level, but as Ubuntu Linux learned, botching this is worse than doing nothing) and pray nothing starts breaking. Have a rollback plan in place in case something goes awry (use disk imaging software prior to OS updates, back up or download the prevision revision of BIOS/UEFI, etc.).

Technology and computers are crap. Let's go do something more useful and enjoyable, like, say, fishing.

Edit: wanted to add clarification about how Meltdown and Spectre can be used in virtualised environments (i.e. VMs) and their relevant CVEs:

Meltdown (CVE-2017-5754). VMs cannot exploit Meltdown to read memory of the hypervisor or other VMs. However, userspace processes in a VM can exploit Meltdown to read the VM kernel memory. Thus, patching Meltdown involves upgrading packages in your VM (yum update or apt-get update && apt-get dist-upgrade, followed by a reboot), so that the Linux kernel is updated to one that enables page table isolation.

Spectre (CVE-2017-5753 and CVE-2017-5715). Both Spectre variants can theoretically be exploited by VMs to read hypervisor memory. Until security updates are applied, userspace processes in your VM will be able to read VM kernel memory even if software in the VM is patched, because the operating system updates depend on new CPU features that require CPU microcode and qemu/kvm/HV updates to be exposed to the VM.

Last edited by koitsu on Sat Jan 27, 2018 6:15 pm, edited 1 time in total.

I'm sorry, but I don't understand the problem here. The code segfaults. Process dies, problem solved. If shared memory is the side-channel then the OS can just flush the cache or something when a program segfaults. What's the big deal?

The branch predictor is tricked into thinking that "thing that is false but a variable" is true, the read causes one slice of "our array" to be loaded into L1 cache, the branch predictor discovers that it predicted wrongly, but the L1 cache contents have already been filled from the invalid fetch.

What many folks (including me) want are replacement CPUs with the bugs fixed in hardware (newer stepping), which is exactly what was done with the FDIV bug in late 1994 and the F00F bug in late 1997 (the latter of which could be worked around in OSes fairly easily, but Intel would only send you a newer stepping if you actually contacted them/asked for it -- no recall was done).

Both of those cases were much smaller in scope, a lot more practical to recall or replace.

I mean, a recall would be nice but I really don't predict one happening. I'm sure there's already class action lawsuits begun for this, but I still wouldn't expect a recall to be the end result of them.

What I do expect is a decade of leaks and patches and pain while the world slowly upgrades.

I mean, a recall would be nice but I really don't predict one happening. I'm sure there's already class action lawsuits begun for this, but I still wouldn't expect a recall to be the end result of them.

I would be willing to compromise with Intel by saying: fine, don't issue a recall, instead for CPUs actively on the market/non-EOL'd, push to market new steppings that have these problems fixed at the silicon level -- and offer the ability for a customer to exchange/replace an existing CPU with a newer stepping.

A lot of people *won't* return/exchange their CPUs due to the hassle and/or accept software patches (performance hits). I learned that from the F00F bug, where Intel would allow you to exchange your F00F-susceptible CPU stepping but only if you contacted them and requested it (while simultaneously releasing a newer stepping that fixed the bug), they tended to try and "offload" the fix responsibility onto the OSes (proof of that is here), which is what a lot of people did (a lot less hassle than pulling a CPU out + doing an RMA). FDIV actually resulted in Intel issuing a full-on recall -- where (I suspect) most customers didn't bother.

So yeah, I agree Meltdown/Spectre is a very different and much more impactful/serious issue given its scope and impact. Though I would point out it's somewhat subjective. For example, the F00F bug was less of a concern for single-user computers/systems, but was catastrophic for multi-user servers. All it took was a single customer assembling/compiling + running LOCK CMPXCHG8B EAX and they could hard-lock the entire server. For me as a sysadmin working at ISPs providing shell accounts/other user-accessible services with hundreds of accounts per server, F00F was one of those the-shit-just-hit-the-fan nightmares. (We did end up replacing our CPUs with new stepping versions bought fresh, exchanging the old, and then selling the Intel-provided replacements)

The branch predictor is tricked into thinking that "thing that is false but a variable" is true, the read causes one slice of "our array" to be loaded into L1 cache, the branch predictor discovers that it predicted wrongly, but the L1 cache contents have already been filled from the invalid fetch.

By the way, this just got announced, further supporting my recommendation to avoid patching for the time being (unless applicable to your environment), and push hard on getting Intel to do silicon-level fixes with updated CPU steppings. Emphasis my own: https://tech.slashdot.org/story/18/01/2 ... itigations

Quote:

Microsoft has issued on Saturday an emergency out-of-band Windows update that disables patches for the Spectre Variant 2 bug (CVE-2017-5715). The update -- KB4078130 -- targets Windows 7 (SP1), Windows 8.1, all versions of Windows 10, and all supported Windows Server distributions. Microsoft shipped mitigations for the Meltdown and Spectre bugs on January 3. The company said it decided to disable mitigations for the Spectre Variant 2 bug after Intel publicly admitted that the microcode updates it developed for this bug caused "higher than expected reboots and other unpredictable system behavior" that led to "data loss or corruption."

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum