Puesto que Spectre representa una clase nueva y entera de ataques, lo más probable es que no pueda haber un único parche general para él. Aunque ya se está trabajando para abordar casos especiales de la vulnerabilidad, el sitio web original dedicado a Spectre y Meltdown afirma que "dado que [Spectre] no es fácil de arreglar, nos perseguirá durante mucho tiempo".

En cualquier caso, se han reportado varios procedimientos a seguir para proteger los ordenadores domésticos y dispositivos relacionados frente a Meltdown y Spectre.

La explotación a través de Javascript incrustado en los sitios web es posible. Chrome 64 incluirá por defecto mitigaciones contra el ataque, y los usuarios de Chrome 63 pueden mitigar manualmente el ataque activando la función Strict Site Isolation (chrome://flags#enable-site-per-process). A partir de Firefox 57, Mozilla está reduciendo la resolución de los temporizadores JavaScript para ayudar a prevenir ataques sincronizados, y está trabajando y planificando técnicas de ofuscación de tiempos para futuras versiones.Alternativamente, se puede evitar la explotación basada en navegadores web desactivando JavaScript (p. ej. NoScript).

El 4 de enero de 2018 Google detalló una nueva técnica en su blog de seguridad llamada Retpoline que puede detener la vulnerabilidad Spectre añadiendo una sobrecarga insignificante para el procesador, y consiste en dirigir a nivel del compilador las ramas indirectas hacia un destino distinto, de forma que no pueda tener lugar una ejecución especulativa fuera de orden que sea vulnerable. Aunque se desarrolló para el juego de instrucciones de los procesadores x86, los ingenieros de Google creen que la técnica también es transferible a otros procesadores.

También se ha sugerido​ que el coste de la mitigación puede aliviarse en procesadores que soporten la limpieza selectiva del TLB, una característica también conocida como identificador de contexto de proceso (PCID) en la arquitectura Intel 64, y número de espacio de dirección (ASN) en la arquitectura Alpha. Esto se debe a que la limpieza selectiva hace que el comportamiento del TLB que resulta crucial para la vulnerabilidad se aisle entre procesos, sin estar constantemente limpiando el TLB en su totalidad, principal motivo del coste de la mitigación.

Además del Kernel de Linux, proyectos como GCC y LLVM ya estar trabajando en adoptar esta técnica.

Fuente: Wikipedia