Search

'(무선)네트워크'에 해당되는 글 16건

  1. 2009.09.30 윈도우 인터럽트 지연처리에 대해서
  2. 2009.09.17 무선랜 카드 MAC 주소 바꾸기
  3. 2009.09.10 리눅스커널의 공간 사용법 1
  4. 2009.09.08 실행파일 크기 줄이기 3
  5. 2009.01.05 Sys_call_table Wrapping
  6. 2009.01.05 Linux system call

윈도우 인터럽트 지연처리에 대해서

(무선)네트워크 2009. 9. 30. 01:34 Posted by 알 수 없는 사용자


IDT 후킹을 공부하다가 인터럽트 지연처리에 대해서 고찰해 보았다.

주변 기계장치에서 CPU에게 통지해야될 일이 생기면 인터럽트를 사용한다. 인터럽트가 발생하면 이를 처리하기 위하여 ISR(Interrupt Service Routine)이 수행된다. 

이 인터럽트에도 우선순위가 있어 우선순위 대로 실행된다. 이 우선순위를 IRQL이라고 하는데, 그럼 IRQL에 대하여 알고 넘어가보자


Passive Level은 평상시 쓰레드에서 루틴이 수행될 때의 상태이다. ACP Level ~ Dispatch Level은 소프트웨어 인터럽트에 해당하며, 그 이상의 레벨을 총칭 하드웨어 인터럽트라고 부른다. 참고로 Passive Level 에서 보통 루틴이 수행되며 코드로 코딩하여 올릴 수 있는 레벨은 Dispatch Level까지 이다.

IRQL은 인터럽트에 대한 우선권을 부여한 것으로 IRQL이 높은 인터럽트가 먼저 수행된다. 특정 ISR이 수행되던 중 현재 수행되는 ISR보다 IRQL이 높은 인터럽트가 발생한다면 당연히 현재 수행하던 ISR을 멈추고, IRQL이 높은 인터럽트를 수행할 것이다.

그러면 다시 인터럽트 지연처리로 돌아와 보자

만약 키보드와 같은 하드웨어에서 인터럽트가 발생했다고 생각해 보자 그럼 Device Level(DIRQL) 어딘가에서 인터럽트가 발생 할 것이고, 현재 수행되던 작업이 멈추게 될 것이다. 키보드에서 발생한 인터럽트 처리가 완료 된 후 다시 이전 작업을 수행하게 되는데 키보드에서 발생한 인터럽트가 오랜시간을 요구하는 작업이라면 그 작업을 처리하는 시간동안 다른 작업들은 지연될 것이다.  이러한 비효율성을 없애기 위해 인터럽트 지연처리가 존재한다.
 
리눅스에서는 이런 이유로 인터럽트를 Top Half와 Bottom Half로 나눠서 실행하며 윈도우에서는 DPC(Deferred Procedure Call)를 이용하여 가능하게 한다. 인터럽트가 발생했을 당시 즉시 처리해야될 작업은 미리 처리 해 놓고, 조금 나중에 처리해도 될 작업들을 DPC Queue에 넣어 둔다. 그리고 멈추었던 작업을 수행해서 시스템을 효율적으로 사용한다. 

DPC Queue에 있는 루틴들이 다시 호출되는 시점은 Dispatch Level이 되는 시점에 DPC Dispatcher(DPC 스케줄러)에 의해 다시 호출된다.

단순히 혼자 생각이지만 DPC루틴은 Dispatch Level에서 동작하는데 이것을 보고 예술이라고 생각한다. Dispatch Level이라면 소프트웨어 인터럽트의 최고 단계이다. 즉 조금나중에 처리해도 별 문제 될 작업이 아니지만 처리는 해야되기 때문에 하드웨어 인터럽트에는 선점당할 수 있으나, 소프트웨어 인터럽트에는 선점당할 수 없게 만들어 놓은것이 아닐까 생각해 보면 딱 맞아 떨어지 때문이다.





PS : 디바이스 드라이버에 대해서 공부 할 수 있는 문서


문서출처 : www.kosr.org

무선랜 카드 MAC 주소 바꾸기

(무선)네트워크 2009. 9. 17. 14:08 Posted by TEAMCR@K
무선 네트워크 점검을 하다보면 무선AP에서 MAC인증을 할 경우 무선 랜카드의 MAC을 수정해야 하는 경우가 있습니다.

윈도우 환경에서 해당툴을 이용하여 간단하게 바꿀 수 있습니다.

http://www.wirelessdefence.org/Contents/MAC%20Address%20Changer.htm

소스파일 : Project Homepage: http://www.codeproject.com/tools/MacIdChanger.asp

BackTrack 환경에서는 "macchager" 명령어가 포함되어 있습니다.



리눅스커널의 공간 사용법

(무선)네트워크 2009. 9. 10. 01:57 Posted by 알 수 없는 사용자

리눅스 커널 코드를 분석하다보면 분명 작성된 언어는 C언어인데 처음보는 낯선 키워드등 분석이 잘 안되는 경우가 있습니다.

이는 메크로함수나 함수 포인터 등 #define으로 새로 정의되어 사용되는 키워드들 때문에 가독성이 떨어지기 때문입니다.
 
그 중 한 예로 리눅스의 스케줄링을 담당하는 schedule() 함수를 보면,

asmlinkage void __sched schedule(void)

이렇게 함수가 구성되어 있습니다.

이를 하나씩 살펴 보겠습니다.

asmlinkage는 어셈블리와 링크가 가능하다는 뜻 즉, 어셈블리어로 짜여진 코드에서 이 함수를 호출 할 수 있다는 뜻입니다.

__sched 이 키워드는 linux/include/linux/sched.h에 정의 되어 있습니다.

#define __sched __attribute__((__section__(".sched.text")))

다음과 같은 형태로 정의되어 있는데 ( 점점 더 복잡하게 되는 것 같습니다. )

__attribute__ 는 윈도우의 #pragma 와 비슷한 것으로 c의 표준은 아닙니다.

#pragma는 cl컴파일러에서 작동하며, __attribute__는 gcc컴파일러에서 작동하며 사용되는 용도는 비슷합니다.

__attribute__ 키워드의 대표적인 예로는

typedef struct
{
char a;
int b;
}asdf;

이런 구조체가 있을때 sizeof(asdf) 라고 하면 결과는 8이 나옵니다.

int a = sizeof(char)+sizeof(int);

printf("%d\n", a);

라고 했을 때 결과는 5가 나옵니다.

이는 packing(natural boundary)때문에 일어나는 현상입니다.

이를 정확한 값을 얻고 싶다면

typedef struct
{
char a;
int b;
}__attribute__(packed) asdf;

이렇게 하면 정확한 값이 나옵니다.  (윈도우에서는 #pragma pack(1) 라고 하면 됩니다.)

이 외에 __attribute__(x) 안에 들어갈 수 있는 것은 여러가지가 있습니다.

그럼 다시 돌아와서 살펴 보도록 하겠습니다.
 
__attribute__((__section__(".sched.text")))

이 키워드는 ".sched.text라는 섹션을 만들어서 그 섹션안에 schedule()함수의 내용을 넣어라" 라는 뜻이 됩니다.

이렇게 함으로써 얻을 수 있는 이점으로 섹션은 build 타임에 relocation이 가능하게 되는데,
 
초기화 역할을하는 특정 섹션을 만들어 그 안에 넣은 후 사용하다가 더이상 필요 없을 시 이 섹션을 날려 버립니다.

이런 방식으로 메모리 공간을 아낄 수 있습니다.
 
리눅스에서는 보통 커널공간이 1GB이고, 유저공간이 3GB입니다.(설정에 따라 달라질 수는 있습니다.)

만약 task_struct등 커널 오브젝트의 증가나 컨택스트 스위칭 등 커널 자원을 소비하는 작업을 할 때 커널 공간이 부족하다면 시스템 운영상 곤란 할 것입니다.

실제로 start_kernel() 함수도

asmlinkage void __init start_kernel(void)

#define __init __attribute__ ((__section__ (".text.init")))

이렇게 정의되어 있습니다.

즉 .text.init섹션에 start_kernel함수의 내용을 넣었다가 초가화가 끝나고 나면 이 섹션을 날리면서 메모리 공간을 절약합니다.

이렇게 리눅스에서는 커널공간을 효율적으로 관리하고 있습니다.

관련된 pdf파일을 첨부합니다. 관련된 내용은 아주 조금 있지만 전반적으로 읽어두면 커널을 이해하는데 조금 도움이 될듯합니다.

실행파일 크기 줄이기

(무선)네트워크 2009. 9. 8. 09:09 Posted by 알 수 없는 사용자

바이러스에 대하여 공부를 하다보면 작은크기의 바이너리가 시스템에 엄청난 타격을 주는것에 대해 놀라지 않을 수 없다.

바이러스를 통해 영감을 얻어 실행파일의 크기를 줄이는 몇가지 방법에 대해서 알아 보자

(실제 바이러스는 LoadLibrary, GetProcAddress를 통하여 필요한 API만 사용하면서 크기를 줄이는 방법을 사용하기도 한다.)

실행파일의 크기를 줄일 수 있는 방법으로는 #pragma 라는 키워드를 사용하면 된다.

#pragma는 define 이나 include와 같이 #으로 시작하는 전처리구문(precompiler)의 하나이다.

컴파일러에 종속적인 구문이라 컴파일러가 변경되었을 경우 제대로된 동작을 보장하지 못하므로 프로젝트 진행중에 서로 다른 컴파일러를 사용한다면 사용하지 않음이 바람직 하겠으나,

Visual Studio로 코딩을 하고 cl컴파일러를 사용하는 한 그런 걱정은 하지 않아도 된다.

실행파일의 크기를 줄일 수 있는 3가지 방법에는 EntryPoint를 바꾸는 방법, FileAlignMent를 바꾸는 방법, SectionMerge가 있다.

1. Entry Point

보통 프로그래밍을 하다보면 맨처음 시작하는 부분이 있다. 

C언어에서는 main( ... ) 함수, 윈도우즈  Programming 에서는 WinMain( ... ) 에 해당된다.

이를 EntryPoint라고 한다.

많은 문서들이 윈도우즈 어플리케이션의 진입 함수를 다음과 같은 함수로 고정된 것으로 설명하고 있다.

int WINAPI WinMain(
        HINSTANCE hInstance,
        HINSTANCE hPrevInstance,
        PSTR szCmdLine,
        int iCmdShow)

하지만 windows.h를 include하여 WinMain()을 이용하게 된다면 7KB정도의 추가적인 코드가 덧붙여 지게 된다.

이렇게 비 생산적인 코드를 제거하려면 진입함수를 변경하면 되는데 linker에게 어떤 진입함수를 쓰는지 알려주는 방법으로 "#pragma comment" directive를 사용하면 된다.

#pragma의 사용법에 대해 잠시 보자면

#pragma comment()는

#pragma comment( comment-type, ["comment string"] )

의 형태를 가지게 된다.

[] 안의 구문은 comment-type에 따라 필요할 경우 사용하는 것이다.

comment type에는 compiler, exestr, lib, linker, user 등이 올 수 있다.

linker 를 사용하면 프로젝트를 console application인지 win32 application인지 명시해줄 수 있다.

#pragma comment( linker, "/subsystem:windows" )
#pragma comment( linker, "/subsystem:console" )

또한 섹션의 설정을 할 수 있다.

#pragme comment( linker, "SECTION:.SHAREDATA,RWS" )

이 중 가장 대표적인 사용법은 명시적인 라이브러리의 링크이다.

#pragma comment(lib, "xxxx.lib")

이렇게 작성하여 주면 VisualStudio에서 별도 설정없이 Library를 사용할 수 있다.

다시 Entry Point를 설정하는 예로 가보자. 

#include <windows.h>
#pragma comment (linker, "/ENTRY:main") //main부터 시작함
 
int main()
{
    MessageBox(NULL, TEXT("test"), TEXT("test caption"), MB_OK);
    return 0;
}

이렇게 하면( #pragma comment (linker, "/ENTRY:main")   ) EntryPoint가 main으로 변경할 수 있다.

2. File Alignment

PE파일구조에서는 Section Alignment, File Alignment라는 용어를 사용하게 된다.
 
각 크기에 따라 파일상의 위치와 메모리상의 위치가 달라지게 되고 이에 따라 Pedding이 생기게 된다.

VC++ 6.0에서 default file alignment는 0x1000 바이트이다.
 
이 옵션에서는 각 section 사이에 의미없는 빈 공간을 많이 만들어 낸다. 이것은 불필요한 낭비가 아닐 수 없다.
 
만약 우리가 만드는 어플리케이션이 3개의 section(.text, data, rdata)으로 이루어져 있다면
 
최소한 0x1000 * 3 = 0x3000 = 12288 바이트나 차지한다는 의미이다.
 
0x1000 바이트 미만의 코드로 짜여진 프로그램이라면 이 역시 많은 부분이 낭비이다.
 
linker에게 FILEALIGN 옵션을 주어서 file alignment를 변경할 수 있다.

#pragma comment(linker,"/ENTRY:main /FILEALIGN:0x200 /IGNORE:4078")

위 옵션은 File Alignment를 0x200으로 주었는데 상황에 따라 적당한 겂으로 설정하면 된다.

IGNORE 옵션은 컴파일러가 4078번 에러를 반환하면 무시하라는 의미이다.
 
이렇게 PEDDING의 크기가 줄어들기 때문에 최종 실행파일 사이즈를 줄일 수 있다.

3. Section Merging

PE파일구조서도 설명되어 있지만, PE 파일 내에서 각 section에는 header, info등의 정보가 추가적으로 따라 붙는다.
 
만약 section들을 하나로 merge한다면 이런 추가적인 공간들을 제거할 수 있을 것이다.
 
그러나 section들을 merge할 때는 section의 내용을 정확히 파악해야 한다.

 section   Description 
  .text   코드 텍스트 영역
  .data   문자열 등이 저장되는 데이타 섹션
  .rsrc   image import descriptor 등이 저장되는 리소스 데이타 영역

그럼 모든 section들을 하나의 section으로 합쳐 보자.

주의할 것은 코드 텍스트 영역은 read-only 영역이고, .data나 .rdata는 쓰기 권한이 필요한 영역이므로 무턱대고 합치면 안되고 액세스 권한을 설정해 줘야 한다.

#pragma comment(linker,"/ENTRY:main /FILEALIGN:0x200/SECTION:.text,EWR /IGNORE:4078")

 설명  속성 
 Executable  E
 Writeable  W
 Readalble  R

이렇게 하면 코드 영역이 executable, write, read등이 가능해 지도록 하는 것이다.
 
실제로 section을 머지하는 옵션은 다음과 같다.

#pragma comment(linker,"/ENTRY:main /FILEALIGN:0x200
    /MERGE:.data=.text      //.data가 .text로 합쳐짐
    /MERGE:.rdata=.text     //.rdata가 .text로 합쳐짐
    /SECTION:.text,EWR /IGNORE:4078")

이런 방법 외에도 어셈블리어로 직접 하드코딩하는 방법도 있다.

어셈블리어로 코딩을 하게 되면 코드 최적화 및 컴파일시 붙는 군더더기 코드가 그나마 줄기 때문에 어셈블리어로 직접 하드코딩을 하는 방법도 있다.

Sys_call_table Wrapping

(무선)네트워크 2009. 1. 5. 14:45 Posted by 알 수 없는 사용자


▷ 작성자 : minams (minams@a3sc.co.kr)
▷ 편집자 : minams (minams@a3sc.co.kr)

 

Sys_call_table Wrapping

 

목차

1. Introduce
2. Find_sys_call_table for kernel 2.6
3. Test kernel 2.6.22
4. Reference
5. Source code


1. Introduce

kernel 개발 등 여러 가지 작업을 하다 보면 부득이하게 Sys_call_table을 수정해야만 하는 상황이 생긴다.

지금 소개하는 방법은 module을 통해 sys_call_table을 wrapping하는 방법으로 kernel 2.6 이상에서도 가능하며 현재, 2.6.22까지 테스트를 마쳤다.
- Module을 사용하는 이유는 kernel을 컴파일 하지 않고도 wrapping 할 수 있어서이다.



2. Find_sys_call_table for kernel 2.6

잘 알려진 방법으로 sys_call_table 보다 주소가 낮은 공개심볼인 loops_per_jiffy와 높은 주소인 boot_cpu_data 를 이용하여 다음과 같은 코드로 sys_call_table 주소를 찾아낼 수 있다.

 for ( ptr = ( unsigned long )&loops_per_jiffy;
ptr < ( unsigned long )&init_mm ; ptr += sizeof( void* ) )
{
p = ( unsigned long * )ptr; 
if ( p[ 6 ] == ( unsigned long ) sys_close )
{
return (void**)p;
}
}

그러나 이 소스는 kernel 2.6.22 전까지만 유요한 코드이다. 이유는 심볼 주소가 바뀌었기 때문이다. 확인해보자

 

Sys_call_table < Loops_per_jiffy < Boot_cpu_data로 변경 된 것을 알 수 있다.

그리하여 a < sys_call_table < b 를 만족하는 공개심볼을 찾아냈다. 바로 _read_lock와 init_mm이다.
# 주소 확인은 직접 해보자!! /boot/System.map 파일을 열어보면 커널 심볼주소(커널 컴파일시)가 들어있다.

이로 만들어지는 코드는 다음과 같다.

 for ( ptr = ( unsigned long )_read_lock; ptr < ( unsigned long )&init_mm ; ptr += sizeof( void* ) )
{
   p = ( unsigned long * )ptr;
   if ( p[ 6 ] == ( unsigned long ) sys_close )
   {
     return (void**)p;
   }
}

여기서 해결되면 쉽겠지만 문제가 또 하나 발생한다. 이유는 sys_call_table 이 읽기전용으로 바뀐 것이다.

해당 page의 속성을 바꾸기 위해서 다음을 추가하자 해더는 asm/cacheflush.h 이다

 // 쓰기로 변경
change_page_attr(virt_to_page(sys_call_table), 1, PAGE_KERNEL);

// 다음으로 캐시라인 전체를 업데이트
global_flush_tlb();

3. Test kernel 2.6.22

Sys_open을 다음과 같이 간략히 Wrapping

다음과 같은 실수를 하지 않도록 ㅡㅡㅋ


 
 다음은 컴파일 하는 화면이다.
 

 
 다은은 Test 하는 화면입니다.
 

 



4. 참고 사이트 및 문헌

IT EXPORT 리눅스 커널 프로그래밍
http://monac.egloos.com/1308090



5. Source code

 --------minux.c-------------------------------------------------------
#include <linux/kernel.h>

#include <linux/init.h>
#include <linux/syscalls.h>
#include <linux/module.h>
#include <asm/unistd.h>

#include <linux/sched.h>
#include <linux/slab.h>
#include <asm/ptrace.h>
#include <asm/cacheflush.h>

//extern int change_page_attr;
void **sys_call_table;

asmlinkage int (*org_sys_open)(const char*, int, int);
asmlinkage int (*org_sys_getuid)(void);

asmlinkage int minux_sys_open(char *fname, int flags, int mode)
{
        printk( KERN_ALERT "%s file is opened by %d\n",fname,org_sys_getuid() );
        return ( org_sys_open( fname, flags, mode ) );
}

static void **find_system_call_table(void)
{
        unsigned long ptr;
        unsigned long *p;

        for( ptr = (unsigned long)_read_lock; ptr < (unsigned long)&init_mm; ptr
+= sizeof(void*) )
        {
                p = (unsigned long *)ptr;
                if( p[6] == (unsigned long)sys_close )
                {
                        return (void**)p;
                }
        }

        return NULL;
}

int __init minux_init(void)
{
        sys_call_table = find_system_call_table();

        if( sys_call_table != NULL )
        {
                printk( KERN_ALERT "I think sys_call_table is at 0x%p\n", (void*)
sys_call_table );
//
                change_page_attr(virt_to_page(sys_call_table), 1, PAGE_KERNEL);
                global_flush_tlb();
//
                org_sys_open = sys_call_table[__NR_open];
                sys_call_table[__NR_open] = minux_sys_open;

                org_sys_getuid = sys_call_table[__NR_getuid];
        }
        else
        {
                printk( KERN_ALERT "Failed to find_sys_call_table T.T \n");
        }
        return 0;
}

void __exit minux_exit(void)
{
        sys_call_table[__NR_open] = org_sys_open;
}

module_init(minux_init);
module_exit(minux_exit);

MODULE_LICENSE( "GPL" );

-----------Makefile---------------------------------
KERNELDIR = /lib/modules/$(shell uname -r)/build

obj-m = minux.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:
        rm -rf *.o
        rm -rf *.mod.*
        rm -rf .*.cmd
        rm -rf *.ko



Linux system call

(무선)네트워크 2009. 1. 5. 14:38 Posted by 알 수 없는 사용자


▷ 작성자 : minams (minams@a3sc.co.kr)
▷ 편집자 : minams (minams@a3sc.co.kr
 )

Linux System_call


목차

1. 사용자 공간과 커널공간
2. SYSTEM CALL
3. SYSTEM CALL 과정
4. SYSTEM CALL reference

 

1. 사용자 공간과 커널공간

8051 프로세서는 ROM의 0번지부터 차례대로 읽어가면서 정해진 대로 프로그램을 수행한다. 결국 하나의 메모리에 하나의 프로그램만 존재한다. 반면에 운영체제는 최소한 2개 이상의 프로그램이 메모리에 존재한다.(운영체제, 프로그램) 이렇게 메모리에 운영체제와 사용자 프로그램을 공존하게 하기 위한 해결책이 바로 사용자 영역과 커널 영역이다.

[그림 1-a] 사용자 공간과 커널공간 - i386 32bit(리눅스)

 


 


위와 같이 포인터연산을 잘못해서 커널공간을 침범하는 것을 막기 위해 메모리 접근을 제한 할 수 있는 권한을 부여하였다.

[그림 1-b] 특권 레벨(privilege level)

 


    (보통 운영체제에서 0, 3 두 가지 영역만 사용)

운영체제는 부팅과정 동안에 GDT(Global Descriptor Table)을 이용해 해당 레벨에 사용할 메모리 영역을 지정한다. GDT의 type필드는 코드영역(읽기/실행)인지 데이터영역(읽기/쓰기)인지 지정하고, offset필드는 접근할 수 있는 메모리의 상대범위를 나타낸다.


 

2. SYSTEM CALL

시스템 호출이란 상위레벨(커널영역)로 접근가능하게 하는 문(함수)이다.
- JMP명령으로는 서로 다른 레벨로 접근할 수 없다.
- C언어를 이용해서 프로그래밍을 할 경우 대부분의 SYSTEM CALL은 libc를통한 포장(wrapper)형태로 제공받을 수 있다.
Ex) syscall(SYS_getpid); - 직접 호출
getpid();  - libc를 통한 wrapper 형태
- 인터럽트번호 128번 사용(0x80)



3. SYSTEM CALL 과정

 사용자 프로세스에서 시스템 호출사용 - ex)open()

 Libc에서 시스템 호출 준비
 시스템 호출에 필요한 인자를 register에 저장
 인터럽트 0x80을 발생 (소프트웨어 인터럽트 = 트랩)

 SYSTEM CALL
 IDT에 의해 system call 발생
 인터럽트 서비스 루틴 실행 – system_call()

 결과값 반환 – register에 저장


 

4.  참고 사이트 및 문헌

[표 1-a] 시스템 콜 레퍼런스 - kernel 2.6 #define NR_syscalls 318

번호

함수 이름

설명

소스

1

exit()

현재 프로세스의 종료

kernel/exit.c

2

fork()

자식 프로세스의 생성

arch/i385/kernel/process.c

3

read()

파일 지정자로 부터 읽기

fs/read_write.c

4

write()

파일 지정자로 쓰기

fs/read_write.c

5

open()

파일이나 장치열기

fs/open

6

close()

파일 지정자 닫기

fs/open.c

7

waitpid()

프로세스의 종료를 기다린다

kernel/exit.c

8

creat()

파일이나 장치의 생성

fs/open.c

9

link()

파일을 위한 새로운 이름 만들기

fs/namei.c

10

unlink()

파일 혹은 참조된 이름을 삭제한다

fs/namei.c

11

execv()

프로그램의 실행

arch/i386/kernel/process.c

12

chdir()

작업디렉토리의 변경

fs/open.c

13

time()

초단위의 시간 얻기

kernel/time.h

14

mknod()

일반 혹은 특수파일의 생성

fs/namei.c

15

chmod()

파일의 권한 바구기

fs/open.c

16

chown()

파일의 소유자 변경

fs/open.c

18

stat()

파일의 상태 얻기

fs/stat.c

19

lseek()

파일에서의 위치 변경

fs/read_write.c

20

getpid()

프로세스의 ID를 얻어온다

kernel/sched.c

21

mount()

파일 시스템의 마운트

fs/super.c

22

umount()

파일 시스템 마운트 해제

fs/super.c

23

setuid()

실제 유저 아이디 설정

kernel/sys.c

24

getuid()

실제 유저 아이디 얻어오기

kernel/sched.c

25

stime()

시스템의 시간과 날짜 설정

kernel/time.c

26

ptrace()

부모프로세스가 자식프로세스의 실행을 제어하도록 허가

arch/i386/kernel/ptrace.c

27

alarm()

실정시간후 alarm시그널이 전달되도록 한다.

kernel/sched.c

28

fstat()

파일 상태 얻기

fs/stat.c

29

pause()

시그널이 전달될때까지 대기한다.

arch/i386/kernel/sys_i386.c

30

utime()

파일의 엑세스시간과 수정시간을 수정한다.

fs/open.c

33

access()

파일의 권한을 검사한다.

fs/open.c

34

nice()

프로세스의 우선순위를 번경한다.

kernel/sched.c

36

sync()

슈퍼블럭을 업데이트 한다.

fs/buffer.c

37

kill()

프로세스에 시그널을 전송한다.

kernel/signal.h

38

rename()

파일의 이름과 위치를 변경한다.

fs/namei.c

39

mkdir()

디렉토리를 생성한다.

fs/namei.c

40

rmdir()

디렉토리를 제거한다.

fs/namei.c

41

dup()

열린 파일 지정자를 복사한다.

fs/fcntl.c

42

pipe()

내부통신을 위한 채널을 생성한다.

arch/i386/kernel/sys_i386.c

43

times()

프로세스 시간을 얻는다.

kernel/sys.c

45

brk()

프로세스의 데이터 세그먼트 크기를 변경한다.

mm/mmap.c

46

setgid()

real 그룹 아이디를 설정한다.

kernel/sys.c

47

getgid()

real 그룹 아이디를 얻어온다.

kernel/sched.c

48

sys_signal()

ANSI C 시그널 제어

kernel/signal.c

49

geteuid()

effective 유저 아이디 가져오기

kernel/sched.c

50

getegid()

effective 그룹 아이디 가져오기

kernel/sched.c

51

acct()

프로세스 측정을 켜거나 끈다.

kernel/acct.c

52

umount2()

파일시스템 unmount

fs/super.c

54

ioctl()

장치 제어

fs/ioctl.c

55

fcntl()

파일 제어

fs/fcntl.c

56

mpx

사용되지 않음

 

57

setpgid()

프로세스의 그룹 아이디 설정

kernel/sys.c

58

ulimit()

사용되지 않음

 

59

olduname

구식의 uname 시스템콜

arch/i386/kernel/sys_i386.c

60

umaks()

파일 마스크의 생성

kernel/sys.c

61

chroot()

루트디렉토리의 변경

fs/open.c