Некоторые функции-члены kext должны быть переопределены, чтобы избежать неразрешенных символов
TL; DR
Подкласс — это переопределение (переопределение) виртуальной функции суперкласса (базовый класс). в рамках суперкласс, потому что динамический загрузчик этого требует. Это не имеет никакого смысла для меня.
Пример:
class IO80211Controller : public IOEthernetController
{
virtual IOReturn enablePacketTimestamping(); // Implemented in binary, I can see the disassembly.
};
// .cpp - Redefinition with superclass namespace.
IOReturn IO80211Controller::enablePacketTimestamping()
{
return kIOReturnUnsupported; // This is from the disassembly of IO80211Controller
}
Выше не настоящий заголовок, я надеюсь, что он близок к тому, что должен быть — заголовок недоступен.
// .hpp
class AirPortBrcm4331 : public IO80211Controller
{
// Subclass stuff goes here
};
// .cpp - Redefinition with superclass namespace.
IOReturn IO80211Controller::enablePacketTimestamping()
{
return kIOReturnUnsupported; // This is from the disassembly of AirPortBrcm4331
}
Фон
Я исследую IO80211Family.kext (для которых нет доступных заголовков), и IO80211Controller в частности, класс — я нахожусь в процессе изменения заголовка, чтобы можно было наследовать от этого класса и создавать собственные драйверы 802.11.
Обнаружение проблемы
IO80211Controller определяет много виртуальных функций-членов, которые мне нужно объявить в моем обратном заголовочном файле. Я создал заголовочный файл со всеми виртуальными функциями (извлеченный из таблицы IO80211Controller) и использовал его для моего подкласса.
При загрузке моего нового kext (с подклассом) были ошибки связывания:
kxld [com.osxkernel.MyWirelessDriver]: следующие символы не разрешены для этого kext: kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: enableFeature (IO80211FeatureCode, void *) kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: flowIdSupported () kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: apple80211_ioctl (IO80211Interface *, __ifnet *, длинная без знака, недействительная *) kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: enablePacketTimestamping () kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: hardwareOutputQueueDepth (IO80211Interface *) kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: disablePacketTimestamping () kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: executeCountryCodeOperation (IO80211Interface *, IO80211CountryCodeOp) kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: requireExplicitMBufRelease () kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: _ RESERVEDIO80211Controllerless7 () kxld [com.osxkernel.MyWirelessDriver]: IO80211Controller :: stopDMA () Ссылка не удалась (код ошибки 5).
Обратный заголовок суперкласса содержит более 50 виртуальных функций-членов, поэтому, если бы возникли какие-либо проблемы со связыванием, я бы предположил, что это будет «все или ничего». При добавлении простой реализации к этим функциям (с использованием пространства имен суперкласса) ошибки компоновки исчезают.
Возникают два вопроса
- Как могут сосуществовать несколько реализаций одних и тех же функций? Они оба живут в адресном пространстве ядра.
- Что делает эти конкретные функции такие особенные, в то время как остальные 50 в порядке без странного повторного спроса?
гипотеза
Я не могу ответить на первый вопрос, но я начал исследование о втором.
Я посмотрел в IO80211Family таблица символов mach-o, и все функции с ошибкой компоновки не содержат N_EXT бит в их поле типа — это означает, что они не являются внешними символами, в то время как другие функции содержат N_EXT немного.
Я не был уверен, как это влияет на процедуру загрузки kext, поэтому я погрузился в исходный код XNU и искал код загрузки kext. Здесь есть крупный игрок, называемый vtable patching, который может пролить свет на мой первый вопрос.
Во всяком случае, есть функция предиката под названием kxld_sym_is_unresolved который проверяет, является ли символ неразрешенным. kxld вызывает эту функцию для всех символов, чтобы убедиться, что они все в порядке.
boolean_t
kxld_sym_is_unresolved(const KXLDSym *sym)
{
return ((kxld_sym_is_undefined(sym) && !kxld_sym_is_replaced(sym)) ||
kxld_sym_is_indirect(sym) || kxld_sym_is_common(sym));
}
Этот результат функции в моем случае сводится к возвращаемому значению kxld_sym_is_replaced, который просто проверяет, был ли исправлен символ (vtable patching), я недостаточно хорошо понимаю, что это такое и как это влияет на меня …
Великий вопрос
Почему Apple выбрала эти функции, чтобы не быть внешними? они подразумевают, что они должны быть реализованы другими — и другими, почему такая же область, как у суперкласса? Я прыгнул в источник, чтобы найти ответ на этот вопрос, но не нашел. Это то, что больше всего беспокоит меня — это не следует моей логике. Я понимаю, что полный исчерпывающий ответ, вероятно, слишком сложен, поэтому, по крайней мере, помогите мне понять, на более высоком уровне, что здесь происходит, в чем логика того, чтобы подкласс не получал реализацию этих конкретных функций таким странным образом (почему не чисто абстрактный)?
Большое спасибо за чтение этого!
Решение
Непосредственное объяснение действительно заключается в том, что символы не экспортируются с помощью kext IO80211. Однако вероятная причина этого заключается в том, что функции реализованы встроенными, например, так:
class IO80211Controller : public IOEthernetController
{
//...
virtual IOReturn enablePacketTimestamping()
{
return kIOReturnUnsupported;
}
//...
};
Например, если я строю этот код:
#include <cstdio>
class MyClass
{
public:
virtual void InlineVirtual() { printf("MyClass::InlineVirtual\n"); }
virtual void RegularVirtual();
};
void MyClass::RegularVirtual()
{
printf("MyClass::RegularVirtual\n");
}
int main()
{
MyClass a;
a.InlineVirtual();
a.RegularVirtual();
}
используя команду
clang++ -std=gnu++14 inline-virtual.cpp -o inline-virtual
а затем проверить символы с помощью nm:
$ nm ./inline-virtual
0000000100000f10 t __ZN7MyClass13InlineVirtualEv
0000000100000e90 T __ZN7MyClass14RegularVirtualEv
0000000100000ef0 t __ZN7MyClassC1Ev
0000000100000f40 t __ZN7MyClassC2Ev
0000000100001038 S __ZTI7MyClass
0000000100000faf S __ZTS7MyClass
0000000100001018 S __ZTV7MyClass
U __ZTVN10__cxxabiv117__class_type_infoE
0000000100000000 T __mh_execute_header
0000000100000ec0 T _main
U _printf
U dyld_stub_binder
Ты это видишь MyClass::InlineVirtual имеет скрытую видимость (t), в то время как MyClass::RegularVirtual экспортируется (T). Реализация для функции, объявленной как inline (либо явно с ключевым словом, либо неявно, поместив его внутри class определение) должно быть предоставлено во всех вызывающих его единицах компиляции, поэтому имеет смысл, чтобы они не имели внешней связи.
Другие решения
Вы столкнулись с очень простым явлением: неэкспортированные символы.
$ nm /System/Library/Extensions/IO80211Family.kext/Contents/MacOS/IO80211Family | fgrep __ZN17IO80211Controller | egrep '\w{16} t'
00000000000560c6 t __ZN17IO80211Controller13enableFeatureE18IO80211FeatureCodePv
00000000000560f6 t __ZN17IO80211Controller15flowIdSupportedEv
0000000000055fd4 t __ZN17IO80211Controller16apple80211_ioctlEP16IO80211InterfaceP7__ifnetmPv
0000000000055f74 t __ZN17IO80211Controller21monitorModeSetEnabledEP16IO80211Interfacebj
0000000000056154 t __ZN17IO80211Controller24enablePacketTimestampingEv
0000000000056008 t __ZN17IO80211Controller24hardwareOutputQueueDepthEP16IO80211Interface
0000000000056160 t __ZN17IO80211Controller25disablePacketTimestampingEv
0000000000056010 t __ZN17IO80211Controller27performCountryCodeOperationEP16IO80211Interface20IO80211CountryCodeOp
00000000000560ee t __ZN17IO80211Controller27requiresExplicitMBufReleaseEv
0000000000055ffc t __ZN17IO80211Controller7stopDMAEv
0000000000057452 t __ZN17IO80211Controller9MetaClassD0Ev
0000000000057448 t __ZN17IO80211Controller9MetaClassD1Ev
За исключением двух деструкторов MetaClass, единственным отличием в вашем списке ошибок компоновки является monitorModeSetEnabled (есть ли шанс, что вы переопределите это?).
Теперь в моей системе есть только один класс расширения IO80211Controller, который AirPort_BrcmNIC, реализованный com.apple.driver.AirPort.BrcmNIC, Итак, давайте посмотрим, как это обрабатывает:
$ nm /System/Library/Extensions/AirPortBrcmNIC-MFG.kext/Contents/MacOS/AirPortBrcmNIC-MFG | egrep '13enableFeatureE18IO80211FeatureCodePv|15flowIdSupportedEv|16apple80211_ioctlEP16IO80211InterfaceP7__ifnetmPv|21monitorModeSetEnabledEP16IO80211Interfacebj|24enablePacketTimestampingEv|24hardwareOutputQueueDepthEP16IO80211Interface|25disablePacketTimestampingEv|27performCountryCodeOperationEP16IO80211Interface20IO80211CountryCodeOp|27requiresExplicitMBufReleaseEv|7stopDMAEv'
0000000000046150 t __ZN17IO80211Controller15flowIdSupportedEv
0000000000046120 t __ZN17IO80211Controller16apple80211_ioctlEP16IO80211InterfaceP7__ifnetmPv
0000000000046160 t __ZN17IO80211Controller24enablePacketTimestampingEv
0000000000046170 t __ZN17IO80211Controller25disablePacketTimestampingEv
0000000000046140 t __ZN17IO80211Controller27requiresExplicitMBufReleaseEv
000000000003e880 T __ZN19AirPort_BrcmNIC_MFG13enableFeatureE18IO80211FeatureCodePv
0000000000025b10 T __ZN19AirPort_BrcmNIC_MFG21monitorModeSetEnabledEP16IO80211Interfacebj
0000000000025d20 T __ZN19AirPort_BrcmNIC_MFG24hardwareOutputQueueDepthEP16IO80211Interface
0000000000038cf0 T __ZN19AirPort_BrcmNIC_MFG27performCountryCodeOperationEP16IO80211Interface20IO80211CountryCodeOp
000000000003e7d0 T __ZN19AirPort_BrcmNIC_MFG7stopDMAEv
Итак, одна группа методов, которые они переопределили, а остальные … они повторно реализованы локально. Запустив дизассемблер, мы видим, что это на самом деле просто заглушки:
;-- IO80211Controller::apple80211_ioctl(IO80211Interface*,__ifnet*,unsignedlong,void*):
;-- method.IO80211Controller.apple80211_ioctl_IO80211Interface____ifnet__unsignedlong_void:
0x00046120 55 push rbp
0x00046121 4889e5 mov rbp, rsp
0x00046124 4d89c1 mov r9, r8
0x00046127 4989c8 mov r8, rcx
0x0004612a 4889d1 mov rcx, rdx
0x0004612d 488b17 mov rdx, qword [rdi]
0x00046130 488b82900c00. mov rax, qword [rdx + 0xc90]
0x00046137 31d2 xor edx, edx
0x00046139 5d pop rbp
0x0004613a ffe0 jmp rax
0x0004613c 0f1f4000 nop dword [rax]
;-- IO80211Controller::requiresExplicitMBufRelease():
;-- method.IO80211Controller.requiresExplicitMBufRelease:
0x00046140 55 push rbp
0x00046141 4889e5 mov rbp, rsp
0x00046144 31c0 xor eax, eax
0x00046146 5d pop rbp
0x00046147 c3 ret
0x00046148 0f1f84000000. nop dword [rax + rax]
;-- IO80211Controller::flowIdSupported():
;-- method.IO80211Controller.flowIdSupported:
0x00046150 55 push rbp
0x00046151 4889e5 mov rbp, rsp
0x00046154 31c0 xor eax, eax
0x00046156 5d pop rbp
0x00046157 c3 ret
0x00046158 0f1f84000000. nop dword [rax + rax]
;-- IO80211Controller::enablePacketTimestamping():
;-- method.IO80211Controller.enablePacketTimestamping:
0x00046160 55 push rbp
0x00046161 4889e5 mov rbp, rsp
0x00046164 b8c70200e0 mov eax, 0xe00002c7
0x00046169 5d pop rbp
0x0004616a c3 ret
0x0004616b 0f1f440000 nop dword [rax + rax]
;-- IO80211Controller::disablePacketTimestamping():
;-- method.IO80211Controller.disablePacketTimestamping:
0x00046170 55 push rbp
0x00046171 4889e5 mov rbp, rsp
0x00046174 b8c70200e0 mov eax, 0xe00002c7
0x00046179 5d pop rbp
0x0004617a c3 ret
0x0004617b 0f1f440000 nop dword [rax + rax]
Что примерно соответствует этому:
static uint32_t IO80211Controller::apple80211_ioctl(IO80211Interface *intf, __ifnet *net, unsigned long some, void *whatev)
{
return this->apple80211_ioctl(intf, (IO80211VirtualInterface*)NULL, net, some, whatev);
}
static bool IO80211Controller::requiresExplicitMBufRelease()
{
return false;
}
static bool IO80211Controller::flowIdSupported()
{
return false;
}
static IOReturn IO80211Controller::enablePacketTimestamping()
{
return kIOReturnUnsupported;
}
static IOReturn IO80211Controller::disablePacketTimestamping()
{
return kIOReturnUnsupported;
}
Я не пытался скомпилировать вышесказанное, но это должно привести вас на правильный путь. 🙂