============================================================== 제목 : 보호모드 프로그래밍과 운영체제의 개발 원저자 : Jeff Thompson(Mythrandir) 작성자 : edward 작성일자 : 2003. 08. 02 분석및번역: edward_frswz 분석버젼 : ver 0.0.1 라이센스 : GPL 홈페이지 : http://OSx86.ORG or http://osx86.org ============================================================== ======================================================= - 준비물 - 요구지식 리얼모드와 보호모드의 기본적인 지식 x86 어셈블리 언어 기초 틀린 내용이나 이상한 내용은 바로 메일로 씹어주세요. 제가 검증 후 바로 고쳐서 업데이트 하겠습니다. email : osx86@osx86.org ======================================================= 0-A. 글을 시작하기에 앞서 ... 나는 대략 두달전에 운영체제 개발에 대해 맨땅에서부터 배우기 시작해야겠다고 결심을 했습니다. 하지만 이게 처음은 아니죠. 2년정도 전부터 지금까지 운영체제 개발에 관여하고 있었지만 항상 이미 존재하던 운영체제를 사용한 작업이었습니다. 그동안 드라이버 모델에 대해 배회하고, 스트림 구현에 대해 해독하는 것들을 했었죠. 하지만 드라이버 모델은 좋았고, 암호해독은 정말 시러합니다. (% edward : 뭔가 모를 원한이 느껴지는 hate 는 잘 안쓰는데 -_-;; 여튼 뭐 신선하고 새롭게 해보고싶다네요 ) 이 글은 우선 운영체제 개발에 대한 시험을 하는 단계에서 시작합니다. 이글의 주된 초점은 아주 조그마한 커널을 통해 시스템을 보호모드로 만들고 동작하게 하는 것일겁니다. 나는 계속적으로 나만의 운영체제의 디자인을 바랬습니다. .. (% edward : 의미없다 생각되어 생략했습니다. 서두가 무척이나 길군요) 0-B. 간략한 소개 이 문서를 읽는 독자들은 어느정도 레벨의 다음과 같은 지식을 갖추고 있다고 가정하고 쓰여진 것입니다. 그 지식은 c 와 어셈블리 언어 프로그래밍, 그리고 x86 아키텍쳐입니다. GuildOS 개발을 위해 필요한 것들은 다음과 같습니다. (% edward : 필자의 더미 OS 인 듯 ..) ====================================================================== ELF 컴파일러 : 저는 gnu 의 리눅스 기반 ELF 컴파일러를 사용했습니다. 이는 다른 시스템에서 ELF 크로스 컴파일러의 사용이 가능합니다. a386 어셈블러 : 정말 멋진 어셈블러입니다. 또한 부트로더 어셈블리 코드를 다른 어셈블러용으로 변환도 가능하지요. 486+ 머신 : OS를 위한 테스트를 하기위해 머신은 반드시 있어야 겠죠. (% edward : 뭐 꼭 그렇지는 않지만 그렇다고 해두죠.) ====================================================================== 아래의 문서들을 읽어 두는것도 좋으리라 생각됩니다. : Protected Mode Software Architecture by Tom Shanley from MindShare, Inc. ISBN 0-201-55447-X $29.95 US 이 책은 x86 기반의 보호모드 아키텍쳐에 대해 다루고 있으며, 리얼 모드와 보호모드 프로그래밍의 차이에 대해서도 설명하고 있지요. 또한 이 책은 인텔 운영체제 개발자 가이드의 역할도 할 수 있습니다. (% edward : 이 책에 대해서는 대개 상반된 의견을 갖고 있더군요. 페이지에 비해 방대한 범위를 설명하려한다. 라는것과 인텔 메뉴얼을 재구성해놓았다는 혹평이 있더군요.) Developing Your Own 32-Bit Operating System by Richard A. Burgess from SAMS Publishing. ISBN 0-672-30655-7 이 책은 32 비트 OS의 전체적인 개발에 대해 다루고 있으며, 저자는 자신의 32비트 어셈블러와 컴파일러 또한 만듭니다. 상당히 많은 부분이 어셈블리 언어로 작성되었지만 여전히 C는 쓰고 있죠. (% edward : 위의 책은 절판 되었습니다. 그 후속으로 나온게 MMURTL 이죠. 저자도 같습니다. Richard A. Burgess 로 말입니다.) 그 외에도 인텔 아키텍쳐 시리즈 전체와 인텔 OS 개발자 가이드는 그들의 웹사이트에서 무료로 제공되고 있습니다. 제 1장 - 보호모드로의 부팅 x86 아키텍쳐에서 운영체제 셋업의 첫번째 단계는 머신을 보호모드로 전환하는 것입니다. 보호모드는 운영체제 레벨의 보안을 제공하기 위한 하드웨어 보호 개념의 사용을 도와준다. 내가 가장 먼저 시작했던 부트 로더는 JeffOS/loader/first 에 있다. 첫 작업인 부트로더는 플로피의 첫번째 섹터에 위치하게 되었고, 각각의 섹터는 512 바이트로 이루어져 있다. 하지만 보호모드로 부트시키기위해 필요한 코드를 적재시키기 위한 공간 치고는 협소하다. 따라서 나는 부트로더를 두개의 파트로 나누었다. 그것이 first stage 와 second stage 이다. (% edward : first stage 와 second stage 는 뭐 특별한 의미가 있다기보단 자기가 부트로더를 두 파트로 나눴는데 그중 선행 되어야 할것이 first 고 모자란 공간때문에 점프할 코드가 second 라는 말이겠지요. ;-p ) (% edward : 참고로 저자의 홈페이지가 없어졌더군요. 하긴 5년이 지났으니 그래서 제가 웹에서 JeffOS 를 찾아서 링크 해두었습니다. URL : http://www.osx86.org/data/ossrc/jeffos/JeffOS[ver0.1].tgz 저 파일을 열어서 압축을 풀게되면 /loader/first 와 /loader/second 가 있답니다. 그리고 그 압축파일의 크기 또한 30KB 밖에 되지 않더군요. ) POST(Power On Self-Test) 후에 첫번째 섹터는 메모리 위치 0000:7C00 으로 로드되고, 플로피 부트 로더의 first stage는 실행되어야 할 모든 파일들을 메모리로 로드하게끔 디자인 되었으며, 부트로더의 첫번째 명령은 부트 코드로 점프하라는 것이다. 하지만, jump 코드와 부트 코드 사이에는 몇가지 자료구조가 있다. 이 중 첫번째 섹션은 디스크 파라메터이다. 현재 디스크 파라메터에 대한 정보를 사용하지 않지만 다음 버젼을 위한 것이다. 다음 구조의 집합은 플로피 디스크의 다른 데이터 파일에 대한 정보이다. 각각의 구조는 어셈블리 처럼 보인다. ========================================================================= #(%edward : 아래 것들이 AP 로 시작한다 하여 APxx 라고 설명하고 있습니다.) APCX DW 0000h ; 인터럽트 13h 바이오스 루틴을 위한 CX 값 APDX DW 0000h ; DX 값 APES DW 0000h ; ES 값 APBX DW 0000h ; BX 값 APSZ DB 0h ; 읽어들이고자 하는 섹터의 번호 APSZ2 DB 0h ; 사용되지 않음 ========================================================================= (% edward : APxx 만 있는게 아니라 BPxx, CPxx, DPxx 까지 있습니다.) 인터럽트 13h 바이오스 콜은 다음과 같은 인자를 갖는다. (% edward : 특별히 argument와 parameter 를 다른 의미로 설명하지는 않겠습니다. 앞으로의 문서도 마찬가지입니다.) ======================================================= ch: 읽기 시작할 실린더 번호 cl: 시작 섹터번호 dh: 읽기 시작할 드라이브 헤드 번호 (1.44M 플로피 디스크 드라이브는 00h 또는 01h ) dl: 드라이브 번호(디스크 A = 00h) es: 섹터를 읽어 저장할 세그먼트 bx: 섹터를 읽기 위한 세그먼트의 옵셋 ah: 읽어들이기 위한 섹터 번호 al: 인터럽트 13h 함수 번호 (02h = 디스크로 부터 읽어 들이기 위한 함수번호) ======================================================= 나는 second stage 부트 로더를 로드하기위해 APxx 사용하고, BPxx 는 first stage 커널 로더를 로드하기위해 사용했고, CPxx 는 간단한 유저 프로그램을 로드하기위해 사용하며, DPxx 는 커널을 로드하는데 사용했습니다. 다음에 나오는 로더의 구조는 임시 데이터 저장에 사용되는 두개의 unused byte로 이루어지는데, SIZE(APSZ) 는 사용되지만 SIZE2(APSZ2) 는 현재 사용되지 않습니다. 부트 코드는 이러한 구조를 가지며, 이 부트 코드는 스스로를 메모리의 다른 섹션 (선형주소 공간 9000:0000 또는 90000h)으로 스스로 재배치 시키는데, 일단 재배치되고 나면, 부트 코드는 메모리에 모든 파일을 로드하고, second stage 부트 로더의 시작점으로 점프합니다. second stage 부트 로더의 첫번째 부분은 GDT(Global Decriptor Table) 엔트리를 쉽게 정의하는데 사용될 매크로들을 포함하고 있습니다. 보호 모드에서 GDT는 셀렉터에 정보를 저장하는데 사용되며 보호 모드에서 셀렉터는 어떤 세그먼트 레지스터에 저장된 번호에 의해 참조되게 되며, 셀럭터는 다음과 같은 형식을 갖습니다. ============================================ 비트 용도 -------------------------------------------- 15 - 3 디스크립터 테이블 인덱스 2 테이블 지시자(TI) 1 - 0 요구 특권 레벨(RPL) ============================================ 디스크립터 테이블 인덱스 또는 (DT)는 GDT 에 대한 인덱스입니다. GDT 의 첫 번째 엔트리는 00h 이며 두 번째는 08h, 그 다음은 10h 와 같이 되는데, GDT 의 엔트리가 이와 같은 형식으로 진행되는것은 적어도 3개의 LSB 가 다른 정보를 위해 사용되기 때문입니다. 그래서 GDT 에 대한 인덱스를 찾기 위해서는 Segment & 0xfff8 (DT = Selector & 0xfff8) 와 같은 공식을 사용해야 합니다. 테이블 지시자(TI) 는 여러분이 GDT 혹은 LDT(Local Descriptor Table) 중 어떤 것을 선택할 지를 결정하게 됩니다. 나는 아직까지 LDT 를 사용해야할 이유가 없었기 때문에 이에 대해서는 언급하지 않을 것이므로 여러분 스스로 조사해보기 바랍니다. 마지막으로 요구 특권 레벨(RPL)은 셀렉터가 접근하기를 원하는 레벨이 어느것인지 프로세서에게 알려주기 위해 사용됩니다. ==================================================== 0 = 운영체제 레벨 1 = 운영체제 레벨(0보다 낮은 특권 레벨을 갖습니다.) 2 = 운영체제 레벨 (1보다 낮은 특권 레벨을 갖습니다.) 3 = 사용자 레벨 ==================================================== (% edward : RPL 비트 값에 대한 설명이죠. 원래는 위와같이 4가지 특권 레벨을 i386+ 프로세서에서는 지원하지만 우리와 친숙한 리눅스는 2가지 특권 레벨만 사용하는 걸로 기억됩니다. 그 외에도 많은 OS 들이 저 많은 레벨을 다 분리하여 관리 하지는 않죠. 페이징도 i386+ 이 지원하는 모든 기능을 쓰지는 않죠.) 통상적으로 현대의 운영체제는 레벨 0 그리고 3 만을 사용하곤 합니다. (% edward : 재수로 맞춘건가 보네요. ^^;) GDT 엔트리들은 다음과 같은 형식의 다양한 세그먼트 타입을 기술합니다. ============================================= 63 - 56 Base Address의 상위 바이트 55 Granularity(G) Bit 54 Default Bit 53 0 52 Available for Use (free bit) 51 - 48 리미트(Limit)의 상위 Digit 47 세그먼트 Present(P) Bit 46 - 45 DPL(Descriptor Privilege Level) 44 System Bit 43 Data/Code Bit 42 Conforming Bit 41 Readable bit 40 Accessed bit 39 - 32 Base Address 세 번째 바이트 31 - 24 Base Address 두 번째 바이트 23 - 16 Base Address 첫 번째 바이트 15 - 8 리미트(Limit)의 두 번째 바이트 7 - 0 리미트(Limit)의 첫 번째 바이트 ============================================= Base Address 는 (코드 또는 데이터) 세그먼트 디스크립터의 시작 위치입니다. 리미트는 바이트의 수 또는 4k 페이지입니다. 이 때 바이트 인지 4k page 인지는 Granularity 비트에 따라 결정됩니다. 만약 Granularity(G) 비트가 0이면 limit 는 바이트의 길이를 나타내고, G 비트가 1이면 리미트는 4K 페이지의 세그먼트의 길이를 나타냅니다. Default 비트는 코드 세그먼트가 16비트 또는 32비트 인지를 나타냅니다. Default 비트가 0 이면 코드 세그먼트는 16비트가 되고 1이면 32비트가 됩니다. Present 비트는 세그먼트가 현재 메모리에 있으면 1로 세트되며, 이는 가상 페이징에서 사용됩니다. DPL 은 RPL 과 비슷합니다. DPL 은 세그먼트의 보호 레벨이 어느것인지 알려주게 되는데, DPL 의 값은 RPL 의 값과 동일한 의미를 갖습니다. (% edward : 특권레벨이 높음 - 0 < 1 < 2 < 3 - 낮음 ) System 비트는 세그먼트가 시스템 세그먼트를 갖는지 알려주는데 사용됩니다. 만약 System(OS) 세그먼트라면 System 비트는 0 이 됩니다. data/code 비트는 세그먼트가 code 세그먼트로 사용될 것인지 data 세그먼트로 사용될 것인지를 알려주는데 사용됩니다. code 세그먼트는 쓰기가 불가능하며 실행을 위한 코드에 사용되며 data 세그먼트는 스택과 프로그램 데이터의 용도로 사용될 수 있습니다. 이는 위에서 묘사한 것과는 약간 다르답니다. Readable 비트는 정보를 세그먼트로 부터 읽을 수 있는지 혹은 실행만 가능한지를 알려주기 위해 사용됩니다. second stage 플로피 부트로더의 다음 파트는 A20 Address 라인을 사용가능하게 만드는 코드를 포함하고 있습니다. A20 Address 라인은 여러분이 일반적인 DOS 리얼 모드 에서 1MB 한계 이상을 넘어서서 메모리 엑세스를 가능하게 합니다. A20 Address 라인에 대한 자세한 내용은 Intel 아키텍쳐 책을 참조해주세요. (% edward : IASDM 3 의 7.6.4.3, 16.1.1, 18.29, 을 참조하세요.) 일단 GDT 가 사용가능하게 되면, 어셈블리 파일의 끝부분에 존재하는 데이터가 GDT 레지스터로 로드됩니다. 이는 반드시 보호모드로 전환하기전에 완료해야 합니다. 만약 그렇지 않으면 어떤 메모리에 대한 접근은 적절한 셀렉터를 갖지 못하게 될것이고 따라서 이들에 의해 fault 가 발생하게 될겁니다. (이는 경험에 의해 얻은 것입니다.) 일단 이런 데이터를 GDT 레지스터로 로드하고 모든 동작이 완료되면, CR0 레지스터의 보호모드 비트를 1로 만들어 보호모드로 진입하게 됩니다. 그 다음에 나오는 코드는 보호모드를 사용가능하게 만드는 것이며, 거기에는 second stage 부트 로더의 다음 부분으로 fal call 하는 데이터가 있습니다. 이는 정의되지 않은 세그먼트와 대립하는 CS 를 위해서 사용될 새로운 셀렉터를 발생시킵니다. 그리고 코드는 단순히 데이터 세그먼트를 위한 다양한 셀렉터를 셋업하는 곳으로 점프하게 되고, 점프한 곳에는 화면에 출력을 하는 몇가지 단순한 디버깅 코드가 있습니다. 이는 제가 사용하기 위한 용도로 만든 것이니 삭제되어도 상관 없습니다. 그리고 나서 스택 세그먼트는 스택 포인터에 따라 셋업 되며, 저는 스택을 90000h 에 위치시켰습니다. 마지막으로 커널에 의해 회복되어야 할 스택을 위한 값을 스택에 push 하고, first stage 로더에 있는 커널을 위한 선형주소 100080h 를 호출하게 됩니다. (% edward : 좀 쉬었다가 음 ... 인생의 고독을 씹으며 담배도 한대 피우고 노래도 한곡 부르고 계속 해야겠습니다. ) 제 2 장 - first stage 커널 부트 로더 first stage 커널 부트 로더는 \boot 에 위치해 있습니다. 부트 로더는 ELF 에서 TEXT 섹션의 주소를 수집하여 점프하고 실행 할것입니다. (% edward : 여기서 Text 는 절대 문서나 그런것이 아니라 Elf 포맷의 한 섹션입니다. 자세한 내용은 제가 번역, 분석한 ELF 문서나 ELF 스펙을 참조하시기 바랍니다.) makefile 에서 text 의 주소를 10080h 로 잡아 두었으므로, 10080h 가 될것입니다. (% edward : JeffOS 의 boot 디렉토리의 메이크 파일안을 보면 아래와 같이 LD 로 링킹 작업을 하고 있습니다. $(LD) -o $@ $(OBJS) -dN -Ttext 0x10080 ) 첫 번째 80h 바이트는 ELF 헤더에서 사용되고, 나는 이 정보를 완전히 무시하고, 바로 선형 메모리 주소인 10080h 로 점프합니다. 이는 내가 새로운 버젼의 ELF 컴파일러가 약간 다른 헤더의 길이를 가지며 이러한 값은 수정되어야 할 필요가 있을지도 모른다고 생각하고 있기 때문이며, TEXT 세그먼트의 시작을 어디로 해야할 지 DOS의 DEBUG와 같은 역어셈블러를 사용해 결정 할수도 있기 때문입니다. 부트 로더를 위한 중요한 두개의 파일들은 main.c 와 mem.c 입니다. main.c 는 "void _start(unsigned long blh);" 함수를 포함하고 있으며, 이 함수는 반드시 첫 번째 함수로 링크되어야 합니다. 따라서 main.c 는 반드시 링크된 첫 번째 file 이어야 하며, _start() 는 반드시 첫 번째 함수가 되어야 합니다. 이러한 점에 대한 보증은 10080h 의 위치에서 시작하는 것이 될 것입니다. 파라메터 blh 는 second stage 부트 로더에 의해 push 되는 값입니다. _start 의 첫 번째 과제는 메모리를 초기화하는 루틴인 kinit_MemMgmt 를 호출하는 것입니다. 첫 번째 과제인 kinit_MemMgmt 가 하는 일은 nMemMax 를 0xfffff로 만드는 것이며, 이 16진 값은 1MB로 시스템의 최대 바이트 수를 정하는 것입니다. 그리고 나서 kinit_MemMgmt 는 시스템 상에 free 한 메모리의 양을 계산하기 위한 함수 인 kmemcount 를 호출 합니다. 일반적으로 이 루틴은 적절하게 동작하지 않고, 시스템에 대충 2MB 의 Free memory 가 있는 것으로 가정해버립니다. 이 정도면 지금은 충분하지만 나중에는 수정되어야 할 필요가 있을지도 모르겠군요. 그리고 나서 kinit_MemMgmt 는 커널을 위한 페이지 테이블을 세트하는 kinit_page 함수를 호출합니다. 페이징은 태스크가 엑세스 할 수 있는 메모리를 결정하기 위해 사용되는 메커니즘입니다.(% edward : -_-;) 이는 태스크가 엑세스 할 "virtual (가상)" 메모리 공간을 생성하게 됩니다. 메모리 엑세스가 발생할때 마다, 프로세서는 "실제(real)" 물리적 메모리가 어떤 메모리 위치에 존재하는지 알기 위해 페이지 테이블을 조사합니다. 예를 들면, 커널은 각각의 태스크가 스택용도로 사용하기 위한 메모리의 32k(8개의 페이지)를 가리길 수 있습니다. 만약 페이징 된 메모리를 사용하지 않았다면 이러한 각각의 메모리 위치는 실제 주소와는 다르게 되어 버릴수도 있습니다. 그리고 페이징을 사용할 때 이러한 각각의 물리적인 메모리의 할당을 동일한 위치에서 발생할 수 있는 응용 또한 허용할 수 있는 페이징 된 주소로 매핑시킬 수 있습니다. (% edward : 횡설 수설 -_-; 뭐 쉽게 이야기 하면 실제 물리적 주소를 쓰는 것보다는 페이징 된 주소를 쓸때 메모리를 공유하기도 편하다는 이야기 인 듯하네요. 관리하기도 편하고 말예요. ) 페이지 테이블들은 다음과 같은 형식으로 구성됩니다. 우선은 페이지 디렉토리 인데, 페이지 디렉토리는 1024개의 엔트리로 구성되며 아래와 같은 속성을 갖습니다. ====================================== 31 - 12 Page Table Base Address 11 - 9 Unused (Free bits) 8 0 7 Page Size Bit 6 0 5 Accessed Bit 4 Page Cache Disable Bit 3 Page Write Through Bit 2 User/Supervisor Bit 1 Read/Write Bit 0 Page Present Bit ====================================== (% edward : 아흑 ~ ㅜ.ㅜ 또 페이징 관련 표군요. 맨날 그리게 되네요 ㅜ.ㅜ 아흑 아흑 ... 설명이 부족하다고 생각 되시는 분들은 이전글을 참조하세요. 저도 이거 자꾸 쓰니까 지겹네요. ) Page Table Base Address 는 메모리 위치에 대한 정보를 포함하는 페이지 테이블의 인덱스 입니다. 메모리 위치가 엑세스 될때 이 중 Most Significant 10 비트는 페이지 디렉토리에서 1024 개의 엔트리중 하나를 참조하는데 사용됩니다. 이 엔트리는 Page Table Base Address 와 일치하는 물리적 메모리 주소를 갖는 페이지 테이블을 가리킵니다. 그리고 나서 이 테이블은 메모리 주소의 12~21 비트에 의해 1024개의 엔트리중 하나를 참조합니다. (% edward : 뭐 항상 같은것이 아니기 때문에 이 부분에 대해 전체적으로 알고 싶으시다면... IASDM 3 를 참조하시는것이 좋을 듯 여러가지 변형이 존재하므로 꼭 이렇다 라고 할 순 없지요. 이 사람은 그렇게 했다 라고 하네요.) Page Size Bit 는 각각의 페이지가 (Bit = 0)4kb 인지 또는 (Bit = 1) 4MB 인지 알려주는 역할을 합니다. (% edward : 전체 가상 메모리의 크기를 결정하는 중요한 비트죠.) Acessed bit 는 페이지가 엑세스 된 적이 있는지 알려주는 역할을 합니다. 일단 1로 세트되면 OS는 반드시 그것을 0으로 리셋해야 합니다. 이는 가상 페이징에서 사용됩니다. Page Cache Disable Bit 와 Page Write Bit 는 정의 하지 않았으며 현재 사용하지 않습니다. User/Supervisor 비트는 페이지 테이블이 특권레벨 0,1,2 또는 3 을 사용하는 태스크에 의한 엑세스를 제한하기 위해 기술된 비트입니다. 만약 이 비트가 0으로 세트되면 특권 레벨 0, 1, 2 를 사용하는 태스크 만이 페이지 테이블을 엑세스 할 수 있으며 이 비트가 1로 세트되면, 이 페이지 테이블은 특권 레벨 0, 1, 2, 3 을 갖는 모든 태스크가 엑세스 할 수 있습니다. Read/Write 비트는 유저 레벨 태스크가 이 페이지 테이블에 쓰기가 가능한지 결정하는 비트입니다. 만약 이 비트가 0이라면 "유저(User)" 태스크는 페이지 테이블에 대해 읽기만이 가능하고 이 비트가 1이라면 모든 태스크에 대해 읽기 쓰기가 가능합니다. 마지막으로 Present 비트는 페이지 테이블이 현재 메모리에 있는지 알기 위해 사용됩니다. 만약 이 비트가 1이면 메모리에 있음을 나타냅니다. 일단 페이지 디렉토리가 참조되고 나면 페이지 테이블 내의 offset 은 선택됩니다. 다음의 메모리 참조의 10 비트를 사용하게 되지요. 각각의 페이지 테이블은 1024 개의 엔트리를 갖고 각각의 엔트리는 다음과 같은 구조로 되어 있습니다. =================================== 31 - 12 Page Base Address 11 - 9 Unused (Free bits) 8 - 7 0 6 Dirty Bit 5 Accessed Bit 4 Page Cache Disable Bit 3 Page Write Through Bit 2 User/Supervisor Bit 1 Read/Write Bit 0 Page Present Bit =================================== Page Base Address 는 엑세스될 메모리에 대한 물리적 메모리의 상위 20비트를 가리킵니다. 하위 12비트는 선형 메모리 엑세스로 부터 얻게 되죠. Dirty, Accessed, Page Cache, 그리고 Page Write Through 비트는 모두 가상 메모리와 아직은 관여한 적이 없는 다른 영역에 의해 사용되는 비트입니다. 그외에 나머지 3비트는 페이지 디렉토리에 사용된다. 모든 커널 페이지들은 Supervisor, Read/Write, Page Present 비트가 세트되고, 유저 페이지는 Superviosr 비트가 세트되지 않습니다. kinit_page 코드는 3개의 물리적 페이지중 첫번째 페이지에 페이지 디렉토리를 생성시킵니다. 다음 페이지는 4MB (1024개의 페이지 테이블 엔트리 중 하나가 1024개의 4KB 크기의 페이지를 가리키므로 4MB)의 유저 메모리 영역(low)을 생성 시키는데 사용됩니다. 세 번째 페이지는 OS(high) 메모리 영역을 가리키는데 사용됩니다. (% edward : 로우와 하이 메모리 영역 코드 ... ================================================================== // Map in the first 4MB as one to one addresses into low PageTbl flat[1024 + i] = 4096 * i | 3; // Map in 10 pages into high memory which are the kernel flat[2048 + i] = i > 10 ? 0 : ((uint32)0x70000 + 4096 * i) | 3; ==================================================================) kinit_page 함수는 모든 low 페이지 메모리를 물리적 메모리 영역으로 세트 시킵니다. 이것의 의미는 첫 4MB 의 메모리가 페이지 된 메모리와 1:1로 상호관계를 갖는다는 것입니다. 그리고 나서 kinit_page 는 선형주소 0x80000000 에서 70000h 지점부터 시작하는 10개의 페이지를 메핑합니다. 페이지 디렉토리의 엔트리 번호 0 은 low(유저) 페이지 테이블을 가리키게 되고, 페이지 디렉토리의 엔트리 번호 512 는 high(OS) 페이지 테이블을 가리키게 됩니다. 마지막으로 kinit_page 함수는 페이지 디렉토리의 주소를 cr3 레지스터에 넣게 되고, 이는 프로세서에게 페이지 테이블을 어디서 찾아야 될지 알려주는 것이 됩니다. (% edward : cr3 가 페이지 테이블의 주소를 가리키게 된다는거죠 .) 그리고 cr0 는 프로세서에게 직접 물리적 메모리 접근을 하기 보다는 페이지 테이블을 통해서 메모리 접근을 하라고 알리는 페이징 비트를 세트시키게 됩니다. 이 후에 _start 함수로 돌아오고 k_start() 를 호출하여 메인 커널에 _start() 를 가리키는 0x80000080 으로 세트됩니다. 부트 코드인 _start() 함수는 k_start() 함수를 호출하여 리얼모드 커널을 내린다는 의미입니다. (% edward : 페이징을 완료한뒤 실제 커널을 k_start() 함수를 호출하는건 당연하겠죠. 실제 커널은 kernel 디렉토리 밑에 있습니다. 지금부터 나오는 내용은 kernel 디렉토리 밑에 있는 main.c 와 mem.c 입니다. void (*k_start)(void) = (void (*)(void)) 0x80000080; ) 제 3장 - 커널 커널은 정말 모든 재미의 시작입니다. 커널 부트 로더는 커널 페이지 테이블을 생성하고, 커널의 _start(); 로 점프하게 됩니다. 그리고 나서 _start() 함수는 콘솔을 셋업하고, 클리어 시킨 뒤 "Main kernel loaded" 라는 메시지를 출력하게 됩니다. 일단 이러한 작업들이 완료되고 나면 메모리 관리자 초기화 루틴인 kinit_page() 을 실행하게 됩니다. 메모리 관리자 초기화 루틴은 PMAT 라 불리는 구조를 초기화로 시작되고, PMAT 는 각각의 비트가 물리적 메모리 하나의 페이지로 표현되는 2048 바이트 크기를 갖는 거대한 비트 필드로 구성됩니다. 만약 비트가 1로 세트 되면, 메모리의 페이지는 Allocate 될것이며 비트가 0으로 세트되면 Unallocate 될 것입니다. 이런 배열은 이미 사용중인 물리적 메모리 조각 인 메모리 관리 코드를 초기화 하게 되고, 시스템 BUS 메모리 영역 뿐만 아니라 물리적 메모리 상의 커널 자체 위치를 포함하게 됩니다. 이 메모리 관리자가 _start() 함수로 리턴하게 되고, 커널 초기화시에 함께 진행됩니다. 그리고 나서 _start() 함수는 first stage 플로피 로더에 의해 사용자 프로그램을 로딩하는데 사용 될 메모리 할당을 위해서 사용할 임시 함수를 호출한다. 이 함수는 물리적 메모리 위치 20000h 의 선형주소 공간에 세트된다. 기본 메모리 시스템이 셋업되고, _start() 함수는 kinit_task() 함수를 호출한다. kinit_task() 는 시스템 상의 프로세스 보다는 태스크를 수행하기 위한 커널 태스크를 셋업한다. kinit_tast()는 kinit_gdt() 와 kinit_ktask() 라는 두개의 다른 함수를 호출하는 실제 쉘 함수입니다. kinit_gdt()는 second stage 플로피 부트 로더에 의해 셋업되는 임시 커널이 아닌 새로운 커널에 사용될 GDT 를 초기화합니다. 일단 GDT 를 위한 새로운 위치는 여러개의 셀렉터로 연결된 메모리와 매핑되고, 커널 코드와 데이터 셀렉터도 추가되며, 유저 코드와 데이터 셀렉터도 추가됩니다. 이러한 셀렉터들이 특정한 위치에 놓이게 되면, 새로운 GDT 는 사용될 수 있게 끔 프로세서의 GDT 레지스터에 놓이게 된답니다. 그리고는 kinit_task() 는 kinit_ktask() 함수를 호출합니다. 이 태스크는 커널 코드가 실행될 태스크를 생성합니다. 이 함수가 첫째로 하는 것은 커널 태스크 리스트를 비우고, 이 리스트에는 시스템 상의 태스크의 목록을 포함시킵니다. 다음의 4k 페이지는 커널 태스크 세그먼트를 위해 할당됩니다. 그리고 나서 현재 실행중인 태스크는 커널 태스크로 설정되고, 다음 태스크 세그먼트는 GDT 에 추가 됩니다. 추가된 태스크 세그먼트는 다음의 구조를 가지며, 제가 의도한 값을 사용해 커널을 채우게 됩니다. 사실상 이 설정으로 모든 태스크는 시작되게 됩니다. ======================================================================== struct TSS { ushort link; // set to 0 ushort unused0; ulong esp0; // set to the end of the task segment page ushort ss0; // set to SEL_KDATA (Kernel Data segment) ushort unused1; ulong esp1; // set to 0 ushort ss1; // set to 0 ushort unused2; ulong esp2; // set to 0 ushort ss2; // set to 0 ushort unused3; ulong cr3; // set to the physical address of this tasks page // tables ulong eip; // set to the entry point to this tasks code ulong eflags; // set to 0x4202 ulong eax, ecx, edx, ebx, esp, ebp, esi, edi; // set to garbage values ushort es; // set to SEL_KDATA (Kernel data segment) ushort unused4; ushort cs; // set to SEL_KCODE (Kernel code segment) ushort unused5; ushort ss; // set to SEL_KDATA ushort unused6; ushort ds; // set to SEL_KDATA ushort unused7; ushort fs; // set to SEL_KDATA ushort unused8; ushort gs; // set to SEL_KDATA ushort unused9; ushort ldt; // set to 0 ushort unused10; ushort debugtrap; // set to 0 ushort iomapbase; // set to 0 }; ======================================================================== 인터럽트가 호출되었을때 링크(link) 필드는 프로세서에 의해 사용됩니다. 프로세서는 좀더 높은 우선순위를 갖고 수행중이던 인터럽트 인 태스크 세그먼트에 포인터를 둡니다. 이는 호출한 프로세스 기반의 접근 권한을 결정하는데 매우 유용합니다. espx 와 ssx 파라메터는 하위 특권 레벨을 사용하는 태스크가 상위 특권 레벨 영역을 엑세스 하려고 할때 사용될 스택을 가리키기 위해 주소를 저장하는 용도로 쓰입니다. cr3 파라메터는 태스크들을 위한 페이지 테이블의 물리적 주소를 가리키기 위한 용도로 사용됩니다. 태스크가 스위치 될때마다 프로세서는 cr3 에 저장된 값을 cr3 레지스터로 로드합니다. 이말의 의미는 각각의 태스크가 독특한 페이지 테이블과 매핑을 가진다는 것이지요. eax, ebx, ... 등의 레지스터들은 한번 사용되고, 초기화 되지 않을 모든 무의미한 값들을 세트 시킵니다. 프로세서가 태스크 전환을 할때, 이러한 파라메터들은 그들 각각의 프로세서 레지스터로 로드됩니다. cs,es,ss,ds,fs 그리고 gs 파라메터는 태스크가 전환될때 그들 각각의 프로세서 레지스터로 로드되어야 할 중요한 값으로 세트됩니다. 저는 로컬 디스크립터(LD)를 사용하지 않았으므로, 이 파라메터를 debugtrap 과 iomapbase 파라메터와 함께 0으로 세트 시켰습니다. 늘 내가 언급했지만, 태스크가 전환될때 프로세서는 태스크 세그먼트로 부터 모든 파라메터를 읽어들이고, 그들 각각의 레지스터로 로드된다. 뿐만 아니라 동작 중이던 태스크가 전환되어서 중지되게 되면, 모든 레지스터는 그들 각각의 파라메터로 저장되게 되고, 태스크는 suspend 모드나 restart 를 위한 모드로 빠지게 된다. 태스크의 전환(스위칭)은 이후에 커널 부분중 태스크 스위칭에 도달하게 되면 설명하게 될 것입니다. 일단 이 태스크 상태 세그먼트(TSS) 가 생성되고, TSS 는 태스크 세그먼트를 가리키기 위한 GDT 엔트리를 생성하기 위해서 꼭 필요한 것입니다. TSS 의 64 비트 엔트리 포맷은 다음과 같습니다. ======================================== 63 - 56 Base Address의 네 번째 바이트 55 Granularity(G) 비트 54 - 53 0 52 Available for use (free bit) 51 - 48 Upper Nibble of Size 47 Present in Memory Bit 46 - 45 디스크립터 특권 레벨(DPL) 44 System Built 43 16/32 비트 42 0 41 Busy 비트 40 1 39 - 32 Base Address의 세 번째 바이트 31 - 24 Base Address의 두 번째 바이트 23 - 16 Base Address의 첫 번째 바이트 15 - 8 Segment Size의 두 번째 바이트 7 - 0 Segment Size의 첫 번째 바이트 ======================================== 이미 본바가 있겠지만, 이 구조는 코드 세그먼트 디스크립터와 매우 흡사합니다. 차이가 있다면 16/32 비트, 그리고 Busy 비트 입니다. 16/32 비트는 TSS 가 16 비트 인지 32 비트인지를 알려줍니다. 우리는 32BIT 태스크 세그먼트만을 사용할 것이므로 이 비트는 1 이 됩니다. 16비트 TSS 는 286을 위해서 사용되는데, 386 이상의 머신에서는 32비트 TSS 로 대치 되었습니다. Busy 비트는 태스크가 현재 busy 상태인지를 기술합니다. 일단 커널 태스크가 할당되고 나면 새 커널 스택이 할당되고, 동작할 수 있는 상태가 됩니다. 이와 같은 작업은 알려진 스택이 커널의 메모리 관리자를 사용하여 특정위치에 매핑 될 수 있게 해줍니다. 그리고 나서 유저 태스크는 커널 태스크와 비슷한 형태로 생성됩니다. 현재의 구현으로는 유저 태스크가 0x20000에 위치하게 되고, 유저 태스크의 스택은 0x2107c 에 위치하게 됩니다. 일반적으로, 이 유저 태스크는 OS 레벨의 특권을 갖고 동작합니다. 이 OS 특권 레벨을 갖는 유저 태스크의 셀렉터를 GDT 의 유저 엔트리로 변경할 때 나는 몇가지 문제점에 직면하게 되었답니다. 내가 이 문제점을 고치게 되면 내 웹 사이트에 수정부분을 포스트 하게 될겁니다. 여하튼 유저 태스크가 생성된 후에 유저 태스크는 스케쥴러가 시작되어 다른 태스크와의 전환을 위해서 태스크 큐에 추가 됩니다. 이제 커널 태스크와 (비록 커널 특권 레벨을 갖고 동작하는 유저 태스크 이지만) 유저 태스크는 생성이 완료 되었는데 이는 인터럽트 테이블을 셋업하기 위해서는 필수적인 작업입니다. 인터럽트 테이블을 셋업하는 작업은 kinit_idt() 함수에 호출에 의해 완료 됩니다. kinit_idt() 는 null 인터럽트 함수를 가리키기 위한 모든 인터럽트의 세팅으로 부터 시작됩니다. null 인터럽트 함수의 의미는 대부분의 인터럽트가 단순히 return 하는 역할만 한다는 의미입니다. 하지만 타이머와 하나의 시스템 콜을 위한 인터럽트 핸들러는 있어야 되겠지요. 또한 인터럽트는 다양한 예외를 처리하기 위해 셋업됩니다. 일단 이 테이블이 채워지면 인터럽트 디스크립터 테이블(IDT)은 idt 레지스터로 로드됩니다. 그리고 인터럽트들은 그들이 호출될 수 있도록 사용가능한 상태가 됩니다. 타이머 인터럽트 핸들러는 하드웨어 타이머가 동작하는 매 시간 마다 태스크 전환을 발생시키는 간단한 함수입니다. 시스템 콜(인터럽트 22h)은 호출되고, 핸들러는 eax 레지스터가 가리키는 곳의 문자열을 콘솔에 출력할 것입니다. 예외 핸들링 루틴은 태스크 레지스터로 덤프될 것이고, 시스템은 hang(정지된) 상태가 됩니다. JeffOS/kernel/ 에 있는 jump.S 파일은 인터럽트가 발생될 때 호출되는 어셈블리 래퍼를 포함하고 있습니다. 이 래퍼 함수들은 C 핸들러 함수를 호출합니다. 이제 IDT 는 셋업 되었고, 인터럽트가 발생하는 동안 태스크 전환이 일어날 수 있습니다. task.c 파일의 swtch() 함수가 호출될때 이러한 일이 발생합니다. swtch() 함수는 태스크 큐의 다음 태스크로 위치시키고, 새로운 태스크의 셀렉터 주소를 호출하게 됩니다. 이러한 행위는 프로세서가 셀렉터를 찾게 하고,새로운 태스크로 전환 되게 됩니다. 여러분은 이제 매우 단순한 멀티-태스킹 커널에 대해 알게 되었습니다. 제 4장 - 유저 레벨 라이브러리 유저 레벨 라이브러리는 정말 단순합니다. 여기에는 2개의 파일이 있습니다. 첫째로 crt0.c 파일이 있는데, 이 파일은 _start() 함수를 포함하고 있습니다. _start() 함수는 유저 코드에서 정의될 main 함수를 호출하게 되는데, 이 stub 함수는 프로세스의 실행을 시작하기 위해서 커널에 의해 점프되어야 하는 첫부분에 항상 링크되게 됩니다. 두 번째 파일은 syscall.c 파일입니다. 이 파일은 단순히 인터럽트 22를 수행하는 하나의 system call 함수를 포함합니다. 인터럽트는 콘솔 시스템 콜을 호출하게 되는데, eax는 시스템 콘솔에 출력될 문자열에 대한 포인터를 전달하게 됩니다. 이러한 두개의 소스 파일은 컴파일 되어서 사용자 코드를 링크할때 사용됩니다. 제 5장 - 유저 코드 유저 코드는 test.c 라는 파일에 저장되게 됩니다. 이 파일은 /user 디렉토리에 위치해 있으며, 모든 코드는 라이브러리에 의해 지원되는 콘솔 시스템 콜 함수를 호출하게 되고, 약간의 시간동안 기다린 후 다시 시스템 콜을 호출하게 되는 무한 루프로 구성되어 있습니다. (태스크 종료 처리를 하지 않는게 좋다고 생각합니다.) 이 유저 프로세스를 세트 할때 링킹할때 중요한 것은 선형 주소 영역 20000h 의 text 세그먼트를 가져야 한다는 것입니다. 그리고, crt0.o 와 syscall.o 파일 또한 링크 되어야 합니다. 커널에 의해 점프되게 될 것이므로 crt0 는 그 자체의 _start() 함수인 20080h 에 링크되어야 합니다. 사실 _start() 는 main() 함수와 대립되는 실제 메인 함수 입니다. (% edward : 실제로 main 함수에서 시작한다고 착각을 하시는 분들이 간혹 계신데 _start() 가 맞는걸로 알고 있습니다. 자세한 내용은 시간날때 분석 문서를 하나 만들어 보겠습니다. ) 이 코드는 생성된 태스크이며, 커널과 함께 실행 되게 됩니다. 제 6장 - 바이너리 디스크 이미지 생성하기 모든 소스들이 바이너리로 컴파일 되고, build 디렉토리에 두개의 파일을 생성해야 합니다. 이 파일들은 STUFF.BIN 과 STUFF2.BIN 인데 단순히 다른 바이너리들의 정렬을 위해서 빈 공간을 채우는 컨테이너 역할을 합니다. 플로피 로더는 1K 크기의 사용자 프로그램을 요구하게 됩니다. 만약 사용자 프로그램이 정확하게 1K 크기를 갖지 않는 다면, STUFF2.BIN 은 생성될 필요가 있고, USER.BIN 에 어떤 크기가 부가되어 1024 바이트가 됩니다. 또한 플로피 부트 로더는 3.5K(3584 바이트) 크기의 커널 부트 로더ㅡㄹ 요구하게 됩니다. STUFF.BIN 은 BOOT.BIN(커널 부트 로더)의 크기에 추가될 어떤 길이로 만들어질 필요가 있고 커널 부트 로더 파일의 크기는 3584 바이트가 됩니다. 나중에 이 프로세스를 자동화 할 것이지만 지금은 작업들을 단순화시켜 놓은 쉘 프로그램인 go를 실행해야 됩니다. go 쉘 프로그램은 모든 바이너리 파일들을 통해 os.bin 이라는 파일을 만들게 될것이고, 이렇게 만들어진 os.bin 파일은 다음의 두가지 방법을 통해 디스크에 쓸 수 있다. 만약 여러분의 환경이 리눅스라면 ================================================ dd if=os.bin of=/dev/fd0 플로피 디스크에 os.bin 을 저장 ================================================ 도스 환경이라면 rawrite 를 실행하여 지시에 따르면 됩니다. --- 결론 이 커널은 완성과는 거리가 멀지만 다만 실제 보호모드 운영체제를 생성하기위한 시작일 뿐입니다. 그리고 보호모드 운영체제 제작에 대한 시작을 어떻게 해야 할지 하는 참고자료로는 충분하다고 봅니다. 머 어쩌구 저쩌구 날밤까고 -_- 좌절도 하고 이리저리 고생이 많았지만 이 모든 것은 매우 재미 있었고, 여러분들도 꼭 성공하길 바랍니다. Jeff Thompson ================================================================ edward 의 문서 작성후기 정말 두서없이 내용이 나가고 있는데 ... 제가 엉망으로 만들고 있는건지 이 사람이 원래 두서 없이 쓴건지 알 수가 없네요. 정말 두손 두발 다 들었습니다. 마침표 빼먹는건 기본이고, 콤마 빼먹는건 장난처럼 하는 사람이군요. ㅜ.ㅜ 상습범입니다. -_-)a 심한 정도를 초월하는 사람이군요. 극단적인 예를들면 동사가 없는 문장도 이 분은 척척 만들어 내십니다. -_-; 그래도 이만큼 이라도 문서작업을 해두었으니 저희는 감사해야 되는 입장이겠죠. ^^; ( ㅜ.ㅡ ) ================================================================