일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- django
- JPA
- 자바
- java
- 스프링 부트
- 보안
- mysql
- 웹 개발
- Spring
- 장고
- 데이터베이스
- 파이썬3
- 개발
- 스프링
- HTTP
- ORM
- 디자인 패턴
- 파이썬
- db
- Python
- Spring Boot
- bytecode
- 스프링부트
- 웹
- python3
- 안드로이드
- node.js
- rabbitmq
- 자료구조
- BCI
- Today
- Total
semtax의 개발 일지
ARM 메모리 관리기법 분석 본문
개요
해당 포스팅은 학교 과제로 정리한 내용을 그냥 묵혀두기에는 아까워서 정리한 내용입니다.
따라서, 틀린부분이 있을 수도 있으니 너그럽게 봐주시면 감사하겠습니다..
2. ARM 메모리 관리기법 분석
2-1. Address Model in ARM
1. 하나 이상의 클라이언트 장치가 메모리 상호 연결을 통해 SMMU에 연결됩니다.
2. 클라이언트 장치는 SMMU의 업스트림으로 설명됩니다. SMMU와 클라이언트 장치 간의 연결은 업스트림 버스입니다.
3. SMMU는 메인 메모리를 통해 나머지 메모리 시스템에 연결됩니다.
4. 나머지 메모리 시스템은 SMMU의 다운 스트림으로 설명됩니다. SMMU와 나머지 메모리 시스템 간의 연결은 다운 스트림 버스입니다.
5. 클라이언트 장치는 SMMU에 트랜잭션 요청을 보냅니다. SMMU는 해당 트랜잭션을 처리하고 클라이언트에 응답을 반환합니다.
SMMU의 가능한 사용 모델에 대한 간단한 설명은 클라이언트 장치가 SMMU로 라우팅되는 메모리 액세스를 만드는 것입니다. SMMU는 메모리의 변환 테이블을 사용하여 액세스에 필요한 주소 변환을 수행하고 필요한 액세스 권한 및 속성 검사를 수행합니다.
- 변환이 성공적이며 액세스가 유효한 경우, SMMU는 액세스를 수행하고 클라이언트에게 결과를 반환합니다.
- 그렇지 않으면, SMMU는 결함 정보를 클라이언트에 반환합니다.
클라이언트 디바이스는 SMMU가 메모리 시스템에 대한 액세스를 처리 중임을 인식하지 않아도 됩니다.
SMMU에 대한 이러한 메모리 시스템 연결 외에도 SMMU는 메모리 매핑 된 레지스터 인터페이스를 제공합니다. 관리자 장치는 이 인터페이스를 사용하여 SMMU를 구성하고 제어합니다.
ARMv8-A는 가상 메모리 시스템을 사용합니다. 가상의 주소는 MMU에 의해 번역됩니다. ARM 아키텍처의 MMU는 메모리에 저장된 변환 테이블을 사용합니다. MMU를 사용하면 시스템에서 여러 작업을 실행할 수 있습니다. 운영 체제와 같은 권한있는 소프트웨어는 MMU가 이러한 두 가지 메모리를 다음 그림과 같이 처리합니다.
이렇게 하려면 하드웨어가 주소 변환을 제공해야합니다. 변환 테이블을 사용하는 주소 변환은 다음 그림과 같습니다.
이 동일한 가상 메모리를 각 프로그램에 사용할 수 있습니다. 또한, 물리적 메모리가 조각화되어 있어도 연결된 가상 메모리에서 작동합니다.
2-2. Memory Model in ARM
-
Memory Model
ARM의 Memory model은 Weakly ordered model of memory라는 특징이 있다. 이는 메모리 접근 순서가 반드시 load 및 store 작업을 위한 프로그램의 순서와 같아야 하는 것이 아니란 것을 의미한다.
프로세스의 최적화가 이루어지는 동안, 프로세서와 System elements는 데이터 처리량을 높이기 위해 서로 관련된 메모리 읽기 작업을 재정렬(reorder)할 수 있다. 마찬가지로, 메모리 쓰기 작업 역시 재정렬 가능하다. 이를 위해서는 최적화를 이루게 해주는 메모리 타입들이 존재해야 한다. 재정렬을 통해 프로세서와 외부 메모리 간의 필요한 대폭을 줄일 수 있다.
b) Memory type
ARM은 Normal과 Device라는 두 개의 상호 배타적인 메모리 타입이 존재한다. 모든 메모리 영역은 이 두 가지 유형 중 하나로 구성된다.
Normal memory는 모든 코드와 대부분의 메모리 데이터 영역에서 사용된다. 물리적 메모리의 RAM, Flash가 대표적인 예이다. Normal memory는 더 많은 최적화를 수행할 수 있는 컴파일러 덩게 최상의 프로세서 성능을 제공한다는 장점이 있다. 프로세서는 Normal memory에 대한 접근을 재정렬, 반복 또는 병합할 수 있다. 애플리케이션의 코드와 데이터를 Normal memory에 수행한다면 최상의 성능을 기대할 수 있다.
Device memory는 side effect 가능성이 있는 모든 메모리 영역과 메모리 매핑된 주변 장치들과 함께 사용된다. Device memory는 Device-GRE/nGRE/nGnRE/nGnRnE로 구분할 수 있다.
-
Gathering(G) / non-Gathering(nG)
메모리 영역에 대한 여러 개의 접근을 single transaction으로 병합할 수 있는지에 대한 여부를 결정한다. Address가 non-Gathering(nG)이면, 해당 위치에 대해 수행되는 액세스의 수와 크기는 코드의 명시적 액세스 수와 정확히 일치하여야 한다.
-
Reordering(R) / non-Reordering(nR)
동일한 장치에 대한 접근 권한을 서로에 대해 재정렬할 수 있는지에 대한 여부를 결정한다. Address가 non-Reordering(nR)이면, 같은 Block 내의 접근은 항상 프로그램 순서에 따라 버스에 나타나게 된다. 이 Block의 크기가 큰 경우, 여러 테이블 엔트리에 걸쳐 있을 수 있다.
-
Early Write Acknowledgement(E) / non-Early Write Acknowledgement(nE)
프로세서와 액세스 중인 장치 사이의 중간 Write buffer가 Write 완료 승인을 보낼 수 있는지에 대한 여부를 결정한다. Address가 non-Early Write Acknowledgement(nE)로 표시된 경우, Write의 응답은 주변 장치에서 온다. Early Write Acknowledgement인 경우, 최종 장치에서 실제로 Write를 수신하기 전에 interconnect logic의 buffer가 되며, 이는 외부 메모리 시스템에 보내는 메시지이다.
2-3. 메모리 관련 레지스터들
이러한 레지스터가 하는 일은 다음과 같다.
1) SMMU_CBn_CONTEXTIDR
현재 프로세스 식별자와 현재 주소 공간 식별자를 식별합니다.
AArch32 Short-descriptor 변환 방식이 선택될 때, 즉 SMMU_CBn_TCR.EAE의 유효 값이 0일 때, ASID는 많은 메모리 관리 기능에 의해 사용됩니다. PROCID 필드에는 SMMU 내에서 하드웨어 사용이 없습니다. AArch32 Long-descriptor 또는 AArch64 변환 스키마가 선택되면, 즉 SMMU_CBn_TCR.EAE의 유효 값이 1 일 때 ASID 필드가 이 레지스터에 없고 PROCID 필드가 32 비트가됩니다. MMU는 대신 SMMU_CBn_TTBRm.ASID 필드를 참조합니다.
2) SMMU_CBn_FAR
동기 중단 예외의 원인이 된 메모리 접속의 입력 주소를 보유합니다.
1단 및 2단 변환 컨텍스트 뱅크의 경우 N의 값은 구현 정의 값이며 SMMU_IDR2.UBS의 값에 의해 암시 된 값보다 작지 않습니다. 구현되지 않은 비트는 RAZ / WI로 동작합니다. SMMUv2에서 기록 된 주소는 항상 SMMU_CBn_TCR2.SEP에 의한 부호 확장으로 수정되지 않은 입력 주소입니다.
3) SMMU_CBn_MAIR1, 0
변환 테이블 항목의 메모리 특성 선택을 재배치하는 TEX-Remap 시스템의 개정 된 버전을 제공합니다.
이 레지스터는 AArch32 Long-descriptor 또는 AArch64 translation scheme이 선택 될 때 사용됩니다. SMMU_CBn_PRRR 및 SMMU_CBn_NMRR 레지스터는 AArch32 Short-descriptor 변환 체계가 선택 될 때 사용됩니다.
4) SMMU_CBn_TCR, 2
TLB에서 입력 주소를 찾을 수 없을 때 필요한 변환 테이블 보행에 대한 기본 주소를 정의하는 변환 테이블 기본 레지스터 SMMU_CBn_TTBRm을 포함하여 변환 특성을 결정합니다.
이 레지스터의 형식은 SMMU_CBA2Rn.VA64 및 SMMU_CBn_TCR.EAE의 값에 따라 다릅니다.
5) SMMU_CBn_TTBR0, 1
첫 번째 레벨 변환 테이블의 실제 주소를 보유합니다.
프로세스 별 주소에 대해 변환 테이블 기본 레지스터 0을 사용합니다. 각 프로세스는 별도의 첫 번째 수준 변환 테이블을 유지 관리합니다. 컨텍스트 스위치에서 변환 테이블 기본 레지스터 0과 변환 테이블 기본 제어 레지스터 (필요한 경우)를 모두 수정해야 합니다.
2-4. Paging 관리 기법
ARM은 1단계 혹은 2단계 페이징을 지원한다. 1단계 페이징은 1MB의 페이지와 16MB 페이지를 지원하며, 2단계 페이징은 4KB의 페이지와 16KB의 페이지를 지원한다.
a) 1단계 페이징
위 그림은 1단계 페이징의 절차를 나타낸 그림이다. TTBA(Translation Table Base Address)는 1단계 페이징 테이블의 시작 주소를 나타낸다. TTBA의 상위 18비트에서 페이지 테이블의 시작 주소를 구하고, 여기에서 변환하고자 하는 Virtual Address의 상위 12비트를 인덱스로 사용해 페이지 테이블 엔트리의 주소를 구한다.(First Level Descriptor Address)
0x000부터 0xfff까지 12비트를 인덱스로 사용하므로, 페이지 테이블 엔트리의 개수는 4,096개가 된다. 이후 MMU는 메모리에서 1단계 페이지 테이블의 엔트리를 가져온다.(Section Base Address Descriptor)
1단계 페이지 테이블 엔트리에는 Virtual address에 해당하는 페이지 프레임의 물리적 주소가 저장되어 있다. 1MB 페이지를 예로 들자면, 상위 12비트는 페이지 프레임의 address로 사용하고, Virtual address의 하위 20비트를 페이지 프레임 내의 offset으로 사용함으로써 Virtual Address에 해당하는 물리적 주소를 구할 수 있다.
위 그림은 1단계 페이징 테이블 엔트리에 대한 설명이다.
-
Fault
해당 엔트리에 접근하면 MMU에서 Translation Fault가 발생하게 해준다. 메모리를 할당하지 않고 페이지에 접근 시, Fault 핸들러에서 동적으로 memory를 할당하는 Demanding paging을 구현하는데 활용할 수 있다.
-
Page table
2단계 페이징에 사용되는 1단계 페이지 테이블 엔트리이다. 페이지 테이블 엔트리는 2단계 페이지 테이블의 시작 주소를 가지고 있다.
-
Section/Supersection
1단계 페이징에 사용되는 페이지 테이블 엔트리이다. 1MB 페이지를 사용하려면 Section, 16MB 페이지를 사용하려면 Supersection을 사용한다.
-
Section/Supersection Base Address
1MB/16MB 페이지 프레임의 물리적 주소
-
SBZ
0 (Should Be Zero)
-
NG
Not Global; Global memory의 여부 설정
-
S
Shareable; 메모리 속성에 따라 공유 가능 여부 설정
-
APX/AP
Access Permission; 접근 권한을 설정하는 필드
-
TEX
Type extension; 메모리 속성 설정에 사용
-
P
Present; 운영체제 커널과 같은 시스템 소프트웨어에서 사용하는 필드.(주로 swapping)
-
Domain
도메인을 설정. 메모리는 도메인 별로 접근 권한 확인 여부를 설정 가능
(No Access, Client, Manager 세 가지 타입으로 설정 가능. 총 16개의 도메인 존재)
-
XN
Execute-Never bit; CPU는 해당 메모리의 코드가 실행 가능한 지 결정함.
-
C
Cacheable; 메모리 속성 설정에 사용
-
B
Bufferable; 메모리 속성 설정에 사용
b) 2단계 페이징
위 그림은 2단계 페이징의 절차를 나타낸 그림이다. 작은 크기의 페이지들은 1단계 페이징을 하기엔 매우 비효율적이기 때문에 2단계 페이징을 사용한다.
2단계 페이징 과정은 다음과 같다. MMU는 우선 TTBA에서 1단계 페이지 테이블의 시작 주소를 가져온다. 이후 1단계 페이지 테이블의 시작 주소에서 Virtual address인 [31 ~ 20]비트를 offset으로 사용하여 접근하려는 1단계 페이지 테이블 엔트리의 주소를 구한다.(Level 1 Descriptor Address) 1단계 페이지 테이블 엔트리에는 2단계 페이지 테이블의 시작 주소가 저장되어 있다.)
2단계 페이지 테이블의 시작 주소(Level 2 Table Base Address)에서 Virtual address [19 ~ 12]비트를 offset으로 사용하여 2단계 페이지 테이블 엔트리의 주소를 구한다.(Level 2 Descriptor Address)
메모리에서 2단계 페이지 테이블 엔트리를 읽어오면, 엔트리에 저장된 Virtual address에 해당하는 페이지 프레임의 시작 주소(Small Page Base Address)를 알 수 있다.
마지막으로, 페이지 프레임의 시작 주소에서 Virtual address [11 ~ 0]비트를 offset으로 사용하여 최종 접근하는 물리적 주소(Physical Address)를 구할 수 있다.
2-5. 메모리 관련 취약점
MeltDown
이번에 발견된 취약점들은 CPU의 추측실행과 비순차실행 구조 자체를 공격하는 것으로, 원리는 유사하나 구현방법에서 차이 있는 공격 세 가지가 존재한다. 그리고 논문이 공개된 이후 다시 ARM Cortex-A15, Cortex-A57, Cortex-A72에서 작동하는 마지막 공격의 변형이 하나 발견되었다.
Variant 1: Bounds Check Bypass, CVE-2017-5753 (Spectre)
Variant 2: Branch Target Injection, CVE-2017-5715 (Spectre)
Variant 3: Rogue Data Cache Load, CVE-2017-5754 (MeltDown)
SubVariant 3a : Privileged register reads from unprivileged code (MeltDown)
잘 알려진 대로 Variant 1인 Bounds Check Bypass와 Variant 2인 Branch Target Injection을 Spectre, Variant 3인 Rogue Data Cache Load를 MeltDown이라 하며, 나중에 발견된 Privileged register reads from unprivileged code도 Variant 3과 비슷한 성격으로 보아 SubVariant 3a인 MeltDown으로 분류하고 있다. Variant 3a의 경우 Variant 3과 많은 부분이 유사하지만 공격 대상이 메모리가 아니라 레지스터라는 점에서 차이가 있는 정도이며, 상대적으로 다른 취약점에 비해 공격의 영향은 작다. 앞으로 이 원고에서는 Variant 3에 한정해서 MeltDown이라는 용어를 사용하고 설명하도록 하겠다.
MeltDown은 이름에서 알 수 있듯이 일반과 특권의 영역경계가 무너져서 일반 유저 권한 프로세스가 커널의 보호되는 메모리 영역을 무제한적으로 읽을 수 있는 취약점으로, 인텔과 ARM 계열 일부 CPU에서만 공격 성공이 확인됐다. AMD나 다른 ARM 프로세서, PowerPC 등에서 이 공격을 성공시키지 못한 것은 구현의 차이에 따른 것으로 생각되지만 실제 CPU 내부의 마이크로코드가 어떤 식으로 작동하는지는 확인할 수 없으므로 추측만 할 뿐이다. 앞서 얘기한 대로 이 공격이 성공하려면 추측실행 이후 취소되기 전까지(즉 misspeculation window 동안) 데이터 유출이 가능하게끔 코드가 실행돼야 한다. MeltDown 공격은 대략 다음과 같은 식으로 구현할 수 있다. 참고로 아래 내용은 원리를 설명하는데 주안점을 둔 방식이며 실제 공격 시에는 이렇게 비효율적으로 1비트씩 읽지 않고 배열을 사용하여 1바이트의 내용을 한 번에 확인한다. 캐쉬도 한 번에 읽는 단위(캐쉬라인)가 있어서 코드를 작성할 때 그 부분도 고려해주어야 한다.
1) 메모리 a0과 a1을 Flush한다(캐쉬를 소거).
2) 레지스터 R에 보호된 메모리 영역 ap(공격대상)를 읽어 들인다. ap는 커널 메모리에 존재하므로 여기서 보호비트에 의해 예외가 발생하고 아래의 3) 4)는 실행되지 않아야 한다.
3) R의 0번 비트가 0이면 a0, 1이면 a1을 메모리 ax에 대입한다.
4) ax의 메모리 주소 내용을 읽는다. 즉 a0 또는 a1이 읽혀지고 캐쉬에 남는다.
5) CPU는 최대한 파이프라인을 쉬지 않게 실행하려고 하므로 3) 4)는 같이 실행됐다가 취소될 수 있다. 그래도 캐쉬에는 a0 또는 a1이 남아 있다.
6) 캐쉬에 직접 접근하는 건 불가능하지만, a0과 a1를 각각 읽으면서 시간을 측정하면 캐쉬에 존재하는 데이터가 더 빨리 읽힌다. 이제 ap의 0번 비트가 0인지 1인지를 알 수 있다.
7) 같은 원리로 ap의 다른 비트들도 읽을 수 있고, 반복하면 커널 메모리를 처음부터 모두 덤프할 수 있다.
일반적으로 커널 메모리에는 보호비트가 설정돼 있어서 일반 모드 애플리케이션이 읽으려고 하면 예외가 발생하면서 거기서 실행이 멈춘다. 따라서 순차적으로 명령을 실행한다면 2)에서 프로그램은 멈춰야 하고 그 이하의 명령들은 실행되지 않아야 한다. 하지만 현대적 CPU는 수퍼스칼라 구조에 의해 복수 개 파이프라인에 한꺼번에 명령을 적재하므로 이미 명령 3) 4)까지가 Fetch-Decode를 거쳐서 실행유닛에 올라와 있을 수 있고, 이 경우 2)에서 예외가 발생하기 전에 ap의 값이 전달돼 3) 4)까지 실행이 된다면 a0 또는 a1 둘 중의 한 메모리가 캐쉬에 남게 된다. 그 후 예외가 발생하면 3) 4)가 파이프라인에서 삭제되면서 명령의 실행은 취소되지만 이미 읽은 메모리에 대한 캐쉬까지 원래대로 복구되지는 않으므로 이 데이터를 통해 간접적으로 보호된 메모리의 내용을 확인할 수 있는 것이다. 여기서 중요한 건 역시 속도로, 2)의 명령에 의해 예외가 발생하기 전에 최소 3) 4)까지 실행이 완료돼야 공격이 성공하게 된다.
MeltDown의 대응
MeltDown은 일단 1) exploit을 대상 시스템에 업로드할 수 있어야 하고 2) 해당 exploit을 실행할 수 있어야 한다라는 두 가지 조건만 충족하면 공격이 성립한다. 즉 예전에 문제가 되었던 SMB attack처럼 네트워크에 접속만 하면 감염되는 그런 종류는 아니고 local exploit에 해당한다고 할 수 있다. 하지만 다른 종류의 공격을 통해 쉘(예를 들어 웹쉘)을 얻으면 앞서의 두 가지 조건은 아주 간단하게 맞춰지므로 네트워크로부터의 공격에 완전히 안전하다고 말할 수도 없다. 심각한 점은 이 취약점의 원리가 대단히 심오한데 비해 공격 방법이 간단하고 조건을 맞추기가 까다롭지 않기 때문에 패치가 되지 않은 시스템에 대한 공격은 아주 높은 확률로 성공한다는 것이다. 암호화된 비밀도 결국은 사용하기 위해 복호화해 메모리에 올려야 하는데, 이 부분을 아무런 흔적도 남기지 않고 쉽게 읽을 수 있다는데 MeltDown의 심각성이 있다.
또한 이 경우 1차적인 공격대상이 되는 건 커널 메모리이지만 커널 메모리에는 프로세스의 페이지 테이블이 저장돼 있다. 잘 알려진 대로 현대적인 CPU에서는 메모리를 유연하게 사용하기 위해 모든 주소를 가상화하여 사용하며 이 가상화된 메모리와 실제 물리 메모리를 맵핑하는 데이터를 갖는 것이 페이지 테이블이다. 즉 이 페이지 테이블이 없이는 메모리로부터 1바이트도 읽을 수 없는데 커널 메모리에 제한 없이 접근할 수 있다는 것은 곧 다른 프로세스의 메모리도 동일하게 읽어낼 수 있다는 사실을 의미하는 것이다.
따라서 위의 두 가지 조건을 충족하거나 그럴 가능성이 있는 시스템들은 패치를 해야 하며, 커널에 대한 공격이므로 OS에 대한 패치가 이 취약점에 대한 대응방법이 된다. 패치의 내용은 간단하게 커널의 페이지 테이블과 애플리케이션의 페이지 테이블을 분리하여 실제로 보호된 메모리의 내용은 커널이 아니면 읽지 못하게 하는 것이다. 리눅스에서는 이미 KPTI(Kernel Page Table Isolation)이라는 이름으로 적용돼 있으며, 윈도우의 패치도 페이지풀을 복사하는 유사한 내용이다. 지금까지는 효율을 위해 모든 애플리케이션의 페이지 테이블에 커널의 페이지 테이블을 복사해서 포함시켜 두었다. 결국 애플리케이션이 시스템콜을 하게 되면 커널의 주소공간에 위치한 API 함수들에 접근해야 하기 때문이다. 이번 패치는 애플리케이션과 커널이 컨텍스트 스위칭을 할 때 양쪽의 페이지 테이블을 그때마다 복사해서 교체하므로 애플리케이션에서 MeltDown 취약점을 이용해 커널주소의 내용을 읽으려고 해도 그에 해당하는 페이지 테이블이 없어서 실제 내용을 읽지 못하게 하는 것이다.
위 그림은 KPTI의 간단한 모식도다. 보라색 부분이 Kernel Space에 대한 페이지 테이블인데 이를 오른쪽처럼 커널 모드와 사용자 모드로 분리하는 것이 KPTI이다. 패치 후 공격자는 하얀색의 비어있는 부분은 읽을 수 없고 API 호출을 위한 최소한의 영역인 보라색 부분에만 접근할 수 있다.
2-6. Memory ordering
코드가 하드웨어 또는 다른 코어에서 실행중인 코드와 직접 상호 작용하거나 실행 지침을 직접로드하거나 작성하거나 페이지 테이블을 수정하는 경우 메모리 주문 문제를 인식해야합니다.
응용 프로그램 개발자 인 경우 하드웨어 상호 작용은 장치 드라이버를 통해 이루어지며 다른 코어와의 상호 작용은 Pthread 또는 다른 다중 스레드 API를 통해 이루어지며 페이징 된 메모리 시스템과의 상호 작용은 운영 체제를 통한 것입니다. 이 모든 경우에 메모리 주문 문제는 관련 코드에 의해 처리됩니다. 그러나 운영 체제 커널 또는 장치 드라이버를 작성하거나 하이퍼 바이저, JIT 컴파일러 또는 멀티 스레딩 라이브러리를 구현하는 경우 ARM 아키텍처의 메모리 순서 지정 규칙을 잘 이해하고 있어야합니다. 코드에서 메모리 액세스의 명시적인 순서가 필요한 곳에서 올바른 장벽 사용을 통해이를 달성 할 수 있어야합니다.
ARMv8 아키텍처는 weakly-ordered model을 사용합니다. 일반적으로 이것은 메모리 액세스 순서가로드 및 저장 조작의 프로그램 순서와 동일 할 필요는 없다는 것을 의미합니다. 프로세서는 서로에 대해 메모리 판독 동작을 재정렬 할 수있다. 또한 쓰기를 다시 정렬 할 수도 있습니다 (예 : 쓰기 결합). 결과적으로 캐시 및 쓰기 버퍼 사용과 같은 하드웨어 최적화는 프로세서의 성능을 향상시키는 방식으로 작동합니다. 즉, 필요한 대역폭 프로세서와 외부 메모리 사이의 간격이 줄어들 수 있고 그러한 외부 메모리 액세스와 관련된 긴 대기 시간이 숨겨 질 수 있습니다.
일반 메모리에 대한 읽기 및 쓰기는 하드웨어에 의해 다시 정렬 될 수 있으며 데이터 종속성 및 명시 적 메모리 차단 명령에만 종속됩니다. 특정 상황에서는보다 강력한 주문 규칙이 필요합니다. 해당 메모리를 설명하는 변환 테이블 항목의 메모리 유형 속성을 통해 코어에 대한 정보를 코어에 제공 할 수 있습니다.
매우 고성능 시스템은 추측 메모리 읽기, 다중 명령 발행 또는 순서가 잘못된 실행과 같은 기술을 지원할 수 있으며 이러한 기술은 다른 기술과 함께 메모리 액세스의 하드웨어 재주문을위한 추가 가능성을 제공합니다.
여러 가지 문제 지침
프로세서는 사이클 당 여러 명령어를 발행하고 실행할 수 있으므로 프로그램 순서로 서로 다른 명령어가 동시에 실행될 수 있습니다.
비 순차적 실행
많은 프로세서가 비 종속 명령어의 순서가 잘못된 실행을 지원합니다. 선행 명령의 결과를 기다리는 동안 명령이 정지 될 때마다 프로세서는 종속성이없는 후속 명령을 실행할 수 있습니다.
추측
프로세서가 분기와 같은 조건부 명령을 만날 때 특정 명령을 실행해야하는지 여부를 확실히 알기 전에 추측 적으로 명령 실행을 시작할 수 있습니다. 따라서 추측이 정확하다는 조건이 풀리면 결과를 더 빨리 얻을 수 있습니다.
투기 적 하중
캐시 가능한 위치에서 읽는로드 명령어가 추론 적으로 실행되면 캐시 라인 필과 기존 캐시 라인의 잠재적 이탈이 발생할 수 있습니다.
로드 및 저장 최적화
외부 메모리에 대한 읽기 및 쓰기가 긴 대기 시간을 가질 수 있기 때문에 프로세서는 여러 저장소를 하나의 큰 트랜잭션으로 병합하는 등 전송 횟수를 줄일 수 있습니다.
외부 메모리 시스템
많은 복잡한 SoC (System on Chip) 장치에는 전송을 시작할 수있는 여러 에이전트와 읽고 쓰는 슬레이브 장치에 대한 다중 경로가 있습니다. DRAM 컨트롤러와 같은 일부 장치는 서로 다른 마스터의 동시 요청을 받아 들일 수 있습니다. 트랜잭션은 상호 연결에 의해 버퍼링되거나 재 배열 될 수 있습니다. 즉, 서로 다른 마스터의 액세스가 완료되기까지 다양한주기를 소요하고 서로 추월 할 수 있음을 의미합니다.
캐시 일관된 멀티 코어 프로세싱
멀티 코어 프로세서에서 하드웨어 캐시 일관성은 코어 간에 캐시 라인을 마이그레이션 할 수 있습니다. 따라서 서로 다른 코어는 서로 다른 순서로 캐시 된 메모리 위치에 대한 업데이트를 볼 수 있습니다.
컴파일러 최적화하기
최적화 컴파일러는 지연 시간을 숨기거나 하드웨어 기능을 최대한 활용하도록 지침을 재정렬 할 수 있습니다. 종종 메모리 액세스를 앞당겨서 앞당길 수 있으며, 값이 필요하기 전에 완료하는 데 더 많은 시간을 할애 할 수 있습니다.
단일 코어 시스템에서는 개별 프로세서가 위험을 검사하고 데이터 종속성을 존중할 수 있기 때문에 이러한 재주문의 효과는 일반적으로 프로그래머에게 투명합니다. 그러나 공유 메모리를 통해 통신하는 여러 코어가 있거나 다른 방식으로 데이터를 공유하는 경우 메모리 주문 고려 사항이 더 중요해집니다. 이 장에서는 다중 처리 (MP) 조작 및 다중 실행 스레드의 동기화와 관련된 몇 가지 주제에 대해 설명합니다. 또한 아키텍처에서 정의한 메모리 유형과 규칙 및 이러한 아키텍처가 제어되는 방식에 대해 설명합니다.
'보안 > 시스템 해킹' 카테고리의 다른 글
운영체제론 : 가상메모리 내용 간략 정리 (0) | 2020.04.23 |
---|---|
인텔 메모리 관리 기법 분석 (0) | 2020.04.23 |
pwnable.kr fd 풀이 (0) | 2020.04.15 |