• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

Page 49 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

csbin

Senior member
Feb 4, 2013
834
339
136
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html


On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
> > All of this is pure garbage.
> >
> > Is Intel really planning on making this shit architectural? Has
> > anybody talked to them and told them they are f*cking insane?
> >
> > Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.

You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.

> Certainly it's a nasty hack, but hey â the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.

It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable â as long as it
> can die entirely by the next generation.

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit â just "you don't have to worry any more, it got better".

It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.

The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".

So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.

I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.

> We do need the IBPB feature to complete the protection that retpoline
> gives us â it's that or rebuild all of userspace with retpoline.

BULLSHIT.

Have you _looked_ at the patches you are talking about? You should
have - several of them bear your name.

The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.

If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.

As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.

It's mis-designed for two major reasons:

- the "the interface implies Intel will never fix it" reason.

See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.

Do you really think that is acceptable?

- the "there is no performance indicator".

The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.

But since we already know that the IBRS overhead is <i>huge</i> on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.

I think we need something better than this garbage.

Linus
 

richaron

Golden Member
Mar 27, 2012
1,357
329
136
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html


On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
> > All of this is pure garbage.
> >
> > Is Intel really planning on making this shit architectural? Has
> > anybody talked to them and told them they are f*cking insane?
> >
> > Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.

You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.

> Certainly it's a nasty hack, but hey â the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.

It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable â as long as it
> can die entirely by the next generation.

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit â just "you don't have to worry any more, it got better".

It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.

The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".

So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.

I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.

> We do need the IBPB feature to complete the protection that retpoline
> gives us â it's that or rebuild all of userspace with retpoline.

BULLSHIT.

Have you _looked_ at the patches you are talking about? You should
have - several of them bear your name.

The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.

If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.

As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.

It's mis-designed for two major reasons:

- the "the interface implies Intel will never fix it" reason.

See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.

Do you really think that is acceptable?

- the "there is no performance indicator".

The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.

But since we already know that the IBRS overhead is <i>huge</i> on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.

I think we need something better than this garbage.

Linus
It's nice to hear the opinion of an actual expert rather than the usual forum warriors in damage control ^
 

FIVR

Diamond Member
Jun 1, 2016
3,753
907
106
It sounds like there are more exploits that Intel knows it is susceptible to but doesn't want to reveal yet. Intel is trying to patch these exploits without users ever knowing they exist, which is why their patches appear nonsensical.


It's either that, or intel isn't actually patching the exploits at all because the true performance hits are really bad. Either way it's bad news for intel and while they may fool average users they won't fool Apple and Google.
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126
It sounds like there are more exploits that Intel knows it is susceptible to but doesn't want to reveal yet. Intel is trying to patch these exploits without users ever knowing they exist, which is why their patches appear nonsensical.


It's either that, or intel isn't actually patching the exploits at all because the true performance hits are really bad. Either way it's bad news for intel and while they may fool average users they won't fool Apple and Google.
Well, they don't need to fool average users as this is not really any problem for average users.
They would need to fool Amazon/Apple/Google etc., if they are going to fool anyone, and I don't see that working.

I asked a few employees, none were even aware of Meltdown or Spectre or any such problems.
Few could tell me what brand of CPU was in the computer they used most of the time.
 

richaron

Golden Member
Mar 27, 2012
1,357
329
136
Well, they don't need to fool average users as this is not really any problem for average users.
They would need to fool Amazon/Apple/Google etc., if they are going to fool anyone, and I don't see that working.

I asked a few employees, none were even aware of Meltdown or Spectre or any such problems.
Few could tell me what brand of CPU was in the computer they used most of the time.
Yes, they for sure are trying to fool average users as well. The sort of average users who ask "do you use a PC or a Mac?" lol. In this case average people talk about whether their computer is an i5 or an i7, and they have obviously seen the "intel inside" sticker on the computer they use every day.

And intel CPUs are the only desktop CPUs affected by the Meltdown bug. If people learn this then they will understand there are other options out there. And if they learn about the joke of a response intel has made to these bugs they might even go looking for other options.
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126
Yes, they for sure are trying to fool average users as well. The sort of average users who ask "do you use a PC or a Mac?" lol. In this case average people talk about whether their computer is an i5 or an i7, and they have obviously seen the "intel inside" sticker on the computer they use every day.

And intel CPUs are the only desktop CPUs affected by the Meltdown bug. If people learn this then they will understand there are other options out there. And if they learn about the joke of a response intel has made to these bugs they might even go looking for other options.
Meltdown seems to be patched by the Win10 update, though.
My i5-3330 system says it is not vulnerable to Meltdown.
I have mentioned this before.
 

richaron

Golden Member
Mar 27, 2012
1,357
329
136
Meltdown seems to be patched by the Win10 update, though.
My i5-3330 system says it is not vulnerable to Meltdown.
I have mentioned this before.
Yep, intel CPUs are the only desktop CPUs affected by the Meltdown bug. We've been talking about the horrible way intel handled the situation, like by implying everyone is equally affected. It's this sort of misinformation we've been talking about and what I've doing my 2c to correct.

And just above we can see an actual experts opinion on intel's attempt to patch their buggy CPUs. Which is another way intel appears to have failed to sufficiently address this situation. So even if it appears patched to you there are still major ways intel failed to sufficiently address this problem, and the actual affect of intel's patches has yet to be sufficiently quantified. So let's just take an expert's opinion of the patches:

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html


On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
> > All of this is pure garbage.
> >
> > Is Intel really planning on making this shit architectural? Has
> > anybody talked to them and told them they are f*cking insane?
> >
> > Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.

You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.

> Certainly it's a nasty hack, but hey â the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.

It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable â as long as it
> can die entirely by the next generation.

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit â just "you don't have to worry any more, it got better".

It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.

The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".

So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.

I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.

> We do need the IBPB feature to complete the protection that retpoline
> gives us â it's that or rebuild all of userspace with retpoline.

BULLSHIT.

Have you _looked_ at the patches you are talking about? You should
have - several of them bear your name.

The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.

If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.

As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.

It's mis-designed for two major reasons:

- the "the interface implies Intel will never fix it" reason.

See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.

Do you really think that is acceptable?

- the "there is no performance indicator".

The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.

But since we already know that the IBRS overhead is <i>huge</i> on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.

I think we need something better than this garbage.

Linus
 
Last edited:

coercitiv

Diamond Member
Jan 24, 2014
4,252
5,373
136
Well, they don't need to fool average users as this is not really any problem for average users.
They need to fool the average users, in the sense that they need to fool the press. If it ever comes out that their (final) solution is not enough (unlikely scenario, but let's indulge), the same ignorance of the average user that protects them right now will become a great liability. Users will read the headlines "Intel CPUs vulnerable, no fix possible" and that will stick.

This is the same reason Intel PR lead their initial announcements by mentioning both ARM and AMD in conjecture with the vulnerabilities, to make sure their names are associated with the flaws as well. Their telegraphed message looked like this "Flaw detected, working with AMD and ARM to fix it".

By comparison Apple had a far more balanced approach: they also stated the flaws affect many CPU types from various vendors (no names though), and they proceeded to announce that most of their systems were already patched with previously launched OS versions or were in the process of being patched. Their telegraphed message look like this "Flaw detected in many modern CPUs, we have fixes for all Apple products". I'm not an Apple fan by any measure, and their other recent security problems were quite disturbing, but as far as this crisis was handled they should be considered as an example for the Intel folks.

To provide more context, something nasty happened in the days prior to the agreed date for the vulnerability announcement: AFAIK AMD made some Linux commits with a bit too much embedded info. This led to chatter, the press picked it up, and it ended up as a story before the big companies were ready to spill the beans. Some people, including one Ars Technica editor, talked about this potentially being AMD's fault in the sense that they may have (intentionally) helped others figure out the news before time. While this may or may not be true, the other side of the story is equally probable: AMD may have found out that Intel, who was supposed to lead the press announcements, made it a priority to put AMD products in the same vulnerability class as Intel products.

Whether the above is true or not is very hard to tell, the press never found out enough to point fingers, but personally I feel pretty confident to say that the customers did not get the treatment they deserved from either Intel or AMD, in the sense that they were too busy watching their own backs instead of customer interest. They were also utterly unprepared for the actual release date, in the sense that many of their corporate customers had to get their information from other sources than their vendors (they ended up sharing info between them as they figured out what was going on). It's one thing to keep them in the dark for security reasons, another thing to not have proper documentation at hand when it became public.

The industry players need to learn how play play ball when it comes to security, the next (major) vulnerability may end up being discovered by state actors and used during times of conflict. I really don't need Intel and AMD pointing fingers at each other while computers shut down one by one in the western part of the world.
 
Last edited:
  • Like
Reactions: KompuKare

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126
I'm totally happy with Intel regarding Meltdown, actually.

My Ivy Bridge and Haswell systems were patched quickly against Meltdown, and if they have slowed down, it's not noticeable to me.
I have seen no re-booting issues.

I have no reason to complain about Meltdown, that I can see.
I never considered it a bug in the first place, but I realize there are arguments there.

Spectre is a different story, but it seems far less likely to be an actual problem.

I have no need to update to a new system right now, so I can afford to just sit back and wait until hardware fixes arrive.

I have not checked my AMD FX systems yet, and I probably just won't worry about them.
 

coercitiv

Diamond Member
Jan 24, 2014
4,252
5,373
136
If this is how Intel plans to ship fixed hardware this year... I'm gonna laugh an cry at the same time.

Rather than preventing abuse of processor branch prediction by disabling the capability and incurring a performance hit, Chipzilla's future chips – at least for a few years until microarchitecture changes can be implemented – will ship vulnerable by default but will include a protection flag that can be set by software.

Intel explained its approach in its technical note about Spectre mitigation, titled Speculative Execution Side Channel Mitigations. Instead of treating Spectre as a bug, the chip maker is offering Spectre protection as a feature.
The expectation here, at least on Torvald's part, is that a chip addressing past flaws should include a flag that tells the kernel it's not vulnerable, so no unneeded and potentially performance-killing mitigations need to be applied. In other words, the chip should indicate to the kernel that its design has been revised and thus does not need any mitigations or workarounds.

Intel's approach is backwards, making the fix opt-in. Processors can, when asked, reveal to the kernel that Spectre countermeasures are present but disabled by default, and these need to be enabled by the operating system.
 

Shamrock

Golden Member
Oct 11, 1999
1,203
220
106
Just an observation, but IMO, Microsoft has seized an opportunity to get people OFF of WIn7, by royally screwing up the Win7 patches. SO bad, I have had to uninstall it, until my MSI bios is published.
 
  • Like
Reactions: Schmide

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126

Updated to add
After this story was filed, an Intel spokesperson emailed The Register to say: “We take the feedback of industry partners seriously. We are actively engaging with the Linux community, including Linus, as we seek to work together on solutions.”
Too bad Linus decided to go to the media first to make headlines, instead of talking to Intel first.
Fortunately it seems that they are working on Spectre and making some progress.

Spectre seems to be the only thing left to worry about.
Spectre v3, aka Meltdown, seems patched fairly well with little impact.

I haven't heard much of AMD's Spectre 1 and 2 efforts and their performance effects.
https://www.amd.com/en/corporate/speculative-execution
 
  • Like
Reactions: pcp7

FIVR

Diamond Member
Jun 1, 2016
3,753
907
106
Looks like the performance hit from these intel patches is MUCH worse than what intel is claiming, especially for their U series laptops. Benchmarks are showing at best a 5% loss in performance and in practice much closer to 15-35% loss of performance when using solid state drives.

https://m.youtube.com/watch?v=ZnQPdZKDhPs


If people realize intel is actually 5%-35% slower than they claim in benchmarks these U chip laptops are going to have to be discounted accordingly to sell against Ryzen 3 and Ryzen 5. Intel better get to work on some rebates.
 

FIVR

Diamond Member
Jun 1, 2016
3,753
907
106
Too bad Linus decided to go to the media first to make headlines, instead of talking to Intel first.
Fortunately it seems that they are working on Spectre and making some progress.

Spectre seems to be the only thing left to worry about.
Spectre v3, aka Meltdown, seems patched fairly well with little impact.

I haven't heard much of AMD's Spectre 1 and 2 efforts and their performance effects.
https://www.amd.com/en/corporate/speculative-execution
Oh yes, it is too bad for intel that Linus decided to tell the world about their nonessential patches and attempts to obscure the issue. If only Linus had kept his mouth shut intel PR would be able to tell people whatever they wanted and they would probably believe it. Now people realize intel is lying.


This whole fiasco is just too bad for intel. How sad!
 

JoeRambo

Golden Member
Jun 13, 2013
1,045
824
136
Spectre v3, aka Meltdown, seems patched fairly well with little impact.
Impact is rather large IF all you do is a ton of syscalls ( like in disk tests, or real life NVMe based database solution). Real deal is future Intel CPU with Meltdown fixed in hardware and KPTI OS bs disabled in Linux/Windows.

Spectre is completely different beast, current solutions are horrible mess in software ( both retpoline efforts to protect kernel and/or userland AND those horrible things Intel is inflicting with those MSR writes to control speculation and stuff).
And if I were ARM/AMD/VIA/Cyrix fan i'd not rush to bash Intel with Spectre bat just yet( while Meltdown bashes are well deserved :) ). Now that the gates are open, researchers are probably cooking even more nasty exploits, way beyond what was admitted by vendors.
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126
Looks like the performance hit from these intel patches is MUCH worse than what intel is claiming, especially for their U series laptops. Benchmarks are showing at best a 5% loss in performance and in practice much closer to 15-35% loss of performance when using solid state drives.

https://m.youtube.com/watch?v=ZnQPdZKDhPs


If people realize intel is actually 5%-35% slower than they claim in benchmarks these U chip laptops are going to have to be discounted accordingly to sell against Ryzen 3 and Ryzen 5. Intel better get to work on some rebates.
Benchmarks or real world? I can't watch the vid where I am, but I'm guessing it's benchmarks?
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126
Lol this dude is a completely independent expert in the field, talking about bug fixes intel has had months to work on, and you think it's better we should instead wait for intel damage control PR :rolleyes:
Intel is clearly still working on this, so Linus isn't helping any by screeching to the press instead of working with Intel.
 

richaron

Golden Member
Mar 27, 2012
1,357
329
136
Intel is clearly still working on this, so Linus isn't helping any by screeching to the press instead of working with Intel.
Nope, Linus is helping by being an expert in the field and informing the rest of us about intel's joke of a response. Intel has had plenty of time and expertise and it it appears they've still failed pretty bad.

Yet you seem to keep trying to imply intel is doing a good job. I think I'll take the word of an independent expert. Obviously everyone else should as well.
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,573
126
Nope, Linus is helping by being an expert in the field and informing the rest of us about intel's joke of a response. Intel has had plenty of time and expertise and it it appears they've still failed pretty bad.

Yet you seem to keep trying to imply intel is doing a good job. I think I'll take the word of an independent expert. Obviously everyone else should as well.
It'll all come out in the wash...and there's absolutely nothing at all that I can do in any case.
Except wait to buy my next CPU.
Haswell systems (one desktop & one Xeon) report meltdown is patched and performance is "good".
Ivy Bridge reports meltdown is patched and performance is "slower", but it's not noticeable.
FX-6300 system reports meltdown is patched and performance is "good".
All report Spectre vulnerability, but I expect no help on that at all, and I don't consider it a threat for my desktop systems anyway.
 

ASK THE COMMUNITY

TRENDING THREADS