Bootloader Internals · 15/37

FIT image 구조 분석 — multi-image·hash·configuration 추적

2026년 5월 9일 · Hawk · 6분 읽기

#한 줄 요약

FIT(Flattened Image Tree)는 kernel·DTB·ramdisk·overlay를 한 파일에 묶고, 각각에 hash와 서명을 붙이는 표준 컨테이너입니다. 한 이미지로 여러 보드를 지원하고, verified boot의 기초가 됩니다.

10~14장에서 본 부트 흐름은 kernel, DTB, ramdisk를 따로 적재했습니다. 파일이 셋이면 배포·검증이 모두 복잡합니다. 어느 하나가 옛 버전이면 무엇이 잘못됐는지 추적이 어렵습니다. FIT는 이 셋을 한 컨테이너에 묶고, 각 component에 hash·서명을 달아, 전체를 원자적으로 다루는 포맷입니다.

이 글에서는 FIT의 구조, ITS(Image Tree Source) 작성, mkimage로 빌드, U-Boot의 적재 흐름, configuration node, 그리고 hash·서명을 다룹니다.

#왜 FIT인가

uImage 시대에는 kernel 하나당 한 파일이었습니다. DTB는 따로, initramfs도 따로. 여기에 signature를 붙이려면 각 파일에 따로 서명을 만들어야 했습니다. 배포에서 한 파일이라도 빠지거나 잘못된 버전이면 부트가 실패합니다.

FIT는 이 문제를 device tree blob 형식의 컨테이너로 풉니다.

multi-image — kernel + DTB + ramdisk + DT overlay를 한 파일에.
configuration node — 같은 이미지에서 여러 보드/모델을 위한 조합 선택.
hash — 각 component에 hash 노드(SHA-256 등).
signature — configuration 또는 각 component에 서명.
압축 지원 — 각 component에 압축 지정(gzip, lzma, lz4, …).
로딩 주소 메타데이터 — load, entry 주소를 노드에 명시.

빌드 산출물은 .itb(Image Tree Binary)이고, U-Boot의 bootm 명령이 이해합니다.

#ITS 파일 — Image Tree Source

ITS는 device tree source 문법으로 작성합니다. 컴파일러는 mkimage(또는 dtc)입니다.

1
/dts-v1/;
2

3
/ {
4
    description = "Kernel and DTB for myboard";
5
    #address-cells = <1>;
6

7
    images {
8
        kernel-1 {
9
            description = "Linux kernel";
10
            data = /incbin/("./Image");
11
            type = "kernel";
12
            arch = "arm64";
13
            os = "linux";
14
            compression = "none";
15
            load = <0x40400000>;
16
            entry = <0x40400000>;
17
            hash-1 {
18
                algo = "sha256";
19
            };
20
        };
21

22
        fdt-1 {
23
            description = "DTB for myboard rev A";
24
            data = /incbin/("./myboard-revA.dtb");
25
            type = "flat_dt";
26
            arch = "arm64";
27
            compression = "none";
28
            load = <0x43000000>;
29
            hash-1 {
30
                algo = "sha256";
31
            };
32
        };
33

34
        fdt-2 {
35
            description = "DTB for myboard rev B";
36
            data = /incbin/("./myboard-revB.dtb");
37
            type = "flat_dt";
38
            arch = "arm64";
39
            compression = "none";
40
            load = <0x43000000>;
41
            hash-1 {
42
                algo = "sha256";
43
            };
44
        };
45

46
        ramdisk-1 {
47
            description = "Initramfs";
48
            data = /incbin/("./rootfs.cpio.gz");
49
            type = "ramdisk";
50
            arch = "arm64";
51
            os = "linux";
52
            compression = "gzip";
53
            load = <0x44000000>;
54
            hash-1 {
55
                algo = "sha256";
56
            };
57
        };
58
    };
59

60
    configurations {
61
        default = "conf-revA";
62

63
        conf-revA {
64
            description = "Boot Linux on myboard rev A";
65
            kernel = "kernel-1";
66
            fdt = "fdt-1";
67
            ramdisk = "ramdisk-1";
68
            hash-1 {
69
                algo = "sha256";
70
            };
71
        };
72

73
        conf-revB {
74
            description = "Boot Linux on myboard rev B";
75
            kernel = "kernel-1";
76
            fdt = "fdt-2";
77
            ramdisk = "ramdisk-1";
78
            hash-1 {
79
                algo = "sha256";
80
            };
81
        };
82
    };
83
};

images/ 안에 raw component들이 들어가고, configurations/ 안에 조합이 들어갑니다. 같은 kernel을 두 DTB와 조합해 두 보드 revision을 한 파일에 묶었습니다.

#빌드

mkimage로 ITS를 컴파일합니다.

1
mkimage -f myboard.its myboard.itb

내부적으로는 device tree compiler가 ITS를 binary blob으로 만들고, mkimage가 hash·서명을 채워 넣습니다. 결과 .itb 파일은 device tree 형식의 binary입니다. fdtdump나 dtc -I dtb -O dts로 들여다볼 수 있습니다.

1
$ fdtdump myboard.itb | head -30
2
/dts-v1/;
3
// magic:            0xd00dfeed
4
// totalsize:        0x12ab450
5
// off_dt_struct:    0x38
6
...
7
/ {
8
    description = "Kernel and DTB for myboard";
9
    images {
10
        kernel-1 {
11
            description = "Linux kernel";
12
            type = "kernel";
13
            ...
14
            hash-1 {
15
                algo = "sha256";
16
                value = <0xabcd1234 ...>;
17
            };
18
        };
19
    };
20
};

hash-1의 value가 mkimage 시점에 계산되어 채워진 것이 보입니다.

#U-Boot 측 적재 — `bootm`

.itb를 메모리에 적재한 뒤 bootm을 호출합니다.

1
=> load mmc 0:1 ${loadaddr} /boot/myboard.itb
2
=> bootm ${loadaddr}#conf-revA
3
## Loading kernel from FIT Image at 40200000 ...
4
   Using 'conf-revA' configuration
5
   Trying 'kernel-1' kernel subimage
6
     Description:  Linux kernel
7
     Type:         Kernel Image
8
     Compression:  uncompressed
9
     Data Start:   0x402000ec
10
     Data Size:    10995712 Bytes = 10.5 MiB
11
     Load Address: 0x40400000
12
     Entry Point:  0x40400000
13
     Hash algo:    sha256
14
     Hash value:   abcd1234...
15
     Verifying Hash Integrity ... sha256+ OK
16
## Loading fdt from FIT Image at 40200000 ...
17
   Using 'conf-revA' configuration
18
   Trying 'fdt-1' fdt subimage
19
     ...
20
     Verifying Hash Integrity ... sha256+ OK
21
## Loading ramdisk from FIT Image at 40200000 ...
22
   ...
23
Starting kernel ...

bootm ${loadaddr}#conf-revA의 #conf-revA가 configuration 이름입니다. 생략하면 default가 쓰입니다.

각 component를 지정된 load 주소로 복사하고, hash를 검증한 뒤, kernel entry로 점프합니다. 한 명령에 검증·압축 해제·재배치가 모두 들어 있습니다.

#bootargs 변수 통합

configuration 노드에 bootargs를 직접 둘 수도 있습니다.

1
configurations {
2
    conf-revA {
3
        kernel = "kernel-1";
4
        fdt = "fdt-1";
5
        ramdisk = "ramdisk-1";
6
        bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw";
7
        hash-1 { algo = "sha256"; };
8
    };
9
};

U-Boot 환경의 bootargs를 덮어쓰고 이미지 자체가 지정한 인자로 부팅합니다. OTA로 새 이미지를 배포할 때 환경 변수에 의존하지 않고 새 bootargs를 같이 보낼 수 있습니다.

#서명 추가 — verified boot의 기초

hash는 전송 오류 탐지에는 충분하지만, 공격자가 image와 hash를 같이 위조하면 무용지물입니다. 서명이 필요합니다.

1
configurations {
2
    default = "conf-revA";
3

4
    conf-revA {
5
        kernel = "kernel-1";
6
        fdt = "fdt-1";
7
        signature-1 {
8
            algo = "sha256,rsa2048";
9
            key-name-hint = "dev";
10
            sign-images = "kernel", "fdt", "ramdisk";
11
        };
12
    };
13
};

mkimage가 RSA 키로 서명을 만들어 value에 채워 넣습니다.

1
mkimage -f myboard.its -k keys/ -K u-boot.dtb -r myboard.itb

-k keys/ — 서명 키가 든 디렉터리
-K u-boot.dtb — 공개 키를 U-Boot의 control DTB에 박는다
-r — 서명을 required로 표시 (verified boot에서 강제)

U-Boot 측에서 CONFIG_FIT_SIGNATURE=y를 켜면 bootm이 서명 없는 FIT를 거부합니다. 공개 키는 U-Boot 빌드 시점에 control DTB에 들어 있으므로, 키 자체가 변조되어도 부트가 막힙니다.

16장에서 verified boot 전체 사슬을 다룹니다. FIT 서명은 그 마지막 단계의 빌딩 블록입니다.

#한 이미지로 여러 보드

configurations 노드의 강력함은 한 .itb로 여러 보드를 지원하는 데 있습니다. 양산 라인에서 보드 revision이 늘어날 때마다 별도 이미지를 빌드하지 않아도 됩니다.

1
# U-Boot 측에서 보드 자동 감지
2
=> setenv board_rev "revA"
3
=> bootm ${loadaddr}#conf-${board_rev}

또는 기본 configuration을 기본 fdt 매칭으로 자동 선택합니다.

1
configurations {
2
    default = "conf-revA";
3

4
    conf-revA {
5
        kernel = "kernel-1";
6
        fdt = "fdt-1";
7
        compatible = "vendor,myboard-revA";   /* 보드 compatible과 매칭 */
8
    };
9
    conf-revB {
10
        kernel = "kernel-1";
11
        fdt = "fdt-2";
12
        compatible = "vendor,myboard-revB";
13
    };
14
};

U-Boot가 현재 보드의 root compatible과 일치하는 configuration을 자동 선택합니다. bootm에 #을 명시하지 않아도 됩니다.

#DT overlay 적용

DT overlay를 FIT 안에 두고, configuration에서 base + overlay 조합을 지정할 수 있습니다.

1
images {
2
    fdt-base { /* ... */ };
3
    fdt-overlay-camera { type = "flat_dt"; /* ... */ };
4
    fdt-overlay-display { type = "flat_dt"; /* ... */ };
5
};
6

7
configurations {
8
    conf-with-camera {
9
        kernel = "kernel-1";
10
        fdt = "fdt-base", "fdt-overlay-camera";
11
    };
12
};

U-Boot가 base DTB에 overlay를 적용한 결과를 커널에 넘깁니다. 같은 보드의 옵션 부품을 configuration 단위로 처리할 수 있습니다.

#자주 하는 실수

load 주소 충돌. kernel과 ramdisk의 load 주소가 겹치면 조용히 깨집니다. 적재 직후 ramdisk가 kernel을 덮어쓰거나 그 반대.
압축 type 불일치. ramdisk를 .cpio.gz로 만들고 ITS에 compression = "none"이라 쓰면 U-Boot는 압축 해제를 안 합니다. 부트 후 init이 실패.
default configuration이 서명되지 않음. signature-1 노드 없는 configuration이 default라면 CONFIG_FIT_SIGNATURE_STRICT=y에서 부트가 거부됩니다.
mkimage가 옛 버전. mkimage가 새 사양(예: configuration signing)을 모르면 ITS는 컴파일되지만 서명 노드는 비어 있습니다. U-Boot 트리에서 빌드한 mkimage를 쓰세요.
공개 키를 control DTB에 안 박았습니다. -K u-boot.dtb를 빼면 U-Boot가 검증할 키가 없어 모든 FIT를 거부합니다.

#정리

FIT는 kernel·DTB·ramdisk·overlay를 한 파일에 묶는 device tree 형식의 컨테이너입니다.
ITS는 device tree source 문법이고, mkimage로 .itb를 빌드합니다.
images/는 raw component, configurations/는 component 조합입니다.
bootm <addr>#<conf>로 configuration을 선택해 부팅합니다.
각 노드에 hash-1을 두면 전송 오류 탐지, signature-1을 두면 verified boot가 됩니다.
compatible 속성으로 보드별 configuration 자동 매칭이 가능합니다.
DT overlay를 configuration 안에서 base + overlay로 조합할 수 있습니다.

#다음 장 예고

다음 글에서는 verified boot의 전체 사슬을 봅니다. SoC ROM → SPL → U-Boot → FIT까지, 서명·해시가 어떻게 이어져 trust chain을 만드는지 정리합니다.

#관련 항목

Ch 14: bootflow / bootmeth — FIT를 적재하는 새 모델
Ch 16: Verified Boot — FIT 서명을 root of trust로
Ch 17: A/B 업데이트 — FIT 단위의 atomic update
Security Ch 2: Secure Boot — root of trust 개념
Security Ch 6: OTA Update — FIT와 OTA 결합
U-Boot FIT 문서

FIT image 구조 분석 — multi-image·hash·configuration 추적

#한 줄 요약

#왜 FIT인가

#ITS 파일 — Image Tree Source

#빌드

#U-Boot 측 적재 — `bootm`

#bootargs 변수 통합

#서명 추가 — verified boot의 기초

#한 이미지로 여러 보드

#DT overlay 적용

#자주 하는 실수

#정리

#다음 장 예고

#관련 항목

Bootloader Internals · 15 of 37

관련 글

U-Boot PCIe Enumeration — 부트로더가 디바이스를 찾는 흐름 분석

U-Boot Distro Boot — extlinux·boot.scr 표준화 분석

SPL·TPL 내부 해부 — 가장 작은 부트 단계의 동작 추적

이 글을 참조하는 글 (6)

#한 줄 요약

#왜 FIT인가

#ITS 파일 — Image Tree Source

#빌드

#U-Boot 측 적재 — bootm

#bootargs 변수 통합

#서명 추가 — verified boot의 기초

#한 이미지로 여러 보드

#DT overlay 적용

#자주 하는 실수

#정리

#다음 장 예고

#관련 항목

Bootloader Internals · 15 of 37

관련 글

U-Boot PCIe Enumeration — 부트로더가 디바이스를 찾는 흐름 분석

U-Boot Distro Boot — extlinux·boot.scr 표준화 분석

SPL·TPL 내부 해부 — 가장 작은 부트 단계의 동작 추적

이 글을 참조하는 글 (6)

#U-Boot 측 적재 — `bootm`