Prebúsqueda adaptativa en un chip multiprocesador

La prebúsqueda agresiva ha demostrado ser una técnica eficiente para mejorar el rendimiento de los sistemas monoprocesador. Sin embargo, en sistemas multiprocesador con un último nivel de memoria cache compartido (LLC), la actividad de prebúsqueda inducida por un núcleo consume recursos comunes como espacio en la LLC y ancho de banda. Esto puede degradar el rendimiento del resto de núcleos e incluso el rendimiento general del sistema. Por tanto, la prebúsqueda hardware en un multiprocesador que tiene un último nivel de cache compartido (LLC) es un reto. En este trabajo presentamos ABS, un mecanismo de bajo coste que adecúa la agresividad de la prebúsqueda de cada uno de los núcleos en cada uno de los bancos de la LLC de un chip multiprocesador. El mecanismo se ejecuta de forma independiente en cada banco de la LLC usando sólo información local. A intervalos temporales regulares un núcleo es seleccionado y la tasa de fallos del banco y la utilidad de la prebúsqueda de dicho núcleo son muestreadas. Estas métricas son utilizadas para ajustar la agresividad de la prebúsqueda asociada al núcleo elegido. Nuestros análisis con cargas multiprogramadas de SPEC2K6 muestran que el mecanismo mejora tanto las métricas de usuario (el tiempo medio de retorno un 27% y la equidad un 11%) como las de sistema (la productividad agregada mejora un 22% y el ancho de banda consumido se reduce un 14%) con respecto a un sistema base con ocho núcleos que usa prebúsqueda secuencial marcada de grado fijo. Los resultados son consistentes cuando se utiliza un sistema con dieciséis núcleos o cuando comparamos nuestro mecanismo con propuestas previas

Formally verified countermeasures against cache based attacks in virtualization platforms

Cache based attacks are a class of side-channel attacks that are particularly effective in virtualized or cloud-based environments, where they have been used to recover secret keys from cryptographic implementations. One common approach to thwart cache-based attacks is to use constant-time implementations, which do not branch on secrets and do not perform memory accesses that depend on secrets. However, there is no rigorous proof that constant-time implementations are protected against concurrent cache attacks in virtualization platforms; moreover, many prominent implementations are not constant-time. An alternative approach is to rely on system-level mechanisms. One recent such mechanism is stealth memory, which provisions a small amount of private cache for programs to carry potentially leaking computations securely. We weaken the definition of constant-time, introducing a new program classification called S-constant-time, that captures the behavior of programs that correctly use stealth memory. This new definition encompasses some widely used cryptographic implementations. However, there was no rigorous analysis of stealth memory and S-constant-time, and no tool support for checking if applications are S-constant-time. In this thesis, we propose a new information-flow analysis that checks if an x86 application executes in constant-time or S-constant-time. Moreover, we prove that (S-)constant-time programs do not leak confidential information through the cache to other operating systems executing concurrently on virtualization platforms. The soundness proofs are based on new theorems of independent interest, including isolation theorems for virtualization platforms, and proofs that (S-)constant-time implementations are non-interfering with respect to a strict information flow policy which disallows that control flow and memory accesses depend on secrets. We formalize our results using the Coq proof assistant and we demonstrate the effectiveness of our analyses on cryptographic implementations, including PolarSSL AES, DES and RC4, SHA256 and Salsa20.Los ataques basados en el cache son una clase de ataques de canal lateral (side-channel) particularmente efectivos en entornos virtualizados o basados en la nube, donde han sido usados para recuperar claves secretas de implementaciones criptográficas. Un enfoque común para frustrar los ataques basados en cache es usar implementaciones de tiempo constante (constant-time), las cuales no tienen bifurcaciones basadas en secretos, y no realizan accesos a memoria que dependan de secretos. Sin embargo, no existe una prueba rigurosa de que las implementaciones de tiempo constante están protegidas de ataques concurrentes de cache en plataformas de virtualización. Además, muchas implementaciones populares no son de tiempo constante. Un enfoque alternativo es utilizar mecanismos a nivel del sistema. Uno de los más recientes de estos es stealth memory, que provee una pequeña cantidad de cache privado a los programas para que puedan llevar a cabo de manera segura computaciones que potencialmente filtran información. En este trabajo se debilita la definición de tiempo constante, introduciendo una nueva clasificación de programas llamada S-constant-time, que captura el comportamiento de programas que hacen un uso correcto de stealth memory. Esta nueva definición abarca implementaciones criptográficas ampliamente utilizadas. Sin embargo, hasta el momento no había un análisis riguroso de stealth memory y S-constant-time, y ningún soporte de herramientas que permitan verificar si una aplicación es S-constant-time. En esta tesis, proponemos un nuevo análisis de flujo de información que verifica si una aplicación x86 ejecuta en constant-time o S-constant-time. Además, probamos que los programas (S-)constant-time no filtran información confidencial a través del cache a otros sistemas operativos ejecutando concurrentemente en plataformas de virtualización. La pruebas de corrección están basadas en propiedades que incluyen teoremas, de interés en sí mismos, de aislamiento para plataformas de virtualización y pruebas de que las implementaciones (S-)constant-time son no interferentes con respecto a una política estricta de flujo de información que no permite que el control de flujo y los accesos a memoria dependan de secretos. Formalizamos nuestros resultados utilizando el asistente de pruebas Coq, y mostramos la efectividad de nuestros análisis en implementaciones criptográficas que incluyen PolarSSL AES, DES y RC4, SHA256 y Salsa20

BuMP: Bulk Memory Access Prediction and Streaming

With the end of Dennard scaling, server power has emerged as the limiting factor in the quest for more capable datacenters. Without the benefit of supply voltage scaling, it is essential to lower the energy per operation to improve server efficiency. As the industry moves to lean-core server processors, the energy bottleneck is shifting toward main memory as a chief source of server energy consumption in modern datacenters. Maximizing the energy efficiency of today's DRAM chips and interfaces requires amortizing the costly DRAM page activations over multiple row buffer accesses. This work introduces Bulk Memory Access Prediction and Streaming, or BuMP. We make the observation that a significant fraction (59-79%) of all memory accesses fall into DRAM pages with high access density, meaning that the majority of their cache blocks will be accessed within a modest time frame of the first access. Accesses to high-density DRAM pages include not only memory reads in response to load instructions, but also reads stemming from store instructions as well as memory writes upon a dirty LLC eviction. The remaining accesses go to low-density pages and virtually unpredictable reference patterns (e.g., hashed key lookups). BuMP employs a low-cost predictor to identify high-density pages and triggers bulk transfer operations upon the first read or write to the page. In doing so, BuMP enforces high row buffer locality where it is profitable, thereby reducing DRAM energy per access by 23%, and improves server throughput by 11% across a wide range of server applications

Improving the SLLC Efficiency by exploiting reuse locality and adjusting prefetch

Desde los teléfonos móviles inteligentes hasta nuestro ordenador portátil los sistemas electrónicos que incluyen chips multiprocesador (CMP) están presentes en nuestra vida cotidiana de una manera abrumadora. Los CMPs contienen varios núcleos o CPUs que tienen que ser alimentados con datos provenientes de la memoria. Pero la velocidad a la que los núcleos que forman el CMP necesitan los datos es mucho mayor que la velocidad a la que la memoria es capaz de proporcionar dichos datos. De hecho, esta diferencia ha ido aumentando desde prácticamente el día en el que ambos dispositivos fueron concebidos. Esta diferencia en el rendimiento de ambos dispositivos se ha venido a llamar "the memory gap". Al mismo tiempo que dicha diferencia aumentaba, los lenguajes de programación proporcionaban a los programadores modelos de memoria que podían acceder a un espacio prácticamente infinito y al que, además, se accedía de manera instantánea. Pero el tamaño de cualquier estructura hardware está íntimamente relacionado con su tiempo de acceso y éste será mayor cuanto mayor sea el tamaño la estructura hardware a acceder. Con el ánimo de deshacer esta aparente contradicción, los arquitectos de computadores incluyeron memorias intermedias entre las CPUs y la grande, aunque al mismo tiempo lenta, memoria principal. Estas memorias intermedias se denominan memorias cache o simplemente caches. Debido a la gran diferencia que existe entre la velocidad del procesador y la de la memoria principal. Los CMPs en la actualidad están provistos de una jerarquía de memorias cache que tiene dos o tres niveles. Las caches que están cerca del procesador sólo contienen unos pocos kilobytes (entre 4 y 64) accesibles en uno o pocos ciclos de reloj, mientras que las que se encuentran más alejadas del procesador pueden llegar a contener varios megabytes y tener un tiempo de acceso de varias decenas de ciclos. Los programas al ser ejecutados muestran una propiedad llamada localidad que se expresa en los ejes espacial y temporal. La localidad temporal es la propiedad que dice que el programa volverá a usar datos que usó recientemente, cuanto más recientemente los usó, más probable es que vuelva a hacerlo. Mientras que la localidad espacial es la propiedad que dice que el programa tenderá a usar datos que están próximos en el espacio de memoria a datos que usó recientemente. Las memorias cache han sido diseñadas tradicionalmente para explotar la localidad. En concreto, la localidad temporal se explotaba mediante una adecuada política de reemplazo, mientras que la localidad espacial se explota al contener cada bloque de cache varios datos o palabras. Un modo adicional de conseguir explotar una mayor cantidad de localidad espacial es mediante el uso de la técnica llamada prebúsqueda. La política de reemplazo influye de manera crítica en la tasa de aciertos de la memoria cache. En un CMP provisto de una jerarquía de memorias cache, la localidad temporal se explota en aquellos niveles más cercanos a los núcleos. Así que muchos de los bloques insertados en la SLLC son de un solo uso, es decir, estos bloques no experimentarán ningún acierto más durante todo el tiempo que permanezcan en la SLLC. Sin embargo, aquellos bloques que lleguen a experimentar un acierto en la SLLC, normalmente experimentarán muchos más aciertos. Por lo tanto, que la política de reemplazo base sus decisiones en la posible explotación de la localidad temporal, es una asunción inválida cuando hablamos de la SLLC. Por el contrario, Este comportamiento indica que dicha política de reemplazo de la SLLC debería estar basada en el reúso1 en lugar de en la localidad temporal. La prebúsqueda hardware tiene por objetivo cargar en la cache datos antes de que sea el procesador quien los pida. La validez de esta técnica a la hora de reducir la latencia media de acceso a memoria ha sido ampliamente demostrada. La prebúsqueda funciona especialmente bien en las jerarquías de memoria de sistemas monoprocesador, donde solamente hay un flujo de datos entre el procesador y la memoria. Sin embargo, cuando la prebúsqueda se usa en un sistema multiprocesador donde diferentes aplicaciones se están ejecutando al mismo tiempo, las prebúsquedas asociadas a un núcleo podrían interferir con los datos cargados en la cache por otro núcleo, provocando la eliminación de los contenidos de otra aplicación y dañando su rendimiento. Es necesario por tanto un mecanismo para regular la prebúsqueda asociada a cada uno de los núcleos. Este mecanismo debería tener por objetivo el mejorar el rendimiento general del sistema. 1 Aunque el DRAE no contenga su definición, usaremos aquí el verbo reusar (así como sus formas derivadas) como sinónimo de volver a utilizar. Cada fallo en la SLLC provoca un acceso a la memoria principal que se encuentra fuera del chip. Además la memoria principal está hecha de chips de DRAM. Ambos factores incrementan su latencia de acceso, latencia que se suma a cada uno de los accesos que falla en la SLLC, penalizando a la vez la latencia media de acceso a memoria. Por lo tanto, la tasa de aciertos de la SLLC es un factor crítico para lograr una latencia media de acceso a memoria óptima. Esta tesis fija su atención en la eficiencia de los dos aspectos comentados con anterioridad: la eficiencia de la prebúsqueda y la eficiencia de la política de reemplazo. Las contribuciones principales de esta tesis son las siguientes: 1) Enunciamos una propiedad llamada localidad de reúso que dice que i) los bloques de cache que hayan sido usados más de una vez tienen una alta probabilidad de ser usados muchas veces en el futuro. ii) Los bloques de cache recientemente reusados son más útiles que otros reúsados previamente. Defendemos en esta tesis que el patrón de acceso a la SLLC muestra localidad de reúso. 2) En esta tesis se proponen dos algoritmos de reemplazo capaces de explotar la localidad de reúso, Least-recently reused (LRR) y Not-recently reused (NRR). Estos dos nuevos algoritmos son modificaciones de otros dos muy bien conocidos: Least-recently used (LRU) y Not-recently used (NRU). Dichos algoritmos fueron diseñados para explotar la localidad temporal, mientras que los nuestros explotan la local- idad de reúso. Las modificaciones propuestas no suponen ninguna sobrecarga hardware respecto a los algoritmos base. Durante esta tesis se muestra que nuestros algoritmos mejoran consistentemente el rendimiento de los originales. 3) Proponemos un novedoso diseño para la SLLC llamado Reuse Cache. En este diseño los arrays de etiquetas y datos de la cache están desacoplados. Solamente se almacenan en el array de datos aquellos bloques que hayan mostrado reúso. El array de etiquetas se usa para detectar reúso y mantener la coherencia. Esta estructura permite reducir el tamaño del array de datos de manera drástica. Como ejemplo, una Reuse Cache con un array de etiquetas equivalente al de una cache convencional de 4MB y un array de datos de 1MB, tiene el mismo rendimiento medio que una cache convencional de 8MB, pero con un ahorro de almacenamiento de en torno al 84%. 4) Un controlador de bajo coste llamado ABS capaz de ajustar la agresividad de la prebúsqueda asociada a cada uno de los núcleos de un CMP pero con el ánimo de mejorar el rendimiento general del sistema. El controlador funciona de manera aislada en cada uno de los bancos de la SLLC y recoge métricas locales. Para optimizar el rendimiento global del sistema busca la combinación óptima de valores de la agresividad de prebúsqueda. Para inferir cuál es esa combinación óptima usa una estrategia de búsqueda hill-climbing

Evasive Malware via Identifier Implanting

To cope with the increasing number of malware attacks that organizations face, anti-malware appliances and sandboxes have become an integral security defense. In particular, appliances have become the de facto standard in the fight against targeted attacks. Yet recent incidents have demonstrated that malware can effectively detect and thus evade sandboxes, resulting in an ongoing arms race between sandbox developers and malware authors. We show how attackers can escape this arms race with what we call customized malware, i.e., malware that only exposes its malicious behavior on a targeted system. We present a web-based reconnaissance strategy, where an actor leaves marks on the target system such that the customized malware can recognize this particular system in a later stage, and only then exposes its malicious behavior. We propose to implant identifiers into the target system, such as unique entries in the browser history, cache, cookies, or the DNS stub resolver cache. We then prototype a customized malware that searches for these implants on the executing environment and denies execution if implants do not exist as expected. This way, sandboxes can be evaded without the need to detect artifacts that witness the existence of sandboxes or a real system environment. Our results show that this prototype remains undetected on commercial malware security appliances, while only exposing its real behavior on the targeted system. To defend against this novel attack, we discuss countermeasures and a responsible disclosure process to allow appliances vendors to prepare for such attacks