Понимание буферизации для блочных устройств Mac OS и IOFilterScheme KEXT - PullRequest
0 голосов
/ 14 января 2019

Я пытаюсь понять, как работают IOFilterScheme KEXTs, чтобы в конечном итоге разработать его самостоятельно. Я попробовал несколько примеров программ и получил базовое шифрование для работы, например, используя этот образец .

Однако, когда я добавляю операторы printf () и просматриваю журналы консоли, я вижу некоторое запутанное поведение. В частности, я почти никогда не вижу входящих вызовов read (), за исключением нескольких процессов, когда я настраиваю вещи (например, mount_hfs и fsck_hfs).

Например, если я напишу новый файл на томе (из образа смонтированного диска) из какого-либо приложения (например, vim), когда я увижу соответствующую запись () в журналах консоли, с правильным PID «ВИМ». Я вижу это и при использовании других приложений.

Однако, если я пытаюсь прочитать этот же файл из другого приложения (скажем, Sublime Text editor), файл открывается нормально, но я никогда не вижу соответствующей записи read () в журнале консоли.

Хотя я могу сказать, что пример шифрования работает, посмотрев на файл DMG, у меня есть две проблемы с поведением, которое я вижу:

1) Мне трудно понять, что происходит с точки зрения чтения и записи.

2) В конце концов я хотел бы написать KEXT, где его поведение различается в зависимости от приложения, которое выполняет чтение или запись. Для этого мне понадобится фактическое чтение () из каждого приложения, которое пытается получить доступ к файлу (по крайней мере, в первый раз, когда это приложение).

После некоторых исследований кажется, что блочные устройства в Mac OS имеют какую-то буферизацию, но я не смог найти слишком много деталей. Экспериментально я попытался выполнить эту строку в вызовах read () и write (), но это не дало эффекта

super::IOStorage::synchronize(client, 0, 0);

Если кто-нибудь скажет мне, как я могу получить больший контроль над буферизацией, чтобы я мог видеть поступающие реальные вызовы read (), это было бы здорово. Если это невозможно, возможно, мне придется написать свой драйвер шифрования на другом уровне. Тем не менее, IOFilterScheme KEXT кажется (за исключением этого момента) действительно подходящим для моего случая использования, поэтому я надеюсь, что смогу заставить его работать.

1 Ответ

0 голосов
/ 14 января 2019

Кэширование в основном происходит на уровне файлов, в Unified Buffer Cache (UBC). Сама файловая система может выполнять любое кэширование, особенно для метаданных (внутренние древовидные структуры и т. Д.). Это на много уровней выше IOKit, поэтому вы не можете влиять ни на что из драйвера IOStorage.

2) В конце концов я хотел бы написать KEXT, где его поведение различается в зависимости от приложения, которое выполняет чтение или запись. Для этого мне понадобится фактическое чтение () из каждого приложения, которое пытается получить доступ к файлу (по крайней мере, в первый раз, когда это приложение).

Попытка сделать это в блоке ввода-вывода kext, вероятно, глупая задача. Современные файловые системы - сложные звери, поэтому нельзя ожидать какого-либо соответствия 1: 1 между файловым вводом / выводом и блочным вводом / выводом. Если вы хотите детализировать уровень приложения / файла, вам нужно работать на уровне VFS, либо через собственную файловую систему, либо в зависимости от того, что именно вы пытаетесь сделать, используя kauth. Если вы не боитесь использовать API-интерфейсы, которые Apple специально не использовала (например, для внутреннего использования / обучения), вы также можете использовать API-интерфейсы kext для инфраструктуры MAC, которые дают вам больше контроля, чем kauth.

...