TR Forums

Glorious · Thu Mar 15, 2018 9:16 am

Given how Intel's been talking though, that could merely be them saying that they will be including microcode like they have for the old chips with the news ones from the outset

...which doesn't really mean much of anything...

derFunkenstein · Thu Mar 15, 2018 9:19 am

Bauxite wrote:
Honestly though the best policy is you have computer(s) just for surfing and it can't connect in any meaningful way (shares, casual file transfer, etc) to computers you care about. Its hard because you have to change your habits. You are the biggest security threat.

For a while I worked as a contractor in IT for a Fortune 100 company. Thanks to Group Policies, all the PCs that ran the factory had IE (IE6 at the time, yuck) disabled and were blacklisted from getting to the outside world, so even if you got another browser installed you couldn't do anything. They still needed access to stuff on the network (schematics and whatnot), so they were plugged in, but you couldn't do anything dangerous with them.

We also couldn't reach any of those machines through remote desktop support tools. The foreman or someone higher up in the building would call level 1, those tickets would automatically get kicked to my group, and then we'd have to kick them back to an on-site guy. Not sure why they couldn't just go to him, but everything had to go through global IT. :lol:

chuckula · Thu Mar 15, 2018 9:23 am

Glorious wrote:
Given how Intel's been talking though, that could merely be them saying that they will be including microcode like they have for the old chips with the news ones from the outset

...which doesn't really mean much of anything...

Since Meltdown could not be fixed by microcode there definitely are some real hardware changes in there. The Spectre v2 mitigations might be microcode or hardware changes + microcode.

Glorious · Thu Mar 15, 2018 9:29 am

chuckula wrote:
Since Meltdown could not be fixed by microcode there definitely are some real hardware changes in there.

You misunderstand.

I'm going by what Intel has officially said here (as, you know, I *explicitly* said previously):

https://newsroom.intel.com/news-release ... -exploits/

Intel wrote:
SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.

Intel blatantly and publicly stated that microcode updates for "all types" of their chips will "immunize" against both exploits.

Thus, since Intel has previously said that microcode can render their products immune in the past, they equally could be making the same statement about the future.

chuckula wrote:
The Spectre v2 mitigations might be microcode or hardware changes + microcode.

The former is far, far more likely.

chuckula · Thu Mar 15, 2018 9:33 am

Glorious wrote:
chuckula wrote:
Since Meltdown could not be fixed by microcode there definitely are some real hardware changes in there.

You misunderstand.

I'm going by what Intel has officially said here (as, you know, I *explicitly* said previously):

https://newsroom.intel.com/news-release ... -exploits/

Intel wrote:
SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.

Intel blatantly and publicly stated that microcode updates for "all types" of their chips will "immunize" against both exploits.

Thus, since Intel has previously said that microcode can render their products immune in the past, they equally could be making the same statement about the future.

chuckula wrote:
The Spectre v2 mitigations might be microcode or hardware changes + microcode.

The former is far, far more likely.

Read your quote again carefully:

SANTA CLARA, Calif., Jan. 4, 2018 — Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.

It said "updates". The word "microcode" never showed up in that quote. An "update" can certainly be a software update like the Linux KPTI infrastructure that was a software fix for Meltdown. Or it could be a combination of microcode + software to fix Spectre. As cited in Intel's official announcement, newer chips have hardware mitigation for Meltdown that's clearly something new because if there was a simple microcode switch that would have fixed Meltdown, Intel definitely would have flipped it on instead.

Glorious · Thu Mar 15, 2018 10:10 am

chuckula wrote:
It said "updates". The word "microcode" never showed up in that quote. An "update" can certainly be a software update like the Linux KPTI infrastructure that was a software fix for Meltdown. Or it could be a combination of microcode + software to fix Spectre. As cited in Intel's official announcement, newer chips have hardware mitigation for Meltdown that's clearly something new because if there was a simple microcode switch that would have fixed Meltdown, Intel definitely would have flipped it on instead.

And if this a novel round of "combination of hardware and software updates" we are still basically playing the same game.

I mean, microcode is updatable in the field, but it also comes with the processors and originally it obviously wasn't. We are really playing on the borders of what is "hardware" versus what is "firmware" so this is clearly a game where you can easily call a minor change "hardware" when it reality you just let the microcoders do more than what they ever could *after* release.

For instance, what would you call making the sort of microcode change to LFENCE Intel did permanent? That literally makes it hardware, does it not?

So what does Intel actually say?

https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/

EDIT2: This is what I meant to cite, what the quote below is from (NOT CHUCKULA LOL)
https://newsroom.intel.com/editorials/a ... con-level/

Intel wrote:
We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3. Think of this partitioning as additional “protective walls” between applications and user privilege levels to create an obstacle for bad actors.

....that is not very clear at all in any aspect other than how he is clearly indicating that this isn't remotely absolute.

But if you are telling me that after the microcode release debacle that they made for-real serious changes to the silicon for a chip that is going to be released on schedule despite this whole thing becoming known to Intel exactly when that silicon was probably taping out?

Come on.

They've been playing fast and loose about this from the start. This "hardware" change just about can't be fundamental, it has to be microcoded, right? Just because it's slightly deeper microcode, the layer that won't ever update, and thus "hardware" doesn't mean that Intel isn't doing the same thing they were originally about this.

But sure, yeah, it's all absolutely on the level. It's really important that wishy-washy "mitigations" and "obstacles" be referred to as "hardware hardware hardware" to Intel's PR benefit.

EDIT: to make this more clear, I'm not coming into this out of the woods like a babe: I read the linux mailing list and Linus Torvalds was screaming about how Intel was all but saying in their patches (which were also all caps GARBAGE etc... according to him) that Intel were never going to fix this in hardware. That wasn't even three months ago.

DancinJack · Thu Mar 15, 2018 10:29 am

Krzanich specifically says hardware here - https://newsroom.intel.com/editorials/a ... con-level/

While Variant 1 will continue to be addressed via software mitigations, we are making changes to our hardware design to further address the other two. We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3. Think of this partitioning as additional “protective walls” between applications and user privilege levels to create an obstacle for bad actors.

He could just be talking, too.

No need to have a cat fight about it though.

Glorious · Thu Mar 15, 2018 10:31 am

Krzanich specifically says hardware here

Actually that was I *MEANT* to cite, and then I quote CHUCKULA as the quote from it.

Wow.

Let me fix my post.

DancinJack · Thu Mar 15, 2018 10:32 am

Glorious wrote:
Krzanich specifically says hardware here

Actually that was I *MEANT* to cite, and then I quote CHUCKULA as the quote from it.

Wow.

Let me fix my post.

Glorious · Thu Mar 15, 2018 10:33 am

Yeah, thanks!

What I posted was an absolute mess.

chuckula · Thu Mar 15, 2018 11:51 am

Glorious wrote:
EDIT: to make this more clear, I'm not coming into this out of the woods like a babe: I read the linux mailing list and Linus Torvalds was screaming about how Intel was all but saying in their patches (which were also all caps GARBAGE etc... according to him) that Intel were never going to fix this in hardware. That wasn't even three months ago.

With all due respect to Torvalds, his time long long ago at Transmeta and his reaction to this entire affair shows more about his ignorance of hardware design than anything else. I'm especially amused by his "OMG THESE BUGS ARE SO OBVIOUS" rants when he's been more than happy to accept the performance gains from speculative instruction over the years. If these bugs were so "obvious" then Torvalds should have been telling us all about them 16 years ago when he was at Transmeta and could have really helped his cause. Except he didn't. Because for all his bluster these bugs are clearly not that obvious... or else ARM wouldn't have gone out of its way to introduce Meltdown into its one and only "high performance" core design that's just beginning to hit the market this year.

As for your interpretation of what Torvalds was complaining about: There's absolutely no reason that Meltdown can't be fixed in hardware AND Intel continues to use and refine KPTI in the Linux kernel for use with future CPUs, even if Meltdown doesn't affect those CPUs. If you look at what KPTI does, it's actually a very nice security architecture that helps to enforce separation between kernel & userspace more strictly. I don't expect KPTI to just disappear after newer CPUs with Meltdown hardware fixes come to market.

Glorious · Thu Mar 15, 2018 12:08 pm

chuckula wrote:
With all due respect to Torvalds, his time long long ago at Transmeta and his reaction to this entire affair shows more about his ignorance of hardware design than anything else. I'm especially amused by his "OMG THESE BUGS ARE SO OBVIOUS" rants when he's been more than happy to accept the performance gains from speculative instruction over the years. If these bugs were so "obvious" then Torvalds should have been telling us all about them 16 years ago when he was at Transmeta and could have really helped his cause. Except he didn't. Because for all his bluster these bugs are clearly not that obvious... or else ARM wouldn't have gone out of its way to introduce Meltdown into its one and only "high performance" core design that's just beginning to hit the market this year.

So instead of talking about how I've detailed that Intel is being very vague here and has a history of not being the most earnestly straightforward on this issue....

...you are making personal attacks against Linus Torvalds because I mentioned him in explicit ninja edit to toss in an aside comment?

Come on.

Also, the bluster you refer to isn't even the relevant part of that aside, which was that Intel's patches indicated that they *didn't* have a hardware fix just waiting in the wings for the next cycle (because Torvalds was particularly screaming about IBRS, which was a Spectre v2 mitigation, -NOT- meltdown as your next paragraph relies upon).

Again, I think that Intel's CEO is dramatically overstating this "hardware" solution, and I have multiple lines of argument to establish that. Just taking today's announcement as absolute text, why is this hardware fix crouched in language like "obstacle" and "additional" (wait, so we had some already, did we?) "protective walls"?

Why can they make a cute and snazzily-produced video that "explains" all this, but not write a few more sentences about just what this "parititioning" actually is?

chuckula wrote:
As for your interpretation of what Torvalds was complaining about: There's absolutely no reason that Meltdown can't be fixed in hardware AND Intel continues to use and refine KPTI in the Linux kernel for use with future CPUs, even if Meltdown doesn't affect those CPUs. If you look at what KPTI does, it's actually a very nice security architecture that helps to enforce separation between kernel & userspace more strictly. I don't expect KPTI to just disappear after newer CPUs with Meltdown hardware fixes come to market.

I talked the security implications of KPTI in general at great length earlier in this thread, so yes, I know all that.

Here's what I didn't know:

chuckula wrote:
Intel continues to use and refine KPTI in the Linux kernel for use with future CPUs

Intel now dictates linux kernel development? Intel "uses" a particular feature of the kernel? Yes, if the kernel developers allow for it, Kconfig for it, or I patch it in myself, sure. But what does that have to do with Intel? I mean, yes, Intel can patch literally anything they like, but if it isn't committed to mainline or whatever...?

Unless you are talking about intel cpus USED BY INTEL, do you even realize what you are saying here?

Thu Mar 15, 2018 12:17 pm

I'm sure Intel has a lot of input, if not actual devs who contribute code to the Linux kernel.

chuckula · Thu Mar 15, 2018 12:25 pm

Glorious wrote:

Intel now dictates linux kernel development? Intel "uses" a particular feature of the kernel? Yes, if the kernel developers allow for it, Kconfig for it, or I patch it in myself, sure. But what does that have to do with Intel? I mean, yes, Intel can patch literally anything they like, but if it isn't committed to mainline or whatever...?

Unless you are talking about intel cpus USED BY INTEL, do you even realize what you are saying here?

Oh please, let's ratchet the clearly disingenuous histrionics down about 100 notches or so. Unless you at least want to be consistent and accuse AMD of hijacking the Linux kernel the next time one of their developers sends in a driver patch. It's called an "open source" project. Intel is actually the #1 organizational contributor to the kernel. They can submit software patches. It's not histrionic fake-outrage, it's called completely ordinary.

As for any alleged "personal attacks" on Torvalds... for somebody who claims to read the LKML you sure have a strange definition of what constitutes a "personal attack" while reading Linus's emails.

Glorious · Thu Mar 15, 2018 12:43 pm

JBI wrote:
I'm sure Intel has a lot of input, if not actual devs who contribute code to the Linux kernel.

You know that I know this.

chuckula wrote:
Oh please, let's ratchet the clearly disingenuous histrionics down about 100 notches or so. Unless you at least want to be consistent and accuse AMD of hijacking the Linux kernel the next time one of their developers sends in a driver patch. It's called an "open source" project. Intel is actually the #1 organizational contributor to the kernel. They can submit software patches. It's not histrionic fake-outrage, it's called completely ordinary.

You also know that I know this. So who is disingenuous?

Let's get back to what I actually said, not this make-believe where you pretend I meant something ridiculous and facile:

I said the kernel developers had to allow for it, because they patch it into mainline.

I explicitly said that. If you even attempt to push this ridiculous lie any further I will quote it at you repeatedly, because what you are doing is absolutely shameful.

What you are saying is different, as you are treating the kernel developer's decision to leave KPTI in as if it was personally up to Dave Hansen (yes, an Intel employee) or the other individual submitters from Intel.

It isn't, so while Intel can keep submitting new patches & refining existing patches they *CANNOT* "continue to use" KPTI in the linux kernel for future CPUs because that choice 100% isn't up to them and therefore they fundamentally can neither rely upon it nor take credit for it. They can only do that under their own prerogative for their own use or for their own distribution.

But, yes, feel free to ignore that CRITICAL POINT in favor of pretending that I'm astoundingly ignorant of patch contributors despite obviously being familiar with the scene. :roll:

chuckula wrote:
As for any alleged "personal attacks" on Torvalds... for somebody who claims to read the LKML you sure have a strange definition of what constitutes a "personal attack" while reading Linus's emails.

Who is Linus shilling for?

EDIT: Let's be clear here, you are taking an omission of a fact, not a contradiction of facts whether explicit or even implicit, as absolute evidence that I am in ignorance of that fact.

Not that, maybe, that fact is not only irrelevant to the discussion, but is rather something so well-known and obvious that there was no need for me to remark upon its existence in the first place.

I don't dislike Intel, I am being critical of Intel because I do not feel they are being as straightforwardly earnest as they should be.

I'm sorry that you would prefer that companies say vague things with less forthright candor than they otherwise could.

Perhaps you are a share-holder. I'm not, I'm just a customer. Perhaps that's why we have different concerns...

Welch · Wed Mar 21, 2018 10:18 pm

Glorious, I'm curious why exactly you think it is more likely to be just a microcode patch.

For the sake of speaking the same language let's agree on terminology.

Software - You can consider this anything that can be programmed to the hardware. This should include any program that may be a payload intended to make permanent changes

Hardware - Physical components, as simple as that.

Are these acceptable takes on Hardware/Software?

I think from what you and Chuckla quoted, it's pretty clear that Intel is stating Hardware or physical changes for future chips, not a firmware/micro code update only. I mean we can all guess at what Intel really means *wink wink, nod nod*, but I don't see any reason to doubt hardware changes.

For instance, Samsung and the big 840 EVO debacle. Sure they had a fix (eventually)... But was it really a fix? No, it was a firmware change that was a workaround at the cost of drive life, roughly 2% IIRC. If there is any negative side effects to JUST a microcode update for Intel, I'd suspect that nothing short of a hardware revision would be their course of action. It sort of stands to reason, unless Intel is trying to be lazy on it and think no one would notice, and clearly people would.

Glorious · Thu Mar 22, 2018 8:07 am

Welch wrote:
Glorious, I'm curious why exactly you think it is more likely to be just a microcode patch.

Because, without slipping the schedule, how did they make serious changes to the actual silicon for a chip that was taped out roughly around when Intel was first notified of this problem (June 2017).

Remember, they goofed the initial microcode patch, but they're not even remotely gun-shy about producing new masks etc... without adjusting their launch dates in the slightest?

How is that possible?

Welch wrote:
Software - You can consider this anything that can be programmed to the hardware. This should include any program that may be a payload intended to make permanent changes

But this is the point: It wasn't like the P6 was microcoded and the P5 wasn't, it is just that Intel added the MSRs (IA32_UCODE_REV, IA32_UCODE_WRITE...) to allow end-users to update the microcode.

Furthermore, it is facile to assume that what is updateable is the entire extent of what was microcoded--it is far more likely that what can be updated after release is only a subset of what is programmable -before- release.

Welch wrote:
Hardware - Physical components, as simple as that.

Again, no. It is not that simple.

The explanation for this is simple: If Intel disabled the microcode update facility but deployed the most recent microcode currently publicly available, viola, what was software under your dichotomy becomes hardware. And, I must add, the transition occurred via Intel's unilateral discretion.

That is, Intel just decided what is hardware versus software according to your metric.

Which, as I hope you now see, is analogous to what I am saying they are actually doing right now.

Welch wrote:
I think from what you and Chuckla quoted, it's pretty clear that Intel is stating Hardware or physical changes for future chips, not a firmware/micro code update only. I mean we can all guess at what Intel really means *wink wink, nod nod*, but I don't see any reason to doubt hardware changes.

It isn't an "update" because unlike the current ones, what they did is likely deeper than what the end-user update facility allows. However, it remains microcode.

I say, again, the P5 was microcoded. So was the P6. The difference was that you could update (some or all) of that microcode for the P6. But, as I say YET AGAIN, it is still microcode either way.

Ever since the ubiquity of microcode (like the minicomputers of the 70s) it's been the same story: "hardware" in CPU design is a totally separate discipline from the "microprogrammers". They work in conjunction, sure, but the "hardware" portion is frozen long before the micro part, something which is likely only worse today when the hardware is masks as opposed to bunch of discrete components on one card of dozens. Even up until launch (or after, via field engineers), you could make adjustments to microcode with those machines. Fiddling around with the high-performance FPU card? Yeah, not so much.

I further add to the argument that Intel is using EXTREMELY CAGEY but yet UTTERLY AMBIGUOUS language to characterize the benefit of this "hardware" change: "obstacle" "additional" "protective walls". That is very suspicious, and it is reminiscent of other misleading statements they've made about this subject in the past that were very carefully crafted to not say anything specifically incorrect but yet indirectly lead people into misunderstanding the situation towards Intel's benefit.

freebird · Thu Mar 22, 2018 9:55 am

Intel muddy the "hardware fix" waters with this information...

https://software.intel.com/sites/defaul ... ations.pdf

Which isn't really a fix, per se, but a flag to tell the processor not to speculatively execute branch predictions (in simpler terms)

Linus Torvalds argues this is crazy because no one will use it, because of the performance degradation...
https://www.theregister.co.uk/2018/01/2 ... fix_linux/

If this is the "hardware" fix, Intel can successfully claim they are making a hard fix in the processors without actually "fixing" the problem.
Legal semantics.

It will be interesting to see how these vulnerability "fixes" are implemented in AMD's Zen2 and Intel's processors next year. (ice lake or whatever lake is coming in late 2018/early 2019)

Personally, eight pages of Forum posts is getting a little overboard. We'll know next year whether the "fix is in" hardware ...and how many new security issues are found...in both ;D

Glorious · Thu Mar 22, 2018 10:41 am

freebird wrote:
Intel muddy the "hardware fix" waters with this information...

https://software.intel.com/sites/defaul ... ations.pdf

Which isn't really a fix, per se, but a flag to tell the processor not to speculatively execute branch predictions (in simpler terms)

Well, that's about the changes they made in the new microcode available for existing processors, and it was released ~2 months before Intel's announcement about the upcoming new processors.

So, that would be categorized as "software" by both chuckula, welch, and I.

freebird wrote:
If this is the "hardware" fix, Intel can successfully claim they are making a hard fix in the processors without actually "fixing" the problem.
Legal semantics.

Well, the initial microcode that provides the facilities listed in your cited document didn't do anything except provide mechanisms for ameloriating what is called variant 2 (1 & 2 are "spectre"), so Chuckula is right that variant 3 (meltdown) clearly isn't related to the previous microcode. It has to be something else.

My concern is that "something else" might just be "deeper" microcode, and that since Intel (despite producing a non-informative flashy video about this) hasn't bothered to say much of anything technical about just what this actually is, yes, I'm suspicious.

I mean, as Chuckula also says, no one is going to say "just turn off KPTI, you're fine now", so the degree to which the "hardware" "fix" for variant 3 (meltdown) is really even a "fix" at all is entirely academic, and since Intel is using such cagey language... I mean, yes, I'm suspicious 2x.

Welch · Thu Mar 22, 2018 9:24 pm

Glorious wrote:
Welch wrote:
Glorious, I'm curious why exactly you think it is more likely to be just a microcode patch.

Because, without slipping the schedule, how did they make serious changes to the actual silicon for a chip that was taped out roughly around when Intel was first notified of this problem (June 2017).

Remember, they goofed the initial microcode patch, but they're not even remotely gun-shy about producing new masks etc... without adjusting their launch dates in the slightest?

How is that possible?

Glorious wrote:
Fair question, if the chips are already tapped out, then yes, I'd consider it software because they clearly aren't doing any hardware changes. A hardware change could include something like how AMD/Intel disable cores on modern CPUs (not just disabling via microcode)

Again, no. It is not that simple.

The explanation for this is simple: If Intel disabled the microcode update facility but deployed the most recent microcode currently publicly available, viola, what was software under your dichotomy becomes hardware. And, I must add, the transition occurred via Intel's unilateral discretion.

That is, Intel just decided what is hardware versus software according to your metric.

Which, as I hope you now see, is analogous to what I am saying they are actually doing right now.

I'm not sure I can agree on that counting as making something hardware. If Intel is simply closing off future "Consumer" update ability via a final microcode update, I don't see how that is considered hardware. This is assuming they don't have a way to re-activate that ability or do an update in house after that code was applied. If you write code in a program that essentially renders the program unreachable or changeable, then I'd hardly call that hardware.

I can see your point though, if they already tapped out, I don't really see how they could make "Hardware" changes, at least not in the traditional sense.

Glorious · Fri Mar 23, 2018 7:42 am

Welch wrote:
I'm not sure I can agree on that counting as making something hardware. If Intel is simply closing off future "Consumer" update ability via a final microcode update, I don't see how that is considered hardware. This is assuming they don't have a way to re-activate that ability or do an update in house after that code was applied. If you write code in a program that essentially renders the program unreachable or changeable, then I'd hardly call that hardware.

Oh, I was simply using that as an extreme example to illustrate how flexible the notion of "hardware" versus "software" can become upon Intel's unilateral whim.

I do not believe that Intel is actually planning on doing anything remotely like that.

Welch · Sat Mar 24, 2018 1:04 am

Glorious wrote:
Welch wrote:
I'm not sure I can agree on that counting as making something hardware. If Intel is simply closing off future "Consumer" update ability via a final microcode update, I don't see how that is considered hardware. This is assuming they don't have a way to re-activate that ability or do an update in house after that code was applied. If you write code in a program that essentially renders the program unreachable or changeable, then I'd hardly call that hardware.

Oh, I was simply using that as an extreme example to illustrate how flexible the notion of "hardware" versus "software" can become upon Intel's unilateral whim.

I do not believe that Intel is actually planning on doing anything remotely like that.

Ahhh, I see. Who knows, I'm not ultra trusting of Intel either, but for some reason here my spidey senses aren't kicking in, maybe they should be. Time will tell.

LiamC · Wed Apr 04, 2018 12:00 am

Looks like Intel will not be patching Bloomfield, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, Wolfdale and Yorkfield

https://www.itnews.com.au/news/intel-wo ... ips-488176
https://newsroom.intel.com/wp-content/u ... idance.pdf

Wed Apr 04, 2018 2:17 am

Other than the normal practice of always keeping Windows 10 up to date, I've been paying more attention to BIOS updates since Meltdown and Spectre were announced. This latest news tells me that my Yorkfield C2Q Q9300 and GA-X48-DS4 are out of luck. :-?

That PC was retired from everyday use at the start of this year, but it is still used occasionally as a backup system.

Asus still hasn't released new BIOSes for the Gryphon Z87 with Haswell i7-4770K or the pair of P8Z77-M Pro boards in my Ivy Bridge i5-3570K and Sandy Bridge i7-2600K systems. Gigabyte just released a BIOS for the GA-Z170N-Gaming 5 and Skylake i7-6700K in March. Asus was extremely prompt with support for the RoG Strix Z370-G Gaming in my Coffee Lake i7-8700K system at the beginning of January. They also released another BIOS update in March.

Krogoth · Wed Apr 04, 2018 6:25 am

LiamC wrote:
Looks like Intel will not be patching Bloomfield, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, Wolfdale and Yorkfield

https://www.itnews.com.au/news/intel-wo ... ips-488176
https://newsroom.intel.com/wp-content/u ... idance.pdf

There's no economic incentive to do so. The majority of the systems could be attack by Meltdown/Spectre vector are going to be much newer than those platforms. Intel and certain vendors see Meltdown/Spectre as an opportunity to up sell new platforms to SMB/Enterprise customers.

The bad guys aren't going to bother using Spectre/Meltdown exploits to attack average joes. They were use the far more easier and effective vectors like social engineering and trojans.

the · Sun May 20, 2018 11:15 am

Well it looks like Spectre can break into SMM. This follows on the heels of another SMM attack in recent memory, coincidentally introduced in the first chips that Spectre could also be used.

Oh, and there is Spectre NG on the way too.

the · Mon May 21, 2018 6:46 pm

Spectre Variant 3a and 4 are now formally disclosed:

https://www.intel.com/content/www/us/en ... 00115.html

Unclear if this is the same Spectre NG that leaked earlier. I though that that disclosure was originally to be disclosed in May but was pushed by into June for patches to be ready. This could be something else but as with all breaking news, there is a bit of a fog on details.

TR Forums

Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: reality check

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Re: Intel Processor bug incoming?

Who is online