[HN Gopher] Mitigations=off considered harmful or spurious SIGIL...
       ___________________________________________________________________
        
       Mitigations=off considered harmful or spurious SIGILL on AMD Zen4
        
       Author : 2bluesc
       Score  : 86 points
       Date   : 2023-10-08 17:31 UTC (5 hours ago)
        
 (HTM) web link (forum.level1techs.com)
 (TXT) w3m dump (forum.level1techs.com)
        
       | GracielaEdison wrote:
       | [dead]
        
       | nightfly wrote:
       | Have they tested this on more than one machine? This seems like
       | it could be a hardware fault
        
       | 2bluesc wrote:
       | Interesting walk through in the linked video as he tried to
       | troubleshoot this:
       | 
       | https://www.youtube.com/live/1UnoBfw6soI
       | 
       | Pretty shocking to see (extremely unlikely) non-malicious code
       | work / not-work depending on a security mitigation setting.
       | 
       | Curious to see where this goes as to whether it's a kernel bug
       | and nobody is paying attention to `mitigations=off` now or the
       | unlikely outcome that it's an actual hardware bug where
       | mitigations work around it and nobody has noticed.
       | 
       | Seems he had overclocked and maybe disabling the migation has
       | revealed an instability in his setup that's otherwise stable (or
       | at best marginal).
        
         | tux3 wrote:
         | mitigations=off does a lot of things, it's a bundle of options
         | 
         | Perhaps the next step is trying to figure out which mitigation
         | exactly causes it to fail. Then kernel peeps should have a
         | fighting chance of tracking this down
        
           | simcop2387 wrote:
           | In the video comments it looks like he's done some of that
           | and it's one of the spectre v2 mitigations. Makes me wonder
           | if there's now less QA happening on the oem side without
           | mitigations=on.
        
           | AnotherGoodName wrote:
           | SMT off fixing it is a good clue. It heavily points to the
           | problem being within a core rather than between execution
           | cores. That's still a broad area though. Within a core some
           | state is inadvertantly shared between the shared threads
           | running on it but there's a lot of possibilities of what that
           | could be.
        
             | foota wrote:
             | Some state being in the CPU or kernel? I guess if you have
             | per core state in the kernel that's only accessed by that
             | core, then you're safe to modify it without locking, but
             | this isn't the case for data shared between hyperthreads of
             | a core?
        
               | AnotherGoodName wrote:
               | Within the CPU core (terminology here gets awkward).
               | Spectre in its simplest to exploit form used the fact
               | that the branch prediction based state wasn't completely
               | cleared between running different threads on the CPU and
               | led to a really easy timing attack. Time your own code to
               | see which way the branch of the previous code likely
               | went. There's a lot of CVE's around this but that's the
               | simplest case.
               | 
               | The mitigations work by making sure to clear everything
               | they can when the CPU switches contexts. This includes
               | clearing loaded local CPU cache, clearing the branch
               | prediction table, clearing all speculative execution
               | entries. The mitigations likely avoid a crash by clearing
               | something that should be cleared between context switches
               | in all cases. As in the mitigations likely accidentally
               | fix this. Which is a good clue. It'd be nice if the
               | mitigations were more fine grained than all or nothing so
               | we could turn on the mitigations one by one but the
               | microcode is not open so we can't do this :(.
        
         | yellow_lead wrote:
         | He says that he tried stock voltage for everything, and even
         | undervolted/underclocked CPU/memory and still had the bug.
        
       | secondcoming wrote:
       | Isn't there a rule about titles containing 'considered harmful'?
       | 
       | Either way, this is pretty interesting and the guy is pretty
       | excited about finding it.
        
         | burnished wrote:
         | I think its merely considered gauche, that and people seem to
         | have broadly realized anyone could use that phrase to imply
         | consensus.
        
         | fabianhjr wrote:
         | There is a rule on mostly not editorializing titles and in this
         | case that is the title of the source article.
         | 
         | > Otherwise please use the original title, unless it is
         | misleading or linkbait; don't editorialize.
        
       | nubinetwork wrote:
       | Still waiting for amd to fix random bugs in znver1.
       | https://bugs.gentoo.org/724314
        
         | ta988 wrote:
         | Unlikely to happen.
        
       | nathants wrote:
       | lucky me, i'm running mitigations=off and smt=off on a 7950x.
        
         | zamadatix wrote:
         | Out of curiosity did you have smt=off for performance reasons
         | or other reasons?
        
           | nathants wrote:
           | performance testing vulkan and physx on linux.
        
       | [deleted]
        
       | Ckirby wrote:
       | Since when is level1techs taken seriously as a source?
       | 
       | A bunch of YouTube Kids with an unwarranted sense of self
       | importance found this "major" "huge" case of nothing
        
         | ezekiel68 wrote:
         | You know how it is in social media -- just like in academia:
         | "Publish or perish".
        
         | sph wrote:
         | Someone got an axe to grind.
        
       ___________________________________________________________________
       (page generated 2023-10-08 23:00 UTC)