kernel/head.S – ARM64 (new for v6.0)

kernel/head.S – ARM64 (new for v6.0)

시스템의 부트로더로부터 커널을 주 메모리에 로드하고 커널이 최초로 호출되는 지점이 head.S의 _head: 레이블이다. 이 시작 코드에는 커널 이미지의 헤더 및 UEFI(Unified Extensible Firmware Interface) PE(Portable Executable) 헤더등을 포함하며 최초 C 언어로 처리하기 힘든 시스템 설정들을 여기 어셈블리에서 처리한 후 C 시작 루틴인 start_kernel()로 jump 하는 역할을 한다. 이 코드들은 물리 DRAM의 2M 단위로 정렬된 주소라면 어떠한 위치에 배치하여도 동작할 수 있도록 모든 코드가 position independent 코드들로 구성되어 있다.

참고:
- UEFI(Unified Extensible Firmware Interface) | 나무위키
- 레거시 BIOS vs UEFI 차이점 | dumsnail
- PE(Portable Executable) | OSDev.org
- 위치 독립(Position Independen) 코드 | 위키백과

다음 그림은 부트로더로부터 커널의 어셈블리 부분과 C 부분이 차례로 호출되는 과정을 보여준다.

부트로더가 하는 일 요약

커널을 로드하여 동작시키기 전까지 부트로더가 수행하는 일들은 다음과 같다.

주 메모리의 초기화를 수행한다.
DTB(Device Tree Blob)를 주 메모리에 로드한다.
- x0 레지스터에 DTB 물리 시작 주소를 담는다.
- x1~x3 레지스터는 미래에 사용할 레지스터로 예약하였다.
커널 이미지를 주 메모리에 로드한다.
(옵션) 압축된 커널 이미지(예: Image.gz 등)를 사용하는 경우 decompress를 수행한다.
- 커널 이미지 헤더가 포함된 압축 풀린 커널 이미지는 2M 단위로 정렬하여야 한다.
커널 이미지의 첫 주소로 jump하여 커널의 head.S 루틴을 시작한다.
DTB는 Device Tree 계층도를 Device Tree Script로 작성한 후 바이너리 형태로 변환한 형태며, 자세한 내용은 다음 문서를 참고한다.
- 참고:
  - Booting AArch64 Linux | Kernel.org
  - Device Tree 문법 | Max Jung

커널 진입전 요구사항

커널 진입 전 부트로더는 다음 조건을 만족해야 한다.

cpu의 레지스터
- x0: boot cpu인 경우 DTB 시작 물리 주소, boot cpu를 제외한 나머지 secondary cpu인 경우 0 (Reserved for Future)
- x1~x3: 0 (Reserved for Future)
MMU 및 캐시 상태
- MMU: off
- D-Cache: off
- 로드된 커널 이미지 영역에 대해 PoC까지 clean 상태여야 한다.
  - PoC 등 참고: Cache – Coherent | 문c
DMA 장치
- 모든 DMA(Direct Memory Access) 장치들은 DMA 기능이 정지되어 있어야 한다.
CPU mode
- 모든 cpu들의 PSTATE.DAIF는 모두 마스크되어야 한다. (디버그, SError, IRQ 및 FIQ의 마스크)
  모든 CPU는 EL2 또는 non-secure EL1에 있어야 하고 동일해야 한다.
아키텍처 타이머
- CNTFRQ 레지스터는 타이머 주파수로 프로그래밍해야 한다.
- CNTVOFF 레지스터는 모든 CPU에서 동일한 값으로 프로그래밍해야 한다.
- 커널이 EL1에서 동작할 경우 하이퍼바이저(el2)가 있는 경우 CNTHCTL_EL2.EL1PCTEN을 설정해야 한다.
그 외 시스템 레지스터들
- SCR_EL3.FIQ
  - 모든 cpu들에 동일한 값이 사용되어야 한다.
- GICv3가 v3 모드에서 사용될 때
  - EL3 존재시
    - ICC_SRE_EL3.Enable=1
    - ICC_SRE_EL3.SRE=1
    - ICC_CTLR_EL3.PMHE 모든 cpu들에 동일한 값 사용
  - 커널이 EL1에서 동작시
    - ICC.SRE_EL2.Enable=1
    - ICC_SRE_EL2.SRE=1
  - Device Tree 또는 ACPI 테이블에 GICv3 인터럽트 컨트롤러에 대해 기술되어야 한다.
- GICv3가 v2 호환모드에서 사용될 때
  - EL3 존재시
    - ICC_SRE_EL3.SRE=0
  - 커널이 EL1에서 동작시
    - ICC_SRE_EL2.SRE=0
  - Device Tree 또는 ACPI 테이블에 GICv2 인터럽트 컨트롤러에 대해 기술되어야 한다.
- Pointer Authentication
  - 참고: ARM pointer authentication | LWN.net
- Activity Monitors Unit v1
  - 참고: Activity Monitors Unit (AMU) extension in AArch64 Linux | Kernel.org

head.S가 하는일 요약

어셈블리 언어로 작성된 head.S 가 커널의 시작점이다. C 언어로 할 수 없는 아키텍처 등의 설정 등을 head.S에서 수행 한 후 이어서 C 언어로 작성된 첫 실행 지점인 start_kernel() 함수가 호출된다. 그런 후 곧바로 setup_arch() 함수에서 나머지 아케틱처 설정들을 C 언어로 수행한다. 다음은 head.S에서 어셈블리 언어로 수행하는 작업들이다.

하이퍼 바이저 모드(el2)가 사용되는 경우 EL2 exception 벡터 준비
부트 cpu 초기화 및 커널 운영체제용 EL1 exception 벡터 준비
필요시 커널 가상 공간에 매핑될 커널 이미지의 위치를 랜덤하게 변경
6 종류 종류별 페이지 테이블 중 init_pg_dir, init_idmap_pg_dir, idmap_pg_dir 페이지 테이블 생성 및 활성화
커널용 스택 준비
MMU를 켜서 가상 주소 체제로 전환
마지막으로 C로 작성된 커널 시작 함수인 start_kernel()로 점프

커널 이미지 위치

PAGE_OFFSET

arch/arm64/kernel/head.S

#if (PAGE_OFFSET & 0x1fffff) != 0
#error PAGE_OFFSET must be at least 2MB aligned
#endif

리니어(연속) 매핑이 시작되는 가상 주소이다. 이 영역에 물리 메모리를 리니어(연속) 매핑한다.

2M 단위의 섹션 매핑을 위해 2M로 정렬되어야 한다.
참고: arm64: allow kernel Image to be loaded anywhere in physical memory (2016, v4.6-rc1)

arch/arm64/include/asm/memory.h

/*
 * PAGE_OFFSET - the virtual address of the start of the linear map, at the
 *               start of the TTBR1 address space.
 * PAGE_END - the end of the linear map, where all other kernel mappings begin.
 * KIMAGE_VADDR - the virtual address of the start of the kernel image.
 * VA_BITS - the maximum number of bits for virtual addresses.
 */
#define VA_BITS                 (CONFIG_ARM64_VA_BITS)
#define _PAGE_OFFSET(va)        (-(UL(1) << (va)))
#define PAGE_OFFSET             (_PAGE_OFFSET(VA_BITS))

예) CONFIG_ARM64_VA_BITS=48로 설정

가상 공간의 크기가 2^48 = 256TB로 결정된다.
이 때 PAGE_OFFSET 값은 0xffff_0000_0000_0000

__PHYS_OFFSET

커널이 동작할 물리 시작 주소 offset 값으로, 실제 물리 주소를 알고자 할 때 adrp 명령과 함께 사용되었었는데, 커널 v6.0-rc1에서 제거되었다.

remove __PHYS_OFFSET (2022, v6.0-rc1)

KERNEL_START & KERNEL_END

arch/arm64/include/asm/memory.h

#define KERNEL_START      _text
#define KERNEL_END        _end

커널 이미지의 코드(_text) 시작 주소가 KERNEL_START 이다. 그리고 커널 이미지의 끝이 _end로 .bss 섹션도 포함된다.

참고: Memory Layout on AArch64 Linux | Kernel.org

TEXT_OFFSET

기존 AArch64 커널(~v4.6까지)에서 2M 정렬된 커널에서 실제 커널 시작 코드가 배치되는 위치로 jump 하기 위해 TEXT_OFFSET을 사용했었다. 사용되는 값은 제조사가 정한 offset(기존 512K offset) 또는 랜덤 offset 등을 사용해왔었다. 그런데 KASLR 도입 과정에서 relocatable kernel 개념을 적용하여 TEXT_OFFSET이 의미 없어지면서 v5.8-rc1에서 0으로 변경하였다가, v5.8-rc2에서 완전히 제거되었다.

참고:
- arm64: don’t map TEXT_OFFSET bytes below the kernel if we can avoid it (2016, v4.7-rc1)
- arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely (2020. v5.8-rc1)
- arm64: remove TEXT_OFFSET randomization (2020, v5.8-rc2)
- arm64: get rid of TEXT_OFFSET (2020, v5.10-rc1)

다음 그림은 커널 이미지가 2M 정렬되어 위치하는 모습을 보여준다.

가상 공간에 커널 이미지 배치

다음 그림은 가상 주소 공간에 배치될 때의 커널 이미지 위치를 보여준다.

KASLR(Kernel Address Sanitizer Location Randomization)을 사용하지 않는 경우이다.

KASLR(Kernel Address Sanitizer Location Randomization)

보안 목적으로 커널 가상 주소 공간에서 커널 이미지 및 커널 모듈이 위치해 있는 곳을 알 수 없게 런타임에 랜덤 배치한다.이때 자동적으로 RELOCATABLE 커널 옵션이 활성화된다.
- CONFIG_RANDOMIZE_BASE
  - 커널 이미지의 위치를 런타임에 랜덤하게 변경한다.
- CONFIG_RANDOMIZE_MODULE_REGION_FULL
  - 커널 모듈의 위치를 런타임에 랜덤하게 변경한다.
- 참고: arm64: add support for kernel ASLR (2016, v4.6-rc1)

EL(Exception Level)

시스템 전원이 켜지고 boot cpu가 처음 가동될 때 ARM64 시스템에 구현되어 가지고 있는 가장 최상의 EL(Exception Level)에서 동작한다. exception이 발생하였을 때 EL의 상승이 발생하고 exception 처리가 끝나면 다시 하강시킬 수 있다. 32비트 ARM 시스템에서는 하이퍼바이저나 Secure Monitor가 ARM SoC에 내장되지 않은채 출하된 경우도 있었지만, 64비트 ARM 시스템에서는 거의 대부분의 확률로 모두 탑재되어 있다. 따라서 대부분 boot cpu가 처음 동작하는 EL은 EL3가 된다.

다음 그림은 exception이 발생한 경우 EL0를 제외하고 해당 EL 또는 상위 EL로 이동하는 모습을 보여준다.

User application이 동작하는 EL0의 경우 privilidge 권한이 없어 exception 처리 루틴을 동작시킬 수 없다.
인터럽트 exception이 발생하였을 경우 인터럽트 번호마다 어떠한 EL로 이동하여 처리할지 최상위 EL에서 설정해야 한다.

다음 그림은 명령을 통해 강제로 상위 EL을 호출하는 모습을 보여준다.

명령들은 sync exception으로 분리한다.

다음 그림은 exception이 처리된 후 되돌아가는 경로를 보여준다.

하위 EL 또는 동일한 EL로 돌아갈 수 있다. 그러나 상위 EL로 되돌아가는 방법은 없다.

VHE(Virtual Host Extension) 기능

부트로더로 부터 리눅스 커널로의 진입 시 boot cpu는 EL1 또는 EL2에 있을 수 있다. 즉 시스템이 처음 부팅하여 리눅스 커널이 하이퍼 바이저 용도로도 사용될 수 있는 상태라면 EL2로 진입하였을 것이고, 그렇지 못한 경우는 EL1으로 시작한다.

다음 그림은 boot cpu가 리눅스 커널에 진입할 때 EL1에서 시작한 경우를 보여준다.

Hypervisor(Xen 등) 또는 QEMU/KVM 등을 통해 가동되는 Guest용 리눅스 커널은 EL1에서 시작한다.

리눅스 커널이 EL2로 시작한 경우 리눅스 커널은 스스로 하이퍼 바이저 역할을 수행할 수 있다. 그런데 기존의 ARM 아키텍처에서는 EL2에서 리눅스 커널을 사용하기 위해서 한 가지 문제점이 있었다. EL2에서 동작하는 레지스터들을 사용하기 위해 방대한 코드들을 모두 변경해야 하는 부담이 있어서, 실제로 그렇게 하지 않고 대부분의 기능을 EL1으로 전환하여 동작시킨다. 즉 EL2로 excecption이 발생하면 일부 stub 코드만을 사용한 후 다시 EL1으로 변경하여 리눅스 커널 코드를 재활용하는 방법을 사용한다. 이렇게 하는 과정에서 EL 전환에 따른 성능 손실이 발생하였고 이를 해결하기 위해 VHE(Virtual Host Extension) 기능이 내장된 ARMv8.2 아키텍처가 나오게 되었다.

ARMv8.2-VHE extension을 가지고 있는 경우 EL2 모드에서 EL1 모드로 변경하지 않고 그대로 EL1 레지스터들을 호출하는 방법을 지원하게 되면서 EL 전환에 따른 성능 손실이 일어나지 않게 되었다.

nVHE는 VHE 기능이 지원되지 않음을 의미한다. (non-VHE)
참고: 가상화 지원 (하이퍼 모드) | 문c

다음 그림은 boot cpu가 리눅스 커널에 진입할 때 EL2에서 시작한 경우에 cpu의 VHE 기능 지원 여부에 따라 Host OS가 EL EL2에 위치(VHE)하여 동작하는 것과, 그렇지 않고 EL2에 위치(nVHE)하여 동작하는 방법과 를 보여준다.

대부분의 최근 ARM64 SoC들은 Hypervisor extension과 Secure Monitor extension이 모두 탑재된 상태로 출하된다.

VHE 지원시 _ELx 레지스터 접미사 사용 규칙

VHE 기능이 활성화된 상태에서 EL2 모드에서 각 ELx의 레지스터 호출 방법은 다음과 같다.

_EL1 레지스터 사용
- EL1 레지스터에 접근하지 않고 EL2 레지스터에 접근한다.
_EL2 레지스터 사용
- 그대로 EL2 레지스터에 접근한다.
_EL12 레지스터 사용
- EL1 레지스터에 접근한다.

Static 페이지 테이블

커널이 컴파일될 때 미리 준비되는 6개 페이지 테이블의 용도는 다음과 같다.

init_pg_dir
- 원래 커널 페이지 테이블은 swapper 페이지 테이블만을 사용했었다. 그런데 보안 향상을 위해 swapper 페이지 테이블을 read-only로 운영하기 위해 별도로 분리하고, 커널 초기 부팅 중에만 잠시 사용하기 위해 read-write 가능한 상태로 init 페이지 테이블을 운영한다.
  - 참고: arm64/mm: Separate boot-time page tables from swapper_pg_dir (2018, v4.21-rc1)
- 초기 부팅 중에만 사용되므로 매핑에 사용할 페이지 테이블의 단계와 단계별 갯수는 커널 영역(text, data, bss 섹션)에 한정하여 컴파일 타임에 계산된다.
- 정규 매핑 준비를 수행하는 paging_init() 후에 swapper_pg_dir로 전환을 수행한 후에는 이 init 페이지 테이블은 더 이상 운영하지 않으므로 할당 해제한다.
swapper_pg_dir
- 커널 부트업 과정에서 정규 매핑이 가능해지는 순간부터 swapper 페이지 테이블이 커널 페이지 테이블로 사용된다.
- 보안 향상을 위해 읽기 전용으로 매핑하여 사용하며, 매핑 변경을 위해 엔트리 값을 수정해야 하는 경우마다 잠깐씩 fixmap 가상 주소 영역에 읽고쓰기(read-write) 매핑하여 사용한다.
- 정규 매핑이 가능해지면서 사용되므로 static으로 만들어지는 pgd 테이블을 제외하곤 필요시 동적으로 생성된다.
reserved_pg_dir
- 보안 상향을 위해 copy_from_user() 등의 별도의 전용 API 사용을 제외하고 무단으로 커널 space에서 유저 공간에 접근 못하게 금지하는 SW 에뮬레이션 방식에서 필요한 zero 페이지 테이블이다.
- ARMv8.0까지 사용되며, ARMv8.1-PAN HW 기능을 사용하면서 이 테이블은 사용하지 않는다.
tramp_pg_dir
- 고성능 cpu를 가진 시스템에서 Speculation 공격을 회피하기 위한 보안 상향을 목적으로 유저 space로 복귀 시 커널 공간에 원천적으로 접근 못하게 하기 위해 별도의 trampoline 페이지 테이블을 운영한다.
- 이 테이블에는 커널 매핑은 없고, 커널/유저 진출입시 사용되는 SDEI(Software Delegated Exception Interface)를 사용한 trampoline 코드만 매핑되어 사용된다.
idmap_pg_dir
- 가상 주소와 물리 주소가 1:1로 매핑되어 사용될 때 필요한 테이블로 영구적으로 사용된다.
- 예) MMU enable 시 사용
init_idmap_pg_dir
- idmap_pg_dir과 동일하게 가상 주소와 물리 주소가 1:1로 매핑하지만, 일부 코드가 아니라 전체 커널 이미지와 FDT를 대상으로 사용되고, 부팅 후에는 제거된다.
- 참고:
  - arm64 head: cover entire kernel image in initial ID map (2022, v6.0-rc1)
  - arm64: head: create a temporary FDT mapping in the initial ID map (2022, v6.0-rc3)

다음 그림은 컴파일 타임에 static하게 만들어지는 페이지 테이블의 용도를 보여준다.

리눅스 커널은 이제 5단계(pgd -> p4d -> pud -> pmd -> pte) 테이블을 사용한다. 하지만 ARM64의 head.S 코드는 실제 ARM64 아키텍처가 4단계만 사용하므로 p4d 단계는 배제하고 구현되어 있다.
init_으로 시작하는 2개의 페이지 테이블은 컴파일 타임에 필요한 페이지 테이블이 모두 준비된다. pgd를 제외하고 나머지 테이블들은 1개 또는 그 이상으로 구성될 수 있다. 단 4K 페이지를 사용하는 커널 이미지의 매핑에는 2M 단위의 블럭 매핑을 사용하므로 마지막 pte 테이블을 사용하지 않는다.
컴파일 타임에 pgd 테이블만 준비되는 4개의 테이블들은 런타임에 정규 매핑 준비 과정에서 pgd 이후 다음 단계의 페이지 테이블부터 dynamic 하게 생성된다.

다음 그림은 static 페이지 테이블들이 배치된 사례를 보여준다.

init_pg_dir & init_idmap_pg_dir
- 4K 페이지, 2M 블럭 매핑을 사용하면서 pte 테이블을 사용하지 않고, 1단계 줄어 3단계로 구성된다.

섹션(블럭) 매핑

ARM64 시스템에서 4K 페이지를 사용하는 경우 2M 단위의 섹션(블럭) 매핑을 하여 필요한 페이지 테이블 단계를 1 단계 더 줄일 수 있다. 이 방법으로 init_pg_dir 및 idmap_pg_dir 역시 1 단계를 줄여 사용할 수 있다.

다음 그림은 init_pg_dir에서 기존 페이지 테이블 단계(4단계, 3단계)를 1 단계 더 줄여 2M 단위 섹션 (블럭) 매핑된 모습을 보여준다.

SWAPPER_PGTABLE_LEVELS가 PGTABLE_LEVELS 보다 1 단계 더 적다.
섹션 블럭 매핑에서 각 단계의 명칭은 아래와 같이 표현하였다.
- 좌측 그림: ARM64 아키텍처로 보면 lvl0 -> lvl1 -> lvl2 -> 2M이고, 매크로 코드를 공유하여 사용하므로 코드 관점에서 보면 pgd -> pmd -> pte -> 2M와 같이 표현해도 좋다.
- 우측 그림: ARM64 아키텍처로 보면 lvl0 -> lvl1 -> 2M이고, 매크로 코드를 공유하여 사용하므로 코드 관점에서 보면 pgd -> pte -> 2M와 같이 표현해도 좋다.

Identity 매핑

물리 주소와 가상 주소가 동일하도록 매핑을 할 때 다음과 같은 3가지 상황이 발생한다.

다음 그림은 물리 주소의 idmap 코드 영역이 동일한 주소의 유저 가상 주소 공간에 배치 가능한 경우이다. 가장 일반적인 상황이다.

다음 그림은 물리 주소의 idmap 코드 영역이 동일한 주소의 유저 가상 주소 공간에 배치가 불가능할 때 페이지 테이블 단계를 증가시켜 유저 가상 주소 공간을 키워 매핑을 하게한 상황이다.

다음 그림은 물리 주소의 idmap 코드 영역이 동일한 주소의 유저 가상 주소 공간에 배치가 불가능하고, VA_BITS=48 공간을 최대치인 52 비트로 확장시킬 수 있는 방법이다.

조건: ARMv8.2-LPA 기능을 지원하는 아키텍처에서 64K 페이지 및 3단계 페이지 테이블을 사용할 때 가능하다.
참고:
- arm64: allow ID map to be extended to 52 bits (2017, v4.16-rc1)
- arm64: handle 52-bit physical addresses in page table entries (2017, v4.16-rc1)

52bit 유저 공간

커널 v5.0-rc1에서 52비트 유저 공간을 지원한다. (4 Peta Bytes)

사용 제약
- ARMv8.2-LPA 기능을 지원하는 아키텍처
- 64K 페이지 사용
참고: arm64: mm: introduce 52-bit userspace support (2018, v5.0-rc1)

52bit 커널 공간

커널 v5.4-rc1에서 52비트 커널 공간을 지원한다. (4 Peta Bytes)

ARMv8.2-LPA 기능을 지원하는 아키텍처
64K 페이지 사용
이 기능이 동작하면서 52bit 유저 공간만 지원하던 것이 이제 유저 및 커널 모두 같은 52bit 커널 공간으로 사용한다.
- 즉 유저용은 52bit, 커널용은 48비트와 같이 나눠서 설정하는 번거로움을 아예 불가능하게 제거하였다.
참고: arm64: mm: Introduce 52-bit Kernel VAs (2019, v5.4-rc1)

커널 및 유저 공간 분리

유저에서 커널 공간의 분리
- swapper 및 trampoline 두 커널 페이지 테이블을 사용한다.
커널에서 유저 공간의 분리
- ARMv8.1의 PAN(Privileged Access Never) 기능을 사용하거나, 이러한 기능이 없는 경우 소프트웨어 에뮬레이션 방법(CONFIG_ARM64_SW_TTBR0_PAN)을 사용한다.
참고: KAISER: hiding the kernel from user space | LWN.net

다음 그림과 같이 ARM64 시스템에서 커널 공간을 담당하는 TTBR1과 유저 공간을 담당하는 TTBR1을 사용하여 각각의 커널 모드와 유저 모드에서 상대방의 영역을 사용하지 못하게 분리하는 방법을 보여준다.

ASID(Address Space IDentification )

mm 스위칭 후 TLB 캐시 및 명령 캐시에 대한 높은 비용의 플러시를 억제하기 위해 ASID를 이용한 가상 주소의 중복을 허용하게 하였다. 이를 이용하여 각각의 태스크 마다 유니크하게 식별할 수 있도록 ASID를 발급하여 구분한다. 그런데 이 ASID는 ARM32의 경우 8 bit 만을 허용하고, ARM64의 경우 8 bit 또는 16 bit를 지원한다. 이 때문에 리눅스 커널에서 태스크의 식별에 사용하는 pid를 사용하지 못하고 별도로 ASID 발급 관리를 수행한다

참고: Scheduler -7- (Preemption & Context Switch) | 문c

SDEI(Software Delegated Exception Interface)

펌웨어(Secure)가 OS 및 하이퍼바이저로 시스템 이벤트를 전달하기 위한 메커니즘이다.

인터럽트 마스킹 및 critical section에 의해 지연되면 안되는 exception을 처리한다.
주 사용 케이스
- 시스템 에러 핸들링(RAS)
- 시스템 감시(watchdog)
- 커널 디버깅
- 샘플 프로파일링
- 유저 모드에서 trampoline 페이지 테이블을 사용한 커널 감추기
참고: SDEI: Software Delegated Exception Interface | Trusted Firmware-A

커널(어셈블리) 시작 전 준비

시작하기에 앞서 몇 가지 어셈블리 명령 및 어셈블리 지시어등을 미리 알고 시작해야 분석에 소요되는 시간을 절약할 수 있다.

어셈블리 명령들
- b, bl
- lda, sta, ldp, stp
- mov, adr
- add, sub, tst, cmp
- mrs, msr
- …
  - 참고: ARM Architecture Reference Manual – 다운로드 pdf
어셈블리 지시어들
- .macro, .endm
- .align, .globl, .local, weak, .L
- .size, .quad, .long
- .if, .endif
- …
  - 참고: 어셈블리 지시자들 | gnu.org

위의 기본 명령과 지시어를 이해한 후에는 다음 항목들에 대해서 필요할 때마다 확인한다.

명령 뒤에 붙는 conditional branch 명령들
주소 참조에 사용되는 addressing mode들
- 참고: Addressing Mode (AArch64) | 문c

참고할 어셈블리 명령

adrp 명령

AArch64:
- adrp Xd, label
Address of 4KB page at a PC-relative offset.
현재 주소(pc)로부터 +-4G 주소까지의 label 주소를 알아와서 Xd 레지스터에 저장한다.
참고: Addressing Mode (AArch64) | 문c

eret 명령 – Exception Layer 이동

AArch64:
- eret
현재 Exception Level을 읽어오는 방법은 Read Only인 CurrentEL 레지스터를 읽어오면 알 수 있다. eret 명령을 사용하여 exception 발생 전으로 돌아갈 수 있는데 돌아갈 EL 모드 정보가 포함된 PSTATE 값을 pspr_elx 레지스터에 저장하고, 복귀할 주소가 담겨 있는 lr 레지스터의 값을 elr_elx 레지스터에 저장한 후 eret 명령을 사용하면 원하는 EL 및 주소로 이동이 가능하다. 단 상위 레이어로의 이동은 불가능하다.
eret 명령은 실제 exception과 pair로만 사용되는 것이 아니라, exception 없이 EL 전환과 특정 주소로 이동시킬 수 있다.
참고: AArch64 Exception Levels | Mike’s

csel(condition select) 명령

AArch64:
- csel Xd, Xn, Xm, #cond
컨디션(#cond)이 true인 경우 Xn을 선택하여 Xd에 대입하고, false인 경우 Xm을 선택한 후 Xd에 대입한다.
- Xd = #cond ? Xn : Xm

ubfx 명령

AArch64:
- ubfx Xd, Xn, #lsb, #width
Xn에서 #lsb 비트 위치 부터 msb 방향으로 #width 비트 수만큼 읽어 Xd에 대입한다.
- 예) Xn=0x1234_5678_9abc_def0, #lsb=4, #width=8
  - Xd=0xef

bic(BitwIse Clear)

AArch64:
- bic Xd, Xn, #op2
Xn에서 #op2 비트들을 클리어하여 Xd에 대입한다.
Xd = Xn & ~op2
- 예) Xn=0x1234_5678_9abc_deef0, #op2=0xfff
  - Xd=0x1234_5678_9abc_d000

bfi(Bit Field Insert) 명령

AArch64:
- bfi Xd, Xn, #lsb, #width
Xn 레지스터 값에서 하위 #width 비트 수 만큼의 값을 Xd의 #lsb 비트 위치에 끼워넣는다.
- 예) Xd=0x1111_2222_3333_4444, Xn=0x1234_5678_9abc_def0, #lsb=4, #width=8
  - Xd=0x1111_2222_3333_4f04

clz(Count Leading Zero) 명령

AArch64:
- clz Xd, Xn
0으로 시작하는 비트가 몇 개인지 센다.
- 예) Xn=0x0000_00f1_1234_0000
  - Xd = 24

PC 상대(PC-relative) 주소 지정 매크로

현재 위치 PC 레지스터로부터 +- 4G 주소 범위 이내에 위치한 심볼 위치에 접근할 때 사용되는 매크로 3개를 알아본다.

adr_l 매크로

arch/arm64/include/asm/assembler.h

/*
 * Pseudo-ops for PC-relative adr/ldr/str <reg>, <symbol> where
 * <symbol> is within the range +/- 4 GB of the PC.
 */
        /*
         * @dst: destination register (64 bit wide)
         * @sym: name of the symbol
         */

.       .macro  adr_l, dst, sym
        adrp    \dst, \sym
        add     \dst, \dst, :lo12:\sym
        .endm

현재 주소에서 +-4G 이내 범위에 위치한 심볼 주소 @sym에 대한 주소를 @dst 레지스터에 알아온다.

ldr_l 매크로

arch/arm64/include/asm/assembler.h

.       /*
         * @dst: destination register (32 or 64 bit wide)
         * @sym: name of the symbol
         * @tmp: optional 64-bit scratch register to be used if <dst> is a
         *       32-bit wide register, in which case it cannot be used to hold
         *       the address
         */

.       .macro  ldr_l, dst, sym, tmp=
        .ifb    \tmp
        adrp    \dst, \sym
        ldr     \dst, [\dst, :lo12:\sym]
        .else
        adrp    \tmp, \sym
        ldr     \dst, [\tmp, :lo12:\sym]
        .endif
        .endm

현재 주소에서 +-4G 이내범위에 위치한 심볼 @sym 주소의 값을 32비트 또는 64비트 @dst 레지스터에 담아온다. 만일 @dst 레지스터가 32비트인 경우 @tmp에 64비트 레지스터를 지정해야 한다. @tmp 레지스터는 사용 후 파손된다.

str_l 매크로

arch/arm64/include/asm/assembler.h

.       /*
         * @src: source register (32 or 64 bit wide)
         * @sym: name of the symbol
         * @tmp: mandatory 64-bit scratch register to calculate the address
         *       while <src> needs to be preserved.
         */

.       .macro  str_l, src, sym, tmp
        adrp    \tmp, \sym
        str     \src, [\tmp, :lo12:\sym]
        .endm

현재 주소에서 +-4G 이내 범위에 위치한 심볼 @sym 주소에 32비트 또는 64비트 @dst 레지스터 값을 기록한다.

mov_q 매크로

include/asm/assembler.h

/*
 * mov_q - move an immediate constant into a 64-bit register using
 *         between 2 and 4 movz/movk instructions (depending on the
 *         magnitude and sign of the operand)
 */

.macro  mov_q, reg, val
        .if (((\val) >> 31) == 0 || ((\val) >> 31) == 0x1ffffffff)
            movz    \reg, :abs_g1_s:\val
        .else
            .if (((\val) >> 47) == 0 || ((\val) >> 47) == 0x1ffff)
                movz    \reg, :abs_g2_s:\val
            .else
                movz    \reg, :abs_g3:\val
                movk    \reg, :abs_g2_nc:\val
            .endif
            movk    \reg, :abs_g1_nc:\val
        .endif
        movk    \reg, :abs_g0_nc:\val
.endm

상수값 @val을 64비트 레지스터인 @reg에 대입한다. 한 개의 어셈블리 코드로 모든 64비트 상수를 대입시킬 수 없으므로, 상수를 16비트씩 나누어 최소 2회에서 최대 4회에 걸쳐 대입한다.

예) 다음 명령을 수행하는 경우 다음과 같이 4회에 걸쳐 mov 명령을 사용하도록 어셈블된다.

mov_q x2, 0x4000300020001

mov     x2, #0x4000000000000            // x2 <- 0x4_0003_0002_0001
movk    x2, #0x3, lsl #32
movk    x2, #0x2, lsl #16
movk    x2, #0x1

:abs_g1_s: & :abs_g1:

_s 접미사가 붙으면 절대 값 g1 영역의 signed 값을 의미한다.
3 개의 g0 ~ g3 영역은 16비트씩 사용되며 다음과 같이 구분한다.
- g0=bits[15:0]
- g1=bits[31:16]
- g2=bits[47..32]
- g3=bits[63..48]
참고: Assembly expressions | ARM

:lo12:

하위 12비트 값을 의미한다.

커널(어셈블리) 시작

_head:

arch/arm64/kernel/head.S

/*
 * Kernel startup entry point.
 * ---------------------------
 *
 * The requirements are:
 *   MMU = off, D-cache = off, I-cache = on or off,
 *   x0 = physical address to the FDT blob.
 *
 * Note that the callee-saved registers are used for storing variables
 * that are useful before the MMU is enabled. The allocations are described
 * in the entry routines.
 */

        __HEAD
        /*
         * DO NOT MODIFY. Image header expected by Linux boot-loaders.
         */
        efi_signature_nop                       // special NOP to identity as PE/COFF executable
        b       primary_entry                   // branch to kernel start, magic
        .quad   0                               // Image load offset from start of RAM, little-endian
        le64sym _kernel_size_le                 // Effective size of kernel image, little-endian
        le64sym _kernel_flags_le                // Informative flags, little-endian
        .quad   0                               // reserved
        .quad   0                               // reserved
        .quad   0                               // reserved
        .ascii  ARM64_IMAGE_MAGIC               // Magic number
        .long   .Lpe_header_offset              // Offset to the PE header.

        __EFI_PE_HEADER

부트 로더로 부터 처음 진입되는 커널 코드 시작점이다.

부트 로더로 부터 커널 코드 시작인 _head에 진입하기 전에 다음 규칙이 적용된다.
- MMU는 off 되어 있어야 한다.
  - 참고: Why MMU and D-Cache must be off at Startup point in ARM64 | more or less insightful
  - D-Cache는 off 되어 있어야 한다.
- I-Cache는 on/off 상관 없다.
- x0 레지스터에는 DTB 시작 물리 주소가 담겨 있어야 한다.
  - 참고: Open Firmware and Devicetree | Kernel.org
- x0~x3까지의 레지스터를 커널(callee)이 보존해야 한다.
- 커널 진입 전 부트 로더 등에서 처리하는 일에 대해 다음을 참고한다.
  - 참고: Booting AArch64 Linux | Kernel.org
코드 라인 1에서 이후의 코드가 a(allocation) 및 x(execution) 속성을 가진 섹션 “.head.text”에 위치하도록 컴파일러에 지시한다.
코드 라인 5에서 ccmp(conditional compare) 명령이 처음 시작되지만 이 명령의 결과는 전혀 의미가 없는 nop 처럼 사용된다. 이를 통해 실제 목표는 UEFI 지원 커널인지 여부를 알아내는 식별자(처음 2바이트가 “MZ” 아스키 코드)로 사용된다.
코드 라인 6에서 실제 코드가 있는 primary_entry 레이블로 이동한다.
코드 라인 7~16에서 커널 이미지 정보이다.

__HEAD

include/linux/init.h

#define __HEAD          .section        ".head.text","ax"

이후의 코드가 a(allocation) 및 x(execution) 속성을 가진 섹션 “.head.text”에 위치하도록 컴파일러에 지시한다.

efi_signature_nop 매크로

        .macro  efi_signature_nop
#ifdef CONFIG_EFI
.L_head:
        /*
         * This ccmp instruction has no meaningful effect except that
         * its opcode forms the magic "MZ" signature required by UEFI.
         */
        ccmp    x18, #0, #0xd, pl
#else
        /*
         * Bootloaders may inspect the opcode at the start of the kernel
         * image to decide if the kernel is capable of booting via UEFI.
         * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
         */
        nop
#endif
        .endm

ccmp(conditional compare) 명령이 처음 시작되지만 이 명령의 결과는 전혀 의미가 없는 nop 처럼 사용된다. 이를 통해 실제 목표는 UEFI 지원 커널인지 여부(DOS 헤더 포함)를 알아내는 식별자(처음 2바이트가 “MZ” 아스키 코드)로 사용된다.

코드 라인 2~8에서 CONFIG_EFI 커널 옵션을 사용하여 빌드하면 UEFI BIOS를 지원하게 되는데, 커널 이미지의 시작 위치 2바이트에 DOS 헤더를 알리는 “MZ” 아스키 코드가 있어야 한다. 따라서 MZ 문자가 들어가면서 특별히 시스템에 영향을 주지 않는 명령을 골라 사용한 결과로 ccmp를 사용하였다.
- arm 및 arm64 모두 아키텍처가 빅 엔디안 모드와 리틀 엔디안 모드가 지원되는데, 위의 ccmp 명령은 0xfa40_5a4d이며 이를 디폴트 설정인 리틀 엔디안으로 빌드한 이미지에서 최초 4바이트는 다음과 같이 거꾸로 표현한다.
  - 4d 5a 40 fa (4d 5a가 각각 ‘M’과 ‘Z’ 아스키 문자)
코드 라인 9~16에서 CONFIG_EFI 커널 옵션을 사용하지 않는 경우 처음 4바이트 명령에 아무 결과도 수행하지 않고 명령 사이클만 소모시키는 nop 명령으로 시작한다.

커널 이미지 헤더

압축 해제 상태의 커널 이미지는 다음과 같이 64바이트의 커널 이미지 헤더이고, DOS 헤더 형태와 호환되도록 최초 2 바이트를 “MZ” 아스키 문자열을 사용하여 만들어졌고, 리틀 엔디안 포맷으로 구성되어 있다.

  u32 code0;                    /* Executable code */
  u32 code1;                    /* Executable code */
  u64 text_offset;              /* Image load offset, little endian */
  u64 image_size;               /* Effective Image size, little endian */
  u64 flags;                    /* kernel flags, little endian */
  u64 res2      = 0;            /* reserved */
  u64 res3      = 0;            /* reserved */
  u64 res4      = 0;            /* reserved */
  u32 magic     = 0x644d5241;   /* Magic number, little endian, "ARM\x64" */
  u32 res5;                     /* reserved (used for PE COFF offset) */

code0/code1
- stext로의 jump 코드가 있다.
  - 예) ccmp x18, #0, #0xd, pl 또는 add x13, x18, #0x16
  - b primary_entry
- 시스템에 UEFI 펌웨어가 있는 경우 이 코드는 skip 하며, UEFI의 PE 헤더에 포함된 entry 포인터(efi_stub_entry)로 jump 한다. 그 후 다시 code0 위치로 jump 한다.
text_offset
- 이미지의 로드 offset 이다. (v3.17 이전에는 0x80000 값이 엔디안 지정없이 기록되어 있다.)
- 커널 v4.7 이후부터 text_offset 값은 0을 사용한다.
  - 참고: arm64: don’t map TEXT_OFFSET bytes below the kernel if we can avoid it (2016, v4.7-rc1)
flags
- bit0: 커널의 엔디안 (1=BE, 0=LE)
- bit1~2: 커널 페이지 사이즈 (0=Unspecified, 1=4K, 2=16K, 3=64K)
- bit3: 2M 정렬된 커널 이미지의 커널 물리 위치(Kernel Physical Placement) (0=DRAM의 시작 위치로 부터 근접, 1=DRAM의 모든 영역)
image_size
- 이미지 사이즈 (v3.17 이전에는 0 값이 기록되어 있다.)
magic
- AMR64 이미지임을 나타내는 식별 문자열로 “ARMd“이다.

다음과 같이 커널(vmlinux)을 덤프해본다. ELF 헤더 + DOS 헤더 + UEFI PE 헤더등으로 시작한다.

ELF 헤더 (64 바이트)
- ELF
  - ELF(Excutable and Linkable Format)
  - 커널 이미지의 첫 부분에는 ELF 헤더가 있고, 이를 식별할 수 있도록 “ELF” 아스크코드 문자열을 볼 수 있다.
DOS 헤더 (64 바이트)
- MZ
  - vmlinux 파일은 위의 ELF를 포함하고 0x10000 offset을 가지므로, UEFI를 지원하는 커널인 경우 아래와 같이 0x10000 주소만큼 떨어진 위치에서 “MZ” 아스키코드 문자열을 볼 수 있다.
  - MZ 문자열로 시작하는데 DOS 호환을 위해 사용되었다.
- ARMd
  - ARM64 커널 이미지라는 것을 알 수 있도록 0x10038 주소에서 “ARMd” 아스키 코드 문자열을 볼 수 있다.
EFI PE 헤더
- PE
  - EFI(Extensible Firmware Interface) PE(Portable Excutable)
  - UEFI 헤더를 식별할 수 있도록 “PE” 아스키 코드 문자열을 볼 수 있다.

$ hexdump -C vmlinux
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  03 00 b7 00 01 00 00 00  00 00 00 10 00 80 ff ff  |................|
00000020  40 00 00 00 00 00 00 00  50 cb cf 01 00 00 00 00  |@.......P.......|
00000030  00 00 00 00 40 00 38 00  03 00 40 00 1c 00 1b 00  |....@.8...@.....|
...
*
00010000  4d 5a 00 91 ff bf 51 14  00 00 00 00 00 00 00 00  |MZ....Q.........|
00010010  00 00 d8 01 00 00 00 00  0a 00 00 00 00 00 00 00  |................|
00010020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00010030  00 00 00 00 00 00 00 00  41 52 4d 64 40 00 00 00  |........ARMd@...|
00010040  50 45 00 00 64 aa 02 00  00 00 00 00 00 00 00 00  |PE..d...........|
00010050  00 00 00 00 a0 00 06 02  0b 02 02 14 00 00 55 01  |..............U.|
00010060  00 00 86 00 00 00 00 00  fc 5e 51 01 00 00 01 00  |.........^Q.....|
00010070  00 00 00 00 00 00 00 00  00 00 01 00 00 02 00 00  |................|

ELF 파일이 아닌 Image 파일을 덤프해본다. ELF 헤더가 제외되고, DOS 헤더 + UEFI 헤더등으로 시작하는 것을 알 수 있다.

$ hexdump -C arch/arm64/boot/Image
00000000  4d 5a 00 91 ff bf 51 14  00 00 00 00 00 00 00 00  |MZ....Q.........|
00000010  00 00 d8 01 00 00 00 00  0a 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  41 52 4d 64 40 00 00 00  |........ARMd@...|
00000040  50 45 00 00 64 aa 02 00  00 00 00 00 00 00 00 00  |PE..d...........|
00000050  00 00 00 00 a0 00 06 02  0b 02 02 14 00 00 55 01  |..............U.|
00000060  00 00 86 00 00 00 00 00  fc 5e 51 01 00 00 01 00  |.........^Q.....|
00000070  00 00 00 00 00 00 00 00  00 00 01 00 00 02 00 00  |................|

ELF Header

참고: ELF Relocations (AArch64) | 문c

DOS Header

실제 DOS Header 규격은 다음과 같다.

typedef struct _IMAGE_DOS_HEADER
{
                        // Cumulative size:
     WORD e_magic;      // 2
     WORD e_cblp;       // 4
     WORD e_cp;         // 6
     WORD e_crlc;       // 8
     WORD e_cparhdr;    // 10
     WORD e_minalloc;   // 12
     WORD e_maxalloc;   // 14
     WORD e_ss;         // 16
     WORD e_sp;         // 18
     WORD e_csum;       // 20
     WORD e_ip;         // 22
     WORD e_cs;         // 24
     WORD e_lfarlc;     // 26
     WORD e_ovno;       // 28
     WORD e_res[4];     // 36
     WORD e_oemid;      // 38
     WORD e_oeminfo;    // 40
     WORD e_res2[10];   // 60
     LONG e_lfanew;     // 64
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

UEFI(Unified Extensible Firmware Interface)

ARM64 시스템에서도 UEFI 펌웨어가 내장된 서버들이 있다. 이러한 커널에서는 CONFIG_EFI가 반드시 필요하다.
- 참고: UEFI(Unified Extensible Firmware Interface) Specification | uefi.org
UEFI 펌웨어는 디바이스 정보를 자동으로 인식하거나 수동 설정된 내용을 ACPI 테이블로 변환하여 부트로더 및 커널에 전달한다. 부트 로더 및 커널은 이 정보를 가지고 시스템을 초기화한다. 이렇게 UEFI가 전달하는 ACPI 테이블이 없는 임베디드 시스템들은 Device Tree 스크립트를 작성하여 컴파일한 FDT/DTB(Flattened Device Tree / Device Tree Blob) 스타일로 디바이스 정보를 전달한다. 최근엔 주요 정보는 ACPI로 전달하고, FDT/DTB로 추가 전달하는 경우도 있다.
- 참고: ACPI on ARMv8 Servers | Kernel.org

primary_entry:

arch/arm64/kernel/head.S

        __INIT

        /*
         * The following callee saved general purpose registers are used on the
         * primary lowlevel boot path:
         *
         *  Register   Scope                      Purpose
         *  x20        primary_entry() .. __primary_switch()    CPU boot mode
         *  x21        primary_entry() .. start_kernel()        FDT pointer passed at boot in x0
         *  x22        create_idmap() .. start_kernel()         ID map VA of the DT blob
         *  x23        primary_entry() .. start_kernel()        physical misalignment/KASLR offset
         *  x24        __primary_switch()                       linear map KASLR seed
         *  x25        primary_entry() .. start_kernel()        supported VA size
         *  x28        create_idmap()                           callee preserved temp register
         */

SYM_CODE_START(primary_entry)
        bl      preserve_boot_args
        bl      init_kernel_el                  // w0=cpu_boot_mode
        mov     x20, x0
        bl      create_idmap

        /*
         * The following calls CPU setup code, see arch/arm64/mm/proc.S for
         * details.
         * On return, the CPU will be ready for the MMU to be turned on and
         * the TCR will have been set.
         */
#if VA_BITS > 48
        mrs_s   x0, SYS_ID_AA64MMFR2_EL1
        tst     x0, #0xf << ID_AA64MMFR2_LVA_SHIFT
        mov     x0, #VA_BITS
        mov     x25, #VA_BITS_MIN
        csel    x25, x25, x0, eq
        mov     x0, x25
#endif
        bl      __cpu_setup                     // initialise processor
        b       __primary_switch
SYM_CODE_END(primary_entry)

커널 코드가 처음 시작되는 .init.text 섹션이다. 어셈블리 코드를 통해 임시 페이지 매핑을 수행한 후 boot cpu의 MMU 장치를 켜서 가상 주소 환경이 동작되도록 페이징 활성화한다. 그 후 C 함수로 작성된 커널의 시작 위치인 start_kernel() 함수로 진입한다. 참고로 boot cpu가 아닌 나머지 cpu 코어들은 secondary core라고 불리고 이들은 아직 시작하지 않는 상태로 있다. 시스템마다 조금씩 다르지만 특정 주소에서 스핀(spin)하며 대기 중에 있거나 또는 전원이 꺼져있는 상태로 시작한다.

코드 라인 1에서기존에 stext 라는 레이블을 사용했었는데 primary_entry 레이블로 변경되었다. 헤더들을 빼면 진정한 커널 시작점이라고 할 수 있다.
- 참고: arm64: rename stext to primary_entry (2020, v5.8-rc1)
코드 라인 2에서 부트로더가 전달해준 x0 ~ x3 레지스터들을 boot_args 위치에 보관해둔다.
- setup_arch() 마지막 부분에서 저장된 boot_args[] 값들 중 x1~x3에 해당하는 값이 0이 아닌 값이 있는 경우 다음과 같은 경고 메시지를 출력한다.
  - “WARNING: x1-x3 nonzero in violation of boot protocol: …“
코드 라인 3에서 리눅스 커널이 el2로 부팅한 경우 하이퍼 바이저에 관련된 설정들을 수행한다.
코드 라인 4~5에서 DTB 물리 주소를 x20에 옮긴 후, 커널에 대해 임시로 사용할 init_idmap 및 init 페이지 테이블을 생성한다.
코드 라인 13~20에서 52비트 가상 주소를 지원하는 커널인 경우 코드를 통해 mmfr2_el1 레지스터에서 LVA(Large Virtual Address) 기능이 지원되는 것을 확인해본다. 만일 확인된 경우 유저 가상 주소를 표현하는 비트 수를 52로하여 x0에 대입한다. 그렇지 않은 경우 VA_BITS_MIN을 사용한다.
- 즉 52비트를 지원하는 커널에서 cpu가 52비트를 지원하는지 여부를 알아보고 다음 둘 중 하나를 선택한다.
  - 52비트 VA를 지원하는 아키텍처인 경우 VA_BITS(52)를 선택한다.
  - 52비트 VA를 지원하지 아키텍처인 경우 VA_BITS_MIN(48)을 선택한다.
코드 라인 21에서 프로세서를 초기화한다.
코드 라인 22에서 MMU를 활성화시킨 후 start_kernel() 함수로 점프한다.

__INIT

include/linux/init.h

#define __INIT          .section        ".init.text","ax"

이후의 코드가 a(allocation) 및 x(execution) 속성을 가진 섹션 “.init.text”에 위치하도록 컴파일러에 지시한다.

.init 섹션에 위치한 코드 및 데이터는 커널이 부팅한 후 더이상 필요 없으므로 추후 커널의 물리 메모리를 관리하는 버디 시스템으로 되돌려 활용하는 것으로 메모리를 절약한다.

VA_BITS vs VA_BITS_MIN

64비트 주소 버스를 사용하는 ARMv8 아키텍처의 경우 MMU를 사용하여 가상 주소를 사용할 수 있는데 그 크기는 ARMv8 아키텍처가 지원하는 몇 가지 크기가 제공된다. 그 크기의 조절은 ARMv8 아키텍처가 지원하는 PAGE_SIZE(4K, 16K, 64K)와 페이지 테이블 레벨(2, 3, 4)의 조합으로 VA_BITS=36, 39, 42, 47, 48, 52 중 하나를 선택하여 사용할 수 있다.

최초 ARMv8 아키텍처의 경우 64비트 주소 중 최대 48비트만을 가상 주소 영역에 사용할 수 있었는데 그 경우 최대 지원 가능한 가상 주소 영역의 크기는 2^48 = 256TB 크기 였다.

그 후, 더 큰 가상 주소 영역을 지원하기 위해 52비트의 LVA(Large Virtual Address) 기능을 탑재한 새 ARMv8.2 아키텍처가 만들어졌다. 이러한 경우 VA_BITS=52로 커널 이미지를 빌드하여 만들 수 있는데, 이렇게 빌드되어 만들어진 52비트 커널 이미지는 최대 가상 주소 영역에 48비트만을 사용하는 구형 아키텍처에서도 동작시킬 수도 있고, 52비트를 지원하는 최신 아키텍처에 둘 다에서 동작시킬 수 있다. 이러한 이유로 52비트에서 동작하는 커널을 만드는 경우 VA_BITS=52로 하되 VA_BITS_MIN=48로 값을 다르게하여 빌드 타임이 아닌 커널이 부트되는 런타임에 구형 아키텍처 및 신형 아키텍처를 판별하여 둘 중 하나를 선택하도록 코드를 구성하였다.

결국 VA_BITS 및 VA_BITS_MIN을 살펴보면 다음과 같이 VA_BITS=48비트까지는 VA_BITS_MIN 값도 동일하다. 그렇지만 VA_BITS=52비트인 경우 VA_BITS_MIN=48과 같이 두 값이 달라지는 것을 알 수 있다.

VA_BITS=36, VA_BITS_MIN=36
VA_BITS=39, VA_BITS_MIN=39
VA_BITS=42, VA_BITS_MIN=42
VA_BITS=47, VA_BITS_MIN=47
VA_BITS=48, VA_BITS_MIN=48
VA_BITS=52, VA_BITS_MIN=48

부트 시 전달된 인자(x0~x3) 저장

preserve_boot_args()

arch/arm64/kernel/head.S

/*
 * Preserve the arguments passed by the bootloader in x0 .. x3
 */

SYM_CODE_START_LOCAL(preserve_boot_args)
        mov     x21, x0                         // x21=FDT

        adr_l   x0, boot_args                   // record the contents of
        stp     x21, x1, [x0]                   // x0 .. x3 at kernel entry
        stp     x2, x3, [x0, #16]

        dmb     sy                              // needed before dc ivac with
                                                // MMU off

        add     x1, x0, #0x20                   // 4 x 8 bytes
        b       dcache_inval_poc                // tail call
SYM_CODE_END(preserve_boot_args)

부트로더가 전달해준 x0 ~ x3 레지스터들을 boot_args 위치에 보관해둔다. x0 레지스터는 DTB 주소로 사용되고, 나머지는 추후 사용하기 위해 예약되었다.

코드 라인 2~6에서 부트로더가 전달해준 x0 ~ x3 레지스터들을 boot_args 위치에 보관해둔다.
코드 라인 8에서 데이터 캐시를 invalidate하여 제거하기 전에 위의 stp 명령이 내부 버퍼에서 완전하게 마무리되도록 메모리 베리어를 사용한다.
- MMU가 꺼진 상태는 캐시를 사용하지 않지만 버퍼는 사용가능한 상태이다.
  - 참고로 MMU가 꺼져 있어도 버퍼를 통해 predictive 로딩은 가능한 상태이다.
- MMU가 꺼진 상태에서 캐시에 쓰레기 값이 존재할 수 있다. 따라서 해당 주소의 캐시는 비워두는 것이 추후 안전하다.
  - 쓰레기 캐시 값이 남아 있게되면 나중에 MMU가 켜진 후 캐시 라인을 clean 하거나 또는 자동으로 evict되는 경우 캐시에 있었던 쓰레기 값을 메모리에 덮어 기록하면서 의도하지 않는 일이 발생할 수 있다.
코드 라인 11~12에서 위에서 설명한 이유로 추후 잘못된 값이 읽히지 않도록 PoC 레벨까지 모든 cpu의 invalidate D-cache를 수행한다.

다음 두 그림을 통해 mmu-off 상태에서 메모리를 기록한 후 dmb와 dc ivac 명령을 사용하여 잠재적인 캐시 코히런스 문제를 제거한다.

- STR -> DMB -> DC IVAC 순서대로 처리한다.
- 참고: arm64: head: fix cache flushing and barriers in set_cpu_boot_mode_flag (2014, v3.16-rc1)

하이퍼 바이저 지원 코드 설정

init_kernel_el()

arch/arm64/kernel/head.S

/*
 * end early head section, begin head code that is also used for
 * hotplug and needs to have the same protections as the text region
 */
        .section ".idmap.text","awx"

/*
 * Starting from EL2 or EL1, configure the CPU to execute at the highest
 * reachable EL supported by the kernel in a chosen default state. If dropping
 * from EL2 to EL1, configure EL2 before configuring EL1.
 *
 * Since we cannot always rely on ERET synchronizing writes to sysregs (e.g. if
 * SCTLR_ELx.EOS is clear), we place an ISB prior to ERET.
 *
 * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in x0 if
 * booted in EL1 or EL2 respectively, with the top 32 bits containing
 * potential context flags. These flags are *not* stored in __boot_cpu_mode.
 */

SYM_FUNC_START(init_kernel_el)
        mrs     x0, CurrentEL
        cmp     x0, #CurrentEL_EL2
        b.eq    init_el2

el1 또는 el2 cpu가 현재 어떤 el 레벨로 커널에 진입했는지 알아오기 위해 CurrentEL 레지스터를 읽어온다. 그 후 레벨에 따라 init_el1 과 init_el2로 분기한다.

코드 라인 2~3에서 CurrentEL 값을 읽어 el2 레벨인지 비교한다.
- 커널 진입 시점의 boot cpu에서 CurrentEL 레지스터를 읽은 값은 CurrentEL_EL1(4) 또는 CurrentEL_EL2(8)이다.
코드 라인 4에서 만일 el2인 경우 init_el2로 점프하고, 그렇지 않은 경우 el1이므로 다음 행에 있는 init_el1: 레이블을 진행한다.

init_el1:

arch/arm64/kernel/head.S

SYM_INNER_LABEL(init_el1, SYM_L_LOCAL)
        mov_q   x0, INIT_SCTLR_EL1_MMU_OFF
        msr     sctlr_el1, x0
        isb
        mov_q   x0, INIT_PSTATE_EL1
        msr     spsr_el1, x0
        msr     elr_el1, lr
        mov     w0, #BOOT_CPU_MODE_EL1
        eret

코드 라인 2~3에서 MMU가 꺼진 상태 값으로 시스템 컨트롤 레지스터인 sctlr_el1 을 설정한다.
코드 라인 4에서 시스템 컨트롤 레지스터의 내용을 변경한 경우에는 isb 명령을 사용하여 파이프라인을 모두 비워야 한다.
코드 라인 5~6에서 EL1 전환을 위해 EL1 pstate 초깃값을 spsr_el1 레지스터에 지정한다.
- INTI_PSTATE_EL1 값에는 DAIF 플래그를 마스크하고 EL1 모드로 변경되도록 값이 지정되어 있다.
코드 라인 7에서 복귀할 주소를 지정하기 위해 lr 레지스터에 담긴 복귀 주소를 elr_el1 레지스터에 저장한다.
코드 라인 8에서 el1으로 복귀하는 것을 호출한 함수에서 알 수 있도록 w0 레지스터에 담는다. (반환 값은 el1을 의미하라고 0xe11)
코드 라인 9에서 exception return 명령을 통해 복귀한다.

INIT_PSTATE_EL1 & INIT_PSTATE_EL2 값

#define INIT_PSTATE_EL1 \
        (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT | PSR_MODE_EL1h)
#define INIT_PSTATE_EL2 \
        (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT | PSR_MODE_EL2h)

EL1 및 EL2의 PSTATE 초깃값으로 DAIF 플래그를 모두 마스크한 상태와 해당 EL 모드를 포함한다.

init_el2:

arch/arm64/kernel/head.S

SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
        mov_q   x0, HCR_HOST_NVHE_FLAGS
        msr     hcr_el2, x0
        isb

        init_el2_state

        /* Hypervisor stub */
        adr_l   x0, __hyp_stub_vectors
        msr     vbar_el2, x0
        isb

        mov_q   x1, INIT_SCTLR_EL1_MMU_OFF

        /*
         * Fruity CPUs seem to have HCR_EL2.E2H set to RES1,
         * making it impossible to start in nVHE mode. Is that
         * compliant with the architecture? Absolutely not!
         */
        mrs     x0, hcr_el2
        and     x0, x0, #HCR_E2H
        cbz     x0, 1f

        /* Set a sane SCTLR_EL1, the VHE way */
        msr_s   SYS_SCTLR_EL12, x1
        mov     x2, #BOOT_CPU_FLAG_E2H
        b       2f

1:
        msr     sctlr_el1, x1
        mov     x2, xzr
2:
        msr     elr_el2, lr
        mov     w0, #BOOT_CPU_MODE_EL2
        orr     x0, x0, x2
        eret
SYM_FUNC_END(init_kernel_el)

el2 에서 동작할 코드 및 exception stub 벡터들을 준비하고 el2 레지스터들을 초기화한다.

코드 라인 2~4에서 하이퍼바이저 설정 레지스터를 nVHE 모드로 설정한다.
코드 라인 6에서 nVHE를 위해 각종 EL2 레지스터들을 초기화한다.
코드 라인 9~11에서 nVHE를 위해 호스트 커널은 EL1으로 전환하여 동작하여야 한다. 따라서 EL2에 하이퍼 바이저 용도로만 사용할 stub 벡터가 필요하므로 이를 설치한다.
코드 라인 13에서 잠시 x1 레지스터에 EL1용 시스템 콘트롤레지스터에 저장할 초기값(mmu disable 포함)을 준비한다.
코드 라인 20~22에서 하이퍼바이저 설정 레지스터를 읽어와서 E2H 필드 값을 읽어와서 0인 경우 VHE를 지원하지 않으므로 1: 레이블로 이동한다.
코드 라인 25~27에서 아키텍처가 VHE 기능을 지원함을 확인했다. 조금 전에 x1 레지스터에 저장해두었던 값을 EL1용 시스템 컨트롤 레지스터에 저장하여 MMU를 확실하게 disable 한다. 그리고 VHE 기능을 활성화 하도록 E2H 비트를 x2레지스터에 담아 2: 레이블로 이동한다.
- VHE 모드에서 _el12 접미사를 사용하는 레지스터는 실제 el1 레지스터를 의미한다.
코드 라인 29~31에서 1: 레이블이다. 조금 전에 x1 레지스터에 저장해두었던 값을 EL1용 시스템 콘트롤레지스터에 저장하여 MMU를 확실하게 disable 한다.
코드 라인 32~36에서 2: 레이블이다. el2 부팅되었음을 알리는 값을 x0 레지스터를 통해 반환한다. (반환값: el2를 의미하라고 0xe12)
코드 라인 37에서 현재 EL2 모드에 있고, eret 명령을 사용하여 EL1 또는 EL2(같은 모드로도 가능) 모드로 전환하면서 elr_el2 레지스터에 저장한 복귀할 주소로 점프한다.
- primary_entry에서 bl init_kernel_el 명령을 사용했었었다. 이렇게 bl 명령을 사용하면 돌아올 위치를 lr 레지스터에 담아두었다는 것을 기억해야 한다.