Вопросы Теги

I/O-overhead dm-шифруемого-устройства?

Если я понимаю правильно, что Вы пытаетесь сделать, Вы помещающий это sudo команда в сценарий и ожидание, что сценарий запрашивает Ваш пароль, когда это работает туда? В этом случае Вы просто делаете вещи сложный путь.

Более чистое решение состоит в том, чтобы записать сценарий обычным способом (т.е. без sudo) и выполненный это как суперпользователь. Причина позади этого, если для сценария нужен доступ суперпользователя, то просто предоставляют ему доступ (почему ожидают до определенной команды?). В сценарии чтобы проверить, выполняется ли это, поскольку корень делает что-то вроде этого:

if [ "$(id -u)" != "0" ]; then
    echo "This script must be run as root" 1>&2
    exit 1
fi

10
23.10.2010, 15:45
2 ответа

Нет никакого I/O-overhead, вовлеченного в dm-склеп - просто ЦП наверху... ;)

На Athlon 64 двухъядерная система на 2,6 ГГц, например, я могу скопировать от одного диска dm-склепа до другого с ~ 40 МБ/с (2.6.26 Ядер, Seagate 1,5 ТБ диски SATA).

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

$ lsmod | grep aes
aes_x86_64             12416  6 
aes_generic            32552  1 aes_x86_64

Относительно безопасности данных нет никакой потребности отключить кэш записи из-за dm-склепа. Старые версии не поддерживали барьеры записи, но с 2010 (ядро приблизительно 2.6.31), dm-склеп действительно поддерживает их (соответственно доступ единицы силы - FUA).

Btw, можно утверждать, что он не делает действительно имеет смысл шифровать корневой раздел.

Однако шифрование подкачки действительно имеет смысл.

12
27.01.2020, 20:02
  • 1
    Можно было бы утверждать также, что бездельничание с hdparm, когда Вы не знаете то, что Вы делаете (или только думают, что Вы знаете) может повредить Ваши жесткие диски. –  amphetamachine 25.02.2012, 01:30
  • 2
    Шифрование корневого раздела имеет смысл, если Ваша модель угрозы включает возможность противника, получающего временный физический доступ и загружающегося в однопользовательском режиме или от Карты памяти и устанавливающего вредоносное программное обеспечение, такое как клавиатурный перехватчик или руткит. Для обычных пользователей это также означает не иметь необходимость волноваться об упущении зашифровать /tmp (если это не смонтировано с 'tmpfs), и любые другие каталоги, которые могли бы пропустить частные данные. –  Anthony G - justice for Monica 11.10.2016, 13:30
  • 3
    @AnthonyGeoghegan, это, возможно, эффективно против некоторых противников. Но защищать от модели угрозы Вы описываете Вас, также должны защитить загрузчик (например, со встроенным микропрограммным обеспечением, которое криптографически проверяет загрузчик прежде, чем выполнить его). –  maxschlepzig 11.10.2016, 22:01
  • 4
    @maxschlepzig, Который очень мысль произошла со мной, поскольку я записал комментарий ранее, но я не хотел идти за борт с правовыми оговорками и provisos в маленьком поле комментария. Вторая причина, вероятно, более важна: Я использую FDE (на моем 10-летнем ноутбуке), таким образом, я не должен волноваться (так же) об учетных данных и закрытых ключах в /etc или некоторые другие уязвимые данные, так или иначе зарегистрированные к /var/ (upvoted, BTW). –  Anthony G - justice for Monica 12.10.2016, 00:05

Ext4 может быть плохим выбором файловой системы, если Вы - планирование выполнения снимков LVM. Я советовал бы делать существенную производительность диска, проверяющую перед вводом в эксплуатацию, experiementing с размерами блока и на FS и на LVM. Мой опыт был с Ext3, но другие статьи, я видел, в то время, когда подразумевается, что Ext4 имел проблемы средства моделирования.

Я решил его при помощи XFS как файловая система.

0
27.01.2020, 20:02

Теги

Похожие вопросы