<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body><a class="email" href="mailto:ckoenig.leichtzumerken@gmail.com" title="Christian König <ckoenig.leichtzumerken@gmail.com>"> Christian König</a> changed <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - radeonsi: 3D engines causing frequent GPU lockups" href="https://bugs.freedesktop.org/show_bug.cgi?id=101672">bug 101672</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">Status</td> <td>NEW </td> <td>RESOLVED </td> </tr> <tr> <td style="text-align:right;">Resolution</td> <td>--- </td> <td>FIXED </td> </tr></table> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - radeonsi: 3D engines causing frequent GPU lockups" href="https://bugs.freedesktop.org/show_bug.cgi?id=101672#c25">Comment # 25</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - radeonsi: 3D engines causing frequent GPU lockups" href="https://bugs.freedesktop.org/show_bug.cgi?id=101672">bug 101672</a> from <a class="email" href="mailto:ckoenig.leichtzumerken@gmail.com" title="Christian König <ckoenig.leichtzumerken@gmail.com>"> Christian König</a> <pre>(In reply to MirceaKitsune from <a href="show_bug.cgi?id=101672#c24">comment #24</a>) > This is the last piece of confirmation I needed to conclude that what's > happening must be a deliberate malware: There is simply no way a GPU crash > bug could behave 100% the same way on two entirely different video drivers. The two driver stacks are mostly the same, only the kernel module differs. > Further more, this freeze is completely identical to the one I initially > reported here... which was obviously fixed since there's been so many > updates to every system component it would have been solved by sheer chance > at this point! Functionality like this should only be seen if someone is > actively re-implementing the problem on top of updated system components, > with the active intent of keeping its effects identical each time. It's > possible that my machine may be used to test malware usable to shut down > Linux systems, in which case I need to find out where it's hidden and how > it's bricking computers before it spreads. LOL, well you are funny. What you are hitting here is just a random problem triggered most likely by a bug in the userspace part of the driver which is identical for both radeon and amdgpu. > This attack must exploit vulnerabilities that keep coming and going in X11, > Mesa, or some other system component... those are hopefully holes which can > be discovered and plugged to render the attacks impractical altogether. > Again I only know that it's triggered while certain 3D engines are running > (possibly aimed primarily at gamers?) and has a random chance of happening > roughly once every 30 minutes (likely to make testing harder and better hide > the exploit). Well there is no such thing as an exploit involved here. If it wants to produce a lockup an application can just send a shader with an infinity loop to the hardware. There is no way to prevent that (see turing halting problem on wikipedia). What we can do is trying to reset the hardware after some timeout. Anyway the logs attached to this bug report are completely useless for your new issue, so closing this one.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>