따라서 Linux 또는 Windows 기반 x86 시스템은 커널 모드의 경우 링 0, 사용자 모드의 경우 링 3 만 사용합니다. 어쨌든 프로세서가 모두 두 개만 사용한다면 네 개의 다른 링을 구별하는 이유는 무엇입니까? 그리고 이것이 AMD64 아키텍처에서 변경 되었습니까?
따라서 Linux 또는 Windows 기반 x86 시스템은 커널 모드의 경우 링 0, 사용자 모드의 경우 링 3 만 사용합니다. 어쨌든 프로세서가 모두 두 개만 사용한다면 네 개의 다른 링을 구별하는 이유는 무엇입니까? 그리고 이것이 AMD64 아키텍처에서 변경 되었습니까?
답변:
두 가지 주요 이유가 있습니다.
첫 번째 이유 는 x86 CPU가 4 개의 메모리 보호 링을 제공하지만, 제공되는 보호 수준은 세그먼트 별 수준에 있기 때문입니다. 즉, 각 세그먼트는 쓰기 금지와 같은 다른 보호 기능과 함께 0에서 3까지의 특정 링 ( "권한 수준")으로 설정할 수 있습니다. 그러나 사용 가능한 세그먼트 디스크립터가 많지 않습니다. 대부분의 운영 체제는 훨씬 더 세분화 된 메모리 보호 기능을 원합니다. 개별 페이지의 경우 ...
따라서 페이지 테이블 항목 (PTE)을 기반으로 보호를 입력하십시오. 대부분의 최신 x86 운영 체제는 대부분 분할 메커니즘을 무시하고 PTE 기반 보호에 의존합니다. 이것은 각 PTE의 하위 12 비트 인 플래그 비트와 실행되지 않는 CPU를 지원하는 CPU의 비트 63으로 지정됩니다. 각 페이지마다 하나의 PTE가 있으며 일반적으로 4K입니다.
이러한 플래그 비트 중 하나를 "권한있는"비트라고합니다. 이 비트는 페이지에 액세스하기 위해 프로세서가 "권한있는"레벨 중 하나에 있어야하는지 여부를 제어합니다. "권한있는"레벨은 PL 0, 1 및 2입니다. 그러나 1 비트에 불과하므로 페이지 별 보호 레벨에서 메모리 보호와 관련하여 사용 가능한 "모드"의 수는 두 개입니다. 비 권한 모드에서 액세스 할 수 있는지 여부 따라서 두 개의 고리 만 있습니다.
각 페이지에 대해 네 개의 가능한 링을 가지려면 각 페이지 테이블 항목에 두 개의 보호 비트가 있어야 세그먼트 세그먼트 설명자처럼 네 개의 가능한 링 번호 중 하나를 인코딩 할 수 있습니다. 그들은하지 않습니다.
두 번째 이유 는 OS 이식성의 목표입니다. x86 정도가 아닙니다. 유닉스는 OS가 여러 프로세서 아키텍처에 비해 상대적으로 이식성이 좋으며 좋은 점이라고 가르쳤다. 그리고 일부 프로세서는 두 개의 링만 지원합니다. 아키텍처의 여러 링에 의존하지 않기 때문에 OS 구현자는 OS를보다 이식 가능하게 만들었습니다.
Windows NT 개발과 관련된 세 번째 이유 가 있습니다. NT의 디자이너 (David Cutler와 그의 팀, Microsoft가 DEC Western Region Labs에서 고용 한 팀)는 VMS에 대한 광범위한 경험을 가지고있었습니다. 실제로 Cutler와 다른 일부는 VMS의 원래 디자이너 중 하나였습니다. 또한 VMS가 설계된 VAX 프로세서에는 4 개의 링이 있습니다. VMS는 4 개의 링을 사용합니다. (실제로 VAX에는 PTE에 4 개의 보호 비트가 있으므로 "사용자 모드에서는 읽기 전용이지만 링 2 및 내부에서는 쓸 수 있습니다."와 같은 조합을 허용합니다.
그러나 VMS의 링 1과 2 (레코드 관리 서비스 및 CLI)에서 실행 된 구성 요소는 NT 디자인에서 제외되었습니다. VMS의 링 2는 실제로 OS 보안에 관한 것이 아니라 사용자의 CLI 환경을 한 프로그램에서 다음 프로그램으로 보존하는 것이 아니라 Windows NT에는 그러한 개념이 없었습니다. CLI는 일반적인 프로세스로 실행됩니다. VMS의 링 1의 경우, 링 1의 RMS 코드는 링 0을 상당히 자주 호출해야했으며 링 전이는 비용이 많이 듭니다. 링 1 코드 내에 링 0 전환이 많지 않고 링 0으로 이동하여 수행하는 것이 훨씬 더 효율적인 것으로 판명되었습니다. (다시 말해서 NT에는 RMS와 같은 것이 없습니다.)
그런데 왜 거기에 있습니까? 왜 x86이 4 개의 링을 구현하고 OS에서 사용하지 않는지에 관해서는 x86보다 훨씬 최신 디자인의 OS에 대해 이야기하고 있습니다. x86의 많은 "시스템 프로그래밍"기능은 NT 또는 진정한 유닉스 커널이 구현되기 오래 전에 설계되었으며 OS가 무엇을 사용할지 실제로 알지 못했습니다. (80386까지는 나타나지 않았던 x86에서 페이징을 받기 전까지 는 처음부터 메모리 관리를 다시 생각하지 않고 진정한 Unix-ish 또는 VMS와 같은 커널을 구현할 수있었습니다 .)
최신 x86 OS는 세그먼트 화를 크게 무시할뿐만 아니라 기본 주소가 0이고 크기가 4GB 인 C, D 및 S 세그먼트를 설정하기 만합니다. F 및 G 세그먼트는 때때로 주요 OS 데이터 구조를 가리키는 데 사용됩니다) "태스크 상태 세그먼트"와 같은 것을 크게 무시하십시오. TSS 메커니즘은 스레드 컨텍스트 전환을 위해 명확하게 설계되었지만 부작용이 너무 많기 때문에 최신 x86 OS는 "수동으로"수행합니다. 예를 들어, x86 NT가 하드웨어 작업을 변경하는 유일한 시간은 이중 오류 예외와 같은 정말 예외적 인 조건입니다.
Re x64에는 이러한 사용하지 않는 많은 기능이 제외되었습니다. AMD는 실제로 OS 커널 팀과 대화를 나누고 x86에서 필요한 것, 필요하지 않은 것, 원하지 않는 것, 추가 한 것 등을 물었습니다. x64의 세그먼트는 vestigial 형식, 작업 상태 전환 등이 존재하지 않습니다. 그리고 OS는 계속 두 개의 링만 사용합니다.