Пытаюсь установить ключ шифрования на привод 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 есть ошибка, которая вызывает сбой, если вы используете --detail на чистой ленте. Я пытался связаться с автором, чтобы исправить это, но не могу связаться с ним.
Кажется, что этот сбой оставляет диск в несогласованном состоянии, когда он отказывается принимать дальнейшие ключи. Исправляем ошибку и запускаем stenc --detail без сбоев, похоже, решил проблему. Теперь я могу устанавливать любые ключи любое количество раз, и больше никаких проблем не возникало.
Если у кого-то такая же проблема, в stenc-1.0.7/sec/scsiencrypt.cpp в строке 176 говорится delete status;. Вам нужно добавить новую строку прямо под этим, которая гласит 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=Software%20and%20Utilities