It’s Not As Simple As “Use A Memory Safe Language"

Rust는 정말 안전한가요?

C++는 정말 그렇게 안전하지 않을까요?

유튜브에 흥미로운 주제로 발표된 내용이 있어서 가져와 봤습니다.
제목을 번역하자면 "메모리 안전 언어를 사용 하란 말은 그렇게 간단한 문제가 아니다" 이런 뉘앙스로 들리네요.
발표자는 한쪽에 치우치지 않는 비교적 공정한 입장에서 자신의 생각을 말하고 있습니다.

• Rust는 패닉을 통해 메모리 안전하지 않은 코드 실행을 방지하지만, "안전하지 않은 Rust"는 이러한 보호 기능을 우회할 수 있습니다.
• 하지만 unsafe Rust는 명시적 옵트인이 필요하므로 안전하지 않은 C/C++보다 더 눈에 띄게 됩니다. 해당 부분을 집중적으로 검토할수 있습니다
• 약 30%의 Rust 크레이트가 안전하지 않은 코드를 사용하며, 임베디드 시스템에서는 두 배 더 많이 사용됩니다.
• Sanitizer(동적 분석 도구)는 Rust와 C/C++ 코드 모두에서 메모리 오류를 감지할 수 있습니다.
• Rust 개발자의 70%가 C/C++ 라이브러리에 대한 FFI(외부 함수 인터페이스)를 통해 안전하지 않은 코드를 호출합니다.
• Rust 프로젝트에서도 사용되는 많은 중요한 라이브러리는 C/C++로 작성됩니다(SQLite, OPCUA 라이브러리).
• Sanitizers는 소스 코드가 있는 경우 LLVM IR 계층에서 Rust와 C/C++ 코드를 모두 분석할 수 있습니다.
• Miri는 중간 수준 표현에서 Rust의 정의되지 않은 동작을 감지하기 위한 보완 도구입니다.
• Miri의 장점: 명확한 오류를 제공하고 모든 정의되지 않은 동작을 동시에 확인합니다. 제한 사항: C/C++ 코드를 해석할 수 없습니다.
• Rust 표준 라이브러리 함수의 약 20%가 안전하지 않은 코드를 사용합니다.
• 중요한 인프라에는 메모리 안전 코드뿐만 아니라 재산 피해나 생명 위협을 방지하기 위한 올바른 코드가 필요합니다.
• 안전한 Rust 프로그램조차도 오작동하거나 서비스 거부 공격에 취약할 수 있습니다.
• 속성 테스트는 경계 사례를 찾기 위해 무작위 입력을 생성하여 도움이 될 수 있지만, 불가능한 오류로 어려움을 겪습니다.
• Kani는 수학을 사용하여 제약 조건 내에서 프로그램의 정확성을 확인하는 모델 검사기입니다.
• Kani의 장점: 제약 조건 내의 모든 입력을 수학적으로 평가합니다. 제한 사항: 루프를 풀어야 하며 동시성이나 C/C++ FFI를 지원하지 않습니다.
• Rust에 대한 결론: rust는 안전하지만 생각만큼 안전하지는 않습니다.
• Bjarne Stroustrup은 C와 C++를 구분하며 C++가 더 안전한 코드를 위해 설계되었다고 언급합니다.
• C++ Core Guidelines는 형식 안전, 바운드 안전 및 수명 안전에 대한 프로필을 제공하여 Rust의 보장에 접근합니다.
• C++의 가장 큰 문제는 기본적으로 안전하지 않은 코드를 작성하기가 너무 쉽다는 것입니다. 개발자들이 노력하지 않는 것은 아닙니다.