Basically timing attacks are completely unavoidable on SMT because SMT fundamentally depends on what the other thread is doing on the core, if the thread is us

Basically timing attacks are completely unavoidable on SMT because SMT fundamentally depends on what the other thread is doing on the core, if the thread is using few core resources the attack thread gets more, or vice versa. This gives you a very fine grained view into what the other thread is doing timing wise, and is inherent to the concept of SMT (two threads running on a core at once, using resources not utilized by the other). I suspect this issue is completely impossible to resolve in anything except very constrained situations that negate the benefit of SMT entirely. Its different than say, a timing attack on the OS scheduler for two reasons 1. OS scheduling is very coarse (A process gets exclusive use of a core for tens of thousands or hundreds of thousands of cycles), with SMT you get a very fine grained near cycle-by-cycle view of core utilization by the other process. 2. you don't get much of a view into what precisely the other thread is doing such as is it doing lots of integer operations, floating point, memory fetches etc, which can be derived in SMT attacks based on how fast such things occur for the evil monitoring thread.