Compilare il modulo kernel Linux (2.6) includendo le intestazioni non kernel

Question

È possibile compilare un modulo kernel Linux (2.6) che include funzionalità definite da include non kernel?

Ad esempio:

---

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

Il modulo del kernel che ho scritto e che sto provando a compilare contiene funzionalità trovate in numerosi file include openssl.

Il makefile standard presentato sopra non consente di includere al di fuori delle intestazioni di Linux. È possibile includere questa funzionalità e, in tal caso, potrebbe indicarmi la giusta direzione.

Grazie, Mike

Answer 1

Il kernel non può usare il codice userspace e deve essere autonomo (cioè essere completamente autonomo, senza librerie), quindi non raccoglie le intestazioni standard.

Non è chiaro quale sia il vantaggio nel provare a raccogliere le intestazioni dello spazio utente. Se ci sono elementi che potrebbero essere validi da usare (costanti, alcune macro forse a condizione che non chiamino alcuna funzione dello spazio utente), allora potrebbe essere meglio duplicarli e includere solo le parti compatibili con il kernel di cui hai bisogno.

Non è possibile collegare il kernel con le librerie progettate per l'uso dello spazio utente - anche se non effettuano chiamate al sistema operativo - perché l'ambiente di collegamento nel kernel non può rilevarle.

Invece, ricompila tutte le funzioni da usare nel kernel (supponendo che non effettuino chiamate al sistema operativo o alla libreria - ad esempio malloc - nel qual caso dovranno comunque essere modificate). Incorporali nella tua libreria per usarli nei tuoi moduli del kernel.

---

Le versioni recenti di Linux contengono comunque funzioni crittografiche, inclusi vari hash SHA - forse puoi usare una di quelle invece.

---

Un'altra idea sarebbe quella di smettere di provare a fare crittografia nello spazio kernel e spostare il codice nello spazio utenti. Il codice dello spazio utente è più facile da scrivere / eseguire il debug / mantenere ecc.

Answer 2

Ho preso parti del codice di userspace che ho scritto e convertito per funzionare nello spazio del kernel (cioè usando kmalloc (), ecc.), non è poi così difficile. Tuttavia, sei limitato alla comprensione del kernel di C, non di spazio utente, che differisce leggermente .. specialmente con vari tipi int standard.

Il semplice collegamento con lo spazio utente di DSO non è possibile & # 8212; il kernel di Linux è monolitico, completamente autonomo. Non utilizza userspace libc, librerie o altri bit come altri hanno notato.

9/10 volte, troverai quello che ti serve da qualche parte nel kernel. È molto probabile che qualcun altro si sia imbattuto nella stessa esigenza che hai avuto e abbia scritto alcune funzioni statiche in alcuni moduli per fare quello che vuoi .. basta afferrare quelli e riutilizzarli.

Nel caso di crypto, come altri hanno già detto, usa semplicemente ciò che è nel kernel. Una cosa da notare, avrai bisogno che siano abilitati in kconfig che può o meno accadere a seconda di ciò che l'utente seleziona quando lo costruisce. Quindi, fai attenzione alle dipendenze e sii esplicito, potresti dover hackerare alcune voci in kconfig che selezionano anche l'API di crittografia che desideri quando il modulo è selezionato. Farlo può essere un po 'doloroso quando si costruisce dall'albero.

Quindi da un lato abbiamo " basta copiare e rinominare le cose mentre aggiungiamo il bloat complessivo " ;, dall'altro hai " dire alle persone che devono avere il sorgente completo del kernel " ;. È una delle stranezze fornite con un kernel monolitico.

Con un Microkernel, quasi tutto gira nello spazio utente, nessun problema di collegamento con un DSO per alcuni driver ... non è un problema. Per favore, non prendere questa affermazione come spunto per riavviare la filosofia di progettazione del kernel nei commenti, non rientra nell'ambito di questa domanda.