Embedded Linux용 OTA 업데이트, 파트 1 – 기본 사항 및 구현

업데이트의 필요성

Embedded Linux 제품이 실험실을 떠나 실제 세계에 들어가면 장치를 업데이트하는 방법에 대한 문제를 중요하게 고려해야 합니다.

업데이트가 항상 필요한 것은 아니지만 어느 시점에서 발견되는 버그가 없는 소프트웨어는 생각하기 어렵습니다. 소프트웨어가 완벽하더라도 장치가 네트워크 또는 인터넷에서 오픈 소스 라이브러리와 통신하면 보안 업데이트가 필수가 될 수 있습니다.

CVE-2104-01650(Heartbleed)의 예를 살펴보십시오. 이 취약점은 OpenSSL 암호화 라이브러리에 영향을 미치고 확장하여 네트워크 웹사이트의 3분의 2에 영향을 미쳤습니다. 3년이 지난 지금도 많은 Embedded Linux 장치가 공격에 취약한 OpenSSL의 방어되지 않은 버전을 실행하고 있습니다.

차단 vs 파일 업데이트

Linux 업데이트에 대해 이야기할 때 "차단" 및 "파일" 업데이트 시스템이 언급되는 것을 볼 수 있습니다. 이는 블록 장치에 직접 쓰기를 수행하거나 업데이트를 수행하기 위해 개별 파일을 업데이트하여 한 번에 전체 파티션을 업데이트하는 것을 말합니다. Desktop 또는 Server Linux의 파일 업데이트 시스템에 익숙할 것입니다(예:"sudo apt-get upgrade").

Embedded Linux에서 블록 기반 업그레이드는 원자성과 전체 파일 시스템이 일반적으로 Embedded Linux 빌드 시스템의 출력이라는 사실 때문에 가야 할 길입니다. 각 임베디드 장치의 저장 공간은 특정 제품에 대해 일정할 것으로 예상하므로 매번 동일한 크기의 파티션을 만듭니다. 이러한 유형의 업데이트는 일종의 폴백 또는 복구 이미지와 함께 사용됩니다.

실패 시 복구

우리는 장치를 사용할 수 없는 상태로 두는 것을 절대 원하지 않습니다(예:정전이 발생한 경우). 업데이트 프로세스에서 문제가 발생하는 경우 항상 다른 파티션으로 "폴백"할 수 있도록 하여 이 문제를 해결할 수 있습니다.

그림 1. 장애 발생 시 복구 – 대체 옵션(출처:ByteSnap)

위에서 정전 시 폴백 모드의 두 가지 가능한 구현을 볼 수 있습니다. 왼쪽에서 부트로더는 복구 파티션을 부팅한 다음 기본 파티션으로 부팅합니다. 오른쪽에서 부트로더는 스위치를 기반으로 두 파티션 중 하나를 부팅합니다.

부트로더는 부팅이 성공했는지 확인하는 몇 가지 방법을 구현해야 하며 그렇지 않은 경우 복구 파티션(왼쪽 다이어그램) 또는 이전 작업 파티션(오른쪽 다이어그램)으로 돌아가야 합니다.

구조 방법(왼쪽)을 사용하면 주 파티션에 더 많은 공간을 제공할 수 있는 반면 이중 rootfs 방법(오른쪽)은 두 파티션 사이에 공간을 어느 정도 균등하게 분할해야 합니다. 공간이 문제가 아닌 경우에는 가동 중지 시간이 줄어들기 때문에 이중 rootfs 방법을 사용하는 것이 좋습니다. 복구 방법을 통해 업데이트하려면 복구 파티션으로 한 번, 메인으로 다시 재부팅하는 두 번의 재부팅이 필요합니다. dual-rootfs 방법은 업데이트가 언제든지 수행될 수 있으므로 한 번만 재부팅하면 됩니다.

이러한 시스템에서 안전하게 업데이트할 수 없는 것은 부트로더(또는 실제로 복구 파티션)입니다. 부트로더도 업데이트할 수 있으려면 두 개의 별도 부트로더 파티션과 둘 사이를 전환하는 논리를 구현하기 위한 일종의 보드 관리 컨트롤러가 필요합니다.

그림 2. 장애 발생 시 복구 – 보드 관리 컨트롤러(출처:ByteSnap)

이것은 물론 추가 마이크로컨트롤러, 새로운 펌웨어 세트 및 더 복잡한 하드웨어 설계가 필요한 복잡한 솔루션입니다(예를 들어 별도의 IPMI(지능형 플랫폼 관리 인터페이스) 컨트롤러가 포함된 일부 장치에서 사용됨) . 따라서 기능적이고 범위가 작아 업데이트할 필요가 없는 부트로더를 구축하는 것을 목표로 해야 합니다.

U-Boot 환경 변수

U-boot는 변수를 저장할 수 있는 비휘발성 "환경"을 구현합니다. 이는 Linux에서도 액세스할 수 있습니다(elinux.org에 자세히 설명된 대로 환경이 저장되는 방식에 따라 다양한 방법으로 액세스할 수 있습니다.

이것은 위에서 설명한 "스위치"를 구현하는 가장 확실한 방법입니다. 또한 이전 부팅 성공 또는 실패에 대한 정보를 저장하는 데 사용할 수 있으므로 부팅 실패 시 스위치를 되돌리고 작업 파티션을 복원할 수 있습니다.

그림 3. U-boot 환경 변수(출처:ByteSnap)