CHERIoT이 MMU 없이 강력하고 사용하기 쉬운 격리를 제공하는 방식

Lobste.rs 의견들 CHERIoT RTOS의 설계 선택을 다시 글로 다루고 있음. 이번에는 모든 CHERI 시스템에 권장하는 설계와, 자원이 극도로 제한된 시스템에만 적합해서 RAM이 몇 MiB보다 넉넉하다면 쓰지 말아야 할 설계를 구분해 보려 함. 질문이 있으면 여기서 답변하겠음! 캐퍼빌리티 하드웨어 지원 없이 이런 추상화를 사용하는 OS를 만드는 것도 의미가 있을까? 예를 들어 애플리케이션 개발자가 이 개념에 익숙해지는 플랫폼으로 쓸 수 있을까? CHERI용 범용 OS를 만들 계획도 있을까? CHERIoT에서는 소켓 상태를 가리키는 봉인된 캐퍼빌리티, 즉 불투명 포인터를 구획 간에 전달하고, TLS 계층에서는 이를 세션 상태 구조체에 담아 다시 봉인된 포인터로 반환한다고 하는데, 왜 유용한지 완전히 이해하지 못했음. 커널 공간의 포인터를 사용자 공간에 넘긴 뒤, 사용자 공간이 그 포인터로 다시 호출하면 유효한 포인터라고 바로 신뢰할 수 있다는 뜻일까? 그렇다면 write 시스템 호출 구현을 사실상 *io_sealed_ptr = *user_data; 같은 단순 복사로 줄일 수 있을까? 덧붙이자면, 그런 취지인 것 같고 적어도 블로킹 방식이라면 write가 시스템 호출일 필요조차 없어 보임. CHERIoT는 계층적 불신이 아니라 상호 불신을 바탕으로 설계돼서, 사실상 ‘커널 공간’이라는 개념이 없음. 쓰기 호출의 첫 번째 포인터도 메모리를 복사해 넣을 목적지가 아니라, 장치나 파일시스템 등에 대한 입출력 수행 방식을 정의하는 자료구조의 핸들임. 모놀리식 커널에서는 사용자 공간이 준 핸들로 실제 상태 포인터를 찾는 테이블이 필요함. 그 구조체와 거기서 도달할 수 있는 자료구조가 쓰는 메모리를 누구에게 귀속할지 추적하는 자원 사용량 관리도 필요함. 파일 디스크립터를 다른 프로세스에 전달하려면 UNIX 도메인 소켓 등을 통한 시스템 호출로 상대 프로세스의 테이블에도 항목을 추가해야 함. CHERIoT에서는 관련 하위 시스템에 자신의 할당 캐퍼빌리티를 직접 전달하면 됨. 하위 시스템은 호출자의 할당량에서 메모리를 확보하고 봉인된 포인터를 반환함. 자원 사용량 관리는 할당기가 일괄 처리하므로 별도로 구현할 필요가 없고, 여러 입출력 종류를 통합하는 추상화가 필요하면 자기 구획 안에 둘 수 있음. 쓰기 같은 작업에서는 구획이 직접 공개한 함수의 첫 번째 인자로 봉인된 포인터를 전달함. 가벼운 봉인 해제 연산으로 변조...