아시겠지만, 커널 영역의 프로세스 스택은 커널이 system call을 호출하여 system mode로 진입했을 때 사용되는 스택입니다.
리눅스는 프로세스 스케줄링이 원할하게 하기 위하여, system mode에 진입한 프로세스들도 스케줄링을 받도록 설계되어 있습니다.
즉, 하나의 프로세스가 system call을 호출하여 system mode에 진입하더라도,
스케줄링에 의하여 다른 프로세스가 system call에 각각 진입할 수 있도록 있어야 하며.
이 때 context를 보장해주기 위해서 각각의 커널 영역의 스택을 필요로 합니다.
커널영역의 프로세스 스택이 하나만 존재하도록 구현하는 것도 가능합니다만..
하나의 system call이 끝나기 전까지 다른 system call들은 진입할 수 없도록 해야 하니까,
스케줄링이 원할하지 않는 문제점이 있을 거라 생각합니다.
커널은 프로세스의
커널은 프로세스의 커널 서비스를 위한 스택이고, 프로세스의 스택은 프로세스를 위한 스택입니다.
프로세스는 커널의 스택에 접근 할 수도 없고, 알 필요도 없습니다.
Database도 마찬가지로 연결마다 세션이라는 영역을 둡니다. 사용 할때마다 연결하면 시간이 많이 걸리니 이런 영역을 둬서 사용자들의 요구를 중간에 보관하고 있는 겁니다. 덕분에 빠르게 응답할 수 있겠죠.
이처럼 프로세스 스택 역시 비슷한 역할을 합니다.
유저 프로세스로 복귀할 리턴 주소, 유저 프로세스가 커널에 넘기는 매개 변수들, 커널에서 쓰는 각종 변수들이 저장됩니다.
ISOLATION과 PROTECTION은
ISOLATION과 PROTECTION은 CPU가 멀티테스크를 지원하는데 필요한 중요한 개념입니다.
이는 보안과도 관련이 있고 실행대기중인 다른 테스크의 데이터가 오염되지 않게 하는 중요한 역활을 합니다.
예를들어 시스템에 스택이 하나라면 유저 프로그램이 inline 어셈등을 이용해서 뭘 할 수 있을지 한번 생각
해보세요. C 코드로 esp 주소를 얻어 오고 주소를 계속올려가면서(스택 주소는 거꾸로 자랍니다.)
덤프를 뜨는겁니다. 그러면 거기에 커널에서 사용중인 데이터를 읽을 수 있겠죠?
잘하면 패스워드 데이터를 저장해놓은 스택주소를 찾아낼수도 있고요.
또한 재귀 프로그램을 짯는데 end ststus를 잘 못줘서 프로그램이 stack overflow 를 일으켰다고
가정해보면 시스템 전체가 사용불능이 될수도 있습니다.
그외에 다양한 케이스를 한번 생각해보세요.
이렇게 CPU의 입장에서 하나의 테스크는 다른 테스크(커널모드 일때도 마찬가지)가 사용하는
자원을 분리시켜야 할 필요가 있습니다.
cpu architecture들과 os architecture들이 이렇게 cpu와 OS를 구현한 데에는 다 이유가 있습니다.
Dig it.
Dig it.
아시겠지만, 커널
아시겠지만, 커널 영역의 프로세스 스택은 커널이 system call을 호출하여 system mode로 진입했을 때 사용되는 스택입니다.
리눅스는 프로세스 스케줄링이 원할하게 하기 위하여, system mode에 진입한 프로세스들도 스케줄링을 받도록 설계되어 있습니다.
즉, 하나의 프로세스가 system call을 호출하여 system mode에 진입하더라도,
스케줄링에 의하여 다른 프로세스가 system call에 각각 진입할 수 있도록 있어야 하며.
이 때 context를 보장해주기 위해서 각각의 커널 영역의 스택을 필요로 합니다.
커널영역의 프로세스 스택이 하나만 존재하도록 구현하는 것도 가능합니다만..
하나의 system call이 끝나기 전까지 다른 system call들은 진입할 수 없도록 해야 하니까,
스케줄링이 원할하지 않는 문제점이 있을 거라 생각합니다.
댓글 달기