Facebook Allowing Israeli Security Forces To Shape The News Palestineans See

A Major Security Vulnerability Has Plagued 'Nearly All' Intel CPUs For Years

from the whoops-a-daisy dept

Wed, Jan 3rd 2018 11:58am — Karl Bode

Intel is in for a very challenging few weeks. Reports began to bubble forth this week suggesting that "nearly all" intel chipsets (and some chipsets from other vendors) have been plagued by a security vulnerability over the last decade that could impact millions upon millions of users. While the full details of the vulnerability have been largely been kept under secret embargo by the security community, the scale of the flaw appears to be monumental. From what's currently known, the vulnerability currently allows programs to gain access to the layout or contents of what previously was believed to be protected kernel memory.

You know, the area where everything from passwords, login keys, and files cached from disk are presumably stored away from prying eyes. The problem appears to be unprecedented, and the entire security community is rushing to quickly push out updates for the problem:

"There is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.

So for one, this appears to have been in the wild for years, raising questions as to whether this has already been exploited by the intelligence community and others. And while the nature of the vulnerability isn't being fully disclosed, AMD hinted at the structure of a problem in an e-mail over the holiday to the Linux kernel mailing list stating that AMD products aren't affected:

"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

At least one computer science PHD candidate at Vrije Universiteit Amsterdam claims to have already developed a proof of concept capable of exploiting the flaw to read kernel memory from user mode:

Bingo! #kpti #intelbug pic.twitter.com/Dml9g8oywk

— brainsmoke (@brainsmoke) January 3, 2018

And while the vulnerability can be patched on the OS level (patches for the Linux kernel are already available even though the notes try to tap dance around the true nature of the issue), early reports indicate these updates could come with a much as a 30% performance penalty, something that will make gamers and other enthusiasts likely weep:

"Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary."

In other words, Intel's not only about to take a severe beating for a massive security vulnerability, but the performance of much of its product lineup is about to be dramatically impacted by the fix, which could flood the market with people looking for new, unimpacted CPUs. That's likely great news for AMD sales, but notably less so for Intel PR reps coming off of their holiday break, who'll be tasked with softening the perceived impact of the flaw ahead of more details in a week or two.

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: chipsets, intel, security
Companies: intel

63 Comments

If you liked this post, you may also be interested in...

Reader Comments

Subscribe: RSS

View by: Time | Thread

Ninja (profile), 3 Jan 2018 @ 12:00pm

I've been reading about the issue and maybe games won't be as impacted as some other workloads because they don't rely heavily on syscalls. Ars has a good article about the probable culprit.

As CPUs get more and more complex we are introducing more attack surface like that case where Intel stuff was running an entire OS with full access to the system core functions. I expected unintended consequences like this to be a lot more common in the future. I'd love to say criminals around the world are thrilled but I don't think they are as thrilled as our authoritarian govts...
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:01pm

From the same people who brought you the Minix backdoor
Obviously, Intel was too busy installing hardware back doors to bother with protecting the poor users.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:02pm

The security community has know about this since may
Bits of the minix issue have been known since May but it was mostly limited to data center users.
[ link to this | view in thread ]
Uriel-238 (profile), 3 Jan 2018 @ 12:27pm

And I got AMD because they were cheaper for the speed.
Today I'm glad I was a cheapskate.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:29pm

MacOS
There are indications that Apple started patching this issue in High Sierra 10.13.2.
[ link to this | view in thread ]
Chuck, 3 Jan 2018 @ 12:30pm

Yet another reason...
I've noted for years that AMD offers motherboards with a full-speed FSB (that's a front-side bus, not the ruski's) while Intel continues to refuse to, and to refuse to allow their third-party board makers to either. This is a nasty trick they've been using since the late 90's.

In short, they make a new CPU that actually is marginally faster than the last one AMD released. Then, they do a limited run of boards with full-speed FSBs and put them in the review units they send to various hardware reviewers. Then the rest of us, even the people who pay upwards of $600 for a motherboard, are stuck with lower-speed FSBs.

The end result is that, even though Intel's CPUs are almost always the best, their actual systems are not overall faster than AMD's. They appear to be in most testing, but in practice they aren't.

Then when enthusiasts who actually care about that last 5% of performance actually benchmark their systems, they're slower than they expected. So the cycle begins anew. The whole thing is a marketing gimmick that isn't even actually illegal because the speed of the FSBs is disclosed to the reviewers. It isn't pointed out that ONLY reviewers will EVER see this FSB speed, but then the law doesn't require that.

Just yet another reason I prefer AMD systems. Their CPUs may be SLIGHTLY slower, but overall their systems are faster, because they're more interested in selling you a decent computer than in shoveling you into the most vicious upgrade cycle they can think of.
[ link to this | view in thread ]
An Onymous Coward (profile), 3 Jan 2018 @ 12:41pm

Re: Yet another reason...
> In short, they make a new CPU that actually is marginally faster than the last one AMD released. Then, they do a limited run of boards with full-speed FSBs and put them in the review units they send to various hardware reviewers. Then the rest of us, even the people who pay upwards of $600 for a motherboard, are stuck with lower-speed FSBs.

If there weren't end-user-driven stats sites out there to get the real performance data (ignore all those reviews sites) this might be a real concern. However, Intel is still the better buy, as long as you go with coffee lake. For now.

Sooner or later I expect AMD will take the lead again but it has been a really long time since the last inversion.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:45pm

Re: Yet another reason...
Intel also disable ECC memory on most non-Xeon CPUs. (Some non-Xeons are rumoured to support it, but it's hard to find official details.) ECC may help prevent certain memory-corruption attacks like Rowhammer, which may or may not be related to this flaw.

AMD's Ryzen processors all have ECC capability—though, sadly, details on mainboard/firmware support are hard to find.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:48pm

Re: Yet another reason...
"Intel's CPUs are almost always the best,"

Based upon what criteria?
Best at what?
Seems to be a rather broad statement.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:49pm

LWN link
One of the linked articles links to a paywalled lwn.net article. Here's a non-paywalled link.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:51pm

definition please.
What exactly does an embargo on the security flaw mean? That they won't share with anyone besides the effected party?
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:55pm

Re: definition please.
I know the definition of embargo itself but how is it applied in this context? Also who orders the embargo when potentially multiple countries are involved?
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:56pm

Re: Re: Yet another reason...
They have the best fabrication technology, i.e., they're able to make chips smaller than any other commercial-scale fab. This helps with speed and power usage, generally.

Until AMD released Ryzen, Intel got higher scores on most CPU performance benchmarks (but cost more, so "better" is subjective). It's been like that through most of their history, except in the Pentium 4 days when AMD got higher scores. And now with Ryzen, which is competitive too.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 12:59pm

dont worry about the slow down after any update patch has been applied, Intel will soon sell you a nice, new, faster chip at 3x the cost of the 'faulty' one!
[ link to this | view in thread ]
Thad, 3 Jan 2018 @ 1:00pm

Re: And I got AMD because they were cheaper for the speed.
It's not clear yet whether AMD processors have the same flaw. It may even exist on ARM chips.

As Ninja noted, Ars has a good rundown of what we know so far.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 1:02pm

Re: Re: definition please.
"Embargo" means the people involved have agreed not to release details right now... presumably until a certain date, or until a patch is available. Obviously, the people writing these patches must have more information than the rest of us.

This would have been negotiated between the researchers and the affected companies/groups. In general nothing stops researches from publishing immediately. It seems they, Intel, AMD, Microsoft, and some Linux developers have the details, at least, and have agreed not to share them.

("Embargo" in this context is similar to the journalistic concept of an "embargoed" story.)
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 1:10pm

Re:
I run something which uses sockets out of a VeraCrypt file on my end.

So I either have to patch which makes this situation completely unworkable because of the sheer amount of I/O system calls...

...or remain vulnerable.

So fair, vulnerability is winning.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 1:11pm

Re:
Also, don't forget about Denuvo.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 1:12pm

Re:
Sounds like Apple's business strategy.
[ link to this | view in thread ]
An Onymous Coward (profile), 3 Jan 2018 @ 1:16pm

Re:
Anything still under warranty should be repaired or replaced. But outside the warranty is no different than anything else you might buy.

If the engine in your 2012 Mazda dies you might be upset at Mazda for poor quality or upset at the universe for your bad luck but you have no recourse. Your options now are to buy another Mazda or some other brand. Or, I suppose, stop driving. This is no different.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 1:40pm

Gosh, I wonder if Intel's CEO flushed a whole bunch of stock options recently...
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 2:08pm

And again. Backdoors make it into the wild every time. Everybody wave their hands in the air in pretend panic as the backdoor is closed, and a new backdoor is tunneled in to replace it.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 2:26pm

Re:
Uh, this wasn't a backdoor. It's just an undiscovered (until now) bug.

It isn't even a write attack, it's read only. Meaning someone exploiting this could only get information from the PC, not make it do anything. Though one could make the argument that what is revealed in this exploit could be used to chain an additional attack that would lead to privilege escalation and an eventual write attack but this by itself, doesn't do that.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 2:55pm

Re: And I got AMD because they were cheaper for the speed.
Is this the "Intel Management Engine" issue? Where it was designed for someone on the outside to access the whole system remotely for (apparently) tech support purposes?

I've heard that AMD CPUs also have a similar function, so don't think that switching to them will save you. Even if their implementation claims to be completely different, it just means that it hasn't been broken to our knowledge, yet.
[ link to this | view in thread ]
Nice Thomas, 3 Jan 2018 @ 3:08pm

Remember that time,
when Intel DIDN'T have a maths co-processor problem on their 585.999938 CPU?
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:09pm

Re: Re:

Uh, this wasn't a backdoor. It's just an undiscovered (until now) bug.

What were you expecting, MSR_NSAKEY? If one wanted to design a backdoor, this would be pretty much perfect. (Or if an agency wanted to defend their country, it's exactly what they should be looking for: areas where a designer might fuck up. CPU design—including caching, speculative execution, and protection, and the interactions between them—is hard.)

It isn't even a write attack, it's read only. Meaning someone exploiting this could only get information from the PC, not make it do anything.

You may not have thought this through. If one can get information like passwords or encryption keys, one can use them to "do things" that shouldn't be allowed. This is why Heartbleed was considered so critical.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:13pm

Re: Re:
Let's see now. At the very least, being able to just detect where some critical kernel pages are located neutralizes Kernel Address Space Layout Randomization, aka last ditch effort to keep buffer overflow attacks from working. Then, you have the row hammer exploit to elevate permissions. And guess what? In order for row hammer to work, you need to know where the addresses of critical kernel structures are. And the above 2 attacks don't even require you to actually know what is in those locations, merely need to know that it's in that location. And if the exploit actually allows you the ability to read kernel memory? At that point, you might as well give your computer to your enemy.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:13pm

Re: Re: And I got AMD because they were cheaper for the speed.

It's not clear yet whether AMD processors have the same flaw.

That's true until we know the details, but they denied this class of bugs with some specificity. Compare that with Intel's non-statement.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:17pm

Re: Re: And I got AMD because they were cheaper for the speed.

Is this the "Intel Management Engine" issue?

The information we've seen suggests it isn't, and that it may be an infoleak related to speculative execution. See AMD's statement, and note that some sources are saying CPUs since the Pentium Pro are affected (they seriously predate the IME).
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:42pm

Re: Re: Re: And I got AMD because they were cheaper for the speed.
Hahahaha - remember the Pentium FDIV bug?
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:45pm

Re: Re:
But one would have discovered rather soon that their Mazda could not reach highway speeds and take it back to the dealer immediately.

Oh yeah - car analogies are bad, all of them - this is no different.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 3:47pm

Re: Re: Re:
"if an agency wanted to defend their country"

They would look for these things in order to eradicate, not use.
[ link to this | view in thread ]
JoeCool (profile), 3 Jan 2018 @ 3:55pm

Re:
Um, actually, he DID.

https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 4:07pm

Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
Yeah but not in detail. Are you hinting that Intel had some bogus denial? Or that they'll need to replace CPUs now, as they did then?
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 4:37pm

Re: Re: Re: And I got AMD because they were cheaper for the speed.

it may be an infoleak related to speculative execution

...and to speculate wildly myself, the CPU must be somehow speculating on secret data. Maybe the result then feeds into the cache or the branch predictor in some user-observable way. Here's a similar thing from last year, involving TSX.

I might start by writing some code that jumps to a kernel address. Run it and handle the fault, or just make the CPU predict the jump will be taken. Then probe the cache or predictor state to get some data. Maybe using the address of a register-dependent jump instruction will make the CPU prefetch based on the (userspace-controlled) register value.
[ link to this | view in thread ]
Lawrence D’Oliveiro, 3 Jan 2018 @ 4:40pm

Update
Seems there are two different flaws, one of which affects a range of non-Intel CPUs.

(h/t Michael Cree)
[ link to this | view in thread ]
David Hess, 3 Jan 2018 @ 4:53pm

Re: Re:
This exploit allows reading of protected memory and could for instance be combined with a rowhammer attack to effect privilege escalation.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 5:15pm

Re: Re: Re: Re:
Yes, of course! They have the expertise to find this, and they'd screw themselves by hoarding it; other agencies are depending on CPUs to be secure. Though really, CPU manufacturers should be releasing enough information so we don't have to rely on powerful agencies.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 5:16pm

No wonder the tekkies are all leaving NSA...
Most of their favorite exploits have been found, so it's no longer any fun...
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 5:20pm

Re: Re: Re: definition please.

This would have been negotiated between the researchers and the affected companies/groups.

Intel's bug bounty program offers $30000 for a critical hardware bug, but participants "Must follow coordinated disclosure" to get paid.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 5:59pm

If it's patched in the Linux kernel, then the bug is basically in the open already. People will reverse engineer the fix to find out what the cause is. They've done the same for security updates from vendors for years. So why still embargo it? Reveal the details of what's affected and the patches available, even if you don't release POC code. Hackers are going to work out an exploit anyway.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 6:05pm

Re: Re: And I got AMD because they were cheaper for the speed.
A newer article from Ars that has technical details:
https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfi xable-security-flaws/

Doesn't really list what's affected though... seems like the answer to that is 'everything' - Intel, AMD and ARM.

Ars reports the patches for some usage scenarios may result in a 40-60% slowdown. That's an incredibly high penalty. But I suppose the vendors will refine patches later and push down the penalty to a lower figure.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 6:26pm

Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
Yeah, they said the average user would not even notice the diff ... heh, it's not the point here.
[ link to this | view in thread ]
David (profile), 3 Jan 2018 @ 6:43pm

Normal laptop and desktop users will notice little delta
This is an optimization (cough,cough) that allowed a system to run faster. The fix is relatively simple; Separate kernel address from user address. That comes at a cost, but many user space applications will notice little to nothing at all.

I shared the description with another software retiree and he laughed. Yes, this is something that any security person would jump on. Of course, software issues much less opinions of software or security people are commonly ignored.

Because chip designers are godlike. Just ask them.
[ link to this | view in thread ]
Pixelation, 3 Jan 2018 @ 9:48pm

Re: Re: Re: And I got AMD because they were cheaper for the speed.
"That's true until we know the details, but they denied this class of bugs with some specificity. Compare that with Intel's non-statement."

Exactly, because Nothing Said is Alarming...
[ link to this | view in thread ]
orbitalinsertion (profile), 3 Jan 2018 @ 9:56pm

Re: Re:
Or your 2018 Mazda. Totes no difference.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 9:57pm

Re: Re: Re:
Read my post a little more thoroughly please.

I acknowledged that this could be used in combo with another attack to actually take control of or modify the computer in some way, but BY ITSELF can't do any of that.

My point was more to address the OP's seeming assumption that this was a deliberate backdooring of hardware and that even if it is fixed, they will deliberately insert a new one. This is not that, it's a flaw, plain and simple.
[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 10:00pm

Re: Re: Re:
Yeah, I acknowledged it could be used IN COMBINATION with another attack to actually create a backdoor into the system, but BY ITSELF this is not that.

Though one could make the argument that what is revealed in this exploit could be used to chain an additional attack that would lead to privilege escalation and an eventual write attack but this by itself, doesn't do that.

[ link to this | view in thread ]
Anonymous Coward, 3 Jan 2018 @ 10:02pm

Re: Re: Re:
Yep, it could be used in combination with another attack to get privilege escalation but as I stated in my original comment, by itself this only gives you info, not any kind of meaningful control or access.
[ link to this | view in thread ]
Anonymous Coward, 4 Jan 2018 @ 4:29am

Re: Re: Re: Re:

I acknowledged that this could be used in combo with another attack to actually take control of or modify the computer in some way, but BY ITSELF can't do any of that.

Once you dump the password or key from memory, using it isn't much of an "attack". If attackers can't run code on the system, dumping kernel/hypervisor memory does require some preceding attack; but lots of systems do let people run code, and this is a serious vulnerability. Chaining isn't generally that hard anyway, and this can break a lot of attack mitigations.

To say this is only an information leak is true but makes it sound much less serious than it is.

My point was more to address the OP's seeming assumption that this was a deliberate backdooring of hardware and that even if it is fixed, they will deliberately insert a new one. This is not that, it's a flaw, plain and simple.

Unless you were on the Intel engineering team that screwed up, you can't know that for sure. I suspect you're right, but (in hindsight) this would be an ideal backdoor because it can be written off as a complexity-induced bug. It sat around for decades before being noticed. And Intel's next CPU will be even more complex, meaning the next bug/backdoor can hide the same way.

Any "sufficiently advanced bug", like this or the SetAbortProc WMF bug, is indistinguishable from a backdoor.
[ link to this | view in thread ]
Anonymous Coward, 4 Jan 2018 @ 4:30am

Re: Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
Well, that seems untrue, plus the papers say (at least some of) the attacks were tested and work on AMD CPUs. Good call with the FDIV comparison.
[ link to this | view in thread ]
Anonymous Coward, 4 Jan 2018 @ 6:08am

Re: Re: And I got AMD because they were cheaper for the speed.
AMD is not vulnerable to Meltdown. Only Intel and some select ARM chips are.
[ link to this | view in thread ]
Anonymous Coward, 4 Jan 2018 @ 6:31am

Re: Re: Re: And I got AMD because they were cheaper for the speed.
Shite. Good to know, all the same.
[ link to this | view in thread ]
carlb, 4 Jan 2018 @ 6:42am

car analogies?
Actually, there is one very obvious motorcar analogy.

Buy a VW Diesel on the presumption that it is efficient, powerful and clean... then get told later to "choose any two" after the vehicle fails a third-party emission road test and the proposed fixes cost efficiency, power or both.

The product is still running; that doesn't mean something doesn't stink here.
[ link to this | view in thread ]
Richard (profile), 4 Jan 2018 @ 8:37am

Re: Re: Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
The papers say that "proof of concept" attacks have been constructed - which is some way short of actual practical attacks.

I also remember the 8087 evaluation stack cock-up - which persisted for many years. In fact it is still technically present in the instruction set to this day.
[ link to this | view in thread ]
Richard (profile), 4 Jan 2018 @ 8:43am

Re: Re: Re: Yet another reason...
They have the best fabrication technology,

But they are crap at designing processors and have a long litany of historical design cock-ups to show for it.

In an ideal world AMD or ARM would design the chips nad Intel would make them
[ link to this | view in thread ]
Anonymous Coward, 4 Jan 2018 @ 8:48am

Re: Re: And I got AMD because they were cheaper for the speed.
>Is this the "Intel Management Engine" issue? Where it was designed for someone on the outside to access the whole system remotely for (apparently) tech support purposes?

No. Also, the word you're looking for is "ostensibly" rather than "apparently."
[ link to this | view in thread ]
Richard (profile), 4 Jan 2018 @ 8:49am

Re: Re: Re:
. If one can get information like passwords or encryption keys, one can use them to "do things" that shouldn't be allowed.

It doesn't seem that that kind of information would be accessible to these exploits without some other route in. It is only possible to determine the layout of the data in the kernel memory - not its contents.
[ link to this | view in thread ]
Richard (profile), 4 Jan 2018 @ 8:53am

Re: Re: Re:
This exploit allows reading of protected memory

No it doesn't - it allows the determination of which parts of protected memory are in use.
[ link to this | view in thread ]
9mm, 4 Jan 2018 @ 12:22pm

And the white papers are out
full details on the vulnerability are now out.

https://meltdownattack.com
[ link to this | view in thread ]
Seegras (profile), 5 Jan 2018 @ 7:05am

Meltdown mitigated in Linux Kernel 4.14.11
Which just has been released. Some distros did patch older kernels themselves.
Actually, 4.14.12 is out as well, https://www.kernel.org/
[ link to this | view in thread ]
Mikael, 5 Jan 2018 @ 4:06pm

Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
There is a paper on the method. Modern CPU's can execute multiple instructions simultaneously. Speculative execution attempts to predict the future state of the CPU by assuming instructions will complete successfully. Because of this parallel nature, when a program attempts to read a value in kernel memory this triggers a whole cascade of events; Because loading data into cache is slow, this request is done first, Then a later check in the pipeline determines whether the memory read was an illegal address and rolls back the state of the CPU, but not the cache. Then the program can issue a flush-and-reload instruction to determine the state of the cache, and get the data that way. The data can be anything from passwords to usernames and account numbers.
[ link to this | view in thread ]
swaroop, 29 Jan 2018 @ 6:38am

i5-7200U CPU @ 2.50GHz - Do i have to worry ..?
My laptop has the following processor

“model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz”

do i have to worry about the above mentioned vulnerability issue ..?
[ link to this | view in thread ]