¿Puede el código nativo causar corrupción de memoria en código Java en Android?

En Android, cuando llamamos código nativo a través de JNI, ¿puede corromper la VM de Dalvik y el código Java que se ejecuta dentro de él?

Por ejemplo, supongamos que tenemos este método C y lo llamamos vía JNI:

JNIEXPORT void JNICALL Java_MemoryCorruptor_corruptMemory() { while (1) { char *p = randomAddress(); *p = randomChar(); } }

Si la VM sólo carga los archivos .so y el código nativo se ejecuta en el mismo espacio de contexto / dirección que la VM, entonces supongo que la máquina virtual podría corromperse.

Por otro lado, si la VM crea un proceso hijo para contener los archivos .so y utiliza algún tipo de IPC para llamar a métodos, entonces el código Java no puede corromperse por el código nativo.

El código nativo se ejecuta en el mismo proceso que el código Java con el que interactúa a través de JNI, por lo que sí, es muy capaz de corromper las estructuras de datos clave. La mayoría de las veces se puede ver esto como un accidente dentro de la biblioteca de la aplicación de la propia máquina virtual, poco después de la vuelta de mal comportamiento código nativo, pero en teoría otro hilo podría mal funcionamiento.

En la medida en que existe un aislamiento entre código nativo y alojado en VM del mismo proceso, es simplemente que la información necesaria para modificar de manera útil y segura las estructuras de datos de implementación sólo está disponible en un grado limitado bajo ciertas llamadas de soporte de JNI. todos expuestos a los ojos vendados empujando, si su código nativo hace eso. Por supuesto también es posible que su código se bloquee el proceso mediante el intento de un acceso ilegal en sí. Dependiendo de los detalles de la implementación de VM, algunos de los "códigos" de la aplicación pueden estar en páginas de memoria de sólo lectura, y el intentar escribir en ellos causaría un fallo de protección de memoria. Sin embargo, los datos, y cualquier JIT "compilado sobre la marcha" el código presumiblemente estará en una páginas escritura. Y el código activamente nefasto puede cambiar la configuración de protección, intercambiando asignaciones respaldadas por archivos de solo lectura para páginas anónimas escritas con el mismo contenido si es necesario.

Es posible ejecutar componentes de una aplicación de Android en un proceso distinto, pero que tendrá su propia VM envolviendo cualquier código JNI que utilice allí – clases como Actividad y Servicio son fundamentalmente de nivel Java, incluso si se utiliza el código JNI cola de Java para hacer el trabajo en una versión nativa. Algunas aplicaciones de navegador web, por ejemplo, pueden hacer esto, para poner un poco más de aislamiento en torno a sus motores de intérprete javascript.

También ha sido posible (hasta la fecha) poner en marcha un proceso autónomo de sólo nativos y hablar con él a través de IPC, sin embargo esto no es alentado, ya que faltará los ganchos de ciclo de vida para la gestión de Android, y hay algunas partes difíciles de la misma usted tendrá que lograrse. Además, dicho programa no puede utilizar la mayoría de las API de plataforma Android definidas por Java, o al menos no de una manera portátil. Históricamente la gente ha recurrido a esto principalmente cuando se usa un shim de raíz "su" en un dispositivo hackeado para iniciar un proceso auxiliar que se ejecuta como superusuario o, ocasionalmente, como una vía para portar una complicada herramienta de estilo Linux sin volver a diseñarla como un Biblioteca de JNI.