sfill -Illv
/dev/urandom
파티션을 채울 때까지 데이터가 포함된 파일을 만듭니다 . 이렇게 큰 파일을 만들려면 시간이 많이 걸립니다. iotop
쓰기 속도는 약 1MB/s라고 합니다.
그러나 dd if=/dev/urandom >> ./randomfile
동일한 작업을 수행하지만 약 12MB/s입니다. 왜?sfill
훨씬 느린가요?
편집: 저는 Debian 11 stable을 사용하고 있습니다. 12MB/s의 데이터가 기계식 하드 드라이브의 ntfs 파티션에 기록되고 있습니다. Ext4 형식의 다른 두 HD를 시도했고 dd를 사용하여 약 100MB/s를 얻었습니다. sfill
그러나 이러한 디스크의 성능은 여전히 좋지 않습니다.
답변1
기준선
sfill
얼마나 느린지 알고 싶어서 벤치마킹했습니다.
나는 신뢰하지 않기 때문에 sfill
(소스 코드를 읽었는데,국제 난독화 C 코드 대회(무언가를 안전하게 수행할 수 있다고 신뢰하는 잘 작성된 시스템 소프트웨어보다 낫습니다.) 적어도 가상 머신에서 실행하여 격리했습니다. 그곳에서 1GB 루프백 탑재 XFS를 사용하여 Podman을 통해 OCI 컨테이너에서 실행했습니다. 볼륨 이미지:
mkfs.xfs fsimage.xfs
udisksctl loop-setup -f fsimage.xfs
# I get a mountpoint automatically here
sudo mkdir /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test
sudo chown testuser:testuser /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test
podman run podman run --pull newer --rm -it -v /run/media/testuser/a02ab05f-8c6f-41ed-bd28-dc81ca7df1a1/test:/data:Z debian:11
나는 그것을 설치 apt install secure-delete
하고 실행했다 sfill -Illv /data
. 시스템에서 실행 htop
한 결과 11~12MB/s의 쓰기 속도가 관찰되었습니다. 따라서 약 4개 계층의 간접 참조를 사용하면 시스템보다 12배 빠릅니다.
왜 느린가요 sfill -Illv
?
sfill
방금 소스 코드를 읽었습니다 (git repo에 체크인된 아카이브 링크;한숨...git의 바이너리 파일. 보안 담당자는 일반적으로 훌륭한 소프트웨어 엔지니어가 아닙니다. 그러나 이는 모든 당사자에게 불필요하게 고통스러운 일입니다.)
이 소프트웨어는 지난 20년 동안 사랑을 받지 못했고, 솔직히 20년 전에는 매우 불결했습니다. 그래서 그것은 즐거운 읽기가 아닙니다.
어쨌든 핵심은 sfill
파일을 열고 데이터로 채운 다음 삭제하는 것입니다.
따라서 기본적으로 O_SYNC
불특정 이유로 –를 사용하여 파일을 엽니다. 이는 끔찍한 성능을 보장하며, 마지막에 단순히 디스크에 플러시하지 않을 이유가 전혀 없습니다.
-f
동기식 쓰기를 비활성화하려면 옵션에 하나를 추가하세요 . 제 경우에는 쓰기 속도가 약 130MB/s로 빨라졌습니다.
비교해 보면 cat /dev/urandom > /data/tmpfile
이는 거의 500MB/s입니다. 1GB 쓰기 버퍼는 그다지 많은 RAM이 아니기 때문에 이는 예상된 것입니다.
주문하다 | 속도 | 측정 대비 속도 향상 |
---|---|---|
sfill -Illv /data |
12MB/초 | 12 |
sfill -Illvf /data |
130MB/초 | 130 |
cat /dev/urandom > /data/tmpfile |
~ 500MB/초 | ~500 |
이를 읽어보면 실제로 CPU에 약간의 병목 현상이 발생하기 시작한 것, 즉 내 커널의 urandom(반유사) RNG의 일부가 실제로 나타나고 있다는 perf top
것이 분명합니다 .cat /dev/urandom > /data/tmpfile
chacha_permute
따라서 동기 쓰기는 여전히 성능 저하를 완전히 설명하지 못하므로 나머지를 무작위 비트를 생성하는 극도로 비효율적인 방식으로 비난해야 합니까 *buf++ = (unsigned char) (256.0*rand()/(RAND_MAX+1.0))
? 이것은 부동 소수점 연산을 수행하는 데 불필요할 뿐만 아니라 좋은 무작위성을 제공하지도 않습니다. 현대 GNU/Linux 시스템에서는 RAND_MAX
정확히 2^3이므로 31비트의 OK 무작위성을 얻은 다음 심하게 깨졌습니다. 그리고 8비트의 잘못된 무작위성을 얻었습니다...
교훈을 얻으세요
- 20년 된 소프트웨어도 성능을 발휘할 것이라고 기대하지 마십시오
- 보안연구원 커뮤니티에서 소프트웨어 광고를 볼 때마다 소프트웨어의 품질에 주목하세요.
- 때로는 더 간단한 해결책이 더 나은 해결책입니다. 사용 가능한 디스크 공간이 모두 소진될 때까지 무작위로 채워진 파일을 작성합니다.안 돼요특별한 프로그램이 필요합니다
sfill
. 임의의 데이터를 생성하고 디스크가 가득 차서 실패할 때까지 파일에 파이프한 다음 삭제하는 모든 작업은 동일한 작업을 수행합니다. - Gutmann USENIX의 기사는 논란의 여지가 전혀 없습니다. 비교적 일반적인 합의는 최신 스토리지 및 파일 시스템에서는 본질적으로 잘못된 트리를 짖는다는 것입니다. 최신 하드 드라이브는 물리학의 한계에 매우 가깝기 때문에 이전에 작성된 내용과 양자 이론에서 허용하는 측정을 통해 이론적으로 정확하게 읽을 수 있는 내용 사이의 상호 정보가 너무 낮아서 많은 작업을 수행할 수 없습니다. 따라서 임의의 데이터로 덮어쓸 필요성이 의심스럽습니다.
기술적으로 말하자면, 1980년 이후의 모든 하드 드라이브에는 소위스크램블러, 이는 0(또는 1)의 긴 행을 쓰는 것이 일정한 신호를 발생시키지 않도록 쓰기 헤드로 들어가는 기호를 준비합니다. 따라서 자기 매체의 물리학에서 "비밀" 데이터를 임의의 비트로 덮어쓰는 것은 불가능합니다. 0으로 덮는 것보다 낫습니다. 덮어쓰기는 더 무작위입니다. 왜냐하면 0은 무작위 데이터와 같으며 쓰기 전에 스크램블되기 때문입니다. 그러나 물론 스크램블링 시퀀스는 본질적으로 알려져 있으므로 실제로 이전 쓰기에서 일부 잔류 자화가 있는 경우 다음을 수행할 수 있습니다.할 수 있다어떤 의미에서 이는 이전 데이터에 대한 추가 정보를 포함합니다. 다시 말하지만, 이것은 오늘날 물리학과 관련된 공격이 아닙니다.