mprotect a nivel del kernel

Depende de lo que quieras decir con "proceso del kernel".

En Linux, cada proceso tiene su propio espacio de direcciones, que se encarga de la MMU y su tabla de configuración. En términos generales, en cualquier momento, la MMU está configurada para encontrar información sobre las páginas (donde cada página del espacio de direcciones está en la RAM, si está presente, y los derechos de acceso) en tablas ubicadas en alguna dirección en la RAM física (Los detalles varían según la arquitectura, pero para x86 de 32 bits se usa el registro CR3). Cuando la CPU cambia de un proceso a otro, cambia la configuración (es decir, antes de otorgar el control a cualquier proceso, la CPU carga el registro CR3 con el valor correcto para el proceso de que ). mprotect() es la API que proporciona el kernel a las aplicaciones (junto con mmap() ) para modificar estas tablas. Es importante tener en cuenta que la asignación es de muchos a uno: cada página en el espacio de direcciones se asigna a una página física (o a "ninguna"), pero varias páginas en el espacio de direcciones pueden apuntar a la misma página física, con derechos de acceso que deben ser iguales.

Esto significa que si un proceso usa mprotect() , entonces modifica su propio conjunto de tablas MMU, y los otros procesos no se ven afectados. Si un proceso altera los derechos de acceso a PROT_NONE para una página que ve, y algún otro proceso también ve la misma página física en su propio espacio de direcciones (a través de alguna configuración de memoria compartida), entonces el segundo proceso aún puede acceder a la página.

Tenga en cuenta que cuando un proceso realiza una llamada al sistema, la CPU salta al espacio del kernel y obtiene privilegios de nivel del kernel, pero la MMU no se ve afectada (bueno, de hecho puede serlo, dependiendo de la arquitectura y la versión del kernel; normalmente, cada página se asigna dos veces, con una asignación accesible solo con privilegios del kernel, de modo que el kernel puede escribir en la RAM, que es, desde el punto de vista del proceso, ausente o de solo lectura; sin embargo, las cosas pueden volverse un poco es más complejo en x86 de 32 bits porque la asignación doble implica una restricción a un máximo de 2 GB de espacio de direcciones por proceso, y los núcleos recientes tienen algunos trucos para ir a 4 GB por proceso, básicamente cambiando las asignaciones de MMU al ingresar al núcleo; No confundamos más la situación con tales detalles). Por lo tanto, el código para la llamada al sistema se ejecuta con la asignación como lo ve el proceso de llamada (aunque con privilegios del kernel).

Los subprocesos del núcleo , a veces conocidos como procesos del núcleo, son algo diferente. Estos son procesos sin RAM. Se ejecutan con privilegios de nivel de kernel y ocupan un espacio en el programador, pero no tienen un espacio de direcciones propio. Al ser hilos, a veces se les otorga la CPU (ese es el punto). Sin embargo, dado que no tienen un espacio de direcciones, no incurren en un cambio de tabla MMU cuando se activan, lo cual es una bendición porque los cambios de tabla MMU son caros (debido a las descargas de TLB). Por lo tanto, los hilos del núcleo básicamente se ejecutan en el espacio de direcciones de cualquier proceso normal que se ejecutó por última vez.

Si un subproceso del núcleo hace un mprotect() en una página, suponiendo que esto funcione (el núcleo de Linux puede tener salvaguardas aquí, no lo he intentado), entonces modificará el espacio de direcciones actual, el de el desafortunado proceso que se ejecutó en último lugar, y cuál es el proceso, no se puede predecir de manera confiable. Si esto afecta a otro proceso del núcleo depende de si ese otro proceso utilizará el mismo espacio de direcciones o no, algo que puede cambiar en cada cambio de contexto, cientos de veces por segundo.

Además, los subprocesos del kernel se ejecutan con privilegios del kernel, lo que significa que pueden hacer más que las aplicaciones normales. Tienden a leer páginas PROT_NONE , siempre que lo hagan a través de la dirección correcta (de nuevo, depende de la arquitectura y la versión del kernel, pero los subprocesos del núcleo normalmente podrán ver todas las páginas con derechos de acceso total para ellos).

Resumen: si el kernel lo permite, parece muy poco prudente jugar con la memoria RAM de la zona del usuario de los hilos del kernel.

Los procesos del kernel son parte del kernel y no se pueden crear ni lanzar desde el espacio del usuario. Por lo general, estos se crean como demonio para ejecutarse periódicamente o bajo ciertas condiciones para realizar ciertas actividades.