Несвопируемая память

[beldmit]

Узнал тут из переписки в криптографической рассылке о функциях mlock/munlock. Почитал man-ы. К счастью, по разным операционкам. И кажется мне, что эти функции сильно недоделаны.

То, что оно позволяет блокировать в памяти от помещения в swap всю страницу целиком, это нормально и по-другому скорее всего не делается. То, что в половине операционок может быть вызваны только из-под рута (под Линуксом не так, там можно задать количество для не-рута через ulimit начиная с ядра 2.6.9), это уже большой привет. То, что там нет встроенного счетчика, сколько раз страницу лочили, и единственный вызов munlock разблокирует страницу, залоченную трижды – уже хуже, поскольку вынуждает сотворить собственный менеджер памяти, пусть даже вырожденный, системы «залочил страницу и отдаем по кусочку, все ценное туда» – совсем уже нехорошо.

А жалко. Потому как функциональность полезная.

Update: В комменты пришел dmih и рассказал про виртуализацию и ее издержки. Да, скорее всего все эти прелести в условиях виртуализации действительно неактуальны.

Comments

[p_govorun.livejournal.com]

А зачем лочить дважды? Залочил страницу, положил ключ, потёр ключ, разлочил страницу.

[beldmit.livejournal.com]

То есть ключ грузить в память каждый раз on demand и не шифровать на разовых ключах, например? Да, но тогда проще ключ прочитать не из свопа, а оттуда, где он лежит.

[p_govorun.livejournal.com]

s/положил/создал/

Я имею в виду, что страницу можно разлочить только когда ключ на ней стёрт. А уж если он стёрт, то неважно, кто и когда просил страницу залочить.

[beldmit.livejournal.com]

Ключ существенно меньше страницы. А malloc выдает адреса откуда попало. Так что получаем необходимость своего менеджера памяти.

[p_govorun.livejournal.com]

Это будет не менеджер памяти, а менеджер ключей. То есть, кто-то должен сказать: "на этой странице больше нет секретной информации", и это явно не работа менеджера памяти.

[beldmit.livejournal.com]

Эмм. А в чем разница, если все равно этого "кого-то" программировать?

[p_govorun.livejournal.com]

Ну, менеджер памяти точно не будет забивать страницу нулями прежде чем объявить её свободной. Так что "кто-то" всё равно нужен.

[beldmit.livejournal.com]

Нужен, нужен. А нэту. Потому что, будь там счетчик, можно было бы поручить это все деструктору: и память нулями затереть, и munlock вызвать...

[gegmopo4.livejournal.com]

Не всегда память нужно затирать. Лочат не только ради безопасности, но и ради производительности.

А при работе с секретной информацией иногда нужно затирать и без освобождения. Чтобы в случае ошибки переполнения буфера не выдать предыдущий ключ.

[beldmit.livejournal.com]

Это уже детали. А то, что нельзя делать malloc/mlock/munlock/free, приводит к необходимости лишней работы дополнительной аккуратности.

[vitus_wagner]

А нехрен экономить Страница не настолько велика, чтобы ключ не стоил выделения под него целой страницы.

[beldmit.livejournal.com]

Да мне не жалко страницы для ключа. Даже для одноразового. Но как гарантировать, что malloc отдаст ровно новую страницу?

[vitus_wagner]

А ты делай mmap(MAP_ANONYMOUS).

[beldmit.livejournal.com]

Вариант. То есть остается только недоступность от обычного пользователя.

[vitus_wagner]

Которую пофиксили еще когда номер версии ядра был меньше числа e

[beldmit.livejournal.com]

Это на линуксе пофиксили.

[vitus_wagner]

У тебя еще много HP/UX-ов и Solaris-ов среди пользователей твоего софта?

[beldmit.livejournal.com]

У меня такого софта вообще нет. На FreeBSD вроде как только от рута.