Quick Facts about Meltdown and Spectre

Zarathustra[H] said:
Well, what is the attack vector? You need to have admin access to a machine in order to exploit it right? So, the machine is already compromised at that point.

The difficulty seems to me is VM's in which third parties maybe have been intentionally been granted administrative access to the CPU cores, and can then use them to trick them to dump the contents of their memory.

Or maybe I've misunderstood how it works?
Click to expand...

There's been a few posts that show that Javascript can be used to implement the attack. This has nothing to do with OS defined Users and Admins, other than most OS prevent non-Admins from running processes that can access kernel memory. The vulnerability is that non privileged programs that non-Admins would be allowed to run and ordinarily aren't able to access any memory other than their own are capable of breaking out of their hardware enforced boundaries.
 
so tell me

how do i get infected?

if it's through the web, maybe browser developers will change the browser code to block the exploit?
 
The saga continues to unfold:

Subject Re: Bricked x86 CPU with software?
From Hector Martin 'marcan' <>
Date Fri, 5 Jan 2018 10:29:25 +0900

On 2018-01-05 10:21, Tim Mouraveiko wrote:
>> On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote:
>> Actually... I don't think your code works. That's why I'm curious. But
>> if it works, its rather a big news... and I'm sure Intel and cloud
>> providers are going to be interested.
>>
>
> I first discovered this issue over a year ago, quite by accident. I changed the code I was
> working on so as not to kill the CPU (as that is not what I was trying to). We made Intel aware
> of it. They didn´t care much, one of their personnel suggesting that they already knew about it
> (whether this is true or not I couldn´t say). It popped up again later, so I had to fix the code
> again. It could be a buggy implementation of a certain x86 functionality, but I left it at that
> because I had better things to do with my time.
>
> Now this news came up about meltdown and spectre and I was curious if anyone else had
> experienced a dead CPU by software, too. Meltdown and spectre are undeniably a problem,
> but the magnitude and practicality of it is questionable.
>
> I suspect that what I discovered is either a kill switch, an unintentional flaw that was
> implemented at the time the original feature was built into x86 functionality and kept
> propagating through successive generations of processors, or could well be that I have a
> very destructive and targeted solar flare that is after my CPUs. So, I figured I would put the
> question out there, to see if anyone else had a similar experience. Putting the solar flare idea
> aside, I can´t conclusively say whether it is a flaw or a feature. Both options are supported at
> this time by my observations of the CPU behavior.
>

If you made Intel aware of the issue a year ago, and they weren't
interested, then the responsible thing to do is disclose the problem
publicly. This is a security issue (if trusted code can brick a CPU,
it's an issue for bare metal hosting providers; if untrusted code can
brick a CPU, it's a *huge* issue for every cloud provider and many, many
others who run code in various sandboxes). If the vendor is not
receptive to coordinated disclosure, the only option is public
disclosure to at least make people aware of the problem and allow for
mitigations to be developed, if possible.

Personally, I would be very interested in seeing such code. We've seen
several ways to brick nonvolatile firmware (writable BIOSes, bad CMOS
data, etc.), but bricking a CPU is a first. The only way that can happen
is either blowing a kill fuse, or causing actual hardware damage, since
CPUs have no nonvolatile memory other than fuses. Either way this would
be a very interesting result.

Source: Re: Bricked x86 CPU with software?
 
I am thankful that people smarter than me are worried about it, and have proposed fixes for it, so that I don't really have to worry about it.
 
Patches coming, they hope, and don't know when. Interesting that they do not mention any of the issues by name.

Customer Identification: KB Networks
Event Type: Announcement Event
Subject: Event 53338231 - Service Disruption -- Bare Metal Maintenance Required
=================================================================
/ Event Description /
IBM Cloud Systems Engineers have been notified of a security vulnerability affecting Bare Metal devices. Due to the nature of this vulnerability and the components which are affected, a Firmware Update and Operating System Update will be required. Please watch for these updates as they become available in your control portal. We will push these notifications as soon as we receive updates from the relevant vendors.
If assistance is required, please contact IBM Cloud support. Additional information on Bare Metal servers can be found at: https://console.bluemix.net/docs/bare-metal/about.html#about-bare-metal-servers
IBM Cloud
 
Sounds lilke it's nothing to worry about considering the average user or even enthusiests.
 
octane said:
Sounds lilke it's nothing to worry about considering the average user or even enthusiests.
Click to expand...
It's one of the most serious and widely spread security issues without a clear fix in sight. For the average user it's at least as serious as any other security threat out there.
 
Meeho said:
It's one of the most serious and widely spread security issues without a clear fix in sight. For the average user it's at least as serious as any other security threat out there.
Click to expand...

Sorry, I shold have been clearer. I was speaking from a patched/performance point of view.

[EDIT] - Rong wording.
 
Performance wise, true, most shouldn't see a big impact.
 
erek said:
"On Skylake and later, Redpoline doesn't work, and you need to use IBRS (and for that, microcode update). A perf hit for SKL/KBL/CFL"
Click to expand...

Interesting. So are you saying that there should be les of an impact with older processors?
 
  • Like
Reactions: erek
like this
Curious to see when vmware will have a patch out. A lot of companies have turned to VM's for a lot of their server infrastructure. This will potentially impact users going to thin client horizon setups for their users.

-Installed win10 patch at home, seems fine so far but looking at the info for the past few days lead me to think that performance wise, home use/games would be minimally impacted.
 
Last edited:
Waiting to hear how this is going to affect us here at the DC, we maintain 1000s of servers here :|
 
CES2018 is almost here and some giants have released a few new laptops/PCs. I was thinking of getting a new Thinkpad, and now this news. What a way to start 2018.
 
MMitch said:
Everytime a patch broke my windows it was because I was using an out-of-date 3rd party SW that uses USB devices (Logitech KB/M).
Need to resort to safe mode to fix those... (W10 safe mode is strange to access at best)

Seems like Windows Update should flag potentially problematic 3rd party applications before doing an update...
Click to expand...

W10 safemode is so prohibitively gated that they have no intention of you ever cleaning out your machine manually. I just drop rovo on devices i'm servicing and have at it. The permissions people enable some of these programs to have boggles my mind.
 
"Sensitive data being protected is a priority."
I think that sums it up. Thanks for your summary, Joe.
 
So I bought 8700k to replace 2500k and after 30% performance hit I will get another 2500k in my hands. Nice :)
 
J3RK said:
:D

I could pretty happily go back to 68000 and 6510 based machines for a while, while they work this all out. Then come back to modern architecture when it's all resolved.

Well, I don't think I'll be able to move the whole datacenter at work over to those, but I can operate at home like that for maybe 6 month (until I get bored of it...) :D
Click to expand...
for some reason i feel inclined to concur
 
I refuse to use any of my computers until this is fixed. I'll expect a notification, and patch, to be delivered in my mail.

I'm out.

;)
 
I'm wondering since this is a hardware level issue, wouldn't it be more effective for the affected chips for vendor to simply issue a firmware flash?

I mean, great MS is giving a patch, but even though they're the majority stakeholder in this they're far from the only ones using Intel.

BTW, thanks guys for posting this, it's a pretty big mess trying to read up on this and as usual the general media(TV/newspapers) are useless.
 
lostin3d said:
I'm wondering since this is a hardware level issue, wouldn't it be more effective for the affected chips for vendor to simply issue a firmware flash?
Click to expand...

Intel is working on a microcode update. CPUs don't have any sort of writable memory to store a "firmware" in, so it's stored the motherboard BIOS which then programs the CPU with the microcode at each boot.

So the issue is that a BIOS update with the new microcode could take a while to resolve (if ever for motherboards more than a couple years old).
 
Parja said:
Intel is working on a microcode update. CPUs don't have any sort of writable memory to store a "firmware" in, so it's stored the motherboard BIOS which then programs the CPU with the microcode at each boot.

So the issue is that a BIOS update with the new microcode could take a while to resolve (if ever for motherboards more than a couple years old).
Click to expand...

Microcode can be updated from the OS too.
 
pcgeekesq said:
Do you understand the difference between a software patch and a microcode patch?

Note that most if not all modern x86 processors translate the x86 instructions into native hardware instructions before executing them. Microcode patches alter these translations, and can therefore be used to make some pretty large changes in how the processor operates. It's a very powerful tool.

And Intel's truthfulness, like any publicly-traded corporation, is a function of how much any lie might affect the stock price. Lying about this probably would affect it a good bit, creating potentially severe civil and criminal liability, so they are less likely to do so.
Click to expand...

I do, do you? Perhaps you should read the white paper on the issue where they explain why they don't think this can be easily fixed without changing the hardware architecture and the Instruction sets themselves?

EDIT: Just to help, this is straight from the Spectre whitepaper:

"While makeshift processor-specific countermeasures
are possible in some cases, sound solutions will require
fixes to processor designs as well as updates to instruc-
tion set architectures (ISAs) to give hardware architects
and software developers a common understanding as to
what computation state CPU implementations are (and
are not) permitted to leak."

EDIT EDIT: To get a better picture of this on why this is more problematic than other software exploits, software exploits are introducing problems within the software. These kind of exploits can be fixed far more easily by just correcting the problems in software. This problem resides in the way the hardware is designed. The researchers believe at best you can mask the problem, obscure it, or redirect, but it can't be truly fixed unless you fix the actual processor design and instruction set. This is why I don't have any faith in either what Intel or AMD are saying about being able to completely mitigate the problem that we shouldn't worry. I believe it is incredibly naive to think the problem can so easily be fixed in such a short time with rushed software patches.
 
Last edited:
  • Like
Reactions: Parja
like this
NoOther said:
I do, do you? Perhaps you should read the white paper on the issue where they explain why they don't think this can be easily fixed without changing the hardware architecture and the Instruction sets themselves?

EDIT: Just to help, this is straight from the Spectre whitepaper:

"While makeshift processor-specific countermeasures
are possible in some cases, sound solutions will require
fixes to processor designs as well as updates to instruc-
tion set architectures (ISAs) to give hardware architects
and software developers a common understanding as to
what computation state CPU implementations are (and
are not) permitted to leak."

EDIT EDIT: To get a better picture of this on why this is more problematic than other software exploits, software exploits are introducing problems within the software. These kind of exploits can be fixed far more easily by just correcting the problems in software. This problem resides in the way the hardware is designed. The researchers believe at best you can mask the problem, obscure it, or redirect, but it can't be truly fixed unless you fix the actual processor design and instruction set. This is why I don't have any faith in either what Intel or AMD are saying about being able to completely mitigate the problem that we shouldn't worry. I believe it is incredibly naive to think the problem can so easily be fixed in such a short time with rushed software patches.
Click to expand...

I was a micro-processor architect and later a cryptosecurity system architect for Intel. So yes, I understand the difference. Probably better than the people you are quoting. How many years of designing microprocessor pipelines, multi-level cache architectures, and platform security hardware for a living do they have? Or you?

You're just quoting people from the Internet, giving conclusions with no pertinent analysis and no credentials to back them.
For all you know, it's fake news. After all, you read it on the Internet, and apparently you have no pertinent expertise to calibrate you BS detector with. I do.
Just the fact that high-end Intel CPUs are all patchable emulators should make you doubt what you're parroting.
 
pcgeekesq said:
I was a micro-processor architect and later a cryptosecurity system architect for Intel. So yes, I understand the difference. Probably better than the people you are quoting. How many years of designing microprocessor pipelines, multi-level cache architectures, and platform security hardware for a living do they have? Or you?

You're just quoting people from the Internet, giving conclusions with no pertinent analysis and no credentials to back them.
For all you know, it's fake news. After all, you read it on the Internet, and apparently you have no pertinent expertise to calibrate you BS detector with. I do.
Just the fact that high-end Intel CPUs are all patchable emulators should make you doubt what you're parroting.
Click to expand...

Actually I quoted directly from the whitepaper written by the researchers who discovered the flaw. Seriously, I don't care who you are or what you did, the fact that you can't even read the papers and information from those that found the flaw is seriously concerning when you then want to lecture others. And then you make claims as to my experience, when you have absolutely no idea what my experience is. But please, keep attacking me since you have no other recourse...
 
pcgeekesq said:
I was a micro-processor architect and later a cryptosecurity system architect for Intel. So yes, I understand the difference. Probably better than the people you are quoting. How many years of designing microprocessor pipelines, multi-level cache architectures, and platform security hardware for a living do they have? Or you?

You're just quoting people from the Internet, giving conclusions with no pertinent analysis and no credentials to back them.
For all you know, it's fake news. After all, you read it on the Internet, and apparently you have no pertinent expertise to calibrate you BS detector with. I do.
Just the fact that high-end Intel CPUs are all patchable emulators should make you doubt what you're parroting.
Click to expand...

Thank you for giving your input on this. There's too much misinformation going around about this from people who have no idea what they're talking about. Reading the rest of NoOther's replies, it's clear he's just parroting anything he hears without actually understanding it.

Now, the question I have is, would you consider this a design flaw? I keep trying to tell my friends this is a performance feature that was exploited, but they're full of anti-Intel rhetoric and demonization.
 
EBound said:
Thank you for giving your input on this. There's too much misinformation going around about this from people who have no idea what they're talking about. Reading the rest of NoOther's replies, it's clear he's just parroting anything he hears without actually understanding it.

Now, the question I have is, would you consider this a design flaw? I keep trying to tell my friends this is a performance feature that was exploited, but they're full of anti-Intel rhetoric and demonization.
Click to expand...

Am I, or are you just listening to someone claiming they know what is going on. I at least provided links directly to the research that was done on this security flaw. Seriously people, come on now.
 
EBound said:
Now, the question I have is, would you consider this a design flaw? I keep trying to tell my friends this is a performance feature that was exploited, but they're full of anti-Intel rhetoric and demonization.
Click to expand...
It's a design flaw in a performance feature. CPUs are fast and memories are slow, so the CPU is guessing what you're going to need soon and asking for it in advance. This is very commonly done. Here, the processing of the guess is apparently sometimes leaving the contents of memory you shouldn't be able to see where you can see it. That's a design flaw but a damn subtle one.

Modern CPUs are too complicated to be perfect.
People used to dream of logically proving a design correct, but life and product cycles are too short for that.
 
Last edited:
NoOther said:
Actually I quoted directly from the whitepaper written by the researchers who discovered the flaw.
Click to expand...
So? Are they experts in the micro-architecture of high-performance microprocessors? Are they experts in the particulars of Intel x86 microprocessors? Do they have clue-1 as to what Intel's microcode patching system is and isn't capable of? Have they published the analysis behind their conclusions?

The answer to at least some and perhaps all of those questions is probably NO.
And if that isn't causing the needle to move on your BS detector, better get it checked.
 
pcgeekesq said:
It's a design flaw in a performance feature. CPUs are fast and memories are slow, so the CPU is guessing what you're going to need soon and asking for it in advance. This is very commonly done. Here, the processing of the guess is apparently sometimes leaving the contents of memory you shouldn't be able to see where you can see it. That's a design flaw but a damn subtle one.

Modern CPUs are too complicated to be perfect.
People used to dream of logically proving a design correct, but life and product cycles are too short for that.
Click to expand...

Thank you for your input on that! I'll change my rhetoric, but like you said, it's very subtle. I just hear people saying Intel needs to recall all of these or should be sued for continuing to sell them when the exploit was known. I work on the manufacturing side, so I laugh when people think this is a feasible option for something like this. It sounds like in the future this feature will probably be nixed, but hopefully there's a workaround that keeps things secure while maintaining close to the same performance.
 
Oh man how nice would it be if Intel would step up to the plate, fix the issue in the chips and allow you to cross ship RMA your affected chip(s) as stock on the new version of the processor becomes available. That would be a pretty good PR move on their part, but would likely be insanely expensive, even if they only did that for chips purchased within say the past year.
 
You must log in or register to reply here.
Back
Top