It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush).
This time it could be an AVX512 instruction (intel only) that leaks kernel address in a way or another.
I was talking from an ISA perspective.
For eg, clflush may be implemented differently between Intel and AMD, it has the same effect on system RAM hence a shared exploit.
> It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush).
No, rowhammer does not need clflush. All rowhammer needs is to be able to write to the same physical memory locations repeatedly. Normally the cache would get in the way, so the attacker needs to bypass it. Flushing the cache (clflush) is one way, but there are others; AFAIK, it has been demonstrated rowhammer from within a Javascript VM, which has no access to clflush.
Yes, I knew you could do rowhammer on arm too where clflush does not exit. So rowhammer is not the correct example.
Yet at some point it was believed that it was necessary on x86 for the attack to work. https://en.wikipedia.org/wiki/Row_hammer#Exploits
I just made a bet that I could guess something out of ISA only.
Going macro to describe what may be the issue. I'm just doing a guess work here.
I was not implying Intel has the same implementation as AMD, nor I was making a case for "this is like rowhammer"
I bet you within the foundations of AVX512 lies a nasty one that can't be patched with microcode update.