Vya DomusNot. A. Fix.

Intel disagrees. And really, you're just trolling at this point.

AusWolfThe term "fix" means making something that's broken work again.

Are we really going to play the semantics game?

AusWolfYou wouldn't fix a leaking toilet by permanently disconnecting it from your water supply, would you?

That is a contextually and deeply flawed analogy. I'm not going to entertain it.

Seriously, how is this difficult to understand? The Haswell series and the accompanying IGPs are RETIRED products. Intel is not going to re-engineer and re-deploy replacements. Disabling DX12 support is the solution Intel has chosen to fix the vulnerability.

Deal with it.

If that solution for those weak-sauce IGPs does not meet with your satisfaction, you have the following options;
A. Use an older driver that does not have DX12 disabled, as stated and directed by Intel.
B. Stop using the Haswell IGP and use a dedicated AMD or NVidia GPU.
C. Upgrade/Transition your computing platform to something not Haswell based.

Vya DomusEnd of story

This is the end of the story.

Vya Domusyou can argue all you want.

I'm not arguing, I'm explaining how this situation works and what the facts are. You are the one arguing. But there is a solution to that problem: You can stop arguing.

lexluthermiesterOh, how so?(I'm calling BS on this because it's total nonsense.)


Once again, Intel can NOT be expected to re-engineer a product that is EOL and many generations old. If disabling the software API which is being used as the attack vector is the only viable option, it IS a valid solution.

Just because that solution does not meet the satisfaction of a few people who fail to properly understand the problem does not make it any less a valid solution.

www.mouser.com/PCN/Intel_Corporation_PCN117291_01.pdf

I did not check if they ever EoL'd it again. They expected to by end of 2020. Regardless, Intel, did bring back Haswell during 12/10nm process node shortages. Yes, it does seem rediculous.

LabRat 891
www.mouser.com/PCN/Intel_Corporation_PCN117291_01.pdf

Did you actually read that PDF? See, what you failed to either disclose or understand, because you didn't read it, is that is for ONE CPU model in the series that had not been properly defined in the original discontinuation declaration.

LabRat 891I did not check if they ever EoL'd it again.

That comment directly implies you did not read or perhaps understand the context of the PDF document.

LabRat 891Regardless, Intel, did bring back Haswell during 12/10nm process node shortages. Yes, it does seem rediculous.

This revision is NOT a statement of intention to return the Haswell series CPU to production status, for any length of time. It is a clarification ONLY.

lexluthermiesterIntel disagrees.

I couldn't care less what Intel agrees or disagrees with, they don't get to decide if their solution was the correct one, the consumer does.

lexluthermiesterAnd really, you're just trolling at this point.

Let's all remember that this coming from a guy that unironically believes a product which is now missing functionality can be considered "fixed".

lexluthermiesterThat is a contextually and deeply flawed analogy. I'm not going to entertain it.

You're not going to do that because we all know you'd be incapable to back up your laughable stance on this matter of defending a corporation for making their product worse than it was before.

Stop the personal back and forth.
Stick to facts; and, do not toss your petty insults/jabs around.
Make you point and move on, don't drag it out, just to have the last word.

lexluthermiesterIntel disagrees. And really, you're just trolling at this point.


Are we really going to play the semantics game?

That is a contextually and deeply flawed analogy. I'm not going to entertain it.

Seriously, how is this difficult to understand? The Haswell series and the accompanying IGPs are RETIRED products. Intel is not going to re-engineer and re-deply replacements. Disabling DX12 support is the solution Intel has chosen to fix the vulnerability.

Deal with it.

If that solution for those weak-sauce IGPs does not meet with your satisfaction, you have the following options;
A. Use an older driver that does not have DX12 disabled.
B. Stop using the Haswell IGP and use a dedicated AMD or NVidia GPU.
C. Upgrade/Transition your computing platform to something not Haswell based.


This is the end of the story.

I'm not arguing, I'm explaining how this situation works and what the facts are. You are the one arguing. But there is a solution to that problem: You can stop arguing.

So you agree, in effect that just throwing said pc in the bin is just as effective a Fix then, great just great.

lexluthermiesterAre we really going to play the semantics game?

It wasn't me who called it a "fix". ;)

The closest definition of the word "fix" by the Merriam-Webster dictionary in the present context is 6.a. "repair, mend" or 6.b. "restore, cure".
To repair means: 1. to restore by replacing a part or putting together what is torn or broken, 2. to restore to a sound or healthy state, 3. to make good; compensate for.
To restore means: 1. to give back (someone or something that was lost or taken); to return (someone or something), 2. to put or bring (something) back into existence or use, 3. to return (something) to an earlier or original condition by repairing it, cleaning it, etc.

It doesn't matter how I twist it, "removing original functionality for whatever reason" is not among the definitions.

lexluthermiesterThat is a contextually and deeply flawed analogy. I'm not going to entertain it.

No, it's not. Disabling a functionality and fixing it (to make sure it works properly) are two totally different things.

lexluthermiesterSeriously, how is this difficult to understand? The Haswell series and the accompanying IGPs are RETIRED products. Intel is not going to re-engineer and re-deply replacements. Disabling DX12 support is the solution Intel has chosen to fix the vulnerability.

I'm not expecting them to recall every single Haswell CPU out there. I'm expecting them to either 1. find a solution to mitigate the vulnerability without disabling DX12 support (that's what fixing means), or 2. issue a warning to users, or 3. leave it alone. Disabling a feature of an already released product is shady practice, and calling it a fix is just a sign of pure laziness.

AusWolf1. find a solution to mitigate the vulnerability without disabling DX12 support (that's what fixing means),

And if that's not possible?

AusWolf2. issue a warning to users

And what do you think this public announcement is?

AusWolf3. leave it alone.

Legal liabilities. Not going to open that can of worms except to say they can't do that.

AusWolfDisabling a feature of an already released product is shady practice

Oh? How so?

AusWolfand calling it a fix is just as sign of pure laziness.

Were you a part of the team to analyze the vulnerability? Were you a part of the process to determine solution viability? If the answer is yes to either one of those questions, then please share with us all how it could have been done better. If the answer is no, then perhaps you and Vya need to let it go because as I pointed out...

lexluthermiesterA. Use an older driver that does not have DX12 disabled, as stated and directed by Intel.
B. Stop using the Haswell IGP and use a dedicated AMD or NVidia GPU.
C. Upgrade/Transition your computing platform to something not Haswell based.

...there are options.

AusWolfI'm not expecting them to recall every single Haswell CPU out there. I'm expecting them to either 1. find a solution to mitigate the vulnerability without disabling DX12 support (that's what fixing means), or 2. issue a warning to users, or 3. leave it alone. Disabling a feature of an already released product is shady practice, and calling it a fix is just a sign of pure laziness.

Or just leave it to up to the user if they actually want it disabled or not.

lexluthermiesterAnd if that's not possible?

Vya DomusOr just leave it to up to the user if they actually want it disabled or not.

That.

lexluthermiester

AusWolfDisabling a feature of an already released product is shady practice

Oh? How so?

When you're buying a product, you're paying for all of its functionality. Disabling some of it through updates is making it a lesser product.

lexluthermiesterIf that solution for those weak-sauce IGPs does not meet with your satisfaction, you have the following options;
A. Use an older driver that does not have DX12 disabled.
B. Stop using the Haswell IGP and use a dedicated AMD or NVidia GPU.
C. Upgrade/Transition your computing platform to something not Haswell based.

A. is an option, I give you that.
B. You mean forcing the user to spend money? (the Haswell iGPU's performance in DX12 is irrelevant)
C. Same again, forced upgrade.

lexluthermiesterWere you a part of the team to analyze the vulnerability? Were you a part of the process to determine solution viability? If the answer is yes to either one of those questions, then please share with us all how it could have been done better. If the answer is no, then perhaps you and Vya need to let it go because as I pointed out...

I was not talking about the solution. I was talking about calling it a fix for the problem.

AusWolfThat.

Let's review...

lexluthermiesterLegal liabilities. Not going to open that can of worms except to say they can't do that.

Yup.

AusWolfB. You mean forcing the user to spend money? (the Haswell iGPU's performance in DX12 is irrelevant)

You mean money they should otherwise already be spending because Haswell IGP performance in DX12 is and always has been pathetic? Yes.

AusWolfC. Same again, forced upgrade.

No, it's an option, one of several.

AusWolfI was not talking about the solution. I was talking about calling it a fix for the problem.

Semantics.

Why are you arguing this? It's over and done. Haswell is a retired product. There is no reinventing it, there is no hardware "fix" for a hardware based vulnerability like this one. If Intel has determined that the only solution is to render the problem moot by denying it an attack vector through disabling DX12, then that is the proper solution. Whether you like it or not is irrelevant, it's retired hardware and that is the end of the story.

lexluthermiesterYou mean money they should otherwise already be spending because Haswell IGP performance in DX12 is and always has been pathetic? Yes.

It's not up to you or anyone else to decide what Random Joe should spend his money on. If he's happy with Haswell's (pathetic) DX12 performance, it's his choice.

lexluthermiesterSemantics.

Why are you arguing this?

Why are you?

I have my opinion, you have yours. I'm a linguist (or at least I used to be one), so words and their meaning are important to me. Reinventing the word shit and calling it gold doesn't make it any less shit.

lexluthermiesterGood find! Didn't know that. Still, the point was that the loss of DX12 on Haswell isn't really a problem as anyone wanting to run DX12 enabled programs will be using a dedicated GPU and not the Haswell IGP as performance from that IGP is lack-luster at best. And the above comments about emulation are a perfect example, Xenia is not an emulator that would run well(if at all) on Haswell IGP. No one is going to do it, so the comment from Aretak was not based on merit or factual information.

I have run DX12 mainly for testing stuff on my laptop which is a broadwell based iGPU weaker than whats in high end haswell chips.

DX12 isnt exclusive to demanding AAA games.

I accept that the use case is likely small, but that doesnt make just disabling an API "ok" in my opinion. Its just a lazy approach, in fact I have noticed Intel have been incredibly lazy when it comes to software support in recent years. For me this would make me seriously question investing in any Intel GPU. As their actions reflect on them company wide.

As an example they decided to only release WPA3 drivers for their very newest wifi chipsets only.

Also if Haswell is a retired product, how is it still getting new iGPU drivers?

My view on this:

These gpus did not come with DX12 support, that was an added bonus later in their lifecycle. Thus, this was never an advertised function. Thus, you can't say they changed the advertised specs. They at most, gave additional icing on your igpu cake, only to remove it later and restore the old spec baseline.

That is not lawsuit material. It'd have no legal grounds. Is it an ideal solution? No. Is it really a "fix?" No. It's a workaround at best. But it's probably the best intel can do if it's really a on-silicon bug. In that sense, this is a storm in a teacup.

R-T-BMy view on this:

These gpus did not come with DX12 support, that was an added bonus later in their lifecycle. Thus, this was never an advertised function. Thus, you can't say they changed the advertised specs. They at most, gave additional icing on your igpu cake, only to remove it later and restore the old spec baseline.

That is not lawsuit material. It'd have no legal grounds. Is it an ideal solution? No. Is it really a "fix?" No. It's a workaround at best. But it's probably the best intel can do if it's really a on-silicon bug. In that sense, this is a storm in a teacup.

This. and also, Intel themselves never said that it's a fix, they said that it was a mitigation, so what are people fighting about ?

DeathtoGnomesIntel has dolphins?

R-T-BDolphin is an emulator

It's a Nintendo GameCube Emulator- Dolphin was Nintendo's code name for the NGC.

SteevoLet’s go Intel

I like how the new CPUs still have the same vulnerability that they didn’t bother to fix

www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html

I wonder how much of their IPC gain will magically disappear when it’s fixed

lexluthermiesterAs it seems this jab will be tolerated, allow me to take the opportunity to respond accordingly. Vya Domus, YOU have no place or room taking a shot at anyone's intelligence. Your failure to understand this very SIMPLE action by Intel to mitigate a security problem is yet another example(of many) where you fail to grasp basic context. Intel elected this solution as it is very likely to be the only way to resolve this security vulnerability. If you(or anyone else) fails that contextual understanding, it is not a failure of Intel, nor is it a reason to be throwing insults at me.

There is no point in repeating the same thing over and over, you're never going to convince me that simply disabling stuff and calling it a day can be considered a proper fix.

R-T-BMy view on this:

These gpus did not come with DX12 support, that was an added bonus later in their lifecycle. Thus, this was never an advertised function. Thus, you can't say they changed the advertised specs. They at most, gave additional icing on your igpu cake, only to remove it later and restore the old spec baseline.

That is not lawsuit material. It'd have no legal grounds. Is it an ideal solution? No. Is it really a "fix?" No. It's a workaround at best. But it's probably the best intel can do if it's really a on-silicon bug. In that sense, this is a storm in a teacup.

Perhaps a reasonable middle ground would have been to turn it off by default, and allow the user to enable it with a disclaimer about security risk.

This was the approach taken on spectre and meltdown.

Also no question it was patchable in drivers or microcode, the decision would have been made on the basis of how economical it was to dedicate resources to something with little benefit to the company.

lexluthermiesterSemantics. Mitigate, solve, remedy, fix.. They're all valid synonyms.

Semantics are important. These words might mean something similar to you, but that doesn't mean that they're the same in general. One should know what one is talking about. Mitigation of a problem: fine. Solution: hardly, but OK. Fix: definitely not. Since it has been mentioned that Intel themselves never called it a fix, I reluctantly suggest that the poor word choice only happened in the article.

lexluthermiesterWhat Vya, AusWolf, et al are complaining about is that they think Intel is now depriving them of functionality they feel is important. They feel Intel is somehow oppressing them with the actions taken. They seemingly fail to understand that the "fix" they believe Intel should make is either not possible due to hardware or DX12 software limitations(lets all remember that Intel is not the developer for DX12), or if it is possible the costs of redevelopment are not financially feasible for an Out-Of-Production line if products.

No. I'm arguing that Intel is depriving of others still using Haswell CPUs of some functionality that we may or may not consider important, but that's besides the point. There's no need to make things personal.

I'm also arguing that removing functionality to prevent security risks is not a fix. "Fix" means restoring something's original functionality, not removing it.

Products get discontinued only after a couple of years on the market, but that doesn't mean they're unusable. There could have been other options to solve this, for example:

chrcolukPerhaps a reasonable middle ground would have been to turn it off by default, and allow the user to enable it with a disclaimer about security risk.

AusWolfSemantics are important. These words might mean something similar to you, but that doesn't mean that they're the same in general. One should know what one is talking about. Mitigation of a problem: fine. Solution: hardly, but OK. Fix: definitely not. Since it has been mentioned that Intel themselves never called it a fix, I reluctantly suggest that the poor word choice only happened in the article.


No. I'm arguing that Intel is depriving of others still using Haswell CPUs of some functionality that we may or may not consider important, but that's besides the point. There's no need to make things personal.

I'm also arguing that removing functionality to prevent security risks is not a fix. "Fix" means restoring something's original functionality, not removing it.

Products get discontinued only after a couple of years on the market, but that doesn't mean they're unusable. There could have been other options to solve this, for example:

The DX12-enabled drivers are still available. From Intel (at least as of this post). No one has been deprived of anything. Need DX12 on Haswell IGPU? Run 15.40.42.5063. Worried about the exploit? Run 15.40.44.5107 or later.

You're right that there are probably other options. Intel may even fold an in-driver mitigation in a future release. Even if they do, that takes much more time than the action they did. If I'm Intel, the security flaw is a bigger deal to me than the edge case of DX12-exclusive applications on Haswell IGP. And even then, see above.

chrcolukPerhaps a reasonable middle ground would have been to turn it off by default, and allow the user to enable it with a disclaimer about security risk.

I mean, reverting driver to get DX12 basically accomplishes that. It's not like Haswell IGP is seeing major optimizations.

chrcolukAlso no question it was patchable in drivers or microcode

I at least know enough to know none of us have any idea on that.