¿Cómo elimino los símbolos locales del módulo del kernel de Linux sin romperlo?

Question

Si hago --strip-debug o --strip-unneeded, tengo el .ko que enumera todos los nombres de funciones con nm, si solo lo hago strip foo.ko Tengo un módulo kernel que se niega a cargar.

¿Alguien sabe un atajo rápido atajo cómo quitar todos los símbolos que no son necesarios para la carga del módulo para que la gente no pueda aplicar ingeniería inversa a la API: tan fácilmente?

PD: Para todo lo que abre la fuente fanáticos misioneros; esto es algo que el público en general nunca usará en ningún caso, así que no hay necesidad de convertir la cuestión en una guerra de llama de la GPL.

Answer 1

Sin respuesta a mis preguntas anteriores, aquí hay algunas conjeturas que también podrían ser algunas pistas, y un paso para una respuesta:

De lo que recuerdo, un .ko no es más que un archivo .o resultante de la fusión de todos los archivos .o generados por su módulo fuente, y la adición de una sección .modinfo. Al final de cualquier .ko build Makefile, hay una llamada LD: por lo que recuerdo, ld se llama con la opción -r, y esto es lo que crea ese archivo .o que el archivo Makefile llama un .ko. Este archivo resultante no se debe confundir con un archivo o biblioteca de objetos (archivo .a), que es solo un formato que archiva/empaqueta múltiples archivos .o como uno: un objeto fusionado es el resultado de un enlace que produce otro .o módulo: Pero en el módulo resultante, todas las secciones que se pudieron fusionar han sido, y todos los pares públicos/externos que se pudieron resolver han estado dentro de esas secciones. así que supongo que usted termina con su archivo .ko que contiene todas las definiciones extern "locales":

• aquellos que son extern porque se utilizan para llamar a través de la .o módulos en su .ko (pero no se necesitan más ya que no son supone que se llama desde fuera la .ko), y

• los que el módulo .ko es necesario que comunicarse correctamente con el cargador y el núcleo .

Los primeros han muy probable que ya han resuelto por LD durante la fusión, pero ld no tiene manera de saber si tiene la intención de hacer que también se puede llamar desde fuera del .ko.

Así que los símbolos extraños que ve son los que son externos para cada uno de sus archivos .o, pero no son necesarios como externos para el .ko resultante. Y lo que estás buscando es una forma de despojar solo a aquellos.

¿Este último párrafo describe correctamente los símbolos que desea eliminar?

Answer 2

no estoy seguro de entender lo que es realmente el problema: Cuando se desarrolla un .ko, si no añado explícitamente algo así como

ccflags-y += -ggdb -O0 -Wall 

en mi Makefile, no consigo ningún símbolo pero para aquellos que publico o me refiero externamente. Estoy seguro de que no entiendo cualquier otro símbolo para varias buenas razones:

• el archivo .ko resultante es considerablemente más pequeño,
• volcar el archivo y el análisis de la ELF muestra las tablas no están allí,
• No puedo ver ni acceder a los símbolos en kgdb.

Así que estoy un poco desconcertado por su pregunta, en realidad? ... ¿Cuáles son esos símbolos que ves en tu .ko (y no quieres)? ¿Cómo se declaran en su archivo fuente? ¿En qué secciones ELF terminan? Y (lo siento, pregunta tonta): ¿Definió estático todas las cosas que no necesitaban ser vistas fuera de su propio módulo?

Answer 3

I think this is exactly what we are talking about here.

Bien, entonces parece que una solución es eliminar "manualmente" los símbolos extraños. La utilidad "strip" parece permitir la eliminación individual (o el mantenimiento) de símbolos, por lo que tendría que usar un --strip-all y un pequeño grupo de --keep-symbol =. Tenga en cuenta que --wildcard también puede ayudar un poco. Puedes hacer lo opuesto, por supuesto, mantener todo y tirar individualmente, dependiendo de lo que sea más conveniente.

Un buen comienzo podría ser eliminar todos los símbolos que definió explícitamente en su módulo para la vinculación entre módulos y no desea que aparezcan, simplemente dejando los útiles obvios, como init y exit. Y para no tocar aquellos que han sido generados por/pertenecen a la infraestructura de software de desarrollo kernel. Luego prueba y error hasta que encuentres la receta correcta ... De hecho, creo que todos tus propios símbolos pueden ser extraíbles, aparte de los que explícitamente definiste como EXPORT_SYMBOL (e init/exit, por supuesto).

¡Buena suerte! :)

PS:

De hecho, parece que existe la información de origen se requiere en todos los .ko proyectos para llevar a cabo la separación requerida de forma automática: A menos que me falta algo, parece que todo lo que no está EXPORT_SYMBOL o insertada explícitamente por el software de compilación podría teóricamente ser eliminada por defecto al final del tiempo "ld -r" que termina con una compilación .ko. Es solo que no creo que la cadena de herramientas (compilador/enlazador) tenga provisiones/directivas/opciones para designar individualmente syms "quitar o mantener" para el enlace/fusión reubicable. De lo contrario, algunas modificaciones en la macro EXPORT_SYMBOL y en algunos otros lugares probablemente podrían lograr el resultado que busca, y afeitar algunos bytes de la mayoría de los archivos .ko en cualquier sistema Linux.

Answer 4

, además del puesto de filofel:

La razón pelar las bibliotecas de espacio de usuario compartida mantiene funcionando es porque sus símbolos exportados están en la sección .dynsym que nunca se despojó. .ko archivos sin embargo, no use dynsym.

Answer 5

personas han reportado éxito con

strip --strip-unneeded 

Answer 6

Acabo de construir un kernel sin darse cuenta de la configuración del núcleo habían permitido a los símbolos de depuración, por lo que el tamaño de los módulos resultantes eran bastante grandes. Esto funcionó para mí:

# du -sh /lib/modules/3.1.0/ 
1.9G /lib/modules/3.1.0/ 
# find /lib/modules/3.1.0/ -iname "*.ko" -exec strip --strip-debug {} \; 
# du -sh /lib/modules/3.1.0/ 
134M /lib/modules/3.1.0/ 

encontrar todos los archivos en /lib/modules/3.1.0 llamado *.ko y ejecutar strip --strip-debug en cada uno de ellos.

Answer 7

strip -g XXX.

Mi problema anterior como lo que sucedió es sloved por este comando en el dispositivo integrado con Linux Kernel 3.0.8.