¿Qué podría causar un 'error de detección' al configurar el cifrado LTO?

Solución 1:

Como de costumbre, horas de solución de problemas no significan nada, pero publicar una pregunta en un foro público revela inmediatamente el problema.

Hay un error en stenc 1.0.7 que provoca un bloqueo si usa --detail en una cinta en blanco. He intentado ponerme en contacto con el autor con una solución, pero no puedo comunicarme con él.

Parece que este bloqueo deja la unidad en un estado inconsistente, donde se niega a aceptar más claves. Arreglando el error y luego ejecutando stenc --detail sin bloqueo parece haber solucionado el problema. Ahora puedo configurar cualquier clave cualquier cantidad de veces y no ha habido más problemas.

Si alguien más tiene el mismo problema, en stenc-1.0.7/sec/scsiencrypt.cpp en la línea 176 dice delete status; . Debe agregar una nueva línea directamente debajo de esta que diga status=NULL; . Esto soluciona un error de doble liberación que causa el bloqueo.

--- a/src/scsiencrypt.cpp
+++ b/src/scsiencrypt.cpp
@@ -174,6 +174,7 @@ SSP_NBES* SSPGetNBES(string tapeDevice,bool retry){
            if(status->nbes.encryptionStatus!=0x01)break;
            if(moves>=MAX_TAPE_READ_BLOCKS)break;
            delete status;
+           status=NULL; //double free bug fix
            if(!moveTape(tapeDevice,1,true))break;
            moves++;
            status=SSPGetNBES(tapeDevice,false);

Solución 2:

A partir de CentOS 7.3 o 7.4 (7.2 funciona), encontré otro error de solicitud ilegal que aparece aleatoriamente al intentar habilitar el cifrado.

Me di cuenta de que algunos bits de reserva en el comando SCSI no se inicializaron correctamente. Al configurar #define DEBUGSCSI se puede ver que estos bits varían en cada llamada.

Agrega el siguiente memset() en scsiencrypt.cpp para arreglarlo:

SCSIWriteEncryptOptions():

...

  SSP_KAD kad;

=> memset(&kad,0,sizeof(kad));

  kad.type=0x00;

Solución 3:

Pasé un día depurando por qué nuestra unidad Quantum LTO7 HH seguía dando un error de sentido cuando estábamos configurando el cifrado usando un stenc completamente parcheado. 1.0.7, independientemente de las opciones utilizadas al cargarlo.

Finalmente, nos dimos cuenta de que, en nuestro caso, se debe a que configuramos un descriptor de clave al generar la clave, generando una clave usando stenc -g 256 -k test.key -kd TESTKEY y luego subirlo usando stenc -f /dev/nst0 -e on -k test.key -a 1 fallaría, mientras que stenc -g 256 -k test.key entonces la carga usando el mismo comando sería exitosa. ¡Espero que esto ayude a alguien!