===============================================================
제목 : 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 <linux/unistd.h>
#include <linux/errno.h>
#include <linux/sched.h>
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 <stdio.h>
#include <linux/unistd.h>
_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 <linux/kernel.h>
#include <linux/module.h>
// 위 두개는 모듈 프로그램에 기본적으로 추가되는 -_-;; 헤더파일이죠.
#include <sys/syscall.h>
#include <linux/sched.h>
#include <linux/fs.h>
#include <asm/uaccess.h>
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 수정 및 보완
========================================================================