나는 최신 운영 시스템이 디버깅을 위해 api를 제공한다는 것을 알고 있습니다. 디버거 프로세스가 커널에게 다른 프로세스의 기계어 명령에 브레이크 포인트를 설정하도록 요청하면 커널은 명령의 첫 번째 바이트를 인터럽트를 발생시키는 opcode로 바꿉니다.소프트웨어 중단 점 및 최신 OOOE 프로세서
인터럽트 처리기는 프로세스를 중단하고 레지스터를 저장하고 디버깅 프로세스에 알립니다.
내가 이해할 수없는 것은 순서가 잘못된 실행 프로세서에서 정확하게 발생하는 것입니다. 인터럽트 명령은 선행 작업 이전이나 조상 작업 이후에 실행될 수 있으므로 인터럽트 발생시 레지스터와 메모리에 잘못된 값이 포함됩니다.
인터럽트, 오류, 예외 등과 같은 모든 정렬 된 이벤트는 원래 프로그램 순서가 복원되고 올바른 시스템 상태가 될 수있는 순서가 잘못된 프로세서의 커밋 시점에서 항상 처리됩니다. 캡처 됨. 이것은 보류중인 이벤트를 알지만 여전히 처리 지연을 의미합니다.
메모리와 같이 외부 세계에서 보이는 작업도이 단계를 지나서 처리되므로 순서가 잘못된 코어의 추측 내부 상태는 볼 수 없습니다 (물론 측면 채널 공격 방법은 제외) ...), 인터럽트 나 브레이크 포인트도 올바르게 정렬됩니다.
일반적으로 인터럽트라고하는 비동기 이벤트 (명령 흐름과 관련 있음)는 커밋 지점을 선택할 수 있습니다. 또한, 동기 이벤트 처리는 확약 이전에 (추측 적으로) 시작할 수 있습니다. 물론, 지금까지 아무도 (AFAIK) 복잡성에 가치가있는 이익을 고려하지 않았습니다! (그러한 뉘앙스는 질문에 대한 답을 찾는 사람을 혼란스럽게 할 수 있습니다.) 현대 프로세서 (OoO 및 주문형 주문/OoO 완료)가 * 정확한 예외를 제공한다고 말하면 OP가 향후 연구에 사용할 용어를 제공하게됩니다. 마찬가지로 비 아키텍처 * 상태 및 효과 (예 : 전력 사용, DRAM 액세스, 캐시 내용)에서 * 아키텍처 상태 (예 : 레지스터 및 메모리 값)를 –
과 구별하는 것은 '외부에서 볼 수있는 동작 세계 "이지만 ** 타겟 고객에게 덜 분명 **합니다. 학문의 박람회를 가진 사람들을 매장하지 않는 것은 일반적으로 미덕입니다! +1 –
@ PaulA.Clayton - 정확한 예외에 대해서는 좋은 지적이지만 아키텍처와 비 아키텍처는 내가 작성한 요점이 아니 었습니다 - DRAM 쓰기 액세스 (메모리로서의 아키텍처는 시스템 아키텍처의 일부입니다. 상태)은 내부 레지스터 쓰기 (아키텍처가 분명하지만 외부 검사에서 숨기고 노출이 필요할 때 롤백하는 것)보다 훨씬 문제가 있습니다. 그러므로 구별은 투기 적으로 수행되어서는 안되는 외부에서 볼 수있는 효과와 자유롭게 추측 할 수있는 내부 효과 사이의 구분입니다. – Leeor
http://en.wikipedia.org/wiki/Memory_barrier seems related –
'커널은 명령의 첫 번째 바이트를 인터럽트를 일으키는 opcode '- 아니, 오늘이 아닙니다. 최신 프로세서에는 다양한 조건에서 디버거 인터럽트를 허용하는 디버그 하드웨어가 내장되어 있습니다 (예 : 브레이크 포인트 레지스터와의 명령 포인터 일치. –