Co to jest format pliku SO?
Plik .so zawiera dynamicznie ładowaną bibliotekę współdzieloną dla aplikacji systemów Unix i Linux. .so to plik binarny używany do zapewnienia dostępu do współdzielonego kodu i danych, z których może korzystać jeden lub więcej programów po uruchomieniu. Rozszerzenie to skrót od Shared Object, co odzwierciedla fakt, że po załadowaniu biblioteki do pamięci jej obiekty - funkcje i dane - mogą być dostępne dla wielu procesów jednocześnie. Typ MIME zarejestrowany dla plików .so to application/x-sharedlib.
Biblioteki .so są obiektami ELF (skrót od Executable and Linkable Format), standardowym formatem binarnym używanym w systemie Linux i wielu systemach uniksopodobnych dla plików wykonywalnych, skompilowanych obiektów, bibliotek współdzielonych i zrzutów pamięci (core dumps). Każdy prawidłowy plik ELF - w tym pliki .so - zaczyna się od czterobajtowej magicznej liczby \x7FELF pod offsetem 0. Struktura pliku obejmuje:
- Nagłówek ELF - definiuje architekturę, kolejność bajtów (endianness) i bitowość (32-bit lub 64-bit), a także liczbę wpisów w tablicach segmentów i sekcji,
- Tablicę nagłówków programów - opisuje segmenty pamięci używane w czasie ładowania,
- Tablicę nagłówków sekcji - opisuje poszczególne sekcje używane przez linker i debugger,
- Dane, do których odwołują się te nagłówki.
Segmenty są używane podczas wykonywania programu i mogą składać się z wielu sekcji; sekcje są używane podczas operacji linkowania. Pliki .so mogą być linkowane do programu w czasie kompilacji lub ładowane w czasie wykonywania za pomocą funkcji dlopen().
Nazwy plików .so są zgodne z konwencją, w której nazwa biblioteki jest poprzedzona prefiksem lib - na przykład biblioteka o nazwie abc będzie miała nazwę pliku libabc.so, a flaga -labc jest używana podczas linkowania z nią. Po przyrostku .so może następować numer wersji, taki jak libabc.so.3 dla pliku wersji głównej lub libabc.so.3.1.2 dla w pełni zwersjonowanej kompilacji. W praktyce libabc.so jest często tylko dowiązaniem symbolicznym wskazującym na rzeczywisty plik z wersją, a libabc.so.3 może być symlinkiem do najnowszego kompatybilnego wydania. Wersja zapisana we wpisie dynamicznym DT_SONAME jest tym, co linker czasu wykonania ld.so rejestruje i sprawdza. Niektóre niskopoziomowe biblioteki systemowe - takie jak samo ld.so - nie przestrzegają konwencji prefiksu lib.
W systemie Windows odpowiednikiem jest plik .DLL; w systemie macOS jest to plik .dylib. Statyczne alternatywy w systemie Linux są archiwizowane w plikach .a.
Bezpieczeństwo
RYZYKO: MEDIUMPlik .so to wykonywalny kod natywny, który działa wewnątrz procesu, który go ładuje, więc złośliwa biblioteka współdzielona może zrobić wszystko to, co program hosta. Rzeczywiste zagrożenia: (1) przejęcie biblioteki (library hijacking) - podstawiony plik .so umieszczony tam, gdzie ładowarka szuka najpierw, lub nadużycie LD_PRELOAD/LD_LIBRARY_PATH może wstrzyknąć kod do legalnego programu; (2) pobieranie pojedynczych plików .so z przypadkowych stron w celu naprawienia błędu - mogą one być złośliwe lub niekompatybilne z ABI i mogą uszkodzić lub narazić system. Zawsze instaluj biblioteki z podpisanych repozytoriów pakietów swojej dystrybucji. Usuwanie systemowych plików .so (w /lib, /usr/lib) może uniemożliwić uruchomienie systemu operacyjnego lub aplikacji.
Szczegóły formatu
w pigułceProgramy otwierające pliki SO
Szczegóły techniczne
specyfikacja| Typ MIME | application/x-sharedlib |
| Magiczne bajty | 7F 45 4C 46 („\x7FELF”) pod offsetem 0 - identyczne dla wszystkich plików ELF; pole e_type odróżnia obiekty współdzielone |
| Wartość ELF e_type | ET_DYN (0x0003) - odróżnia obiekt współdzielony od pliku wykonywalnego (ET_EXEC = 0x0002) lub obiektu relokowalnego (ET_REL = 0x0001) |
| Bitowość | Bajt EI_CLASS pod offsetem 4: 1 = 32-bit (Elf32), 2 = 64-bit (Elf64); oba warianty są powszechnie stosowane w systemie Linux |
| Endianness | Bajt EI_DATA pod offsetem 5: 1 = little-endian (ELFDATA2LSB), 2 = big-endian (ELFDATA2MSB); zależne od architektury |
| Kod niezależny od pozycji | Musi być skompilowany z flagą -fPIC, aby biblioteka mogła zostać zmapowana pod dowolny adres wirtualny bez konfliktów relokacji między procesami |
| Dynamiczna tablica symboli | Sekcja .dynsym eksportuje i importuje symbole widoczne w czasie wykonywania; .dynstr przechowuje odpowiadające im ciągi nazw |
| PLT / GOT | Procedure Linkage Table i Global Offset Table umożliwiają leniwe (domyślne) lub natychmiastowe (-z now) rozwiązywanie symboli w czasie ładowania |
| soname (DT_SONAME) | Kanoniczna nazwa biblioteki osadzona w sekcji dynamicznej ELF; ld.so rejestruje tę nazwę podczas linkowania programu, umożliwiając śledzenie wersji ABI niezależnie od nazwy pliku |
| Wersjonowanie symboli | Sekcje .gnu.version i .gnu.version_r pozwalają na wiele wersji symboli w jednym pliku, umożliwiając ewolucję ABI kompatybilną wstecz |
| Linker czasu wykonania | Ładowany przez ld.so / ld-linux-x86-64.so.2; ścieżka wyszukiwania kontrolowana przez LD_LIBRARY_PATH, DT_RUNPATH lub /etc/ld.so.conf + pamięć podręczną ldconfig |
| Konwencja nazewnictwa | lib<nazwa>.so[.główna[.pomocnicza.poprawka]]; libabc.so to zazwyczaj deweloperski symlink → libabc.so.3 → libabc.so.3.1.2 |
| Osadzona ścieżka wyszukiwania | Wpisy dynamiczne DT_RPATH lub DT_RUNPATH „zaszywają” ścieżki wyszukiwania bibliotek w pliku w czasie linkowania; DT_RUNPATH jest preferowany, ponieważ może być nadpisany przez LD_LIBRARY_PATH |
| Narzędzia inspekcji | readelf -a, objdump -d, nm --dynamic (binutils); ldd do listowania zależności; polecenie file identyfikuje typ ELF i architekturę |
| Wydano | ELF format 1990s (System V Release 4); .so shared libraries are core to Linux/Unix |
| Otwarty standard | Tak · bezpłatny (royalty-free) |
| Specyfikacja | refspecs.linuxfoundation.org |
Konwersje SO
Pytania i odpowiedzi społeczności
pytania użytkownikówBrak pytań - bądź pierwszą osobą, która zapyta o pliki SO.