Не знам защо моята OS X kext с по-нисък резултат от сондата се съпоставя

Опитвам се избирателно да скринирам и деактивирам определени USB устройства. За тази цел написах IOUSBInterface драйвер, който указва заместващи знаци за idProduct, idVendor и bcdDevice. Всеки път, когато не искам да деактивирам дадено устройство, задавам probeScore на 0 и се връщам.

Подходът probeScore работи в почти всички случаи и мога да видя как драйверът ми разглежда всяко USB устройство на свой ред в system.log. Но в случая на Bluetooth USB хост контролера, ядрото прикачва моя драйвер към него въпреки резултата ми от сондата 0. За сравнение, ако моят драйвер не присъства, Bluetooth USB хост контролерът съвпада с резултат от сондата от 90 000.

Вярно е, че драйверът ми посочва OSBundleRequired като Root, но Bluetooth USB хост контролерът посочва OSBundleRequired като Safe Boot, което изглежда ги поставя на една и съща основа. От друга страна, имам същите проблеми с Bluetooth на Yosemite като другите и моята Bluetooth мишка не реагира, докато не вляза, което предполага, че Bluetooth USB хост контролерът може да не се зарежда до момента на зареждане.


macos bluetooth kernel-extension iokit
person Neil Steiner    schedule 30.09.2015    source източник
comment
Имам активиран FileVault 2 на машината, което може да повлияе на това, което се вижда, преди да отключа устройството си. Когато стартирам в режим на един потребител и се опитвам изрично да заредя /System /Library/Extensions/IOBluetoothFamily.kext/Contents/PlutIns/BroadcomBluetoothHostControllerUSBTransport.kext, получавам грешка при невалиден подпис, въпреки че системата няма проблем със зареждането на този драйвер, след като вляза. Може би трябва да задам този въпрос на Попитайте различно.   -  person Neil Steiner    schedule 01.10.2015
comment
Инструментът за команден ред kextcache има флаг -print-diagnostics, който може да помогне да се определи проблема.   -  person pmdj    schedule 02.10.2015
comment
@pmdj Имам малко проблеми с kextcache. Опитах sudo kextcache -system-caches -print-diagnostics -v 6 и някои други опции, но наистина не намерих това, което търсех. Каква употреба имахте предвид?   -  person Neil Steiner    schedule 05.10.2015
comment
Щеше да покаже някаква причина, поради която зареждането на вашия kext може да не работи. Явно няма такъв. Вижте отговора ми за това, което подозирам, че може да се случи.   -  person pmdj    schedule 21.10.2015

Отговори (1)


arrow_upward
1
arrow_downward

Напълно пренаписан отговор, тъй като не бях разбрал въпроса

Първо, от устата на коня:

"Имайте предвид, че никога не трябва да добавяте свое собствено свойство IOProbeScore към списъка със свойства на USB драйвер."

Вероятно затова не изпитваш много радост от резултата от сондата. (Имайте предвид, че горната препоръка се отнася само за USB устройства; пренебрегване на Thunderbolt и т.н.)

Ако модифицирането на вашия речник за съвпадение на личността, така че да не съответства на въпросното устройство, не е практично (изглежда, че искате да решите по време на изпълнение, така че това е добра причина), тогава заменете probe() метода на вашия драйвер и селективно върнете this или NULL от него в зависимост от дали искате вашият (блокиращ) драйвер да поиска устройството или не. Връщането на NULL от probe() винаги трябва да работи - ако създава проблеми, най-вероятно имате грешка в кода си някъде.

person pmdj    schedule 21.10.2015
comment
Може би тук имаме грешна комуникация? Използвам 10.10 и kext-dev-mode и проблемът ми не е, че моят kext не се зарежда, а по-скоро че улавя хардуера, който обикновено се управлява от Bluetooth USB хост контролера, дори когато аз върне отрицателен резултат от мача. Бях се опитал да върна NULL по-рано, но изпаднах в паника по пътя, така че си помислих, че може би е по-красиво да върна невероятно нисък резултат. - person Neil Steiner; 23.10.2015
comment
Аааа, добре, прав си, погрешно съм разбрал въпроса ти. Ако искате драйверът на Apple да поеме, тогава ако стесняването на вашите критерии за съвпадение не е практично, връщането на NULL от вашия заменен probe() наистина е най-добрият начин да не съвпадате. Ако това предизвиква паника, тогава имате грешка в кода си; не е присъщо за отхвърляне на сондата. IOProbeScore е известен като ненадежден за USB устройства, така че не съм много изненадан, че не изпитвате голяма радост от това. - person pmdj; 23.10.2015
comment
Добре, актуализирах отговора си до нещо, което се надявам да е полезно. Ако все още имате сривове след връщането на NULL, не се колебайте да отворите друг въпрос и аз ще направя всичко възможно да диагностицирам. :-) Съжалявам за преследването на диви гъски. - person pmdj; 23.10.2015
comment
благодаря, има смисъл. Ще се чувствам свободен свободно да връщам NULL по всяко време, когато не искам да поема устройство, и ще игнорирам грозните *::probe fails записи в system.log. И нямам IOProbeScore в моя plist, така че сме добри в това отношение. - person Neil Steiner; 23.10.2015