Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitigations=off considered harmful or spurious SIGILL on AMD Zen4

forum.level1techs.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Mitigations=off considered harmful or spurious SIGILL on AMD Zen4

#12

Post by AnotherGoodName »

tux3 wrote: post #4
2bluesc wrote: post #2

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 w…

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

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.

Re: Mitigations=off considered harmful or spurious SIGILL on AMD Zen4

#14

Post by foota »

AnotherGoodName wrote: post #12
tux3 wrote: post #4

Earlier quoted context omitted.

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

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.

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?

Re: Mitigations=off considered harmful or spurious SIGILL on AMD Zen4

#15

Post by burnished »

secondcoming wrote: post #5

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.

I think its merely considered gauche, that and people seem to have broadly realized anyone could use that phrase to imply consensus.

Re: Mitigations=off considered harmful or spurious SIGILL on AMD Zen4

#19

Post by AnotherGoodName »

foota wrote: post #14
AnotherGoodName wrote: post #12

Earlier quoted context omitted.

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.

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?

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 :(.

Post reply on HN