Что такое «неопределенный ссылочный / неразрешенный внешний символ»
Я попытаюсь объяснить, что такое «неопределенный ссылочный / неразрешенный внешний символ».
note : я использую g ++ и Linux, и все примеры для него
blockquote>Например, у нас есть некоторый код
// src1.cpp void print(); static int local_var_name; // 'static' makes variable not visible for other modules int global_var_name = 123; int main() { print(); return 0; }
и
// src2.cpp extern "C" int printf (const char*, ...); extern int global_var_name; //extern int local_var_name; void print () { // printf("%d%d\n", global_var_name, local_var_name); printf("%d\n", global_var_name); }
Создание объектных файлов
$ g++ -c src1.cpp -o src1.o $ g++ -c src2.cpp -o src2.o
После фазы ассемблера у нас есть объектный файл, который содержит любые экспортируемые символы. Посмотрите на символы
$ readelf --symbols src1.o Num: Value Size Type Bind Vis Ndx Name 5: 0000000000000000 4 OBJECT LOCAL DEFAULT 4 _ZL14local_var_name # [1] 9: 0000000000000000 4 OBJECT GLOBAL DEFAULT 3 global_var_name # [2]
Я отклонил некоторые строки из вывода, потому что они не имеют значения
Итак, мы видим следующие символы для экспорта.
[1] - this is our static (local) variable (important - Bind has a type "LOCAL") [2] - this is our global variable
src2.cpp ничего не экспортирует, и мы не видели его символов
Свяжите наши объектные файлы
$ g++ src1.o src2.o -o prog
и запустите его
$ ./prog 123
Linker видит экспортированные символы и связывает их. Теперь мы пытаемся раскомментировать строки в src2.cpp, как здесь
// src2.cpp extern "C" int printf (const char*, ...); extern int global_var_name; extern int local_var_name; void print () { printf("%d%d\n", global_var_name, local_var_name); }
, и перестроить объектный файл
$ g++ -c src2.cpp -o src2.o
OK (нет ошибок), потому что мы только строим объектный файл, связь еще не завершена. Попробуйте установить ссылку
$ g++ src1.o src2.o -o prog src2.o: In function `print()': src2.cpp:(.text+0x6): undefined reference to `local_var_name' collect2: error: ld returned 1 exit status
Это произошло потому, что наше local_var_name статично, то есть оно не отображается для других модулей. Теперь глубже. Получить выход фазы перевода
$ g++ -S src1.cpp -o src1.s // src1.s look src1.s .file "src1.cpp" .local _ZL14local_var_name .comm _ZL14local_var_name,4,4 .globl global_var_name .data .align 4 .type global_var_name, @object .size global_var_name, 4 global_var_name: .long 123 .text .globl main .type main, @function main: ; assembler code, not interesting for us .LFE0: .size main, .-main .ident "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2" .section .note.GNU-stack,"",@progbits
Итак, мы видели, что для local_var_name нет метки, поэтому линкер не нашел его. Но мы хакеры :), и мы можем это исправить. Откройте src1.s в текстовом редакторе и измените
.local _ZL14local_var_name .comm _ZL14local_var_name,4,4
на
.globl local_var_name .data .align 4 .type local_var_name, @object .size local_var_name, 4 local_var_name: .long 456789
i.e. вам должно быть как ниже
.file "src1.cpp" .globl local_var_name .data .align 4 .type local_var_name, @object .size local_var_name, 4 local_var_name: .long 456789 .globl global_var_name .align 4 .type global_var_name, @object .size global_var_name, 4 global_var_name: .long 123 .text .globl main .type main, @function main: ; ...
мы изменили видимость local_var_name и установили его значение в 456789. Попробуйте построить из него объектный файл
$ g++ -c src1.s -o src2.o
ok, см.
$ readelf --symbols src1.o 8: 0000000000000000 4 OBJECT GLOBAL DEFAULT 3 local_var_name
В настоящее время local_var_name имеет привязку GLOBAL (LOCAL)
link
$ g++ src1.o src2.o -o prog
и запускает ее
$ ./prog 123456789
ok, мы взломаем его:)
Итак, в результате - «неопределенная ссылка / неразрешенная внешняя ошибка символа» происходит, когда компоновщик не может найти глобальные символы в объектных файлах.
Это на самом деле взлом, введенный в JVM еще в 1.3 или 1.4 дня
http://bugs.sun.com/view_bug.do?bug_id=4705093
http://bugs.sun.com/view_bug.do?bug_id=6202721
Основная проблема заключается в том, что в собственном JVM-коде они жестко закодированы /dev/urandom
, чтобы фактически использовать /dev/random
, чтобы попытаться обеспечить достаточную энтропию. Поскольку предполагается, что /dev/urandom
не блокируется, это имеет непреднамеренные последствия блокировки, если доступно недостаточно энтропии.
Жесткий код выглядит специально для строки /dev/urandom
, поэтому предоставляя что-то, что разрешает к тому же, но не соответствует тому, что вызывает желаемое поведение. Если вы кодируете /dev/./urandom
, вы обходите жестко закодированное сглаживание и переходите к предполагаемому источнику энтропии urandom
.
Я бы не рекомендовал использовать urandom для SSL. Ваша проблема в том, что ваша машина не обладает достаточной энтропией, а использование урбанда не решает эту проблему. Предполагая, что на Linux вы можете проверить доступную энтропию с помощью:
cat /proc/sys/kernel/random/entropy_avail
Если вы находитесь на машине с генератором случайных чисел hw, вы, скорее всего, захотите установить rngd. Вы можете проверить, имеет ли ваш процессор один из них:
cat /proc/cpuinfo
Посмотрите флаги под названием rand . Вы также можете проверить, присутствует ли файл / dev / hwrng. Возможно, у вас есть / хотите загрузить соответствующий модуль:
ls /lib/modules/*/kernel/drivers/char/hw_random
Для меня это:
sudo modprobe tpm-rng
Чтобы сделать его постоянным:
echo tpm-rng | sudo tee -a /etc/modules
Если вы оказались на Ubuntu / Debian, просто установите пакет rng-tools.
sudo aptitude install rng-tools
Если вы проверите свою энтропию до и после установки rng-tools, вы увидите значительное увеличение.
Следующая команда должна показать вам доступные источники энтропии:
sudo rngd -f -r /dev/hwrng -v
Обратите внимание, что если вам нужна более высокая безопасность, вы хотите смешивать несколько источников энтропии. Неверные rng-tools поддерживают это.