Важен ли размер блока при очистке диска с нулями и нулями?

793
Emil

Я использовал
dd if=/dev/zero of=/dev/sda bs=4096
для протирания диска. Может быть блокировать угрозу безопасности или просто ускорить процесс.

Извините за мой плохой английский

1
Единственный аспект безопасности заключается в том, что если во время записи произошла ошибка записи, то остальная часть блока может быть не инициализирована. Чем больше буфер, тем больше неинициализированный блок. Если вы стираете диск перед утилизацией, вам следует искать «erase mil std»: среди утилит вы найдете `wipe` и` secure-delete`. AFH 6 лет назад 0

1 ответ на вопрос

0
Austin Hemmelgarn

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

Если это SSD, это может иметь некоторое влияние на безопасность, но вы ddвсе равно не можете безопасно стереть SSD, так что это не имеет большого значения (и если вы просто хотите обнулить все, чтобы повторно использовать SSD, просто используйте blkdiscardна нем вместо).

Тем ddне менее, это не безопасно, и это не очень высокая производительность, независимо от размера блока. Я бы предложил заглянуть в DBAN для очистки дисков. В дополнение к возможностям безопасного стирания традиционных жестких дисков, он также включает в себя быстрый режим с нулевым заполнением, который делает то же, что и вы dd, но в большинстве случаев гораздо быстрее.

Отредактируйте в ответ на вопросы о безопасности ddдля вытирания дисков

Использование ddдля очистки жесткого диска не является безопасным способом очистки диска по нескольким причинам:

  • Это не стирает перераспределенные сектора. Практически любой жесткий диск в конечном итоге перераспределяет поврежденные сектора. Как только это произойдет, вы не сможете вообще дотронуться до этих секторов, если не будете использовать какую-либо специальную прошивку или полностью обойдете дисковый контроллер (что требует пайки и много тайных знаний о конкретном диске). Это означает, что даже если вы заполните каждый доступный байт информации нулевыми байтами, любые поврежденные сектора будут по-прежнему содержать данные, которые они сделали, когда их перераспределили (и в большинстве случаев большая часть этих данных подлежит восстановлению). Это на самом деле относится и к стиранию с помощью других нефизических методов, и поэтому, если на вашем диске есть перераспределенные сектора, и вам необходимо убедиться, что он очищен, вам нужно использовать неэлектронные средства для этого.
  • Перезапись сектора на магнитном носителе не полностью удаляет все следы предыдущих данных. Эти следы не могут быть доступны через обычный интерфейс диска, но хорошо финансируемый злоумышленник может использовать атомно-силовой микроскоп, чтобы наблюдать эти следы.

    Чтобы провести аналогию, представьте, что вы пишете карандашом на толстой бумаге. После того, как вы оторвете верхний лист, впечатления от записи на этом листе все еще будут слабо присутствовать на следующих нескольких листах и ​​могут быть восстановлены с использованием любого из нескольких достаточно простых средств.

    Вот почему все основные коммерческие продукты для очистки дисков выполняют несколько проходов с использованием разных шаблонов. Каждый последующий проход ослабляет следы исходных данных, делая их все труднее и труднее восстанавливать.

Это еще хуже для SSD, хотя у них нет второй проблемы, перечисленной выше, потому что есть множество других вещей, которые могут вам помешать:

  • Большинство современных твердотельных накопителей используют отображение блоков при копировании при записи. Это означает, что когда вы пишете в определенное место, как это видно из ОС, вы фактически не перезаписываете данные, уже находящиеся в этом месте, вы записываете в новое физическое местоположение на носителе устройства и, возможно, копируете некоторые существующие данные из старое место.
  • Все современные твердотельные накопители, независимо от того, используют ли они сопоставление блоков с копией при записи или нет, перегружены и выполняют некоторую форму выравнивания износа. Это означает, что в любой данный момент времени вы не можете получить доступ к каждому байту флэш-памяти на устройстве и по существу вызывает те же проблемы, что и перераспределение поврежденных секторов при очистке жестких дисков.
  • Некоторые SSD используют линейное сжатие для повышения эффективности хранения. Это означает, что точные данные, записанные в каждом блоке флэш-памяти, могут отличаться от того, что вы пытаетесь записать.
  • Некоторые SSD используют встроенную дедупликацию для повышения эффективности хранения. Это означает, что любой данный блок данных, который вы записываете, может вообще не переводиться в запись чего-либо во флэш-память на устройстве.

Учитывая все это, если вы действительно заботитесь о безопасности, не пытайтесь стирать твердотельные накопители электронным способом (однако, если это SED, совместимый с TCG Opal, и вы доверяете производителю, выбирайте этот путь), и не пытайтесь стереть сильно диски в электронном виде, если они показывают какие-либо доказательства прошлых плохих секторов.

Как может DBAN быть намного быстрее при заполнении нулями, чем DD? Я очень скептически отношусь к этому заявлению. davidgo 6 лет назад 0
@davidgo `dd` должен копировать из` / dev / zero` для каждого блока, DBAN повторно использует один и тот же предварительно заполненный буфер, поэтому он должен сделать только один вызов ввода-вывода на блок по сравнению с двумя и memcpy для ` dd`. Austin Hemmelgarn 6 лет назад 0
@AustinHmmelgam - так? / dev / zero - это специальный файл, он не похож на то, как ОС читает содержимое с диска. В качестве быстрого теста, чтение 10 гигабайт из / dev / zero и запись в / dev / null с использованием dd с блоками 1k заняли 9,5 секунд на моем ноутбуке. То же самое с блоками 4k (т.е. 40 гигабайтами) заняло 11,1 секунды, а блоки 40k (то есть 400 гигабайт) заняли 37 секунд - это говорит мне о том, что чтение из / dev / zero не является значительным источником ресурсов. davidgo 6 лет назад 0
@davidgo Несмотря на то, что это специальный файл, системный вызов все еще используется, что означает, по крайней мере, два переключения контекста. Существует также вопрос обработки буфера (DBAN выделяет один буфер, заполняет его нулями, а затем повторно вызывает write с этим буфером see в качестве аргумента, в то время как `dd` должен вызывать read для каждого блока, а затем записывать для каждого блока, потому что он должен обрабатывать копирование из обычных файлов). Austin Hemmelgarn 6 лет назад 1
По какой причине вы говорите, что `dd` не безопасен? Что может быть более безопасным, чем нулевая запись на диск? Hashim 6 лет назад 0
@Hashim Обновил мой ответ, чтобы подробнее остановиться на аспектах безопасности. Austin Hemmelgarn 6 лет назад 0