패키지 안의 요청에도 권한 경계가 필요한 이유

패키지 안에 있다는 이유로 다른 die의 요청을 모두 믿으면, 외부 인터페이스에서는 막아 둔 접근이 내부 연결을 통해 열릴 수 있다. chiplet trust boundary는 제조사를 평가하는 문장보다 구체적이어야 한다. 어느 요청자가 어떤 자원에 어떤 동작을 할 수 있으며, 그 요청자의 권한을 어디에서 확정하는지가 경계의 실제 모습이다.

바이트가 정확하다는 것과 권한이 있다는 것

CRC가 정상인 요청도 허가받지 않은 요청일 수 있다. 전송 오류를 검사하는 계산은 요청자의 의도를 판별하지 않는다. 공개된 CRC 알고리즘을 아는 주체는 자기가 만든 메시지의 CRC도 계산할 수 있으므로, 이를 비밀 키를 사용하는 인증과 같은 증거로 취급하면 안 된다.

UCIe 2.0의 관리 transport에서도 packet integrity와 access control은 별도로 정의된다. access control을 사용하는 관리 프로토콜은 요청의 security clearance group으로 자원 접근을 확인한다. 해당 프로토콜마다 적용 여부가 다르므로 모든 vendor-defined 관리 동작에 같은 검사가 자동으로 붙는다고 확대하지 않는다. 원문 297–299쪽, 8.1.3.4–8.1.3.5절

따라서 정확하게 도착한 요청을 거절하는 것은 링크의 오류가 아니다. 정상적인 권한 경계의 동작일 수 있다. 디버깅에서는 수신 여부, 메시지 형식, 요청자의 권한과 자원의 허용 정책을 나누어 관측한다.

요청 안의 신분을 그대로 믿지 않는다

자체 통합 예로 가속기에는 group 2, 신뢰하는 보안 관리 주체에는 group 0을 배정하자. 가속기는 작업용 RAM을 읽고 쓸 수 있지만 비밀 키 저장소나 권한 설정 레지스터에는 접근할 수 없다. 이 예의 gateway는 신뢰하는 입력 경로와 실행 주체를 기준으로 요청의 group을 결정한다고 정한다.

가속기가 메시지에 group 0을 써 넣었다고 그 값만 믿으면, 같은 주소 검사기가 더 높은 권한으로 요청을 통과시킬 수 있다. gateway가 가속기 경로에서 허용한 group 2에 묶거나 허용하지 않은 표기를 거절하면 이 승격이 막힌다. 이것은 특정 UCIe IP의 구현을 단정하는 설명이 아니라, 권한 태그의 출처를 보장해야 한다는 자체 경계 설계다.

원문은 security clearance group을 요청자의 group에 맞춰 넣도록 정의하지만, entity가 그 값을 설정·선택하는 방식은 구현에 남긴다. 그러므로 일곱 비트의 group 필드를 구현했다는 사실만으로 그 필드가 정당한 신분을 증명하는 것은 아니다. 원문에서도 group 0은 Security Director를 위한 group으로 구별한다.

요청의 시작 주소뿐 아니라 전체 범위를 본다

자체 가속기의 허용 RAM 범위를 0x80000000–0x80000FFF로 두자. 주소 0x80000FF0에서 길이 16B인 요청의 마지막 주소는 0x80000FFF라 범위 안이다. 같은 시작 주소에서 길이가 32B이면 마지막 주소는 0x8000100F로 경계를 넘는다. 시작 주소만 허용 범위에 있다고 통과시키면 보호되지 않은 끝부분이 생긴다.

덧셈의 폭도 필요하다. 32비트 주소 0xFFFFFFF0에 길이 32B를 더해 마지막 주소를 계산하면 넓은 정수에서는 0x10000000F다. 이를 먼저 32비트로 잘라 0x0000000F로 만들면 wrap을 정상 요청처럼 볼 수 있다. 더 넓은 값으로 범위를 계산하거나 overflow를 검사하고 거절해야 한다.

UCIe 관리 access control 원문도 요청에 여러 자원이 필요하면 모든 자원에 접근이 허용되어야 하고, 하나라도 거절되면 해당 요청으로 어떤 자원도 접근하지 않도록 한다. 한 자원은 표준 class 또는 vendor class가 허용하면 통과하지만, 여러 자원이 필요한 요청에서는 각 자원이 모두 통과해야 한다. 두 허용 판단의 논리를 혼동하지 않는다.

정상 기능과 복구 기능에 같은 경계를 유지한다

정상 DMA를 제한했는데 debug나 복구 명령으로 같은 메모리를 읽을 수 있다면 다른 경로가 남는다. 권한 설정을 바꾸는 CSR, 펌웨어 갱신, 디버그 개방처럼 민감한 동작을 목록화하고 lifecycle 상태에 따라 허용 여부를 정한다. OpenTitan의 원 가이드도 민감 동작 식별, lifecycle 조건, 최소 권한의 안전한 기본값을 권고한다. 공식 하드웨어 설계 지침의 Recommendation 1·4·6

reset 후의 기본값도 이 정책에 들어간다. 정상 동작 중에만 권한이 좁아지고 reset 직후에는 모든 접근이 열린다면 재시작이 경계를 우회하는 수단이 된다. 반대로 복구에 필요한 최소 접근까지 막으면 관리 주체가 장치를 복원할 수 없다. 초기 상태에서 누구에게 어떤 기능을 남길지 명시하고 설정이 완료되는 흐름을 검증한다.

chiplet trust boundary는 모든 die의 동작이 선의라는 가정을 없앤 뒤에도 유지되는 접근 규칙이다. 요청자의 권한을 신뢰하는 경로에 묶고, 전체 자원 범위와 동작을 검사하고, 관리·debug·reset 경로에도 같은 원칙을 적용한다. 이렇게 정의하면 연결의 호환성을 시스템 전체의 권한으로 잘못 확대하는 일을 줄일 수 있다.