[HN Gopher] AMD Ryzen 7000 Series performs better with Spectre V...
___________________________________________________________________
AMD Ryzen 7000 Series performs better with Spectre V2 Mitigations
enabled
Author : ad8e
Score : 242 points
Date : 2022-10-04 12:39 UTC (4 days ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| ZiiS wrote:
| This is basically just saying: the super clever AMD designers and
| Linux kernel developers have optimised for the setting they
| recomend and most people use. An insecure setting they recomend
| against isn't yet well optimised on brand new hardware.
| staticassertion wrote:
| Yes, the interesting question is _how_ they did this.
| staticassertion wrote:
| Interesting. I wonder if the kpti path leveraging PCID has
| 'tipped' into a performance improvement? Maybe a larger PCID
| cache on the CPUs and optimized codepaths for specter-usage?
| Havoc wrote:
| Interesting. When i first heard this I assumed it's bad
| benchmarking but photonics saying same suggest otherwise
| sylware wrote:
| this smells really bad... as it does not make a lot of sense, the
| devil hides in the details.
| [deleted]
| simlevesque wrote:
| It seems logical that if Zen 4 is immune to Spectre, the
| mitigations are a waste and therefore slow the CPU.
| pdpi wrote:
| Except that that's the opposite of what's going on. The CPU
| performs better with the "wasted" mitigations turned on.
| Ristovski wrote:
| An interesting comment made in the Phoronix forums:
|
| > My theory is that fixing the Spectre V2 vulnerability on a
| hardware level would lead to fundamental architecture changes
| that AMD is not willing to make, because it may add so much more
| complexity to the architecture or it may just be too
| unconvenient. They probably realized that optimizing the code
| paths that the Linux kernel utilizes on the default mitigations
| mode is faster, simpler and it may involve less deeper changes,
| while still being secure.
|
| > As far as I know, pretty much every CPU architecture that
| implements speculative execution is vulnerable to some version of
| Spectre, so note that this is not a fundametal flaw of AMD64.
| ajross wrote:
| That seems like a disaster brewing. The whole spectre family of
| vulnerabilities is a side effect of CPUs keeping state around
| to optimize things and leaking that data between privilege
| levels.
|
| I mean, in the humorous extreme: imagine if some enterprising
| group at AMD got together and realized they could "optimize"
| all that retpoline code by making the RET instruction aware of
| the branch prediction cache!
|
| "Fundamental architecture changes" are, in fact, what is
| actually required here.
| galaxyLogic wrote:
| https://www.pcgamer.com/intel-amd-and-arm-cpus-hit-by-new-sp...
| dundarious wrote:
| That's the Spectre V2 from the OP title. What's the point
| this link is meant to convey?
| aliqot wrote:
| Probably that they had a feeling they wanted to refute it
| somehow but figured an article would be more authoritative,
| except the one they picked was picked by the headline
| rather than content.
| dundarious wrote:
| Yes, it certainly seems that way.
| tadfisher wrote:
| Occam's Razor would suggest a Linux bug.
| Sesse__ wrote:
| Occam's Razor would suggest that Phoronix' benchmarks are
| broken.
| iforgotpassword wrote:
| Or maybe if we want to keep in the realm of AMD doing
| something on purpose here, maybe they can detect that the
| kernel is run with mitigations and then just let the CPU do
| all the unsafe speculation, while without the mitigations,
| they disable a lot of the speculative stuff which is somehow
| even slower than the former case.
| Sirened wrote:
| I am terrified to think what AMD's predictor structure is if
| it's easier for them to do _this_ than it is to simply add
| privilege tags to their predictors. I don't personally buy this
| explanation anyways; trying to optimize retpolines in hardware
| would be an absolute pain in the ass and require an insane
| amount of synchronization with the backend since retpolines
| always trash the RAS.
| sounds wrote:
| I would guess it's probably physics. Specifically the
| complexity of the signal path routing for the predictor core
| must be pretty heavily optimized, and probably are where AMD
| (and Intel) have invested heavily in advanced design software
| - their secret sauce - to push the chip right to the edge of
| what semiconductor physics can achieve.
|
| The branch predictor is one of the most highly optimized
| pieces of the CPU core. Lots of discussion has been had about
| how the arm architecture's frontend is simpler, so for
| example Apple's chips have way more execution units. Intel
| and AMD's latest designs have also expanded the number of
| execution units, but the frontend instruction decode and
| dispatch is the "serial" part of the process, reading the
| incoming instruction stream. And the x86 instruction set is
| hard to decode, with a lot of variation in the number of
| bytes per instruction. So for the instruction decoder to even
| know there's a branch coming up is a "hard problem," and then
| it predicts which way the branch will go.
| stevefan1999 wrote:
| meh, maybe they just flush TLB every time in hardware level if
| you disabled the mitigations, ane disabled the hardware flush if
| the software side can handle it
| staticassertion wrote:
| This is basically my guess. In the event of no mitigations you
| have to pessimistically flush TLB. In the case of mitigations
| the flush only has to happen in specific instances, which PCID
| significantly helps with but requires cooperation from both
| hardware and software.
|
| So maybe even something like "if PCID is not set, flush the
| cache" vs "if PCID _changes_ , flush the cache".
|
| I think that would certainly account for this, and they could
| have improved the performance with PCID by increasing the PCID
| cache size.
| bmacho wrote:
| So mitigations = off when they do flush, and mitigations = on
| when they use previous data and weird shenanigans?
| Cloudef wrote:
| Yeah it seems like hw migtation is slower than software
| amelius wrote:
| Perhaps their Spectre path has benchmark detection :)
| MBCook wrote:
| "As for why the Ryzen 7000 series performance is actually slower
| if disabling the Spectre V2 mitigations, that's likely something
| only AMD can effectively answer but presumably..."
|
| _Just ask!_
|
| Seriously. You can ask AMD. Maybe they won't tell you, but _they
| might_. It might be really good info. Why not ask someone who is
| really knowledgeable about this stuff like a kernel developer who
| works on x86-64 or worked on the mitigations?
|
| This is what I never understand about Phoronix. People link to
| them all the time but they run a bunch of benchmarks and then end
| on "there you go". I'd like investigation into _why_. You won't
| always get an answer but you should try.
| p-e-w wrote:
| > Seriously. You can ask AMD. Maybe they won't tell you, but
| they might.
|
| Seriously? By far the most likely outcome is that they don't
| even bother responding.
|
| That's how corporations operate in 2022. If you're a journalist
| from the Washington Post, you might get a three-line statement
| from a spokesperson. Everyone else gets a canned reply from a
| bot, or nothing at all.
|
| I don't blame Michael for not even bothering to try. Phoronix
| is the only game in town for much of the topics it covers. The
| fact that it exists at all, and is effectively run by a single
| person, is nothing short of amazing.
| worthless-trash wrote:
| > That's how corporations operate in 2022. If you're a
| journalist from the Washington Post, you might get a three-
| line statement from a spokesperson. Everyone else gets a
| canned reply from a bot, or nothing at all.
|
| This is not true, I write to AMD security team for
| spectre/meltdown/CPU flaws and get reasonable responses.
| Intel security team is also quite good. The usual wait time
| is 3-4 days.
|
| Admittedly I do write from my work address.
| stingraycharles wrote:
| What's your work, out of curiosity? I suppose security
| researcher?
| p-e-w wrote:
| That's great, but I suspect the address you write from
| indeed plays a big part here. Direct responses from
| engineers of that caliber within a matter of days is most
| certainly _not_ standard.
| inglor wrote:
| I answer engineers from other companies all the time but
| never answer journalists. Engineers give a vibe of "cares
| about what you do and wants to collaborate".
|
| Talking to journalists is like talking to the police - as
| an engineer you don't understand the situation well enough
| and you need to involve an (expensive) professional to
| navigate it.
|
| The question going through my head when I get journalist
| emails is "can I ignore this and save the hours of work
| with legal/pr?".
| spookie wrote:
| True that
| [deleted]
| marcosdumay wrote:
| On most places only the PR team is even allowed to talk
| to journalists. Exactly because that "is like talking to
| the police" issue.
|
| It's a very sensible and correct policy.
| TheRealPomax wrote:
| > By far the most likely outcome is that they don't even
| bother responding
|
| So, "likely" the same outcome as when you don't ask, except
| unlike when you don't ask, there _is_ a different outcome
| when you _do_ ask? Sounds like you just made the argument in
| favour of always asking questions.
| Blikkentrekker wrote:
| Under the assumption that time is not valuable. Writing
| such an email is still an investment of time.
| theow7384iri wrote:
| I don't think Phoronix has time and budget for that. It is a
| single man, a few scripts and heavy automation. Sometimes he
| founds bugs and reports it, but there is no time to follow such
| rabbit hole!
| getcrunk wrote:
| if anything, industry should reach out to him imo. he has a
| lot of mind share in the IT community
| albertopv wrote:
| Phoronix is a one man show literally doing everything: hw
| managemen, tests, articles, news reports, forum admin, premium
| users management...
| hericium wrote:
| > Just ask! Seriously. You can ask AMD.
|
| But it's Phoronix - short reprints, not well-done benchmarks,
| 1-3 paragraphs long "articles" and backlink spam on forums,
| wikis and wherever possible. They may ask AMD but that will be
| another "article" and another wave of spam.
| woliveirajr wrote:
| Remembers me about the 'supercow powers" question at
| StackOverflow (unixStackExchange): everybody just guessing, I
| dared to ask Jason Gunthorpe and he didn't answer me... he made
| post about it:
|
| https://web.archive.org/web/20190322061230/https://plus.goog...
___________________________________________________________________
(page generated 2022-10-08 23:02 UTC)