• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Dubious Research Discovers Ryzen vulnerabilites

Man of Honour
Joined
13 Oct 2006
Posts
91,300
Given that only you understand it like that, given what the entire industry understands disagrees with you entirely are you so arrogant as to presume only you can possibly be right?

You keep saying "but other people don't understand" well lets try a different angle, make your case, don't just post a wall of text gibberish and assume people are too lazy to read it or just assume the gibberish is incomprehensible to them and in both cases just take your word for it, no, you stand alone among recognized professionals contradicting them, don't just do that and run, elaborate your arguments.

You need to separate between your understanding - which is so clouded by pro-AMD you even accused AMD basically of just owning up to and making a statement claiming responsibilities of issues that you claim weren't real despite the huge legal ramifications of doing that - and what these experts are actually saying - plus a lot of what you are repeating is what media people are repeating based on their understanding of technical articles - not the actual words of the technical document.

We need a wealthy 3rd party to fund a research group to find out if ASMedia chip flaws can be exploited on Intel platforms. Only give them 24 seconds notice though, because users need to be protected.

Yes indeed. If there is anything to it you can bet someone will be on it really quick though. Given these controllers have been in older Intel and AMD systems going back years and the difference in how they are used between implementations I'll be surprised if its possible to do much dangerous with them even when you are in the controller. In a lot of cases they interface with the CPU and hardware abstraction layer quite differently to how they are implemented with Promontory.
 
Soldato
Joined
9 Nov 2009
Posts
24,859
Location
Planet Earth
OP,can you update the first post please,with more up to date information,ie,the AT interview,AMD response,etc - this thread keeps getting bumped up and people might only read the first post and get the wrong impression!!
 
Caporegime
Joined
17 Mar 2012
Posts
47,752
Location
ARC-L1, Stanton System
You need to separate between your understanding - which is so clouded by pro-AMD you even accused AMD basically of just owning up to and making a statement claiming responsibilities of issues that you claim weren't real despite the huge legal ramifications of doing that - and what these experts are actually saying - plus a lot of what you are repeating is what media people are repeating based on their understanding of technical articles - not the actual words of the technical document.



Yes indeed. If there is anything to it you can bet someone will be on it really quick though. Given these controllers have been in older Intel and AMD systems going back years and the difference in how they are used between implementations I'll be surprised if its possible to do much dangerous with them even when you are in the controller. In a lot of cases they interface with the CPU and hardware abstraction layer quite differently to how they are implemented with Promontory.

Ah right, so now anyone who disagrees with you is "pro AMD" AMD may not be owning up to anything untrue but they do need to be much more careful in what they do say because people with insane agendas tend to hang on every word they say and twist it if they can, just like you just did.

Yes indeed. If there is anything to it you can bet someone will be on it really quick though. Given these controllers have been in older Intel and AMD systems going back years and the difference in how they are used between implementations I'll be surprised if its possible to do much dangerous with them even when you are in the controller. In a lot of cases they interface with the CPU and hardware abstraction layer quite differently to how they are implemented with Promontory.

Here is an example of you making blanket statements without you backing any of it up with details and proof, anyone can say anything they like, throw in a couple of technical terms and to make it look convincing, but if you cannot actually backup anything you are saying up then what you are saying is utter nonsense.

Back up what you are saying.

plus a lot of what you are repeating is what media people are repeating based on their understanding of technical articles - not the actual words of the technical document.

No. these are CTS-Labs actual words.

but also works on any machine that has these ASMedia Chip-Sets and so quite a few Motherboards and PC's are affected by these vulnerabilities as well

CTS-Labs would not be saying

works on any machine that has these ASMedia Chip-Sets

Unless it
works on any machine that has these ASMedia Chip-Sets

Intel use the same ASMedia Chip-Sets
 
Associate
Joined
10 Jan 2014
Posts
1,360
It's funny that those guys are doing it for money and yet they have not used Rroff's theories, while he is doing it for free...what a commitment to the cause.
 
Man of Honour
Joined
13 Oct 2006
Posts
91,300
You are misunderstanding what works on any board (although I'd question that working on any board) which uses an ASMedia controller.

Also the ASM controllers can accept data from BIOS, SPI ROM or ship with the firmware locked entirely (in which case you'd have to remove it from the board and mount in a chip programmer to flash it) - for instance on X79 boards that use the ASM1x42 controllers externally you need to reboot into pure DOS mode to update the firmware on them.

Even if the backdoor client that CTS Labs is talking about is able to execute read/write on the controller in operation so as to manipulate it (which is what they are talking about) that doesn't mean you can then use the controller necessarily to do anything harmful depending on what features are enabled and how it interfaces with the rest of the system or facilitate persistently taking over the controller.
 
Caporegime
Joined
17 Mar 2012
Posts
47,752
Location
ARC-L1, Stanton System
You are misunderstanding what works on any board (although I'd question that working on any board) which uses an ASMedia controller.

Also the ASM controllers can accept data from BIOS, SPI ROM or ship with the firmware locked entirely (in which case you'd have to remove it from the board and mount in a chip programmer to flash it) - for instance on X79 boards that use the ASM1x42 controllers externally you need to reboot into pure DOS mode to update the firmware on them.

Even if the backdoor client that CTS Labs is talking about is able to execute read/write on the controller in operation that doesn't mean you can then use the controller necessarily to do anything harmful depending on what features are enabled and how it interfaces with the rest of the system or enable persistently taking over the controller.

So we are supposed to take CTS-Labs wording as given fact when it suites you but they are wrong when it doesn't? They are competent but also incompetent at the same time for the same thing, just so long as its comment on AMD but the same thing for anything else, that's incompetence.

It's funny that those guys are doing it for money and yet they have not used Rroff's theories, while he is doing it for free...what a commitment to the cause.

Roff is smarter and more knowledgeable than they, the industry, anyone, its amazing Roff didn't go to AMD for a nice payout to help them fix it.

You're still not backing anything you say with facts, you're just justifying blanket statements with more blanket statements. and still completely ignoring what those responsible for this have actually said.

works on any machine that has these ASMedia Chip-Sets

That's a statement of fact Roff, if its wrong prove it.
 
Man of Honour
Joined
13 Oct 2006
Posts
91,300
So we are supposed to take CTS-Labs wording as given fact when it suites you but they are wrong when it doesn't? They are competent but also incompetent at the same time for the same thing, just so long as its comment on AMD but the same thing for anything else, that's incompetence.

You are not understanding what they are saying with that statement. They are saying their backdoor client works with 6 other boards they have for testing - they aren't say they were able to do anything malicious once the client had backdoored the controller. Just that they've been able to backdoor the controller on systems other than the original Ryzen target.
 
Caporegime
Joined
17 Mar 2012
Posts
47,752
Location
ARC-L1, Stanton System
You are not understanding what they are saying with that statement. They are saying their backdoor client works with 6 other boards they have for testing - they aren't say they were able to do anything malicious once the client had backdoored the controller. Just that they've been able to backdoor the controller on systems other than the original Ryzen target.

Not in what i quoted they haven't, link me to that quote.
 
Man of Honour
Joined
13 Oct 2006
Posts
91,300
Roff is smarter and more knowledgeable than they, the industry, anyone, its amazing Roff didn't go to AMD for a nice payout to help them fix it.

You're still not backing anything you say with facts, you're just justifying blanket statements with more blanket statements. and still completely ignoring what those responsible for this have actually said.

*snigger* I'm wasting my time here you are clearly incapable of thinking for yourself and just parotting what is being said on certain forums and resorting to clown posts like this - even if I spent the time to get upto speed to do a full technical breakdown you wouldn't accept it anyhow and just change tactic or come out with something as ludicrous as claiming AMD would just hold their hands up to security issues of this nature that weren't actually real.

Back on ignore and I'm moving on - I guess this thread will descend into another pro-AMD echo chamber.
 
Caporegime
Joined
17 Mar 2012
Posts
47,752
Location
ARC-L1, Stanton System
Not in what i quoted they haven't, link me to that quote.
*snigger* I'm wasting my time here you are clearly incapable of thinking for yourself and just parotting what is being said on certain forums and resorting to clown posts like this - even if I spent the time to get upto speed to do a full technical breakdown you wouldn't accept it anyhow and just change tactic or come out with something as ludicrous as claiming AMD would just hold their hands up to security issues of this nature that weren't actually real.

Back on ignore and I'm moving on - I guess this thread will descend into another pro-AMD echo chamber.

So no link then? bye.
 
Last edited:
Associate
Joined
27 Apr 2007
Posts
963
That's a statement of fact Roff, if its wrong prove it.
The burden of proof is equal for both sides. So do you have a link to hard evidence showing that Intel systems using these controllers have the same issue as impacts AMD?
God knows they have had enough other major issues so wondering if this is one more for their portfolio! :)
I've seen no hard evidence yet whether this flaw impacts or doesn't impact the small minority of Intel boards that use the same controller as an add-in.
The threat is a 2nd tier one (already requires admin access) so it doesn't appear to be a major issue for now but in the back of my mind after the year we've had I'm getting more concerned about these things as to how they may unfold.
Even though as a percentage Intel have dramatically fewer systems using these controllers, due to their much larger market share it still adds up to a large enough number I imagine.
 
Caporegime
Joined
17 Mar 2012
Posts
47,752
Location
ARC-L1, Stanton System
The burden of proof is equal for both sides. So do you have a link to hard evidence showing that Intel systems using these controllers have the same issue as impacts AMD?
God knows they have had enough other major issues so wondering if this is one more for their portfolio! :)
I've seen no hard evidence yet whether this flaw impacts or doesn't impact the small minority of Intel boards that use the same controller as an add-in.
The threat is a 2nd tier one (already requires admin access) so it doesn't appear to be a major issue for now but in the back of my mind after the year we've had I'm getting more concerned about these things as to how they may unfold.
Even though as a percentage Intel have dramatically fewer systems using these controllers, due to their much larger market share it still adds up to a large enough number I imagine.

You obviously don't know its CTS-Labs them selves saying this, not me, the burden of proof is with Roff.
 
Soldato
Joined
16 Nov 2013
Posts
2,723
End of the day AMD came up with fixs and its sorted so we can presume there was some issue (Which tbh was not really a major thing and if they had given AMD 90 days notice it would have been sorted quietly like most things) .
I dont recall CTS labs having hard linked proof of it affecting intel for this vs them just saying some other platforms can have a similar issue .
Not saying intel isnt affected just agreeing with smiling if one side needs hard linked info and testing then so does the other.
 
Soldato
Joined
11 Jun 2003
Posts
5,082
Location
Sheffield, UK
Eh, anyway. Let's hope this octa-core Intel chip isn't so pants-down pathetic with it's security aye? :D ;)
If it at least needs admin for someone to screw with it, they'll have at least caught up with AMD on security.
 
Soldato
Joined
18 Oct 2012
Posts
4,146
Location
Oxfordshire
YOU are saying that this problem is the same for Intel so where is YOUR proof? I'm not talking about anybody else.
I have seen no proof either way and have ZERO interest in opinions.

No CTS Labs are saying the problem is the same for any chipset that uses the one in questions be it Intel, AMD, Apple, Samsung or whomever. Intel just happens to be the only other option as the other person that it can relate too as there are only two parties utilising this chipset. So the statement of fact is from CTS Labs where we also took statements of facts about all the other research but want to throw away something because it doesn't fit the narrative being discussed.

It is counter intuitive to suggest you take CTS on their word for one element but not the other. That from what I can see was Humbugs point and that would correlate with common sense on the situation of what we are able to read.

Now in terms of CTS, they have not delved deeper with Intel although their statement suggests it would be a problem. However they are focusing on AMD. That then brings into question motive and other since they say on one side they know issues can be on all chipsets but don't back it up and instead seem to be purposefully causing issues.

The issue there is Rroff posts back as matter of fact statements that everyone is wrong without so much as even a statement from a "'professional company' (CTS-Labs are not professional in any way and all they have actually done more harm to security for users by the way they released the info). Instead Rroff has made an opinion and now utilising that as an argument to something he cannot prove and there is no evidence to support and telling everyone else they don't get it and are wrong. That is not a good basis to start a point of view and creating a debate because debating personal opinions is impossible by nature.

We don't know that Intel do have issues, we also don't know they don't. However if we believe the info CTS labs has produced and then take their statement of fact that the issue is on any machine with said chip. What then doubles down people even listening to Rroff is that anyone who happens to have the opinion that the issue is likely to be both Intel and AMD are now AMD fanboys and they are just pro-AMD and that is it does not help justify his point and just makes him sound childish without the ability to debate with common sense and neutrality.

It is for that reason I hadn't said much and not replied to Rroff for most part because there is nothing to actually debate and discuss like adults because nothing he has stated so far can be shown to any degree with facts and evidence. Making the whole thing a non starter.
 
Associate
Joined
27 Apr 2007
Posts
963
No CTS Labs are saying the problem is the same for any chipset that uses the one in questions be it Intel, AMD, Apple, Samsung or whomever. Intel just happens to be the only other option as the other person that it can relate too as there are only two parties utilising this chipset. So the statement of fact is from CTS Labs where we also took statements of facts about all the other research but want to throw away something because it doesn't fit the narrative being discussed.

It is counter intuitive to suggest you take CTS on their word for one element but not the other. That from what I can see was Humbugs point and that would correlate with common sense on the situation of what we are able to read.

Now in terms of CTS, they have not delved deeper with Intel although their statement suggests it would be a problem. However they are focusing on AMD. That then brings into question motive and other since they say on one side they know issues can be on all chipsets but don't back it up and instead seem to be purposefully causing issues.

The issue there is Rroff posts back as matter of fact statements that everyone is wrong without so much as even a statement from a "'professional company' (CTS-Labs are not professional in any way and all they have actually done more harm to security for users by the way they released the info). Instead Rroff has made an opinion and now utilising that as an argument to something he cannot prove and there is no evidence to support and telling everyone else they don't get it and are wrong. That is not a good basis to start a point of view and creating a debate because debating personal opinions is impossible by nature.

We don't know that Intel do have issues, we also don't know they don't. However if we believe the info CTS labs has produced and then take their statement of fact that the issue is on any machine with said chip. What then doubles down people even listening to Rroff is that anyone who happens to have the opinion that the issue is likely to be both Intel and AMD are now AMD fanboys and they are just pro-AMD and that is it does not help justify his point and just makes him sound childish without the ability to debate with common sense and neutrality.

It is for that reason I hadn't said much and not replied to Rroff for most part because there is nothing to actually debate and discuss like adults because nothing he has stated so far can be shown to any degree with facts and evidence. Making the whole thing a non starter.
Thanks. I don't take CTS Labs seriously so not concerned what they say.
AMD have acknowledged their issues but have Intel acknowledged that they have the same issue or have a reputable 3rd party SHOWN that Intel have the same issue?
Based on what has been said on this thread it all seems to be speculation on the Intel side.
 
Soldato
Joined
18 Oct 2012
Posts
4,146
Location
Oxfordshire
Thanks. I don't take CTS Labs seriously so not concerned what they say.
AMD have acknowledged their issues but have Intel acknowledged that they have the same issue or have a reputable 3rd party SHOWN that Intel have the same issue?
Based on what has been said on this thread it all seems to be speculation on the Intel side.

Nope the problem we have is many suspect that Intel have paid for said 3rd party accordingly or certainly are involved in some way due to the nature of how the information was represented. Of course that is speculation. So far due to the time frame of all this no one has as far as we are aware publicly tested it with Intel and proved either way.

The problem being is that any reputable 3rd party will abide by the 90 day industry standard from testing, confirming and information being released accordingly. I would suggest that more reputable companies are/have likely tested this and since we haven't heard anything then there is more likely to be issues as a statement of no problem would not require the 90 day industry standard. So in someways not saying anything and being silent is just as telling.

The evidence given by silence is that Intel are patching quietly because there is nothing on the net about it. The lack of time frame for AMD to respond and to actually put users at more risk by highlighting the issues with the 3rd party chip is the larger issue I think out the two overall. It does not help companies keep users safe because they cannot respond in such a short period. 90 days is in effect because the amount of testing and the roll out release of updates that is needed to be coordinated.

I have no problem if testing is done and Intel fine and it is just the way AMD and the 3rd party talk to each other as such. But this never should have come out and been a public issue to start with which is why people are looking at it from one side more. If someone done the same to Intel I would expect the same response from Intel and people posting as they have here (bar Rroff who seems to have a personal agenda to this :/).
 
Soldato
Joined
9 Nov 2009
Posts
24,859
Location
Planet Earth
The last bit of the AT interview where David Kanter asked some very telling questions.

DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?

ILO: I definitely am not going to comment on our customers.

DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.

ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.

So,they confirm that someone was basically involved in this. If not they would have said we ourselves started the work. They didn't.

Its why AMD said they wanted this investigated.

BTW,in case no one knows who David Kanter is:

https://www.realworldtech.com/
https://www.linkedin.com/in/kanterd

This is why Ian Cutress got him onboard.
 
Back
Top Bottom