커널모드가 왜 안전한지를 모르겠습니다

접근 가능한 메모리 영역도 물론 차이가 있습니다. 커널 모드에선 일단 모든 메모리에 액세스가 가능하니까요.
물론, 그렇다고 일반적인 상황에서 커널이 물리 메모리 주소에 바로 액세스한다는 얘기는 아닙니다.
보통 운영체제는 대부분 페이징을 하고, 리눅스라면 pgd pte 등의 항목이 있는데 한 마디로 현재 태스크의
페이지 테이블은 모두 따로 존재하고 유저모드에서 시스템 콜 호출로 커널 모드로 스위칭이 되었다고 해도
현재 태스크에 대한 정보는 그대로 가지고 있습니다. 즉 어느 프로세스에서 시스템 콜을 호출했냐에 따라서 다르다는 얘기입니다.

이 말은 리눅스에서 커널 모드라고 해도 결국 페이지 테이블을 통한 가상 주소 -> 물리 주소 변환 후 액세스를 한다는 얘기입니다.
이는 경우에 따라 오해가 있을 수 있는 얘기이지만 보통의 상황에선 그렇습니다. 또한 커널 모드에서는 모든 메모리에 접근이 가능하단 얘기와
유저 모드에서는 커널 메모리에 접근을 못하도록 보호한다는 얘기는 여러 가지 의미가 있을 수 있는데, 당연한 얘기지만 일단 유저 모드에서
만약 c0000000 부터가 커널 영역 가상 주소라고 치면 *(char *)0xc0000000 = 'a'; 와 같은 명령을 실행했다간 바로 Segmentation fault 입니다.
왜냐면 일단 현재 유저 모드 태스크의 페이지 테이블에 c0000000 에 대한 정보는 없기 때문입니다.

이 때, 커널 모드로 스위칭해서 커널 코드 중 0xc0000000 에 액세스한다고 해서 paging error 가 나진 않습니다. 커널 모드에서는
이에 대한 페이지 정보를 글로벌하게 갖고 있기 때문입니다. 물론 커널 모드에서 현재 태스크(프로세스)의 가상 주소에 접근해서 값을 바꿀 수도 있습니다.
보통 리눅스 커널 코드를 보시면 copy_from_user 나 copy_to_user 등이 있는데 이게 어떻게 되어 있는지 잘 보시면 됩니다.

그리고, 이런 생각을 할 수 있습니다. "그럼 시스템 콜 중 만약 write/read 같은 시스템 콜의 두 번째 인자(주소)에 0xc0000000 이상의 주소를 넘겨서
커널이 직접 그곳에 쓰게 하면 유저 모드에서도 그 주소에 값을 간접적으로 읽고 쓸 수 있는 것 아니냐" 라고 할 수 있습니다.
당연히 이론적으로는 그렇게 할 떄 특별히 문제되는 것은 없습니다.

그래서 리눅스에서는 최신 리눅스 커널로 치면 thread_info 인가 task_struct 구조체의 addr_limit 같은 항목을 두고,
모든 시스템 콜 핸들러에서 유저 모드에서 받는 주소에 대해선 전부 addr_limit 주소보다 큰지 작은지에 대해서 체크를 합니다.
그리고 만약 크다면 바로 에러를 내뱉고 리턴하는 것이 직접 커널 모드로 짜여 있습니다.

이는 일종의 소프트웨어 레벨에서의 보호라고 할 수 있습니다. 앞에서 얘기한 것과는 조금 성격이 다르다고 할 수 있겠지요.

커널 모드에 대해 어떤 생각을 하시는지 모르겠지만, 기본적으로 리눅스로 치면 모듈과 같은 것을 직접 작성해서 올리는 경우가 아니라면
커널이 수행하는 코드는 당연히 처음부터 정해져 있습니다.(설치하신 리눅스 커널 코드 그대로 행동하겠지요) 유저가 커널 모드에서 임의로 어떤
코드를 실행하고 말고의 문제가 아니고 그런 게 가능하지도 않습니다.

Privilege 시스템은 별 게 아니라(그냥 대충 제가 쓴 용어입니다), 리눅스로 치면 권한 시스템들입니다. root 와 같은 특별한 관리자 계정이 따로 있는 이유가
일반적인 유저가 할 수 있는 일과 관리자가 할 수 있는 일을 나누기 위해서이고, 이것이 예로 들어서 위에서 언급한 모듈과 같은 것을 올리는 게 있을 수 있습니다.
아무 유저나 커널 모듈을 동적으로 막 올릴 수 있다면 어떻게 될지는 아실 테니 굳이 언급하지 않겠습니다.
이런 부분 역시 일종의 소프트웨어(커널) 레벨에서의 보호 기법 중 하나라고 할 수 있는 것입니다.

그리고 말씀하신 것 처럼 시스템 콜을 실행할 때 잘못된 인자를 건네줘서 문제가 생길 수 있는 상황에 대비한 보호 기능은 말 하자면
커널 익스플로잇 등을 방어하기 위한 기법을 말씀하시는 것인데, 아쉽게도 특별히 그러한 것이 그렇게 많지 않습니다.
일단 커널 취약점은 아무래도 유저 레벨에서의 취약점에 비해 방어하기가 어렵습니다. 커널 모드 자체가 더 로우 레벨이 없기 때문에
이를 보호해 줄 상단 영역 코드 같은 것을 만들 수 없습니다. 따라서 대부분 특별히 보호 기법이 있지는 않고, 많은 방어 기능들은 모두
유저 레벨에서의 취약점 방어에 치중해 있습니다.(최근으로 치면 seccomp 같은 샌드박스 용도의 시스템 콜 등이 있겠습니다.)

그러나 간단히 그나마 역사적으로 커널 취약점에 대해 뭔가 방어하기 위한 수정을 한 적이 있기는 있는데,(물론 여기서 말하는건 다 리눅스 얘기입니다.)
과거 Null pointer dereference 라는 취약점 형태가 한창 유행했을 때가 있습니다. 이 형태의 공격법이 공개된 이후 이러한 형태를 갖고 있던
취약점들이 전부 익스플로잇에 성공하게 되었습니다. 간단히 말해서 커널 상에서 어떠한 이유로(물론 보통 근본 원인은 시스템 콜 인자 조작) 널 포인터를
액세스하거나, 또는 아예 그냥 노골적으로 널 포인터를 함수로 호출하는 형태가 만들어졌다고 할 때, 이전에 유저 모드 프로세스에서 미리 mmap 등을
통해 0번 주소에 메모리를 할당해놓고 아예 바로 코드를 넣던지, 아니면 단순 널 포인터 액세스라면 어떤 값을 넣어서 이후 트리거가 가능하도록 하는 방식입니다.

추후 이런 형태의 취약점을 방어하기 위해 현재는 유저 모드에서 mmap 을 통해 0번 주소에 메모리를 할당하는 것은 금지되었습니다.(0x0 부터 1페이지 단위까지)
이 형태의 취약점은 리눅스 뿐 아니라 다른 운영체제에도 흔히 발견되었으며 Mac OS X 에서도 아주 자주 볼 수 있습니다.

이러한 것이 어떻게 보면 커널 익스플로잇을 막기 위한 일종의 보호 기법 적용의 한 예라고 볼 수 있습니다. 물론 단순히 회피하기 위해 커널을 조금 수정한 것 뿐이지
어떤 "보호 기능" 을 넣었다고 하기엔 좀 무리가 있긴 합니다만 일단 이런 것이 굳이 말하자면 커널 익스플로잇 보호의 예 입니다.
사실 대부분의 커널 모드 익스플로잇은 커널의 시스템 콜 쪽 보다는 드라이버 쪽이 훨씬 더 많습니다만.