There are no "cryptographic operations" on the hardware level. It's just normal math, therefore cryptographic code would have to give hints to the processor to enable such countermeasures. Such a facility does not seem to exist yet, and this is why this vulnerability is considered to be unfixable. In comparison, there were workarounds for Spectre because compilers can emit code where the processor cannot apply the dangerous optimizations.
There are special CPU instructions to help speed up cryptographic algorithms, but applying countermeasures to these is not always crucial. They only matter if an attacker could otherwise create a side-channel. This applies in TLS, but not, e.g., when verifying checksums of downloaded software.
> therefore cryptographic code would have to give hints to the processor to enable such countermeasures. Such a facility does not seem to exist yet, and this is why this vulnerability is considered to be unfixable
That is what I am describing. I am proposing that we need to implement these facilities in firmware/microcode.
There are special CPU instructions to help speed up cryptographic algorithms, but applying countermeasures to these is not always crucial. They only matter if an attacker could otherwise create a side-channel. This applies in TLS, but not, e.g., when verifying checksums of downloaded software.