USB Mass Storrage на уровне файлов
Проблема: у меня есть портативное устройство Linux, которое записывает данные и сохраняет их на диске. Он должен обмениваться этими данными с приложением Windows через USB. Когда эти данные доступны пользователю - например, через USB-накопитель - они должны быть зашифрованы. Он должен работать "из коробки", с различными ОС, также для терминальных сессий Citrix и т. Д.
План: я создаю файловую систему в пространстве пользователя с помощью FUSE и предлагаю ее окнам через запоминающее устройство. Всякий раз, когда Windows обращается к одному файлу, я получаю обратный вызов и шифрую данные на лету. Более того, мы можем иметь некоторый динамический контент - например, когда какой-то пароль записывается в файл, отображается больше контента.
Проблема: при использовании гаджета запоминающего устройства (например, g_file_storage) он принимает только файлы или блочные устройства - но не файловые системы (каталоги). Зачем?
[...] он предоставляет простой интерфейс для чтения и записи секторов данных - во многом как низкоуровневый интерфейс, используемый для доступа к любому жесткому диску [...]. Операционные системы могут относиться к USB-накопителю как к жесткому диску и могут форматировать его в соответствии с любой файловой системой. (из википедии)
Таким образом, у вас нет шансов получить динамическую файловую систему через запоминающее устройство... и это, вероятно, причина, по которой мой мобильный телефон Android отключает все данные на телефоне, когда я подключаю его к ПК.
Варианты:
- Создайте " блочное устройство в пользовательском пространстве" - аналогично FUSE (нужен обратный FAT-драйвер, когда я хочу предлагать файлы динамически)
- Реализовать собственный nbd-сервер для создания блочного устройства (нужен также обратный FAT-драйвер?)
- Я сохраняю зашифрованные файлы в раздел и передаю этот раздел в гаджет-хранилище (проблема заключается в производительности и отсутствии динамического взаимодействия)
- Не предлагайте устройство массовой памяти и следите за другими идеями (даже через USB)
На данный момент только последний вариант кажется реалистичным - или у вас есть еще один совет для меня?
Буду признателен!
Charly
4 ответа
Протокол запоминающего устройства USB является протоколом блочного устройства; он не работает на уровне файлов или каталогов. Хост Windows ожидает увидеть необработанную файловую систему VFAT, предоставляемую драйвером g_mass_storage, и будет делать записи и чтения в метаданные VFAT в зависимости от ситуации, чтобы выяснить, как структурированы каталоги.
Из-за этого нетривиально предоставлять файловую систему FUSE хосту Windows. Вам придется эмулировать VFAT, назначая блоки в виртуальной файловой системе метаданным и данным, и поскольку хост Windows может свободно кэшировать любые данные или метаданные, которые он читает, после того, как вы назначите некоторые метаданные или данные, которые он не может изменить (поэтому изменяется на Ваши данные FUSE не могут быть отражены в файловой системе Windows). Хост Windows также может задерживать и переупорядочивать записи как метаданных, так и данных - все это очень сложно, если вы попытаетесь эмулировать.
Теперь есть несколько вещей, которые вы можете сделать:
- Вы можете написать собственный драйвер IFS на стороне Windows для взаимодействия с вашим устройством Linux через специальный протокол, который работает на уровне файлов / каталогов.
- Вы можете рассматривать устройство USB как виртуальный порт Ethernet и говорить CIFS с хостом Windows
- Вы можете каким-то образом создать статическую компоновку VFAT во время соединения для показа хосту Windows; еще не расшифрованные данные могут возвращать ошибки ввода-вывода, чтобы избежать кэширования необработанных зашифрованных данных на хосте Windows.
- Вы можете просто зашифровать необработанное блочное устройство с помощью dm-crypt и открыть все это блочное устройство (зашифрованное как один чанк) для окон.
- Вы могли бы реализовать гаджет MTP.
Эти подходы имеют свои проблемы:
- Требует установки драйвера для Windows, подписи Microsoft и т. Д. Нельзя использовать на машине без прав администратора для установки драйвера.
- Не будет автозапуска; пользователь должен будет просматривать браузер сети, чтобы получить доступ к файлам. Настройки брандмауэра могут мешать. Может иметь значительные накладные расходы.
- Очень сложный. Обработка обновлений метаданных на сервере может быть чрезвычайно сложной. События неожиданного отключения могут быть разрушительными. Поведение Windows при получении ошибки ввода-вывода может быть проблемой, если пользователь пытается получить доступ к заблокированному файлу.
- Шифрование на уровне файлов недоступно, но в остальном должно работать хорошо.
- Я не уверен точно, сколько поддержки немедиа файлов, которые имеет MTP; поддержка не так широко распространена, как поддержка массовых хранилищ.
Возможно, вам будет интересно узнать, что Android, который ранее выставлял себя в качестве запоминающего устройства USB для хоста, вместо этого действует как устройство MTP (как у Honeycomb).
При этом кто-то уже реализовал ваш вариант 1, хотя "устройство" и "хост" немного поменялись местами. В QEMU есть безумный хак, называемый vvfat, который может создать поддельное блочное устройство, которое для виртуальной машины выглядит так, как будто оно содержит файловый элемент VFAT только из дерева каталогов / файлов на хосте. Он требует полной рекурсивной проверки перед запуском, зависит от деталей того, как операционные системы пишут в файловые системы, и падает, если вы самостоятельно изменяете какие-либо файлы во время их использования, но (каким-то образом) удается (иногда) работать.
Может быть возможно преобразовать протокол NBD в USB, и usb "bit-bang", чтобы появиться на USB-хосте как запоминающее устройство USB.
- Хранение NBD и USB msas являются устройствами блочного уровня, поэтому может быть возможно преобразовать один протокол в другой. Однако это почти наверняка потребует программирования, так как я не думаю, что оно существует. Тем не менее, http://travisgoodspeed.blogspot.com/2012/07/emulating-usb-devices-with-python.html выглядит довольно полезным для стороны USB, а https://bitbucket.org/hirofuchi/xnbd/wiki/Home должен дать вам хороший пример для клиента NBD.
- Использование VFAT означает, что Windows может видеть его как обычный USB-накопитель без драйверов.
- как предположил другой автор, модуль qemu vvfat может быть использован для автоматизации некоторых из них.
- Шифрование трафика потребовало бы туннелирования трафика NBD через SSH или OpenVPN.
Окончательная настройка будет выглядеть примерно так:
+---------------------------------+ +------------------+
| data collection device | | client device |
| +----------------+ | | |
| | collected data | | | SSH -> NBD |
| | -> linux fs | | | client |
| +--+-------------+--------+ | | | |
| -> | qemu vvfat | SSH +-{some network}-+ V |--> client PC
| | run NBD inside the VM| | | USB Mass Storage | USB port
+----+----------------------+-----+ +------------------+
Рассматривая варианты, я рассмотрел бы использование ethernet-гаджета и автоконфигурирование IP на устройстве, а затем запуск Samba для экспорта файловой системы на хост Windows. Это даст вам необходимый вам уровень контроля.