Systemicus чаcть 3: OMFS3 и Liberte
В этой части хотел бы поделится опытом создания файловой системы OMFS3 для ОС Systemicus. Главная цель ее создания — надежное шифрование данных.
Предыдущие части: Первое публичное выступление RTOS SystemicusSystemicus чаcть 2: GUI
Сразу хочу отметить, почему я решил написать свою ФС, а не прикрутить, к примеру, FAT, NTFS (форкнуть код NTFS Kolibri) или ext2/3. Я хотел, чтобы изначально она была проста в реализации, при этом расширяема и безопасна.
Простота. Она заключается в отсутствии журналирования на базовом уровне. Всё устроено достаточно просто — есть большие кластеры (по 64 килобайта, т.к. malloc в OS Systemicus тоже выделяет по 64k), в одних кластерах содержится информация о файлах и вложенных каталогах, в других — собственно данные. Первый кластер зарезервирован под информацию о разделе + много места для будущих расширений (сейчас в нем используется только первые 64 байта).
Второй кластер я отвел под код ядра моей ОС. Сделано это было из-за заботы о самой системе. Во-первых, это намного сокращает код загрузчика (т.к. не нужно писать поиск файла по всей системе), во-вторых это скрывает ядро от пользователя, а значит ни он, ни пользовательская программа не смогут повредить код ядра (т.к. формально этот кластер не входит в видимое пространство файловой системы). + это никак не влияет на универсальность, 2-й кластер может быть не занят, но он всегда один и есть там код или нету — не важно.
Есть еще один системный кластер (или кластеры, если размер диска большой). Его адрес уже не фиксирован, а указан в параметрах раздела. Это байтовая карта раздела, где каждый байт указывает на то, свободен ли соответствующий кластер или нет. Почему не битовый? Так проще + по опыту знаю, что в будущем что-то может пригодится, например указывать кроме 0 и 1 еще другие состояния, например, поврежден, только для чтения и т.п. Один кластер с байтовой картой обеспечивает покрытие 65 536(кол-во записей в карте на одном кластере) * 65 536 (размер кластера) = 4 294 967 296 байт, т.е. 4-х гигабайт дискового пространства. Как по мне, вполне приемлемо.
Как организовано хранение данных. Не делал особых структур, просто в конце каждого кластера указано 2 dword’а: размер значащих данных в текущем кластере (в принципе, можно было бы обойтись и без этого значения, т.к. размер всего файла известен через его inode-запись) и адрес следующего кластера с данными текущего файла. Если адрес равен 0 — значит это последний кластер в цепочке данных. Всё просто и логично — при чтении файла мы обращаемся к диску последовательно, не переключаясь каждый раз на отдельную структуру расположения данных.
Самое вкусноеСобственно, из-за чего и писалась своя ФС. Итак, шифрование в ФС устроено на низком уровне, т.е. шифруется каждый кластер в отдельности, а не файл. Т.е. на уровне драйвера файловой системы. Шифрование происходит в 2 этапа двумя разными ключами.Для начала из пароля пользователя получаем через 256-битный вариант ГОСТ 34.11–2012 256-битный ключ (точнее пару, по одному на пароль). Первым ключом кластер шифруется алгоритмом ГОСТ 28147–89 (таблицу замен использую «тестовую», ту что ЦБ РФ использует). Вторым ключом кластер вновь шифруется, но алгоритм задается пользователем при создании самой файловой системы (форматировании) — на выбор RC4, RC6, IDEA (медленный зараза) или Blowfish-256.
ВАЖНО! Первые два кластера шифруются, читайте выше почему (для чего они используются).
Далее, отдельно предусмотрена возможность шифровать отдельный файл уже на высоком уровне, но всё-же на уровне файловой системы. Т.е. поверх этих двух шифрований, которые напомню применяются не к файлу, а к кластеру, есть возможность шифровать именно файл. Эта возможность прописана, но пока что это я не реализовал (проблема времени, а не сложности).
О расширяемостиВо-первых, главные параметры хранятся в 64-битных вариантах, т.е. проблем с размерами не будет (а учитывая, что адресация идет на посекторно, а по кластерам в 64 килобайта, то адресовать можно много :-)), равно как и с метками времени (тоже 64 бит).Осталось место для дополнительных флагов файла (доступ, права,…). Также, очень много места (см. 1-ый кластер) для других расширений.В принципе, можно в будущем реализовать журналирование, ничего противоречащего не вижу, журнал можно записывать в отдельный файл специальный или цепочку кластеров.С шифрованием тоже, вид алгоритма хранится в байтовой переменной, т.е. кроме этих 4-х, можно еще прикрутить 252 других алгоритма шифрования и хеширования)
ПлюшкаДавно хотел сделать свой аналог LeanFS GUI, т.к. компилировать раздел каждый раз вручную неудобно как-то… да и в самой ФС шифрования пока кроме ГОСТ+RC4 нету (и те временно отключены, на время разработки). Поэтому, надо писать.
Выбрал Delphi (не злитесь, не люблю C/C++, или не умею ;-)). За 2,5 дня управился, функции шифрования делал всё-таки на fasm как отдельную dll и просто прикрутил ее к моему приложению. Нужно отметить, что с Blowfish и IDEA пока происходят непонятные жуткие вещи, поэтому я их отключил в этой версии, лично мне хватает ГОСТ+RC6.Так вот, программку обозвал Liberte и по своей сути это получилась не только просмотрщик моей файловой системы, но и криптоконтейнер :-) Сам уже пользуюсь, делал ранее для себя такую штуку — Wolfram, но там было шифрование отдельных файлов и было не удобно. Теперь для моих важных данных использую Liberte.
Не сетуйте на скорость шифрования — я сам в шоке, но всё впереди.Даю ссылку на скачивание — nebka.ru/files/Liberte_0.1c. 7zНет, вот еще одна, а то в прошлой статье ругались что сервер неправильно что-то отдает: http://yadi.sk/d/1up9km3cSBPvE
Ругайте) т.к. сам хочу довести ее до ума. Формат контейнера стабильный, а программку можно доделывать.
