기준선

기준선

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/tmpfilechacha_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은 무작위 데이터와 같으며 쓰기 전에 스크램블되기 때문입니다. 그러나 물론 스크램블링 시퀀스는 본질적으로 알려져 있으므로 실제로 이전 쓰기에서 일부 잔류 자화가 있는 경우 다음을 수행할 수 있습니다.할 수 있다어떤 의미에서 이는 이전 데이터에 대한 추가 정보를 포함합니다. 다시 말하지만, 이것은 오늘날 물리학과 관련된 공격이 아닙니다.

관련 정보