(새 문서: 분류: 가상화 == 개요 == 가상화 환경에서 메모리 주소 쳬게에서는 게스트 운영체제가 생각하는 물리 주소를 실제 머신 주소로 변환하여야 한다. 이는 하이퍼바이저의 섀도 페이지 테이블을 이용하게 된다. 운영체제의 페이지 테이블이 가상 주소에서 물리 주소로 가는 변환을 저장한다면, 섀도 페이징은 가상 주소에서 머신 주소로 가는 정보를 저장한다. 하이...) |
잔글편집 요약 없음 |
||
| 8번째 줄: | 8번째 줄: | ||
즉 가상 머신의 MMU는 섀도우 페이지 테이블을 통하여 10을 50으로 바꾼다고 생각하지만 결국에는 30으로 바꾸게 되는 것이다. 그렇다면 어떻게 섀도우 테이블을 탐지 할까? 이는 가상의 운영체제가 페이지 테이블을 교체하는 명령을 인터셉트하여 이 명령을 하이퍼바이저의 섀도 페이지 테이블로 바꾸는 명령으로 치환하여 작동하게 된다. | 즉 가상 머신의 MMU는 섀도우 페이지 테이블을 통하여 10을 50으로 바꾼다고 생각하지만 결국에는 30으로 바꾸게 되는 것이다. 그렇다면 어떻게 섀도우 테이블을 탐지 할까? 이는 가상의 운영체제가 페이지 테이블을 교체하는 명령을 인터셉트하여 이 명령을 하이퍼바이저의 섀도 페이지 테이블로 바꾸는 명령으로 치환하여 작동하게 된다. | ||
Shadow paging은 다음과 같은 과정을 통해서 작동한다. | |||
#GuestOS에 숨겨져서, GuestOS의 요청을 실제 요청으로 변경해주는 Shadown page directory를 GuestOS의 lcr3요청을 인터셉트 한다. | |||
#Guest page table을 돌면서 Shadow page table을 만든다. 이 Shadow page table은 Guest virtual address를 host physical address로 만든다. | |||
#위의 Shadow page table을 GuestOS의 CR3로 지정한다. | |||
이 경우 Shadow page table은 Guest kernel과 Guest application간에 두개를 사용함으로서, 각각의 Address space를 분리한다. (마치 [[KPTI]]처럼 작동한다.) XEN에서는 이러한 Dupulicated page table문제를 x86의 Ring을 통해서, 유저를 Ring3에 커널을 Ring1에 둠으로서 이를 해결하였다. <ref>[[Xen and the Art of Virtualization]]</ref> | |||
2023년 3월 20일 (월) 10:29 기준 최신판
개요
가상화 환경에서 메모리 주소 쳬게에서는 게스트 운영체제가 생각하는 물리 주소를 실제 머신 주소로 변환하여야 한다. 이는 하이퍼바이저의 섀도 페이지 테이블을 이용하게 된다. 운영체제의 페이지 테이블이 가상 주소에서 물리 주소로 가는 변환을 저장한다면,
섀도 페이징은 가상 주소에서 머신 주소로 가는 정보를 저장한다. 하이퍼바이저는 머신 주소 정보를 통하여 섀도 페이지 테이블을 구축하고 페이지 테이블 베이스 레지스터에 섀도 페이지 테이블의 시작 주소를 등록한다. 예를 들어서 가상머신이 가상 주소 10을 물리 주소 50으로 변환하고자 한다고 생각해 보자. 이러한 작업에서 물리 주소 50은 섀도우 페이지 테이블에 호스트 운영체제의 물리 주소 30에 매핑되어 있다.
즉 가상 머신의 MMU는 섀도우 페이지 테이블을 통하여 10을 50으로 바꾼다고 생각하지만 결국에는 30으로 바꾸게 되는 것이다. 그렇다면 어떻게 섀도우 테이블을 탐지 할까? 이는 가상의 운영체제가 페이지 테이블을 교체하는 명령을 인터셉트하여 이 명령을 하이퍼바이저의 섀도 페이지 테이블로 바꾸는 명령으로 치환하여 작동하게 된다.
Shadow paging은 다음과 같은 과정을 통해서 작동한다.
- GuestOS에 숨겨져서, GuestOS의 요청을 실제 요청으로 변경해주는 Shadown page directory를 GuestOS의 lcr3요청을 인터셉트 한다.
- Guest page table을 돌면서 Shadow page table을 만든다. 이 Shadow page table은 Guest virtual address를 host physical address로 만든다.
- 위의 Shadow page table을 GuestOS의 CR3로 지정한다.
이 경우 Shadow page table은 Guest kernel과 Guest application간에 두개를 사용함으로서, 각각의 Address space를 분리한다. (마치 KPTI처럼 작동한다.) XEN에서는 이러한 Dupulicated page table문제를 x86의 Ring을 통해서, 유저를 Ring3에 커널을 Ring1에 둠으로서 이를 해결하였다. [1]