CPU 링은 가장 명확한 구분입니다.
x86 보호 모드에서 CPU는 항상 4 개의 링 중 하나에 있습니다. Linux 커널은 0과 3 만 사용합니다.
이것은 커널 대 사용자 영역의 가장 어렵고 빠른 정의입니다.
Linux가 링 1과 2를 사용하지 않는 이유 : CPU 권한 링 : 링 1과 2가 사용되지 않는 이유는 무엇입니까?
현재 링은 어떻게 결정됩니까?
현재 벨소리는 다음 조합으로 선택됩니다.
전역 설명자 테이블 : GDT 항목의 메모리 내 테이블이며 각 항목에는 Privl링을 인코딩 하는 필드 가 있습니다.
LGDT 명령어는 주소를 현재 설명자 테이블로 설정합니다.
참조 : http://wiki.osdev.org/Global_Descriptor_Table
세그먼트는 GDT에서 항목의 인덱스를 가리키는 CS, DS 등을 등록합니다.
예를 들어, CS = 0GDT의 첫 번째 항목이 현재 실행중인 코드에 대해 활성화되어 있음을 의미합니다.
각 반지는 무엇을 할 수 있습니까?
CPU 칩은 다음과 같이 물리적으로 구축됩니다.
프로그램과 운영 체제가 링간에 어떻게 전환됩니까?
CPU가 켜지면 링 0에서 초기 프로그램을 실행하기 시작합니다 (좋지만 근사치입니다). 이 초기 프로그램을 커널이라고 생각할 수 있습니다 (하지만 일반적으로 링 0에있는 커널을 호출하는 부트 로더입니다 ).
유저 랜드 프로세스가 커널이 파일에 쓰기처럼 그것을 위해 무언가를하고자 할 때, 그것은 같은 인터럽트를 생성하는 명령어 사용 int 0x80또는syscall 커널 신호를합니다. x86-64 Linux syscall hello world 예 :
.data
hello_world:
.ascii "hello world\n"
hello_world_len = . - hello_world
.text
.global _start
_start:
/* write */
mov $1, %rax
mov $1, %rdi
mov $hello_world, %rsi
mov $hello_world_len, %rdx
syscall
/* exit */
mov $60, %rax
mov $0, %rdi
syscall
컴파일 및 실행 :
as -o hello_world.o hello_world.S
ld -o hello_world.out hello_world.o
./hello_world.out
GitHub 업스트림 .
이 경우 CPU는 커널이 부팅 할 때 등록한 인터럽트 콜백 핸들러를 호출합니다. 다음은 핸들러를 등록하고 사용 하는 구체적인 베어 메탈 예제입니다 .
이 핸들러는 링 0에서 실행되며, 커널이이 작업을 허용할지 여부를 결정하고, 작업을 수행하고, 링 3에서 userland 프로그램을 다시 시작합니다. x86_64
때 exec시스템 호출을 사용하는 (또는 경우 커널 시작한다/init ), 커널은 레지스터와 메모리를 준비하고 , 새로운 유저 기반 프로세스를 다음의 엔트리 포인트로 점프 링 (3)에 CPU 스위치
프로그램이 금지 된 레지스터 나 메모리 주소 (페이징으로 인해)에 쓰기와 같은 장난스러운 작업을 시도하면 CPU는 링 0에서 일부 커널 콜백 핸들러도 호출합니다.
그러나 사용자 영역이 장난 스러웠 기 때문에 커널이 이번에는 프로세스를 종료하거나 신호와 함께 경고를 줄 수 있습니다.
커널이 부팅되면 일정한 주파수로 하드웨어 클럭을 설정하여 주기적으로 인터럽트를 생성합니다.
이 하드웨어 시계는 링 0을 실행하는 인터럽트를 생성하고 어떤 사용자 영역 프로세스가 깨어날 지 예약 할 수 있도록합니다.
이렇게하면 프로세스가 시스템 호출을하지 않는 경우에도 스케줄링이 발생할 수 있습니다.
여러 개의 링이있는 이유는 무엇입니까?
커널과 사용자 영역을 분리하면 두 가지 주요 이점이 있습니다.
- 하나가 다른 하나를 방해하지 않을 것이라는 확신이 있기 때문에 프로그램을 만드는 것이 더 쉽습니다. 예를 들어, 하나의 사용자 영역 프로세스는 페이징으로 인해 다른 프로그램의 메모리를 덮어 쓰거나 다른 프로세스에 대해 하드웨어를 잘못된 상태로 만드는 것에 대해 걱정할 필요가 없습니다.
- 더 안전합니다. 예를 들어 파일 권한 및 메모리 분리는 해킹 앱이 은행 데이터를 읽는 것을 방지 할 수 있습니다. 물론 이것은 커널을 신뢰한다고 가정합니다.
그것을 가지고 노는 방법?
링을 직접 조작하는 좋은 방법 인 베어 메탈 설정을 만들었습니다 : https://github.com/cirosantilli/x86-bare-metal-examples
안타깝게도 유저 랜드 예제를 만들 수있는 인내심이 없었지만 페이징 설정까지했기 때문에 유저 랜드가 가능해야합니다. 풀 리퀘스트를보고 싶습니다.
또는 Linux 커널 모듈은 링 0에서 실행되므로 제어 레지스터 읽기와 같이 권한있는 작업을 시도하는 데 사용할 수 있습니다 . 프로그램에서 제어 레지스터 cr0, cr2, cr3에 액세스하는 방법은 무엇입니까? 분할 오류 얻기
다음은 호스트를 죽이지 않고 사용해 볼 수 있는 편리한 QEMU + Buildroot 설정 입니다.
커널 모듈의 단점은 다른 kthread가 실행 중이고 실험을 방해 할 수 있다는 것입니다. 그러나 이론적으로는 커널 모듈로 모든 인터럽트 핸들러를 인수하고 시스템을 소유 할 수 있습니다. 실제로 흥미로운 프로젝트가 될 것입니다.
네거티브 링
네거티브 링은 인텔 매뉴얼에서 실제로 참조되지 않지만 실제로 링 0 자체보다 더 많은 기능을 가진 CPU 모드가 있으므로 "네거티브 링"이름에 적합합니다.
한 가지 예는 가상화에 사용되는 하이퍼 바이저 모드입니다.
자세한 내용은 다음을 참조하십시오.
팔
ARM에서는 링을 예외 수준이라고 부르지 만 주요 아이디어는 동일하게 유지됩니다.
ARMv8에는 일반적으로 다음과 같이 사용되는 4 가지 예외 수준이 있습니다.
EL0 : userland
EL1 : 커널 (ARM 용어로 "감독자").
이전에 통합 어셈블리svc 로 알려진 명령 (SuperVisor Call) 과 함께 입력됩니다.이 명령 은 Linux 시스템 호출을 만드는 데 사용됩니다. Hello world ARMv8 예제 :swi
안녕하세요 .S
.text
.global _start
_start:
/* write */
mov x0, 1
ldr x1, =msg
ldr x2, =len
mov x8, 64
svc 0
/* exit */
mov x0, 0
mov x8, 93
svc 0
msg:
.ascii "hello syscall v8\n"
len = . - msg
GitHub 업스트림 .
Ubuntu 16.04에서 QEMU로 테스트하십시오.
sudo apt-get install qemu-user gcc-arm-linux-gnueabihf
arm-linux-gnueabihf-as -o hello.o hello.S
arm-linux-gnueabihf-ld -o hello hello.o
qemu-arm hello
다음은 SVC 핸들러 를 등록하고 SVC 호출을 수행하는 구체적인 베어 메탈 예제입니다 .
EL2 : 하이퍼 바이저 ( 예 : Xen) .
hvc지침 (HyperVisor Call) 과 함께 입력되었습니다 .
하이퍼 바이저는 OS에 대한 것이고 OS는 사용자 영역에 대한 것입니다.
예를 들어 Xen을 사용하면 동일한 시스템에서 Linux 또는 Windows와 같은 여러 OS를 동시에 실행할 수 있으며 Linux가 사용자 영역 프로그램에서 수행하는 것처럼 보안 및 디버그 용이성을 위해 OS를 서로 격리 할 수 있습니다.
하이퍼 바이저는 오늘날 클라우드 인프라의 핵심 부분입니다. 여러 서버를 단일 하드웨어에서 실행할 수 있으므로 하드웨어 사용량을 항상 100 %에 가깝게 유지하고 많은 비용을 절약 할 수 있습니다.
예를 들어 AWS는 2017 년까지 KVM으로 이동하면서 Xen을 사용 했습니다 .
EL3 : 또 다른 수준. TODO 예.
smc지침 과 함께 입력 됨 (보안 모드 호출)
ARMv8 아키텍처 참조 모델 DDI 0487C.a는 - 장 D1 일 - AArch64 시스템 레벨 프로그래머 모델 - 그림 D1-1 아름답게이 보여
ARM의 상황은 ARMv8.1 VHE (Virtualization Host Extensions) 의 출현으로 약간 변경되었습니다 . 이 확장을 사용하면 커널이 EL2에서 효율적으로 실행될 수 있습니다.
VHE는 KVM과 같은 Linux 내 커널 가상화 솔루션이 Xen을 능가했기 때문에 생성되었습니다 (예 : 위에서 언급 한 AWS의 KVM으로의 이동 참조). 대부분의 클라이언트에는 Linux VM 만 필요하고 상상할 수 있듯이 모두 단일 프로젝트에서 KVM은 Xen보다 간단하고 잠재적으로 더 효율적입니다. 따라서 이제 호스트 Linux 커널이 이러한 경우 하이퍼 바이저 역할을합니다.
뒤늦게 알 수있는 이점으로 인해 ARM이 x86보다 권한 수준에 대해 더 나은 명명 규칙을 가지고 있다는 점에 유의하십시오. 0은 더 낮고 3은 가장 높은 수준이 필요하지 않습니다. 높은 수준은 낮은 수준보다 더 자주 생성되는 경향이 있습니다.
현재 EL은 MRS명령 으로 쿼리 할 수 있습니다 . 현재 실행 모드 / 예외 수준 등은 무엇입니까?
ARM은 칩 영역을 절약하는 기능이 필요하지 않은 구현을 허용하기 위해 모든 예외 수준을 요구하지 않습니다. ARMv8 "예외 수준"은 다음과 같이 말합니다.
구현에는 모든 예외 수준이 포함되지 않을 수 있습니다. 모든 구현에는 EL0 및 EL1이 포함되어야합니다. EL2 및 EL3은 선택 사항입니다.
예를 들어 QEMU의 기본값은 EL1이지만 EL2 및 EL3은 명령 줄 옵션으로 활성화 할 수 있습니다. qemu-system-aarch64 a53 전원 켜기를 에뮬레이션 할 때 el1 입력
Ubuntu 18.10에서 테스트 된 코드 조각.