2023.10.07 (22주차) - 약 12명 참여

1. 시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리

9.4 Armv8 익셉션을 구성하는 주요 개념

9.5 익셉션의 전체 실행 흐름

공유) 익셉션 case에 따른 익셉션 벡터 테이블 offset 알아보기 

Q: 4단계에서 인터럽트 핸들러는 "인터럽트가 발생한 시점의 레지스터 세트를 프로세스의 스택 공가에 푸시한다" 설명하는데, 여기서 말하는 레지스터 세트가 SPSR_ELx, ELR_ELx  레지스터 인가요?

SPSR_ELx, ELR_ELx 에서 익셉션 처리 전의 상태와 익셉션 레벨을 로딩한다로 이해가 되는데 맞는지 모르겠네요

A: 푸시하는 레지스터 세트는 범용 레지스터 세트이다. SPSR은 PSTATE를 저장하는 레지스터이고, ELR은 익셉션 처리 이후 복귀 주소를 저장하는 레지스터이다. 익셉션이 발생했을 때 SPSR의 익셉션 레벨이 익셉션을 처리할 레벨로 변경되고, ELR은 복귀 주소를 저장할 것이다. 

Q: 익셉션 레벨별로 벡터 테이블이 존재하나요?

A: 그렇다. (pg 237, pg278, VBAR)

9.6 익셉션 종류별 레지스터 변경

9.7 익셉션 벡터 테이블 분석

Q: ELR은 익셉션 후 복귀할 때 사용하는 레지스터, ESR은 익셉션에 대한 정보를 담는 레지스터로 이해했는데, synchronize, IRQ 모두 두 레지스터가 업데이트 되지만, 복귀 여부에 따라 명령어가 실행되지 않는건 아닐까... 생각도 드는 것 같아요…

A: IRQ, FIQ 경우 ESR는 업데이트 되지 않습니다.(246 page)

Q: 개인적으로 궁금한건데 모든 익셉션 레벨에서  같은 스택을 사용할 경우 발생할 수 있는 문제는 어떤게 있을까요?

A1: 스택에 있는 ELR, LR 주소를  변경시켜 return , ERET명령이 실행되었을경우 자기가 원하는 코드를 실행하게 할수 있고. 스택이 오염되었을 경우 모든 시스템이 마비될 수 있음,

스택이 나누워져 있을 경우 EL0에서 오염이 되었으면 EL0 어플리케이션만 죽이면 되지만 하나의 스택을 쓴다면 무조건 시스템 종료시켜야함

A2: 잘은 모르겠지만 접근권한의 문제가 아닐까싶네요

Q: 구동중인 커널의 익셉션을 판단하려면 커널 외부의 무언가에 도움을 받아야 할 것 같은데, 익셉션을 감지하는 하드웨어가 별도로 존재하나요...??

A: 275페이지 그림 9.12 같은곳 2번을 보면 "하드웨어적으로 처리" 한다고 나와 있으니 하드웨어가 존재할 것 같다.

Q: 284쪽에 2번째 A를 보면, ESR_EL1 레지스터의 비트 읽는 부분이 없는데 맞나요?

SVC 명령어 실행 시 분기 질문하는 부분이요. SVC 명령어 실행 시에도 ESR_EL1 레지스터의 [31:26] 비트 읽을 수 있다고 이해하고 있었는데 내용이 없길래 혹시 제가 잘못알고 있나 싶어서요

A: ESR_EL1 [31:26]을 읽는 것이 맞습니다.

Q: 그림 9.15 처럼 여러 OS가 존재할 떄는 각 OS의 ELx마다 벡터 테이블을 갖는건가요?

A1: 그럴 것 같다. OS를 만들 때, 하이퍼바이저까지 신경쓰지 않을 것 같다.

A2: EL1에존재하는 2개의 게스트 OS에 각각 익셉션 벡터 테이블이 있고, EL2에 익셉션 벡터 테이블이 존재합니다 (pg 286)

cf) 리눅스 커널 6.4.2 에서 el1h_64_sync와 el1h_64_irq 비교 

1) el1h_64_sync

2) el1h_64_sync_handler

3) el1h_64_irq

4) el1h_64_irq_handler

9.8 익셉션과 익셉션 모델 

9.9 Illegal Return Event (허용되지 않는 익셉션 레벨 복귀)

cf) 리눅스 커널 6.4.2에서 EL1 with SP_EL0을 지원하지 않는 코드

1) 익셉션 벡터 테이블

2) el1t_64_sync

3) el1t_64_sync_handler

4) __panic_unhandled

2. 리눅스 커널 6.4.2 

** init_kernel_el 에 들어가기 전 아키텍처 공부 진행. 자세한 내용은 공유 문서의 시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리 파일에서 확인 가능

head.S : init_kernel_el 시작, init_el1의 pre_disable_mmu_workaround 까지 진행

1) mov_q 매크로

문c 블로그의 관련 설명

Assembly expressions

https://developer.arm.com/documentation/100067/0611/armclang-Integrated-Assembler/Assembly-expressions

2) INIT_SCTLR_EL1_MMU_OFF

3) INIT_SCTLR_EL1_MMU_ON

SCTLR_EL1의 각 비트의 의미

https://developer.arm.com/documentation/ddi0595/2021-12/AArch64-Registers/SCTLR-EL1--System-Control-Register--EL1-

4) pre_disable_mmu_workaround

ARM Errata에 대한 설명 : https://blog.naver.com/PostView.naver?blogId=crushhh&logNo=222025070115