https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #14 from Jonathan Wakely ---
Created attachment 51547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51547=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #13 from Jonathan Wakely ---
(In reply to Edward Cree from comment #12)
> Stdlib must be looking at cpuid
> directly rather than using anything the kernel can mediate?)
Correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #12 from Edward Cree ---
A datum: booting with 'nordrand' on the kernel command line does not affect
this, the test program still prints 4294967295. (Yet '/proc/cpuinfo' no longer
mentions rdrand or rdseed in flags. Stdlib must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #11 from Jonathan Wakely ---
We could use a different function for AMD, rather than __x86_rdrand. If it
reads a -1 value it could try again a few more times, and if it gets -1 every
time assume it's broken (and throw?), maybe after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #10 from Jonathan Wakely ---
Maybe we should go back to only using RDRAND for Intel :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #9 from Richard Biener ---
Note that if you read the errata you figure that the broken RDRAND behavior can
occur after a suspend/resume cycle only which means that detecting this in
the RDRAND detection logic is too "early" if you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #8 from Jonathan Wakely ---
g:b0c0d878a8b5bf39dbea4c192fed26d340524439 enabled RDRAND and RDSEED for AMD
chips, where previously we'd only used RDRAND and only for Intel (which caused
one particular idiot to complain that we "hate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #7 from Edward Cree ---
(In reply to Richard Biener from comment #4)
> people that
> cannot be bothered to update their ucode or the kernel are not likely
> bothered to update libstdc++ either.
Fwiw, my kernel is fairly up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #6 from Jonathan Wakely ---
(In reply to Richard Biener from comment #4)
> so here it could check for -1 as well though in theory that
> can happen with true randomness as well, even if very unlikely. Note
> that it would never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #5 from Jonathan Wakely ---
(In reply to Richard Biener from comment #4)
> Thus I believe the issue is mitigated at the kernel level and people that
Yes, that's my understanding.
> cannot be bothered to update their ucode or the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #4 from Richard Biener ---
So at least libstdc++ does check RDRAND availability via cpuid. It also
already
checks the return value for "no avaialble randomness":
while (__builtin_ia32_rdrand32_step() == 0)
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #2 from Edward Cree ---
(In reply to Richard Biener from comment #1)
> Isn't this worked around at kernel level by disabling RDRAND support on
> affected CPUs?
Not sure. I wondered if it might be, so I straced the process and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444
--- Comment #1 from Richard Biener ---
Isn't this worked around at kernel level by disabling RDRAND support on
affected CPUs?
15 matches
Mail list logo
