Как использовать atos для правильного обозначения адресов из OSReportWithBacktrace?

Я пытаюсь найти утечки в проекте с открытым исходным кодом для поддержки трекпадов на основе I2C (https://github.com/kprinssu/VoodooI2CHID).

Причина, по которой я считаю, что сохраняются утечки, заключается в том, что когда я пытаюсь выгрузить расширение ядра с помощью следующих команд:

sudo kextunload -verbose 6 VoodooI2CHID.kext

Я получаю следующий вывод:

Kext user-space log filter changed from 0xff2 to 0xfff.
Kext kernel-space log filter changed from 0xff2 to 0xfff.
Kext library architecture set to x86_64.
Requesting unload of com.alexandred.VoodooI2CHID (with termnation of IOServices).
(kernel) User-space log flags changed from 0x0 to 0xfff.
(kernel) Received 'Unload' request from user space.
(kernel) Rescheduling scan for unused kexts in 60 seconds.
(kernel) Can't unload kext com.alexandred.VoodooI2CHID; classes have instances:
(kernel)     Kext com.alexandred.VoodooI2CHID class VoodooI2CPrecisionTouchpadHIDEventDriver has 1 instance.
(kernel)     Kext com.alexandred.VoodooI2CHID class VoodooI2CMultitouchHIDEventDriver has 1 instance.
Kernel error handling kext request - (libkern/kext) kext is in use or retained (cannot unload).
Failed to unload com.alexandred.VoodooI2CHID - (libkern/kext) kext is in use or retained (cannot unload).

Я наткнулся на отличный ответ pmdj об отслеживании утечек сохранения (Не удается выгрузить расширение ядра ; Классы имеют экземпляры). Я проверил, что моя ситуация является вторым случаем через ioreg (классы завершаются, но не освобождаются должным образом). Кроме того, я использовал подсказку pmdj, переопределив taggedRelease и taggedRetain (https://stackoverflow.com/a/13471512/48660) для печати трассировки стека вызовов функций.

Вот где я сталкиваюсь с проблемами, я не могу использовать atos для преобразования шестнадцатеричных адресов обратно в удобочитаемые символы. Я использую следующую команду для создания символов:

atos -arch x86_x64 -o VoodooI2C.kext/Contents/MacOS/VoodooI2C -l 0xffffff7f8432b000 0xffffff804588dfa0

Параметр адреса загрузки извлекается из kextstat, и я ожидаю, что аргумент -l должен обрабатывать арифметику слайдов.

atos должен возвращать допустимый символ, но все, что я получаю, это шестнадцатеричный адрес. В приведенном выше примере я получаю 0xffffff804588dfa0 в качестве вывода. Может ли кто-нибудь указать, что именно мне не хватает?


macos kernel darwin kernel-extension xnu
person kprinssu    schedule 17.06.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

И kextstat, и OSReportWithBacktrace сообщают о непропущенных адресах, так что KASLR не ваша проблема.

Обратите внимание, что ваш kext, по-видимому, загружен по адресу 0xffffff7f8432b000, тогда как адрес вашего кадра обратной трассировки — 0xffffff804588dfa0. Это довольно далеко друг от друга, и действительно, кексты всегда загружаются в диапазоне 0xffffff7f8??????? (нескользящий), поэтому 0xffffff804588dfa0 не может быть рядом с кодом кекста. (смещение составляет около 3 ГБ) Это почти наверняка функция в самом ядре. Если вы используете atos с соответствующим работающим двоичным файлом ядра, он сможет определить, какой из них. Например:

atos -o /Library/Developer/KDKs/KDK_10.14.5_18F132.kdk/System/Library/Kernels/kernel 0xffffff804588dfa0

(Я не знаю, какую версию ядра вы используете, и этот адрес, кажется, не имеет смысла в ядре 18F132, но вы поняли идею.)

person pmdj    schedule 17.06.2019
comment
Хотя адрес, который мне дали, был неверным. Адреса из OSReportWithBacktrace действительно исходят от ядра. Наконец-то я вижу ожидаемые символы, спасибо! Кроме того, чтобы помочь кому-либо еще с похожей проблемой, используйте kextstat, чтобы проверить, находится ли адрес ниже или выше первого и последнего загруженного диапазона адресов. Это значительно помогло мне найти, на какой двоичный файл указать atos. - person kprinssu; 18.06.2019