Что могло вызвать «ошибку восприятия» 'при настройке шифрования LTO?

Я пытаюсь установить ключ шифрования на привод LTO-4 под Linux. Я успешно сделал это один раз, выключил и снова включил питание привода, и теперь я не могу заставить привод снова принять ключ.

Я использую следующую команду:

$ 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.

Привод HP, поэтому мне нужно использовать -a 1 , однако разные значения не меняют результат. Использование / dev / sg1 вместо этого имеет ту же проблему.

Лента - LTO-4, поэтому поддерживается шифрование:

$ 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

Я запустил HP Tape & Library Tools и провел тест шифрования с тем же самым лента, и он прошел, поэтому кажется, что у накопителя есть возможность установить ключи, но по какой-то причине не с помощью программы stenc .

Я нашел руководство по SCSI, в котором говорится, что ASC 0x26 - это «недопустимое поле в список параметров ", который на самом деле мало что объясняет.

Кто-нибудь еще видел эту ошибку раньше или есть идеи, как заставить привод принять ключ?

4
задан 22 July 2017 в 06:32
4 ответа

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

В stenc 1.0 есть ошибка.7, что вызывает сбой, если вы используете - деталь на пустой ленте. Я попытался связаться с автором с исправлением, но не могу связаться с ним.

Похоже, что этот сбой оставляет диск в несогласованном состоянии, когда он отказывается принимать дополнительные ключи. Исправление ошибки и последующий запуск stenc --detail без сбоев, похоже, устранили проблему. Теперь я могу устанавливать любые ключи любое количество раз, и больше никаких проблем не возникало.

Если у кого-то такая же проблема, в stenc-1.0.7 / sec / scsiencrypt.cpp в строке 176 говорится о статусе удаления , . Вам нужно добавить новую строку непосредственно под этим, которая читает status = NULL; . Это устраняет ошибку двойного освобождения, вызывающую сбой.

--- 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);
6
ответ дан 3 December 2019 в 02:32

Начиная с CentOS 7.3 или 7.4 (работает 7.2), я обнаружил еще одну ошибку Illegal Request, которая случайно появляется при попытке включить шифрование.

Я выяснил, что некоторые резервные биты в команде SCSI являются неправильно инициализирован. При установке #define DEBUGSCSI можно увидеть, что эти биты меняются при каждом вызове.

Добавьте следующий memset () в scsiencrypt.cpp , чтобы исправить это :

SCSIWriteEncryptOptions():

...

  SSP_KAD kad;

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

  kad.type=0x00;
3
ответ дан 3 December 2019 в 02:32

Я потратил день на отладку, почему наш накопитель Quantum LTO7 HH продолжал выдавать ошибку Sense, когда мы настраивали на нем шифрование с использованием полностью пропатченного stenc 1.0.7, независимо от параметры, используемые при загрузке.

Наконец, мы выяснили, что в нашем случае это потому, что мы устанавливаем дескриптор ключа при генерации ключа - генерация ключа с помощью stenc -g 256 -k test.key -kd TESTKEY , а затем его загрузка с помощью stenc -f / dev / nst0 -e on -k test.key -a 1 завершится ошибкой, а stenc -g 256 -k test.key , то загрузка с использованием той же команды будет успешной. Надеюсь, это кому-нибудь поможет!

2
ответ дан 3 December 2019 в 02:32

Я решил немного другую ошибку stenc на диске IBM SCSI LTO-4, обновив прошивку. Вроде заводская прошивка вообще не поддерживала шифрование.

Моя ошибка была:

Status for /dev/nst0
--------------------------------------------------
Device Mfg:              IBM     
Product ID:              ULTRIUM-TD4     
Product Revision:        74H6
Sense Code:              Illegal Request (0x05)
 ASC:                    0x24
 ASCQ:                   0x00

Прошивки находятся за платным доступом на сайте IBM, но вы можете найти их на FTP-сервере IBM, немного покопавшись (они недостаточно общедоступны, чтобы я мог подумать, что могу ссылаться напрямую ) или на сайте Lenovo здесь: https://datacentersupport.lenovo.com/gb/en/products/storage/tape-and-backup/ts3200/6173/downloads/driver-list/component?name= Программное обеспечение% 20and% 20Утилиты

1
ответ дан 8 March 2020 в 14:13

Теги

Похожие вопросы