initramfs 이미지에 파일을 첨부하세요 - 신뢰할 수 있나요?

initramfs 이미지에 파일을 첨부하세요 - 신뢰할 수 있나요?

저는 다양한 Linux 배포판의 여러 아카이브를 수정하고 있으며 initramfs일반적으로 하나의 파일만 변경합니다.

initramfs이미지 내의 모든 파일을 추출하고 다시 패키징하기 위해 루트 사용자로 전환할 필요 없이 프로세스를 자동화하고 싶습니다 .

먼저 파일 목록을 생성하려고 합니다.gen_init_cpio 아니요아카이브의 모든 내용을 추출합니다 . 즉, 모든 권한을 8진수로 변경하고 출력을 원하는 형식 으로 정렬하는 스크립트를 통해 initramfs출력 cpio -tvn initrd.img(예: 출력)을 구문 분석합니다. 예:ls -lgen_init_cpio

dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
slink /bin/sh busybox 777 0 0
file /bin/busybox initramfs/busybox 755 0 0

여기에는 몇 가지 대체가 포함되며 스크립트를 작성하기 어려울 수 있으므로 더 나은 방법을 찾았습니다. 얼마나 안전하고 이식성이 있는지 묻습니다.

일부 배포판에는 initramfs연결된 섹션이 포함된 파일이 있으며 분명히 커널은 전체 파일을 구문 분석하여 1바이트 경계로 묶인 모든 섹션을 추출하므로 각 섹션을 512바이트의 배수로 채울 필요가 없습니다. 나는 이 "기능"이 아카이브 내의 파일을 수정할 때 아카이브를 다시 생성하는 것을 방지하는 데 유용할 것이라고 생각합니다. 실제로는 적어도 Debianand 에서는 작동합니다 CloneZilla.

예를 들어 Debian 8.2.0 /init에서 파일을 수정한 경우 해당 파일을 이미지 initrd.gz에 추가할 수 있습니다 .initrd.gz

$ echo ./init | cpio -H newc -o | gzip >> initrd.gz

따라서 initrd.gz원래 아카이브와 수정된 아카이브라는 두 개의 연결된 아카이브가 있습니다. 결과를 보자 binwalk:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             gzip compressed data, maximum compression, has original file name: "initrd", from Unix, last modified: Tue Sep  1 09:33:08 2015
6299939       0x602123        gzip compressed data, from Unix, last modified: Tue Nov 17 16:06:13 2015

완벽하게 작동합니다. 하지만 믿을만한가요? 파일에 데이터를 추가할 때 제한 사항은 무엇입니까 initfamfs? 원본 아카이브를 512바이트 배수로 채우지 않고 추가해도 안전합니까? 이 기능을 지원하는 커널 버전은 무엇입니까?

답변1

내가 아는 한, initrd를 지원하는 모든 커널 버전에서 매우 안정적이고 지원됩니다. 이것이 cpio아카이브를 구성하는 요소의 특징입니다. 입력을 계속 추출합니다... 파일이 차례로 두 개의 cpio 아카이브라는 것을 알 수 있지만 cpio는 이를 단일 입력 스트림으로 처리합니다.initramfscpio

데비안에서는 이 방법(initramfs에 또 다른 cpio 연결)을 사용하여 설치 프로그램 initramfs에 바이너리 blob 펌웨어를 추가할 것을 권장합니다. 예를 들어:

데비안 설치 프로그램/Netboot 펌웨어 데비안 위키 |

Initramfs는 본질적으로 램디스크로 추출되어 Linux 커널에서 초기 사용자 공간으로 사용되는 gzip으로 압축된 cpio 아카이브를 연결한 것입니다. 데비안 설치 프로그램의 initrd.gz는 실제로 시작 시 설치 프로그램에 필요한 모든 파일이 포함된 gzip으로 압축된 cpio 아카이브입니다. 누락된 펌웨어 파일이 포함된 또 다른 gzip으로 압축된 cpio 아카이브를 첨부하기만 하면 됩니다!

답변2

아니요, 기존 initramfs입니다.압축된 아카이브에 첨부된 임의의 아카이브를 안정적으로 계속 구문 분석하려면 패딩이 필요합니다..

특히xz"레거시 프레임 형식"lz4압축은 까다로우며 4번 중 3번은 실패합니다. 특히 이전 아카이브의 바이트 수가 4로 나누어지지 않을 때마다 그렇습니다. 원시 형식=newc cpio를 앞에 배치할 때 개별 압축 아카이브에 대해 걱정할 필요가 없기 때문에 이는 종종 간과됩니다. 압축되지 않은 형식은 항상 정렬됩니다.

이론적으로 initramfs 형식은 아카이브의 단순한 연결(선택적으로 압축) 외에는 지정되지 않지만 압축 해제 루틴(경우에 따라 설계에 따라)이 한 아카이브가 끝나는 위치와 아카이브가 시작되는 다음 아카이브를 알 수 없는 경우 여전히 채워야합니다. 일부 극단적인 경우는 다음과 같습니다.Linux 버전 5.14의 개선 사항, 다른 것들은 커널에서 명시적으로 감지하기가 (불가능하지는 않지만) 어려워 보입니다. 압축된 아카이브 뒤에 추가 데이터가 있는 경우 다음과 같은 메시지가 해당 데이터가 무시되었음을 나타냅니다.

Initramfs unpacking failed: Decoding failed
Initramfs unpacking failed: invalid magic at start of compressed archive
Initramfs unpacking failed: broken padding

압축이 마지막 아카이브에만 적용되는 경우 이러한 메시지는 무해합니다. 더 이상 구문 분석되지 않지만 어쨌든 구문 분석할 항목이 없습니다.

관련 정보