В этой части хотел бы поделится опытом создания файловой системы OMFS3 для ОС Systemicus. Главная цель ее создания — надежное шифрование данных.
Предыдущие части:
Первое публичное выступление RTOS Systemicus
Systemicus ча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
Ругайте) т.к. сам хочу довести ее до ума. Формат контейнера стабильный, а программку можно доделывать.
Автор: omegicus
