어셈블리 프로그램이 운영 체제를 중단시키는 원인은 무엇입니까? [닫은]

우선, 나는 초보자 이므로이 질문이 어리석은 경우 잘못된 가정을 지적하십시오.

내가 이해 한 바에 따르면 운영 체제의 작업은 OS에서 실행되는 하드웨어 및 소프트웨어를 관리하는 것입니다. 또한 내가 이해 한 바에 따르면 어셈블리 프로그램을 통해 하드웨어를 거의 직접 제어 할 수 있습니다. 어셈블리 프로그램에서 데이터를 레지스터로 읽고 쓸 수 있고 RAM에서 데이터를 읽고 쓸 수 있습니다.

레지스터와 RAM을 망칠 수있는 자유가 주어지면 어셈블리 프로그램이 운영 체제에 영향을 줄 수 없습니까? OS가 레지스터 A를 사용하여 중요한 정보를 저장한다고 가정하고 해당 OS에서 조립 된 프로그램을 실행한다고 가정합니다. 프로그램이 정크를 레지스터 A에 성공적으로 쓰면 OS에 영향을 미칩니다.

질문 :

1. 위에서 설명한 방식으로 레지스터 A를 망칠 수 있습니까?

2. 그렇지 않은 경우 어셈블리 프로그램이 OS에서 사용하는 레지스터를 수정하지 못하게하는 원인은 무엇입니까?

결국, 모든 언어는 소스 언어가 어셈블러인지 또는 고급 언어인지에 관계없이 머신 코드입니다.

중요한 것은 다른 프로그램이나 운영 체제 자체에 영향을 줄 수있는 "메시지와의 레지스터"를 포함하여 주어진 프로세스가 수행 할 수있는 작업을 제한하는 하드웨어 메커니즘이 있다는 것입니다.

이는 "사용자"와 "감독자"작동 모드 사이의 간단한 구분으로 시작되었으며, 이후 여러 "링"권한을 가진 보안 아키텍처로 발전했습니다.

좀 더 구체적으로 만드는 매우 일반적인 예는 다음과 같습니다.

• "사용자 모드"에서 프로세스는 프로세스 ID에 할당되지 않은 메모리에 액세스 할 수 없습니다. 다른 프로세스 및 운영 체제 자체에 할당 된 메모리는 차단됩니다. 여기에는 다른 프로세스에서 사용되는 레지스터 값이 포함됩니다. 이것은 MMU 하드웨어에 의해 시행됩니다.

• 따라서 "사용자 모드"에서는 프로세스가 MMU 제어 레지스터에 액세스 할 수 없습니다.

• 분명히 "사용자 모드"에서 운영 체제 기능을 호출하는 매우 잘 정의 된 메커니즘을 제외하고 프로세스는 모드를 "감독자 모드"로 변경할 수 없습니다.

프로세스가 이러한 규칙을 위반하려고하면 운영 체제가 제어권을 갖습니다. 그런 일이 발생하면 OS는 문제를 일으키는 프로세스를 중단하고 더 이상 명령을 실행하지 않습니다.

많은 멀티 태스킹 운영 체제는 프로세스 제어 블록 (PCB) 이라는 데이터 구조를 사용 하여 레지스터 덮어 쓰기 문제를 처리합니다. 코드를 실행할 때 OS는 새로운 프로세스를 생성하여이를 추적합니다. PCB에는 레지스터 내용을 보유하기 위해 할당 된 프로세스 및 공간에 대한 정보가 들어 있습니다. 프로세스 A가 현재 프로세서에서 실행 중이고 코드가 프로세스 B에 있다고 가정 해 보겠습니다. 코드를 실행할 때 발생하는 상황은 다음과 같습니다.

1. 프로세스 A의 상태 데이터 (등록 내용, 프로그램 카운터 등)가 PCB로 복사됩니다.

2. 프로세스 B의 상태 데이터는 PCB에서 CPU 레지스터로 복사됩니다.

3. 프로세스 B는 완료되거나 선점 될 때까지 프로세서에서 실행됩니다.

4. 프로세스 B의 상태 데이터가 PCB로 다시 복사됩니다.

5. 프로세스 A의 상태 데이터가 다시 CPU로 복사되고 계속 실행됩니다.

운영 체제가 프로세스 A로 실행중인 경우 프로그램이 실행되기 전에 레지스터를 저장 한 다음 프로그램이 종료되면 다시 레지스터를 CPU에 복사하여 사용자 프로그램이 다른 프로세스에서 발생하는 작업을 방해하지 않도록 방지 할 수 있습니다.

메모리에서 OS 데이터를 덮어 쓰는 사용자 프로세스를 피하기 위해 대부분의 플랫폼은 메모리 세그먼트 화를 사용합니다. 기본적으로 가상 메모리를 사용하면 프로세스가 보는 주소 공간을 임의의 물리적 주소 범위에 매핑 할 수 있습니다. 프로세스의 실제 메모리 공간이 겹치지 않는 한 프로세스가 다른 프로세스의 데이터를 덮어 쓰는 것은 불가능합니다.

물론 OS마다 다른 방식으로 작동하므로 모든 경우에 해당되는 것은 아닙니다. 또한 대부분의 플랫폼에서 OS 프로세스는 사용자 프로세스와 다른 모드로 실행되며 약간의 복잡성이 있습니다.

사용중인 플랫폼에 따라 다릅니다.

• 보다 기본적인 프로세서에서 프로세서는 프로그램이 지시하는 모든 명령을 실행합니다.

• 보다 정교한 프로세서에는 적어도 두 가지 모드가 있습니다. 하나의 모드에서 프로세서는 프로그램이 지시 한대로 수행합니다. 다른 모드에서 프로세서 자체 는 특정 명령의 실행을 거부 합니다.

프로그램이 전체 시스템을 중단시키는 원인은 무엇입니까? 첫 번째 유형의 프로세서에서 답은 "아무것도 없습니다"입니다. 기본 프로세서를 사용하면 단일 불량 프로그램이 실제로 전체 시스템에 충돌을 일으킬 수 있습니다. 초기 8 비트 가정용 컴퓨터와 많은 16 비트 컴퓨터가이 범주에 속합니다.

최신 PC에서 프로세서에는 "보호"하드웨어가 있습니다. 기본적으로 OS는 모든 작업을 수행 할 수있는 특수 모드로 실행되는 반면 일반 프로그램은 프로세서가 특정 작업 만 허용하는 모드에서 실행됩니다 (OS가 프로세서에서 구성한 설정에 따라). 특정 레지스터에만 액세스하거나 특정 메모리 범위에만 액세스하는 것과 같습니다.

분명히, 단일 불량 프로그램이 전체 시스템을 중단시키는 것은 나쁜 일입니다. (불량한 프로그램이 원하는 데이터에 액세스 할 수있게하려면 보안에 심각한 영향을 미칩니다.)이를 피하려면 다음 두 가지가 필요합니다.

1. 실제로 보호 하드웨어가있는 프로세서 (예 : 특정 명령의 실행을 거부하도록 구성 할 수 있음)

2. 실제로 이러한 기능을 사용하여 자신을 보호하는 OS입니다. (OS가 절대로 그것을 사용하지 않으면 보호 회로가있는 칩을 갖는 것은 좋지 않습니다!)

최신 데스크톱 OS (Windows, Linux, Mac OS, BSD ...)의 이름은 보호 하드웨어가있는 프로세서에서 실행되는 보호 모드 OS입니다. 일부 8 비트 마이크로 컨트롤러에서 임베디드 개발을 수행하는 경우 보호 하드웨어가 없을 수 있습니다. (또는 그 문제에 대한 OS) ...

Q. 어셈블리 프로그램이 운영 체제를 중단시키는 원인은 무엇입니까?

A. 아무것도 아닙니다.

그러나, 매우 영리한 많은 프로그래머들이 수년 동안 점점 더 어렵게 만들려고 노력했습니다. 불행히도, 모든 영리한 프로그래머에게는 그들 사이에 더 창의적이고 야심적이며 때로는 영리한 사람들보다 운이 좋은 많은 사람들이 많이 있습니다. 영리한 프로그래머는 매번 누구도 무언가를해서는 안되며, 할 수 없거나 할 수 없다고 말합니다. Microsoft Windows (예를 들어)는 거의 35 년 동안 사용되어 왔으며 운영 체제를 중단시킨 지침 인 BSoD (Blue Screens of Death)가 여전히 있습니다.

작은 용어부터 시작하겠습니다. 컴퓨터에서 실행되는 모든 것은 기계 코드에서 수행됩니다. 키 입력을 읽거나 마우스 포인터의 움직임을 나타내는 비트, 디스플레이에서 픽셀의 색상을 변경하거나 파일에서 바이트를 읽는 비트 및 글 머리 기호가 나쁜 사람을 때렸는지 또는 결정하는 비트를 계산하는 비트 신용 카드 신청이 승인되면 모두 일련의 기계 코드 명령으로 실행됩니다. 일부 작업은 너무 일반적이며 너무 자주 수행되므로 작업을 수행하는 데 필요한 지침을 모아 모든 사람이 해당 어셈블리를 사용하도록하는 것이 합리적입니다. 다른 사람이 컴퓨터를 사용하도록 허용하거나 도와주는 이러한 작업은 운영 체제라고하는 경향이 있지만 다른 프로그램과는 본질적으로 다른 점이 없습니다. 그것들은 모두 일련의 기계 코드 명령입니다.

운영 체제를보다 복잡하게 만들고 충돌하는 경향이있는 것은 일반적으로 생각할 필요가없는 것들을 설명해야한다는 것입니다. 가장 간단한 작업을 예로 들어 보겠습니다. 파일 끝에 메시지를 쓰고 싶습니다. 고급 언어에서는 다음과 같이 작성합니다.

  with open("myFile.txt", "w+") as f:
      # do some really clever things
      f.write("Goodbye cruel world!")

물리적 상태에 액세스하고 변경하는 방법 또는 비트 및 바이트로 해석되는 방법 또는 해당 바이트가 메모리 및 CPU와주고받는 방법에 대한 모든 세부 정보를 무시하고 OS가 제공하는 프로그램이 처리하는 모든 것을 신뢰합니다 무대 뒤에서. 파일 끝에 추가하는 방법에 대해서만 생각해 봅시다. 1) 파일의 끝이 어디인지 알아 내십시오. 2) 그 위치에 무언가를 쓰십시오. 무엇이 잘못 될 수 있습니까? 실제로, 꽤 많이. 영리한 일을하는 동안 컴퓨터에서 다른 일이 발생하는지 생각해보십시오. 다른 사람 (운영 체제 자체 포함)이 수행중인 파일이 어떤 식 으로든 작업중인 파일을 변경하면이 간단한 작업이 갑자기 훨씬 더 복잡해집니다. 파일이 더 길고 파일이 더 짧습니다. 파일이 더 이상 존재하지 않습니다. 디스크가 가득 찼습니다.