Respuesta corta: hará aproximadamente lo que quieras y luego nada funcionará. Usar ddestá operando a un nivel por debajo del sistema de archivos, lo que significa que las restricciones que se aplicarían allí ya no son relevantes (esto no significa que el núcleo no pueda evitar que lo haga, pero no lo hace). Parte del contenido del sistema de archivos ya está en la memoria, por ejemplo, el núcleo y el ddprograma en sí, y algunos estarán en caché. Existe la posibilidad de que si el sistema está en modo multiusuario, algunos archivos se pueden volver a escribir mientras ddestá en progreso, suponiendo que realmente hayan cambiado, y si está bajo presión de memoria, algunas páginas de allí también pueden intercambiarse (deben estar encriptados y, por lo tanto, inutilizables después del reinicio).
La mayoría de los comandos que emitiría después de esto, incluido reboot, no estarían en la caché y, por lo tanto, no funcionarían. Entonces, si está en modo de usuario único, lo hará extremadamente bien, si está en modo multiusuario, borrará la gran mayoría de los datos. Idealmente, debe hacerlo arrancado desde otro medio (incluso deteniéndose en el initrd tal vez) para que pueda estar seguro de dónde provienen todas las escrituras.
Si desea un borrado seguro, esto no hará el trabajo porque aún quedarán algunos rastros de los datos originales si simplemente lo pone a cero. Por lo general, desearía hasta tres escrituras aleatorias, lo que significaría copiar desde en /dev/urandomlugar de /dev/zero- mucho más lento pero más seguro. Algunos pueden sugerir que utilice /dev/randomcuál es el dispositivo para datos aleatorios "puros", no pseudoaleatorios, pero para este propósito, la posibilidad de que alguien logre descifrar la semilla PRNG y enmascarar con éxito los datos es esencialmente insignificante.
Si eres realmente paranoico, debes tirar el dispositivo de almacenamiento en un horno para que se desmagnetice / descargue.
