* 참고 : http://blog.naver.com/PostView.nhn?blogId=jeix2&logNo=80007589533&viewDate=¤tPage=1&listtype=0
=> 유용한 그림이 많은 듯. 나중에 다시 보자.
* 출처 : 인텔 메뉴얼 "VOLUME 3A: System Programming Guide Part 1"의 "3.4.5. System Descriptors" 참고
인텔 메뉴얼을 그대로 해석해보았다. 미숙한 영어실력이지만 궁금해서..
3.2 세그먼트의 사용( Using Segments )
IA-32 아키텍쳐에 의해 제공되는 세그먼테이션 메커니즘은 매우 광범위한 시스템 디자인을 수행하는데 사용될 수 있다.
디자인에는 프로그램을 보호하기 위해 단지 작은 세그먼테이션의 사용을 하는 flat model 과,
다수의 프로그램과 일이 신뢰성 있게, 확실하게 수행될 수 있도록 하는 (체체, 조직이) 탄탄한(robust 한) 운영체제 환경을 만들기 위해
세그먼테이션을 사용하는 Multi segmented model 이 있다.
3.2.1 Basic Flat Model
시스템을 위한 가장 간단한 메모리 모델은 "flat model"이다. 이 시스템에서는 운영체제와 application program이 연속된, 세그먼테이션 되지 않은 주소 공간에 접근한다.
확장이 최대로 가능하도록 하기 위해 basic flat model은 아키텍쳐의 세그먼테이션 메커니즘을 시스템 디자이너와 application 프로그래머로부터 숨긴다.
IA-32 아키텍쳐로 basic flat memory model을 수행하기 위해서는 최소한 두 개의 세그먼트 레지스터가 생성되어야 한다. 하나는 코드 세그먼트를 참조하기 위한 것,
또 하나는 데이터 세그먼트를 참조하기 위한 것이다. (그림 3-2를 참조하라) 그러나 두 개의 세그먼트는 전체 선형 주소 공간과 매핑되어있다. 즉, 두 개의 세그먼트 디스크립터가 같은
base 어드레스 '0' 을 가지며, segment limit은 4 GBytes이다. 세그먼트 limit을 4 GByte로 설정함으로써, 세그먼테이션 메커니즘은 out of limit memory 참조에 대한 예외를 생성하는 것
(generating exceptions for out of limit memory references)이 가능하지 않다. 심지어 특정 어드레스에 아무런 물리적 메모리가 상주하고 있지 않은데도 불구하고 말이다.
ROM(EPROM)은 일반적으로 물리 주소 공간의 맨 위에 위치한다. 왜냐하면 프로세서는 FFFF_FFF0H 에서부터 수행을 시작하기 때문이다. RAM(DRAM)은 주소 공간의 밑 부분에 위치
한다. 왜냐하면 리셋 초기화 후에 DS 데이터 세그먼트를 위한 초기 Base address 가 0이기 때문이다.
▶ 이쯤에서 참고해보는 메모리 맵
3.2.2 Protected Flat Model
protected flat 모델은 segment limit 값이 실제 물리 메모리 주소가 존재하는 주소 범위만을 포함한다는 점만 제외하면 basic flat 모델과 유사하다.
존재하지 않는 메모리에 접근하려는 어떤 시도, 노력이 있을 때 general-protection exception(#GP)이 발생하게 된다. 이 모델은 몇몇 종류의 프로그램 버그에 대해 최소 수준의 하드웨
어 보호를 제공한다.
protected flat model에 더 많은 보호를 제공하기 위해서는 더한 복잡성이 더해질 수 있다. 예를 들어, 유저 코드ㆍ데이터와, 관리자(supervisor) 코드ㆍ데이터를 격리(isolation) 시키는
것을 제공하기 위해서는 네 개의 세그먼트의 정의가 요구된다. : 유저를 위한 특권레벨 3에 해당하는 코드와 데이터 세그먼트와 관리자를 위한 특권 레벨 0에 해당하는 코드, 데이터 세그
먼트가 필요하다. 대게 이 세그먼트들은 모두 서로서로 덮어 씌운다. 그리고 선형 주소 공간의 0 주소에서 시작한다. 간단한 페이징 구조를 따르는 이 flat segmentation 모델은 application
으로부터 운영체제를 보호할 수 있다. 그리고 각각의 task나 프로세스에 대해 나눠진 페이징 구조를 더함으로써, application끼리의 보호도 서로서로 가능하다. 유사한 디자인이 몇몇 유명
한 멀티테스킹 운영체제에 사용된다.
3.2.3. Multi-Segment Model
multi-segment model은 코드, 자료구조, 프로그램과 task에 대한 의무적인 보호를 제공하기 위하여 세그먼테이션 메커니즘의 최대한의 능력, 역량(full capabilities)을 발휘한다.
여기, 각각의 프로그램(이나 task)은 자기 자신만의 세그먼트 디스크립터와 자신만의 세그먼트에 대한 테이블을 갖는다. 세그먼트는 그들의 할당된 프로그램에 완벽하게 개인 소유일 수
도 있고, 프로그램끼리 공유할 수도 있다. 시스템에서 수행 중인 모든 세그먼트들로의, 그리고 각각의 프로그램들의 실행환경들로의 접근은 하드웨어로부터 통제, 관리된다.
세그먼트의 한계, 경계를 넘어선 외부 어드레스로의 참조에 대한 것 뿐만 아니라, 특정 세그먼트들에 대해 허용되지 않은 수행에 대한 접근 확인(access check)은 보호를 위해 사용
될 수 있다. 예를 들어, 코드 세그먼트가 read-only 세그먼트로 지정이 되었기 때문에, 하드웨어는 code segment에 대해 쓰는 것을 막는다. 세그먼트를 위해 생성된 접근 권한에 대한
정보는 protection ring이나 level을 set up 하는데 사용될 수 있다. ( 내가 정리했던 내용 참조: http://cotkdrl1.blog.me/10152722953 ) protection level은 application program들
이 권한을 부여받지 않은 접근을 하는 것으로부터 운영체제의 procedure를 보호하기 위해 사용된다.
'무근본 IT 지식 공유 > 무근본 운영체제(OS)' 카테고리의 다른 글
[무근본 OS 만들기] CPU 세그먼트 레지스터에 대해 (0) | 2023.03.26 |
---|---|
[무근본 OS 만들기] 보호모드. GDT, 세그먼트 디스크립터 (0) | 2023.03.26 |
[무근본 OS 만들기] 현재까지의 과정(부트로더-> 커널 엔트리 포인트-> C언어. Kernel32) (0) | 2023.03.26 |
[무근본 운영체제(OS) 공부] 실행파일이 메모리에 올라갔을 때의 그림 (0) | 2023.03.26 |
[무근본 OS 만들기] 현재까지의 과정 ② (부트로더-> 커널 엔트리 포인트-> C언어. Kernel32) (0) | 2023.03.26 |
댓글