[배경]
저는 임베디드 Linux 플랫폼을 개발 중이고 NAND 플래시 메모리에 dm-verity를 설정하려고 합니다. 저는 cryptsetup v2.3.0(soc 공급업체 패키지의 일부)을 사용하고 있으며 이것이 첫 번째 시도입니다. 해시 트리를 성공적으로 생성하고 이를 확인했습니다. 여기서 내 veritysetupdata_device는 루트 파일 시스템 파티션(예: /dev/mtdblock8)을 참조하는 mtdblock이고 내 hash_device는 다른 파티션의 마운트 경로에 있는 파일 경로를 가리킵니다. 하지만 이 파티션은 아직 마운트되지 않았고 부팅 시퀀스 후반까지 파일을 사용할 수 없기 때문에 부팅 검증 중에 액세스할 수 있도록 해시 트리 데이터를 메모리 블록 장치에 직접 저장하는 작업을 하고 있습니다.
나는 사용해 보았습니다.동일한mtdblock은 data_device 역할을 하지만 데이터 블록 크기를 확인하기 위해 데이터 블록 수를 사용하여 계산된 해시 오프셋을 제공합니다. 현재 다른 파티션의 파일에 사용되는 hash_device로 mtdblock을 사용해 보았습니다(오프셋 포함 또는 제외). 마지막으로 빈 mtdblock을 hash_device로 사용해 보았습니다. 이것은 아무 것도 연결되지 않은 임의의 "남은" 원시 파티션일 뿐입니다. 저는 이 빈 블록을 사용하는 것을 선호합니다. 약 2MB의 공간을 낭비하고 이러한 목적으로 사용할 수 있기 때문입니다.
[질문]
가장 간단한 형태로 내 명령은 다음과 같습니다. veritysetup -v --debug format /dev/mtdblock8 /dev/mtdblockX여기서 X는 숫자입니다. 매번 일반 I/O 오류가 발생하고 --debug 로그에 "해시 장치에 다이제스트를 쓸 수 없습니다"라고 표시됩니다. 이는 verity_hash.c 파일의 실패한 fwrite에 해당합니다.비밀번호 설정. 테스트 프로그램을 사용하여 /dev/mtdblockX에 직접 쓸 수는 없지만 /dev/mtdX(캐릭터 장치mtdblock과 연결됨).하지만, veritysetup에 문자 장치를 제공하면 오류가 발생합니다! 이 도구는 문자 장치를 허용하지 않고 호환되지 않는 장치 오류 메시지와 함께 실패하며 코드에서 허용되는 유일한 장치 유형은 블록 장치와 일반 파일입니다.
if (fstat(devfd, &st) < 0)
r = -EINVAL;
else if (!S_ISBLK(st.st_mode))
r = S_ISREG(st.st_mode) ? -ENOTBLK : -EINVAL;
if (r == -EINVAL) {
log_err(cd, _("Device %s is not compatible."),
device_path(device));
close(devfd);
return r;
}
코드를 수정하고 내 플랫폼에 맞게 다시 컴파일하는 것을 고려했지만 주저했습니다. veritysetup에서 문자 장치를 허용하지 않는 이유를 이해할 수 없습니다. Linux는 mtdblock 장치에 대한 모든 종류의 쓰기를 완전히 차단하는 것으로 보이지만 mtd 장치에 대한 쓰기는 허용합니다. 나를 더욱 혼란스럽게 만드는 것은 사람들이 /dev/mtdblock 장치 data_devices 및 hash_devices를 호출하는 데 성공한 수많은 사례를 온라인에서 발견했다는 것입니다. 나는 또한 게시했다이 문제cryptsetup gitlab 문제 섹션에서.