=============================================================== 제목 : Linux System Call - 구조 분석 및 간단한 Syscall 작성 작성일자 : 2002. 07. 30 수정일자 : 2003. 04. 10 문서버젼 : ver 0.0.5 라이센스 : GPL =============================================================== Linux System Call ======================================================= * 준비물 - i386이상 - 리눅스 머신 - 리눅스 source - binutils - glibc.a - nasm * test 환경 - os : redhat linux 6.2 - processor : pentium 2 333mhz - ram : 64mb 저는 linux kernel newbie 도 못되며 system call 이나 linux kernel 구조에 대해서도 초보 수준이니 틀린 내용이나 이상한 내용은 바로 메일로 씹어주세요. 제가 검증 후 바로 고쳐서 업데이트 하겠습니다. 이 문서는 결코 제 개인의 창작물이나 그런것이 아닌 다른이의 문서를 번역 분석작업을 했을 뿐입니다. (예를 들면, linus 가 linux의 기초를 세웠으며, FSF 와 같은 팀들이 이미 다한 작업들을 그저 공부하는것일 뿐이죠.) email : osx86@codesum.org ======================================================= 1. Linux Kernel Compile 우선 system call 을 만들고 나면 커널 컴파일에 대해서 알아야 되니까 대충 정리 해봤습니다. ////////////////////////////////////////////////////////////////////////////////// 1) 심볼릭 링크 삭제 rm -rf /usr/src/linux 2) 새로운 커널 소스 디렉토리를 위한 심볼릭 링크 생성 mkdir linux-major.minor.patch ls -s linux-major.minor.patch linux 3) 커널 소스 압축풀기 tar xvzf linux-major.minor.patch.tar.gz 4) 압축이 풀린 커널의 버젼이름으로 경로를 바꾸기 mv linux linux-major.minor.patch 5) 새로운 커널을 위한 심벌릭 링크 생성 및 확인 cd /usr/include rm -rf asm ln -s /usr/src/linux/include/asm-i386 /usr/include/asm ln -s /usr/src/linux/include/linux /usr/include/linux ls -l linux asm lrwxrwxrwx 1 root root 26 1월 17 10:46 asm - /usr/src/linux/include/asm-i386 lrwxrwxrwx 1 root root 28 1월 17 10:45 linux - /usr/src/linux/include/linux 4) 심볼릭 링크 디렉토리에서 기존 커널 의존성 삭제 make mrproper 5) 커널 설정작업 make menuconfig or make config 6) 커널 소스 파일 간 의존성검사 make dep 7) 과거 오브젝트 파일이나 구버젼 소스 파일 삭제 make clean 8) 커널 이미지 만들기 make zImage (압축커널을 만들때 ) make bzImage (일반적인 커널 만들때 ) make bzdisk (플로피 디스크에 저장할 커널 ) make zlilo (lilo.conf 자동화 ) 완성된 커널이미지의 위치는 /usr/src/linux/arch/[processor]/boot/bzImage 9. 모듈 컴파일 및 설치 make modules make modules_install 10. lilo 환경설정하기 vi /etc/lilo.conf lineardefault = 기본으로 부팅할 커널 이미지 label .... image=/커널 PATH/커널 이미지 이름 label = lilo 커맨드로 인식할 커널이름 read-only root = 루트 파일시스템 ////////////////////////////////////////////////////////////////////////////////// ( 커널 컴파일에 대해서 부족하게 설명이 되어있으므로, kldp 나 타 사이트에서 커널 컴파일에 대해서 먼저 익혀두세요. ) 2. System Call 구현을 위한 필요 지식 2-1). H/W 인터럽트 - Device -> PIC (인터럽트 발생) - PIC -> CPU (인터럽트 알림) - CPU -> PIC (어떤 장치에서 발생했는지 질의) - PIC -> CPU (인터럽트가 발생한 핀 넘버를 알림) - CPU -> Kernel (CPU는 핀넘버값을 Kernel 에게 알리고 커널은 IDT 에서 그와 매핑된 장치를 찾음) - Kernel -> interrupt function ( 인터럽트 함수 호출 ) 2-2). IDT(Interrupt Descriptor Table) 구성 0x0 ~ 0x1F - Trap Handler 0x20 ~ 0x7F - Interrupt Handler(IRQ) 0x80 - System Call ... 2-3). System Call 구현을 위한 과정 설명이 부족 했던것 같죠. 2-1) 에 대한 내용은 8259 PIC(Programmable Interrupt Controller 였던가) 하는놈에 대해서 좀 찾아보시면 이해가 될것같습니다. 그리고 2-2) 의 IDT 는 Intel Architecture Software Developers Manual 3 를 참조하시면 될것 같구요. 아니면 i386 이상으로 쓰여진 시스템 관련 서적이라면 있을겁니다. 우선 시스템 콜 작성을 위해서는 다음과 같은 과정을 거칩니다. System Call Table, Stub 을 고치고, 그리고 새로 만들 System Call 의 위치를 정합니다. 그 위치에 System Call을 구현합니다. 그리고 나서 만들어진 c 소스코드를 미리정해둔 /usr/src/linux/ 하위 디렉토리중 한곳에 넣고, OBJECT 파일 이름을 정해줍니다. 이제 커널 REBUILD를 하고, 새로 만들어진 커널 이미지로 부팅하게 LILO 혹은 다른 부트로더를 이용해 설정하고, 새로 부팅을 합니다. 별 문제 없이 부팅이 되었으면, 그 시스템 콜을 이용한 프로그램을 작성합니다. 그리고 실행해봅니다. 3. System Call 구현 우선 원하는 리눅스 커널 소스(/usr/src/linux)가 있는 곳으로 이동합니다. 3-1). System Call Stub System Call Stub 에 새로 생성할 시스템 콜 Name과 Number를 추가합니다. source: /usr/src/linux/include/asm-[processor]/unistd.h # System Call Stub define 파일 ================================================================================= #ifndef _ASM_I386_UNISTD_H_ #define _ASM_I386_UNISTD_H_ /* * This file contains the system call numbers. */ #define __NR_exit 1 #define __NR_fork 2 #define __NR_read 3 #define __NR_write 4 #define __NR_open 5 #define __NR_close 6 #define __NR_waitpid 7 ... ... #define __NR_sendfile 187 #define __NR_getpmsg 188 /* some people actually want streams */ #define __NR_putpmsg 189 /* some people actually want streams */ #define __NR_vfork 190 // 이 아래 한줄을 추가해주세요 #define __NR_mycall 191 ================================================================================= 리눅스 프로그래밍을 해보셨거나 관련 서적을 보셨던 분들은 알겁니다. 저는 -_- 몰랐습니다. 이게 먼가... 여튼 이 파일에 stub 과 system call 관련 인자에 따른 구현 방법이 있습니다. 그럼 stub 아랫 부분을 볼까요 ... ================================================================================= #define _syscall0(type,name) \ type name(void) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name)); \ __syscall_return(type,__res); \ } #define _syscall1(type,name,type1,arg1) \ type name(type1 arg1) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1))); \ __syscall_return(type,__res); \ } #define _syscall2(type,name,type1,arg1,type2,arg2) \ type name(type1 arg1,type2 arg2) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2))); \ __syscall_return(type,__res); \ } #define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \ type name(type1 arg1,type2 arg2,type3 arg3) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \ "d" ((long)(arg3))); \ __syscall_return(type,__res); \ } #define _syscall4(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4) \ type name (type1 arg1, type2 arg2, type3 arg3, type4 arg4) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \ "d" ((long)(arg3)),"S" ((long)(arg4))); \ __syscall_return(type,__res); \ } #define _syscall5(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \ type5,arg5) \ type name (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \ "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5))); \ __syscall_return(type,__res); \ } ================================================================================= 대충 이런것들이 보이죠. 저런식으로 argument 의 수에 따라 저런 식으로 정의해서 쓴다는 의미입니다. 아래에 또 나올테니 우선 간단히 짚어 보고 넘어 갑시다. 한놈만 족쳐봅시다. ================================================================================= #define _syscall2(type,name,type1,arg1,type2,arg2) \ type name(type1 arg1,type2 arg2) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2))); \ __syscall_return(type,__res); \ } ================================================================================= #define _syscall2(type,name,type1,arg1,type2,arg2) \ 우선 #define 을 보면 _syscall2 뒤에 숫자 2는 argument 가 두개라는 의미 입니다. 그리고 () 안의 내용을 잘 보시면, type 은 system call 의 return data type 입니다. 그리고 name 은 우리가 정의할 system 콜의 이름이 되겠지요. 우리는 mycall 이라고 system call 을 썻으니 나중에 구현 파일에서 저런식으로 하면 된다는 말입니다. 그렇다고 여기 #define 에서는 고치시면 안됩니다. 여튼 그렇구요. type1 은 첫번째 argument의 data type 이 되겠구요. arg1 은 첫번째 argument 의 이름입니다. 뭐 그 뒤는 설명 안해도 아실거라 믿구요. 이제 그 밑에 함수 안으로 들어가 봅시다. long __res; __res 라는 변수를 생성하는 거겠죠. __asm__ volatile ("int $0x80" \ 먼가 복잡군요. 다른건 제쳐두고 int $0x80 의 의미는 IDT TABLE 의 0x80 영역의 엔트리를 쓴다고 하는데 ... 간략하게 IDT 엔트리에 대해 설명해논게 있죠. 거기 보시면 0x80은 System Call 입니다. : "=a" (__res) \ 리턴값을 __res 에 저장하기 위함입니다. : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2))); \ 여기서 __NR_##name 이라고 있습니다. 보통 시스템 콜은 sys_fork(), sys_exit() 이런식으로 구현 됩니다. 하지만 사용시에는 fork() 이런식으로 사용을 하죠. 머 대충 사설은 제쳐두고, __NR_##name 은 위에 stub 에 추가하는 부분에 우리가 mycall 이라고 했으니 이 부분과 연계되는 것입니다. __NR_mycall 이란 의미가 되겠죠. 요놈이 eax 레지스터에 들어갑니다. 결국 191 이란 값이 eax 에 저장이 되는거겠죠. 증거로는 이런놈이 포착되었습니다. ======================================================= source : glibc -> sysdep.h #define SYS_ify(syscall_name) __NR_##syscall_name #define DO_CALL(args, syscall_name) PUSHARGS_##args DOARGS_##args movl $SYS_ify (syscall_name), %eax; int $0x80 POPARGS_##args ======================================================= DO_CALL 정의에서 둘,넷.. 네번째 라인을 보시면 movl $SYS_ify (syscall_name), %eax; 요론놈이 보이시죠. syscall_name 을 eax에 저장 -_-;; 그리고 첫번째 인자는 ebx, 두번째 인자는 ecx 에 저장이 됩니다. 그런 의미입니다.(-_-;;; 땀뻘뻘) 대충 stub 은 이정도로 마치구요. 설명이 길었는데 우리가 추가한 내용은 아래의 한줄 분이죠. #define __NR_mycall 191 3-2). System Call Table 이제 System Call Table 에 우리가 stub 에 추가한 시스템 콜에 대한 Table Entry 를 마찬가지로 추가 해주어야 겠죠. source: /usr/src/linux/arch/[processor]/kernel/entry.S # System Call을 Table에 등록 ================================================================================= .... ...어쩌구 저쩌구 저쩔시구.... ENTRY(sys_call_table) .long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/ .long SYMBOL_NAME(sys_exit) .long SYMBOL_NAME(sys_fork) .long SYMBOL_NAME(sys_read) .long SYMBOL_NAME(sys_write) .long SYMBOL_NAME(sys_open) /* 5 */ ... 이러쿵 저러쿵 ... .long SYMBOL_NAME(sys_capset) /* 185 */ .long SYMBOL_NAME(sys_sigaltstack) .long SYMBOL_NAME(sys_sendfile) .long SYMBOL_NAME(sys_ni_syscall) /* streams1 */ .long SYMBOL_NAME(sys_ni_syscall) /* streams2 */ .long SYMBOL_NAME(sys_vfork) /* 190 */ // 아래에 이 한줄을 삽입합시다. .long SYMBOL NAME(sys_mycall) /* 191 */ /* * NOTE!! This doesn't have to be exact - we just have * to make sure we have _enough_ of the "sys_ni_syscall" * entries. Don't panic if you notice that this hasn't * been shrunk every time we add a new system call. */ .rept NR_syscalls-190 .long SYMBOL_NAME(sys_ni_syscall) .endr ================================================================================= 머 감이 오시나요 ... -_-;; 안온다면 할수 없구요. .long SYMBOL NAME(sys_mycall) /* 191 */ 위에서 하는일이 무엇인가 ? 라는 질문이 스스로 생긴다면 아주 대단한겁니다 라고 말할줄 알았죠... 그때부터 피곤의 연속입니다. ENTRY(sys_call_table) 우선 ENTRY 저놈이 어디 정의되어 있나 하니 ... linkage 라는 놈에 정의가 되어있더라구요. ===================================== source: include/linux/linkage.h #define SYMBOL_NAME(X) X #define ENTRY(name) \ .globl SYMBOL_NAME(name); \ ALIGN; \ SYMBOL_NAME_LABEL(name) ===================================== 자세한 분석은 이 문서의 분석 0.0.2 version 에서 하게 될겁니다. 대충 보시면 ENTRY가 전역으로 SYMBOL_NAME(name) 이란걸 선언하고, 뭐 의문 덩어리입니다. 우선 sys_call_table 이란놈을 전역변수로 잡나부다 하고 생각합시다. 그리고 우리가 생성할 시스템 콜 이름을 table에 등록을 합니다. 아래와 같이 ... .long SYMBOL NAME(sys_mycall) /* 191 */ 그리고 ENTRY.S 파일의 맨 아래 세줄을 봅시다. .rept NR_syscalls-190 .long SYMBOL_NAME(sys_ni_syscall) .endr 저 190 이란 숫자 -_- 191로 바꿔야 겠죠. 여담입니다만 중간중간에 등록된 entry 중에 sys_ni_syscall 이라고 있습니다. 커널 뉴비 사이트를 뒤지다 보니 구현은 안된 syscall holder 라고 나와 있더군요. 아마 제 생각엔 ni 가 not implemented 의 약자가 아닌가 하는 생각이 .. (어디까지나 제 생각일 뿐입니다. -_-a) 뭐 이정도로 TABLE에 우리가 만들 System Call 의 등록을 마쳤습니다. 3-3) System Call 구현 예 우선 간단히 인자두개를 받아 더하고, 그 값을 리턴하는 system call을 작성해봅시다. (이놈은 없는검당 -_- 찾지 마시고 작성하시길...) ============================================ source: /usr/src/linux/kernel/mycall.c #include #include #include asmlinkage int sys_mycall(int x, int y) { return x+y; } ============================================ 그럼 우리가 작성한 시스템 콜을 커널 컴파일할때 같이 컴파일 되도록 Makefile 을 고쳐야겠죠. =================================================================== source : /usr/src/linux/kernel/Makefile (엄한 다른데 있는 Makefile 고치지 마세요 -_-;;) # # Makefile for the linux kernel. # # Note! Dependencies are done automagically by 'make dep', which also # removes any old dependencies. DON'T put your own dependencies here # unless it's something special (ie not a .c file). # # Note 2! The CFLAGS definitions are now in the main makefile... .S.s: $(CPP) -traditional $< -o $*.s O_TARGET := kernel.o O_OBJS = sched.o dma.o fork.o exec_domain.o panic.o printk.o sys.o \ module.o exit.o signal.o itimer.o info.o time.o softirq.o \ resource.o sysctl.o mycall.o ifeq ($(CONFIG_MODULES),y) OX_OBJS = ksyms.o endif include $(TOPDIR)/Rules.make sched.o: sched.c $(CC) $(CFLAGS) $(PROFILING) -fno-omit-frame-pointer -c $< =================================================================== O_OBJS = sched.o dma.o fork.o exec_domain.o panic.o printk.o sys.o \ module.o exit.o signal.o itimer.o info.o time.o softirq.o \ resource.o sysctl.o mycall.o 위에 O_OBJS 라고 보이시죠. 조기 셋째줄 끝에 보시면 mycall.o 라는 것은 제가 새로운 시스템 콜을 등록하기 위해서 추가한 내용입니다. 여러분도 추가하시고 저장하고 파일을 닫습니다. 그리고 참고로 2.4.19 버젼 커널의 Makefile을 보니 O_OBJS 는 온데간데 없고, obj_y 라는 놈이 있더군요. 2.4.19 버젼 커널을 쓰시는 분들 참고 하시기 바랍니다. (이제 머해야 되더라 -_-a) 아 커널 리빌드를 해야겠죠. /usr/src/linux/make bzImage 일케 해주시고, 커피한잔을 하고 옵니다. 물론 여기서 먼가를 잘못했다면 문제가 생깁니다. stub과 entry의 number가 맞지 않으면 문제가 생깁니다. 확인해주시고, 또 kernel/Makefile 에서 O_OBJS 밑에 mycall.c 라고 적어두시는 분이 있더군요.(접니다 ㅜ.ㅜ) 그럴경우 알수없는 파일 포맷이라고 나옵니다. 주의하세요.. 그리고 mycall.c 는 엉뚱한데 작성해놓고, Makefile은 kernel/Makefile 을 고치는 분도 계시더군요. ( 이것도 접니다 ㅜ.ㅜ 하수의 길이란 ...) 머 이정도했으면 별 이상없이 커피를 마시고 오시면 될겁니다. 한참 기다리면 어쩌구 커널 이미지가 완성되었다고 나올겁니다. 완성된 커널이미지는 /usr/src/linux/arch/[processor]/boot/bzImage 라고 보일겁니다. (이놈이 없으면 -_-; 저도 모름니다 뭔가 오류가 있어서 제대로 안되었겠지요.) 이제 저놈을 옮깁시다. 혹시 문제가 생길지 모르니 원래 있던 커널이미지는 보존해두는게 좋겠죠. mv /usr/src/linux/arch/i386/boot/bzImage /boot/bzImages 우선 저렇게 옮겨두고, lilo.conf 파일을 수정합니다. (저는 grup이나 gag 인지 먼지 하는건 안 써봐서 잘 모르겠군요) vi /etc/lilo.conf 하시면 lilo의 config 파일이 열리겠죠. ====================================================================== boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=50 linear default=linux image=/boot/vmlinuz-어쩌구 저쩌구 label=linux read-only root=/dev/hda1 // 아래에 이렇게 추가해주세요 image=/boot/bzImages label=systest read-only root=/dev/hda1 ====================================================================== image=/boot/bzImages <-- 이미지 파일이름과 path 가 같아야합니다. label=systest <-- 그냥 alias 의미의 라벨입니다. read-only root=/dev/hda1 리로에 대한 자세한 설명은 생략하도록 하겠습니다. (왜 ? 저도 잘 모르니까요 ...) 여튼 이 정도로 해놓고 ... 이제 재부팅을 합니다. 부팅시 리로에 다음과 같이 입력합니다. lilo : systest 커널 어쩌구 저쩌구 하면서 부팅이 되겠죠. 이제 부팅이 완료되면 ... 여기 까지 우리가 작성한 시스템 콜 탑재가 끝난것입니다. 이제 사용자 프로그램을 작성하여, 시스템 콜이 제대로 동작하는지 알아봅시다. ========================================================== # source : /home/ed/test.c #include #include _syscall2(int,mycall,int,x,int,y) int main() { int i; i = mycall(2,3); printf("system call : mycall return -> %d\n",i); return 0; } ========================================================== 위의 소스도 작성하시는 도중에 _syscall2(int,mycall,int,x,int,y) 이놈을 보시고 어디서 많이 봤다 라고 생각이 드셨다면, 성공입니다. 본문 저위를 보시면 ... 이런 내용이 나오죠.. 한놈만 족쳐봅시다. ================================================================================= #define _syscall2(type,name,type1,arg1,type2,arg2) \ type name(type1 arg1,type2 arg2) \ { \ long __res; \ __asm__ volatile ("int $0x80" \ : "=a" (__res) \ : "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2))); \ __syscall_return(type,__res); \ } ================================================================================= 여기서 _syscall2 음 ... 이해가 가시죠. _syscall2(return data type,function name,argument type1,arg1 name,argument type2,arg2 name) 위에서 x가 ebx 에 y가 ecx에 저장되는것 마져 이해하셨다면 ㅜ.ㅜ 전 아직도 이해가 잘 ... 그리고 함수의 지역변수가 __res에 의해 리턴된다는것 까지 아셨다면 ... 쓸데없는 이야기는 그만하고 이제 컴파일하고 실행을 해봐야겠죠. 아 컴파일하기전에는 꼭 다음과 같이 심벌릭 링크를 걸어주세요. 안그러면 라이브러리를 찾을수 없다고 나올겁니다. # symbolic link cd /usr/include rm -rf asm ln -s /usr/src/linux/include/asm-i386 /usr/include/asm ln -s /usr/src/linux/include/linux /usr/include/linux ls -l linux asm lrwxrwxrwx 1 root root 26 1월 17 10:46 asm - /usr/src/linux/include/asm-i386 lrwxrwxrwx 1 root root 28 1월 17 10:45 linux - /usr/src/linux/include/linux # compile gcc -o test test.c # execution ./test system call : mycall return -> 5 위와 같은 결과를 보셨다면 성공하셨습니다. 4. 문제점 내용이 짧았는데 모자란 부분도 많을 거라 생각합니다. 유저 프로그램에서 시스템 콜의 진행과정을 정리해보면 ... 아래와 같이 되는것 같습니다. usertask -> libc.a -> idt -> kernel -> sys_call_table -> real handler 그리고 제가 해본 바로는 entry 와 unistd 에 시스템 콜의 개수가 다른경우가 있더군요. entry.s 에는 190개가 있는데 unistd에 197 개가 있길래 과감히 7개를 주석처리하고 돌려봤습니다. 잘 되더군요. 이런 저런 방법으로 돌려보시기 바랍니다. end of [ver 0.0.1] [ver 0.0.2] 5. system call 을 모듈로 작성하기 5-1) system call 모듈 작성 리눅스에는 모듈을 kernel space 에 적재하는 좋은 기능이 있지 않았는가 ? 그걸 이용해 간단한 시스템 호출 모듈을 작성해보자. ================================================================= filename : wrapper.c (소스에 이줄을 치시는 분이 있을까?) #include #include // 위 두개는 모듈 프로그램에 기본적으로 추가되는 -_-;; 헤더파일이죠. #include #include #include #include extern void *sys_call_table[]; asmlinkage int(*original_call)(const char *, int, int); asmlinkage int(*getuid_call)(); asmlinkage int sys_our_open(char *fname, int flags, int mode) { printk("%s file is opened by %d\n", fname, getuid_call()); return(original_call(fname, flags, mode)); } int init_module() { // 함수 포인터를 이용해 오리지날 sys_open 저장 original_call = sys_call_table[__NR_open]; // 그리고 sys_open 의 자리에 sys_our_open 으로 대치 sys_call_table[__NR_open] = sys_our_open; // user id 갖고 오기 getuid_call = sys_call_table[__NR_getuid]; printk("Module Init!!\n"); return 0; } void cleanup_module() { sys_call_table[__NR_open] = original_call; } //소스참조 : 커널 프로그래밍 서적 ================================================================== 위 코드는 sys_call_table 에 등록된 sys_open 을 sys_our_open 으로 대치하는 프로그램이다. 물론 다른 시스템 콜들도 가능하다. # compile : wrapper.c gcc -D__KERNEL__ -D_LINUX -DMODULE -O2 -c wrapper.c 컴파일이 완료되면 이제 wrapper.o 라는 파일이 작성될것이다. 여기서부터는 모듈에 관련된 내용이므로 문서중에 "Linux Module Programming 기초" 인가 먼가하는 문서가 -_- 이 홈페이지 어딘가에 있을것이다. 읽고 오기바란다. 음냥 여튼 이제 모듈을 올려보자. # insert module insmod wrapper.o 이렇게 kernel space에 모듈을 올리게 되면, init_module 이 실행되고, 그 이후 어떤 파일을 열게되면, 그 파일 이름이 무엇이며, 파일을 연 user id 가 뿌려지게 될것이다. 아마도 root 가 실행을 했다면, 다음과 같이 ... 말이다. Module Init!! /etc/localtime file is opened by 0 ... ... ... 이렇게 비슷하게 나온다면 정상적으로 system call 업어치기에 성공한것이다. 이제 모듈이 올라갔는지 확인이 되었지만 그래도 한번 확인해보자 # list module lsmod 라고 엔터치는 순간 -_-;; 모듈 리스트를 보여주기위해 커널이 어떤 파일이든 system call 인 sys_open 을 호출하면 sys_our_open 으로 먼저 호출되어 뜨게 될것이다. 위에서 insmod 했을때 처럼 파일명을 어떤 uid를 가진 사람이 열었는지 가만히 놔둬도 시스템은 어떤 파일들을 열기위해 sys_open 을 sys_call_table 에서 호출하게 되지만, 결국 sys_our_open 을 선 호출한후에 sys_open 을 호출하게 되는것이다. 심지어 ls 라는 명령을 수행해도 무슨 파일을 여는지 튀어 나온다. 계속보다가는 -_-;;; 어지럽다. 그냥 이제 모듈을 kernel space에서 내리자 ... # release module rmmod wrapper 끝나면서도 마지막으로 발악을 하는 sys_our_open 을 볼수 있을것이다. 이제부터는 sys_our_open 이 sys_open 의 앞길을 막는일은 없을것이다. 정상적으로 sys_open 만이 호출되게 된다. 6. 어셈블리 언어로 시스템 콜 호출하기 이 내용은 이 문서 2-2 에 나오는 인터럽트 디스크립터 테이블(IDT)에 나온 내용을 실제로 어셈블리 언어를 사용해서 인터럽트 호출하여 문자를 출력하는 함수를 작성하고, 문자열을 정의하는 하나의 c 프로그램을 사용하여, 둘을 동시에 링크하여 어셈블리 언어로 어떻게 시스템 콜을 사용하는가에 대한 내용입니다. 6-1. 라이브러리 독립적인 Hello World 프로그램 작성하기 대부분의 C 프로그래머들은 문자열 출력을 위해서 printf 나 fprintf 를 사용합니다. 물론, 이들은 GNU libc 에 의해 제공되는 표준 라이브러리 함수 입니다. 어셈블리 언어에서 이런 출력 루틴을 지원하게 하기 위해서 xputchar() 라는 함수를 생성했습니다. xputchar.asm (write 시스템 콜을 사용해 문자열을 출력하는 코드) ====================================================================== ; N A M E : x p u t c h a r . a s m ; ; D E S C : putchar() by assembly ; ; A U T H : Wataru Nishida, M.D., Ph.D. ; wnishida@skyfree.org ; http://www.skyfree.org ; ; M A K E : nasm -f elf xputchar.asm ; ; V E R S : 1.0 ; ; D A T E : Dec. 17, 2000 ; bits 32 ; 32bit 모드 사용 ; 여기서부터 code 시작 section .text ; GCC 의 .text 섹션에서 코드가 시작 global xputchar ; 전역 함수처럼 xputchar() 선언 ; ; x p u t c h a r ; ; int xputchar (unsigned int ch) ; ; --- return one (success) or -1 (error) ; ; Dec. 17, 2000 xputchar: push ebp ; EBP 를 스택에 PUSH mov ebp, esp ; xputchar 자체 스택 프레임의 준비 ; [ebp] 가 저장된 EBP 를 가리키게 하고, ; [ebp+4] 가 복귀 주소를 가리키게 함 ; EAX,ECX,EDX 를 제외한 레지스터를 보존 push ebx ; Save EBX. ; 1 번째 아규먼트는 [ebp+8]에 2번째 아규먼트는 [ebp+12] 에 ... mov eax, [ ebp + 8 ]; 문자코드 얻어오기 mov [ msgbuf ], al ; 저장하기 mov edx, 1 ; 문자카운트 설정 mov ecx, msgbuf ; 버퍼 포인터 설정 mov ebx, 1 ; 표준 출력(STDOUT) 설정 mov eax, 4 ; sys_write 시스템 콜 호출 int 0x80 ; IDT 의 0x80( 시스템 콜 호출을 위한 인터럽트) pop ebx ; EBX 복구 시키기 leave ; ESP와 EBP 를 같게 하고, 스택에서 pop 해서 EBP로 ret ; 변수시작을 위한 저장 공간은 여기서 부터 ... section .data ; GCC 의 .data 섹션에 변수적재 msgbuf db 0 ; 메시지 버퍼 ====================================================================== xputchar() 함수는 아규먼트 3개를 사용하는 "write" 시스템 콜(함수 번호 4번)을 실행시킨다. write 의 첫번째 아규먼트는 파일 디스크립터를, 두번째는 스트링 버퍼 포인터를 마지막은 문자열의 길이를 나타낸다. 이 프로그램에서는 STDOUT(표준 출력)을 하나의 파일 디스크립터 처럼 사용한다. 임시 버퍼를 위해 static 변수인 msgbuf 를 .data 섹션에 정의하고, 문자열 출력을 원한다면, strlen 함수를 생성해야만 한다. 위의 코드를 잘보시면 제가 3장 3-1절에서 설명했던 내용과 유사하죠. xputchar 소스코드 하단부를 보시면 mov edx, 1 mov ecx, msgbuf mov ebx, 1 mov eax, 4 int 0x80 가 보이시죠. mov eax, 4 가 시스템 콜 스텁의 번호를 가리킵니다. 따라서 4번 시스템 콜을 호출하겠다는 이야기가 됩니다. 그리고 그 바로 위에 mov ebx, 1 이 보이시죠. ebx 에는 eax 가 가리키는 해당 시스템 콜의 첫번째 아규먼트를 저장하게 된다고 했었죠. ebx 에 1을 넘겨주었으니 파일 디스크립터는 표준출력이 됩니다. ( 아마도 stdin 이 0 stderr 이 2 로 기억됩니다만 한번 테스트 해보세요.) ecx 에는 eax 가 가리키는 시스템 콜의 두번째 아규먼트를 저장하죠. ecx 에 문자열 버퍼 포인터를 넘겨주었고, edx 에는 세번째 아규먼트를 저장하는데 마지막은 문자열의 길이죠. 그리고 마지막으로 int 0x80 인터럽트 호출을 하게 되는데, IDT 에 정의된 시스템 콜 인터럽트 호출입니다. 이렇게 전체적으로 작성된 코드를 global xputchar 로 정의하여 c 에서 불러 쓸수 있게 전역함수로 만듭니다. 근데 main 함수 종료를 위한 코드도 작성해야 겠죠. xexit.asm ============================================ bits 32 section .text global xexit xexit : mov ebp, esp mov ebx, [ebp+4] mov eax, 1 int 0x80 ============================================ 이 호출은 c 로 작성할 프로그램의 종료를 위한 시스템 콜 sys_exit를 호출하여, 프로그램을 종료시키는 프로그램 입니다. 원리는 위의 xputchar와 같죠. hello.c ============================================ extern int xputchar(unsigned int); extern int xexit(int); main(){ char msg[]="Hello World!\n"; char *ptr; int res; ptr = msg; while (*ptr) res = xputchar(*ptr++); xexit(128); } ============================================ 이 프로그램에서 우리가 어셈블리 언어를 사용하여, write 시스템 콜을 호출하게 작성한 xputchar 를 사용해 "Hello World!" 를 출력하게 됩니다. 이 c 프로그램은 단순하니 한번 작성해보세요. 6-2. build 작업과 프로그램 실행하기 # xputchar.asm , xexit 의 make $ nasm -f elf xputchar.asm (elf 포맷을 갖는 xputchar.o 파일 생성됨) $ nasm -f elf xexit.asm (elf 포맷을 갖는 xexit.o 파일 생성됨) # hello.c 의 compile $ gcc -c hello.c (hello.o 라는 목적코드 생성됨) # 위의 컴파일을 통해 생성된 hello.o 파일과 xputchar.o 파일을 이용해 링크하기 $ ld -s -e main -o hello hello.o xputchar.o xexit.o (hello.o xputchar.o xexit.o 파일을 사용해 hello 라는 실행 코드로 링크하되, 엔트리 포인트(-e)는 main 함수에서 시작하게 하고, -s 옵션을 주어 불필요한 섹션 심벌 테이블 제거) # 불필요한 섹션들 제거하기 $ strip --remove-section=.comment --remove-section=.note hello (hello 파일의 comment 섹션과 note 섹션 제거 ) # 공유 라이브러리 의존성 출력해서 확인 $ ldd hello statically linked (ELF) 또는 not a dynamic executable # 생성된 파일들 ======================================================================= $ ls -l total 25 drwxr-sr-x 2 root src 208 Jan 6 22:03 . drwxr-sr-x 4 root src 96 Jan 6 21:57 .. -rwxr-xr-x 1 root src 676 Jan 6 22:03 hello -rw------- 1 root src 196 Jan 6 22:02 hello.c -rw-r--r-- 1 root src 1040 Jan 6 22:02 hello.o -rw------- 1 root src 1360 Jan 6 21:31 xexit.asm -rw-r--r-- 1 root src 512 Jan 6 21:31 xexit.o -rw------- 1 root src 1360 Jan 5 18:49 xputchar.asm -rw-r--r-- 1 root src 704 Jan 5 18:49 xputchar.o ======================================================================= # 프로그램의 실행 $ ./hello ; echo $? Hello World! 128 위의 ld 에서 -s 옵션은 자동적으로 심벌 테이블 섹션을 제거하게 합니다. 완성된 프로그램은 라이브러리 독립적이며, 그 크기도 676 바이트가 됩니다. 결국, 표준 환경의 도움없이 리눅스 커널을 완전히 컨트롤 하게 되었죠. (위의 build 시 옵션들이 하는 일이 무엇인지 좀더 자세히 알고 싶으시다면, C Calling Convention 문서와 elf 포맷문서를 참조하셔서 읽어보시면 될것 같네요.) 축하합니다. 하지만 이건 시작일 뿐이죠. ^^ 7. 정리 커널 리빌드는 시간이 조금 걸립니다. 모듈 프로그래밍으로 테스트 해본후 최종적으로 커널 리빌드를 하는게 좋겠다는 \n님의 의견에 따라 이렇게 문서를 업데이트 했습니다. 위의 시스템콜 덮어치기 외에 하나를 더 추가적으로 재미로 만들어봐도 되겠습니다. 시간이 날때... 오랜만에 올리는 자료라 지져분한 면이 많군요... 아무쪼록 이해해주시기 바랍니다. 여튼 읽어주셔서 감사드립니다. _(__)_ ======================================================================== * Change Log (bout Documentation) - v 0.0.5 (2003.04.10) : 어셈블리 언어를 이용하여 C 프로그램과 함께 링크하여 시스템콜을 어떻게 어셈블리 언어를 사용해 제어하는지에 대한 내용 (참조 : http://www.skyfree.org/linux/assembly/section6.html) - v 0.0.4 : 시스템 콜을 모듈로 작성하여 사용하는 방법 - v 0.0.3 : 커널 컴파일부분 errata 수정 및 보완 ========================================================================