타입 시스템의 분산성은 제네릭 매개변수 간의 서브타입 관계가 전체 타입에 어떻게 영향을 미치는지를 결정합니다. Rust의 접근 방식은 지역 기반 메모리 관리 연구와 사용 후 해제(vulnerability) 방지를 위한 필요성의 영향을 많이 받았습니다. Rust가 가변 참조(&mut T)를 도입할 때, 설계자들은 그것이 공변(covariant, &T와 같은)해야 할지, 반변(contravariant)일지, 혹은 불변(invariant)일지를 결정해야 했습니다. &mut T의 불변성을 선택한 것은 런타임 체크 없이 메모리 안전성을 유지하는 데 중요했습니다.
만약 &mut T가 T에 대해 공변이었다면, U가 V의 서브타입일 경우 &mut V가 예상되는 곳에 &mut U를 대체할 수 있었을 것입니다. 생명주기 측면에서 'long이 'short의 서브타입이므로('long이 'short보다 더 오래 살아있기 때문), 이는 &mut &'long str을 &mut &'short str에 할당할 수 있다는 것을 의미합니다. 이는 해롭지 않은 것처럼 보이지만, 신뢰성 문제가 발생합니다.
&mut T는 T에 대해 **불변(invariant)**입니다. 이는 &mut &'a str과 &mut &'b str이 생명주기 간의 서브타입 관계에 관계없이 'a가 'b와 정확히 같지 않는 한 관련이 없는 타입임을 의미합니다. 컴파일러는 이들 간의 강제 변환을 시도하는 코드를 거부하여, 단기 생명 데이터가 장기 생명 참조를 기대하는 위치에 대입되는 것을 방지합니다.
코드 예제:
fn demonstrate_invariance() { let mut long_lived: &'static str = "static string"; // &mut T가 공변이었다면, 이는 컴파일될 것입니다: // let short_ref: &mut &'short str = &mut long_lived; // 그러나 &mut T가 불변이기 때문에, 이는 실패합니다: // error: lifetime mismatch // let short_ref: &mut &'_ str = &mut long_lived; let local = String::from("temporary"); // 위가 허용되었다면, 우리는 이렇게 할 수 있습니다: // *short_ref = &local; // 이제 long_lived가 드롭된 데이터(UAF!)를 가리킵니다. } // 여기서 local이 드롭됩니다
한 팀이 고성능 네트워킹 스택을 위한 구성 관리자를 구축하고 있었습니다. 핵심 구조는 런타임에 소유권을 가지지 않고 프로토콜 구성을 교환할 수 있는 가변 참조를 보유해야 했습니다.
문제: 초기 API 설계에서 &mut &'a Config를 사용했으며, 여기서 'a는 네트워크 세션의 생명주기였습니다. 개발자들은 이를 &mut &'static Config(전역 기본 구성 사용을 위해)로 초기화한 후, &mut &'session Config를 기대하는 함수에 전달하려고 했습니다. 컴파일러는 이를 거부하여 불만을 일으켰고, 불변 참조(& &'static Config)는 잘 작동했습니다.
고려된 해결책:
1. 변환을 강제하기 위한 안전하지 않은 변환 팀은 std::mem::transmute를 사용하여 &mut &'static Config를 &mut &'session Config로 변환하는 것을 고려했습니다. 이는 컴파일러의 분산성 체크를 우회합니다. 그러나 이는 단기 생명 구성 참조를 현재 스코프보다 오래 사는 위치에 쓸 수 있게 하여, 생성 후에 구성이 접근될 경우 즉시 정의되지 않은 동작을 초래할 수 있었습니다. 프로덕션 코드에서 사용 후 해제의 위험은 용납할 수 없었습니다.
2. 불변 참조로 변경하기 그들은 API를 & &'a Config를 사용하도록 변경하는 것을 고려했습니다. 공유 참조는 공변성이 있으므로, & &'static Config를 & &'session Config로 변환할 수 있었습니다. 그러나 이는 런타임 업데이트 중 설정을 원자적으로 교환하는 능력을 제거하여, 연결을 다시 시작하지 않고 설정을 핫 리로드하는 것이라는 핵심 요구 사항을 잃는 결과를 낳았습니다.
3. 내부 가변성을 위한 Cell<&'a Config> 사용 이 옵션은 공유 참조를 통해 변형을 허용합니다. 그러나 **Cell<T>**도 안전성을 위해 T에 대해 불변이기 때문에 분산성 문제를 해결하지 못했습니다. 또한, Cell은 다중 스레드 접근을 위한 동기화를 제공하지 않으며, RefCell로 인한 런타임 대여 검사 비용은 핫 경로에서 너무 비쌌습니다.
4. 소유 타입과 간접성을 사용한 재설계 선택된 솔루션은 참조-참조 패턴을 완전히 제거했습니다. &mut &'a Config를 저장하는 대신, 구조체는 &'a mut ConfigHolder를 저장했으며, 여기서 ConfigHolder는 소유 래퍼였습니다. 이는 변형성을 참조 수준이 아닌 소유자 수준으로 이동시켜, 분산성 문제를 피하면서 구성을 교환할 수 있게 했습니다. API는 사용자들이 이중 참조를 관리할 필요가 없어져 더 편리해졌습니다.
결과: 재설계된 API는 안전한 코드를 포함하지 않고 컴파일되었으며, &mut T의 불변성 덕분에 팀이 생명주기 가정이 위반될 수 있는 잠재적 구조적 결함을 인식할 수 있게 되었습니다. 최종 시스템은 구성이 유효 기간을 초과하여 지속될 수 있는 오류 범주를 방지했습니다.
왜 Cell<T>가 T에 대해 불변이며, 이것이 &mut T의 분산성과 어떤 관련이 있는가?
**Cell<T>**는 내부 가변성을 제공하여 공유 참조를 통해 변형할 수 있게 합니다. 만약 **Cell<T>**가 T에 대해 공변이었다면, **Cell<&'short str>**을 **Cell<&'static str>**로 업캐스팅할 수 있었습니다. 그러면 짧은 생명 문자열 참조를 내부에 저장하고 나중에 Cell<&'static str> 타입을 통해 읽을 수 있게 되어, 일시적인 데이터를 정적처럼 취급하게 됩니다. 이는 사용 후 해제 취약점을 초래할 수 있습니다. 따라서 &mut T와 마찬가지로 Cell<T>(및 UnsafeCell<T>)는 짧은 생명 데이터가 더 긴 생명 데이터를 보유한다고 주장하는 슬롯에 기록되는 것을 방지하기 위해 T에 대해 불변이어야 합니다. 이 불변성은 RefCell, Mutex 및 기타 내부 가변성 유형으로 전파됩니다.
PhantomData<T>가 실제 T를 포함하지 않는 구조체의 분산성에 어떤 영향을 미치며, 왜 PhantomData<fn(T)>를 사용하여 반변성을 달성하는가?
**PhantomData<T>**는 컴파일러에게 해당 구조체가 분산성과 드롭 검사 목적으로 T를 소유하는 것처럼 처리하도록 지시합니다. 기본적으로 **PhantomData<T>**는 구조체에 T와 같은 분산성을 부여합니다. 그러나 함수 포인터는 특별한 분산성을 가집니다: fn(A) -> B는 A(인수)에 대해 반변적이고 B(반환)에 대해 공변적입니다. 생명주기에서 반변적으로 구조체를 만들 필요가 있는 경우(**Struct<'long>**이 **Struct<'short>**의 서브타입일 때 'long이 'short보다 더 오래 살아있음), **PhantomData<fn(T)>**를 사용합니다. 이는 생명주기 간의 관계를 반전시켜야 하는 타입 안전한 콜백 또는 비교기를 구축하는 데 중요합니다.
안전하지 않은 코드에서 원시 포인터를 사용하여 자기 참조 구조체를 구현할 때, 왜 구조체를 그 생명주기 매개변수에 대해 불변으로 표시해야 하는가?
구조체가 같은 구조체 내의 다른 데이터(자기 참조)를 가리키는 원시 포인터를 포함할 경우, 해당 구조체의 생명주기가 포인터의 유효성을 결정합니다. 만약 구조체가 생명주기 'a에 대해 공변이라면, 'a를 더 짧은 생명주기 'b로 축소할 수 있어, 구조체가 실제로 'b만큼만 살아있다고 주장할 수 있습니다. 그러나 구조체가 더 길게 살아있을 때 생성된 원시 포인터는 이제 더 짧은 범위에서 더 이상 유효하지 않은 데이터를 가리킬 수 있습니다. 불변성은 구조체가 더 짧은 생명주기로 강제 변환될 수 없도록 보장하여, 자기 참조가 타입 시스템에 인코딩된 전체 생명주기 동안 유효함을 유지하는 안전성을 보장합니다. 이것이 Pin이 안전한 자기 참조 구현에서 명시적인 분산성 마커와 자주 결합되는 이유입니다.