O que poderia causar um 'erro de detecção' ao configurar a criptografia LTO?

Question

Estou tentando definir uma chave de criptografia em um drive LTO-4 no Linux. Eu fiz isso com sucesso uma vez, desliguei a unidade e agora não consigo fazer com que a unidade aceite a chave novamente.

O comando que estou usando é o seguinte:

$ stenc -f /dev/nst0 -a 1 -e on -k test.key
Provided key length is 256 bits.
Key checksum is 7a43.
Turning on encryption on device '/dev/nst0'...
Sense Code:              Illegal Request (0x05)
 ASC:                    0x26
 ASCQ:                   0x00
 Additional data:        0x00000000000000000000000000000000
Error: Turning encryption on for '/dev/nst0' failed!
Usage: stenc --version | -g <length> -k <file> [-kd <description>] | -f <device> [--detail] [-e <on/mixed/rawread/off> [-k <file>] [-kd <description>] [-a <index>] [--protect | --unprotect] [--ckod] ]
Type 'man stenc' for more information.

A unidade é HP, portanto, preciso usar -a 1 , mas valores diferentes não alteram o resultado. Usar /dev/sg1 tem o mesmo problema.

A fita é LTO-4 para que a criptografia seja suportada:

$ mt-st -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Eu corri o HP Tape & Library Tools e fez um teste de criptografia com essa mesma fita e ela passou, então a unidade parece ser capaz de ter as chaves configuradas, não apenas através do programa stenc por algum motivo.

Eu encontrei um manual do SCSI que dizia que o ASC 0x26 é "Campo inválido na lista de parâmetros", o que não explica muito.

Alguém mais viu este erro antes ou tem alguma ideia de como fazer com que o disco aceite a chave?

    

Answer 1

Como de costume, horas de solução de problemas não significam nada, mas postar uma pergunta em um fórum público revela imediatamente o problema.

Há um bug no stenc 1.0.7 que causa uma falha se você usar --detail em uma fita em branco. Eu tentei entrar em contato com o autor com uma correção, mas não consigo pegá-lo.

Parece que essa falha deixa a unidade em um estado inconsistente, onde ela se recusa a aceitar outras chaves. Corrigir o erro e, em seguida, executar stenc --detail sem falha parece ter corrigido o problema. Agora posso definir qualquer tecla quantas vezes quiser e não houve mais problemas.

Se alguém mais estiver tendo o mesmo problema, em stenc-1.0.7/sec/scsiencrypt.cpp na linha 176 ele diz delete status; . Você precisa adicionar uma nova linha diretamente abaixo disso e ler status=NULL; . Isso corrige um erro duplo-livre causando a falha.

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

    

Answer 2

Começando com o CentOS 7.3 ou 7.4 (7.2 obras), encontrei outro erro de solicitação ilegal que aparece aleatoriamente ao tentar ativar a criptografia.

Eu descobri que alguns bits de reserva no comando SCSI não são inicializados corretamente. Ao definir #define DEBUGSCSI , pode-se ver que esses bits variam em cada chamada.

Adicione o seguinte memset() em scsiencrypt.cpp para corrigir:

SCSIWriteEncryptOptions():

...

  SSP_KAD kad;

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

  kad.type=0x00;

    

Answer 3

Passei um dia depurando por que nossa unidade Quantum LTO7 HH continuava dando um erro Sense quando estávamos configurando a criptografia usando um stenc 1.0.7 totalmente corrigido, independentemente das opções usadas ao fazer o upload.

Finalmente, descobrimos que, no nosso caso, é porque definimos um Descritor de chave ao gerar a chave - gerar uma chave usando stenc -g 256 -k test.key -kd TESTKEY e, em seguida, fazer o upload usando stenc -f /dev/nst0 -e on -k test.key -a 1 , enquanto stenc -g 256 -k test.key envia usando o mesmo comando teria sucesso. Espero que isso ajude alguém!