Week-05

14. 막간 : 메모리 관리 API

• stack : 프로그래머를 위해, 컴파일러에 의해 자동으로 할당과 해제가 이루어진다(automatic).

void func() {
  int x;
}

• func()가 호출되면 스택에 공간을 확보하고, func()가 종료되면 스택에서 공간을 해제한다.

• heap : 프로그래머가 직접 할당과 해제를 해야한다.

void func() {
  int *x = (int *) malloc(sizeof(int));
  free(x);
}

• malloc()을 통해 메모리를 할당하고, free()를 통해 메모리를 해제한다.

• heap에 데이터를 저장하고, func()의 스택에는 heap에 저장된 데이터의 주소를 저장한다.

stack만큼 명시적이고 단순하기는 하지만, 쓰임새가 다양하고 실수를 할 여지가 많다.

14.2 malloc()함수

• malloc()은 메모리를 할당하는 함수이다.

• 약간 더 자세하게 설명하면, malloc()은 힙에 요청할 공간의 크기를 받아 성공하면 할당한 메모리의 주소를 반환하고, 실패하면 NULL을 반환한다.

• 참고로 sizeof()는 연산자의 관점에서 바라보면 조금 더 적절한 부분이 있다.

  • sizeof()는 컴파일 시간에 계산되는 연산자이다.
  • 예를들어 int *x = malloc(sizeof(int) * 10); printf(sizeof(x)). 이 코드에서는 4 또는 8값이 반환된다.
  • 즉 동적으로 할당된 메모리의 크기가 아닌, 포인터의 크기를 반환하기 때문이다.

14.3 free()함수

• free()는 malloc()을 통해 할당된 메모리를 해제하는 함수이다.

• free()를 통해 메모리를 해제 할 때 할당된 영역의 크기를 알 필요가 없다. (라이브러리가 알아서 처리한다.)

14.4 흔한 오류

| 기본적으로 malloc()과 free()를 사용할 때 자주 오류가 발생하는데, 특히 가비지컬렉터가 없는 경우에 더욱 신경써야 한다.

메모리 할당 잊어버리기

많은 루틴은 자신이 호출되기 전에 필요한 메모리가 이미 할당되었다고 가정한다. 이런 경우 메모리를 할당하지 않고 사용하려고 할 때, 프로그램은 세그멘테이션 폴트를 발생하고 종료된다.

| 사실 이러한 경우는 너무 흔해서 조금 더 안전한 루틴이나 라이브러리를 사용하는 것이 좋다.

버퍼 오버플로우 : 충분하지 않은 메모리 할당

프로그램이 할당된 메모리보다 더 많은 데이터를 쓰려고 할 때, 문제 없이 동작하는 것 처럼 보이지만, 실제로는 할당받지 않은 메모리를 사용하게 된다. 다른 변수나 중요한 데이터를 덮어쓰는 경우가 발생할 수 있고, 보안적으로 매우 위험하다.

할당받은 메모리 초기화 하지 않기

malloc()을 통해 할당받은 메모리는 초기화되지 않는다. 나중에 uninitialized read가 발생할 수 있다. 마찬가지로 공격자의 데이터를 읽을 수 있게 되는 보안적인 문제가 발생할 수 있다.

할당받은 메모리 해제하지 않기

free()를 호출하지 않으면, 메모리 누수가 발생한다. 이는 프로그램이 실행되는 동안 메모리 사용량이 계속 증가하게 되고, 결국 프로그램이 더 이상 실행되지 않게 된다.

메모리 사용이 끝나기 전에 메모리 해제하기

dangling pointer는 이미 해제된 메모리를 사용하려고 할 때 발생한다. 이는 프로그램이 종료되거나, 다른 메모리를 할당받을 때 발생할 수 있다.

두 번 해제하기

double free는 이미 해제된 메모리를 다시 해제하려고 할 때 발생한다. 이는 프로그램이 종료되거나, 다른 메모리를 할당받을 때 발생할 수 있다.

free() 잘못 호출하기

14.5 운영체제의 지원

• malloc()과 free()는 라이브러리 함수이기 때문에, 시스템콜을 직접적으로 언급하지는 않았지만, 라이브러리 자체는 당연히 시스템콜을 사용한다.

• brk, sbrk 시스템콜을 사용하고 있지만, 직접적으로 사용하지는 않는다.

15. 주소 변환의 원리

LDE에서 프로그램이 하드웨어에 의해 직접 실행되면서도, 약간의 하드웨어 지원을 받은 운영체제의 개입으로 어떻게 가상화를 제공하면서도, 프로그램을 방해하지 않는지에 대해서 알아봤다, 메모리 가상화에도 마찬가지로, 비슷한 동작을 알아본다.

• 메모리 가상화에서도 제어와 효율성을 동시에 추구한다.

• 제어 : 프로그램이 자기 자신의 메모리 이외에 다른 메모리에 접근하지 못하는것을 운영체제가 보장한다.

• 효율성 : 하드웨어의 지원으로 하여금, 다양한 자원을 사용하여 가상화를 효율적으로 수행할 수 있도록 한다.

• 여기서 다룰 기법은 hardware-based address translation, 짧게는 address translation이다.

• address translation은 프로그램이 메모리에 접근할 때, 가상 주소를 물리 주소로 변환하는 기법이다.

• 그리고 해당 기법을 다루며 달성하고자 하는 목표는 프로그램이 자신의 전용 메모리 공간을 가지고 있다고 믿게 하면서도, 실제로는 물리 메모리를 공유하도록 하는 것이다.

15.1 가정

CPU 가상화 부분에서 LDE에 대한 이야기를 했었는데, 요약하자면 대부분의 프로그램은 하드웨어에서 직접 실행되면서, 프로세스가 시스템콜을 호출하거나 타이머 인터럽트가 발생하면, 하드웨어는 커널로 제어권을 넘기고, 운영체제가 적절한 작업을 수행한다. 즉 실행 프로그램에 문제가 발생하지 않도록 적절한 시점에 개입해서 하드웨어 지원을 받아 역할을 수행한다는 것이다.

• LDE에서 위와 같은 것들을 달성하기 위해서, 중요한 포인트를 효율성과 제어라고 할 수 있었다.

• 메모리 가상화도 마찬가지로, 가상화를 제공하는 목표는 효울성과 제어를 달성하기 위함이다.

• 물론 이런것들을 달성하려면 적절한 하드웨어의 지원이 필요하다.

• 이전 장에서와 마찬가지로, 처음에는 단순 하드웨어의 지원(레지스터만 사용하는 정도)에서 TLB, 페이지 테이블등 점차 복잡한 하드웨어 지원을 공부하는 방식으로 진행한다.

• 마지막으로 메모리 가상화 관점에서 효율성과 제어의 목표를 각각 알아보면 다음과 같다.

  • 효율성 : 메모리 가상화는 물리적 메모리를 효율적으로 사용할 수 있도록 해야한다.
  • 제어 : 메모리 가상화는 프로세스가 다른 프로세스의 메모리에 접근하지 못하도록 해야한다.

결론, 핵심 질문

• 메모리 가상화를 배우는 시작 장에서 핵심 질문은 다음과 같다.

어떻게 효율적이고 유연하게 메모리를 가상화할 수 있을까?

• 먼저 다룰 기법은 하드웨어 기반 주소 변환(hardware-based address translation), 그냥 짧게 주소 변환(address translation)이라고도 한다.

• 핵심은 그냥 프로그램의 모든 메모리 참조를 실제 메모리 주소로 재지정하기 위해서 하드웨어가 주소를 변환하는 것이다.

• 하드웨어만으로는 메모리 가상화를 제공 할 수 없다. 운영체제가 실제로 메모리의 빈공간과 사용중인 공간을 알고 관리해야 하며, 메모리 사용을 제공해야한다.

• 그리고 모든 프로그램이 자신의 전용 메모리 공간을 가지고 있다는 환상을 제공해야 한다.

15.1 가정

스케줄링을 배울 때 문제를 쉽게 이해하기 위해서 가정을 통해 고려 요인을 단순화 했듯이, 여기서도 가정을 통해 많은 제한사항을 두고 시작한다.

• 먼저 사용자 주소 공간은 물리 메모리에 연속적으로 배치되어야 한다고 가정한다.
• 그리고 주소 공간의 크기가 너무 크지 않다고 가정한다.
• 마지막으로, 각 주소공간의 크기가 같다고 가정한다.

쉬워보이지만, 가정을 완화하는 과정에서 머리가 깨질 예정! 🤪

15.2 사례

void func() {
  int x = 3000;
  x = x + 3;
}

• 위 코드를 x86 어셈블리로 변환하면 다음과 같다.

movl 0x0(%ebx), %eax; // 0 + ebx를 eax에 저장
addl $3, %eax; // eax에 3을 더한다.
movl %eax, 0x0(%ebx); // eax를 ebx에 저장

이 명령어가 실행되면 프로세스 관점에서 아래와 같은 메모리 접근이 발생한다.

(출처 : OSTEP)

• 주소 128의 명령어를 반입

• 이 명령어 실행(주소 15kb에서 탑재)

• 주소 132의 명령어를 반입

• 이 명령어 실행 (메모리 참조 없음)

• 주소 135의 명령어를 반입

• 이 명령어 실행 (주소 15kb에 저장)

지금 시점의 프로그램 관점에서 주소공간은 0부터 16kb까지의 주소공간을 가지고 있다. (프로그램이 생성하는 모든 메모리 참조는 이 범위 내에 있어야 한다.)

그러나 우리는 메모리 가상화를 위해 물리 메모리 주소 0이 아닌 다른곳에 위치시키고 싶다.

이걸 실제로 프로세스 모르게 어떻게 재배치 하냐가 메모리 가상화의 핵심이다.

일단 위의 그림처럼 간단한 상황이 있을 수 있다.

15.3 동적 재배치

• 이 문제에 대한 첫 번째 해결 사례는 동적 재배치(dynamic relocation), 또는 base and bounds로 불리는 방법이.

• 이 방법은 프로세스가 시작될 때, 운영체제가 프로세스의 주소 공간을 위한 두 가지 레지스터(base, bounds)를 설정한다.

• base : 프로세스에 할당된 메모리의 시작 주소를 가리키는 레지스터

• bounds : 프로세스에 할당된 마지막 주소를 가리키는 레지스터

• 그리고 아주 간단한 가상화 공식을 얻을 수 있다! physical address = virtual address + base

• 그러면 자연스럽게 bounds는 보호를 위해 쓰이며, 이 메모리 주소에 대한 참조가 유효한지 확인한다.

결론적으로아래와 같은 간단한 로직으로 동작한다.

if (virtual address < 0 || virtual address > bounds) {
  raise an error(fault);
} else {
  physical address = virtual address + base;
}

15.4 하드웨어 지원 : 요약

위의 로직을 달성하기 위해서 필요한 하드웨어 지원은 다음과 같다.

1. 커널 모드 : 유저모드의 프로세스가 특권 연산을 수행할 수 없도록 한다.
2. base, bounds 레지스터 : 주소 변환과, 번위 검사를 위해 CPU당 두 개의 레지스터가 필요하다.
3. 가상 주소를 변환하고 범위 안에 있는지 확인하는 능력 : 주소 변환과 검사를 위한 회로가 필요하다.
4. 베이스/바운드를 갱신하기 위한 privileged instruction : 프로그램 시작 전에 이를 설정할 수 있어야 한다.
5. 예외 핸들러 등록을 위한 privileged instruction : 범위를 벗어난 주소에 접근할 때, 예외 처리 코드를 하드웨어에 등록할 수 있어야 한다.
6. 예외 발생 기능 : 범위를 벗어난 주소에 접근할 때, 예외를 발생시킬 수 있어야 한다.

15.5 운영체제 이슈

• 위와 같은 하드웨어 지원을 받는다고 하더라도, 운영체제는 여전히 몇 가지 문제를 해결해야 한다.

• 먼저 베이스-바운드를 구현하기 위해서 운영체제가 반드시 개입해야하는 시점이 세가지가 있다.

  • 프로그램이 시작될 때 : 운영체제는 주소 공간이 저장될 메모리 공간을 찾아야 한다.
  • 프로그램이 종료될 때 : 운영체제는 사용된 메모리를 회수해야 한다.
  • 컨텍스트 스위칭 : 컨텍스트 스위칭이 일어날 때, 프로세스별 자료구조에 베이스-바운드 레지스터 값을 저장해야 한다. (참고로 이 프로세스별 자료구조를 PCB라고 한다.)
    • 당연히 새로 실행되는 프로세스의 베이스-바운드 레지스터 값을 로드해야 한다.

부팅시 LDE + 동적 재배치 

프로세스 실행중

15.6 정리

를 따로 하기보다는 여기서 생겨난 문제를 알아본다.

기본적으로 동적 재배치는 비효율적이다.

예를들어 힙이 아주 작은 프로세스라도 동일한 크기의 베이스-바운드를 가지고 있어야 한다.

그렇게 낭비되는 메모리를 내부 단편화라고 한다.

메모리의 실제 이용률을 높이기 위해서 더 나은 방법이 필요한데, 첫 번째는 base and bounds를 일반화 하는 것인데 이것을 segmentation이라고 한다.