Я пытаюсь установить ключ шифрования на привод 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 - это «недопустимое поле в список параметров ", который на самом деле мало что объясняет.
Кто-нибудь еще видел эту ошибку раньше или есть идеи, как заставить привод принять ключ?
Как обычно, часы поиска и устранения неисправностей ничего не значат, но размещение вопроса на публичном форуме немедленно обнаруживает проблему.
В 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);
Начиная с 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;
Я потратил день на отладку, почему наш накопитель 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
, то загрузка с использованием той же команды будет успешной. Надеюсь, это кому-нибудь поможет!
Я решил немного другую ошибку 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Утилиты