실행 파일 자체가 SQLite 데이터베이스인 SELF

1 week ago 20

SELF(Structured Executable & Linkable Format) 는 실행 파일 자체를 SQLite 데이터베이스로 만들고, chmod +x 권한을 부여해 일반 바이너리처럼 실행하는 프로토타입임 ELF의 문자열 테이블·심볼 인덱스·섹션 헤더·버전 정보를 SQLite의 테이블·열·인덱스·외래 키로 대체해 readelf, ldd, strip, patchelf 작업을 SQL 쿼리와 트랜잭션으로 수행함 binfmt_misc가 SQLite 헤더의 SELF 식별자를 감지해 self-exec를 호출하면, 인터프리터가 세그먼트와 심볼을 읽어 메모리에 매핑하고 재배치한 뒤 진입점으로 이동함 SELF는 기본적으로 ELF보다 약 2배 크고 시작할 때 약 5ms의 고정 지연이 있지만, 선택 테이블을 제거한 coreutils는 ELF 대비 1% 이내 크기이며 1,123개 객체를 묶은 사용자 공간 데이터베이스는 원본 ELF 전체보다 작았음 실행 파일과 전이 의존성을 하나의 데이터베이스에 담으면 라이브러리 해석이 외래 키로 확정되고 중복 제거가 자연스럽게 적용되며, 사용자 공간 전체의 LD_PRELOAD 같은 변경도 원자적 트랜잭션으로 처리할 수 있음 ELF를 데이터베이스로 다시 보기 ELF는 이미 여러 데이터베이스 원리를 자체 형식으로 구현하고 있음 .strtab과 .dynstr는 문자열 인터닝, .hash와 .gnu.hash는 인덱스에 해당함 섹션 헤더 테이블은 테이블 목록인 sqlite_schema, st_name의 문자열 오프셋은 수작업 외래 키와 비슷함 sh_offset과 sh_size는 B-tree 페이지의 레코드 배치, .gnu.version_r는 열에 대응함 objcopy --strip-debug는 DELETE와 VACUUM, ldconfig 캐시와 debuginfod는 별도 인덱스 역할을 함 커널, ld.so, binutils, LIEF, goblin, readelf 등 ELF 소비자는 같은 파서를 반복 구현하며, 생성 도구도 동일한 직렬화 코드를 다시 구현함 ELF는 디스크와 네트워크가 극도로 제한되던 환경에 맞춰 조밀하게 설계돼 수정하기 어려움 데이터가 빈틈없이 배치되어 기존 섹션을 0으로 채우고 새 섹션을 추가해야 할 때가 있음 자체 기술 스키마가 없고 데이터 섹션의 해석을 관례에 의존하며, 형식 자체는 이를 강제하지 않음 SQLite는 자체 기술 형식이면서 안정성이 높고, 기존 소비자를 깨뜨리...

Read Entire Article