Deed-OS TF-A(BL31)

idbloader는 어차피 uboot에서 mkimage로 만들기만 하니까 어차피 만들 수 없고

OP-TEE는 볼륨이 너무 크기도 하고, 직접 구현하지 않아도됨

부트체인에서의 동작을 공부하는게 중요하기 때문에

TF-A, u-boot 코드를 참고해서 필수로 필요한 핵심 부분만 ROCK5b+, QEMU 각각 필요한 부분을 구현 하드웨어 의존적인 부분이라 바이너리파일이라면 그부분은 그대로 사용

이 글에서는 TF-A 에 대해서만 작성

문서로 이해시키기 위한 기능설명 등 이런것만 작성하기

이러려면 general_bootchain 에서

일단 TF-A는 직접 구현. 이 안에서 시큐어부트 체인을 구현해야한다. 하드웨어 키로 BL32, BL33 전부 검증하면서 로드

QEMU에서 BL31이 쉬운 이유
QEMU virt는 전원/클럭/보안 컨트롤러 같은 현실 하드웨어가 제거돼 있어서,
EL3 모니터가 해야 할 일이 “표준 장치 기준 최소”로 줄어듦.
RK3588에서 BL31이 어려운 이유
RK3588 실기기에서는 BL31(EL3)이 아래를 제대로 해줘야 안정적으로 굴러가:
PSCI(멀티코어 on/off)와 관련된 플랫폼 bring-up
secure/non-secure 메모리 carveout/속성
(필요 시) GIC 라우팅 세부
OP-TEE가 쓰는 secure DRAM 보호/공유 메모리 설정

interconnect/NoC, SMMU 설정 등으로 secure DRAM

이런것들이 secureDRAM을 하드웨어적으로 막는건데, 그러힉 때문에 직접 TF-A를 구현해서 원리를 파악하는것이 좋다.

왜 TF-A 그대로 써도 연구/방어 검증이 가능한가

연구/방어 관점에서 확인하고 싶은 건 대개 이런 것들이야:

secure/non-secure 메모리 구획이 “어디서” 강제되는지(컨트롤러/인터커넥트/페이지 속성/권한)

경계(REE↔EL3↔TEE)에서 어떤 데이터가 오가야 “안전한지”

잘못 설정되면 어떤 종류의 문제가 생기는지(설정 누락/속성 불일치/검증 누락)

이건 TF-A를 “재구현”하지 않아도,

플랫폼 초기화가 어떤 순서로 일어나는지

메모리 맵/속성 설정이 어디서 결정되는지

OP-TEE에 어떤 carveout/공유 영역이 전달되는지 같은 걸 코드/로그/설정 파일로 충분히 추적할 수 있어.

특히 실기기(RK3588)는 플랫폼 종속이 커서, 처음부터 자작 BL31로 가면 “원리 학습”보다 “보드 bring-up”에 시간을 많이 쓰게 돼.

그럼 미니 TF-A(미니 BL31)를 직접 구현하는 장점은 뭐냐

미니 BL31을 만들면 학습 포인트가 아주 선명해져:

EL3에서 “월드 스위치 + 컨텍스트 저장/복원 + SMC 디스패치”가 최소로 무엇인지

secure/non-secure 속성을 “잘못 주면” 어떤 증상으로 터지는지

경계 검증(주소/정렬/속성/범위)을 빼먹으면 왜 위험해지는지

즉, **방어적으로 ‘어떤 검증이 꼭 필요하다’**를 “기계적으로” 이해하게 돼.

브링업은 문제가 안되도록

그 방향 충분히 괜찮아. 실제로 “포팅된 TF-A를 정답지로 두고, 내가 필요한 최소만 뽑아내서 재구성”하는 게 가장 현실적인 학습/구현 루트야. 다만 성공률을 높이려면 ‘필수’의 기준을 먼저 고정해야 코드 복사가 아니라 “구조를 이해한 이식”이 돼.

이 방향으로 해도될듯

일단 TF-A를 만들어볼까

ESC
Type to search...