Qu'est-ce qui pourrait provoquer une "erreur de détection" lors de la configuration du cryptage LTO ?

Solution 1 :

Comme d'habitude, des heures de dépannage ne signifient rien, mais poster une question sur un forum public révèle immédiatement le problème.

Il y a un bogue dans stenc 1.0.7 qui provoque un plantage si vous utilisez --detail sur une bande vierge. J'ai essayé de contacter l'auteur avec un correctif, mais je n'arrive pas à le joindre.

Il semble que ce crash laisse le lecteur dans un état incohérent, où il refuse d'accepter d'autres clés. Corriger le bogue puis exécuter stenc --detail sans plantage semble avoir résolu le problème. Je peux maintenant définir n'importe quelle touche autant de fois que je le souhaite et il n'y a plus eu de problèmes.

Si quelqu'un d'autre a le même problème, en stenc-1.0.7/sec/scsiencrypt.cpp à la ligne 176, il est écrit delete status; . Vous devez ajouter une nouvelle ligne directement en dessous qui lit status=NULL; . Cela corrige une erreur double-free provoquant le plantage.

--- 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);

Solution 2 :

À partir de CentOS 7.3 ou 7.4 (7.2 fonctionne), j'ai rencontré une autre erreur de demande illégale qui apparaît de manière aléatoire lorsque j'essaie d'activer le chiffrement.

J'ai compris que certains bits de réserve dans la commande SCSI ne sont pas correctement initialisés. Lors du réglage de #define DEBUGSCSI on peut voir que ces bits varient à chaque appel.

Ajoutez le memset() suivant en scsiencrypt.cpp pour y remédier :

SCSIWriteEncryptOptions():

...

  SSP_KAD kad;

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

  kad.type=0x00;

Solution 3 :

J'ai passé une journée à déboguer pourquoi notre lecteur Quantum LTO7 HH continuait à donner une erreur de détection lorsque nous configurions le chiffrement dessus à l'aide d'un stenc entièrement corrigé 1.0.7, quelles que soient les options utilisées lors de son téléchargement.

Enfin, nous avons compris que dans notre cas, c'est parce que nous avons défini un descripteur de clé lors de la génération de la clé - générant une clé à l'aide de stenc -g 256 -k test.key -kd TESTKEY puis en le téléchargeant en utilisant stenc -f /dev/nst0 -e on -k test.key -a 1 échouerait, alors que stenc -g 256 -k test.key puis le téléchargement à l'aide de la même commande réussirait. J'espère que cela aidera quelqu'un !