질문 이력: Drop Check (dropck) 알고리즘은 일반 파괴자가 이미 할당 해제된 데이터에 접근할 수 있는 초기 Rust 버전의 오류를 해결하기 위해 도입되었습니다. dropck 이전에는 스택에 할당된 데이터에 대한 참조를 보유하는 구조체를 만들고, 이를 역참조하기 위해 Drop을 구현할 수 있었으며, 참조된 데이터가 컨테이너보다 먼저 해제되어 use-after-free 문제가 발생할 수 있었습니다. 이 문제는 빌린 데이터를 포함할 수 있는 일반 컬렉션과 관련하여 파괴자 안전성을 보장하기 위한 보수적인 분석이 필요했습니다.
문제:
일반 타입 Container<T>가 Drop을 구현할 때, 컴파일러는 파괴자가 유효하지 않은 메모리에 접근하는 것을 방지하기 위해 T가 컨테이너보다 반드시 더 오래 살아야 한다는 것을 보장해야 합니다. 원시 포인터를 사용하는 타입(예: *const T)의 경우, 원시 포인터는 빌리기 검사기에 의해 추적되지 않기 때문에 컴파일러는 라이프타임 정보를 가지고 있지 않습니다. 명시적인 라이프타임 마커가 없으면, 컴파일러는 파괴자가 현재 스코프에서 먼저 해제될 수 있는 데이터에 대한 포인터를 역참조할 수 있는지 확인할 수 없습니다.
해결 방법:
PhantomData는 타입 T 또는 라이프타임 'a의 소유권 또는 빌림을 시뮬레이션하는 크기가 0인 마커로 작용합니다. 원시 포인터를 보유하는 구조체에 PhantomData<&'a T>를 포함시킴으로써 컴파일러에 이 구조체가 라이프타임 'a에 묶인 참조를 논리적으로 보유하고 있음을 알립니다. Drop Check 알고리즘은 이를 사용하여 구조체가 'a를 초과하지 못하도록 강제합니다. 구조체가 Drop을 구현하고 참조 대상을 초과할 수 있는 경우 컴파일이 실패하여 정의되지 않은 동작을 방지합니다.
바이트 버퍼를 래핑하는 제로 복사 네트워크 프로토콜 파서를 구축하고 있습니다. 네트워크 스택에서 수신된 임시 Vec<u8>에 대한 원시 포인터 *const u8를 포함하는 Packet<'a>를 정의합니다. 파싱 통계를 업데이트하기 위해 원시 포인터를 읽어서 Packet에 대해 Drop을 구현하려고 시도합니다. 위험은 Vec<u8>이 수신 함수가 종료될 때 해제되지만, Packet은 나중에 처리하기 위해 큐에 저장될 수 있어 Drop이 실행될 때 use-after-free가 발생할 수 있습니다.
우선 원시 포인터 대신 참조 &'a [u8]를 사용하는 것을 고려합니다. 이를 통해 빌리기 검사기가 버퍼의 수명이 충분히 길도록 보장합니다. 그러나, 이는 패킷을 자유롭게 이동하거나 'static 경계를 요구하는 컬렉션에 저장할 수 없게 되어 API를 엄청나게 제한합니다. 또한 파서에서 일반적인 자기 참조 패턴을 방해합니다.
두 번째로, Rc<Vec<u8>>를 사용하여 버퍼의 소유권을 공유하는 것을 고려합니다. 이는 패킷이 존재하는 한 데이터가 유효하게 유지되도록 합니다. 단점은 참조 카운팅과 힙 할당으로 인한 성능 비용으로, 이는 고속 네트워크 처리의 제로 복사 및 제로 오버헤드 요구사항을 위반합니다.
세 번째로, 성능을 위해 원시 포인터를 유지하면서 라이프타임 종속성을 표시하기 위해 PhantomData<&'a ()>를 추가하는 것을 고려합니다. 그러나 이는 Drop을 구현하는 것이 본질적으로 안전하지 않다는 것을 드러냅니다. 컴파일러는 버퍼가 패킷보다 오래 살아남는다는 보장을 할 수 없기 때문입니다. Drop 구현을 제거하고 대신 버퍼가 해제되기 전에 호출되는 수동 정리 메서드를 사용하거나 빌린 데이터와 소유된 데이터를 모두 지원하기 위해 Cow<'a, [u8]>로 전환하기로 선택합니다.
원시 포인터와 안전하지 않은 Drop 논리가 필요 없는 Cow<'a, [u8]> 접근 방식을 선택합니다. 결과적으로 패킷이 기본 버퍼보다 오래 살 수 없도록 보장되는 엄격한 라이프타임 보장을 가진 파서가 성공적으로 컴파일됩니다.
왜 컴파일러는 PhantomData<&'static T>가 포함된 구조체에 대해 Drop을 구현하는 것을 허용하지만, 'a가 비정적일 때 PhantomData<&'a T>에 대해서는 거부하는가?
라이프타임이 'static일 때, 참조되는 데이터는 프로그램 실행 전체에 걸쳐 존재하므로 파괴자가 실행되기 전에 메모리가 해제될 가능성이 없습니다. 'a가 로컬 라이프타임인 경우, 구조체가 존재하는 동안 데이터가 해제될 수 있어 Drop에서 덩글링 참조 접근을 생성할 수 있습니다. 컴파일러는 국부 라이프타임 사례를 거부하며, 이는 파괴자가 해제된 후 데이터에 접근하지 않을 것이라는 것을 증명할 수 없기 때문입니다.
dropck의 맥락에서 PhantomData<T>(소유 의미론)와 PhantomData<&'a T>(빌림 의미론)은 어떻게 다르며, 왜 전자가 구조체가 스코프를 벗어나는 것을 방지하지 않는가?
PhantomData<T>는 구조체가 T를 소유하는 것처럼 작용한다고 나타내며, 이는 변별성을 영향을 미치고 구조체가 T를 해제할 수 있다고 가정하여 dropck에 영향을 미치지만, 구조체의 라이프타임을 특정 빌림 라이프타임 'a에 묶지 않습니다. 따라서 컴파일러는 구조체가 지역 데이터보다 오래 살아남을 수 있다고 가정합니다. 반면에 PhantomData<&'a T>는 구조체를 라이프타임 'a에 명시적으로 제한하여, 구조체가 빌림보다 오래 살 수 없도록 하여 파괴자에서 use-after-free를 방지합니다.
dropck와 관련하여 may_dangle 속성(불안정/사용 중단)이 어떤 용도로 사용되었고, Vec<T>와 같은 타입에 어떻게 적용되었는가?
#[may_dangle] 속성은 안전하지 않은 코드가 타입의 Drop 구현이 제네릭 매개변수 T의 내용을 액세스하지 않을 것이라는 것을 컴파일러에 알릴 수 있도록 하였습니다. 이는 Vec<T>와 같은 컬렉션에서 중요했으며, 컬렉션은 그 버퍼를 소유하지만 drop하는 동안 T 값을 읽을 필요가 없기 때문입니다(그냥 메모리를 해제합니다). 후보자들이 자주 놓치는 것은 Drop Check가 기본적으로 보수적이라는 점입니다. Drop이 모든 것을 액세스할 수 있다고 가정하고 may_dangle은 컬렉션의 유연성을 위해 이 가정을 선택적으로 피하는 메커니즘이었지만, 이를 위해서는 안전하지 않은 코드와 덩글링 데이터를 액세스하지 않도록 엄격한 불변성을 유지해야 했습니다.