Any chance for BIOS update to allow disabling fTPM?

[Hamstray]

System: Windows 10 64-bit
Battery or AC: AC
Model: Zephyrus G15 GA503QS
Frequency of occurrence: Random
Reset OS: Too Many Times
Screenshot or video:
========================
Detailed description：Hello, since AMD have officially acknowledged the fTPM stutter issues that have been plaguing me since getting my laptop, would it be possible for ASUS to release a new version of my laptop's BIOS that allows me to disable fTPM until and if an actual fix arrives? I know AMD claims to have something in the works but it still requires waiting at least until May, and even then it might not even work in the end. In any case I'd like to be able to disable fTPM, I don't think it's right to force it on me.
Unfortunately the support in my country is a complete travesty (they still ignore the fTPM issue even though it's been in news media and AMD themselves said the issue exists, in fact before the issue got official recognition they went as far as trying to convince me that 1. my laptop doesn't have any TPM and 2. that AMD chipsets don't support TPM in general) so I can't get any assistance from them.

[Hamstray]

Also "simply return the device"? If it was that simple I wouldn't be here, that's for certain. ASUS do their useless tests and find nothing wrong with the laptop, and because that's their official findings they refuse to allow a return.

[Danishblunt]

@Hamstray
"even a tiny bit" being literally at the end of the site where on mobile it didnt load the PDF like it would on desktop. smh.
I did assume it was bs because complaining about fTPM being unsecure is just exceedingly dumb. So i went ahead and read the paper and this is going to be a big L for the consumers. All the complaints about security are very easy to debunk or are just theoretical bs. So let me break it down for those who are interested:
When they talk about fTPM, they first write huge amount of texts (decently written i might add) and explain about how security is important and what measures have been taken. Then they explain how AMD is implementing it, however here they start to get really theoretical and nonfactual. There are also some dumb things in there like "Low level hardware" which, is not a thing but i digress.
First problematic point they are making is:
This creates a significant problem. If the PSP is compromised by an attacker, the entire
AMD-based system can be trivially compromised as well—including direct access to system memory
and hardware.
This is already a non starter to begin with. It's like me saying, don't lock your door because if someone takes a truck and drives through it the lock won't help. Well no shit it doesn't help.
Then they proceed to mess up again by writing this:
The PSP has been the source of many vulnerabilities in AMD computer systems,
particularly in computers running AMD Ryzen CPUs.
133. For example, in late 2017, a Google security researcher discovered a stack overflow
vulnerability in the PSP—specifically, within its firmware TPM implementation—that would allow an
attacker to take full control of the PSP (which would then, by the PSP’s design, allow escalation to
compromise of the AMD CPU and system itself). Google’s security researcher noted: “As far as we
know, general exploit mitigation technologies (stack cookies, NX stack, ASLR) are not implemented in
the PSP environment.”
First of all, the PSP itself was never the problem, it was always the drivers that could cause very theoretical issues where AMD was very quick to act on it also it required direct access to your PC to begin with.
The second problem here is they took the possibly worst example they could have taken.
Full Disclosure: AMD-PSP: fTPM Remote Code Execution via crafted EK certificateWithout access to a real AMD hardware, we used an ARM emulator [7] to
emulate a call to EkCheckCurrentCert with the CERT_DATA listed above. We
verified that full control on the program counter is possible:

EkCheckCurrentCert+c8 : B loc_10EE4
EkCheckCurrentCert+60 : LDR R4, =0xB80
EkCheckCurrentCert+62 : ADDS R4, #0x14
EkCheckCurrentCert+64 : ADD SP, R4
EkCheckCurrentCert+66 : POP {R4-R7,PC}
41414140 : ????
|
R0=ff,R1=f00242c,R2=f001c24,R3=824,R4=41414141,R5=41414141,R6=41414141,R7=41414141,PC=41414140,SP=f003000,LR=11125

As far as we know, general exploit mitigation technologies (stack cookies,
NX stack, ASLR) are not implemented in the PSP environment.
Already here the researcher admitted that he wasnt able to access the PSP and just assumed that the PSP would be the same as a generic ARM Core which he emulated. Later AMD clearified that this "vulnurability" was never really a thing since there was no access to the PSP to begin with.
Then they take another 2 examples where it was as usual the PSP driver having some vulnurabilities, while claiming its the actual PSP having them, which is false. The PSP was never compromised.
After there the entire thing just went basicially on a rampant blatant lying spree about how AMD shoehorned fTPM only to fulfill Windows 11 requirements without a shred of evidence. fTPM exists at the very least since 2018 when Windows 11 was nowhere near being released which already debunks their entire point.

Overall, the case had a chance with the entire stuttering issue, which is valid, but arguing security will cost them the case. If they go to court, HP will have an easy time focusing on the security fallacies and win the case easy mode.

[Danishblunt]

Hamstray

Also "simply return the device"? If it was that simple I wouldn't be here, that's for certain. ASUS do their useless tests and find nothing wrong with the laptop, and because that's their official findings they refuse to allow a return.

View post

Record evidence of unusable media consumption and demand refund. Its literally not working as advertised. If they refuse, sue them.

[Hamstray]

Danishblunt

@Hamstray

"even a tiny bit" being literally at the end of the site where on mobile it didnt load the PDF like it would on desktop. smh.

I did assume it was bs because complaining about fTPM being unsecure is just exceedingly dumb. So i went ahead and read the paper and this is going to be a big L for the consumers. All the complaints about security are very easy to debunk or are just theoretical bs. So let me break it down for those who are interested:

When they talk about fTPM, they first write huge amount of texts (decently written i might add) and explain about how security is important and what measures have been taken. Then they explain how AMD is implementing it, however here they start to get really theoretical and nonfactual. There are also some dumb things in there like "Low level hardware" which, is not a thing but i digress.

First problematic point they are making is:

This creates a significant problem. If the PSP is compromised by an attacker, the entire

AMD-based system can be trivially compromised as well—including direct access to system memory

and hardware.

This is already a non starter to begin with. It's like me saying, don't lock your door because if someone takes a truck and drives through it the lock won't help. Well no shit it doesn't help.

Then they proceed to mess up again by writing this:

The PSP has been the source of many vulnerabilities in AMD computer systems,

particularly in computers running AMD Ryzen CPUs.

133. For example, in late 2017, a Google security researcher discovered a stack overflow

vulnerability in the PSP—specifically, within its firmware TPM implementation—that would allow an

attacker to take full control of the PSP (which would then, by the PSP’s design, allow escalation to

compromise of the AMD CPU and system itself). Google’s security researcher noted: “As far as we

know, general exploit mitigation technologies (stack cookies, NX stack, ASLR) are not implemented in

the PSP environment.”

First of all, the PSP itself was never the problem, it was always the drivers that could cause very theoretical issues where AMD was very quick to act on it also it required direct access to your PC to begin with.

The second problem here is they took the possibly worst example they could have taken.

https://seclists.org/fulldisclosure/2018/Jan/12

Without access to a real AMD hardware, we used an ARM emulator [7] to

emulate a call to EkCheckCurrentCert with the CERT_DATA listed above. We

verified that full control on the program counter is possible:

EkCheckCurrentCert+c8 : B loc_10EE4

EkCheckCurrentCert+60 : LDR R4, =0xB80

EkCheckCurrentCert+62 : ADDS R4, #0x14

EkCheckCurrentCert+64 : ADD SP, R4

EkCheckCurrentCert+66 : POP {R4-R7,PC}

41414140 : ????

|

R0=ff,R1=f00242c,R2=f001c24,R3=824,R4=41414141,R5=41414141,R6=41414141,R7=41414141,PC=41414140,SP=f003000,LR=11125

As far as we know, general exploit mitigation technologies (stack cookies,

NX stack, ASLR) are not implemented in the PSP environment.

Already here the researcher admitted that he wasnt able to access the PSP and just assumed that the PSP would be the same as a generic ARM Core which he emulated. Later AMD clearified that this "vulnurability" was never really a thing since there was no access to the PSP to begin with.

Then they take another 2 examples where it was as usual the PSP driver having some vulnurabilities, while claiming its the actual PSP having them, which is false. The PSP was never compromised.

After there the entire thing just went basicially on a rampant blatant lying spree about how AMD shoehorned fTPM only to fulfill Windows 11 requirements without a shred of evidence. fTPM exists at the very least since 2018 when Windows 11 was nowhere near being released which already debunks their entire point.

Overall, the case had a chance with the entire stuttering issue, which is valid, but arguing security will cost them the case. If they go to court, HP will have an easy time focusing on the security fallacies and win the case easy mode.

View post

if you hadn't actually read the complaint before posting the previous post, maybe you shouldn't have claimed anything about what's in it? as for the rest, it might be true for all I know, but AMD has lied to me before so I see no reason they couldn't lie about other things.
As for AMD developing the fTPM specifically to side-step W11's TPM requirements, that's for certain not true.

Danishblunt

https://zentalk.asus.com/en/discussion/comment/221874#Comment_221874

Record evidence of unusable media consumption and demand refund. Its literally not working as advertised. If they refuse, sue them.

View post

lol, 'it's so simple! just sue them' man your privilege is stuck up your behind so deep. I have in fact started legal proceedings but one thing it hasn't been is simple.

[Danishblunt]

Hamstray

https://zentalk.asus.com/en/discussion/comment/221885#Comment_221885

if you hadn't actually read the complaint before posting the previous post, maybe you shouldn't have claimed anything about what's in it? as for the rest, it might be true for all I know, but AMD has lied to me before so I see no reason they couldn't lie about other things.

As for AMD developing the fTPM specifically to side-step W11's TPM requirements, that's for certain not true.

https://zentalk.asus.com/en/discussion/comment/221886#Comment_221886

lol, 'it's so simple! just sue them' man your privilege is stuck up your behind so deep. I have in fact started legal proceedings but one thing it hasn't been is simple.

View post

I skimmed through it and assumed it was a bogus post since claiming that they should allow you to disable fTPM because of security is just silly. Then I saw the paper and saw they were serious (lol)
Nah, stuff like that is well documented by people who find vulnurabilities and AMD who patches their drivers. There is no ground for the guys who made that paper.
Never said simple, but thats what you're supposed to do. Also has nothing to do with priveleges, it's against the law to advertise something and sell something different, no clue where you live but when it's legal in your country then you're screwed no matter what you do.