Compile el módulo linux kernel (2.6) incluyendo encabezados que no sean kernel

Question

¿Es posible compilar un módulo del kernel de Linux (2.6) que incluye la funcionalidad definida por los kernel no incluidos?

Por ejemplo:

---

kernelmodule.h

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>   // printk()
// ...
#include <openssl/sha.h>
// ...

---

Makefile

obj-m := kernelmodule.o
all:
    $(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` modules

clean:
    $(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` clean
    $(RM) Module.markers modules.order

El módulo del kernel que he escrito y estoy intentando compilar contiene la funcionalidad que se encuentra en varios archivos de inclusión de openssl.

El makefile estándar presentado anteriormente no permite incluir fuera de los encabezados de Linux. ¿Es posible incluir esta funcionalidad? Si es así, ¿podría indicarme la dirección correcta?

Gracias Mike

Answer 1

El kernel no puede usar código de espacio de usuario y debe estar solo (es decir, ser completamente autónomo, sin bibliotecas), por lo tanto, no recoge encabezados estándar.

No está claro qué beneficio es intentar recoger los encabezados del espacio de usuario. Si hay cosas allí que serían válidas de usar (constantes, algunas macros quizás siempre y cuando no llamen a ninguna función de espacio de usuario), entonces sería mejor duplicarlas e incluir solo las partes compatibles con el núcleo que necesita.

No es posible vincular el kernel con bibliotecas diseñadas para el uso del espacio de usuario, incluso si no hacen ninguna llamada al sistema operativo, porque el entorno de vinculación en el kernel no puede recogerlas.

En su lugar, vuelva a compilar las funciones que se utilizarán en el kernel (suponiendo que no realicen llamadas al sistema operativo ni a la biblioteca, por ejemplo, malloc, en cuyo caso deberán modificarse de todos modos). Incorporarlos en su propia biblioteca para ser utilizados en los módulos de su núcleo.

---

Las versiones recientes de linux contienen funciones criptográficas de todos modos, incluidos varios hashes SHA, tal vez puedas usar uno de esos en su lugar.

---

Otra idea sería dejar de intentar hacer criptografía en el espacio del kernel y mover el código al espacio del usuario. El código del espacio de usuario es más fácil de escribir / depurar / mantener, etc.

Answer 2

Tomé bits del código de espacio de usuario que escribí y lo convertí para que funcione en el espacio del kernel (es decir, utilizando kmalloc (), etc.), no es tan difícil. Sin embargo, está limitado a la comprensión del núcleo de C, no del espacio de usuario, que difiere ligeramente ... especialmente con varios tipos int estándar.

Simplemente no es posible vincular contra DSO de espacio de usuario & # 8212; El kernel de Linux es monolítico, completamente autónomo. No utiliza libc de espacio de usuario, bibliotecas u otros bits como otros han notado.

9/10 veces, encontrará lo que necesita en alguna parte en el kernel. Es muy probable que alguien más haya tenido la misma necesidad que usted y haya escrito algunas funciones estáticas en algún módulo para hacer lo que quiere ... solo agréguelas y vuelva a usarlas.

En el caso de crypto, como han dicho otros, simplemente use lo que está en el kernel. Una cosa a tener en cuenta, necesitarás que estén habilitados en kconfig, lo que puede o no suceder, dependiendo de lo que el usuario seleccione al compilarlo. Por lo tanto, tenga cuidado con las dependencias y sea explícito, es posible que tenga que piratear algunas entradas en kconfig que también seleccionen la API criptográfica que desea cuando se selecciona su módulo. Hacer eso puede ser un poco doloroso cuando se construye fuera del árbol.

Entonces, por un lado, tenemos "copiar y cambiar el nombre de las cosas mientras agregamos la hinchazón general", por otro lado, tenemos que decirle a la gente que deben tener la fuente completa del núcleo. Es una de las peculiaridades que vienen con un núcleo monolítico.

Con un Microkernel, casi todo se ejecuta en el espacio del usuario, no se preocupa vincularlo con un DSO para algún controlador ... no es un problema. Por favor, no tome esa declaración como una indicación para reiniciar la filosofía de diseño del kernel en los comentarios, eso no está dentro del alcance de esta pregunta.