메모리를 예약하는 것과 접근을 막는 것은 다릅니다
커널이 일반 RAM으로 사용하면 안 되는 영역을 펌웨어와 합의해야 합니다. DT의 예약 정보, Linux의 초기 메모리 예약, 실제 보안 하드웨어의 접근 제어는 같은 기능이 아닙니다.
| 설정 | 담당하는 일 | 그것만으로 보장되지 않는 것 |
|---|---|---|
| FDT memreserve / reserved-memory | 커널에 해당 범위의 예약 또는 용도를 알려줍니다. | Secure World만 접근할 수 있도록 하드웨어를 잠그는 기능은 아닙니다. |
| reserved-memory의 no-map | 운영체제가 표준 메모리 매핑에 해당 영역을 넣지 않도록 요구합니다. | 버스 master나 다른 보안 상태의 접근 권한 전체를 제어하지 않습니다. |
| TF-A/OP-TEE 및 플랫폼 보안 설정 | 보안 RAM과 장치의 접근 권한을 구성합니다. | Linux가 사용할 공유 영역의 가상 주소를 자동으로 같게 만들어 주지는 않습니다. |
| TEE 공유 메모리 등록 | 양쪽이 사용할 버퍼의 참조와 수명을 관리합니다. | 그 버퍼의 내용이 항상 신뢰할 수 있거나 다른 쪽에서 바뀌지 않는다는 뜻은 아닙니다. |
행은 서로 대체할 수 있는 네 방식이 아니라 함께 확인해야 할 서로 다른 책임입니다.
예약 범위의 시작과 크기, 커널의 RAM 범위, 펌웨어가 실제 사용하는 범위가 서로 맞아야 합니다. 공개 보드의 DT와 공개 펌웨어 설정을 대조해야 하며, 출처가 불분명한 속성 이름만 보고 표준 기능이라고 판단하지 않습니다. 커널의 FDT 초기 처리
no-map은 사용하는 드라이버의 통제를 벗어난 추측 접근도 허용하지 않도록 요구합니다. reusable은 소유자가 다시 회수할 수 있다는 조건으로 운영체제의 임시 사용을 허용하는 속성이므로 no-map과 동시에 지정하지 않습니다. Devicetree 규격의 reserved-memory 정의
서로 다른 주소로 같은 버퍼를 가리킵니다
| 보는 쪽 | 표현 | 주의할 점 |
|---|---|---|
| 사용자 프로그램 | 사용자 가상 주소 U | 다른 프로세스나 커널이 U를 그대로 역참조하지 않습니다. |
| Linux 드라이버 | tee_shm과 커널 가상 주소 K | 버퍼 참조, offset, 크기와 수명을 관리합니다. |
| 전송 ABI | 물리 주소 P 또는 등록 cookie/FF-A handle | 선택한 ABI에서 요구하는 표현을 사용합니다. |
| OP-TEE / TA | 검증된 메모리 객체와 보안 쪽 매핑 S | U, K, P와 숫자가 같다고 가정하지 않습니다. |
U ↔ K ↔ P/handle ↔ S는 매핑과 참조의 관계입니다. 단순 덧셈으로 언제나 변환 가능하다는 뜻도, 각 단계에서 버퍼 전체가 복사된다는 뜻도 아닙니다.
offset과 size를 더할 때 범위를 넘는지, 덧셈 overflow가 있는지, 버퍼를 사용 중인데 등록을 해제하거나 재사용하지 않는지 확인해야 합니다. 입력 버퍼인지 출력 버퍼인지도 요청 규약에 들어갑니다. OP-TEE 메시지와 메모리 참조 형식
메모리에 쓰기와 상대가 읽을 준비는 별개입니다
cache 일관성이 보장되는 환경인지, 상대 CPU의 cache가 켜져 있는지, 메모리의 속성이 무엇인지에 따라 필요한 처리가 달라집니다. CPU_ON과 spin-table의 초기 진입은 일반적인 두 Linux 태스크 사이의 공유 메모리보다 제약이 많습니다.
| 작업 | 의미 |
|---|---|
| 메모리 쓰기 | 새 값이 프로그램의 메모리 동작으로 발생합니다. |
| barrier | 앞뒤 접근의 순서와 완료 조건을 해당 명령의 규칙에 따라 제한합니다. |
| cache maintenance | 필요한 cache line을 clean/invalidate하여 관찰 가능한 데이터 상태를 맞춥니다. |
| 알림: SEV·인터럽트·mailbox | 상대에게 새 상태를 확인하거나 처리하도록 알립니다. 데이터 본문을 자동으로 대신 전달하는 것은 아닙니다. |
volatile, SEV, memory barrier, cache clean은 서로 대체하는 같은 명령이 아닙니다. 한편 모든 공유 메모리 호출에 무조건 수동 cache flush를 넣는 것도 올바르지 않습니다. 실제 transport와 coherency 규약에 맞춰야 합니다. spin-table의 실제 쓰기·cache 정리·SEV 순서에서 구체적인 예를 보실 수 있습니다.
클럭·전원 요청도 펌웨어를 거칠 수 있습니다
CPU_ON 이외에도 Linux의 클럭, 전원 도메인, 성능 제어 등이 SCMI(System Control and Management Interface)를 통해 플랫폼 펌웨어에 요청될 수 있습니다. 모든 보드가 SCMI를 쓰거나 모든 자원을 펌웨어에 맡기는 것은 아닙니다.
- Linux의 자원 사용 코드
클럭 속도나 전원 도메인 같은 자원을 요청합니다.
해당 SCMI protocol driver
- SCMI core
protocol/message ID와 token을 포함한 요청을 구성하고 응답을 대응시킵니다.
플랫폼이 선택한 transport
- SMC 또는 mailbox 등
SMC transport와 mailbox transport는 별도 구현입니다. 공유 메모리 사용과 완료 통지는 transport 규칙을 따릅니다.
펌웨어의 SCMI 처리
- 플랫폼의 관리 펌웨어
요청 권한과 지원 범위를 검사해 자원을 제어하고 결과를 돌려줍니다.
화살표는 요청 전달 단계입니다. 모든 SCMI 요청이 TF-A의 PSCI handler로 들어간다는 뜻이 아닙니다. SCMI 서버는 별도 관리 프로세서나 다른 펌웨어 구성에 있을 수 있습니다.
SCMI를 “SMC의 다른 이름”으로 설명하면 mailbox 경로를 놓치게 됩니다. PSCI의 CPU_ON 인자와 SCMI의 메시지 형식도 서로 다릅니다. SCMI core · SMC transport · mailbox transport
기준 소스와 확인 범위
각 코드의 링크는 위 버전의 고정 커밋을 가리킵니다. 프로젝트별 버전을 함께 명시한 것은 비교 기준이며, 이 조합을 특정 보드에서 빌드·부팅해 호환성을 검증했다는 뜻은 아닙니다. 코드는 표시한 범위의 실제 원문이며, 설명 표는 그 범위의 동작을 묶어서 읽도록 작성했습니다.