Stripping librerie condivise di linux

Question

Ci è stato recentemente chiesto di spedire una versione Linux di una delle nostre librerie, in precedenza abbiamo sviluppato sotto Linux e spedito per Windows dove la distribuzione di librerie è generalmente molto più semplice. Il problema che abbiamo riscontrato è quello di rimuovere i simboli esportati solo verso quelli nell'interfaccia esposta. Ci sono tre buoni motivi per voler fare questo

• Per proteggere gli aspetti proprietari della nostra tecnologia dall'esposizione attraverso i simboli esportati.
• Per evitare che gli utenti abbiano problemi con nomi di simboli in conflitto.
• Per velocizzare il caricamento della libreria (almeno così mi è stato detto).

Prendendo un esempio semplice allora:

test.cpp

#include <cmath> 

float private_function(float f) 
{ 
    return std::abs(f); 
} 

extern "C" float public_function(float f) 
{ 
    return private_function(f); 
} 

compilato con (g ++ 4.3.2, ld 2.18.93.20081009)

g++ -shared -o libtest.so test.cpp -s 

e di ispezione delle simboli con

nm -DC libtest.so 

dà

  w _Jv_RegisterClasses 
0000047c T private_function(float) 
000004ba W std::abs(float) 
0000200c A __bss_start 
     w __cxa_finalize 
     w __gmon_start__ 
0000200c A _edata 
00002014 A _end 
00000508 T _fini 
00000358 T _init 
0000049b T public_function 

ovviamente inadeguata. Così la prossima abbiamo ridichiarare la funzione pubblica come

extern "C" float __attribute__ ((visibility ("default"))) 
    public_function(float f) 

e compilare con

g++ -shared -o libtest.so test.cpp -s -fvisibility=hidden 

che dà

  w _Jv_RegisterClasses 
0000047a W std::abs(float) 
0000200c A __bss_start 
     w __cxa_finalize 
     w __gmon_start__ 
0000200c A _edata 
00002014 A _end 
000004c8 T _fini 
00000320 T _init 
0000045b T public_function 

che è buono, se non che std :: abs è esposto. Più problematico è quando iniziamo il collegamento in altre librerie (statiche) al di fuori del nostro controllo, tutti i simboli che usiamo da quelle librerie vengono esportati. Inoltre, quando iniziare a usare contenitori STL:

#include <vector> 
struct private_struct 
{ 
    float f; 
}; 

void other_private_function() 
{ 
    std::vector<private_struct> v; 
} 

si finisce con molte esportazioni aggiuntivi dalla libreria C++

00000b30 W __gnu_cxx::new_allocator<private_struct>::deallocate(private_struct*, unsigned int) 
00000abe W __gnu_cxx::new_allocator<private_struct>::new_allocator() 
00000a90 W __gnu_cxx::new_allocator<private_struct>::~new_allocator() 
00000ac4 W std::allocator<private_struct>::allocator() 
00000a96 W std::allocator<private_struct>::~allocator() 
00000ad8 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_Vector_impl::_Vector_impl() 
00000aaa W std::_Vector_base<private_struct, std::allocator<private_struct> >::_Vector_impl::~_Vector_impl() 
00000b44 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_M_deallocate(private_struct*, unsigned int) 
00000a68 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_M_get_Tp_allocator() 
00000b08 W std::_Vector_base<private_struct, std::allocator<private_struct> >::_Vector_base() 
00000b6e W std::_Vector_base<private_struct, std::allocator<private_struct> >::~_Vector_base() 
00000b1c W std::vector<private_struct, std::allocator<private_struct> >::vector() 
00000bb2 W std::vector<private_struct, std::allocator<private_struct> >::~vector() 

NB: Con ottimizzazioni su Avrai bisogno di assicurarsi che il vettore è effettivamente utilizzato in modo che il compilatore non ottimizzi i simboli non utilizzati.

Credo che la mia collega è riuscito a costruire una soluzione ad hoc che coinvolgono file di versione e modificando le intestazioni STL che sembra funzionare, ma vorrei chiedere (!):

C'è un modo pulito rimuovere tutti i simboli non necessari (quelli che non fanno parte della funzionalità della libreria esposta) da una libreria condivisa Linux? Ho provato un sacco di opzioni per g + + e ld con scarso successo quindi preferirei le risposte che funzionano meglio di quanto si creda.

In particolare:

• Simboli (closed-source) librerie statiche non vengono esportati.
• I simboli della libreria standard non vengono esportati.
• I simboli non pubblici dai file oggetto non vengono esportati.

La nostra interfaccia è esportato C.

sono a conoscenza delle altre domande simili su SO:

• NOT sharing all classes with shared library
• How to REALLY strip a binary in MacOs
• GNU linker: alternative to --version-script to list exported symbols at the command line?

ma h ave avuto poco successo con le risposte.

Answer 1

Quindi la soluzione che abbiamo per ora è la seguente:

test.cpp

#include <cmath> 
#include <vector> 
#include <typeinfo> 

struct private_struct 
{ 
    float f; 
}; 

float private_function(float f) 
{ 
    return std::abs(f); 
} 

void other_private_function() 
{ 
    std::vector<private_struct> f(1); 
} 

extern "C" void __attribute__ ((visibility ("default"))) public_function2() 
{ 
    other_private_function(); 
} 

extern "C" float __attribute__ ((visibility ("default"))) public_function1(float f) 
{ 
    return private_function(f); 
} 

esportazioni.Versione

LIBTEST 
{ 
global: 
    public*; 
local: 
    *; 
}; 

compilato con

g++ -shared test.cpp -o libtest.so -fvisibility=hidden -fvisibility-inlines-hidden -s -Wl,--version-script=exports.version 

dà

00000000 A LIBTEST 
     w _Jv_RegisterClasses 
     U _Unwind_Resume 
     U std::__throw_bad_alloc() 
     U operator delete(void*) 
     U operator new(unsigned int) 
     w __cxa_finalize 
     w __gmon_start__ 
     U __gxx_personality_v0 
000005db T public_function1 
00000676 T public_function2 

che è abbastanza vicino a quello che stiamo cercando. Ci sono un paio di grattacapi però:

• dobbiamo garantire non usiamo il prefisso "esportato" (in questo semplice esempio "pubblico", ma ovviamente qualcosa di più utile nel nostro caso) nel codice interno.
• Molti nomi di simboli finiscono ancora nella tabella delle stringhe, che sembra essere in giù a RTTI, -fno-rtti li fa andare via nei miei test semplici, ma è una soluzione piuttosto nucleare.

Sono felice di accettare qualsiasi soluzione migliore che qualcuno si avvicini!

Answer 2

In generale, su più sistemi Linux e Unix, la risposta è che qui non c'è risposta al momento del collegamento. è abbastanza fondamentale su come funziona ld.so.

Questo porta ad alcune alternative piuttosto laboriose. Ad esempio, rinominiamo STL per vivere in _STL anziché std per evitare conflitti su AWL, e usiamo namespace alti, bassi e intermedi per mantenere i nostri simboli lontani da possibili conflitti con i simboli di altre persone.

Ecco una soluzione che non vi piacerà:

1. creare un piccolo .so solo con l'API esposta esso.
2. Aprite l'implementazione reale con dlopen e collegate con dlsym.

Fintanto che non si utilizza RTLD_GLOBAL, ora si dispone di isolamento completo se non di segretezza particolare .. -Bsymbolic potrebbe anche essere auspicabile.

Answer 3

L'utilizzo dell'attributo di visibilità predefinito e -fvisibility = hidden deve essere aumentato con -fvisibility -inlines-hidden.

Si dovrebbe anche dimenticare di provare a nascondere le esportazioni di stdlib, vedere this GCC bug per il motivo.

Inoltre, se si dispone di tutti i simboli pubblici in intestazioni specifiche, è possibile racchiuderli in #pragma GCC visibility push(default) e #pragma GCC visibility pop anziché utilizzare gli attributi. Anche se stai creando una libreria multipiattaforma, dai un'occhiata a Controlling Exported Symbols of Shared Libraries per una tecnica per unificare la tua strategia di esportazione di Windows DLL e Linux DSO.

Answer 4

Se si avvolgono la vostra parte privata in uno spazio dei nomi anonima allora né std::abs né private_function si può vedere nella tabella dei simboli:

namespace{ 
#include<cmath> 
    float private_function(float f) 
    { 
    return std::abs(f); 
    } 
} 
extern "C" float public_function(float f) 
{ 
     return private_function(f); 
} 

compilazione (g ++ 4.3.3):

g++ -shared -o libtest.so test.cpp -s

ispezione:

# nm -DC libtest.so 
     w _Jv_RegisterClasses 
0000200c A __bss_start 
     w __cxa_finalize 
     w __gmon_start__ 
0000200c A _edata 
00002014 A _end 
000004a8 T _fini 
000002f4 T _init 
00000445 T public_function 

Answer 5

Basta notare che Ulrich Drepper ha scritto un saggio sugli aspetti (tutti?) Di writing shared libraries per Linux/Unix, che copre il controllo dei simboli esportati tra molti altri argomenti.

Questo è stato molto utile per chiarire come esportare solo le funzioni su una lista bianca da una lib condivisa.