LINUX.ORG.RU
Форум — Development  

Интегрирование page cache и прозрачного шифрования файлов


0

0 

Хотелось бы услышать предложения как бы это получше сделать.

Навскидку варианты:

1) использовать оригинальную страницу для ввода-вывода
   и в b_end_io расшифровывать поблочно(для readpage).

   Если во время b_end_io разрешены прерывания, то,
   как мне кажется, можно легко переполнить стек ядра
   (файловая система может жить на 16-64 дисках),

   если прерывания запрещены, то могут теряться прерывания,
   кроме того, поскольку шифрование тяжелое, то
   могут возникать неприятные задержки, даже если ядро
   поддерживает вытеснение

   кроме того, kmap_atomic(bh_kmap_irq) может в первом
   случае в какой-то момент не спроецировать страницу.

2) (для readpage) в b_end_io помещать буфера в очереди 
   и вне контекста прерывания их обрабатывать (расшифровывать)
   
   По-моему, это будет слишком медленно (лишнее переключение
   контекста).

3) совершать операции над страницами синхронно (readpage, 
   prepare-/commit- write), используя для ввода-вывода
   теневую страницу.

   Так я реализовал сейчас, но проблема в том, что readahead
   становится синхронным.

Как бы получить разумный компромисс между безопасностью и
производительностью?
★★

Кернел хакеру Мурру от параноика Signal11:
 SECURITY IS FAR ABOVE OTHER THINGS OUT THERE.
дословный перевод:
 СЕЦУРИТЫ ИС ФАР АБОВЕ ОТХЕР ТХИНГС ОУТ ТХЕРЕ.

то что оно будет sync это даже хорошо в некотором плане. Кстати есть
ли в линукс какой-либо общий криптографический API или каждый для
себя сам функции пишет. (я знаю еcть Cryptographic API для IPsec, но
можно ли его юзать не из IPsec кода? И еще это для нового IPsec кода
в 2.6 или FreeS/WAN его тоже использует) И еще. Есть ли возмлжность
использования в Linux crypto-акселлераторов?

Прошу прощения что загружаю Вас этими вопросами, но если ответите я
с удовольствием прочитаю... ;)

signal11 ★
()
Ответ на: комментарий от signal11

Хе-хе. Я половину твоего сообщения не понял - так кто из нас хакер?
Да и нет тут ничего мистического, просто надо понять куда засунуть расшифровку блоков, чтобы было наименее плохо.

По поводу криптографии из того, с чем я сам сталкивался:

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

Начиная с 2.6 вроде интерфейсы более-менее зафиксировались,
добавили алгоритмов ну и сам патч был залит в vanilla ядро.

Это, видимо, то самое crypto API, о котором ты говоришь(linux/crypto).

Пока в качестве симметричного алгоритма и алгоритма шифрования ключа
используется простейшая сеть Фейстеля (100% никем не запатентованная%=))

в будущем надо будет заменить на Rijndael или Blowfish; если лицензия
на алгоритмы не позволяет использовать в закрытых коммерческих продуктах, то придется оформить это дело модулем.


А чем хороша синхронность? Если эвристика mm будет лажаться, то приложение просто будет тормозить на чтении никому не нужных страниц. Можно, конечно, из модуля ковырять filp->f_ra,но хотелось бы этого избежать (опять же из соображений переносимости).

По поводу криптоускорителей - никогда таких не видел, но не думаю,
что для них сильно сложно написать драйвер. :) По крайней мере до тех пор, пока они не начнут делать что-нибудь мистическое. ;)

Murr ★★
() автор топика
Ответ на: комментарий от Murr 

> Хе-хе. Я половину твоего сообщения не понял - так кто из нас хакер?

:-)

>Начиная с 2.6 вроде интерфейсы более-менее зафиксировались,
>добавили алгоритмов ну и сам патч был залит в vanilla ядро.
>
> Это, видимо, то самое crypto API, о котором ты говоришь (linux/crypto).

Как раз про это, правдо они и в 2.4.26 есть к примеру...
На самом деле я посмотрел /usr/src/linux/Documentation/crypto/api-into.txt
и многие вопросы отпали...

Вам кстати тоже наверное следует юзать это.... Там есть и blowfish
и twofish и rijndael (aes) и дигесты всякие и HMAC есть, Так что
приписывать что-то свое смысла особого нет... Единственное -- там
документация плохая.

> ...Rijndael или Blowfish; если лицензия на алгоритмы не позволяет
> использовать в закрытых коммерческих продуктах

rijndael вообще стандарт. blowfish открыт. с лицензией здесь нет
никаких проблем.

> А чем хороша синхронность?

Давайте определимся чего с чем. Если ввода вывода страниц то это не плохо. Это уменьшает риск странице быть в памяти в небезопасном состоянии. Тем более если еще разрешены прерывания. Очередь это
хреново в плане, что системный сбой может привести к потери данных.

Но. Это мое видение. Я не kernel хакер. И тем более ядра Linux.
Решать Вам. Но я скажу одно: компромисс с безопасностью -- дело
не очень хорошее по любому (и уж тем более с данными которые хотят
скрыть).

> По поводу криптоускорителей - никогда таких не видел

Странно. Моделей много: Hifn, Broadcom, Securealink, SafeNet и
другие. Еще новые VIA cyrix (eden) умеют аппаратно AES. Вот это
супер вещь для encrpyted filesystems...

signal11 ★
()
Ответ на: комментарий от signal11 

> Вот это супер вещь для encrpyted filesystems...

Это если действительно есть какой-то cryptographic framework, где
такие девайсы могут регистрировать предоставляемые функции.

В OpenBSD это называется OpenBSD Cryptographic Framework (OCF) с
доступом в userland через /dev/crypto. Оно там есть с 2000 года...

Ну это так. К слову...

signal11 ★
()
Ответ на: комментарий от signal11

> В OpenBSD это называется OpenBSD Cryptographic Framework (OCF) с
> доступом в userland через /dev/crypto. Оно там есть с 2000 года...

в NetBSD это тоже портировали. А в OpenBSD из NetBSD обратно
портировали cgd -- как раз прозрачное шифрование на
уровне блочных устройств

dilmah ★★★★★
()
Ответ на: комментарий от signal11

signal11:

>Вам кстати тоже наверное следует юзать это.... Там есть и blowfish
>и twofish и rijndael (aes) и дигесты всякие и HMAC есть, Так что
>приписывать что-то свое смысла особого нет... Единственное -- там
>документация плохая.

Не в документации дело. Базовой платформой является RH9/RHES, с прицелом на ядро 2.6. А интерфейсы cryptoAPI успели поменяться много раз (во всяком случае в RH9 они совсем не такие как в 2.6+). Неохота заниматься оттачиванием связки crypto(во всех его несовместимых версиях) и модуля fs... куда проще вставить небольшой кусок оригинального кода, если лицензия это позволяет. :)

>rijndael вообще стандарт. blowfish открыт. с лицензией здесь нет
>никаких проблем.

С Rijndael вроде все так, а вот насчет Blowfish не уверен.
Вроде как этот самый Blowfish принадлежит конторе, в которой
работал Шрайбер и лицензия на него может быть пожестче, чем
MIT/BSD.

В общем, с юридической стороной вопроса будет разбираться отдельный
человек. Это в любом случае не моя прерогатива. :)

Вообще, в этой теме это оффтоп. :)

>Давайте определимся чего с чем. Если ввода вывода страниц то это не
>плохо. Это уменьшает риск странице быть в памяти в небезопасном
>состоянии. Тем более если еще разрешены прерывания. Очередь это
>хреново в плане, что системный сбой может привести к потери данных.
В небезопасном состоянии - это каком?

Вообще, весь страничный кэш в памяти, разумеется, в расшифрованном состоянии. Иначе mm не могла бы им воспользоваться, шифрование/расшифрование идет только во время чтения/записи (то бишь page operations).

Если у пользователя есть необходимые права, то он всегда сможет перехватить ключи другого пользователя(при передаче их ядру), прозрачно олицетворять его(например, через ptrace), ковырять кэши. Я думал делать привязки ключей к сеансам(sid), отслеживать отладку процессов и т.д., но в Linux есть слишком много обходных путей для root... Проблема в его модели безопасности. :-/ Придется смириться с тем, что root может всё.

Что касается сбоев, то все равно мы не можем гарантировать то, что на диск запишется всё в нужном порядке. Ведь, если для read/write mm вызывает page operations в "нужном" порядке, то, скажем, для отображенных в память файлов такого порядка просто нет.

Murr ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development