HD64GEveryone should deactivate that feature. Less than 1% effect on performance isn't something to discuss about.

Why? There's not even a real exploit yet.

R-T-BMakes me wonder why it's enabled at all...

How do I disable it? I don't see how to do it.

HD64GEveryone should deactivate that feature. Less than 1% effect on performance isn't something to discuss about.

Where's the button?
Ah yes only in Linux , and with patches.
Another funny thing, I couldn't find this Vulnerability on CVE list :rolleyes:

efikkanThen that's a product of bias, a bias which unfortunately has become widespread. I've not seen any evidence of Intel taking "security shortcuts".

A shortcut would imply a conscious decision, while the Spectre family is caused by an oversight, an oversight done by numerous companies implementing their own microarchitectures.

Not bias, I'm just presuming that AMD pass a minium low bar for common sense and business survival, the same low bar I'd apply to Intel, Nvidia, Microsoft, Apple, or Google.

If you understand Spec-ex attacks then you know it affects Intel because they skipped privilege checks on stuff that had passed checks earlier in the pipeline as implied trust, in order to speed up the pipeline. Call it a shortcut, call it an optimisation - it doesn't matter. AMD checks privileges at every stage rather than assuming implied trust. That's a gross oversimplification but the TL;DR is that Intel chose speed over security, and AMD chose security over speed.

AMD's decision to choose security over speed has been vindicated publicly and presumably ratified internally at AMD, possibly making them even more security-cautious than they were previously. That basic decision of security over speed saved their bacon and they got to see what might have happened if they'd made the same shortcut/optimisations as Intel. Call it a free lesson at Intel's expense. That's not bias, that's just how any competent company should be run.

So no, presuming AMD won't take shortcuts isn't pro-AMD bias. It's based on historic empirical data.
I am now assuming that everyone takes spec-ex and pipeline privilege checks more seriously, not just Intel.

lasYes, because people actually cared about finding them. So they can collect money. Logic, yeah.

You fail to understand what an assumption is I see. You made the assumption that Intel has more known vulnerabilities and assumed that AMD has equal or more undisclosed ones based on the assumption that Intel's bug payment program encourages people to find more bugs. This is funny for two reasons:

1) Google Project Zero found Spectre and Meltdown, not someone encouraged by the bug program. They are employed by google to find zero day vulnerabilities regardless of the existence of a bug payout program. Therefore your initial assumption that your stacked house of assumptions is based on is in fact false. Again, you assumed but it's irrelevant as your unproven argument basis has already been disproven despite no requirement for me to do so as you failed to provide evidence to support it to begin with.

2) You provided no evidence to support the idea that AMD has an equal or greater amount of vulnerabilities as Intel, assumptions are not supporting evidence. You first make the assumption that Intel's bug bounty program is the reason they have so many vulnerabilities (disproven above) and again assume on top of that false logic that AMD has at least that many unknown vulnerabilities. AMD has 16, Intel has over 240. Think about that. You are in essence assuming AMD has 15 times the unkown vulnerabilities as known and assuming, without evidence, that they in fact exist. That's not something a bug bounty program alone is going to make up.

R-T-BBut they know this one individual feature constitutes a security risk. So I repeat the question.

No they don't.

Short version: to find a bug is a non-computable problem.

Long version: All security/correctness properties can only be proven under an assumption, and only works under that assumption, e.g., eventual correctness of execution result, etc. "Side channel attacks" just means they found some new ways of invalidating your assumptions and can thus only be handled on a case-by-case basis. Being in the same category does not mean they are the same bug. If you are not an omnipotent god, then you simply don't know it in advance.

Yes, you can have a vague sense of vulnerability based on your human instinct. But it takes engineering genuity to prove the vulnerability. (invulnerability, as I previous said, is not provable by any means).

---

[/HR]

A good example is the cache microtag generator for zen/zen+. For an outsider, that microtag generator design would freak them out because it may appears too insecure for an untrained engineer. But after all these years, no one actually found an attack vector for it. Proving invulnerability is impossible, but proving vulnerability is also hard.

Intel didn't take any shortcuts?

Spectre is a side-effect of out-of-order execution engines that might allow you to take a glimpse of code running on a computer, as long as you have sufficient privileges, only in-order CPUs are safe from it.

Meltdown was intel (and others) not doing any security checks which allowed kernel access.
Easily exploitable since you know what to look for(kernel), could be done blindly and massively through websites because everyone had the same kernel(windows)
The only things stopping it were kernel memory randomization and flushing caches for every kernel call which tanks performance.

Imagine the period before patches....and the researchers having the power to snoop around every pc on the internet that had "intel inside", without leaving any traces.

Yeah, zero shortcuts...and then there's Intel Management Engine, a webserver inside your cpu.

lasThis is the reason why most vulberabilies were found in Intel CPUs; www.intel.com/content/www/us/en/security-center/bug-bounty-program.html

Intel actually pays people for finding them. "Intel’s bug bounty awards range from $500 up to $100,000."

AMD had plenty of vulnerabilies, even tho they don't pay people for finding them. Meaning, very few people will spend time trying to find them. Logic 101.

It's sad that AMD does not pay people for finding bugs, when tons of big tech companies do; www.guru99.com/bug-bounty-programs.html

So you are simply LYING? AMD had plenty of vulnerabilities? Try to read up all the news about back to those days when they were found: most of them were Intel-related and affected more generations of Intel CPUs. Shame on you.

If you cannot have a discussion without trolling and baiting, I suggest you refrain from posting. Thread bans issued

Honestly looks like nothing to panic about, as a Ryzen user. I'm going on with business-as-usual.

*Swivels head to look at Band-Aid covered Intel rigs*

Wake me when its serious.

B-RealSo you are simply LYING? AMD had plenty of vulnerabilities? Try to read up all the news about back to those days when they were found: most of them were Intel-related and affected more generations of Intel CPUs. Shame on you.

Lying? Haha. AMD had many vulnerabilies, feel free to Google, YET no bug bounty program to make people even wanna go look for them.

If Intel did not have their bug bounty program, you can be sure that many of the vulnerabilies were never found to begin with. STILL Intel continue to have it.

lasIf Intel did not have their bug bounty program, you can be sure that many of the vulnerabilies were never found to begin with. STILL Intel continue to have it.

The bug bounty program certainly contributes, but the main reason is Intel's close collaboration with researchers and data-center customers. Ice Lake-SP which launched the other day, has been deployed as engineering samples with partners at least since 2017, and has over the past year shipped over 100.000 units of the final product prior to the "public launch", so when it finally launched it was a very mature product. Their next-gen Sapphire Rapids (presumably launching sometime next year or so), has had engineering samples for over a year already. A lot of errors are found and resolved long before the general public gets their hands on the products, and helps avoid problems like waiting for months for stable BIOSes, or failing to boot Linux, or compile correctly with GCC etc. Bugs like Meltdown and Spectre which were found long after product launches are rare exceptions.

AMD would be well served by allowing their partners access to engineering samples much earlier, and probably extending their development cycle by at least 6-12 months.