KR20220108175A - 모드간 호출 분기 명령어 - Google Patents

Abstract

프로세싱 회로부(4)는 핸들러 모드 및 스레드 모드를 갖는다. 예외 조건에 응답하여, 핸들러 모드로의 전환이 이루어진다. 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어에 응답하여 프로세싱 회로부(4)가 핸들러 모드에 있을 때, 명령어 디코더(10)는 프로세싱 회로부를 제어하여 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고; 프로세싱 회로부(4)의 현재 모드를 스레드 모드로 전환하고; 분기 타겟 어드레스에 의해 식별되는 명령어로 분기한다. 이것은 예외들의 권한박탈에 유용할 수 있다.

Description

모드간 호출 분기 명령어

본 발명은 데이터 프로세싱의 분야에 관한 것이다.

프로세싱 회로부는 프로세싱 회로부가 명령어들을 프로세싱하는 다수의 동작 모드들을 가질 수 있다. 예를 들어, 모드들은 적어도 핸들러 모드 및 스레드 모드를 포함할 수 있다. 예외 조건들은 프로세싱 회로부로 하여금 핸들러 모드에서 예외 핸들러를 프로세싱하도록 전환시킬 수 있다. 핸들러 모드와 스레드 모드의 하드웨어 분리를 제공함으로써, 운영 체제와 연관된 예외 핸들러들의 동작과 운영 체제에 의해 관리되는 스레드들 사이의 분리를 관리하는 것을 더 용이하게 만들 수 있다.

적어도 일부 예들은: 적어도 핸들러 모드 및 스레드 모드를 포함하는 복수의 모드들 중 하나에서 데이터 프로세싱을 수행하기 위한 프로세싱 회로부; 예외 조건에 응답하여 프로세싱 회로부를 제어하여 핸들러 모드에서 예외 핸들러의 프로세싱으로 전환하기 위한 예외 제어 회로부; 및 프로세싱 회로부를 제어하여 데이터 프로세싱을 수행하도록 명령어들을 디코딩하기 위한 명령어 디코더를 포함하는 장치를 제공하고; 여기서: 적어도 프로세싱 회로부는 핸들러 모드에 있고, 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여: 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고; 프로세싱 회로부의 현재 모드를 스레드 모드로 전환하고; 분기 타겟 어드레스에 의해 식별된 명령어로 분기하도록 구성된다.

적어도 일부 예들은 적어도 핸들러 모드 및 스레드 모드를 포함하는 복수의 모드들 중 하나에서 데이터 프로세싱을 수행하기 위한 프로세싱 회로부; 및 예외 조건에 응답하여 프로세싱 회로부를 제어하여 핸들러 모드에서 예외 핸들러의 프로세싱으로 전환하기 위한 예외 제어 회로부를 포함하는 장치에 대한 데이터 프로세싱 방법을 제공하고, 상기 방법은: 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어를 디코딩하는 단계; 및 적어도 프로세싱 회로부가 핸들러 모드에 있을 때, 모드간 호출 분기 명령어에 응답하여: 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하는 단계; 프로세싱 회로부의 현재 모드를 스레드 모드로 전환하는 단계; 및 분기 타겟 어드레스에 의해 식별된 명령어로 분기하는 단계를 포함한다.

적어도 일부 예들은 호스트 데이터 프로세싱 장치를 제어하여 타겟 프로그램 코드로부터 명령어들의 실행을 위한 명령어 실행 환경을 제공하기 위한 컴퓨터 프로그램을 제공하고; 컴퓨터 프로그램은: 적어도 핸들러 모드 및 스레드 모드를 포함하는 복수의 모드들 중 하나에서 데이터 프로세싱을 수행하기 위한 프로세싱 프로그램 로직; 예외 조건에 응답하여 프로세싱 프로그램 로직을 제어하여 핸들러 모드에서 예외 핸들러의 프로세싱으로 전환하기 위한 예외 제어 프로그램 로직; 및 프로세싱 프로그램 로직을 제어하여 데이터 프로세싱을 수행하도록 타겟 프로그램 코드의 명령어들을 디코딩하기 위한 명령어 디코딩 프로그램 로직을 포함하고; 여기서: 적어도 프로세싱 프로그램 로직이 핸들러 모드에 있을 때, 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어에 응답하여, 명령어 디코딩 프로그램 로직은 프로세싱 프로그램 로직을 제어하여: 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고; 프로세싱 프로그램 로직의 현재 모드를 스레드 모드로 전환하고; 분기 타겟 어드레스에 의해 식별된 타겟 프로그램 코드의 명령어로 분기하도록 구성된다.

컴퓨터-판독가능 저장 매체는 전술한 컴퓨터 프로그램을 저장할 수 있다. 저장 매체는 비일시적 저장 매체일 수 있다.

본 기법의 추가의 태양들, 특징들 및 이점들은 첨부 도면과 관련하여 읽혀질 예들의 하기의 설명으로부터 명백해질 것이다.
도 1은 개략적으로 상이한 동작 모드들을 지원하는 프로세싱 회로부를 갖는 데이터 프로세싱 시스템의 예를 도시한다.
도 2는 프로세싱 회로부의 상이한 도메인들 및 동작 모드들의 예를 도시한다.
도 3은 프로세싱 회로부의 레지스터들의 예를 도시한다.
도 4는 실행가능 명령어들에 사용될 수 없는 예약된 어드레스 범위의 제공을 도시한다.
도 5는 더미 함수 복귀 어드레스 및 더미 예외 복귀 어드레스를 도시한다.
도 6은 함수 호출 또는 예외에 응답하여 스택에 저장될 수 있는 상이한 스택 프레임들을 도시한다.
도 7은, 비교를 위해, 모드간 호출 분기 명령어들이 지원되지 않는 경우에, 예외 권한해제의 예를 도시한다.
도 8은 모드간 호출 분기 명령어를 이용한 예외 권한박탈의 예를 도시한다.
도 9는 금지된 도메인/모드 조합 전환의 예를 도시한다.
도 10은 허용된 도메인/모드 조합 전환의 예를 도시한다.
도 11a 내지 도 11c는 도 10의 도메인/모드 조합 전환이 유용할 수 있는 꼬리 호출(tail calling)의 예를 도시한다.
도 12는 함수가 호출될 때 수행되는 단계들을 도시하는 흐름도이다.
도 13은 예외 엔트리에 수행되는 단계들을 도시하는 흐름도이다.
도 14는 함수 호출 이외의 분기 명령어에 응답하여 수행되는 단계들을 도시하는 흐름도이다.
도 15는 더미 함수 복귀 어드레스로의 분기에 응답하여 수행되는 단계들을 도시하는 흐름도이다.
도 16a 내지 도 16d는 도 15에 도시된 무결성 크로스-체크를 이용하여 검출될 수 있는 잠재적 공격을 도시한다.
도 17은 스레드 모드에서의 도메인 전이의 디스에이블링을 도시하는 흐름도이다.
도 18 내지 도 20은 도메인 전이 디스에이블 구성 파라미터를 이용하는 예들을 도시한다.
도 21은 안전한 어드레스 영역에서 어드레스를 갖는 명령어를 페칭 시 도메인 전이 디스에이블 구성 파라미터의 체크를 도시하는 흐름도이다.
도 22는 사용될 수 있는 시뮬레이터 예를 도시한다.
모드간 호출 분기 명령어
프로세싱 회로부가 핸들러 모드 및 스레드 모드를 지원하는 시스템에서, 일반적으로 예외 핸들러들(예컨대 운영 체제 또는 기타 감독 소프트웨어와 연관됨)의 프로세싱에 사용되는 핸들러 모드 및 운영 체제 또는 감독 소프트웨어에 의해 관리되는 스레드들의 백그라운드 코드를 프로세싱하는 데 사용되는 스레드 모드를 예상한다. 그러나, 때때로 USB 제어기 또는 무선 네트워크 인터페이스와 같은 신뢰될 수 없는 디바이스로 지향되는 유형들의 예외들이 있을 수 있다. 이러한 디바이스들에 대한 인터럽트들은 프로세싱 시스템의 일반적 동작을 관리하는 운영 체제를 제공하는 당사자와는 상이한 제3자에 의해 제공되는 예외 핸들러 코드에 의해 핸들링될 수 있다. 운영 체제 제공자는 다른 당사자에 의해 제공되는 코드를 신뢰할 수 없고 따라서 이러한 비신뢰 디바이스들을 제어하기 위한 비신뢰 예외 핸들러 코드가 핸들러 모드와 연관된 전체 권한을 갖지 않기를 바랄 수 있다. 따라서 코드가 핸들러 모드에서 정상적으로 액세스할 수 있는 모든 레지스터들 또는 메모리에 액세스하는 능력을 예외 핸들러가 갖지 않을 수 있도록 예외를 "권한박탈"할 수 있는 요구가 있을 수 있다. 또한, 디바이스 상에서 실행되는 모든 소프트웨어가 동일한 벤더로부터 온 경우, 권한부여된 소프트웨어의 복잡성을 감소시키고, 그럼으로써 권한부여된 소프트웨어에 보안 취약성이 존재할 가능성을 감소시키려는 요구가 있을 수 있다. 심층 방어 전략의 일환으로서, 모든 소프트웨어가 단일 벤더로부터 온 경우에도, 이와 같이 예외들을 "권한박탈"하려는 요구가 있을 수 있다.
그러나, 핸들러 모드 및 스레드 모드를 갖는 일반적인 시스템에서, 그 모드들을 전환하는 메커니즘은 스레드 모드에서 핸들러 모드로 전환하기 위한 예외들 및 스레드 모드로 다시 전환하기 위한 예외 복귀들을 이용하는 것일 수 있다. 단순히 스레드 모드로 돌아가는 예외 복귀를 트리거하는 것이 적절하지 않을 수 있는데, 그 이유는 이것이 통상적으로 원래 예외와 연관된 우선순위의 레벨을 떨어뜨려, 상이한 인터럽트들 또는 예외들을 적절히 우선순위화하는 데 어려움을 초래할 것이다. 따라서, 단지 제2 예외로부터 복귀 시 원래 예외로 하여금 핸들러 모드 대신에 스레드 모드에서 프로세싱되게 하는 예외 복귀 제어 정보를 설정하기 위하여, 종종 "위조" 제2 예외가 생성될 필요가 있을 수 있다. 이 메커니즘은 느릴 수 있는데, 그 이유는 제2 예외를 호출하는 것이 위조 예외 복귀 동작을 설정하기 위한 동작들의 성과 비용뿐만 아니라, 또한 추가적인 상태 저장 및 복원 동작들의 비용을 초래할 수 있기 때문이며, 이들은 통상적으로 예외 전에 실행 중인 프로세스와 연관된 아키텍처 상태를 보존하기 위하여 예외 진입 및 복귀 시 수행된다. 따라서, 예외 핸들러를 권한박탈하는 데 예외 엔트리 및 복귀 메커니즘이 사용되는 경우, 전체 인터럽트/예외 핸들링 레이턴시를 증가시킬 수 있고, 이는 일부 시스템들에서, 특히 실시간 애플리케이션에 의도된 시스템들에서 허용불가능할 수 있다. 또한, 이 접근법은 컴파일러에 대해 코딩하기 어려울 수 있어서, 에러를 초래할 가능성이 있다.
아래 설명되는 예들에서, 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어가 제공된다. 모드간 호출 분기 명령어에 응답하여, 적어도 프로세싱 회로부가 핸들러 모드에 있을 때, 명령어 디코더는 프로세싱 회로부를 제어하여 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고, 프로세싱 회로부의 현재 모드를 스레드 모드로 전환하고, 분기 명령어에 의해 명시된 분기 타겟 어드레스에 의해 식별되는 명령어로 분기하도록 한다. 따라서, 명령어가 핸들러 모드 대신에 스레드 모드에서 프로세싱될 명령어의 분기 타겟 어드레스로 직접 분기될 수 있는 함수 호출 메커니즘이 제공된다. 이는 예외들을 권한박탈하기 위한 훨씬 더 빠르고 더 단순한 메커니즘을 제공하여, 전술된 바와 같이 위조 제2 예외에 대한 필요성을 제거한다.
핸들러 모드 및 스레드 모드에 더하여, 프로세싱 회로부는 또한 적어도 안전한 도메인 및 덜 안전한 도메인을 포함하는 다수의 안전한 도메인들 중 하나에서 데이터 프로세싱을 지원할 수 있다. 프로세싱 회로부의 현재 안전한 도메인에 따라 메모리 액세스가 허용되는지 여부를 체크하기 위한 메모리 액세스 체크 회로부가 제공될 수 있다. 예를 들어, 메모리 액세스 체크 회로부는 각각의 어드레스 영역들을 안전한 도메인과 연관된 안전한 영역들 또는 덜 안전한 도메인과 연관된 덜 안전한 영역들로서 정의하는 보안 속성들을 제공하는 테이블들을 유지할 수 있다. 안전한 도메인에서 동작할 때, 프로세싱 회로부는 메모리의 안전한 영역들 및 덜 안전한 영역들 둘 모두에 대한 액세스를 가질 수 있는 반면, 덜 안전한 도메인에서 동작할 때 프로세싱 회로부는 덜 안전한 영역들에 대한 액세스를 가질 수 있지만 안전한 영역들에 액세스하는 것은 허용되지 않을 수 있다.
명령어 디코더 및 프로세싱 회로부는 분기 타겟 어드레스를 명시하는 도메인간 호출 분기 명령어를 지원할 수 있다. 도메인간 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고, 분기 타겟 어드레스에 의해 식별되는 명령어로 분기되고, 프로세싱 회로부의 현재 안전한 도메인을 전환할 수 있다. 따라서, 안전한 도메인의 변경은 또한 하나의 도메인으로부터 다른 도메인으로의 직접 분기를 허용함으로써 더 빠르게 이루어질 수 있다. 일부 시스템들에서, 도메인간 호출 분기 명령어들은 안전한 도메인에서 덜 안전한 도메인으로의 방향 및 덜 안전한 도메인에서 안전한 도메인으로의 방향 둘 모두에서 지원될 수 있다. 그러나, 다른 구현예들에서 도메인들을 전환하는 양방향에 대하여 도메인간 호출 분기 명령어들을 제공하는 것이 필요하지 않을 수 있다. 예를 들어, 일부 구현예들에서 도메인간 호출 분기 명령어는 안전한 도메인에서 덜 안전한 도메인으로의 전환을 트리거하는 안전한-덜 안전한 호출 분기 명령어일 수 있고, 덜 안전한 도메인에서 안전한 도메인으로 전이하기 위한 다른 메커니즘들이 제공될 수 있다(예컨대 대신에 보안 게이트웨이 명령어는 도메인으로 하여금 덜 안전한 도메인에서 안전한 도메인으로 전환되게 하여, 메모리의 덜 안전한 영역들로부터의 명령어들을 실행한 후에 메모리의 안전한 영역으로부터 페치된 제1 어드레스에 보안 게이트웨이 명령어가 존재하도록 요구함으로써 안전한 도메인이 진입될 수 있는 유효 위치들이 제한되도록 할 수 있다). 일부 구현예들은 권한부여된 것으로 마크된 메모리 영역만을 액세스하는 덜 권한부여된 상태에서 실행되는 코드를 방지하기 위한 유사한 기법들을 사용할 수 있다.
따라서, 다수의 호출 분기 명령어들이 지원될 수 있으며, 이는 프로세싱 회로부로 하여금 함수 복귀 어드레스를 저장하고 분기된 타겟 어드레스에서 명령어를 분기하는 함수 호출 동작들을 수행하게 한다. 이는, 스레드 모드로의 전환을 트리거하는 모드간 호출 분기 명령어 및 안전한 도메인의 변경을 트리거하는 도메인간 호출 분기 명령어뿐만 아니라, 동일한 모드 및 도메인 내에 유지되는 호출 분기 명령어들을 포함할 수 있다. 그러나, 동일한 호출 분기 명령어에 응답하여 모드 및 도메인 둘 모두에서의 조합된 전환이 금지될 수 있다. 따라서, 모드간 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부의 현재 안전한 도메인을 변경하지 않으면서, 현재 모드를 스레드 모드로 전환하도록 프로세싱 회로부를 제어할 수 있다. 이는 허용되는 보안 도메인의 유효 전이의 수를 감소시킴으로써 보안을 증진시켜, 보안 도메인의 변경이 안전하다는 것을 검증하는 것을 더 간단하게 만들 수 있다.
모드간 함수 복귀 명령어에 응답하여, 프로세싱 회로부는 프로세싱 회로부의 현재 모드를 다시 핸들러 모드로 전환하고 모드간 호출 분기 명령어에 의해 이전에 저장된 함수 복귀 어드레스에 의해 식별된 명령어로 분기될 수 있다. 따라서, 예외 핸들러의 권한박탈된 부분이 완료되면, 모드간 함수 복귀 명령어는, 대응하는 예외가 발생했을 때 프로세싱 회로부가 처음 실행하던 핸들러 모드로 돌아가는 전환을 트리거 하는 데 사용될 수 있다.
일부 예들에서, 모드간 함수 복귀 명령어는 명령어 디코더에 의해 함수 복귀 동작을 요구하는 것으로서 식별되는 인코딩을 갖는 전용 함수 복귀 명령어일 수 있다.
그러나, 필수적인 것은 아니고 일부 경우들에서 명령어가 모드간 함수 복귀를 야기하는지 여부는 그것이 실행될 때 레지스터들 또는 메모리에 저장된 정보에 따라 달라질 수 있다. 예를 들어, 모드간 함수 복귀는 예약된 비-실행가능 어드레스(아래에서 더미 함수 복귀 어드레스로 지칭됨, 예컨대 도 5에 도시된 FNC_RETURN 어드레스(140), 이는 이후에 더 상세하게 설명될 것임)로 분기하려는 시도에 의해 트리거될 수 있다. 모드간 함수 복귀 명령어가 예외 핸들러의 권한박탈된 섹션 내의 비신뢰 코드의 일부일 수 있기 때문에, 모드간 함수 복귀 명령어가 스레드 모드에서 핸들러 모드로 다시 전환하는 것을 트리거하도록 의도되지 않을 비-모드간 함수 복귀 명령어와 동일한 명령어 인코딩을 갖는 경우 유용할 수 있는데, 그 이유는 예외 핸들러의 권한박탈된 섹션이 그것의 예외 핸들러가 권한박탈되었는지 알지 못하는 제3자에 의해 제공될 수 있기 때문이다.
일부 예들에서, 모드간 호출 분기 명령어에 응답하여, 명령어 디코더는 더미 함수 복귀 어드레스를 링크 레지스터에 저장하도록 프로세싱 회로부를 제어할 수 있다. 더미 함수 복귀 어드레스는 유효 실행가능 어드레스가 아닌, 예약된 어드레스들의 범위 내의 어드레스일 수 있다. 더미 함수 복귀 어드레스는 더미 함수 복귀 어드레스가 모드간 호출 분기 명령어에 응답하여 저장되었음을 나타내는 모드간 호출 표시 값을 포함할 수 있다. 명령어가 더미 함수 복귀 어드레스로 분기하려고 시도하는 경우, 더미 함수 복귀 어드레스가 모드간 호출 표시 값을 포함하면, 프로세싱 회로부는 그 명령어를 모드간 함수 복귀 명령어로서 처리하고, 핸들러 모드로 전환할 뿐만 아니라 스택으로부터 획득된 실제 함수 복귀 어드레스로 분기할 수 있다. 따라서, 모드간 호출 표시 값을 더미 함수 복귀 어드레스 내에 저장함으로써, 동일한 명령어 인코딩이 두 유형의 함수 복귀에 사용될 수 있도록, 모드간 함수 복귀를 비-모드간 복귀들로부터 구분할 수 있다. 이는 위에서 설명한 모드간 분기 기술을 지원하기 위해 제3자 권한박탈된 예외 핸들러 코드의 변경이 필요 없음을 의미한다. 또한, 함수 복귀 시, 실제 함수 복귀 어드레스가 스택으로부터 액세스되어야 함을 신호하도록 링크 레지스터 내의 비-실행가능 더미 함수 복귀 어드레스를 이용함으로써, 모드간 호출 분기 명령어 후에 스레드 모드에서 실행될 권한박탈된 코드로부터 실제 함수 복귀 어드레스를 숨길 수 있다.
모드간 함수 복귀 명령어는 더미 함수 복귀 어드레스로의 분기를 야기할 수 있는 다수의 유형들의 명령어 중 하나, 예컨대 분기 명령어, 또는 프로그램 카운터로 하여금 더미 함수 복귀 어드레스에 설정되게 하는 비-분기 명령어(예컨대 레지스터 이동 명령어, 로드 명령어, 또는 스택 팝 명령어)일 수 있다. 따라서, 일부 구현예들에서 이는 모드간 함수 복귀가 수행되어야 하는지, 그리고 따라서 이것이 또한 핸들러 모드로의 전환을 트리거해야 하는지 식별하는 (명령어 디코더보다는) 프로세싱 회로부일 수 있다. 일부 예들에서, 더미 함수 복귀 어드레스를 분기 타겟 어드레스로서 명시하는 경우, 모든 유형들의 분기들은 함수 복귀 프로세싱을 야기할 수 있다. 다른 예들에서, 더미 함수 복귀 어드레스를 분기 타겟 어드레스로서 명시하더라도, 함수 복귀 프로세싱으로 하여금 수행되게 하지 않을 일부 유형들의 분기가 있을 수 있다(예컨대 중간 값을 이용하여 타겟 어드레스를 명시하는 분기들은 함수 복귀 프로세싱으로 하여금 수행되게 하지 않을 수 있는데, 그 이유는 중간 명시 분기 타겟 어드레스는 함수 호출 명령어에 응답하여 저장될 수 없었기 때문에 함수 복귀를 수행할 필요가 없다).
모드간 호출 분기 명령어와 달리, 모드간 함수 복귀 명령어에 대해 도메인 및 모드의 조합된 전환을 허용하는 것이 바람직할 수 있다. 따라서, 모드간 함수 복귀 명령어에 응답하여, 프로세싱 회로부는 제1 보안 도메인 및 스레드 모드에서의 프로세싱으로부터 제2 보안 도메인 및 핸들러 모드에서의 프로세싱으로 도메인/모드 조합 전환을 수행 가능할 수 있다. 이는 꼬리 호출을 지원하는 데 유용할 수 있고, 이는 제2 함수가 제1 함수를 위해 수행된 코드 내의 마지막 작동으로서 호출된 시나리오들에서 일부 컴파일러들에 의해 사용된 성능 최적화이다. 제2 함수는 제1 함수와는 상이한 안전한 도메인에서 프로세싱될 수 있기 때문에, 꼬리 호출을 이용하여 이전에 컴파일된 레거시 코드가 여전히 올바르게 기능할 수 있도록 모드간 함수 복귀 명령어가 도메인/모드 조합 전환을 지원하는 데 유용할 수 있다.
그러나, 일부 경우들에서 제1 보안 도메인이 안전한 도메인이고 제2 보안 도메인이 덜 안전한 도메인인 경우 모드간 함수 복귀 시 도메인/모드 조합 전환이 허가될 수 있지만, 제1 보안 도메인이 덜 안전한 도메인이고 제2 보안 도메인이 안전한 도메인이면 금지될 수 있다. 안전한 도메인으로의 전이를 야기할 경우, 함수 복귀 시 도메인/모드 조합 전환을 금지함으로써, 안전한 도메인으로의 유효 엔트리에 이용가능한 경로들의 수를 감소시킴으로써 보안을 개선할 수 있다.
아래 더 설명되는 바와 같이, 스레드 모드에 있는 동안 안전한 도메인과 덜 안전한 도메인 사이에서의 전이가 디스에이블되는지 아니면 인에이블되는지 나타내기 위한 도메인 전이 디스에이블 구성 값이 제공될 수 있다. 이는 안전한 도메인 또는 덜 안전한 도메인 중 하나와 연관되는 리소스들의 여유로운 할당을 지원하는 데 유용할 수 있다. 종종 예외 핸들러 또는 모드간 호출 분기 명령어를 실행하는 기타 프로세스는 이미 두 도메인에서 동작하는 데 필요한 리소스들을 구성했는지 여부를 알 수 있기 때문에, 모드간 호출 분기 명령어에 응답하여 도메인 전이 디스에이블 구성 값을 설정하는 데 유용할 수 있다. 이는 도메인 전이 디스에이블 구성 값을 설정하기 위하여 별개의 명령어를 실행할 필요성을 피함으로써 성능을 개선한다. 모드간 호출 분기 명령어의 하나 이상의 변형들. 모드간 호출 분기 명령어의 제1 변형에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 도메인 전이 디스에이블 구성 값을 스레드 모드에 있는 동안 안전한 도메인과 덜 안전한 도메인 사이의 전이가 디스에이블됨을 나타내도록 설정할 수 있다. 모드간 호출 분기 명령어의 제2 변형에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 도메인 전이 디스에이블 구성 값을 스레드 모드에 있는 동안 안전한 도메인과 덜 안전한 도메인 사이의 전이가 인에이블됨을 나타내도록 설정할 수 있다. 일부 시스템들은 모드간 호출 분기 명령어의 두 변형을 지원할 수 있다. 다른 시스템들은 모드간 호출 분기 명령어의 제1/제2 변형들 중 하나만을 지원할 수 있다.
모드간 호출 분기 명령어에 응답하여, 프로세싱 회로부의 현재 모드가 스레드 모드일 때 명령어 디코더는 결함의 시그널링을 트리거할 수 있다. 모드간 호출 분기 명령어는 핸들러 모드의 스레드 모드 전이를 야기하기 때문에, 스레드 모드로부터 그것을 실행하는 것은 에러의 표시일 수 있다. 이 경우에 결함을 부각시키는 것은 오용을 방지한다. 예를 들어, 모드간 호출 분기 명령어의 실행이 대응하는 함수 복귀 시 스레드 모드에서 핸들러 모드로의 전이가 이루어져야 함을 나타내는 상태의 저장을 트리거할 수 있기 때문에, 스레드 모드에서 프로세스를 실행하는 공격자가 대응하는 함수 복귀 시 권한을 획득하려는 시도로 모드간 호출 분기 명령어를 이용하는 변조가 있을 수 있다. 이것이 시도되는 경우, 스레드 모드에서 모드간 호출 분기 명령어의 성공적인 실행을 방지하고 결함을 시그널링함으로써, 이런 종류의 공격이 성공하는 것을 방지함으로써 보안을 개선한다.
일반적으로, 함수 복귀 명령어는 호출 분기 명령어에 응답하여 이전에 설정된 함수 복귀 어드레스에 의해 식별되는 명령어로의 분기를 야기하는 임의의 명령어일 수 있다. 모드간 함수 복귀 명령어는 또한 현재 모드에서 스레드 모드로부터 핸들러 모드로의 전환을 트리거하는 특정 유형의 함수 복귀 명령어이다(예컨대 모드간 함수 복귀는 레지스터 또는 메모리에 저장된 정보, 또는 예약된 더미 함수 복귀 어드레스인 분기 타겟에 의한 비-모드간 함수 복귀로부터 구분될 수 있다). 현재 모드가 핸들러 모드일 때 모드간 함수 복귀 명령어를 만나는 경우, 결함이 시그널링될 수 있다. 이는 보안을 개선할 수 있다. 모드간 함수 호출에서 일부 정보는 메모리의 스택 데이터 구조 상의 스택 프레임에 저장될 수 있다. 현재 모드가 핸들러 모드일 때 모드간 함수 복귀가 시도된 경우, 이는 함수 복귀 전이가 그 스택 프레임을 사용하도록 예상되는 의도된 전이가 아니라는 사인일 수 있고, 이는 스택 프레임 상의 정보가 오용되는 경우 보안을 훼손하는 위험이 될 수 있다. 모드간 복귀 분기 명령어가 핸들러 모드에서 실행될 때만 성공하도록 함으로써 이러한 공격에 대한 취약성을 감소시킨다.
프로세서 아키텍처는 호출 분기 명령어들에 응답하여 함수 복귀 어드레스들을 저장하도록 지정된 링크 레지스터를 제공할 수 있다. 링크 레지스터는 또한 범용 레지스터로서 사용가능할 수 있지만, 함수 호출 시, 함수가 완료되고 프로세싱이 분기될 함수 복귀 어드레스를 저장하는 데 사용된다. 모드간 호출 분기 명령어 이외의 적어도 하나의 호출 분기 명령어에 대해, 링크 레지스터는 함수 복귀 어드레스 저장 위치로서 사용될 수 있다. 그러나, 모드간 호출 분기 명령어에 대해, 함수 복귀 어드레스 저장 위치는 메모리에 저장된 스택 데이터 구조 상의 위치일 수 있다. 스택 데이터 구조를 포함하는 메모리의 영역은 스레드 모드에 액세스불가능한 영역일 수 있다(예컨대 메모리 보호 때문에 대응하는 어드레스 영역에 대한 액세스 허가를 정의하는 데이터가 스레드 모드와 연관된 권한의 레벨을 갖는 코드에 액세스가능하지 않음을 나타내고/내거나 스택 데이터 구조를 지목하는 스택 포인터가 스레드 모드에서 액세스불가능한 레지스터에 있기 때문이다). 함수 복귀 어드레스를 링크 레지스터 대신에 스택에 저장함으로써, 모드간 함수 호출 후에 함수 복귀 어드레스가 스레드 모드에서 실행되는 권한박탈된 코드에 노출되는 것을 방지하여, 공격자가 핸들러 모드에서 실행되는 더 권한부여된 코드의 동작에 관련된 정보를 열람하거나 변경할 기회를 감소시킴으로써 보안을 개선한다.
위에서 언급된 바와 같이, 모드간 호출 분기 명령어에 응답하여 더미 함수 복귀 어드레스는 링크 레지스터에 저장될 수 있다. 그러나, 주의해야 할 점은 대응하는 함수 복귀 명령어가 더미 함수 복귀 어드레스로 분기하려고 시도하는 시점에서, 이 더미 함수 복귀 어드레스는 링크 레지스터에 더이상 저장되지 않을 수 있다는 것이다. 일부 컴파일러들은 더미 함수 복귀 어드레스가 링크 레지스터에 유지되도록 코드를 생성할 수 있고, 다른 함수가 이전에 호출된 함수 안에 삽입된 경우, 컴파일된 코드는 더미 함수 복귀 어드레스를 메모리의 스택에 저장할 수 있고, 이어서 삽입된 함수가 완료되면, 더미 함수 복귀 어드레스를 링크 레지스터로 복원하여, 제1 함수로부터 복귀하는 시점에 더미 함수 복귀 어드레스가 한 번 더 링크 레지스터에 있도록 한다. 그러나, 이는 필수적인 것은 아니다. 다른 컴파일러들은 삽입된 함수 호출로부터 복귀 시 더미 함수 복귀 어드레스를 링크 레지스터로 복원하지 않는 코드를 컴파일할 수 있지만, 대신 대응하는 함수 복귀가 요구될 때 더미 함수 복귀 어드레스를 직접 스택으로부터 프로그램 카운터 레지스터로 로딩하여, 스택으로부터 획득될 실제 함수 복귀 어드레스를 요구함에 따라 검출될 수 있는 더미 함수 복귀 어드레스로의 분기를 효과적으로 야기함으로써 대신 성능을 개선한다. 따라서, 함수 복귀의 시점에 더미 함수 복귀 어드레스가 여전히 링크 레지스터에 저장되어 있을 필요는 없다. 유의할 점은, 함수 호출의 네스팅을 인에이블하기 위하여 더미 함수 복귀 어드레스가 스택에 저장되는 경우에, 더미 함수 복귀 어드레스를 저장하는 데 사용되는 스택은 모드간 호출 분기 명령어가 실행될 때 실제 함수 복귀 어드레스를 저장하는 데 사용되는 스택 데이터 구조와는 상이한 스택 데이터 구조일 수 있다. 예를 들어 모드간 호출 분기 명령어에 응답하여 실제 함수 복귀 어드레스를 저장하는 데 사용되는 스택은 핸들러 모드와 연관된 메인 스택일 수 있지만, 스레드 모드에서 실행 중인 권한박탈된 코드 내에 함수 호출의 네스팅이 있는 경우, 이전의 링크 레지스터 내의 더미 함수 복귀 어드레스는 스레드 모드와 연관된 프로세스 스택 데이터 구조에 저장될 수 있다.
더미 함수 복귀 어드레스는 대응하는 함수 복귀가 시도될 때 동작을 제어하기 위한 다양한 종류의 정보를 포함할 수 있다. 예를 들어 더미 함수 복귀 어드레스는 다음 중 적어도 하나를 나타낼 수 있다: 스레드 모드에서 핸들러 모드로의 전환이 더미 함수 복귀 어드레스로 분기하려고 시도하는 명령어에 응답하여 요청되어야 하는지 여부; 프로세싱 회로부의 현재 안전한 도메인에서의 전환이 더미 함수 복귀 어드레스로 분기하려고 시도하는 명령어에 응답하여 요청되어야 하는지 여부; 및 복수의 스택 데이터 구조들 중 어느 것이 함수 복귀 어드레스가 더미 함수 복귀 어드레스로 분기하려고 시도하는 상기 명령어에 응답하여 획득되는 스택 데이터 구조로서 사용되어야 하는지 여부. 따라서, 함수 복귀 시 프로세싱 회로부는 더미 함수 복귀 어드레스의 정보를 이용하여 모드 전환 여부, 도메인 전환 여부를 결정하고/하거나 함수 복귀 어드레스를 획득하는 데 어느 스택 데이터 구조를 사용할지 결정할 수 있다. 일부 예들에서 더미 함수 복귀 어드레스는 2비트를 이용하여 이러한 3가지 정보를 나타낼 수 있다: 제1 비트는 더미 함수 복귀 어드레스가 모드간 호출 분기 명령어에 응답하여 설정되었는지 여부를 나타내고, 제2 비트는 모드간 함수 호출이 만들어진 안전한 도메인을 나타냄. 어느 스택 데이터 구조가 사용되어야 하는지는 이 2비트로부터 추론될 수 있어서, 명시적 표시를 필요로 하지 않을 수 있다. 그러나, 이는 단지 더미 함수 복귀 어드레스 내의 정보를 인코딩하는 한가지 방법이고 다른 접근법들은 상이한 옵션을 취할 수 있음이 이해될 것이다. 또한 일부 구현예들은 전술된 3가지 유형의 정보를 모두 나타내지 않을 수 있다.
더미 함수 복귀 어드레스의 사전결정된 부분은 프로세싱 회로부의 현재 안전한 도메인에서의 전환이 더미 함수 복귀 어드레스로 분기하려고 시도하는 명령어에 응답하여 요청되어야 하는지 나타낼 수 있다. 예를 들어, 이 사전결정된 부분은 더미 함수 복귀 어드레스의 최하위 비트일 수 있다. 현재 안전한 도메인이 덜 안전한 도메인일 때 보안 게이트웨이 명령어에 응답하여, 프로세싱 회로부는 복귀 어드레스(예컨대 링크 레지스터 내의 어드레스)의 일부분을 덜 안전한 상태를 나타내는 값으로 설정할 수 있고, 그 부분은 복귀 어드레스 값 내에서, 더미 함수 복귀 어드레스 내의 도메인의 전환을 나타내는 부분과 동일한 상대적 위치에 있다. 이 접근법은 안전한 코드 내의 대응하는 복귀 분기를 덜 안전한 도메인 내의 어드레스로 복귀하는 대신에 안전한 도메인 내의 임의의 위치로 점프하게 하려는 시도로, 덜 안전한 도메인으로부터 안전한 함수를 호출 시 안전한 코드에 위조 복귀 어드레스를 전달하는 덜 안전한 코드에 기초한 공격들을 완화함으로써 보안을 개선하도록 돕는다. 보안 게이트웨이 명령어는 덜 안전한 도메인으로부터 실행될 때 덜 안전한 도메인에서 안전한 도메인으로의 전환을 트리거하는 명령어일 수 있고, 덜 안전한 도메인에서 명령어들을 실행한 후에 안전한 도메인에서 페치된 제1 명령어가 보안 게이트웨이 명령어가 아닌 경우, 프로세싱 회로부는 결함의 시그널링을 트리거할 수 있다. 따라서, 보안 게이트웨이 명령어는 유효 엔트리 시점에 안전한 도메인 내에 존재하도록 예상될 수 있고, 따라서, 안전한 도메인 내의 임의의 어드레스로 분기를 야기하기 위하여 복귀 어드레스가 신뢰될 수 없음을 나타내도록, 안전한 도메인에 진입하는 시점에 덜 안전한 코드에 의해 설정된 복귀 어드레스를 갱신할 수 있다. 덜 안전한 상태를 나타내는 값으로 설정된 부분을 갖는 어드레스를 분기 타겟 어드레스로서 명시하는 사전결정된 유형의 분기 명령어가 안전한 도메인에서 실행되면, 타겟 어드레스가 메모리 내의 안전한 영역에 대응하는지 아니면 덜 안전한 영역에 대응하는지 여부에 상관없이 프로세싱 회로부로 하여금 덜 안전한 도메인으로 다시 전환되게 한다. 따라서, 안전한 코드는 덜 안전한 도메인에 의해 제어되는 분기 타겟 어드레스를 사용할 것으로 예상되는 분기들에서 사전결정된 유형의 분기 명령어를 포함하도록 기록될 수 있고, 그럼으로써 위에서 논의된 유형의 공격으로부터 보호를 제공한다. 모드간 함수 복귀 분기들은 유사한 공격의 위험에 있을 수 있으므로, 그 부분이 보안 게이트웨이 명령어에 응답하여 덜 안전한 상태를 나타내는 값으로 설정된 복귀 어드레스의 부분과 동일한 상대적 위치에서 안전한 도메인의 전환이 요청되는지 여부를 신호하는 데 사용되도록 더미 함수 복귀 어드레스를 인코딩함으로써, 또한 공격으로부터 모드간 함수 복귀 분기들을 보호한다.
링크 레지스터는 스레드 모드에서 실행되는 코드에 액세스가능한 레지스터일 수 있다. 따라서, 링크 레지스터에 저장된 더미 함수 복귀 어드레스를 이용하여 대응하는 함수 복귀가 모드간 호출로서 처리되어야 하는지 여부를 나타내는 정보를 제공하는 것이 편리하지만, 더미 함수 복귀 어드레스에 배치된 정보는 스레드 모드를 실행하는 덜 권한부여된 코드에 의해 수정되는 데 취약할 수 있다. 더미 함수 복귀 어드레스의 악의적인 수정에 기초한 공격으로부터 보호하기 위하여, 모드간 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 스택 데이터 구조에 저장되는 스택 프레임 내의 제1 상대적 위치의 적어도 일부에 크로스-체킹 값을 저장할 수 있다. 크로스-체킹 값이 저장되는 스택 데이터 구조는 스레드 모드에서 실행되는 코드에 액세스불가능한 스택일 수 있다. 어드레스의 더미 함수로 분기하려고 시도하는 적어도 하나의 유형의 명령어에 응답하여, 프로세싱 회로부는 모드간 호출 표시 값을 인코딩하기 위한 더미 함수 복귀 어드레스의 일부분과 스택 데이터 구조로부터 획득된 스택 프레임 내의 제1 상대적 위치의 적어도 일부의 값을 비교하고, 비교에 기초하여 결함의 시그널링을 트리거할 지 결정할 수 있다. 따라서, 더미 함수 복귀 어드레스는 스택 데이터 구조 상의 스택 프레임에 액세스하는 것이 조금이라도 필요한 지 여부를 신호할 수 있지만, 스택 프레임 내의 크로스-체킹 값은 함수 복귀 시 모드의 변경을 나타내는 임의의 정보가 신뢰될 수 있는지 이중 체크를 제공하여, 보안을 증진할 수 있다. 보안 도메인 표시를 위하여 더미 함수 복귀 어드레스에 유사한 체크가 이루어질 수 있다.
모드간 호출 분기 명령어 이외의 적어도 하나의 유형의 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 크로스-체킹 값 이외의 값을 스택 데이터 구조에 저장된 스택 프레임 내의 제1 상대적 위치의 적어도 일부분에 저장할 수 있다. 따라서, 크로스-체킹은 또한 비-모드간 호출 분기 명령어를 통해 들어간 코드로부터 복귀하기 위한 메커니즘으로서 모드간 함수 복귀를 사용하려고 시도하는 공격으로부터 보호할 수 있다. 이러한 유형의 미스매칭된 함수 호출 및 함수 복귀는 메모리 내의 스택 프레임들의 미스매칭에 기초한 취약성을 야기할 수 있다. 따라서, 모드간 함수 복귀를 나타내기 위한 더미 함수 복귀 어드레스를 수정하려는 시도가 이루어지지만, 메모리 내의 대응하는 스택 데이터 구조는 실제로 비-모드간 호출 분기 명령어에 의해 메모리에 저장된 경우, 크로스-체크는 실패할 것이고 그럼으로써 결함이 트리거될 수 있다.
모드간 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 핸들러 모드를 나타내는 값을 스택 데이터 구조에 저장된 스택 프레임 내의 제2 상대적 위치의 적어도 일부분에 저장할 수 있다. 제2 상대적 위치는 제1 상대적 위치와 동일한 어드레스일 수 있거나(이 경우 모드간 호출 표시 값 및 핸들러 모드를 나타내는 값에 대한 크로스 체킹 정보는 스택 상의 동일한 데이터 워드 내의 비트들의 상이한 부분들에 있을 수 있음), 또는 제1 상대적 위치에 대하여 상이한 어드레스에 대응하는 스택 프레임 내의 상이한 상대적 오프셋이 있을 수 있다. 더미 함수 복귀 어드레스가 모드간 호출 표시 값을 포함할 때 더미 함수 복귀 어드레스로 분기하려고 시도하는 적어도 하나의 유형의 명령어에 응답하여, 프로세싱 회로부는 스택 프레임 내의 제2 상대적 위치의 관련 부분 내의 값이 핸들러 모드를 나타내지 않을 때 결함의 시그널링을 트리거할 수 있다. 따라서, 더미 함수 복귀 어드레스가 스레드 모드에서 핸들러 모드로의 함수 복귀를 나타내지만, 메모리 내의 스택 프레임은 대응하는 함수 호출이 원래 핸들러 모드로부터 기인되지 않았음을 나타내는 경우, 결함이 트리거될 수 있다. 다시 이는 일부 형태들의 공격으로부터 보호한다.
일부 구현예들은 제1 상대적 위치에서의 크로스-체킹 값 및 스택 상의 제2 상대적 위치에서의 핸들러 모드 표시 값 둘 모두를 제공할 수 있다. 다른 구현예들은 이러한 유형들의 크로스-체크 중 하나를 생략할 수 있고 단지 크로스-체킹 값 또는 핸들러 모드 표시 값만을 제공할 수 있다.
더미 함수 복귀 어드레스가 모드간 호출 표시 값을 포함할 때 더미 함수 복귀 어드레스로 분기하려고 시도하는 적어도 하나의 유형의 명령어에 응답하여, 프로세싱 회로부는 스택 데이터 구조로부터 획득된 함수 복귀 어드레스의 체크를 수행할 수 있다. 프로세싱 회로부의 현재 모드로부터 핸들러 모드로의 전환 전에, 프로세싱 회로부는 스택 데이터 구조로부터 획득된 함수 복귀 어드레스가 명령어 실행이 금지된 예약된 어드레스들의 사전결정된 범위 내에 있는지 체크할 수 있다. 함수 복귀 어드레스가 예약된 어드레스들의 사전결정된 범위 내에 있을 때, 스레드 모드를 실행하는 프로그램 코드에 귀속된 결함이 트리거될 수 있다. 이러한 유형의 체크가 유용할 수 있는데, 그 이유는 모드간 호출 분기 명령어가 실행될 때 함수 복귀 어드레스는 스택 데이터 구조에 저장된 스택 프레임 내의 제3 상대적 위치에 저장될 수 있고, 예외 조건에 의해 트리거된 적어도 하나의 유형의 예외 전이에 대해, 예외 제어 회로부는 스택 프레임 내의 제3 상대적 위치에 저장된 예약된 어드레스들의 사전결정된 범위 중 하나를 포함하는 스택 프레임을 저장할 수 있다. 따라서, 모드간 함수 복귀 시 함수 복귀 어드레스가 사전결정된 범위의 예약된 어드레스들 중 하나인지 여부를 체크함으로써, 실제로 함수 호출 전이가 아니라 예외 엔트리 전이에 응답하여 저장된 스택 프레임에 기초하여 함수 복귀를 수행하려는 시도에 기초한 공격으로부터 보호하고, 그렇지 않으면 이는 보안을 훼손하는 예측불가능한 결과들을 초래할 수 있다. 함수 복귀 어드레스의 체크는 또한 다른 유형들의 공격을 방지하도록 도울 수 있다. 예를 들어 스택의 시작이 스택 프레임 내의 제3 상대적 위치에서 (사전결정된 범위의 예약된 어드레스들로부터의) 다른 예약된 값으로 밀봉되는 경우, 스택을 언더플로우(즉 스택이 비어 있을 때 스택 프레임을 사용)하려는 시도는 또한 검출되고 결함을 신호할 것이다.
함수 복귀 어드레스가 모드간 함수 복귀 명령어에 대한 체크의 일부로서 예약된 어드레스들의 범위 내에 있는지 여부를 체크하는 것은 중복으로 보일 수 있는데, 이는 사전결정된 범위의 예약된 어드레스들로부터의 명령어를 실행하려는 시도에 의해 야기된 결함들은 명령어가 예약된 어드레스들 중 하나로부터 페치되도록 시도되는 시점에 트리거될 것이라고 예상할 것이기 때문이다. 그러나, 발명자는, 모드간 함수 복귀의 경우, 모드가 핸들러 모드로 전환되도록 모드간 함수 복귀가 성공적으로 완료하도록 허용되고, 이어서 함수 복귀 어드레스로부터 다음 명령어를 페치하려고 시도 시 결함이 순차적으로 트리거되는 경우, 이 결함은, 핸들러 모드로 전환되기 전에 스레드 모드에서 실행되는 프로그램 코드보다는, 핸들러 모드에서 실행되는 코드에 귀속될 수 있음을 알게 되었다. 이는 문제가 될 수 있는데, 그 이유는 핸들러 코드가 운영 체제와 연관될 수 있어서, 이 결함은 운영 체제 동작이 결함이 있는 것으로 의심받게 할 수 있고, 이는 전체 시스템 리셋과 같은 상대적으로 공격적인 행위가 수행되게 요구할 수 있다. 따라서, 이 접근법으로, 공격자가 (반복적으로 예외 스택 프레임들에 기초하여 함수 복귀를 트리거함으로써) 프로세싱 시스템의 올바른 기능을 방해하는 것을 목적으로 하는 서비스 거부 공격을 수행하는 방법을 제공할 수 있다.
대조적으로, 함수 복귀 어드레스가 (스레드 모드에서 핸들러 모드로의 임의의 모드 전환을 트리거하기 전) 모드간 함수 복귀 명령어를 프로세싱하는 시점에 예약된 범위의 어드레스들 내에 있는지 여부를 조기 체크하는 본 명세서에 기재된 접근법을 이용하면, 결함은 스레드 모드 코드에 귀속될 수 있고 따라서 결함 핸들링 동작은 시스템 기능에 훨씬 적게 영향을 미칠 수 있고(예를 들어, 단일 스레드를 죽이고 재시작하는 정도), 서비스 거부 공격의 기회를 감소시키고 그럼으로써 보안을 개선한다.
신뢰성 및 안전성 목적을 위해, 일부 구현예들은 하드웨어 결함 또는 임시 결점들에 의해 야기된 일시적 또는 영구적 에러들을 검출하기 위한 에러 검출/교정 회로부를 가질 수 있다. 예를 들어, 에러 검출/교정 회로부는 레지스터들 또는 메모리에 저장된 데이터의 에러들을 검출하기 위하여 에러 검출/교정 코드를 이용하는 회로부를 포함할 수 있으며, 에러들은 예를 들어 입자 충돌에 의해 또는 저장 소자가 0 또는 1로 고착됨으로써 야기될 수 있다. 에러 검출/교정 회로부는 또한 동일한 동작을 2회 이상 수행하여 에러들이 이 동작들의 중복 결과물들의 비교로부터 검출될 수 있도록 하는 중복 프로세싱 로직을 포함할 수 있다. 에러 검출/교정 회로부의 특정 형태는 그 시스템의 필요에 따라 시스템마다 현저하게 달라질 수 있다. 전술한 서비스 거부 공격 시나리오와 유사한 이유로, 검출된 임의의 에러들을 특정 데이터 프로세싱 컨텍스트에 귀속시킬 수 있는 것이 유용할 수 있고, (예를 들어 에러가 실제로 특정 스레드와 연관된 데이터 프로세싱 내에서 발생한 경우에 운영 체제를 죽이고 침입적인 시스템 리셋을 수행할 필요성을 피함으로써) 에러의 해결책을 더 효율적으로 만들 수 있다.
에러들의 분리를 가능하게 하기 위해, 모드간 호출 분기 명령어에 응답하여 명령어 디코더는 프로세싱 회로부를 제어하여 에러 동기화 차단 동작을 수행하여 에러 동기화 차단 동작 전에 수행된 데이터 프로세싱과 연관된 에러들의 검출을 에러 동기화 차단 동작 후에 수행된 데이터 프로세싱과 연관된 에러들의 검출로부터 분리할 수 있다. 유사하게, 모드간 함수 복귀 명령어의 경우, 이는 또한 에러 동기화 차단 동작을 트리거할 수 있다. 예를 들어 에러 동기화 차단 동작은 임의의 미처리된 동작들이 완료되고 에러 동기화 차단 동작 전에 수행된 임의의 동작들에 대한 임의의 에러 체킹의 결과들이 이용가능하고 조기 프로세싱의 결과물들이 올바른지 여부가 알려질 때까지 프로세싱이 중단되는 것을 포함할 수 있다. 따라서, 이는 발생하는 임의의 에러들이 에러가 발생한 특정 코드에 더 정확히 지목되도록 한다. 일부 시스템들에서, 모드간 호출 분기 명령어 및 모드간 함수 복귀 명령어는 항상 에러 동기화 차단 동작을 트리거할 수 있다. 다른 시스템들(예를 들어 신뢰성/안전성 에러 체크 회로부 중 어느 하나도 갖지 않은 것들)은 에러 동기화 차단 동작을 지원하지 않을 수 있다. 다른 예들에서, 모드간 호출 분기 명령어 및 모드간 함수 복귀 명령어가 에러 동기화 차단 동작을 트리거하는지 여부를 제어하는 일부 구성 상태 데이터가 제공될 수 있다. 에러 동기화 차단 동작들의 존재를 소프트웨어에 의해 구성되도록 함으로써, 단일 칩이, 예를 들어 성능이 에러 격리보다 더 중요하거나 또는 그 반대인, 다양한 시장의 요구를 더 잘 해결할 수 있다.
일부 구현예들은 안전한 도메인 당 프로세스 스택 포인터 레지스터 및 안전한 도메인 당 메인 포인터 레지스터를 포함하는 둘 이상의 스택 포인터 레지스터들을 제공할 수 있다(오직 하나의 안전한 도메인을 구비한 시스템들에는, 단일 프로세스 스택 포인터 레지스터 및 단일 메인 스택 포인터 레지스터만이 있을 수 있지만, 다수의 안전한 도메인들을 지원하는 시스템들에는 스택 포인터 레지스터들이 안전한 도메인마다 구축될 수 있다). 선택 회로부는, 각각의 안전한 도메인에 대하여, 메모리 내의 스택 데이터 구조에 액세스하기 위하여 스택 포인터를 제공하는 데 어느 스택 포인터 레지스터가 사용되어야 하는지 선택할 수 있다. 핸들러 모드에서 선택 회로부는 현재 안전한 도메인에 대하여 메인 스택 포인터 레지스터를 선택할 수 있다. 스레드 모드에서, 선택 회로부는 현재 도메인에 대한 스택 포인터 선택 값에 기초하여 현재 도메인에 대하여 메인 스택 포인터 레지스터와 프로세스 스택 포인터 레지스터 사이에서 선택할 수 있다. 핸들러 모드 및 스레드 모드 각각에 대한 별개의 메인 및 프로세스 스택들의 공급은 예외 핸들러 코드의 개발을 더 단순하게 만들 수 있는데, 그 이유는 예외 핸들러들이 메인 스택 데이터 구조 상에 남겨놓는 임의의 데이터는 일반적으로 예외 복귀 후에 스레드 모드에서 실행되는 스레드에 액세스가능하지 않게 되기 때문이다. 일부 구현예들에서, 스레드 및 핸들러 모드에 대하여 별개의 스택을 이용하는 것은 또한 거짓 예외 복귀 스택 프레임들의 위조에 기초한 특정 유형들의 공격들로부터 보호하는 데 도움을 줄 수 있다. 그러나, 일부 시나리오들에서(예를 들어 제한된 이용가능한 메모리가 있는 경우) 별개의 프로세스 스택를 이용하는 스레드 모드 대신에, 스레드 모드 코드가 메인 스택 포인터에 의해 식별된 메인 스택을 핸들러 모드와 공유하도록 허용하는 것이 바람직할 수 있다. 따라서 스레드 모드에서 어느 스택이 사용되어야 하는지 정의하기 위하여 스택 포인터 선택 값이 제공될 수 있다(더 권한부여된 코드에 의해 제어됨).
모드간 호출 분기 명령어에 응답하여, 명령어 디코더는 프로세싱 회로부를 제어하여 현재 안전한 도메인에 대한 스택 포인터 선택 값을 설정하여 스레드 모드에 있을 때 프로세스 스택 포인터 레지스터가 선택되어야 함을 나타낼 수 있다. 이는 모드간 함수 호출 후에 실행되는 예외 핸들러의 권한박탈된 섹션이 더 권한부여된 코드가 메인 스택 구조에 남아 있을 수 있는 정보에 액세스하는 것을 방지하여, 보안을 개선할 수 있다.
호스트 데이터 프로세싱 장치를 제어하여 타겟 프로그램 코드로부터의 명령어들의 실행을 위한 명령어 실행 환경을 제공하기 위하여 시뮬레이터 컴퓨터 프로그램이 제공될 수 있다. 컴퓨터 프로그램은 전술된 프로세싱 회로부, 예외 제어 회로부 및 명령어 디코더의 기능을 모방하는 프로세싱 프로그램 로직, 예외 제어 프로그램 로직 및 명령어 디코딩 프로그램 로직을 가질 수 있다. 이는 전술된 바와 같이 모드간 호출 분기 명령어에 대한 지원을 포함한다. 따라서, 이러한 시뮬레이터 컴퓨터 프로그램은, 시뮬레이터 컴퓨터 프로그램 상에서 실행될 타겟 코드에 대하여, 시뮬레이터 컴퓨터 프로그램을 실행하는 호스트 컴퓨터에 이러한 특징부들을 제공하는 어떠한 실제 하드웨어도 존재하지 않을 수 있더라도, 실제 하드웨어 장치에 의해 제공될 것과 유사한 명령어 환경을 제시할 수 있다. 이는 실제로 그 아키텍처를 지원하지 않는 호스트 플랫폼 상에서 하나의 명령어 세트 아키텍처에 대하여 기록된 코드를 실행하는 데 유용할 수 있다. 또한, 시뮬레이터는 새로운 버전의 명령어 세트 아키텍처를 위한 소프트웨어의 개발 동안 유용할 수 있는데, 소프트웨어 개발이 새로운 버전의 명령어 세트 아키텍처를 지원하는 하드웨어 디바이스들의 개발과 병렬로 수행될 때, 새로운 버전의 명령어 세트 아키텍처를 지원하는 하드웨어 디바이스들이 준비되기 전에 소프트웨어 개발이 시작할 수 있도록 개발중인 소프트웨어가 시뮬레이션 상에서 테스트될 수 있다.
도메인 전이 디스에이블 구성 파라미터
위에서 언급된 바와 같이, 프로세싱 회로부는 적어도 안전한 도메인 및 덜 안전한 도메인을 포함하는 다수의 안전한 도메인들을 가질 수 있고, 프로세싱 회로부의 현재 안전한 도메인에 따라 메모리 액세스가 허용되는지 여부를 체크하기 위한 메모리 액세스 체크 회로부가 제공될 수 있다. 예를 들어 이러한 메모리 액세스 체킹은 메모리 영역들이 안전한 지 아니면 덜 안전한 지 정의하는 속성 데이터에 기초할 수 있고, 덜 안전한 도메인에서 동작할 때 안전한 영역들에 대한 액세스는 금지될 수 있다.
적어도 하나의 모드에서 프로세싱 회로부에서, 안전한 도메인과 덜 안전한 도메인 사이의 도메인 전이가 인에이블되는지 아니면 디스에이블되는지 명시하는 도메인 전이 디스에이블 구성 파라미터를 저장하기 위한 제어 저장 위치가 제공될 수 있다. 적어도 하나의 모드에서, 도메인 전이 디스에이블 구성 파라미터가 도메인 전이가 디스에이블된다고 명시하면, 프로세싱 회로부는 안전한 도메인에서 덜 안전한 도메인으로 전이하려는 시도에 응답하여 디스에이블된 도메인 전이 결함의 시그널링을 트리거할수 있고, 덜 안전한 도메인으로부터 안전한 도메인으로 전이하려는 시도에 응답하여 디스에이블 도메인 전이 결함의 시그널링을 트리거할 수 있다. 이 접근법은 직관에 반할 수 있는데, 그 이유는, 보안상의 이유로 덜 안전한 도메인에서 안전한 도메인으로의 전이를 방지할 수 있는 것이 유용할 수 있다고 예상할 수 있는데, 안전한 도메인에서 덜 안전한 도메인으로의 전이를 선택적으로 디스에이블하는 것이 왜 유용한 지 궁금해 할 수 있기 때문이다. 그러나, 발명자는 이것이 특정 스레드의 프로세싱을 안전한 도메인 및 덜 안전한 도메인 중 단일 도메인에 포함시키는 방법을 제공한다는 것을 인식하였는데, 이는 성능이 우수할 수 있는데, 그 이유는 도메인들을 전환하려는 시도가 디스에이블 도메인 전이 결함을 트리거할 것이라고 알려진다면, 스레드가 두 도메인들에 걸치는 경우 필요할 수 있는 성능 집약적 동작들의 일부가 억제될 수 있기 때문이다. 이어서 이 성능 집약적 동작들이 천천히 수행되도록 허용하는데, 도메인들을 전환하려는 시도가 있을 때 필요한 경우에만 수행되어, 스레드들이 도메인들에 걸칠 지 여부에 상관없이 모든 스레드들에 대하여 투기적으로 이 동작들을 수행하는 성과 비용을 피한다. 따라서, 프로세싱 회로부가 적어도 하나의 모드에 있을 때 안전한 도메인과 덜 안전한 도메인 사이의 전이를 양 방향에서 디스에이블하는 도메인 전이 디스에이블 구성 파라미터의 제공은 성능 상 유익할 수 있다.
이 기술은 안전한 도메인에서 프로세싱 회로부가 적어도 하나의 안전한 구성 레지스터에 저장된 정보를 이용하여 메모리에 대한 액세스를 제어하고, 덜 안전한 도메인에서 프로세싱 회로부가 적어도 하나의 덜 안전한 구성 레지스터에 저장된 정보를 이용하여 메모리에 대한 액세스를 제어하는 경우에 특히 유용할 수 있다. 예를 들어 안전한/덜 안전한 구성 레지스터들은 각각의 안전한 또는 덜 안전한 스택 데이터 구조들에 액세스하기 위한 스택 포인터들을 메모리 내에 저장하는 스택 포인터 레지스터들, 메모리의 영역들에 대한 액세스 허가를 정의하기 위한 메모리 보호 속성들을 정의하는 메모리 보호 유닛(MPU) 내의 레지스터들, 및/또는 메모리 보호 영역 속성들을 제공하는 메모리 내의 테이블에 포인터를 제공하는 MPU 포인터 레지스터들을 포함할 수 있다. 안전한 도메인과 덜 안전한 도메인 사이의 분리를 보장하기 위해, 안전한 도메인 및 덜 안전한 도메인 각각에 의한 사용을 위한 MPU 속성들의 별개의 세트들 또는 스택 데이터 구조들을 정의하는 것이 바람직할 수 있다. 그러나, 스택 포인터들을 구성하고, 스택 데이터 구조들을 위하여 메모리 어드레스 공간에 공간을 할당하고/하거나 안전한 도메인 및 덜 안전한 도메인을 위하여 MPU 영역 속성들을 구성하기 위한 동작들은 상대적으로 성능 집약적일 수 있고, 따라서 안전한 도메인 및 덜 안전한 도메인 중 하나에 대한 이 동작들을 다른 도메인에서만 동작해야 하는 스레드를 위하여 수행하는 것을 피하는 것이 바람직할 수 있다. 이는 인터럽트 핸들링과 같은 시간이 중요한 동작들이 수행되어야 할 때 특히 중요할 수 있다. 따라서, 도메인 전이 디스에이블 구성 파라미터를 제공함으로써, 이 구성 동작들이 수행하지 않은 스레드가 다른 도메인으로 전환하려고 시도하는 경우들을 검출하는 데 사용될 수 있는 결함을 제공하여, 이 구성 동작들이 요구 시 느리게 수행될 수 있도록 할 수 있다. 일 예에서, 구성된 리소스들은 안전한 도메인과 연관된 적어도 하나의 스택 포인터 레지스터 및 덜 안전한 도메인과 연관된 적어도 하나의 스택 포인터 레지스터를 포함하는, 스택 데이터 구조들을 지목하기 위한 스택 포인터들을 저장하는 스택 포인터 레지스터들을 포함할 수 있다.
적어도 하나의 모드에서 덜 안전한 도메인으로부터 안전한 도메인으로의 적어도 하나의 유형의 전이를 수행하려는 시도에 응답하여, 프로세싱 회로부는 디스에이블된 도메인 전이 결함의 시그널링을 트리거할 지 여부를 결정하기 위하여 도메인 전이 디스에이블 구성 파라미터를 이용하여 디스에이블된 도메인 전이 체킹을 수행할 수 있다. 이 디스에이블된 도메인 전이 체킹은, 덜 안전한 도메인으로부터 안전한 도메인으로 전이하려는 시도에 대하여, 덜 안전한 도메인으로부터 안전한 도메인으로 전이하려는 시도가 허용되는지 결정하기 위한 적어도 하나의 다른 보안 체크를 수행하기 전에 수행될 수 있다. 적어도 하나의 다른 보안 체크의 적어도 일부는 도메인들을 전환하는 것이 예상되지 않은 스레드에 대하여 아직 구성되지 않은 정보 또는 리소스들, 예컨대, 스택 포인터 레지스터들에 의해 참조되는 MPU 구성 또는 스택 데이터 구조들에 따라 달라질 수 있는 것이 가능하다. 따라서, 디스에이블된 도메인 전이 체킹 전에 다른 보안 체크가 수행되는 경우, 이는 쉽게 보안 체크 실패로 이어질 수 있는데, 그 이유는 일부 다른 보안 위험이 식별되어서가 아니라, 체크할 관련 데이터가 아직 구성되지 않았기 때문이다. 보안 체크는 디스에이블된 도메인 전이 결함과 연관된 결함 핸들러(이는 단지 리소스들의 지연 구성만을 트리거할 수 있음)보다 더 과감한 행동을 트리거하는 결함 핸들러와 연관될 수 있기 때문에, 디스에이블된 도메인 전이 체킹을 먼저 수행하여, 만약 리소스들이 이용가능하지 않은 경우 계속하기 전에 다른 유형의 보안 체크를 수행하도록 구성될 수 있도록 하는 것이 바람직할 수 있다. 예를 들어, 일부 구현예들은 체크가 실패한 경우, 보안 결함이 부상되도록 하는 보안 체크를 수행할 수 있다. 보안 상태의 무결성을 보장하기 위해, 보안 결함과 연관된 예외 핸들러는 전체 덜 안전한 상태의 실행을 종료할 수 있다. 이러한 결함은 덜 안전한 상태에서 실행되는 운영 체제 상에서 서비스 거부 공격을 수행하기 위한 수단으로서 덜 안전하고 덜 권한부여된 상태에서 실행되는 소프트웨어에 의해 고의적으로 트리거될 수 있다.
안전한 도메인으로부터 덜 안전한 도메인으로 시도된 전이에 대해, 디스에이블된 도메인 전이 체킹은 또한 도메인 전이 디스에이블 구성 파라미터를 이용하여 수행될 수 있다. 그러나, 이러한 전이는 안전한 도메인에서 덜 안전한 도메인으로 이루어짐에 따라, 다른 보안 체크를 수행할 필요하지 않을 수 있고, 디스에이블된 도메인 전이 체킹과 다른 보안 체크 사이의 순서는 관련이 없을 수 있다. 대안적으로, 일부 시스템들은 안전한 도메인에서 덜 안전한 도메인으로 복귀 시 여전히 보안 체크를 수행할 수 있고, 이 경우 디스에이블된 도메인 전이 체킹과 다른 보안 체크 사이의 순서는 디스에이블된 도메인 전이 결함에 응답하여 구성된 임의의 정보가 다른 보안 체크에 사용되도록 예상되는지 여부에 따라 달라질 수 있다.
디스에이블된 도메인 전이 체킹은 덜 안전한 도메인에서 안전한 도메인으로 또는 안전한 도메인에서 덜 안전한 도메인으로의 적어도 하나의 유형의 전이를 수행하려는 시도에 의해 트리거될 수 있다. 때때로, 디스에이블된 도메인 전이 체킹은 반드시 실제로 안전한 도메인과 덜 안전한 도메인 사이의 전이를 야기하지 않을 수 있는 이벤트 또는 명령어에 의해 트리거될 수 있다. 예를 들어, 일부 경우들에서 디스에이블된 도메인 전이 체킹은 잠재적으로 보안 도메인들 사이의 전이를 야기할 수 있는 이벤트 또는 명령어가 발생할 때, 그러나 이벤트 또는 명령어가 실제로 도메인들의 변경을 트리거하는지 여부가 식별되는 시점 전에 수행될 수 있다. 따라서, 도메인 전이 디스에이블 구성 파라미터가 도메인들을 변경하려는 실제 시도에 응답하여 적어도 체크되는 동안, 디스에이블된 도메인 전이 체킹이 통과되고 도메인 전이가 인에이블될 것이라고 결정하는 경우 실제로 도메인의 변경을 야기하지 않을 이벤트들에서 또한 때때로 체크될 수 있는 것을 배제하지 않는다.
도메인 전이 디스에이블 구성 파라미터는 안전한 도메인 및 덜 안전한 도메인 둘 모두에서 수정가능할 수 있다. 일부 구현예들에서, 특정 프로그램 코드가 도메인 전이 디스에이블 구성 파라미터를 수정하도록 허용되는지 여부에 대하여 다른 조건들이 또한 부과될 수 있다. 예를 들어, 권한부여된 상태 및 덜 권한부여된 상태를 갖는 시스템들에서 도메인 전이 디스에이블 구성 파라미터는 권한부여된 상태에서만 수정가능할 수 있다. 그럼에도 불구하고, 프로세싱 회로부는 현재 안전한 도메인이 덜 안전한 도메인인 경우에도 도메인 전이 디스에이블 구성 파라미터를 수정하도록 허용될 수 있다. 이는 반직관적으로 보일 수 있는데, 그 이유는 안전한 도메인의 변경을 제한하는 정상적인 구성 파라미터들은 안전한 도메인으로부터 구성되는 것이 예상되기 때문이다. 그러나, 디스에이블된 도메인 전이 결함의 트리거링이 보안보다는 성능을 개선하기 위한 메커니즘으로서 사용될 수 있음에 따라, 도메인 전이 디스에이블 구성 파라미터가 덜 안전한 도메인으로부터 수정되는 것이 허용가능할 수 있다. 이는, 스레드가 안전한 도메인의 변경을 위해 적절한 안전한 리소스들을 구축하지 않은 경우 그것을 인에이블할 이득이 거의 없을 수 있는데, 그 이유는 그 경우 안전한 도메인으로 전환하려고 시도한다면 임의의 그러한 리소스들이 구축되지 않았을 것이기 때문에 프로세싱이 실패할 것이기 때문이라는 사실을 악용한다.
위에서 논의된 바와 같이, 프로세싱 회로부는 스레드 모드 및 핸들러 모드를 가질 수 있다. 안전한 도메인에서 프로세싱 회로부는 스레드 모드 또는 핸들러 모드에서 동작할 수 있고 유사하게 덜 안전한 도메인에서 프로세싱 회로부는 스레드 모드 또는 핸들러 모드에서 동작할 수 있다는 점에서, 이 모드들은 보안 도메인들에 직교할 수 있다. 전술된 프로세싱 회로부의 적어도 하나의 모드는 스레드 모드일 수 있다. 따라서, 스레드 모드에 있을 때 도메인 전이 디스에이블 구성 파라미터는 안전한 도메인의 전이를 선택적으로 디스에이블할 수 있다. 그러나, 적어도 하나의 모드는 핸들러 모드를 배제할 수 있어서, 핸들러 모드에서 프로세싱 회로부는 도메인 전이 디스에이블 구성 파라미터에 독립적으로 도메인 전이가 허용되는지 결정할 수 있다. 따라서, 도메인 전이 디스에이블 구성 파라미터가 안전한 도메인과 덜 안전한 도메인 사이의 전이가 스레드 모드에서 디스에이블됨을 나타내는 경우에도, 이러한 안전한 도메인/덜 안전한 도메인 전이는 여전히 핸들러 모드에서 허용될 수 있다. 안전한 도메인 및 덜 안전한 도메인을 갖는 시스템에서, 핸들러 모드에서 실행되는 핸들러 코드(예를 들어 운영 체제와 연관될 수 있음)는 안전한 프로세싱 및 덜 안전한 프로세싱 둘 모두를 포함할 수 있어서, 두 도메인들로부터 리소스들을 필요로 하고, 따라서 핸들러 모드에서 안전한 도메인/덜 안전한 도메인 전이를 디스에이블하는 값이 적을 가능성이 더 높다. 또한, 핸들러 모드에서 실행되는 핸들러 코드는 스레드 모드 코드가 디스에이블된 도메인 전이 결함을 트리거한 경우에 개입하여 다른 도메인을 위한 리소스들을 지연 구성하는 코드일 수 있어서, 스레드 모드가 도메인 전이를 디스에이블한 경우에도 핸들러 모드가 두 도메인들에서 계속 동작하도록 허용하는 것이 유용할 수 있다.
앞서 논의된 바와 같이, 명령어 디코더는, 함수 복귀 어드레스를 저장하고 분기 타겟 어드레스로 분기하는 것 뿐만 아니라 또한 프로세싱 회로부의 현재 모드를 핸들러 모드에서 스레드 모드로 전환하는 모드간 호출 분기 명령어를 지원할 수 있다. 이는 또한 도메인 전이가 인에이블되는지 아니면 디스에이블되는지 명시하기 위하여, 이러한 명령어에 응답하여 도메인 전이 디스에이블 구성 파라미터를 설정하는 데 유용할 수 있다. 모드간 호출 분기 명령어의 제1 변형 및 제2 변형 중 적어도 하나가 정의될 수 있는데, 제1 변형은 도메인 전이 디스에이블 구성 파라미터로 하여금 도메인 전이가 적어도 하나의 모드에서 디스에이블됨을 명시하도록 설정되게 하고, 제2 변형은 파라미터로 하여금 도메인 전이가 적어도 하나의 모드에서 인에이블됨을 명시하도록 설정되게 한다. 두 변형을 지원하는 시스템들은 특히 유용할 수 있는데, 그 이유는 핸들러 코드가, 예외 핸들러 코드의 권한박탈된 섹션을 호출하는 동일한 모드간 호출 분기 명령어에서, 권한박탈된 섹션이 두 도메인에서 동작하도록 리소스들을 이미 구성했는지 여부를 신호할 수 있게 하기 때문이다.
유사하게, 앞서 논의된 바와 같이 모드간 함수 복귀 명령어에 대해, 이는 또한 도메인 전이 디스에이블 구성 파라미터가 설정되도록 트리거할 수 있다. 함수 복귀의 경우, 도메인 전이 디스에이블 구성 파라미터가 도메인 전이가 적어도 하나의 모드에서 인에이블됨을 명시하는 값으로 설정되는 데 특히 유용할 수 있다. 이것은 유용한데, 그 이유는 위에서 언급된 바와 같이 모드간 함수 호출 분기 및 모드간 함수 복귀를 위한 하나의 사용 경우는 예외 핸들러 스레드 모드에서 권한박탈될 함수를 호출하도록 허용하는 것일 수 있고, 이 코드는 제3자 제공자에 의해 제공될 수 있기 때문이다. 더 권한부여된 코드는 핸들러 모드에서 코드의 권한박탈된 섹션 전 후로 실행될 "래퍼(wrapper)" 코드를 실행할 수 있다. 모드간 함수 복귀 명령어에 응답하여 도메인 전이 디스에이블 구성 파라미터를 디폴트 값으로 설정함으로써, 래퍼 코드는 권한박탈된 섹션이 실제로 안전한 도메인 및 덜 안전한 도메인 둘 모두를 사용했는지 여부에 상관없이, 권한박탈된 섹션의 종료 시 항상 일관된 알려진 상태로 실행되게 된다. 또한, 모드간 함수 복귀 다음에 설정되는 디폴트 값으로서 "디스에이블" 표시보다는 "인에이블" 표시를 이용함으로써, 도메인 전이 디스에이블 구성 파라미터를 지원하지 않는 시스템들에 대해 기록된 후속 레거시 코드(이는 스레드 모드 도메인 전이가 허용될 것이라고 예상할 것임)가 추가 결함들을 트리거하지 않고 기능할 수 있게 된다.
또한, 모드간 함수 복귀 명령어에 응답하여, 도메인 전이가 적어도 하나의 모드에서 인에이블됨을 나타내도록 도메인 전이 디스에이블 구성 파라미터를 업데이트할 뿐만 아니라, 프로세싱 회로부는 또한, 모드간 함수 복귀 명령어를 실행하기 이전에, 도메인 전이 디스에이블 구성 파라미터가 적어도 하나의 모드에서 도메인 전이가 인에이블 또는 디스에이블되었음을 명시했는지 여부에 대해 표시를 기록할 수 있다. 도메인 전이 디스에이블 구성 파라미터의 이전 상태의 이러한 표시는 후속 핸들러 코드가 다른 보안 상태(예컨대 MPU 상태 또는 스택 포인터들)에 속하는 구성 레지스터 내의 정보가 모드간 호출과 모드간 함수 복귀 사이에 실행되는 코드에 의해 변경되었을 수 있는지 여부를 결정하도록 하는 데 유용할 수 있고, 따라서 다른 보안 상태에 대한 구성 레지스터들이 변경되지 않은 경우, 이전 구성을 복원하기 위한 임의의 동작들이 생략되어 성능을 개선할 수 있다.
만약, 도메인 전이 디스에이블 구성 파라미터의 체크 후에, 제1 보안 도메인에서 제2 보안 도메인으로 전이하려고 시도할 때 디스에이블된 도메인 전이 결함이 신호되는 경우, 예외 제어 회로부는 프로세싱 회로부를 제어하여 제1 보안 도메인에서 예외 핸들러를 프로세싱할 수 있다. 따라서, 덜 안전한 도메인에서 안전한 도메인으로 전환하려는 시도에 의해 결함이 트리거되는 경우, 결함은 덜 안전한 도메인에서 프로세싱될 것이고, 시도가 안전한 도메인에서 덜 안전한 도메인으로의 전이인 경우, 결함은 안전한 도메인에서 프로세싱될 것이다. 통상적으로 대응하는 스레드가 도메인 전환 전에 동작했던 도메인은 스레드가 처음 초기화된 도메인일 것이고, 따라서 그 스레드를 관리하는 관리 프로세스와 연관된 도메인일 것이기 때문에, 이것이 유용하다. 예를 들어 안전한 도메인에서 생성된 안전한 스레드들은 안전한 운영 체제에 의해 관리될 수 있고, 덜 안전한 도메인에서 생성된 덜 안전한 스레드들은 덜 안전한 운영 체제에 의해 관리될 수 있어서, 임의의 디스에이블된 도메인 전이 결함이 디스에이블된 도메인 전이를 시도했던 스레드와 연관된 관리 프로세스로 지향되는 것이 바람직할 수 있다. 결함은 제1 보안 도메인에서 핸들링될 수 있지만, 결함에 응답하여 예외 핸들러에 의해 수행되는 리소스들의 구성은 제2 보안 도메인과 연관된 리소스들의 것일 수 있다. 디스에이블된 도메인 전이 결함이 타겟으로 하는 도메인은 리소스들이 느리게 구성될 필요가 있는 상태와는 상이하기 때문에, 덜 안전한 상태에서 동작하는 프로그램 코드와 보안 상태에서 동작하는 프로그램 코드 사이의 닫힌 조정이 핸들러 모드에서 요구될 수 있다. 따라서 디스에이블된 도메인 전이 체킹이 수행되는 적어도 하나의 모드로부터 핸들러 모드를 배제하는 것이 유리할 수 있다.
예외 조건이 발생하면, 예외 제어 회로부는 안전한 도메인/덜 안전한 도메인 전이가 적어도 하나의 모드에서 인에이블된다고 명시하기 위하여 도메인 전이 디스에이블 구성 파라미터를 업데이트할 수 있다. 다시, 이는 안전하고, 공지된, 디폴트 상태를 갖는 예외 핸들러들를 제공하므로, 예외 핸들러들은 예외가 발생하는 시점에 프로세싱되는 백그라운드 코드와 연관된 도메인 전이 디스에이블 구성 파라미터의 값에 상관없이 일관된 방식으로 기능할 수 있다. 또한, 예외 조건에 응답하여 전이를 인에이블하는 것을 디폴트로 함으로써, 도메인 전이 디스에이블링 기능을 지원하지 않았던 시스템을 위해 기록되었을 수 있는 예외 핸들러들 내의 레거시 코드와의 호환성을 개선한다.
예외 조건이 발생하면, 예외 제어 회로부는 예외 조건이 발생하기 전에 수행된 프로세싱과 연관된 아키텍처 상태를 저장하기 위한 일부 상태 저장을 트리거할 수 있다. 예외 제어 회로부의 하드웨어가 이전 프로세싱과 연관된 모든 아키텍처 상태를 저장할 필요는 없으며, 일부 경우들에서 하드웨어는 아키텍처 상태의 서브세트만을 저장할 수 있다. 다른 상태가 존재하는 레지스터들이 예외 핸들러에 의해 덮어씌여질 경우, 하드웨어에 저장되지 않은 다른 아키텍처 상태를 저장하는 것은 후속 예외 핸들러의 책임일 수 있다.
예외에 응답하여 이러한 상태 저장을 수행할 때, 상태 저장에 저장된 아키텍처 상태는 도메인 전이 디스에이블 구성 파라미터를 포함할 수 있다. 따라서, 예외가 발생하면 도메인 전이 디스에이블 구성 파라미터는 자동으로 하드웨어에 의해 보존될 수 있어서, 예외 핸들링이 완료되고 프로세싱이 예외가 발생하기 전에 수행되고 있던 이전 프로세싱으로 복귀하면, 도메인 전이 디스에이블 구성 파라미터는 제어 저장 위치로 복원될 수 있어서 백그라운드 코드의 후속 프로세싱은 예외가 결코 일어나지 않은 것처럼 동일한 방법으로 기능할 수 있도록 한다.
일부 구현예들에서, 도메인 전이 디스에이블 구성 파라미터는, 예외 조건에 응답하여, 스택 데이터 구조에 저장되는 스택 프레임의 일부로서 저장될 수 있는데, 스택 프레임은 또한 예를 들어 범용 레지스터 콘텐츠 또는 예외 복귀 어드레스와 같은 다른 아키텍처 상태를 포함한다. 그러나, 일부 구현예들에서 도메인 전이 디스에이블 구성 파라미터를 인코딩하기 위한 예비 공간이 스택 프레임 내에 거의 없을 수 있고, 다른 목적을 위한 임의의 예비 인코딩 공간을 보존하는 것이 바람직할 수 있다.
따라서, 일부 예들에서, 상태 저장 동안 예외 제어 회로부는 스택 데이터 구조에 예외 복귀 어드레스 및 아키텍처 상태의 제1 서브세트를 포함하는 제1 스택 프레임을 저장할 수 있지만, 도메인 전이 디스에이블 구성 파라미터를 나타내는 값은 대신에 제1 스택 프레임에 포함되는 대신에 사전결정된 레지스터에 저장될 수 있다(예컨대 사전결정된 레지스터는 링크 레지스터일 수 있음). 이는 스택 프레임 내의 추가 비트들을 들일 필요가 없다. 유의할 점은 도메인 전이 디스에이블 구성 파라미터를 나타내는 저장된 값은 도메인 전이 디스에이블 구성 파라미터 자체에 대하여 동일한 인코딩을 가질 필요는 없다는 것이다 - 예외 발생 시 도메인 전이 디스에이블 구성 파라미터가 무슨 값을 갖고 있었는지 결정하게 하는 임의의 값이 스택에 저장될 수 있다.
그러나, 사전결정된 레지스터는 예외 조건에 응답하여 실행될 예외 핸들러에 액세스가능할 수 있다. 적어도 안전한 도메인에서 덜 안전한 도메인으로의 전이를 야기하는 예외들의 경우, 예외 후에 실행되는 덜 안전한 코드가 예외 전에 수행되는 프로세싱에서 보안 도메인 전이가 디스에이블되었는지 나타내는 값을 수정할 수 있게 하는 것은 바람직하지 않을 수 있다.
이 시나리오로부터 보호하기 위하여, 적어도 안전한 도메인에서 덜 안전한 도메인으로의 전이를 트리거하는 예외 조건에 응답하여, 예외 제어 회로부는 스택 데이터 구조에 전술한 제1 스택 프레임뿐만 아니라 아키텍처 상태의 제2 서브세트 및 도메인 전이 디스에이블 구성 파라미터를 나타내는 값을 체크하기 위한 크로스-체킹 정보를 포함하는 제2 스택 프레임을 저장할 수 있다. 적어도 덜 안전한 도메인에서 안전한 도메인으로의 예외 복귀 전이 시, 예외 제어 회로부는 도메인 전이 디스에이블 구성 파라미터를 나타내는 값을 제2 스택 프레임 내의 크로스-체킹 정보와 비교하여, 비교에서 미스매치가 검출되는 경우 결함의 시그널링을 트리거할 수 있다. 유의할 점은 초기 예외에 응답하여 도메인 전이 디스에이블 구성 파라미터를 나타내는 값이 사전결정된 레지스터 저장되었을 수 있지만, 예외 복귀 전이를 수행하는 시점에는, 도메인 전이 디스에이블 구성 파라미터는 더 이상 사전결정된 레지스터에 있지 않을 수 있고, 메모리의 스택 데이터 구조로부터 로딩된 값 내에, 또는 예외 복귀를 트리거하도록 분기되는 더미 비-실행가능 어드레스 내의 필드에 있을 수 있다. 제2 스택 프레임에서 크로스-체킹 정보를 제공함으로써, 보안 위반을 방지하기 위해 검출될 사전결정된 레지스터 내에 초기에 배치된 도메인 전이 디스에이블 구성 파라미터의 저장된 값을 수정하려는 덜 안전한 예외 핸들러에 의한 시도를 허용할 수 있다. 이 접근법이 더 복잡하게 보일 수 있지만, 제2 스택 프레임은 메모리에 저장된 추가 상태를 기록하여 그것을 덜 안전한 예외 핸들러들로부터 숨길 수 있고, 모든 예외 엔트리들에 대하여 저장된 상태의 서브세트를 제공하는 제1 스택 프레임보다 추가 정보에 대하여 더 많은 예비 용량을 가질 수 있다. 따라서, 제2 스택 프레임에 크로스-체킹 정보를 기록하는 것은 제1 스택 프레임만이 요구되는 예외들의 경우에 도메인 전이 디스에이블 구성 파라미터에 보존하기 위하여 임의의 추가적인 스택 상태를 저장하는 메모리 비용 및 인터럽트 레이턴시를 초래할 필요가 없지만 (왜냐하면 이 경우에 사전결정된 레지스터에 의존하는 것이 안전하기 때문임), 제2 스택 프레임이 저장되어야 하는 안전한 것에서 덜 안전한 것으로의 예외 전이 시 크로스-체크는 스택에 저장되어 보안을 증진시킬 수 있게 한다.
프로세싱 회로부가 안전한 도메인과 덜 안전한 도메인 사이의 도메인 전이가 수행되도록 허가할 수 있는 여러가지 방법이 있을 수 있고, 도메인 전이 디스에이블 구성 파라미터의 체킹은 안전한 도메인들 사이의 전이에 어느 루트가 사용되는지에 따라 약간 상이한 방법들로 수행될 수 있다.
앞어 언급된 바와 같이, 도메인들을 전환하는 한가지 방법은 명령어 디코더가 프로세싱 회로부를 제어하여 도메인간 호출 분기 동작을 수행할 수 있는 것에 응답하여 안전한 도메인에서 덜 안전한 도메인으로의 전이를 요청하는 도메인간 호출 분기 명령어를 이용하는 것이며, 도메인간 호출 분기 동작은 함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치(예컨대 메모리 내의 스택 데이터 구조)에 저장하는 단계, 더미 함수 복귀 어드레스를 사전결정된 레지스터(예컨대 링크 레지스터)에 저장하는 단계, 프로세싱 회로부를 덜 안전한 도메인으로 전환하는 단계, 및 도메인간 호출 분기 명령어에 의해 명시된 분기 타겟 어드레스에 의해 식별된 명령어로 분기하는 단계를 포함한다. 안전한 도메인에서 덜 안전한 도메인으로의 직접 함수 호출을 허용함으로써, 예외 핸들러 또는 도메인 전이를 감독하기 위한 모니터 코드를 호출할 필요성을 회피하여, 성능 개선을 제공한다.
도메인간 호출 분기 명령어에 대해, 도메인 전이 디스에이블 구성 파라미터는 체크될 수 있고, 도메인 전이 디스에이블 구성 파라미터가 도메인간 전이가 적어도 하나의 모드에서 인에이블된다고 명시하면, 도메인간 호출 분기 동작이 수행될 수 있다. 또한, 도메인 전이 디스에이블 구성 파라미터의 값에 상관없이, 프로세싱 회로부가 현재 적어도 하나의 모드 이외의 모드에 있는 경우(예컨대 현재 모드가 핸들러 모드이면) 도메인간 호출 분기 동작이 수행될 수 있다. 반대로, 적어도 하나의 모드(예컨대 스레드 모드)에 있으면서 도메인 전이 디스에이블 구성 파라미터가 도메인 전이가 적어도 하나의 모드에서 디스에이블되어 있다고 명시하면, 디스에이블된 도메인 전이 결함의 시그널링이 트리거될 수 있다.
도메인들 사이에서 전이하는 다른 방법은 도메인간 복귀 분기 명령어를 실행하려고 시도하는 것일 수 있는데, 이는 안전한 도메인에서 덜 안전한 도메인으로의 전이를 요청하고 도메인간 복귀 분기 명령어에 의해 명시된 분기 타겟 어드레스에 의해 식별된 명령어로 분기한다. 명령어를 실행하려는 시도는 도메인 전이 디스에이블 구성 파라미터가 체크되도록 트리거할 수 있고, 도메인 전이 디스에이블 구성 파라미터가 도메인간 전이가 적어도 하나의 모드에서 인에이블된다고 명시하면, 도메인간 복귀 분기 동작은 수행될 수 있다. 또한, 도메인 전이 디스에이블 구성 파라미터의 값에 상관없이, 프로세싱 회로부가 현재 적어도 하나의 모드 이외의 모드에 있는 경우(예컨대 현재 모드가 핸들러 모드이면) 도메인간 복귀 분기 동작이 수행될 수 있다. 반대로, 적어도 하나의 모드(예컨대 스레드 모드)에 있으면서 도메인 전이 디스에이블 구성 파라미터가 도메인 전이가 적어도 하나의 모드에서 디스에이블되어 있다고 명시하면, 디스에이블된 도메인 전이 결함의 시그널링이 트리거될 수 있다.
도메인들 사이에서 전이하는 다른 방법은 앞서 논의된 바와 같이 이전의 함수 호출 분기 명령어에 의해 설정된 더미 함수 복귀 어드레스로 분기하려고 시도하는 것일 수 있다. 안전한 도메인에서 덜 안전한 도메인으로의 전이를 요청하는 도메인간 호출 분기 명령어가 실행될 때, 함수 호출에 대한 함수 복귀 어드레스는 스택 데이터 구조에 저장되어 덜 안전한 코드에 노출되는 것을 보호할 수 있고, 더미 함수 복귀 어드레스는 덜 안전한 코드에 노출되는 링크 레지스터에 저장될 수 있다. 더미 함수 복귀 어드레스는 대응하는 함수 복귀 시 안전한 도메인으로 복귀하기 위하여 도메인 전이가 수행되어야 함을 나타내는 정보를 포함할 수 있다. 따라서, 나중에 더미 함수 복귀 어드레스로 분기하려는 시도가 있고 더미 함수 복귀 어드레스가 도메인간 함수 복귀를 나타내면, 프로세싱 회로부가 현재 적어도 하나의 모드에 있고 도메인 전이 디스에이블 구성 파라미터가 적어도 하나의 모드에서 도메인 전이가 디스에이블되어야 한다고 명시하는 경우, 프로세싱 회로부는 디스에이블된 도메인 전이 결함의 시그널링을 트리거할 수 있다.
덜 안전한 도메인에서 안전한 도메인으로 전이하는 다른 방법은 명령어가 안전한 어드레스 영역으로부터 페치될 때일 수 있다. 메모리 액세스 체크 회로부에 의해 유지되는 보안 속성 데이터는 어드레스 영역들을 덜 안전한 어드레스 영역들 또는 안전한 어드레스 영역들로서 정의할 수 있다. 메모리의 안전한 어드레스 영역들에 저장된 명령어들은 안전한 도메인에서만 실행될 수 있다. 현재 덜 안전한 도메인에 있으면, 안전한 어드레스 영역의 어드레스를 갖는 명령어를 페치하려는 시도가 이루어지는 경우, 안전한 도메인으로의 전이가 허용될 수 있는지 체크하도록 일부 보안 체크들이 수행될 것을 요구할 수 있다. 예를 들어, 체크는 안전한 어드레스 영역의 어드레스에 있는 명령어가 유효 엔트리 시점들을 안전한 도메인에 마크하는 특정 유형의 보안 게이트웨이 명령어인지 여부를 체크하는 것을 포함할 수 있다. 일부 경우들에서, 안전한 어드레스 영역의 어드레스에 있는 명령어가 보안 게이트웨이 명령어인 경우, 보안 게이트웨이 명령어의 디코딩은 덜 안전한 도메인에서 안전한 도메인으로 안전한 도메인의 변경을 트리거할 수 있다. 다른 경우들에서 덜 안전한 도메인에서 안전한 도메인으로의 전이는 명령어를 페치하려는 시도가 덜 안전한 호출가능 보안 메모리일 수 있는 특정 유형의 보안 메모리를 타겟으로 하는 경우에만 허용될 수 있다. 일부 구현예들은 보안 게이트웨이 명령어 체킹 및 덜 안전한 호출가능 보안 메모리 체킹 둘 모두를 수행할 수 있다.
그러나, 앞서 언급된 바와 같이, 덜 안전한 도메인에서 안전한 도메인으로의 전이의 경우, 보안 체크는 하나의 안전한 도메인 내에 남도록 예상되었던 스레드에 대해 구성되지 않았을 수 있는 리소스들에 따라 달라질 수 있다(예컨대 체크는 안전한 영역에서 페치된 명령어가 페치되고 디코딩될 수 있도록 설정된 안전한 영역에 대한 메모리 보호 유닛 속성들에 따라 달라질 수 있음). 따라서, 덜 안전한 도메인에만 존재하는 것으로 예상되는 스레드가 상태를 전환하려고 시도하는 경우 보안 체크는 그 자체로 역부족일 수 있다. 이러한 보안 체크 역부족을 막기 위해, 가능한 일찍 도메인 전이 디스에이블 구성 파라미터의 체크를 수행하는 것이 바람직할 수 있다.
따라서, 이 체크는, 명령어가 페치되고 디코딩될 때까지 대기하기 보다는, 안전한 어드레스 영역의 어드레스를 갖는 명령어를 페치하려는 시도에 응답하여 수행될 수 있다. 파이프라인의 초기 스테이지에서 도메인 전이 디스에이블 구성 파라미터의 체크를 수행함으로써, 구성된 리소스의 부족으로 인해 보안 체크가 실패할 가능성을 감소시킨다. 이 체크가 완료되는 시점에, 페치되는 명령어가 실제로 보안 도메인으로의 전이를 트리거했을 명령어인지 여부는 아직 알려지지 않을 수 있다(예를 들어 페치된 명령어가 보안 게이트웨이 명령어가 아니라면, 안전한 도메인으로의 엔트리를 트리거하지 않았을 수 있다). 따라서, 도메인 전이 디스에이블 구성 파라미터의 체킹은, 명령어가 안전한 어드레스 영역 내의 어드레스로부터 페치되고 현재 도메인이 덜 안전한 도메인인 경우, 페치되는 명령어의 유형에 상관없이 체크될 수 있다는 점에서 보수적일 수 있다. 일부 구현예들에서 파이프라인 내의 다양한 체크들의 위치는 달라질 수 있지만, 도메인 전이 디스에이블 체크를 먼저 수행하는 동일한 효과는 이 체크를 나중에 파이프라인에서 수행하지만, 임의의 생성된 도메인 전이 디스에이블 결함들의 시그널링을 다른 결함들의 시그널링보다 우선순위화함으로써 달성될 수 있음을 이해할 것이다.
모드간 호출 분기 명령어에 대하여 전술된 바와 같이, 도메인 전이 디스에이블 구성 파라미터는 시뮬레이션 환경에서 사용될 수 있으며, 여기서 호스트 데이터 프로세싱 장치 상에서 실행되는 시뮬레이션 컴퓨터 프로그램은 타겟 프로그램 코드가 도메인 전이 디스에이블 구성 파라미터를 저장하는 제어 저장 위치 및 전술된 바와 같이 파라미터를 설정 및 이용하기 위하여 연관된 로직의 특징부들을 갖는 실제 하드웨어 디바이스 상에서 실행되는 경우 예상되는 것에 동등한 명령어 실행 환경을 시뮬레이션한다. 따라서, 컴퓨터 프로그램은 전술된 바와 같이 프로세싱 프로그램 로직, 메모리 액세스 체킹 프로그램 로직 및 프로세싱 회로부의 기능을 모방하는 구성 파라미터 설정 프로그램 로직, 메모리 액세스 체크 회로부 및 제어 저장 위치에서 도메인 전이 디스에이블 구성 파라미터를 유지하기 위한 회로부를 가질 수 있다.
특정 실시예의 설명
도 1은 메모리 시스템(6)으로부터 페치된 명령어들에 응답하여 데이터 프로세싱을 수행하기 위한 프로세싱 회로부(4)를 포함하는 데이터 프로세싱 시스템(2)의 예를 개략적으로 도시한다. 메모리 시스템(6)은 메인 메모리뿐만 아니라 캐시(예컨대 하나 이상의 레벨들의 데이터 캐시 및/또는 명령어 캐시)를 포함할 수 있다. 프로세싱 회로부(4)는 다수의 파이프라인 스테이지들, 예를 들어, 메모리 시스템(6)으로부터 실행될 명령어들을 페치하기 위한 페치 스테이지(8), 데이터 프로세싱을 수행하기 위하여 나머지 파이프라인 스테이지들을 제어하기 위한 제어 신호들을 생성하는 페치된 명령어들을 디코딩하기 위한 디코딩 스테이지(10), 및 데이터 프로세싱 동작들을 수행하기 위하여 디코딩된 명령어들을 실행시키기 위한 실행 스테이지(12)를 포함하는 프로세싱 파이프라인을 포함한다. 파이프라인(4)에 의해 프로세싱되는 명령어들에 대한 입력 피연산자들을 저장하기 위해 레지스터들(14)이 제공된다. 레지스터들(14)은 정수 값들을 저장하기 위한 범용(정수) 레지스터들(16), 및 프로세싱 회로부(4)에 의한 명령어들의 실행 및 예외 핸들링, 보안 체킹 등과 같은 다른 동작들을 제어하기 위한 제어 파라미터들을 저장하기 위한 제어 레지스터들(20)을 포함하는 다수의 유형들의 레지스터들을 포함한다. 다른 유형들의 레지스터들, 예컨대 부동소수점 값들을 저장하기 위한 부동소수점 레지스터들 또는 다수의 독립적인 데이터 값들을 포함하는 벡터 피연산자들을 저장하기 위한 벡터 레지스터들이 또한 제공될 수 있다.
도 1에 도시된 파이프라인 스테이지들은 단순화된 표현이고, 다른 유형들의 파이프라인 스테이지들, 예컨대, 레지스터 재명명을 수행하기 위한 재명명 스테이지, 실행을 기다리는 명령어들을 큐잉(queueing)하고 그것들의 필요한 피연산자들이 이용가능할 때 실행할 명령어들을 발행하기 위한 이슈 스테이지, 및 명령어들의 책무를 핸들링하고 결과를 다시 레지스터들(14)에 다시 기록하기 위한 재기록(writing back) 스테이지가 또한 제공될 수 있음을 이해할 것이다. 파이프라인은 순서가 있거나 순서가 없는 파이프라인일 수 있다.
프로세싱 시스템의 동작 시 무작위로 발생하는 하드웨어 결함을 검출 또는 교정하기 위하여 에러 검출 또는 교정 동작들을 수행하기 위한 신뢰성, 가용성 및 편리성(RAS) 에러 검출/교정 회로부(29)가 제공된다. 예를 들어 하드웨어 결함은 저장된 상태 비트 또는 프로세싱 로직 경로 상의 신호가 0과 1이 뒤바뀌게 하는 입자 충돌로 인해 발생할 수 있다. 또한, 하드웨어 결함은 시간 경과에 따른 전자 회로의 물리적 열화로 인해, 예컨대 일렉트로마이그레이션은 결국 저장 소자가 그것에 기록된 비트 값에 상관없이 0 또는 1로 고착되게 할 수 있다. 이러한 결함들을 검출하기 위해, RAS는 하나 이상의 에러 검출/교정 메커니즘들을 포함할 수 있다. 예를 들어, 하나의 메커니즘은 프로세싱 회로부(4)와 동일한 동작들을 중복적으로 실행하는 중복 프로세싱 로직, 및 임의의 결함들을 검출하기 위하여 메인 및 중복 프로세싱의 결과물들을 비교하는 비교 로직을 제공하기 위한 것일 수 있다. 다른 메커니즘은 메모리에 기록된 데이터와 연관되어 저장되는 에러 검출 코드들 또는 에러 교정 코드들의 설정 및 체킹을 관리하는 것일 수 있어서, 메모리에서 다시 데이터를 판독 시 대응하는 에러 검출/교정 코드는 재계산되고 저장된 에러 검출/교정 코드와 비교하여 에러를 검출(및 가능하다면 교정)할 수 있도록 한다. RAS 에러가 검출되는 경우, 가능한 경우 에러는 교정되고 프로세싱은 계속해서 순방향 진행한다(예컨대 이는 3중 코어 동일방식 기술 또는 에러 교정 코드들을 이용하여 가능할 수 있다). 대안적으로, 에러가 교정가능하지 않은 경우, 프로세싱의 스레드가 종료되고 재시작하게 할 수 있는 결함은 신호될 수 있다. 에러 검출/교정 및 복구에 대하여 임의의 공지된 기술이 사용될 수 있음을 이해할 것이다.
시스템(2)은 또한 메모리 어드레스 공간의 다양한 영역들에 대하여 명시된 속성 데이터에 기초하여 메모리 시스템(6)에 대한 액세스들이 허용되는지 체크하기 위한 메모리 액세스 체크 회로부(22)를 포함한다. 메모리 액세스 체크 회로부는 메모리 어드레스 공간의 각각의 각자 영역과 연관된 보안 도메인을 정의하는 보안 도메인 정의 데이터를 저장하기 위한 보안 속성 유닛(SAU)(24)을 포함한다. 보안 속성 데이터에 기초하여, 보안 속성 유닛(24)은 프로세싱 회로부의 동작의 현재 안전한 도메인 및 메모리 액세스의 타겟 어드레스를 포함하는 영역과 연관된 보안 도메인에 따라 메모리 액세스가 허용되는지 여부를 체크할 수 있다. 다른 실시예들에서 SAU는 보안 도메인 정의 데이터를 직접 저장하지 않고, 메모리 액세스 체크를 수행하기 위하여 다른 곳에 저장된 보안 도메인 정의 데이터에 액세스할 수 있다. 일부 시스템들에서 보안 도메인 정의 데이터는 메모리 시스템(6)에 저장될 수 있거나, 또는 시스템(2) 내의 다른 곳의 구성 레지스터들에 저장될 수 있다. 프로세싱 회로부(4)는 동작의 현재 안전한 도메인에서 동작할 수 있고, (예컨대 도메인들 사이의 전이를 핸들링할 때 일부 예외들이 있을 수 있지만) 이는 일반적으로 현재 실행되는 명령어의 어드레스와 연관된 보안 도메인에 대응할 수 있다. 명령어가 SAU(24)에 의해 하나의 도메인에 있는 것으로 명시된 영역의 어드레스로부터 상이한 도메인과 연관된 영역의 어드레스로 분기하면, 이는 프로세싱 회로부(4)가 동작하고 있는 현재 안전한 도메인의 전이를 트리거할 수 있다. 다른 실시예들에서 이러한 분기는 현재 안전한 도메인의 전이를 직접 트리거하지 않을 수 있지만, 대신 게이트웨이 명령어가 존재하는지 여부와 같은 추가 보안 체크를 트리거하고, 이러한 실시예들에서 그것은 현재 안전한 도메인의 변경을 트리거하는 게이트웨이 명령어 자체일 수 있다. 일반적으로, 안전한 도메인에서 동작하는 동안, 프로세싱 회로부는 안전한 도메인 및 덜 안전한 도메인 둘 모두와 연관된 메모리 영역들 내의 데이터에 액세스할 수 있고, 덜 안전한 도메인에서 동작하는 동안, 프로세싱 회로부는 덜 안전한 도메인과 연관된 영역들 내의 데이터에 액세스할 수 있지만 SAU(24)가 안전한 도메인과 연관된 것으로 명시하는 어드레스 공간의 영역들 내의 데이터에 액세스하는 것은 허가되지 않을 수 있다. 이는 덜 안전한 도메인에서 동작하는 코드로부터의 인가되지 않은 액세스에 대항하여 민감한 데이터의 보호를 가능하게 한다.
또한, 메모리 액세스 체크 회로부는 메모리 보호 유닛(MPU)(26)을 포함할 수 있으며, 이는 메모리 시스템(6)에 대한 메모리 액세스가, 예를 들어, 프로세싱 회로부(4)의 어느 권한 레벨들이 메모리의 주어진 영역에 액세스하도록 허용되는지 명시할 수 있거나, 또는 어드레스 공간의 메모리 영역이 판독 및 기록 동작 둘 모두에 의해 액세스될 수 있는지 아니면 기록이 금지되는 영역을 판독만 하는지 명시할 수 있는 액세스 허가를 충족하는지 여부를 체크한다. MPU(26)에 의해 사용되는 액세스 허가는 덜 권한부여된 프로세스(예컨대 애플리케이션)가 메모리의 어느 영역들을 액세스하도록 허용될 지, 그리고 얼마나 허용될 지(판독 전용 또는 판독/기록, 및 메모리가 실행가능한 지 여부) 제어하도록 예를 들어 (하이퍼바이저 또는 운영 체제와 같은) 더 권한부여된 프로세스에 의해 명시될 수 있다. 일부 구현예들에서 MPU(26)는 또한 권한부여된 프로세스가 메모리의 어느 영역들 액세스하도록 허용될 지, 그리고 얼마나 허용될 지(판독 전용 또는 판독/기록, 및 메모리가 실행가능한 지 여부)에 대한 체킹을 적용할 수 있다. MPU(26)는 덜 권한부여된 액세스 대 권한부여된 액세스에 대하여 상이한 허가가 명시되게 할 수 있다. MPU(26)에 의해 제공되는 허가는 SAU(24)에 의헤 제공되는 것들에 직교할 수 있어서, 허용되는 주어진 메모리 액세스의 경우, MPU(26) 및 SAU(24) 둘 모두에 대하여 정의된 액세스 허가들에 기초하여 체크를 통과시켜야 한다. MPU(26)는 각각 보안 도메인들 중 하나와 연관되는, 별개의 안전한 및 덜 안전한 MPU(26-S, 26-NS)를 포함할 수 있으며, 현재 도메인이 안전한 도메인인지 아니면 덜 안전한 도메인인지에 따라 메모리의 주어진 영역에 대하여 상이한 메모리 액세스 허가들이 명시될 수 있다(예컨대 영역은 덜 안전한 도메인에서 판독만 될 수 있지만, 안전한 도메인에서 판독 및 기록 둘 모두 가능할 수 있다).
따라서, 도 2에 도시된 바와 같이, 프로세싱 회로부(4)는 적어도 안전한 도메인(들) 및 덜 안전한 도메인(또한 안전하지 않은 도메인, NS)을 포함하는 다수의 안전한 도메인들 중 하나에서 데이터 프로세싱을 수행하는 것을 지원할 수 있다. 도 2는 단지 2개의 안전한 도메인을 갖는 시스템을 도시하지만, 상이한 레벨들의 보안과 연관된 3개 이상의 도메인을 제공하는 것이 가능할 것이며, 이 경우에 도시된 S 및 NS 도메인들은 제공된 3개 이상의 도메인들 중 임의의 2개일 수 있다.
또한, 주어진 안전한 도메인 내에서, 도 2에 도시된 바와 같이 프로세싱 회로부는 예외 프로세싱을 위한 핸들러 모드(H) 및 백그라운드 프로세싱을 위한 스레드 모드(T)를 포함하는 다수의 모드들 중 하나에서 데이터 프로세싱을 수행할 수 있다. 도 1에 도시된 바와 같이, 예외 엔트리 전이 및 예외 복귀 전이, 및 이러한 전이 동안 아키텍처 상태의 임의의 저장/복원을 포함하는, 예외 핸들링 동작들을 제어하기 위한 예외 제어 회로부(28)가 제공될 수 있다. 예외 핸들링의 전용 핸들러 모드(H)로의 분리는 프로세싱 회로부에 의해 액세스되는 것이 허용되는 레지스터들의 관리를 단순화하는 데 유용할 수 있다(예컨대 예외 핸들링에 사용되는 일부 레지스터들은 핸들러 모드(H)에서 액세스가능하지만, 스레드 모드(T)에서 액세스가능하지 않을 수 있다). 일반적으로, 핸들러 모드(H)에서 동작할 때, 프로세싱 회로부(4)는 기본적으로 더 권한부여된 동작 모드를 갖는 것으로 간주될 수 있어서, 메모리 및 레지스터들에 대한 액세스가 적어도 권한부여된 레벨 이외의 특정 레벨의 권한 레벨에 따라 제어되지만, 스레드 모드(T)에서 프로세싱 회로부는 제어 레지스터들(20)에 저장된 다른 아키텍처 상태에 따라 다수의 상이한 권한 레벨들 중 하나를 가질 수 있다.
따라서, 도 2에 도시된 바와 같이, 프로세싱 회로부(4)가 동작하는 보안 도메인 및 모드의 조합은 프로세싱 회로부(4)에 의해 프로세싱이 어떻게 수행되는지의 양태들을 결정할 수 있다. 도 2는 다음 모드들의 4가지 상이한 조합을 도시하며, 이들은:

안전한 스레드 모드(안전한 도메인 및 스레드 모드의 조합에 대한 약칭)

덜 안전한 스레드 모드(덜 안전한 도메인 및 스레드 모드의 조합)

안전한 핸들러 모드(안전한 도메인 및 핸들러 모드의 조합) 및

덜 안전한 핸들러 모드(덜 안전한 도메인 및 핸들러 모드의 조합).
아래 논의되는 바와 같이, 예외 조건들, 및 예외 복귀 조건들에 응답하여, 수행되는 작용들은 안전한 도메인 및 모드의 이들 각각의 조합 사이에서 이루어지는 특정 전이에 따라 달라질 수 있다. 보안 속성 유닛(SAU)(24)은 안전한 도메인과 덜 안전한 도메인 사이의 경계를 감시한다. 안전한 MPU(26-S)의 속성들은 안전한 스레드 모드에서 동작하는 상이한 스레드들 사이의 경계, 및 이 스레드들과 안전한 운영 체제 사이의 경계를 감시하는 데 사용될 수 있다. 덜 안전한 MPU(26-NS)의 속성들은 덜 안전한 스레드 모드에서 동작하는 상이한 스레드들 사이의 경계, 및 이 스레드들과 덜 안전한 운영 체제 사이의 경계를 감시하는 데 사용될 수 있다.
도 3은 프로세싱 시스템의 레지스터들(14)의 일부를 도시한다. 이러한 표현이 제공될 수 있는 모든 가능한 레지스터들을 도시하는 것은 않으며, 많은 다른 레지스터들이 또한 제공될 수 있음을 이해할 것이다. 도 3에 도시된 바와 같이, 레지스터들(14)은 범용 레지스터들(16), 및 다수의 제어 레지스터들(20)을 포함한다(제어 레지스터들 중 일부만이 도 3에 도시되어 있고 - 다른 것들이 또한 제공될 수 있다). 이러한 예에서 R0부터 R15까지 라벨링된, 16개의 범용 레지스터가 제공되어 있다. 일부 실시예들에서, 범용 레지스터들(16)은 또한 조건 플래그 값들 및 현재 컨텍스트에 관련된 다른 정보를 유지할 수 있는 프로그램 상태 레지스터(XPSR)를 포함할 수 있다.
범용 레지스터들(R0 내지 R15) 중에서, 레지스터들(R0 내지 R12)은 범용 피연산자들, 예컨대, 산술 또는 논리 명령어들을 위한 입력 피연산자들 또는 메모리 시스템(6)에 액세스하기 위한 로드/저장 명령어들을 위한 어드레스들을 도출하는 데 사용되는 피연산자들을 저장하는 데 사용된다. 이러한 범용 피연산자들을 위해 범용 레지스터들(R13 내지 R15)을 사용하는 것이 가능할 수 있지만, 또한 다른 제어 기능들을 제공한다.
레지스터(R15)는 프로세싱 회로부(4)에 의해 도달되는 프로그램의 현재 시점의 표시를 제공하는 프로그램 카운터를 저장하는 프로그램 카운터(PC) 레지스터로서 사용된다. 프로그램 카운터 레지스터는 어느 명령어들이 메모리 시스템으로부터 페치되는지 결정하기 위하여 페치 스테이지(8)에 의해 사용될 수 있다.
레지스터(R14)는 함수가 호출될 때 함수 복귀 어드레스들를 저장하는 데 사용되는 링크 레지스터(LR)로서 사용되어, 함수와 연관된 프로세싱이 완료되면 링크 레지스터 내의 어드레스가 프로그램 흐름을 함수 호출 명령어 후의 다음 명령어로 다시 재지향시키는 데 사용될 수 있도록 한다. 또한 링크 레지스터는 예외 발생 시 대응하는 예외 복귀 조건이 발생할 때 아키텍처 상태의 스택해제를 제어하기 위한 정보를 제공하는 예외 복귀 값을 저장하는 데 사용될 수 있다. 유사하게 링크 레지스터는 또한 모드간 또는 도메인간 함수 호출이 수행될 때 더미 함수 복귀 어드레스를 저장하는 데 사용될 수 있다. 이들은 아래 더 상세하게 논의될 것이다.
레지스터(R13)는 메모리 내의 스택 데이터 구조의 어드레스를 나타내는 스택 포인터를 제공하는 스택 포인터 레지스터로서 사용된다. 스택 데이터 구조는 예외 조건이 발생할 때 아키텍처 상태를 저장하고, 예외 복귀 조건이 발생할 때 아키텍처 상태를 복원하는 데 사용될 수 있다. 도 3에 도시된 바와 같이, 레지스터(R13)는 다수의 상이한 물리적 레지스터들이 하드웨어에서 제공되도록 구축되고, 각각 레지스터 지정자(R13)를 이용하여 액세스가능하고, R13이 명시될 때 구축된 특정 레지스터가 어떻게 선택되는지는, 프로세싱 회로부의 현재 안전한 도메인 및 모드, 및 또한 구성 레지스터들의 값을 포함하는 여러 요인들에 따라 달라질 수 있다.
예를 들어 구축된 스택 포인터 레지스터들은 안전한 메인 스택 포인터 레지스터(MSP_S), 안전한 프로세스 스택 포인터 레지스터(PSP_S), 덜 안전한 메인 스택 포인터 레지스터(MSP_NS) 및 덜 안전한 프로세스 스택 포인터 레지스터(PSP_NS)를 포함할 수 있다. 일반적으로, 안전한 스택 포인터 레지스터들(MSP_S, PSP_S)은 안전한 도메인(S)에 있을 때 프로세싱 회로부(4)에 액세스가능하지만 덜 안전한 도메인(NS)에 있을 때 액세스불가능하다. 덜 안전한 스택 포인터 레지스터(MSP_NS, PSP_NS)는 덜 안전한 도메인에서 액세스가능하다. 일부 구현예들은 구축된 스택 포인터들에 액세스하는 추가적인 방법들을 제공할 수 있고, 이는 덜 안전한 도메인과 연관된 스택 포인터들(MSP_NS, PSP_NS)에 대한 안전한 도메인 액세스를 제공할 수 있다. 일반적으로, 프로세스 스택 포인터들(PSP_S 또는 PSP_NS)은 스레드 모드(T) 내에서 사용되도록 예상되며, 메인 스택 포인터들(MSP_S 또는 MSP_NS)은 핸들러 모드(H) 내에서 사용되도록 예상된다. 핸들러 모드 및 스레드 모드 각각에 대한 별개의 메인 및 프로세스 스택들의 공급은 예외 핸들러 코드의 개발을 더 단순하게 만들 수 있는데, 그 이유는 예외 핸들러들이 메인 스택 상에 남겨놓는 임의의 데이터는 일반적으로 예외 복귀 후에 스레드 모드에서 실행되는 스레드에 액세스가능하지 않게 되기 때문이다. 이는 예외 핸들러 코드의 개발을 단순화할 수 있는데, 그 이유는 예외 핸들러가 메인 스택 데이터 구조로부터 그것의 모든 데이터를 소거하기 위한 명령어들을 포함할 필요가 없기 때문이다. 그러나, 스레드 모드(T)에서의 프로세스들이 메인 스택 포인터를 이용하는 것은 가능하며, 제어 레지스터(32)에 저장된 스택 포인터 선택 값(30)은 스레드 모드(T)에 있을 때 메인 스택 포인터가 사용되어야 하는지 아니면 프로세스 스택 포인터가 사용되어야 하는지 제어한다. 따라서, 어느 스택 포인터가 사용되어야 하는지는 현재 모드(스레드 또는 핸들러) 및 현재 도메인(안전한 또는 덜 안전한)의 조합 뿐만 아니라 스택 포인터 선택 값(30)에도 기초하여 결정될 수 있다. 도 3에 도시된 바와 같이, 스택 포인터 선택 값(30)은 보안 상태들 사이에 구축될 수 있어서, 안전한 도메인 및 덜 안전한 도메인은, 스택 포인터 선택 값(30)의 별개의 안전한 및 덜 안전한 버전들(30-S, 30-NS)을 이용하여, 독립적으로 안전한 및 덜 안전한 스레드 모드가 각각 메인 스택 포인터를 사용하는지 아니면 프로세스 스택 포인터를 사용하는지 제어할 수 있다. 현재 안전한 도메인은 어떤 구축된 버전(30-S, 30-NS)이 판독/기록될 지 제어한다.
일반적으로, 핸들러 모드(H)에서 동작하는 예외 핸들러의 본체 또는 스레드 모드(T)에서 동작하는 스레드 내에서, 안전한 또는 불안전한 스택 포인터의 선택은 프로세싱 회로부(4)가 코드를 실행하는 현재 안전한 도메인에 따라 달라질 수 있다. 예외 엔트리 및 복귀의 경우, 상태의 스택 및 스택해제는 예외가 발생하기 전 실행되었던 백그라운드 코드의 보안 도메인과 연관된 스택 포인터에 의해 식별된 스택으로부터 수행된다.
제어 레지스터(32)는 또한 스레드 모드에서 실행되는 코드가 권한부여되는지 아니면 권한박탈되는지 제어하는 권한 제어 값(nPRIV)(31)을 포함할 수 있다. 권한 제어 값은 안전한 도메인 및 덜 안전한 도메인에 대하여 상이하게 설정될 수 있다
(예컨대 안전한 스레드 모드는 권한박탈될 수 있지만 덜 안전한 스레드 모드는 권한부여될 수 있거나, 또는 그 반대일 수 있음). 대안적으로 안전한 및 덜 안전한 스레드 모드 둘 모두는 동일한 권한 레벨에서 동작할 수 있다. 권한 제어 값(31)은 단지 하나의 예이고, 제어 레지스터에 저장된 아키텍처 상태를 이용하여 안전한/덜 안전한 스레드 모드에서 코드에 배정되는 권한 레벨을 제어하는 다른 방법들이 있을 수 있음을 이해할 것이다. 도 3의 예에서, 권한 제어 값(31)은, 안전한 도메인 및 덜 안전한 도메인에서 각각 스레드 모드에 의해 사용되는 권한 레벨을 제어하기 위한 별개의 안전한 및 덜 안전한 권한 제어 값들(31-S, 31_NS)이 제공되도록 구축된다. 그러나, 다른 접근법은 도메인 전이시 전환되는 단일 제어 비트를 제공할 수 있다.
도 3에 도시된 바와 같이, 제어 레지스터(32)는 또한 스레드 모드에서 안전한 도메인과 덜 안전한 도메인 사이의 전이가 인에이블되는지 아니면 디스에이블되는지 제어하기 위한, 도메인 전이 디스에이블 구성 파라미터로도 지칭되는, 스레드 모드 상태간 디스에이블(TMID) 파라미터(34)를 포함한다. 이는 아래 더 상세하게 논의될 것이다. 스택 포인터 선택 값(30) 및 권한 값(31)과 달리, TIMID(34) 값은 보안 상태들 사이에서 공유된다. TMID 파라미터(34)는 스레드 모드에서 안전한 도메인과 덜 안전한 도메인 사이의 전이를 디스에이블하는 데 사용될 수 있고, 이는 아래 더 설명되는 바와 같이 안전한/덜 안전한 도메인들 중 하나를 위한 리소스들의 지연 구성을 인에이블하는 데 유용할 수 있는데, 그 이유는 도메인 전이의 디스에이블링(디스에이블된 도메인 전이를 수행하려는 시도가 이루어지는 경우 결함을 트리거함)은 스레드들이 단일 도메인으로 국한될 수 있음을 의미하기 때문이다.
도 3에 도시된 바와 같이, 제어 레지스터들(20)은 또한 예외 번호(36)를 제공하는 레지스터를 포함한다. 예외 번호(36)는 이 제어 레지스터에 저장된 유일한 값이 아닐수 있다 - 다른 상태가 동일한 레지스터에 저장될 수 있다. 예외 번호는 시스템이 핸들러 모드에 있을 때 현재 실행되는 예외 핸들러와 연관되는 예외를 식별한다. 시스템이 스레드 모드에 있을 때, 예외 번호(36)는 현재 프로세싱되는 예외가 없음을 나타내는 특정 디폴트 값(예컨대 0)으로 설정된다. 따라서, 예외 번호(36)는 효과적으로 또한 시스템이 현재 스레드 모드에 있는지 아니면 핸들러 모드에 있는지에 대한 표시인데, 그 이유는 예외 번호 레지스터(36)가 특별한 값(예컨대 0)을 명시하는 경우 시스템은 스레드 모드에 있는 것이고, 임의의 다른 값이 명시되면 시스템은 핸들러 모드에 있는 것이고, 특정 0이 아닌 값은 핸들링되고 현재 예외를 식별하기 때문이다. 따라서, 시스템이 동작중인 현재 모드를 나타내는 별도의 레지스터가 필요하지 않을 수 있다. 도 3에 도시되지 않았지만, 현재 도메인이 안전한 도메인인지 아니면 덜 안전한 도메인인지 나타내는 제어 레지스터가 있을 수 있다. 대안적으로, 이러한 레지스터는 필요하지 않을 수 있는데, 그 이유는 프로세싱되고 있는 명령어의 어드레스가 SAU(24)에 의해 정의된 바와 같이 메모리의 안전한 영역에 있는지 아니면 덜 안전한 영역들에 있는지 결정으로부터 암시될 수 있기 때문이다.
도 4는 메모리 시스템(6)을 어드레싱하는 데 사용되는 메모리 어드레스 공간의 예를 도시한다. 메모리 어드레스 공간(100)은 안전한 도메인 및 덜 안전한 도메인 둘 모두에서 액세스가능한 하나 이상의 덜 안전한 영역들(102) 및 안전한 도메인에서 액세스가능하고 덜 안전한 도메인에서 액세스불가능한 하나 이상의 안전한 영역들(104)을 포함할 수 있다. 설명의 용이함을 위하여 도 4는 단지 하나의 덜 안전한 영역(102) 및 하나의 안전한 영역(104)을 도시하지만, 각각의 유형의 다수의 영역들이 있을 수 있고 이 영역들은 서로 배치될 수 있어서, 모든 안전한 영역들이 연속되는 블록에 있고 모든 덜 안전한 영역들이 연속되는 블록에 있을 필요는 없다. 덜 안전한 영역들은 덜 안전한 프로그램 코드(110), 스택 데이터 구조들(112)(덜 안전한 스택 포인터들(MSP_NS, PSP_NS)을 이용하여 액세스됨) 및 덜 안전한 데이터(114)를 포함할 수 있다. 유사하게 안전한 영역들(104)은 안전한 프로그램 코드(122) 스택 데이터 구조들(124)(안전한 스택 포인터들(MSP_S, PSP_S)을 이용하여 액세스됨) 및 안전한 데이터(126)를 포함할 수 있다. 다시, 안전한 영역(104) 또는 덜 안전한 영역(102) 내의 프로그램 코드, 스택 및 데이터가 도 4에 도시된 바와 같이 연속되는 블록들에 조직화될 필요는 없고, 실제로 스택 및 프로그램 코드는 다른 데이터와 함께 배치된 다수의 불연속 블록들에서 분포될 수 있다. 어드레스들의 실행가능 범위 내의 메모리의 특정 할당이 프로세싱 시스템 상에서 실행되는 소프트웨어에 의해 선택될 수 있고 하드웨어에 의해 고정되지 않는다.
도 4에 도시된 바와 같이, 메모리 어드레스 공간(100)은 예약 영역(130)을 포함하고, 이는 이러한 예에서 0xF0000000 이상의 어드레스들을 포함한다(16진수로 표현됨 - 다른 예들이 상이한 어드레스 범위를 예약 영역(130)으로서 선택할 수 있음이 이해될 것이다). 예약 영역(130)은 실행가능 명령어들을 제공하도록 허용되지 않는 어드레스들의 범위를 표현한다. 이러한 예약된 어드레스들 중 일부는 아래 더 설명되는 바와 같이 함수 복귀 또는 예외 복귀를 나타내는 것과 같은, 특수 목적을 위해 배정될 수 있다. 예약된 어드레스들(130) 중 하나로부터 명령어를 페치하려는 시도가 이루어지는 경우, 명령어 페치 스테이지(8)는 결함을 시그널링할 수 있다. 이러한 예약된 어드레스들은 향후 버전들의 아키텍처가 특수 목적을 위하여 추가 어드레스들을 할당하는 기회들을 제공하여, 이러한 어드레스들 중 하나로부터 명령어를 페치하려는 시도가 주어진 이벤트가 프로세싱되는 것을 시그널링하는 것으로 해석될 수 있도록 할 수 있다.
도 5에 도시된 바와 같이, 예약된 어드레스들의 범위 중 일부는 특정 도메인/모드 전이 및 예외 복귀 동작들을 위한 함수 복귀를 나타내는 데 사용되는 특수한 더미 함수 복귀 어드레스(140) 및 더미 예외 복귀 어드레스(142)를 나타내도록 할당된다. 더미 함수 복귀 어드레스(140)는 특정 함수 복귀 선두 값(144)에 설정된 비트들(144) 중 그것의 가장 중요한 부분을 갖는 예약된 범위(130) 내의 어드레스들의 임의의 그룹이다. 이 예에서, 함수 선두는 0xF0 이상의 값을 가져서 더미 함수 복귀 어드레스가 예약된 범위(130) 내에 있도록 한다. 더미 함수 복귀 어드레스는, 그 더미 함수 복귀 어드레스로부터의 명령어를 페치 또는 실행하려는 시도가 이루어지는 경우, 함수 복귀 동작이 수행되어야 함을 신호하는 데 사용된다. 일부 구현예들에서 더미 예약된 어드레스에 (분기, 또는 PC를 타겟으로 하는 로드와 같은 일부 다른 명령어에 의해) 프로그램 카운터(PC)를 설정하려는 시도는 명령어 페치 대신에, 함수 복귀 동작을 트리거하는 것일 수 있다. 하드웨어를 단순화하기 위하여, PC를 설정할 수 있는 명령어들의 서브세트(통상적으로 함수 복귀를 수행하는 데 사용되는 것들)만이 실제로 함수 복귀 동작을 트리거할 수 있는 것일 수 있다. 이는 링크 레지스터(R14) 내의 모드간 또는 도메인간 함수 호출에 대해 실제 함수 복귀 어드레스를 노출할 필요를 피하기 위한 메커니즘을 제공함으로써, 덜 안전한 또는 덜 권한부여된 코드에 의해 액세스될 수 없다.
더미 함수 복귀 어드레스(140)는 모드간 또는 도메인간 함수 호출 수행 시, 함수 호출의 속성들 및/또는 대응하는 함수 복귀가 어떻게 핸들링될 지에 관한 정보를 나타내도록 설정될 수 있는 다수의 상태 정보를 포함한다. 이 예에서, 더미 함수 복귀 어드레스(140)는 더미 함수 복귀 어드레스가 핸들러 모드에서 스레드 모드로의 모드간 함수 호출에 응답하여 설정되었는지 아니면 동일한 모드 내에 남아 있던 (핸들러 모드 또는 스레드 모드에 남아 있는) 비-모드간 호출에 응답하여 설정되었는지 나타내는 모드간 호출 플래그(M)(146)를 포함한다. 이러한 예에서 모드간 호출 플래그(146)는 0의 값을 갖는 경우 모드간 호출을 나타내고, 플래그(146)가 1인 경우, 대응하는 함수 호출 동안 모드는 변경되지 않고 남도록 인코딩된다. 모드간 호출 플래그(146)는 현재 모드가 스레드 모드에서 핸들러 모드로 다시 전환되어야 하는지 아니면 변경되지 않고 유지되어야 하는지 결정하기 위하여 함수 복귀시 사용될 수 있다.
또한, 더미 함수 복귀 어드레스(140)는 대응하는 함수 호출이 덜 안전한 도메인으로부터 이루어졌는지 아니면 안전한 도메인으로부터 이루어졌는지 나타내는 안전한 도메인 표시자(들)(148)를 포함한다. 이 예에서, 보안 도메인 표시자는 호출이 안전한 도메인으로부터 이루어지는 경우 1로 설정되고 호출이 덜 안전한 도메인으로부터 이루어진 경우 0으로 설정되도록 인코딩된다. 더미 함수 복귀 어드레스(140)에 도시된 플래그들(146, 148)의 특정 인코딩은 단지 하나의 예이고 다른 접근법들은 상이한 인코딩을 사용할 수 있음을 이해할 것이다. 또한, 더미 함수 복귀 어드레스는 도 5에 도시되지 않은 추가적인 상태 플래그들을 포함할 수 있다. 일부 구현예들에서 보안 게이트웨이 명령어는 덜 안전한 도메인으로부터 호출가능한 안전한 함수들의 시작에 배치된다. 이 보안 게이트웨이 명령어는 프로세싱 회로부로 하여금 덜 안전한 도메인에서 안전한 도메인으로의 전이를 수행하게 할 수 있다. 따라서 후속 함수 복귀는 함수가 안전한 도메으로부터 호출되었는지 아니면 덜 안전한 도메인으로부터 호출되었는지 결정하고, 따라서 어느 도메인으로 실행이 복귀되어야 하는지 결정할 수 있고, 보안 게이트웨이 명령어는 보안 게이트웨이 명령어가 덜 안전한 도메인에서 안전한 도메인으로의 전이를 수행한 경우, 링크 레지스터 내의 복귀 어드레스의 최하위 비트를 소거할 수 있다. 나중에 계속 논의되는 바와 같이, S(148)를 더미 함수 복귀 어드레스의 최하위 비트에 배치하고, S(148) 표시자를 인코딩하여 0이 덜 안전한 도메인을 나타내도록 함으로써, 전술한 보안 게이트웨이 명령어 거동과 조합하여 사용될 때 추가 보안 보호를 제공할 수 있다. 전술한 구현예에서, S(148)의 값 0은 덜 안전한 상태를 나타내고, 보안 게이트웨이 명령어는 복귀 어드레스의 최하위 비트를 소거하지만, 원하는 행동은 또한 S(148) 필드의 다른 인코딩으로 달성될 수 있음을 이해할 것이다. 예를 들어 S(148)에 대한 1의 값이 덜 안전한 상태를 나타내는 경우, 보안 게이트웨이 명령어는 복귀 어드레스의 최하위 비트를 1로 설정할 것이다.
더미 예외 복귀 어드레스(142)는 특정 예외 엔트리 전이에 응답하여 링크 레지스터에 저장되고, 더미 함수 복귀 어드레스(140)와 유사한 방식으로 실제 예외 복귀 어드레스가 스택에 저장되게(그리고 순차적으로 그로부터 복원되게) 하고 예외에 후속하여 실행되는 덜 안전한 프로세스로부터 그것을 숨기기 위한 메커니즘을 제공한다. 더미 예외 복귀 어드레스(142)는 더미 예외 복귀 어드레스(142)의 최상위 비트 부분에 예외 복귀 선두(150)를 포함하고, 이는 다시 예외 복귀 어드레스가 예약된 범위(130) 내에 있도록 보장하기 위하여 0xF0이 상의 값을 갖는다. 예외 복귀 선두(150)는, 더미 함수/예외 복귀 어드레스들(140, 142)이 서로 구분될 수 있도록 함수 선두(144)와는 상이하다.
더미 예외 복귀 어드레스(142)는 예외가 발생한 모드(스레드 또는 핸들러)를 나타내기 위한 모드 플래그(152), 및 예외가 발생한 보안 도메인(안전한 또는 덜 안전한)을 나타내기 위한 안전한 도메인 플래그(들)(156)를 포함한다. 일부 구현예들에서 또한 예외가 원래 발생한 보안 도메인(안전한 또는 덜 안전한)을 나타내는 예외 보안 도메인 플래그(ES)(157)가 있을 수 있다. 또한, 예외 복귀 값은, 예외를 취하기 전에, TMID 플래그(34)가 도메인 전이가 스레드 모드에서 예외가 발생된 컨텍스트에서 디스에이블되었는지 아니면 인에이블되었는지 나타냈는지 여부를 나타내는 스레드 모드 상태간 인에이블(TMIE) 값(158)을 포함한다. 후퇴 호환성의 이유로 (158에 대응하는 비트를 1로 설정하는 것으로 예상되는 레거시 코드는 스레드 모드에서 도메인 전이를 인에이블함에 따라 TMIE 플래그(158)를 표현할 것임), 더미 예외 복귀 어드레스 내의 TMIE 플래그(158)는, 더미 예외 복귀 어드레스(142) 내의 TMIE 플래그(158)를 설정할 때 현재 안전한 도메인에 대한 TMID 플래그의 값이 반전되도록, 제어 레지스터(32) 내의 TMID 플래그(34)에 대하여 반대의 인코딩을 갖는다. TMIE 플래그(158)는 자체적으로 예외 복귀 동작을 제어할 필요는 없지만, TMIE 플래그(158)를 더미 예외 복귀 어드레스에 저장하는 것은 효과적으로 컨텍스트 저장/복원 기능을 제공하여 예외로부터 복귀 시 복귀하는 프로세스에 대한 제어 레지스터(32) 내의 TMID 플래그(34)의 값은 예외가 발생하기 전에 그것이 있었던 상태로 복원될 수 있도록 한다. 예외로부터 복귀 시, TMIE 플래그(158)의 값은 다시 반전되고, 반전된 값은 제어 레지스터(32) 내의 TMID 플래그(34)에 기록된다. 도 5는 TMIE 플래그(158)에 대한 특정 인코딩을 도시하지만, 이 인코딩은 필수적이지 않고 TMID(34)에 복원될 값을 표현하는 다른 방법들이 사용될 수 있다.
유의할 점은 더미 함수 복귀 어드레스(140) 및 더미 예외 복귀 어드레스(142)에 기록된 상태 정보(146, 148, 152, 156, 157, 158)는 상이한 값들을 취할 수 있음에 따라, 각각 더미 함수 복귀 어드레스들(140)로서 거동하는 예약된 범위(130) 내의 다수의 상이한 어드레스들, 및 각각 더미 예외 복귀 어드레스(142)로서 거동하는 다수의 상이한 어드레스들이 있게 된다는 것이다. 따라서, 함수 호출 시 또는 예외 진입 시 링크 레지스터(R14)에 저장되는 특정 더미 어드레스는 상태 플래그들에 인코딩될 정보에 기초하여 선택된다.
도 6은 모드간 또는 도메인간 함수 호출을 수행 시, 또는 예외에 진입 시 메모리 내의 스택 데이터 구조에 저장될 수 있는 상이한 스택 프레임들의 예들을 도시한다. 스택 프레임이 저장되는 특정 스택 데이터 구조는 함수 호출 또는 예외의 시간에 현재 모드 및 안전한 도메인에 따라 달라지며, 현재 스레드 모드에 있는 경우 선택된 스택은 또한 전술된 바와 같이 현재 도메인과 연관된 스택 포인터 선택 값(30)에 따라 달라진다.
도 6의 일부(170)에 도시된 바와 같이, 도메인간/모드간 함수 호출(모드 또는 도메인의 어떠한 전이도 트리거하지 않음) 이외의 함수 호출의 경우, 스택 프레임은 스택에 저장될 필요가 없는데, 그 이유는 동일한 모드 및 도메인 내의 함수 호출들의 경우 실제 함수 복귀 어드레스는 단순히 링크 레지스터(R14)에 저장될 수 있고 함수 호출 후에 실행되는 코드로부터 함수 복귀 어드레스를 숨길 필요가 없기 때문이다.
안전한 도메인에서 덜 안전한 도메인으로의 도메인간 함수 호출 또는 모드간 함수 호출의 경우, 함수 복귀 스택 프레임(172)이 스택에 저장된다. 안전한 도메인에서 덜 안전한 도메인으로의 도메인간 함수 호출의 경우, 스택 프레임(172)은 안전한 스택 포인터들 중 하나에 의해 표시되는 안전한 스택에 저장된다. 도메인간 함수 호출이 핸들러 모드로부터 이루어지는 경우 이는 안전한 메인 스택 포인터(MSP_S)가 될 것이지만, 도메인간 호출이 스레드 모드로부터 이루어지는 경우, 스택 프레임은 포인터가 안전한 도메인에 대하여 스택 포인터 선택 값(30-S)에 의해 표시되는 안전한 메인 스택(MSP_S) 및 안전한 프로세스 스택(PSP_S) 중 하나에 저장된다. 모드간 함수 호출의 경우, 이들은 핸들러 모드로부터 만들어진 결함에 의한 것이고, 따라서 현재 안전한 도메인과 연관된 메인 스택 포인터가 사용된다.
도 6에 도시된 바와 같이, 함수 복귀 스택 프레임(172)은 호출된 함수로부터 복귀할 때 프로세싱이 복귀할 실제 함수 복귀 어드레스를 나타내는 복귀 어드레스(174)를 포함한다. 실제 함수 복귀 어드레스는 함수 호출 분기 명령어의 어드레스로부터 순차적으로 후속하는 다음 명령어의 어드레스로 설정될 수 있다. 또한, 함수 복귀 스택 프레임은 대응하는 함수 복귀를 핸들링하는 방법을 결정하기 위한 정보를 제공하는 상태 데이터 워드(176)(FRETPSR)를 포함한다. 이 예에서, 함수 복귀 스택 프레임(172)이 핸들러 모드에서 스레드 모드로 이루어지는 모드간 함수 호출에 응답하여 저장되었는지 여부를 나타내는 스레드 모드(HDT) 플래그(178)에 대하여 권한박탈된 핸들러를 포함한다. 예를 들어 HDT 플래그는, 함수 호출이 모드간 함수 호출이 아니었고 그래서 핸들러 모드가 스레드 모드에 대하여 권한박탈되게 하지 않은 경우 0의 값을 가질 수 있고, 함수 호출이 모드간 함수 호출이었을 경우, 1의 값을 가질 수 있다. 또한 상태 데이터 워드(176)는 함수가 호출되었을 때 예외 번호 레지스터(36)의 값에 대응하는 예외 번호 값(179)을 포함한다. 이는 함수 복귀 스택 프레임이 핸들러 모드로부터 호출된 함수에 응답하여 저장되었는지 아니면 스레드 모드로부터 호출된 함수에 응답하여 저장되었는지 나타내는 "핸들러 모드 표시 값"의 역할을 한다. 다른 정보가 또한 함수 복귀 상태 워드(176) 내에 저장될 수 있거나, 또는 함수 복귀 스택 프레임(172)의 다른 부분들 내에 저장될 수 있음을 이해할 것이다.
예외 스택 프레임들(180, 182)의 예들이 도 6의 상부에 도시되어 있다. 예외에 응답하여, 제1(호출자) 스택 프레임(180) 및 제2(피호출자) 스택 프레임(182) 중 하나 또는 둘 모두가 스택에 저장된다. 성능상 이유로, 예외 엔트리 이벤트들에 응답하여 저장될 필요가 있을 수 있는 레지스터들을 "호출자" 레지스터들 및 "피호출자" 레지스터들로 지칭되는 2개의 그룹으로 분할하는 것이 유용할 수 있다. 호출자 레지스터들은 하드웨어에서 구현되는 예외 제어 회로부(28)가 스택에 저장하는 것을 담당하는 레지스터들이다. 따라서, 예외 핸들러의 소프트웨어가 호출자 레지스터들을 스택 데이터 구조에 저장하기 위한 명령어들을 포함할 필요가 없다.
도 6에 도시된 바와 같이, 호출자 레지스터들(호출자 스택 프레임(180)에 포함됨)은 범용 레지스터들의 서브세트를 포함할 수 있다. 이 예에서, 호출자 상태는 범용 레지스터들(R0, R1, R2, R3, R12), 링크 레지스터(LR)(R14), 예외의 프로세싱 후에 프로세싱이 복귀될 복귀 어드레스(181)의 표시(이는 예외가 적용된 시점에 프로그램 카운터 레지스터(R15)로부터 도출된 값으로 설정될 수 있음), 및 조건부 명령어들의 결과물들을 제어하기 위한 조건 코드들 및 프로세싱의 현재 상태에 관련된 기타 상태 정보를 제공할 수 있는 프로그램 상태 레지스터(XPSR) 내의 값들에 기초하여 설정되는 예외 복귀 프로그램 상태 값(ERETPSR)을 포함한다. ERETPSR은 또한 프로세싱의 예외 번호(36)가 예외 발생 전에 수행되는 것을 명시할 수 있으며, 이는 예외 발생 전에 프로세싱 회로부가 스레드 모드에서 동작하고 있었던 경우 0의 디폴트 값을 가질 수 있다. 이는 레지스터 상태가 호출자 레지스터 상태에 포함될 수 있는 단지 하나의 특정 예라는 것을 이해할 것이다. 일부 예들은 또한 호출자 스택 프레임 내에 부동소수점 레지스터 상태를 포함할 수 있고, (예컨대 실행되는 스레드가 부동소수점 상태를 인에이블되게 했는지에 따라) 부동소수점 레지스터 상태가 포함되어야 하는지 여부가 구성가능할 수 있다.
호출자 스택 프레임(180)만이 스택에 저장되는 예외들의 경우, 예외 이벤트에 응답하여 예외 제어 회로부(28)에 의해 호출자 스택 프레임(180)이 스택에 저장된 후에, 예외 핸들링 코드의 실행이 시작할 수 있고, 이어서 예외 핸들러 소프트웨어는 그것의 실행 동안 이 상태를 덮어쓸 것이라고 아는 경우, 추가적인 피호출자 레지스터들로부터의 상태를 스택 상에 저장할 수 있다. 그러나, 예외 핸들러에 의한 이 상태 저장은 예외 핸들러 코드에서 제공되는 로드/저장 명령어들에 응답하여 프로세싱 회로부(4)의 로드/저장 유닛을 제어하여 관련 데이터를 메모리에 저장하게 됨으로써 수행되고, 이는 예외 제어 회로부(28)가 하드웨어의 스태킹을 제어하는 경우보다 더 느릴 수 있다. 그러나, 호출자와 피호출자 레지스터 상태 사이에 파티션을 허용하여, 예외가 진입된 후에 실행되는 소프트웨어가 어느 레지스터들이 저장될 필요가 있는지 영향을 줄 수 있도록 하는 것이 유리할 수 있다. 예외 핸들러가 특정 피호출자 레지스터(예를 들어, 범용 레지스터(R7))에 결코 액세스하지 않는다면, 예외 핸들러는 대응하는 아키텍처 상태를 저장할 필요가 없으며, 예외 제어 회로부(28) 및 하드웨어에 이 상태 저장을 수행하는 것과 연관된 에너지 및 시간이 또한 회피되었다. 예외 핸들러들에 대한 코드의 라이터(writer)들, 또는 이러한 코드의 컴파일러들은 소프트웨어의 추가적인 상태 저장이 필요할 가능성을 낮추기 위해 추가적인 피호출자 레지스터들을 이용하기 전에 먼저 호출자 레지스터들을 사용하도록 장려될 수 있다.
그러나, 예외 엔트리가 안전한 도메인에서 덜 안전한 도메인으로의 전이를 야기하고 원래 백그라운드 프로세싱이 예외 전에 안전한 도메인에서 수행되는 경우, 호출자 레지스터들만이 예외 제어 회로부(28)에 의해 메모리에 저장된다면, 레지스터 뱅크(14) 내에서 실행가능한 피호출자 레지스터들을 마지막 예외 후에 실행될 덜 안전한 예외 핸들러에 남겨둘 수 있다. 이는 바람직하지 않을 수 있는데, 그 이유는 피호출자 레지스터들이 메모리 어드레스 공간의 안전한 영역들로부터 도출된 정보를 포함할 수 있기 때문이며, 이는 그렇지 않으면 SAU(24)에 의해 덜 안전한 예외 핸들러가 액세스하는 것이 금지되었을 것이다.
따라서, 백그라운드 프로세싱이 이전에 안전한 도메인에서 수행된 안전한 도메인에서 덜 안전한 도메인으로의 특정 전이의 경우, 예외 제어 회로부(28)는, 호출자 레지스터들을 저장하는 것에 더하여, 또한 피호출자 레지스터들을 관련 스택 데이터 구조에 저장할 수 있고 저장된 레지스터들(호출자 및 피호출자 레지스터들을 포함)의 콘텐츠를 소거할 수 있다. 따라서, 하드웨어에 추가적인 상태 저장을 수행함으로써, 피호출자 레지스터들을 정상적으로 저장할 덜 안전한 소프트웨어가 예외 발생 전에 이 레지스터들에 저장된 잠재적으로 안전한 정보에 대한 액세스를 획득할 수 없게 된다.
따라서, 특정 예외 엔트리 전이의 경우, 호출자 스택 프레임(180)을 저장하는 것에 더하여, 제2(피호출자) 스택 프레임(182)은 또한 스택에 저장될 수 있다(예외 제어 회로부(28)에 의한 하드웨어 제어 하에서, 즉 프로세싱 회로부(4)에 의해 실행될 명시적인 로드/저장 명령어들을 필요없이). 유의할 점은 도 6에서 피호출자 스택 프레임은 호출자 스택 프레임과는 별개의 스택 프레임으로서 참조되지만, 다른 것들은 180, 182의 조합이 단일 스택 프레임으로 보이도록, 피호출자 스택 프레임을 호출자 스택 프레임의 연장으로서 볼 수 있다는 것이다. 두 접근법은 동등한 것으로 볼 수 있다.
피호출자 스택 프레임(182)은 호출자 스택 프레임(180)에 저장되지 않았던 레지스터들(R4 내지 R11)을 포함하는 추가적인 피호출자 상태를 포함한다. 옵션적으로 부동소수점 컨텍스트가 또한 피호출자 스택 프레임(182)에 포함될 수 있다. 하드웨어에 의해 저장된 추가 상태는 또한 사전결정된 무결성 서명(190)을 포함할 수 있다. 무결성 서명(190)은, 호출자 및 피호출자 상태 둘 모두가 예외 제어 하드웨어(28)에 의해 저장되지만 호출자 예외 스택 프레임(180)으로부터 누락되는 경우, 피호출자 스택 프레임(182)에 포함된다. 무결성 서명(190)은 예약된 범위의 비-실행가능 어드레스들(130) 중 하나에 대응하는 값을 가지며, 따라서 그것으로부터 명령어를 페치하려는 시도가 있는 경우, 결함이 신호될 것이다. 무결성 서명(190)은 임의의 유효 더미 함수 복귀 어드레스(140) 또는 더미 예외 복귀 어드레스(142)와 매칭될 수 없는 값을 가질 수 있다. 무결성 서명(190)은 안전한 도메인과 덜 안전한 도메인 사이의 파티셔닝을 보강하는 하드웨어에 의해 제공되는 보안 보호를 회피하려고 시도하는 프로세싱 회로부 상에 장착될 수 있는 특정 형태들의 공격을 검출하는 데 사용될 수 있다. 하나의 가능한 공격 경로는 공격자가 예외의 프로세싱에 진입하기 위하여 예외 엔트리 전이를 수행하려고 시도하지만, 이어서 나중에 함수 복귀 전이를 수행하는 것과 같은 예외 엔트리로부터 복귀하도록 예상되는 것으로의 상이한 유형의 복귀 전이를 위조하는 것일 수 있다. 서명(190)은 함수 복귀 어드레스(174)를 저장하기 위하여 함수 복귀 스택 프레임(172)에 사용되는 상대적 위치와 동일한 스택 프레임 상의 상대적 위치에 위치된다. 따라서, 함수 복귀 시 복귀 어드레스(174)가 무결성 서명(190)과 매칭되는 것(또는 비-실행가능 예약된 어드레스(130) 중 임의의 것에 대응하는 것)이 검출되는 경우, 결함이 트리거될 수 있는데, 그 이유는 함수 복귀를 수행하는 데 사용되는 스택 프레임이 실제로 예외 엔트리 이벤트에 응답하여 스택에 저장되었기 때문이고, 이는 공격이 수행되고 있다는 표시자일 수 있다. 또한, 피호출자 레지스터들과 연관된 추가 아키텍처 상태가 스택 상에 존재하는 예외로부터 복귀 시, 보안 체킹의 일부는 무결성 서명(190)에 대응하는 스택 내의 관련 오프셋에서의 값이 예상 값을 갖는지 체크하는 것일 수 있는데, 그 이유는 서명의 결여는 예외 복귀 이벤트가 보안 위반의 위험이 다시 발생할 수 있는 함수 호출에 응답하여 메모리에 저장된 스택 프레임에 기초하여 수행되고 있음을 나타낼 수 있기 때문이다.
도 6에 도시된 바와 같이, 사전결정된 서명 값(190)의 일부로서, TMIE 크로스체크 값(192)은 사전결정된 서명(190)의 비트들 중 하나 내에 저장될 수 있다(따라서 실질적으로 사전결정된 서명(190)의 둘 이상의 유효 값들이 있을 수 있고, 이들 각각은 어드레스들의 예약된 범위(130) 내에 있지만, 더미 함수 복귀 및 더미 예외 복귀 값들에 사용되는 어드레스들과 분리된다). 피호출자 스택 프레임(182)이 저장되는 예외를 취할 때, TMIE 크로스체크 값(192)은 링크 레지스터 내의 더미 예외 복귀 어드레스(142)에 기록된 TMIE 플래그(158)의 상태를 나타내는 값으로 설정된다(예컨대 크로스체크 값(192)은 TMIE 플래그(158)와 동일할 수 있거나, 또는 TMIE 플래그(158)에 대하여 반전될 수 있거나, 또는 TMIE 플래그의 상태를 표현하기 위하여 다른 인코딩을 사용할 수 있다). 피호출자 스택 프레임(182)이 스택에 저장될 때, 안전한 도메인에서, 예외가 안전한 도메인 내에 있기 전에 원래 백그라운드 프로세싱이 수행되던, 덜 안전한 도메인으로 예외가 발생하고 있음을 나타내는 경우에, 예외에 후속하여 실행된 덜 안전한 코드가 안전한 코드가 예외 복귀에 후속하여 올바르게 기능하는 것을 막으려는 시도로 더미 예외 복귀 어드레스(142) 내의 TMIE 값을 수정할 수 있는 위험이 있을 수 있다. TMIE 크로스 체크 값(192)은 TMIE 값(158)의 변조를 검출하기 위하여 크로스 체크를 제공한다.
일부 시스템 구현예들에서, 때때로 특정 유형들의 예외가 권한없는 상태에서 실행되는 그것들의 예외 핸들러들을 갖는 것이 바람직할 수 있다. 이는 유용할 수 있는데, 그 이유는 신뢰할 수 없는 제3자에 의해 제공되는 라이브러리 코드에 의해 제어되는 디바이스들과 연관된 특정 유형들의 예외들의 경우, 신뢰할 수 없는 제3자에 의해 제공된 예외 핸들러가 핸들러 모드에 이용가능한 전체 권한들을 가질수 있게 하는 것은 바람직하지 않을 수 있기 때문이며, 그 이유는 그들은 예를 들어 특정 상태 정보를 수정하지 않는다고 신뢰될 수 없기 때문이다. 그러나, 도 2에 도시된 바와 같이 핸들러 모드는 권한부여된 상태에서 디폴트로 동작하고, 따라서 권한없는 상태에서 동작하는 예외 핸들러의 경우 다시 스레드 모드로 전환되도록 요구할 것이다. 그러나, 통상적인 구현예들에서 핸들러 모드에서 스레드 모드로 전환하기 위한 메커니즘은 예외 복귀를 통해 이루어질 것이다. 원래 예외가 예외 복귀를 트리거하는 것은, 원래 예외의 실행 우선순위를 떨어뜨리기 때문에, 일반적으로 바람직하지 않을 것이다(복귀 어드레스를 수정한 후에 복귀가 이전 백그라운드 프로세싱 대신에 권한없는 라이브러리 코드로 가게 됨). 이런 방식으로 실행 우선순위를 떨어뜨리는 것은 예외 핸들링 루틴이 올바르게 우선순위화되는 것을 방해할 수 있다. 따라서, 원래 예외를 핸들링하고 있는 핸들러 코드가 예외 복귀를 트리거하지 않고 스레드 모드로 전환할 수 있는 것이 가능하다면, 선호될 것이다.
일반적인 시스템들에서, 핸들러에서 스레드 모드로 전환하기 위한 메커니즘만이 예외 복귀를 통함에 따라, 도 7에 도시된 바와 같이, 원래 예외를 핸들링하기 위한 예외 핸들러를 권한박탈할 수 있도록 하기 위하여, 추가 예외가 생성되도록 요구할 것이고(예를 들어 감독자 호출 예외, SVC), 따라서 예외 복귀 스택 프레임은 예외 전에 수행되고 있는 실제 프로세싱 컨텍스트를 나타내지 않는 메모리에 설정될 수 있지만, 이전에 발생한 예외의 본체가 스레드 모드에서 권한없는 상태로 핸들링될 수 있도록 SVC 예외가 복귀될 때 프로세싱이 스레드 모드로 전환되는 것을 보장하기 위하여 위조된다.
예를 들어, 도 7에 도시된 바와 같이, 스레드 모드에서 스레드(T₁₎ 내의 일부 백그라운드 코드를 프로세싱할 때, 권한없는 라이브러리로 전달되는 유형인 인터럽트 IRQ가 발생한다. 도 7의 단계 1에서, 인터럽트는 예외 제어 회로부(28)로 하여금 스레드(T₁)의 레지스터 상태를 보존하기 위하여, 프로세스 스택에 레지스터 상태를 스태킹하는 것을 트리거하게 한다. 인터럽트는 스레드 모드에서 핸들러 모드로의 전이를 야기하는데, 그 이유는 예외들이 핸들러 모드에서 초기에 디폴트로 발생하기 때문이다. IRQ 예외를 처리하기 위한 예외 핸들러의 메인 본체(200)는 신뢰할 수 없는 라이브러리에 의해 실행될 것이지만, IRQ 예외를 처리하기 위한 예외 핸들러에는 메인 예외 핸들러 본체(200) 전후로 실행될 래퍼 코드(202)가 제공되는데, 래퍼 코드는 핸들러 모드에서 실행되고 메인 본체가 스레드 모드에서 핸들링될수 있도록 보장하기 위하여 SVC 예외를 생성하기 위한 동작들을 제어한다.
따라서, 도 7의 단계 2에서 핸들러 모드의 래퍼 코드는 SVC 예외를 생성하며, 이는 실제로 원래 IRQ 인터럽트를 처리하지 않지만 IRQ 핸들러가 스레드 모드로 전환하도록 단독으로 생성된다. SVC 예외는 예외 제어 회로부(28)로 하여금 현재 도메인과 연관된 메인 스택 포인터(MSP)에 의해 지목된 메인 스택으로 레지스터 상태의 스태킹을 수행하게 한다(현재 모드는 핸들러 모드이기 때문에, 메인 스택이 사용됨). SVC 예외에 응답하여 실행되는 SVC 예외 핸들러는 원래 IRQ 예외를 처리하기 위하여 메인 예외 핸들러 본체(200)를 실행하는 스레드(T_IRQ)와 연관된 상이한 스택 구조(PSP_IRQ)를 지목하도록 프로세스 스택 포인터를 전환한다. SVC 예외 핸들러는, 그것의 예외 복귀 상태 정보(ERETPSR)에서, 대응하는 예외 복귀는 스레드 모드로 복귀해야 한다고 나타내기 위한 0의 예외 번호를 나타내는 프로세스 스택 상의 스택 프레임을 위조한다. 유의할 점은 이 값은 위조이고, 그 이유는 SVC 예외 전에 수행되고 있던 프로세싱이 실제로 핸들러 모드에 있었기 때문이라는 것이다.
SVC 예외 핸들러가 완료되면, 단계 2에서 메인 스택 상에서 생성된 예외 스택 프레임보다는 PSP_IRQ에 의해 지목된 스택 상에서 생성된 위조 예외 복귀 스택 프레임을 이용하여 예외 복귀를 트리거하는 위조 더미 예외 복귀 어드레스로의 분기를 야기한다. 이어서 예외 제어 회로부(28)에 의해 예외 복귀가 수행되는데, 이는 도 7의 단계 3에서 PSP_IRQ 스택으로부터 하드웨어 스택해제를 야기한다. 하드웨어는 위조 더미 예외 복귀 어드레스(142) 내의 M 비트(152)가 복귀가 스레드 모드로 되어야 한다고 나타내는 것을 검출하고, 따라서 단계 4에서 IRQ 예외를 처리하기 위한 예외 핸들러(200)의 후속 메인 본체는 스레드 모드에서 권한없는 라이브러리에 의해 실행될 수 있다. 유의할 점은 이는 원래 IRQ 예외로부터 복귀 없이 수행되었고, 따라서 IRQ 예외를 처리하기 위한 예외 핸들러의 우선순위는 떨어지지 않았다는 것이다.
메인 예외 핸들러 본체(200)가 완료되면, 단계 5에서 다른 SVC 예외 호출이 이루어지는데(SVC는 예상치 못하거나 또는 결함이 있는 이벤트에 의해 트리거되는 예외의 유형이 아니라, 소프트웨어에 의해 자발적으로 트리거될 수 있는 예외의 유형이다), 이는 다시 PSP_IRQ에 의해 지목되는 프로세스 스택으로의 추가적인 하드웨어 스태킹을 야기하고, 호출된 SVC 핸들러는 이어서 단지 PSP_IRQ 에 의해 지목된 프로세스 스택 상에서 생성된 스택 프레임을 파괴하고, 이어서 현재 안전한 도메인에 대한 프로세스 스택 포인터를 업데이트하여 백그라운드 스레드(T₁)와 연관되었던 이전 스택 포인터(PSP₁₎를 복원한다. 도 7의 단계 6에서 SVC 예외는 예외 복귀를 생성하고, 이는 이어서 MSP를 이용하여 메인 스택으로부터 추가 하드웨어 스택해제를 트리거하고(즉 단계 2 동안 생성된 스택 프레임을 스택해제함) 이어서 임의의 나머지 래퍼 함수들(202)을 핸들러 모드에서 실행한 후에, 이어서 단계 7에서 PSP₁에 의해 지목된 프로세스 스택으로부터 스레드(T₁)와 연관된 레지스터 상태의 하드웨어 스택해제를 야기하는 추가 예외 복귀가 생성된다(즉 단계 1 동안 생성된 스택 프레임을 스택해제함). 이어서 프로세싱은 스레드 모드에서 실행되는 스레드(T₁)의 백그라운드 코드에서 계속된다.
도 7에 도시된 프로세스는 특정 유형들의 예외들이 권한박탈되게 하여 그것들의 예외 핸들러들이 스레드 모드에서 동작하도록 한다. 그러나, 그것은 다수의 단점들을 갖는다. 첫째로, 요구되는 예외 스택 프레임들의 위조로 인해 이 프로세스를 제어하기 위한 소프트웨어 코드를 생성하는 것이 어렵고, 따라서 프로그래머들에 의해 에러가 발생하기 쉬울 수 있는데, 이는 공격자가 악용할 수 있거나 또는 시스템이 올바르게 기능하는 것을 막을 수 있는 취약성을 제공할 수 있거나, 또는 공격자가 암호 키와 같은 비밀 값들을 빼내는 방법을 제공할 수 있다.
다른 단점은 이 접근법이 작동하기 위하여, (위조 스택 프레임을 생성하고 원래 예외로부터 복귀하기 전에 소거하기 위하여 메인 예외 핸들러 본체(200)의 시작과 종료 시에 수행되는) SVC 예외들의 예외 우선순위가 권한박탈될 필요가 있는 모든 인터럽트 IRQ의 우선순위보다 높아야 한다는 것이다. 이는 실시간 시스템들의 설계를 훨씬 더 복잡하게 만들 수 있는데, 그 이유는 SVC 예외들이 항상 동일한 우선순위를 취하게 되고, 그럼으로써 최악의 경우 다른 IRQ 예외들에 대한 인터럽트 레이턴시가 가장 긴 SVC 호출의 듀레이션만큼 길어지기 때문이다. 이는 바람직하지 않을 수 있다.
또한, 도 7에 도시된 접근법은 매우 느린데, 이것이 치명적인 인터럽트 레이턴시를 갖는 권한없는 라이브러리들의 사용에 대한 주요 차단장치이다. 이러한 열악한 성능은, 도 7의 단계들(2, 3) 사이에서 SVC 예외를 프로세싱할 때 예외 스택 프레임들의 수동 생성 및 도 7의 단계들(2, 3, 5, 6)에서 4개의 추가 레지스터 상태 스택 및 스택해제 이벤트를 트리거하는 2개의 상이한 SVC 예외가 요구된다는 사실을 포함하는 여러 요인들에 기인하며,이는 IRQ를 처리하기 위한 예외 핸들러가 단순히 핸들러 모드에서 실행된다면 필요하지 않을 메모리 액세스 레이턴시를 나타낸다. 따라서, 성과 비용은 일부 시스템 설계자들이 신뢰할 수 없는 라이브러리 코드와 연관된 무선 네트워크 인터페이스들 또는 USB 제어기들과 같은 디바이스들을 손쉽게 사용할 수 없다고 느끼는 것일 수 있고, 이것이 시스템 설계의 유연성을 제한할 수 있음을 의미할 수 있다. 도 7의 하부에 도시된 바와 같이, 전체 권한박탈 프로세스는 이 예에서 덜 안전한 도메인에서 수행되지만, 프로세스는 또한 안전한 도메인 내에서 수행될 수 있음이 이해될 것이다.
도 8은 예외 권한해제의 성능을 개선하기 위하여 본 출원에서 기술된 바와 같이 모드간 호출 분기 명령어를 이용하는 대안적인 접근법을 도시한다. 명령어에 의해 명시되는 타겟 어드레스에서 명령어로 분기하고 함수가 완료되면 프로세싱이 복귀해야 하는 어드레스를 나타내도록 함수 복귀 어드레스를 설정할 수 있는 모드간 호출 분기 명령어를 제공할 뿐만 아니라, 핸들러 모드에서 스레드 모드로의 전환을 트리거함으로써, 인터럽트들은 훨씬 더 빨리 권한박탈될 수 있고 성능 충돌, 복잡성 및 도 7에 도시된 접근법과 연관된 전술된 기타 이슈들을 감소시키게 된다. 이 접근법을 이용하면, 권한없는 상태에서 핸들링되는 IRQ 예외에 대한 응답이 훨씬 더 간단해질 수 있다.
도 8의 단계 1은 도 7에서와 동일하다. 단계 2에서 메인 인터럽트 핸들러 본체(201)의 실행을 준비하기 위한 일부 래퍼 코드(203)가 실행되는데, 이는 그것의 마지막 명령어로서 메인 인터럽트 핸들러 본체(201) 전에 모드간 호출 분기 명령어를 가지며, 모드간 호출 분기 명령어는 분기 타겟 어드레스로서 메인 예외 핸들러 본체(201)에서 실행될 제1 명령어의 어드레스를 명시한다. 일부 운영 체제들에서 래퍼(203)는 SVC 예외를 트리거하는 대신에 모드간 분기 명령어를 실행하는 것을 제외하고 래퍼(202)와 동일할 수 있다. 일부 구현예들에서 모드간 호출 분기 명령어는 핸들러에서 스레드 모드로 전이되지 않는 비-모드간 호출 분기 명령어에 대한 명령어 인코딩과는 상이한 전용 명령어 인코딩일 수 있다. 따라서, 도 8의 단계 3에서, 모드간 호출 분기 명령어의 실행은 핸들러 모드에서 스레드 모드로의 전환을 트리거하고, 메인 예외 핸들러 본체(201)는 계속해서 스레드 모드에서 도 8의 단계 4를 실행한다. SVC 예외가 호출될 필요가 없다.
모드간 함수 호출 시, 정보는 더미 함수 복귀 어드레스(140)에 저장되어 (모드간 호출 표시자(146)를 이용하여) 함수 호출이 모드간 호출이었음을 나타낼 수 있고, 대응하는 함수 복귀가 도 8의 단계 5에서 트리거되면 프로세싱 회로부(4)는 표시자(146)를 검출하고, (함수 복귀 스택 프레임(178)에 저장된) 이전 함수 호출과 연관된 함수 복귀 어드레스(174)로의 복귀에 더하여, 현재 모드가 또한 스레드 모드에서 핸들러 모드로 다시 전환되어야 함을 검출할 수 있다. 이어서 도 8의 단계 6에서 일부 나머지 래퍼 코드(203)가 핸들러 모드에서 실행되고, 후속하는 단계 7에서 핸들러에서, IRQ 예외가 발생하기 전에 실행되고 있었던 백그라운드 스레드(T₁)로 복귀하는 예외 복귀가 수행된다. 일부 시스템들에서 메인 인터럽트 핸들러 본체(201)(도 8)는, 권한없는 메인 인터럽트 핸들러 본체로부터 복귀하도록 SVC 예외를 트리거하는 대신에, 도 8의 단계 3에서 링크 레지스터에 배치된 더미 함수 복귀 어드레스(140)로 간단히 분기함으로써 복귀가 요청될 수 있는 것을 제외하고, 메인 인터럽트 핸들러 본체(200)(도 7) 예외와 동일할 수 있다. 이와 같이 메인 인터럽트 핸들러 본체(201)(도 8)는 표준 C 함수일 수 있고, 어떠한 특별한 핸들링도 필요로 하지 않는다.
따라서, 이 접근법을 이용하면, 요구되는 하드웨어 스택 및 스택해제 동작들만이 백그라운드 코드(T₁)와 연관된 레지스터 상태를 저장 및 복원하기 위한 것들이고, 2개의 SVC 예외와 연관된 추가 하드웨어 스택 및 스택해제 동작들은 필요가 없다. 또한, 이 접근법은 컴파일러들 또는 프로그래머들이 코딩하기에 훨씬 쉬어서, 에러의 가능성을 낮추고, SVC 예외들이 권한박탈될 모든 예외들보다 더 높은 우선순위를 가질 필요가 없다.
안전한 도메인들을 전환하는 기회들의 수를 제한함으로써 보안을 개선하기 위해, 모드간 함수 호출은 안전한 도메인들을 변경하도록 허용되지 않을 수 있지만, 모드들 사이에서 변경될 수는 있다. 따라서, 모드간 함수 호출 분기 명령어를 실행할 때, 프로세싱 회로부(4)는 현재 안전한 도메인을 모드간 함수 호출 분기 명령어의 실행 이전과 동일하게 유지할 수 있다. 도 9에 도시된 바와 같이 덜 안전한 스레드 모드에서 안전한 핸들러 모드로의 도메인/모드 조합 함수 복귀 전이는 보안을 보존하기 위하여 금지될 수 있다. 이는 안전한 도메인으로의 복귀가 모드간 함수 복귀 시 요청되고 있는지 여부에 대한 명시적인 체크에 의해 보강될 수 있고, 만약 그것이 검출되면 결함이 트리거될 수 있고, 이는 아래 도 15를 참조하여 설명되는 바와 같다.
그러나, 모드간 함수 복귀의 경우, 도 10에 도시된 바와 같이 적어도 모드간 함수 복귀가 안전한 스레드 모드에서 덜 안전한 핸들러 모드인 경우에는 모드/도메인 조합 전이를 허용하는 것이 바람직할 수 있다. 이는 컴파일러들이 도 11a 내지 도 11c에 도시된 바와 같이 꼬리 호출로 알려진 기술을 사용하게 할 수 있다. 일부 구현예들에서, 보안상의 이유로, 안전한 함수 호출에서 덜 안전한 함수 호출로의 꼬리 호출은 이미 금지될 수 있다. 이와 같이, 도 10에 도시된 덜 안전한 핸들러 모드간 복귀 전이에 대하여 안전한 스레드를 지원할 필요가 있을 수 있지만, 도 9에 도시된 안전한 핸들러 모드간 복귀 전이에 대하여 덜 안전한 스레드를 지원할 필요는 없을 수 있다.
도 11a에 도시된 바와 같이, (프로세싱 시스템의 명령어 디코더(10)에 의해 지원되는 어셈블리 코드로 컴파일될) 일부 높은 레벨 코드는 제2 함수 fn2가 제1 함수 fn1 내에서 호출되는 삽입된 함수 호출들을 포함할 수 있고, 함수 fn2에 대한 호출의 위치는 fn2의 종료와 fn1의 종료 사이에 fn1의 추가적인 명령어들이 없도록 한다.
이 시나리오에서, 도 11b에 도시된 바와 같이, 어셈블리 코드를 생성하는 컴파일러에 대한 한가지 옵션은, fn1 및 fn2에 대한 호출들의 각각에 대하여, 함수 복귀 어드레스의 링크 레지스터(LR)(R14)로의 저장 및 함수를 위한 그 함수 코드의 시작을 나타내는 타겟 어드레스로의 분기를 트리거하는 호출 분기 명령어(BL, 또한 분기-및-링크 명령어로 알려짐)를 생성는 것일 수 있고, 프로세싱이 이전에 링크 레지스터에 저장된 복귀 어드레스로 복귀해야 한다고 나타내는 함수 복귀 명령어(그것의 어드레스 피연산자들로서 링크 레지스터를 명시하는 간접 분기 명령어(BX))가 후속한다. fn1을 호출하기 위한 호출 분기 명령어는 도 11b에 도시되지 않는데, 그 이유는 그것이 fn1을 호출한 코드의 일부일 것이고, 도 11b는 fn1 및 fn2에 대한 함수 코드만을 도시하기 때문이다. 따라서, fn1에 대해 컴파일러는 (fn2를 호출하기 위한) BL 명령어(283) 및 (fn1에서 fn1을 호출한 코드로 복귀하기 위한) BX 명령어(286)를 생성한다. fn2에 대해 컴파일러는 fn2에서 fn1을 복귀하기 위한 BX 명령어(284)를 생성한다. fn2를 호출할 때 fn1을 위한 복귀 어드레스가 보존되도록 보장하기 위하여, fn1 코드는 또한 fn2를 호출하기 전에 링크 레지스터의 콘텐츠를 스택에 밀어넣기 위한 푸시 명령어(282), 및 fn1로부터 복귀하기 전에 스택으로부터 링크 레지스터를 복원하기 위한 팝 명령어(285)를 포함한다. 실제로, fn2는 fn1 내에서 수행될 마지막 활동이기 때문에, 함수 1의 링크 레지스터의 스택에 대한 이러한 푸시 및 팝은 일부 불필요한 메모리가 성능 과다되는 것을 유발한다.
따라서, 도 11c에 도시된 바와 같이 함수들을 컴파일하기 위한 대안적인 접근법은 링크 레지스터를 업데이트하지 않고, 실질적으로 fn1을 위해 링크 레지스터에 저장된 복귀 어드레스를 fn2에 전달하는 비-호출 분기 명령어(287)를 이용하여 fn2와 연관된 코드를 호출하는 것일 수 있다. 이는 최종 복귀 분기(288)가 실행되면 프로세싱이 fn1 전에 프로세싱되고 있던 백그라운드 코드로 다시 복귀함을 의미한다. 이 접근법은 꼬리 호출로 알려져 있고, PUSH(282), POP(285), 및 BX(286) 명령어들에 대한 필요성을 회피함으로써 성능을 개선할 수 있다.
그러나, 함수 1이 덜 안전한 스레드 모드에 있고 도 10의 예에 도시된 바와 같이 모드간 함수 호출에 의해 호출되고 함수 2가 안전한 스레드 모드에 있고 도메인간 함수 호출로 호출(덜 안전한 도메인(NS)에서 안전한 도메인(S)으로 호출)되는 시나리오에서, 복귀 분기 명령어(288)에 후속하여 꼬리 호출을 지원하는 것은 안전한 스레드 모드에서 덜 안전한 핸들러 모드로의 복귀 방향을 트리거할 필요가 있게 된다. 도메인/모드 조합 전이가 지원되지 않는다면, 많은 기존 레거시 코드가 재컴파일될 필요가 있을 수 있는 꼬리 호출은 가능하지 않을 것이며, 따라서 안전한 스레드 모드에서 덜 안전한 핸들러 모드로 전이될 때 도메인/모드 조합 전이를 지원하는 것이 더 효율적일 수 있다. 그럼에도 불구하고, 덜 안전한 도메인에서 안전한 도메인으로 이동하는 모드간 함수 복귀를 금지함으로써, 보안을 개선하는데, 그 이유는 안전한 도메인에 들어갈 수 있는 경로들 을 제한하기 때문이다. 앞서 설명한 바와 같이, 이러한 전이의 조합에 대한 수요가 없을 수 있는데, 그 이유는 안전한 도메인에서 덜 안전한 도메인으로의 꼬리 호출은 이미 레거시 코드-에서 금지될 수 있기 때문이다.
도 12는 함수 호출 분기 명령어(BLX)에 응답하여 수행되는 단계들을 도시하는 흐름도이다. 단계들은, 함수 호출 분기 명령어로서 식별된 명령어의 디코딩에 응답하여, 명령어 디코더(10)의 제어 하에, 프로세싱 회로부(4)에 의해 수행된다. 단계(300)에서 함수 호출 분기 명령어가, 상이한 명령어 인코딩에 의해 다른 유형들의 함수 호출 분기 명령어와 구분되는 특정 유형의 함수 호출 분기 명령어인, 모드간 호출 분기 명령어인지 결정된다. 예를 들어 모드간 호출 분기 명령어는 비-모드간 호출 분기 명령어들과는 상이한 op코드를 가질 수 있거나, 또는 동일한 op코드를 갖지만 그것이 모드간 호출 분기 명령어인지 구분하는 명령어 인코딩 내에 명시된 별개의 파라미터를 가질 수 있다. 도 12에 도시된 예시적인 실시예에서 모드간 호출 분기 명령어들의 2개의 변형, BLXT 및 BLXTI이 있으며, 이들 둘 모두 모드간 함수 호출을 트리거하지만, TMID 파라미터(34)를 제어 레지스터(32)에 설정하는 방식은 상이하다. 일부 시스템 구현예들은 모드간 호출 분기 명령어의 두 변형을 지원하지 않을 수 있고, BLXT 및 BLXTI 변형들 중 하나만을 가질 수 있음을 이해할 것이다. 또한 일부 구현예들은 모드간 호출 분기 명령어들의 추가적인 변형들을 가질 수 있다.
함수 호출 분기 명령어가 모드간 호출 분기 명령어가 아닌 경우, 단계(302)에서 프로세싱 회로부(4)는 (명령어 디코더(10)의 제어 하에서) 함수 호출이 안전한 도메인에서 덜 안전한 도메인으로의 도메인간 함수 호출인지 결정한다. 일부 구현예들에서, 이러한 안전한 도메인과 덜 안전한 도메인간 호출은 함수 호출 분기 명령어의 또 다른 변형, BLXNS에 의해 신호될 수 있으며, 이는 다른 유형들의 함수 호출 분기로부터 구분되는 전용 명령어 인코딩을 갖는다. 또한, 일부 구현예들에서, BLXNS 명령어가 도메인간 호출을 트리거하는지 여부는 또한 명령어에 의해 명시되는 분기 타겟 어드레스에 따라, 특히 분기 타겟 어드레스의 최하위 비트가 0인지 여부에 따라 달라질 수 있다. 일부 예들에서, 덜 안전한 코드로부터의 유효 함수 호출 또는 안전한 도메인으로의 분기 시, 함수 복귀 어드레스의 최하위 비트는 함수 호출 후에 안전한 코드 내의 제1 명령어로서 실행되는 보안 게이트웨이 명령어에 응답하여 0으로 갱신되어, 후속 함수 복귀가 이어서 덜 안전한 도메인으로 복귀하여 덜 안전한 코드가 안전한 영역 내에 있는 함수 복귀 어드레스를 제공함으로써 SAU(24)에 의해 정의되는 안전한 어드레스 영역들 내의 임의의 위치로 분기하도록 안전한 코드를 속일 수 없도록 보장할 수 있다. 분기 타겟 어드레스의 최하위 비트를 갱신하는 것이 (BXNS 명령어를 사용하는) 안전한 도메인과 덜 안전한 도메인간 함수 복귀의 보안을 보장하는 데 사용될 수 있기 때문에, (BLXNS 명령어를 사용하는) 안전한 도메인과 덜 안전한 도메인간 함수 호출들의 보안을 보장하기 위하여 유사한 기법을 이용하는 것이 편리할 수 있다. 따라서, 분기 타겟 어드레스의 최하위 비트가 0으로 설정된 도메인간 호출 명령어(BLXNS)가 있음을 검출 시, 안전한 도메인과 덜 안전한 도메인간 호출로서 처리될 수 있다. 일부 구현예들에서 안전한 도메인과 덜 안전한 도메인간 호출 명령어(BLXNS)는 프로세싱 회로부(4)가 안전한 도메인에서 동작하고 있을 때 명령어 세트에서만 이용가능할 수 있다(따라서 디코더 스테이지(10)에 의해 검출가능하다). 이러한 구현예에서 덜 안전한 상태로부터의 BLXNS 명령어를 실행하려는 시도는 디코딩 스테이지(10)가 명령어를 현재 상태에 대하여 유효한 명령어로서 인식하지 못하게 할 수 있고, 따라서 프로세싱은 단계(300)에 도달하지 않을 것이다.
함수 호출이 안전한 도메인과 덜 안전한 도메인간 호출이 아닌 경우, 단계(304)에서 함수 호출은 어떠한 특정 보안 암시도 없이 핸들링될 수 있고 단계(304)에서 링크 레지스터(R14)는 함수 복귀 어드레스로 설정된다. 함수 복귀 어드레스는 어드레스 공간(100)에서 함수 호출 명령어 뒤에 명령어의 어드레스의 값을 갖는다(즉 함수 호출 명령어의 어드레스 및 함수 호출 명령어 op코드의 길이). 단계(306)에서 프로그램 카운터 레지스터(R15)는 함수 호출 분기 명령어에 의해 명시된 분기 타겟 어드레스에 기초하여 업데이트되어 이어서 프로세싱이 분기 타겟 어드레스에 있는 명령어로 분기되도록 한다. 어떠한 도메인의 변경 또는 모드의 변경도 트리거하지 않는 함수 호출에 대한 분기 핸들링의 정상적인 경우를 나타낸다.
단계(302)에서 함수 호출 분기가 안전한 도메인과 덜 안전한 도메인간 호출이라고 결정되는 경우 단계(307)에서 프로세싱 회로부(4)는 결정한다 (예외 번호(36)가 0의 특별한 스레드 모드 값인지 여부에 기초하여) 현재 모드가 스레드 모드인지 여부를 결정하고 또한 스레드 모드 상태간 디스에이블(TMID) 파라미터(34)가 스레드 모드에서 도메인 전이가 디스에이블됨을 나타내는지 결정한다. 현재 모드가 스레드 모드이고 도메인간 전이가 스레드 모드에서 디스에이블된 경우, 단계(308)에서 프로세싱 회로부는 결함을 신호한다. 신호된 특정 유형의 결함은 TMID 플래그(34)가 이것은 디스에이블된다고 나타낼 때 스레드 모드에서 안전한 도메인들을 전환하려는 시도에 의해 트리거되는 예외들에 대해서만 사용되는 전용 결함 유형일 수 있다. 대안적으로 결함은 다양한 결함 조건들을 핸들링하는 데 사용되는 예외 핸들러에 관한 것일 수 있고, 이러한 경우들에 도메인간 전이 디스에이블 체킹과 연관된 신드롬 플래그는 예외 핸들링 루틴이 결함의 원인, 및 수행되어야 할 후속 작용들을 쉽게 식별할 수 있도록 설정될 수 있다. 도 12에서 이는 INVTMI(무효 스레드 모드 상태간) UsageFault로서 표시되지만, 이러한 유형의 결함에 대한 정확한 명명 규칙은 물론 달라질 수 있다. 안전한 도메인과 덜 안전한 도메인간 호출의 경우, INVTMI 결함은 안전한 도메인(호출을 시도하기 전 현재 도메인)에서 핸들링되고, 이는 유용한데, 그 이유는 because 안전한 것에서 덜 안전한 것으로의 전이를 요청했을 스레드를 관리하기 위한 프로세스는 안전한 스레드를 관리하는 안전한 운영 체제일 것이기 때문이고, 이는 INVTMI 결함을 핸들링하도록 잘 배치되어 그 스레드가 덜 안전한 도메인에서 동작하는 데 필요한 임의의 리소스들이 구성될 수 있도록 할 수 있다.
단계(307)에서 현재 모드는 핸들러 모드이거나(예컨대 예외 번호(36)가 0이 아닐 때) 또는 도메인 전이가 스레드 모드에서 인에이블됨을 나타내기 위하여 TMID 파라미터(34)가 0이라고 결정되는 경우, 단계(310)에서 프로세싱 회로부는 링크 레지스터(R14)를 도 5에 도시된 바와 같이 유효 더미 함수 복귀 어드레스 값들(140) 중 하나로 설정한다. 더미 함수 복귀 어드레스(140)에서, 모드간 함수 호출이 아님을 나타내기 위하여 모드간 플래그(M)(146)는 1로 설정되고, 또한 호출이 안전한 도메인으로부터 이루어지지 않았음을 나타내기 위하여 안전한 도메인 플래그(들)(148)는 1로 설정된다. 단계(312)에서, 함수 복귀 스택 프레임(172)은 (현재 모드가 핸들러 모드인지 아니면 스레드 모드인지에 따라 그리고 스레드 모드인 경우, 안전한 도메인(13_S)에 대한 스택 포인터 선택 값(30)에 따라) 안전한 메인 스택 포인터(MSP_S) 또는 안전한 프로세스 스택 포인터(PSP_S)에 의해 지목되는 스택 데이터 구조에 저장된다. 저장된 함수 복귀 스택 프레임(172)은 이것이 모드간 함수 호출이 아님을 나타내기 위하여 HDT 플래그(178)를 0과 같은 것으로 명시한다. 또한 함수 복귀 스택 프레임(172) 내의 예외 번호 필드(179)는 호출이 핸들러 모드로부터 이루어지는지 아니면 스레드 모드로부터 이루어지는지 나타내기 위하여 제어 레지스터들(20) 내의 예외 번호(36)의 현재 값과 동일하게 설정된다. 이 예외 번호 필드(179)는 현재 모드가 핸들러 모드인지 나타내는 핸들러 모드 표시 값의 역할을 한다. 함수 복귀 스택 프레임은 또한 단계(304)에서와 동일한 방법으로 설정되는 함수 복귀 어드레스(174)를 포함하지만, 이번에는 링크 레지스터 대신에 스택에 저장되어 도메인간 호출 뒤에 실행될 덜 안전한 코드가 어떤 명령어가 안전한 코드에서 함수 호출 전에 실행되고 있었는지 알 수 없도록 한다. 단계(314)에서 프로세싱 회로부는 현재 도메인을 덜 안전한 도메인으로 전환하고 이어서 방법은 단계(306)로 진행하는데, 여기서 함수 호출 분기 명령어에 의해 명시되는 분기 타겟 어드레스로의 분기는 이전에 설명된 것과 동일한 방법으로 수행된다.
단계(300)를 다시 참조하면, 함수 호출 분기 명령어가 모드간 호출 분기 명령어인 경우, 단계(320)에서 프로세싱 회로부는 동작의 현재 모드가 스레드 모드인지 결정하고, 현재 모드가 스레드 모드인 경우, 단계(322)에서 사용 결함이 신호된다. 이는 INVTMI UsageFault과는 상이한 유형의 사용 결함일 수 있다. 모드간 호출 분기 명령어는 인터럽트 권한박탈을 지원하기 위하여 핸들러 모드에서 스레드 모드로의 전환을 트리거하도록 의도되기 때문에, 스레드 모드로부터 그것을 실행하려는 시도는 에러이다. 스레드 모드에서 모드간 호출 분기의 명령어 실행을 억압하는 것은 호출 분기에 응답하여 잘못된 스택 프레임을 잠재적으로 설정함으로써 야기되는, 보안 취약성을 초래할 수 있는, 잠재적으로 예측불가능한 결과들을 회피한다. 따라서, 모드간 호출 분기 명령어는 핸들러 모드에서만 실행될 수 있다.
단계(320)에서 현재 모드가 핸들러 모드인 것으로 결정되는 경우, 방법은 단계(324)로 진행되고, 여기서 링크 레지스터는 특수한 더미 함수 복귀 어드레스 값들(140) 중 하나로 설정되지만, 단계(310)에서와는 달리, 모드간 플래그(M)(146)는 단계(324)에서 0으로 설정되어 대응하는 함수 복귀가 모드간 함수 복귀로서 처리되어야 함을 나타낸다. 또한, 함수 복귀 값(140)의 안전한 도메인 플래그(들)(148)는 모드간 호출 분기 명령어가 실행되었던 때의 현재 동작 도메인을 나타낸다(모드간 호출은 안전한 도메인 또는 덜 안전한 도메인으로부터 이루어질 수 있음).
단계(326)에서, 프로세싱 회로부는 모드간 호출 명령어를 실행하기 전 동작의 도메인 및 모드 및 스택 포인터 선택 값(30)에 기초하여 선택된 스택에 함수 복귀 스택 프레임(172)을 저장한다. 함수 복귀 스택 값은 함수 복귀 어드레스(174)(단계들(304 또는312)에서와 동일한 방법으로 설정됨), 및 예외 번호(36)의 현재 값에 대응하는 핸들러 모드 표시 값을 다시 포함한다. 모드간 호출이 핸들러 모드에서 이루어짐에 따라, 예외 번호 필드(179)는 0이 아닌 것으로 예상된다. 모드간 호출의 경우, 함수 복귀 스택 프레임 내의 HDT 플래그(178)는 1로 설정되어 이 함수 복귀 스택 프레임이 모드간 호출에 응답하여 저장되었음을 나타내고, 이는, 더미 함수 복귀 어드레스(140)를 이용하여 대응하는 함수 복귀 시, 모드간 플래그(146)가 올바른지 아니면 비신뢰 코드에 의해 변조되었는지 체크하는 크로스-체킹 정보를 제공할 수 있다. 유의할 점은 단계(312) 또는 단계(326)에서의 함수 복귀 스택 프레임의 저장에 후속하여, 대응하는 스택 포인터는 또한, 현재 저장된 스택 프레임이 스택해제되기 전에 추가 스태킹이 필요한 경우, 추가 스택된 정보가 스택에 저장되어야 하는 위치에 대한 포인트에 업데이트될 것이다.
단계(328)에서, 옵션적으로 프로세싱 회로부는 모드간 호출 분기 명령어에 응답하여 에러 동기화 차단 동작이 수행되도록 트리거한다. 예를 들어, 에러 동기화 차단 동작은 프로세싱 회로부(4)가, 임의의 이전에 실행된 명령어들의 유효성을 체크하기 위한 적어도 일부 유형들의 에러 검출 또는 교정 동작들의 결과들이 완료되었다고 결정되고 이 동작들은 에러가 없거나, 교정될 수 있는 에러를 포함하거나, 또는 핸들러 모드에서 스레드 모드로의 변경 전에 명령어들의 실행에 올바르게 기여할 수 있는 에러를 포함하고 있다고 확인될 때까지 명령어들의 추가 실행을 중지하는 것을 포함할 수 있다. 에러 동기화 차단 동작은 신뢰성, 가용성, 및 편리성(RAS) 에러 검출/교정 회로부(29)에 의해 검출되는 적어도 일부 유형들의 에러들이 모드간 호출 분기 명령어에 의해 야기된 모드 변경 전에 실행되는 코드에 귀속될 수 있고 모드간 호출 분기 명령어에 의해 야기된 모드 변경 후에 실행되는 코드를 프로세싱할 때 발생하는 에러들과 구분될 수 있도록 보장하기 위한 동작이다. 모드간 호출 분기의 경우, 검출된 RAS 에러가 모드간 함수 호출에 의해 야기된 모드 변경 전에 실행되는 더 권한부여된 코드 또는 모드 변경 후에 실행되는 덜 권한부여된 코드에 영향을 미쳤는지 정확히 지목할 수 있는 것이 유익할 수 있다. 이는 종종 덜 권한부여된 코드와 연관된 에러들을 해결하는 것이 더 권한부여된 코드와 연관된 에러들을 해결하는 것보다 시스템 가용성에 훨씬 낮은 충격을 초래할 수 있기 때문이다. 예를 들어 더 권한부여된 코드는 운영 체제일 수 있고, 따라서 운영 체제에 귀속되는 에러들을 처리하는 것은 전체 시스템 리셋을 필요로 할 수 있는 반면, 개별 스레드와 연관된 덜 권한부여된 코드에 귀속된 에러는 단순히 그 스레드를 죽이고 다른 스레드들 및 운영 체제는 영향 없게 함으로써 처리될 수 있다. 따라서, 모드간 호출에 응답하여 에러 동기화 차단 동작을 수행함으로써, 임의의 검출된 에러들이 모드간 함수 호출에 의해 야기된 모드 변경 후에 실행되는 덜 권한부여된 코드에 안전하게 귀속될 수 있는 경우에 그것들을 처리하는 영향을 제한함으로써 시스템의 가용성을 개선할 수 있다. 에러 동기화 차단의 범주 밖에 있을 수 있는 일부 유형들의 에러들이 있을 수 있고, 따라서 이러한 차단의 사용에 의해 포함되지 않을 수 있음을 이해할 것이다. 이 포함불가능 에러들도 전체 시스템 리셋을 필요로 할 수 있다. 그러나 에러 동기화 차단의 사용은 에러가 단일 스레드에 귀속될 수 있는 가능성을 증가시킬 수 있고, 따라서 전체 시스템 리셋이 필요한 가능성을 낮출 수 있다.
에러 동기화 차단 동작이 모든 시나리오들에서 트리거될 필요는 없다. 일부 시스템들은 모드간 함수 호출 후에 실행되는 후속 명령어들의 실행을 인위적으로 억누르지 않음으로써 규칙적인 프로그램 실행을 위한 성능이 개선되는 것을 선호할 수 있다. 예를 들어, 특정 실시간-결정적 인터럽트들의 경우 인터럽트 핸들링 레이턴시는 가능한 짧아야 할 수 있고 따라서 에러 동기화 차단 동작을 트리거하지 않는 것이 선호될 수 있고, RAS 에러가 검출되는 경우 더 큰 성과 비용을 지불해야 하는 반면, 덜 실시간-결정적 요건들을 구비하거나, 또는 안전성 결정적 거동에 관련된 다른 유형들의 인터럽트들의 경우, 에러 검출/교정 결과들이 이용가능할 때까지 모드간 호출 후에 명령어들의 실행을 억누름으로 인해 규칙적 인터럽트 레이턴시는 약간 더 느릴 수 있지만, 에러가 검출되는 경우 에러의 위치가 정확히 지목될 수 있고 가능한 경우 시스템 리셋이라는 큰 충격이 회피될 수 있도록 에러 동기화 차단 동작을 트리거하는 것이 선호될 수 있다. 따라서, 일부 구현예들에서 제어 레지스터들(20)은 에러 동기화 차단 동작이 모드간 호출 명령어에 응답하여 트리거되어야 하는지 명시하는 구성 파라미터를 저장할 수 있다. 일부 시스템들에서 에러 동기화 차단 동작들이 수행되어야 하는지 명시하는 구성 파라미터가 보안 도메인들 사이에 구축되어, 덜 안전한 도메인 및 안전한 도메인이 독립적으로 차단 동작들이 수행되어야 하는지 선택할 수 있도록 한다.
에러 동기화 차단 동작이 수행되는지 여부에 상관없이, 단계(330)에서 모드간 호출 분기 명령어에 응답하여 프로세싱 회로부는 또한 프로세스 스택 포인터가 모드간 함수 호출 후에 스레드 모드에서 수행되는 후속 동작들에 대하여 선택되어야 한다고 나타내도록 현재 안전한 도메인에 대한 스택 포인터 선택 값(30-S 또는 30-NS)을 설정한다. 이는 예외 핸들러에 의해 핸들링되는 예외 이전에 실행되는 스레드 모드 코드가 메인 스택 포인터에 액세스하는 경우에도, 모드간 호출 후에 실행되는 예외 핸들러의 덜 권한부여된 부분이 모드간 호출 명령어 이전에 핸들러 모드에서 실행되는 래퍼 코드의 더 권한부여된 섹션에 의해 사용되는 메인 스택 포인터에 액세스하거나 손상시킬 수 없도록 보장한다.
단계(332)에서 프로세싱 회로부(4)는 실행되고 있는 모드간 호출 분기 명령어가 명령어의 BLXTI 변형인지 결정한다. 그렇다면, 단계(334)에서 TMID 파라미터(34)는 0으로 설정되어 스레드 모드에서 안전한 도메인과 덜 안전한 도메인 사이의 도메인 전이가 인에이블됨을 나타낸다. 이는 앞서 언급된 바와 같이 모드간 호출 분기 명령어의 제2 변형에 대응한다. 모드간 호출 분기 명령어가 BLXT 변형(제1 변형)인 경우, 단계(336)에서 TMID 파라미터(34)는 1로 설정되어 스레드 모드에서의 도메인 전이가 디스에이블됨을 나타낸다. 프로그래머는 안전한 도메인 및 덜 안전한 도메인 둘 모두를 위한 리소스들이 모드간 함수 호출에 후속하여 실행되는 스레드를 위해 이미 설정되었는지에 따라 BLXT 또는 BLXTI 변형을 사용할 지 선택할 수 있다. BLXTI 변형은 두 도메인을 위한 리소스들이 이미 설정되어서 필요 시 안전한 도메인과 덜 안전한 도메인 사이에서 전환하는 것이 안전한 경우에 선택될 수 있고, BLXT 변형은 S/NS 도메인들 중 하나만을 위한 리소스들이 구성된 경우에 선택될 수 있다. 이 리소스들은 안전한 및 덜 안전한 MPU들(26-S, 26-NS) 중 관련된 것 내에 MPU 구성을 포함할 수 있다(여기서 MPU 구성은 각각의 메모리 영역들에 대한 액세스 허가들을 정의하는 일부 메모리 영역 속성들 및/또는 이러한 메모리 속성들을 제공했던 메모리 시스템(6) 내의 표에 대한 포인터 중 하나 또는 둘 모두를 포함할 수 있다). 또한 리소스들은 안전한 또는 덜 안전한 스택 포인터 레지스터들(도 3에 도시된 바와 같이 구축된 버전들의 R13)에 스택 포인터들을 포함할 수 있고, 메모리 내의 적절한 스택 구조가 이미 이용가능하지 않은 경우, 또한 메모리에 저장된 대응하는 스택 구조들의 할당을 포함할 수 있다. 스레드 모드에서 도메인 전이를 디스에이블하는 능력을 제공함으로써, 스레드가 하나의 도메인에 대해서만 구성된 그것의 리소스들을 갖게 하고, 도메인들을 전환하려는 시도가 있어서, 결함이 달리 위 단계(308)에 도시된 바와 같이, 또는 다른 유형들의 도메인간 전이에 대하여 설명된 바와 같이 트리거되는 경우, 다른 도메인을 위한 리소스들은 단지 느리게 할당되기만 하면 된다. BLXTI 또는 BLXT 명령어를 이용하여 또한 스레드 최장 상태간 디스에이블 파라미터(34)를 설정함으로써, 별개의 명령어가 따로 플래그를 설정할 필요성을 회피한다.
모드간 호출 분기 명령어의 어느 변형이 실행되는지에 상관없이, 단계(338)에서 프로세싱 회로부는 비-예외 핸들링 값(예컨대 0)을 나타내도록 예외 번호(36)를 업데이트하고, 따라서 프로세서는 스레드 모드로 전환된다. 다시, 방법은 이어서 단계(306)로 진행되어 함수 호출 분기 명령어에 의해 명시되는 분기 타겟 어드레스로 분기한다. 이어서 후속 프로그램 실행은 분기 타겟 어드레스에 저장된 명령어로부터 계속될 것이다. 분기 타겟 어드레스가 여러가지 방법으로 함수 호출 분기 명령어에 명시될 수 있음을 이해할 것이다. 간접 분기의 경우, 분기 타겟 어드레스는 타겟 어드레스를 포함하는 레지스터를 선택하도록 피연산자를 이용하여 정의될 수 있다. 직접 분기는 명령어 인코딩에 직접 인코딩된 중간 값을 이용하여 타겟 어드레스를 명시할 수 있다. 프로그램 카운터-관련 분기(간접적 또는 직접적일 수 있음)는 분기 타겟 어드레스를 획득하기 위하여 현재 프로그램 카운터 값에 가산될 오프셋을 명시할 수 있다.
도 13은 예외 진입 시 수행되는 단계들을 도시한다. 단계(350)에서 예외가 발생한다. 예외는 감독자 호출(SVC)과 같은 소프트웨어-트리거 예외 또는 소프트웨어에 의해 직접 야기되는 결함, 예컨대, 정의되지 않은 명령어를 실행하려는 시도, 예약된 어드레스 범위(130)로부터 명령어를 페치하려는 시도, 또는 메모리 액세스 체크 회로부(22)에서 실패한 메모리 허가 체크로 인한 어드레스 결함을 트리거하는 메모리에 대한 액세스의 발생에 의해 야기되는 예외일 수 있다. 또한, 예외는 외부 디바이스 또는 주변장치로부터의 신호 또는 메시지의 수신에 의해 야기되는 하드웨어-트리거 인터럽트일 수 있다.
예외의 원인에 상관없이, 예외가 발생하면, 단계(352)에서 프로세싱 회로부(4)는 링크 레지스터(R14)를 앞서 설명한 특수한 더미 예외 복귀 값(142)에 설정하도록 예외 제어 회로부(28)에 의해 제어된다. 더 구체적으로는, 여러 더미 예외 복귀 값들 중 하나는 현재 모드 및 현재 도메인 플래그들(152, 156)의 값들을 이용하여 선택되며, 예외가 발생했던 때의 현재 동작 모드 및 도메인에 기초하여 선택된다. 또한, 스레드 모드 상태간 인에이블(TMIE) 플래그(158)은 제어 레지스터(32) 내의 TMID 플래그(34)의 현재 값의 역으로 설정된다. 이는 예외 프로세싱 동안 정보를 TMID 플래그에 보존하여 예외 복귀 시 복원될 수 있도록 한다. TMID 플래그를 반전시켜 TMIE 플래그를 설정하는 구현예는 단지 하나의 구현예이고, 다른 예들은 TMID 값과 동일한 인코딩으로 TMIE 값을 인코딩하여 그것을 직접 복사할 수 있거나, 또는 단일 비트 플래그로 표현될 필요는 없지만 다중-비트 값을 이용할 수 있는 완전히 상이한 인코딩을 사용할 수 있음을 이해할 것이다.
단계(354)에서 예외 제어 회로부(28)는 레지스터들(1)로부터 구축된 스택 포인터 레지스터들 내의 스택 포인터들 중 하나에 의해 식별되는 메모리 내의 스택 데이터 구조로 레지스터 상태의 하드웨어-트리거 상태 저장을 트리거한다. 선택할 특정 스택 포인터는 현재 도메인 및 모드 및 예외 발생 이전에 사용 중인 스택 포인터 선택 값(30)에 따라 달라진다. 상태 저장은 도 6에 도시된 호출자 스택 프레임(180)만을 저장하거나 또는 호출자 스택 프레임(180) 및 피호출자 스택 프레임(182) 둘 모두를 저장하는 것을 포함할 수 있다. 호출자 스택 프레임만을 저장할 지 아니면 호출자 및 피호출자 스택 프레임들 둘 모두를 저장할 지에 대한 결정은 예외가 발생한 시점의 현재 동작 도메인 및 예외가 프로세싱될 도메인에 따라, 그리고 일부 경우들에서 제어 레지스터(20)에 저장된 상태 데이터에 기초하여 달라질 수 있다.
자체적으로 예외를 프로세싱하지 않고, 임의의 이전에 발생한 예외들이 이미 처리된 백그라운드 코드로부터 예외가 발생하고, 백그라운드 코드가 덜 안전한 도메인에서 프로세싱되는 경우, 호출자 스택 프레임(180)만이 저장될 필요가 있고 피호출자 스택 프레임(182)을 저장할 필요가 없다. 또한, 백그라운드 코드는 안전한 도메인에서 프로세싱되었지만 예외가 안전한 도메인에서 발생하는 경우, 다시 피호출자 스택 프레임(182)을 저장할 필요는 없다.
예외가 안전한 도메인에서 프로세싱되는 백그라운드 코드로부터 발생하지만 예외는 덜 안전한 도메인에서 프로세싱되는 이벤트에서, 예외 이전에 동작하는 안전한 코드에 의해 레지스터들(14)에 배치된 레지스터 상태에 덜 안전한 예외 핸들러가 액세스할 수 있는 위험이 있을 것이다. 따라서, 이 경우에, 호출자 및 피호출자 스택 프레임들(180, 182) 둘 모두는 안전한 메인 스택 포인터 및 안전한 프로세스 스택 포인터 중 하나에 의해 식별되는 안전한 스택에 저장될 것이고, 범용 레지스터들(16)은 안전한 데이터를 덜 안전한 핸들러로부터 액세스되는 것으로부터 숨기도록 소거될 수 있다.
이전 단락은 백그라운드 코드에서 예외가 발생할 때 추가적인 피호출자 스택 프레임을 저장할 지 결정하는 일반적인 원칙을 설명한다. 그러나 그것의 예외 핸들러를 아직 완료하지 않은 앞선 예외보다 추가 예외가 선수를 치거나, 또는 하나의 예외를 완료시 백그라운드 코드로 복귀하기 전에 다른 예외가 발생하는 예외들의 꼬리물기가 수행되는 경우, 호출자 스택 프레임 및/또는 피호출자 스택 프레임을 저장할 지에 대해 더 복잡한 결정이 있을 수 있다. 예외에 응답하여 호출자 및 피호출자 상태 중 어느 것을 저장할 지 결정하기 위한 결정 프로세스들의 예들이 공개된 PCT 출원 WO2013/117899 A1 및 WO2014/0538048 A1에 기재되어 있고, 이들의 내용은 참조로서 포함되고, 어느 레지스터들을 스택할 지 결정하는 데 사용될 수 있고, 본 출원의 도 13의 단계(354)에 적용될 수 있다. 특히 WO 2013/117899 A1의 도 12 및 관련 설명을 참조한다.
단계(354)에서, 피호출자 스택 프레임(182)이 스택에 저장되는 것으로 결정되는 경우, 사전결정된 서명(190) 내에, TMIE 크로스체크 정보(192)가 명시되고, 이는 단계(352)에서 설정된 더미 예외 복귀 어드레스 내의 TMIE 플래그(158)와 동일한 값으로 (또는 대안적인 구현예들에서, TMIE 플래그(158)가 올바르게 설정되었는지 체크하는 데 사용될 수 있는 다른 값으로) 설정된다. 이는, TMIE 플래그(158)가 TMID 플래그(34)를 제어 레지스터(32)에 복원하는 데 사용되면, 예외로부터 복귀 후에 프로세싱되는 안전한 코드가 상태간 디스에이블 플래그 TMID(34)의 틀린 값을 수신하는 위험을 무릅쓰는 방법으로, 예외의 발생에 후속하여 동작하는 덜 안전한 코드가 더미 예외 복귀 어드레스 내의 TMIE 플래그(158)를 변조할 수 있는 위험으로부터 일부 보호를 제공한다. 이는 허위 결함들이 변조된 TMIE 플래그(34)에 기초하여 설정된 TMID(34)에 기초하여 생성되는 것에 의해 야기되는 서비스 거부 공격으로부터 보호한다.
TMIE 크로스체크 값(190)이 호출자 스택 프레임(180) 대신에 피호출자 스택 프레임(182) 내에 명시되는 이유를 궁금해 할 수 있는데, 그 이유는 백그라운드 코드에 대한 TMID 플래그(34)를 보존하는 값이 호출자 스택 프레임(180)에 저장된다면, 예외 복귀 값(142) 내의 TMIE 플래그(158)의 경우와 같이, 링크 레지스터 내의 예외 핸들러에 액세스가능하지 않으면서 안전을 유지할 수 있다고 생각할 수 있기 때문이다. 그러나, 실제로 호출자 스택 프레임(180)은 추가 정보를 위하여 많은 예비 용량을 갖지 않을 수 있는데, 그 이유는 상태 필드 ERETPSR이 이미 많은 정보를 인코딩했을 수 있고 따라서 크로스-체킹 정보(192)를 위한 공간이 없을 수 있기 때문이다. 일부 구현예들에서 TMIE 플래그의 추가를 위하여 ERETPSR 값 내에 충분한 공간이 있는 것이 가능하지만, ERETPSR 값 내의 남은 공간은 여전히 제한되고 아키텍처에 향후 추가를 위한 공간을 예약하는 것이 선호된다. 피호출자 스택 프레임(182)은 모든 유형들의 예외들에 대하여 저장되는 것은 아니며, 따라서 예외 복귀 시 TMID 플래그(34)에 복원될 값을 나타내는 TMIE 값(158)의 메인 사본을 저장하기 위하여 의존할 수 없다. 따라서 TMIE 플래그(158)가 링크 레지스터 내에 더미 예외 복귀 어드레스의 일부로서 배치되지만, 크로스-체크 정보(190)가 피호출자 스택 프레임(182)에 포함되는 도 5 및 도 6에 도시된 접근법은 호출자 스택 프레임(180) 내의 공간 부족에도 불구하고 모든 유형들의 예외들이 TMID 플래그(34)의 값을 보존할 수 있게 하지만, TMIE 플래그(158)가 변조되는 위험이 있는 시나리오들의 경우에, 이들은 또한 추가적인 피호출자 스택 프레임(182)을 저장하여, 피호출자 스택 프레임(182)에 저장된 크로스-체킹 정보(192)가 변조로부터 TMIE 플래그(158)를 보호함으로써 레지스터 상태가 보호되는 동일한 시나리오들이다.
단계(356)에서, 예외 엔트리 전이의 일부로서, 예외 제어 회로부(28)는 제어 레지스터(32) 내의 TMID 플래그(34)를 0으로 설정하고, 도메인 전이가 스레드 모드에서 인에이블됨을 나타내도록 프로세싱 회로부(4)를 트리거한다. 이는 모든 예외 핸들러들이, 도메인 전이가 예외 이전에 실행되는 코드에 대하여 디스에이블되었는지 여부에 상관없이, 도메인 전이가 스레드 모드에서 인에이블되는지 여부에 대하여 일관된 관점을 보도록 보장한다. 도메인 전이를 스레드 모드에서 이러한 방법으로 인에이블하는 것은 TMID 플래그(34)가 생성되기 전에 기록된 소프트웨어와의 역방향 호환성을 필요로 할 수 있다.
단계(358)에서 예외 제어 회로부(28)는 프로세싱 회로부(4)가 예외 핸들링 루틴으로 분기하도록 제어한다. 예외 핸들링 루틴의 시작에서 수행될 명령어의 어드레스는 상이한 유형들의 예외들을 각각의 예외 핸들링 루틴 어드레스들에 맵핑하는 예외 벡터 테이블들에 기초하여 결정될 수 있다. 예외 핸들링 루틴은 핸들러 모드에서 프로세싱되고, 따라서 프로세싱 회로부(4)가 현재 스레드 모드에 있다면, 예외가 발생한 것에 응답하여 현재 모드는 핸들러 모드로 스위칭된다. 예외가 발생했을 때의 현재 모드가 이미 핸들러 모드라면, 현재 모드에 변경은 일어나지 않는다. 따라서, 일부 코드를 핸들러 모드에서 프로세싱한 후에 모드간 함수 호출을 전술된 바와 같이 수행하여 스레드 모드로 전환하는 것이 가능하더라도, 초기에 스레드 모드에 예외를 적용하는 것은 가능하지 않다.
또한, 예외 엔트리 시 예외 제어 회로부(28)는 옵션적으로 필요한 경우 안전한 도메인들을 전환하도록 프로세싱 회로부(4)를 트리거할 수 있다. 상이한 예외들은 상이한 안전한 도메인들과 연관될 수 있다. 일부 예외들은 항상 안전한 도메인 또는 덜 안전한 도메인과 같은, 특정 도메인에서 발생할 필요가 있을 수 있다. 다른 예외들은 예외가 발생했던 때의 현재 도메인에서 발생할 수 있다. 따라서, 예외가 현재 도메인과는 상이한 도메인에서 핸들링되는 경우, 예외 제어 회로부(28)는, 예외 핸들링 루틴으로의 분기뿐만 아니라, 또한 안전한 도메인의 변경을 트리거할 수 있다.
도 14는 도 12에 도시된 유형의 함수 호출 분기 명령어가 아닌 분기 명령어에 응답하여 수행되는 단계들을 도시하는 흐름도이다. 단계(400)에서 프로세싱 회로부는 타겟 어드레스가 예약된 어드레스 범위(130)에 있는지 체크한다. 그렇지 않다면, 이것은 실행가능 명령어의 어드레스로의 규칙적 분기 명령어이다. 단계(402)에서 분기가 안전한 도메인에서 덜 안전한 도메인으로의 전이를 요청하고 있는지 검출된다. 이는 프로세싱 회로부(4)의 현재 동작 도메인을 체크하고 분기 타겟 어드레스의 최하위 비트를 체크함으로써 식별될 수 있다. 분기 타겟 어드레스의 최하위 비트가 0인 경우, 그것은 덜 안전한 도메인으로 돌아가는 분기를 나타낸다. 대안적으로 일부 구현예들에서 안전한 도메인에서 덜 안전한 도메인으로의 전이를 요청하는 분기는 전용 도메인 전이 분기 명령어(이는 BXNS로 불릴 수 있음)의 사용에 의해 표시될 수 있다. 전용 도메인 전이 분기 명령어는 다른 유형들의 분기 명령어와는 상이한 op코드 값에 의해 식별가능할 수 있거나, 또는 다른 유형들의 분기 명령어와 동일한 op코드이지만, 파라미터 값이 안전한 도메인에서 덜 안전한 도메인으로의 전이가 요청됨을 나타낼 수 있다. 일부 구현예들은 두 접근법을 조합하여 안전한 도메인에서 덜 안전한 도메인으로의 전이 요청이 둘 모두 분기 타겟 어드레스의 최하위 비트가 0이 되도록 하고, 전용 도메인 전이 명령어의 사용을 필요로 할 수 있다.
분기가 안전한 것에서 덜 안전한 것으로의 분기를 요청하지 않는 경우, 단계(404)에서 분기는 정상적으로 프로세싱될 수 있고 프로그램 카운터 레지스터(R15)는 분기 명령어에 의해 명시된 분기 타겟 어드레스에 기초하여 업데이트되고 이어서 프로그램 흐름은 (분기의 실행 이전과 동일한 도메인에서) 계속해서 분기 타겟 어드레스에 있는 명령어를 실행한다. 일부 구현예들에서 모든 유형들의 비-함수 호출 분기가 함수 복귀에 사용되는 것으로 예상되는 것은 아님을 이해할 것이다. 예를 들어 명령어 op코드 내에서 인코딩된 중간 값에 기초하여 타겟 어드레스를 결정하는 분기들은 항상 동일한 위치로 분기할 수 있으며, 이와 같이 그것들은 프로그램 흐름이 복귀하는 함수를 호출했던 다양한 상이한 함수들로 다시 분기할 필요가 있을 경우 함수 복귀 분기에 적절하지 않을 수 있다. 설계를 단순하게 하기 위해, 일부 구현예들은 함수 복귀를 수행하는 데 사용될 수 있는 비-함수 호출 분기들의 서브세트에 대하여 도 14에 설명된 단계들만을 수행하도록 선택할 수 있다. 전술된 바와 같이, 명령어가 전용 분기 명령어가 아닐 수 있더라도, 분기를 수행하는 효과를 가질 수 있는 많은 유형들의 명령어가 있을 수 있다(예를 들어 로딩된 값을 프로그램 카운터에 기록하는 로드 명령어일 수 있다). 도 14에 기재된 단계들은 또한 적어도 분기를 수행하는 효과를 갖는 이러한 비-분기 명령어들의 서브세트에 적용될 수 있다.
단계(402)에서 분기가 안전한 것에서 덜 안전한 것으로의 분기라고 결정되는 경우, 단계(406)에서 프로세싱 회로부는 현재 모드가 스레드 모드인지 그리고 도메인 전이 디스에이블 구성 파라미터(TMID)가 스레드 모드에서 도메인간 전이가 디스에이블됨을 나타내는 1인지 체크한다. 현재 모드는 스레드 모드이고 TMID는 스레드 모드에서 도메인 전이가 디스에이블됨을 나타내는 경우, 단계(408)에서 안전한 도메인에서 프로세싱되는 INVTMI UsageFault가 트리거된다. 이를 통해, 안전한 스레드를 관리하는 안전한 운영 체제는 필요에 따라 안전한 스레드가 또한 덜 안전한 도메인에서 동작할 수 있게 허용하도록 임의의 MPU 또는 스택 리소스들을 구성할 수 있다.
대안적으로 단계(406)에서 현재 모드가 핸들러 모드이거나 또는 도메인 전이(interstating)가 인에이블됨을 나타내기 위하여 제어 레지스터(32) 내의 TMID 값(34)이 0이라고 결정된다면, 단계(410)에서 보안 도메인은 덜 안전한 도메인(NS)으로 전환되고 이어서 단계(404)에서 앞서 설명된 바와 같이 타겟 어드레스로의 분기가 수행된다.
단계(400)에서 타겟 어드레스가 예약된 범위 내에 있다고 결정되는 경우, 이는 분기가 함수 복귀 또는 예외 복귀를 나타내도록 의도될 수 있음을 나타낸다. 단계(412)에서 프로세싱 회로부(4)의 실행 스테이지(12)는 분기의 타겟 어드레스가 함수 복귀 선두(144)에 의해 표시된 바와 같이 그것의 최상위 비트 부분에서 유효 더미 함수 복귀 어드레스들(140) 중 하나인지 결정한다. 타겟 어드레스가 유효 더미 함수 복귀 어드레스들(140) 중 하나인 경우, 단계(414)에서 함수 복귀 분기 핸들링이 수행되는데, 이는 아래 도 15를 참조하여 더 상세하게 설명될 것이다.
대안적으로, 분기의 타겟 어드레스가 유효 더미 함수 복귀 어드레스들 중 하나가 아닌 경우, 단계(416)에서 도 5에 도시된 바와 같이 타겟 어드레스가 유효 더미 예외 복귀 어드레스들(142) 중 하나인지 결정된다. 그렇지 않다면, 타겟 어드레스로 분기하려는 시도는 에러인데, 그 이유는 어드레스가 비-실행가능 명령어 어드레스를 나타내고, 그것은 예외적인 함수 복귀를 신호하는 데 사용되는 더미 어드레스가 아니기 때문이며, 따라서 단계(418)에서 결함이 트리거될 수 있다. 대안적으로, 분기가 비-실행가능 어드레스를 향하는 것임을 검출하는 것에 응답하여 결함을 직접 트리거하는 대신에, 분기는 프로그램 카운터 레지스터를 분기 타겟 어드레스로 설정하도록 정상적으로 수행될 수 있고(따라서 단계(416)에 대한 "N" 결정의 이벤트 시 도 14는 단계(416)에서 단계(404)로 전이함), 이어서 순차적으로 명령어 페칭 회로부(8)가 비-실행가능 어드레스로부터 명령어를 페치하려고 시도하면 결함으로 하여금 신호되게 할 수 있다. 따라서, 결함의 생성은 분기에 의해 간접적으로 야기될 수 있지만, 분기 명령어 자체에 응답하여 직접 신호되지 않을 수 있다. 어느 접근법이든 유효할 수 있다.
단계(416)에서 타겟 어드레스가 유효 더미 예외 복귀 어드레스들(142) 중 하나라고 결정되는 경우, 단계(420)에서, 적어도 예외 복귀가 덜 안전한 도메인에서 안전한 도메인으로의 전이를 포함하는 경우(이는 더미 예외 복귀 어드레스 내의 보안 도메인 플래그(156)로부터 결정될 수 있음) 더미 예외 복귀 어드레스(142) 내의 TMIE 플래그(158)와 호출 스택 프레임(182)의 일부로서 저장된 TMIE 크로스-체크 정보(190) 사이에 크로스-체킹 비교가 이루어진다. 미스매치가 검출되는 경우, 단계(422)에서 결함이 트리거되는데, 그 이유는 이것이 링크 레지스터 내의 TMIE 플래그(158)를 변조하려는 시도가 이루어졌거나, 또는 대안적으로 부주의한 에러가 발생했음을 나타낼 수 있기 때문이다. TMIE 플래그(158)가 크로스-체크 정보(192)와 매칭되거나, 또는 대안적으로 예외 복귀 전이가 이러한 크로스-체크를 필요로 하지 않는 것인 경우, 방법은 단계(424)로 진행되고, 여기서 예외 복귀가 핸들링된다.
단계들(420, 424)에서의 예외 복귀 핸들링은 또한 앞서 참조된 PCT 공개공보 WO2013/117899 A1 및 WO2014/053804 A1에 설명된 바와 같은 다른 동작들을 포함할 수 있다. 단계(420)에서 TMIE 값을 체크하기 이전에, 단계(424)에서의 예외 복귀 핸들링은 스택에서 레지스터들(14)로의 레지스터 상태의 스택해제를 포함할 수 있다. 스택해제가 호출자 스택 프레임(180)만 스택해제하는 것을 포함해야 하는지 아니면 호출자 스택 프레임 및 호출 스택 프레임(180, 182) 둘 모두 스택해제하는 것을 포함해야 하는지 결정은 예외를 적용 시 예외 복귀 값(142)의 일부로서 저장될 수 있는 상태 플래그에 기초하여 이루어질 수 있다. 어느 레지스터들이 스택해제되어야 하는지에 대한 결정에 관한 더 상세한 설명을 위해, WO2013/117899 A1의 도 13 또는 WO2014/053804 A1의 도 13을 참조한다.
또한, 예외 복귀 핸들링 사전결정된 서명(190)이 피호출자 스택 프레임(182)의 일부로서 스택 상에 존재한다고 예상되는지 여부의 체크를 포함할 수 있다. 이는 WO 2014/053804 A1의 도 14에 따라 결정될 수 있다. 사전결정된 서명(190)이 존재한다고 예상되지만 사전결정된 서명과 비교되는 스택 상의 위치의 콘텐츠가 매칭되지 않는 경우, 결함이 트리거될 수 있는데, 그 이유는 이것이 예외 복귀 메커니즘이 함수 호출에 응답하여 저장된 스택 프레임에 기초하여 시도되었던 경우들을 검출할 수 있기 때문이다. 결함의 생성은 WO2014/053804 A1의 도 7에 도시되어 있다.
예외 복귀 핸들링 동작들은 또한 다른 동작들, 예컨대, 로딩된 스택 프레임 내의 ERETPSR 값에 기초하여 복원된 예외 번호 값(36)을 업데이트하는 것 및 복귀되는 프로세싱의 우선순위에 기초하여 예외 우선순위 레벨을 변경하는 것을 포함할 수 있다.
또한, 단계(424)에서 제어 레지스터(32)의 TMID 값(34)이 분기되었던 더미 예외 복귀 어드레스 내에 포함된 TMIE 플래그(158)에 기초하여 복원될 수 있다. 대응하는 예외가 적용되기 전에 TMID(34)가 가졌던 값과 매칭하기 위하여 스레드 모드에서의 도메인 전이가 인에이블되어야 하는지 아니면 디스에이블되어야 하는지 나타내도록, TMIED 플래그(34)의 복원된 값은 TMIE 플래그(158)의 값의 역에 대응할 수 있다. 예외 복귀들을 핸들링 시 본 명세서에서 논의되지 않은 많은 다른 동작들이 또한 수행될 수 있음을 이해할 것이다.
도 15는 도 14의 단계(414)에서 함수 복귀 어드레스로의 분기를 위해 수행된 동작들을 더 상세하게 도시한다. 단계(440)에서 프로세싱 회로부는 분기를 위한 분기 타겟 어드레스로서 검출된 더미 함수 복귀 어드레스(140)가 모드간 함수 복귀를 나타내는지 결정한다. 예를 들어 이는 핸들러에서 스레드 모드로의 모드간 호출 시 대응하는 함수 복귀 값이 설정되었음을 명시하기 위하여 모드간 표시자(146)가 0인지 여부의 체크일 수 있다. 시도된 함수 복귀가 모드간 함수 복귀가 아닌 경우, 그것은 도메인간 함수 복귀이다(그 이유는 대응하는 함수 호출이 모드간 호출도 아니고 도메인간 호출도 아닌 경우, 링크 레지스터는 단순히 함수 복귀 어드레스로 설정되었을 것이고, 더미 함수 복귀 어드레스를 사용할 필요가 없었을 것이기 때문이다).
단계(442)에서 도메인간 함수 복귀의 경우, 스레드 모드 상태간 디스에이블 플래그 TMID(34)의 체크가 수행된다. 현재 모드는 스레드 모드이고 스레드 모드에서 도메인 전이가 디스에이블됨을 나타내기 위하여 TMID 플래그(34)가 1인 경우, 단계(444)에서 INVTMI UsageFault는 도 12의 단계(308) 또는도 14의 단계(408)에서와 같이 다시 트리거된다. 그러나, 단계(444)에서 INVTMI 결함은 어떤 도메인이 분기가 시도되었을 때의 현재 도메인(즉, 단계들(308, 408)의 경우와 같은 안전한 도메인이 아닌, 도메인간 함수 복귀가 시도되는 소스 도메인)이든 핸들링된다. 이는 분기를 요청했던 스레드의 관리를 담당하는 프로세스가 결함을 핸들링하고 이어서 필요에 따라 목적지 도메인에 필요한 리소스들을 구성할 수 있음을 보장한다.
단계(442)에서 현재 모드가 핸들러 모드인 것으로 결정되거나 또는 TMID 플래그(34)가 상태간 전이가 인에이블됨을 나타내는 0인 것으로 결정되는 경우 단계(446)에서 분기는 진행되도록 허용될 수 있다. 분기가 이루어지는 함수 복귀 어드레스(174)는 현재 동작 모드, 전이되는 보안 도메인에 기초하여 결정된 관련 스택으로부터 판독되고, 스레드 모드에 있는 경우, 스택 포인터 선택 값(30)에 기초한다. 도메인간 전이가 허용되는지 검증하는 데 필요한 임의의 무결성 체크가 수행된다. 이 무결성 체크는 예를 들어 함수 복귀 스택 프레임(172) 내의 예외 번호(179)가 스택 프레임이 현재 동작 모드와 동일한 모드에서 생성되었음을 나타내는지 여부(즉 현재 동작 모드가 스레드 모드인 경우 예외 번호(179)는 0이고, 현재 동작 모드가 핸들러 모드인 경우 0이 아님)뿐만 아니라, 도메인간 함수 복귀에 예상되는 바와 같이 HDT 플래그(178)가 0인지 여부의 체크를 포함할 수 있다. 또한, 허용되는 도메인 전이를 제한하는 임의의 다른 요건들이 체크될 수 있다. 무결성 체크가 통과되는 경우 함수 복귀 어드레스(174)로의 분기는 계속되도록 허용되고 후속 프로세싱은 함수 복귀 어드레스(174)로부터 페치된 명령어로부터 계속된다(이것은 실제로 도 14의 단계(400)에서 발생된 시도된 분기의 타겟 어드레스로서 명시된 더미 함수 복귀 어드레스(140)가 아닌, 함수 복귀 스택 프레임(172)으로부터 로딩된 실제 함수 복귀 어드레스이다). 함수 복귀 스택 프레임(172)을 지목하는 스택 포인터는 스택 데이터 구조로부터의 함수 복귀 스택 프레임의 스택해제 및 제거를 고려하도록 조정될 수 있다. 필요한 무결성 체크둘 중 임의의 것이 실패하는 경우 결함이 신호된다(이는 안전한 도메인에서 프로세싱될 수 있는 보안 결함일 수 있다).
단계(440)에서 시도된 함수 복귀가 모드간 함수 복귀인 것으로 결정되는 경우 단계(450)에서 프로세싱 회로부는 현재 도메인이 덜 안전한 도메인인지 그리고 더미 함수 복귀 어드레스(140) 내의 보안 도메인 표시자(148)가 안전한 도메인으로의 복귀가 요청됨을 나타내는지 결정한다. 이것이 그 경우인 경우, 단계(452)에서 현재 도메인(덜 안전한 도메인)에서 핸들링될 INVPC 사용 결함이 트리거된다. 이 결함이 트리거되어 위 도 9에 도시된 바와 같이 덜 안전한 스레드 모드에서 안전한 핸들러 모드로의 금지된 도메인/모드 조합 전이를 방지하며, 이는 그렇지 않으면 보안 취약성을 제기할 수 있다.
시도된 모드간 함수 복귀가 덜 안전한 도메인에서 안전한 도메인으로 것이 아닌 경우 (동일한 도메인 내에 남거나 또는 안전한 도메인에서 덜 안전한 도메인으로의 것) 방법은 단계(454)로 진행하고, 여기서, 구성되는 경우, 에러 동기화 차단 동작은 도 12의 단계(328)에 있는 것과 유사하게 트리거된다. 다시, 모드간 함수 복귀 시 에러 동기화 차단을 트리거함으로써, 에러가 모드간 함수 복귀 전에 실행되는 덜 권한부여된 프로세싱에 귀속될 수 있는 경우, 공격적 시스템 리셋 동작들에 대한 필요성을 감소시키도록 에러들의 정확한 지목을 도울 수 있다.
단계(456)에서, 모드간 함수 복귀 명령어에 응답하여, 프로세싱 회로부는 복귀가 이루어지고 있는 목적지 보안 도메인과 연관된 메인 스택으로부터 함수 복귀 스택 프레임(172)을 로딩한다. 단계(458)에서 프로세싱 회로부는 무결성 크로스-체킹 동작들을 수행하고, 그 무결성 크로스-체킹의 결과물이 성공적인지 결정한다. 이 무결성 크로스-체킹은 함수 복귀 스택 프레임 상에서 다수의 아이템들을 체크할 수 있다. 예를 들어, 프로세싱 회로부는 함수 복귀 어드레스(174)가 예약된 범위(130)의 어드레스들 중 하나인지 체크할 수 있다. 함수 복귀 어드레스가 예약된 범위의 어드레스들 중 하나인 경우, 함수 복귀가 실제로 함수 복귀 스택 프레임(172) 내의 함수 복귀 어드레스(174)와 동일한 스택 상의 상대적 위치에 사전결정된 서명(190)을 포함하는 예외 스택 프레임인 스택 프레임에 기초하여 시도된다는 표시일 수 있으며, 이러한 예외 및 함수 엔트리들 및 복귀들의 미스매칭은 공격을 위한 경로가 될 수 있다. 따라서, 스택 프레임 상의 함수 복귀 어드레스(174)가 예약된 어드레스(130)인 경우, 무결성 크로스-체킹은 실패한다.
또한, 무결성 크로스-체킹의 일부로서 프로세싱 회로부는 현재 모드가 스레드 모드인 지, 제어 레지스터들(20) 내의 예외 번호 값(36)에 기초하여 체크한다. 현재 모드가 핸들러 모드인 경우, 무결성 크로스-체킹은 실패한다.
또한, 무결성 크로스-체킹은 함수 복귀 스택 프레임 내의 예외 번호 필드(179)를 체크하는 것을 포함하며, 0인 경우, 무결성 크로스-체크가 실패하도록 트리거하는데, 그 이유는 모드간 함수 복귀가 스레드 모드에서 핸들러 모드로 복귀하도록 예상되기 때문이다.
또한, 무결성 크로스-체킹은 HDT 플래그(178)를 이용하여 함수 복귀 스택 프레임이 모드간 호출 분기 명령어에 응답하여 저장되었는지 검출한다. HDT 플래그가 0인 경우, 함수 복귀 스택 프레임은 모드간 함수 호출이 아니라 도메인간 함수 호출에 응답하여 설정되었음을 나타낸다(도 12의 단계(312) 참조), 그리고 이어서 무결성 크로스-체킹은 실패한다. 다시, 이는 미스매칭된 함수 호출들 및 복귀들의 시퀀스들을 금지하여 미스매칭 스택 프레임들에 기초한 공격들의 기회를 제한하고, 또한 일반적으로 액세스가능한 링크 레지스터에서 저장되는 동안, 더미 함수 복귀 어드레스(140) 내의 모드간 플래그(146)의 잠재적 수정으로부터 보호하고, HDT 플래그(178)는 모드간 플래그가 정확했는지 체크하기 위한 크로스-체크 값의 역할을 한다.
무결성 크로스-체크들 중 임의의 것이 실패하는 경우, 단계(460)에서 보안 체크의 실패가 발생했음을 나타내는 INVPC 사용 결함이 트리거되고, 이러한 유형의 결함은 분기되도록 시도하는 코드와 연관되는 목적지 보안 도메인에서 핸들링된다.
대안적으로, 모든 무결성 크로스-체크가 통과하면, 단계(462)에서 모드간 함수 복귀는 작동될 수 있다. 모드간 함수 복귀가 수행되면 단계(462)에서 다수의 작동들이 수행된다. 보안 상태는 더미 함수 복귀 어드레스(140) 내의 보안 도메인 표시자(148)에 의해 표시되는 보안 상태가 되도록 업데이트된다. 이는 보안 도메인이 대응하는 모드간 함수 호출이 이루어지기 전에 실행되고 있었던 도메인으로 복원되는 것을 보장한다.
또한, 단계(462)에서, 모드간 함수 복귀 이전에, TMID 플래그(34)가 0이었는지 아니면 1이었는지 기록하기 위한 표시가 저장된다. 이 표시는 예외 엔트리 시 저장되는 TMIE 플래그(158)와는 별개이다. TMID의 이전 값의 표시가 저장되는 위치는 실시예마다 다를 수 있다. 예를 들어, 표시는 범용 레지스터(16)에 저장될 수 있거나, 또는 후속 조건부 명령어들에 의해 직접 검사될 수 있는 플래그들 레지스터 내의 조건 플래그들과 같은 제어 레지스터(20)에 저장될 수 있다.
또한, 단계(462)에서 제어 레지스터(32) 내의 TMID 값(34)은 스레드 모드 도메인 전이가 이제 다시 인에이블됨을 나타내도록 0으로 설정될 수 있다. 이는 모드간 함수 복귀 이전에 실행되는 예외 핸들러 코드의 권한박탈된 섹션이 안전한 도메인들을 전환하려고 시도했는지 여부에 상관없이, 더 권한부여된 래퍼 코드로 복귀 시 도메인 전이 디스에이블링 구성 값(34)은 일관된 상태에 있을 수 있도록 보장한다.
또한, 단계(462)에서 모드간 함수 복귀 시 함수 복귀 스택 프레임이 로딩되었던 목적지 스택 포인터는 스택해제된 데이터가 스택으로부터 제거된 것을 고려하여 조정될 수 있다. 또한, 목적지 도메인에 대한 스택 포인터 선택 값(30)은 메인 스택 포인터가 선택되어야 함을 나타내도록 업데이트되고 현재 동작 모드는 함수 복귀 스택 프레임(172) 내의 예외 번호 필드(179)로부터 예외 번호 레지스터(36)를 복원함으로써 핸들러 모드로 전환된다(이전 무결성 체크는 단계(458)에서 예외 번호 필드(179)가 0이 아님을 체크했을 수 있고, 따라서 예외 번호 레지스터(36)를 복원하는 것은 현재 모드를 핸들러 모드로 전환할 것이다). 단계(464)에서 함수 복귀 스택 프레임(172)으로부터 획득된 실제 함수 복귀 어드레스(174)로의 분기가 수행되어, 프로세싱될 다음 명령어는 함수 복귀 어드레스에 있는 명령어이다.
따라서, 함수 호출 시 저장된 더미 함수 복귀 어드레스(140)(ISR(201)의 메인 본체)를 이용하여 후속 함수 복귀가 모드간 함수 복귀여야 하는지 여부를 신호함으로써, 함수 복귀를 트리거하는 명령어 자체는 그것이 모드들을 스위칭하는지 여부를 알 필요가 없게 되고, 모드간 함수 호출들 및 복귀들에 대한 지원을 완전히 모르게 기록된 레거시 예외 핸들러 코드가 여전히 사용될 수 있게 된다. 이는 위 도 7 및 도 8에 관련하여 설명된 인터럽트 권한박탈 시나리오에 특히 유용하다. 즉, 함수 복귀 분기 명령어는 그것이 모드간 분기인지 여부에 상관없이 동일한 인코딩을 가질 수 있다.
유의할 점은 도 14 및 도 15에서, 주어진 타겟 어드레스로의 분기를 트리거하는 명령어는 프로그램 카운터 레지스터(R15)로 하여금 분기 타겟 어드레스로 수정되게 하는 다양한 명령어들 중 임의의 것일 수 있다. 일부 경우들에서 이는 전용 분기 명령어일 수 있지만, 그것은 또한 분기 타겟 어드레스를 프로그램 카운터 레지스터로 이동시키는 레지스터 이동 명령어, 또는 스택 데이터 구조로부터 정보를 팝핑하고 정보를 프로그램 카운터 레지스터에 로딩하는 스택 팝 명령어일 수 있다. 특히 분기가, 대응하는 함수/예외 복귀 전에 추가 함수 호출이 이루어지는 경우 결국 스택으로 저장될 수 있는, 더미 함수 복귀 어드레스들(140) 또는 더미 예외 복귀 어드레스들(142) 중 하나인 경우에, 먼저 복귀 어드레스를 링크 레지스터에 로딩하고 이어서 링크 레지스터를 명시하는 복귀 분기를 실행하기 보다는, 컴파일러가 복귀 어드레스를 스택 프레임에서 프로그램 카운터 레지스터로 직접 이동시키는 코드를 생성하는 것이 더 효율적일 수 있다. 따라서, 실제 함수 복귀 어드레스, 더미 함수 복귀 또는 더미 예외 복귀 어드레스는 초기에 함수를 호출하거나 또는 예외를 적용할 때 링크 레지스터에 저장될 수 있지만, 대응하는 복귀가 실행될 때까지 더 이상 링크 레지스터에 있지 않을 수 있고, 도 14 및 도 15에서 분기 동작들을 트리거하는 명령어는 실제로 전용 분기 명령어가 아닐 수 있다는 것이 이해될 것이다.
도 16a 내지 도 16d는 위에서 설명한 체크들을 이용하여 방지될 수 있는 가능한 공격들의 예들을 도시한다. 이러한 공격들은 미스매칭되는 예외 또는 함수 호출들 및 복귀들의 시퀀스에 기초할 수 있으며, 이들은 호출에 의해 설정되고 복귀 시 예상되는 미스매칭된 스택 프레임들을 악용하려고 시도할 수 있다.
도 16a의 예에서 예외는 단계 1에서 안전한 핸들러 모드에서의 프로세싱 동안 발생하고, 예외는 덜 안전한 도메인에서 적용되고 따라서 호출자 및 피호출자 스택 프레임들(180, 182) 둘 모두 스택에 저장된다. 도 16a의 단계 2에서 결국 프로세싱이 안전한 스레드 모드에서 수행되게 하는 일련의 예외 복귀들 및/또는 함수 호출들이 이루어진다. 안전한 스레드 모드가 되면, 단계 3에서 단계 1에서 설정된 예외 스택 프레임들(180, 182)에 기초하여 모드간 함수 복귀를 수행하려는 시도가 이루어진다. 예를 들어, 이는 더미 함수 복귀 값들(140) 중 하나로 분기함으로써 수행될 수 있다. 이러한 유형의 공격은 검출될 수 있는데, 그 이유는 함수 복귀 시 도 15의 단계(458)에서의 무결성 크로스-체킹은 함수 복귀 어드레스(174)가 예약된 범위의 어드레스들(130) 중 하나임을 검출할 것이기 때문이다(사전결정된 서명(190)이 예상된 함수 복귀 스택 프레임(172)이 아닌, 단계 3에서 로딩된 예외 스택 프레임의 하부에 있을 것이기 때문임).
도 16b는 단계 1에서 안전한 도메인에서 덜 안전한 도메인으로 도메인간 함수 호출이 이루어져, 함수 복귀 스택 프레임(172)이 안전한 메인 스택에 저장되게 하는 제2 예를 도시한다. 다시, 단계 2에서 일련의 다른 전이가 수행되고 이어서 단계 3에서 단계 1에서 설정된 도메인간 스택 프레임에 기초하여 모드간 함수 복귀가 시도된다. 이 모드간 함수 복귀는 성공하도록 허용되어서는 안되는데, 그 이유는 대응하는 호출이 모드간 호출이 아니라 도메인간 호출이었기 때문이다. 이것은 검출되는데, 그 이유는 함수 복귀 스택 프레임 내의 HDT 값(178)이 단계 1에서 도메인간 함수 호출 시 0으로 설정될 것이고, 단계 3에서 모드간 함수 복귀를 위하여 1이어야 하므로, 따라서 도 15의 단계(458)에서 무결성 크로스-체크는 실패할 것이기 때문이다.
도 16c는 다른 잠재적 공격을 도시하는데, 여기서 먼저 단계 1에서 핸들러 모드에서 스레드 모드로 권한박탈되는 모드간 함수 호출이 이루어지고, 이어서 단계 2에서 일련의 다른 전이가 후속하고, 나중에 단계 3에서 도메인간 함수 복귀를 수행하려는 시도 시 단계 1에서 설정된 모드간 함수 복귀 스택 프레임에 기초하여, 덜 안전한 도메인에서 안전한 도메인으로 전이가 이루어진다. 도 15의 단계(446)에서 함수 복귀 스택 프레임(172) 내의 HDT 값(178)이 0인지 여부의 무결성 체크가 수행되고, HDT 값이 1인 경우, 결함이 트리거될 수 있다. 따라서, 모드간 함수 호출이 이루어지는 도 16c의 시나리오에서 도메인간 함수 복귀가 시도되고, 이어서 HDT 체크는 미스매치를 검출할 것이고, 단계 1에서 생성된 모드간 스택 프레임이 단계 3의 도메인간 스택 프레임으로서 해석될 수 없도록 보장할 것이다. 유의할 점은 단계들(446, 458)에서의 HDT 체크들은 더미 함수 복귀 어드레스 내의 모드간 플래그 M(146)와 함수 복귀 스택 프레임 내의 HDT 플래그(178) 사이의 비교와 동등한 것으로 간주될 수 있는데, 그 이유는 이 비교에서 식별되는 미스매치는 모드간 복귀의 경우(도 16b) 또는 도메인간 복귀의 경우(도 16c)에 결함을 트리거할 것이기 때문이라는 것이다.
계속 도 16c를 참조하면, 단계 3에서 도메인간 복귀를 수행하는 대신에(모드간 플래그 M = 0), 공격자는 모드간 함수 복귀를 시도했을 수 있다(모드간 플래그 M = 1). 대응하는 함수 호출이 실제로 모드간 호출이었지만, 그것은 여전히 시도된 모드간 함수 복귀와 매칭되지 않는데, 그 이유는 단계 3 전의 현재 모드가 스레드 모드가 아니라 핸들러 모드이기 때문이다. 이 경우에, 모드간 호출 값(146)이 단계 1에서 모드간 호출 시 설정된 함수 복귀 스택 프레임 내의 HDT 값(178)과 매칭될 수 있지만, 공격은 방지되는데, 그 이유는 현재 상태가 핸들러 모드일 때 모드간 함수 복귀가 허용되지 않기 때문이며, 이는 현재 모드가 스레드 모드인지 여부를 체크하는 도 15의 단계(458)에서 무결성 체크에 의해 잡힐 것이다.
도 16d는 도메인간 스택 프레임은 단계 1에서 안전한 도메인에서 덜 안전한 도메인으로의 도메인간 분기 명령어로 인해 설정되고, 순차적으로 단계 2에서 안전한 도메인으로 복귀하기 위한 일련의 전이가 이루어지고, 이어서 단계 3에서 단계 1의 도메인간 분기에 의해 설정된 스택 프레임을 이용하여 모드간 함수 복귀를 수행하려는 시도가 이루어지는 다른 예를 도시한다. 이러한 유형의 공격은 성공할 수 없는데, 그 이유는 함수 복귀 스택 프레임(172) 내의 예외 번호 필드(179)는 단계 1에서 설정된 스택 프레임이 핸들러 모드가 아니라 스레드 모드에서 설정되었음을 나타낼 것이고, 이는 모드간 함수 복귀가 엔트리를 요구할 것이기 때문이다. 대안적으로, 단계 2'에 도시된 바와 같이 비-안전한 스레드 모드에서 안전한 핸들러 모드로의 도메인 및 모드의 조합된 전이가 시도된다면 다시 이것은 실패할 것이며, 그 이유는 단계(450)에서 허가되지 않은 조합된 전이는 금지될 것이기 때문이다.
체크들 중 일부는 중첩될 수 있고 동일한 유형의 공격이 하나 초과의 유형의 체크의 실패를 트리거할 수 있음을 이해할 것이다. 일부 아키텍처 구현예들의 경우, 이러한 체크들 중 일부가 중복인 것으로 간주되는 경우 그것들은 아키텍처 요건들에서 제거될 수 있어서, 무엇으로부터 보호하는 것이 중요하다고 고려되는지에 따라, 모든 상이한 유형들의 공격 방지 메커니즘들을 반드시 수행해야 하는 것은 아니다. 그러나, 임의의 하나 이상의 이러한 체크들이 제공될 수 있다. 도 16에 도시된 공격들은 공격자가 원래 전이와 매칭되지 않고 따라서 생성된 스택 프레임의 유형과 매칭되지 않는 복귀 동작(함수 또는 예외 복귀)을 시도함으로써 시스템의 상태를 손상시키려고 하는 방대한 수의 유사한 미스매치 유형 공격들의 상이한 조합들 중 단지 작은 선택임을 이해할 것이다.
도 12, 도 14 및 도 15의 단계들(307, 406, 442)은 함수 호출 분기, 비-함수 호출 분기 및 함수 복귀 각각에 대하여 도메인 전이 디스에이블 구성 파라미터(TMID)(34)를 체크하는 특정 예들을 도시한다. 그러나, 일부 아키텍처들에서 또한 도메인들 사이의 전이를 트리거하는 것이 가능한 다른 유효한 수단들이 있을 수 있고, 도 17은 TMID 값의 체크를 핸들링하는 더 일반적인 접근법을 도시한다. 단계(500)에서 현재 모드에서 안전한 도메인에서 덜 안전한 도메인으로의 전이 또는 현재 모드에서 덜 안전한 도메인에서 안전한 도메인으로의 전이를 수행하려는 가능한 시도가 검출된다. 시도는 도메인 전이를 수행하려는 실제 시도일 수 있거나 또는 다른 보안 또는 무결성 체크가 통과된다면 단지 때때로 이러한 도메인 전이를 트리거할 수 있는 동작일 뿐일 수 있지만, 도메인 전이가 실제로 허용될 지, 또는 다른 체크가 실패하고 결함이 발생될 지 아직 검출될 수 없을 정도로 TMID 체크가 충분히 일찍 수행되는 경우, 도메인 전이를 항상 트리거할 수 있는 것은 아니다.
단계(502)에서, 도메인 전이를 트리거하려는 가능한 시도가 검출되는 경우, 현재 모드가 스레드 모드인지 결정된다. 현재 모드가 스레드 모드인 경우, 단계(504)에서 프로세싱 회로부는 TMID 값(34)이 스레드 모드에서 도메인 전이가 디스에이블됨을 나타내는지 결정한다. 현재 모드가 스레드 모드이고 스레드 모드에서 도메인 전이가 디스에이블되는 경우, 단계(506)에서 디스에이블된 도메인 전이 결함(예컨대 전술된 INVTMI UsageFault)이 신호된다. 시도된 도메인 전이가 작동되기 전에는 결함은 현재 안전한 도메인에서 핸들링되므로, 시도된 도메인 전이가 안전한 것에서 덜 안전한 것으로인 경우, 결함은 안전한 도메인에서 핸들링되고 시도된 전이가 덜 안전한 것에서 안전한 것으로인 경우 그것은 덜 안전한 도메인에서 핸들링된다. 또한, 옵션적으로 일부 신드롬 정보는 제어 레지스터에 저장되어 결함이 발생했던 시도된 전이에 관한 정보를 나타낼 수 있다. 일부 구현예들에서, 신드롬 정보를 설정하는 것은 UsageFault 상태 레지스터(UFSR)에서 INVTMI 비트를 설정하는 것을 포함할 수 있다.
단계(502)에서 현재 모드는 핸들러 모드인 것이 검출되었거나 또는 단계(504)에서 TMID 값(34)이 스레드 모드에서 도메인 전이가 인에이블됨을 나타내는 것이 검출된 경우, 방법은 단계(508)로 진행하고, 여기서 적어도 시도된 전이가 덜 안전한 도메인에서 안전한 도메인으로의 것인 경우, 임의의 다른 필요한 보안 체크들이 통과되었는지 체크하고 만약 통과된다면 단계(510)에서 전이가 허용된다. 보안 체크가 필요 없다면 (예컨대 일부 유형들의 안전한 도메인에서 덜 안전한 도메인으로의 전이의 경우에 체크가 필요 없을 수 있는데, 그 이유는 안전한 코드는 덜 안전한 코드를 공격하지 않을 것으로 신뢰될 수 있기 때문임) 전이는 어떠한 보안 체크도 수행하지 않고 단계(510)에서 허용될 수 있다(즉 단계(508)는 이러한 전이의 경우에 생략될 수 있다). 대안적으로 보안 체크가 실패한다면, 단계(512)에서 결함이 트리거될 수 있고, 이는 안전한 도메인에서 핸들링될 수 있는데, 그 이유는 그것이 허가되지 않은 엔트리 또는 보안 상태로부터의 이탈과 관련되기 때문이다. 단계(512)에서 트리거되는 결함의 유형 및 설정되는 임의의 신드롬은 실패한 보안 체크의 유형에 따라 달라질 수 있다.
도 17은 단계들(502, 504)이 순차적으로 수행되는 것으로 도시하지만, 그것들은 또한 일부 예들에서 반대 순서 또는 병렬로 수행될 수 있다.
도 18 내지 도 20은 TMID 값(34)을 포함하는 사용 경우의 일부 예들을 도시한다. 도 18은 본질적으로 도 8의 예에 대응하며, 스레드 모드에서 프로세싱되는 메인 본체(201)를 포함하도록 예외 핸들러가 권리박탈되도록 모드간 호출을 포함한다. 이러한 예에서 예외는 안전하지 않은(또한 덜 안전한 것으로 알려진) 예외이고, 따라서 래퍼(203) 및 메인 본체(201)를 포함하는 예외 핸들러 프로세싱은 모두 안전하지 않은 도메인에 있다. 안전한/덜 안전한 도메인 경계를 가로지르는 임의의 스레드는 안전한 리소스들 및 덜 안전한 리소스들 둘 모두 구성되어야 한다(예컨대 MPU 구성 및 메모리에 할당된 연관된 스택 구조들의 스택 포인터들). 하나의 도메인에서만 동작하는 도 18에 도시된 T₂와 같은 스레드들의 경우, 메모리 낭비 및 컨텍스트 전환 시간 증가를 피하기 위하여 다른 도메인을 위한 리소스들을 할당하는 것을 피하는 것이 바람직할 수 있다. 따라서, 바람직하게는 시스템은 추가 리소스들이 사용될 지 여부에 상관없이 모든 스레드들을 위해 추가 리소스들을 할당하는 비용을 피할 수 있다. 모든 스레드에 대해 안전한 및 덜 안전한 리소스들 둘 모두를 구성하지 않는 이러한 능력은 또한 도 18에 도시된 바와 같이 스레드 모드로 다시 권한박탈될 필요가 있는 인터럽트들에 대하여 인터럽트 레이턴시를 개선하도록 도울 수 있어서, 래퍼 코드(203)가 실행되기에 그렇게 오래 걸릴 필요가 없게 될 것이며, 그 이유는 안전한 및 비-안전한 MPU들 중 하나 그리고 안전한 및 비-안전한 스택 포인터들 중 하나를 구성하는 것을 생략할 수 있기 때문이다.
이것을 핸들링하는 한가지 접근법은 단일 보안 상태(예컨대 도 18의 스레드 2의 예에서 덜 안전한 도메인)의 경우 스레드들에는 스택 및 MPU 구성이 할당될 수 있고,
스레드가 다른 안전한 도메인으로 전환하려고 시도하는 경우에만 다른 도메인을 위한 리소스들이 할당될 수 있는 것이다. 그러나, TMID 파라미터(34)가 없는 경우, 이것을 보강하고 지연 할당을 트리거하는 데 필요한 결함을 생성하는 유일한 방법은 프로세스가 액세스할 허가가 없거나 또는 영역 허가 데이터가 MPU(26)에 정의되어 있지 않은 어드레스에 액세스하려는 시도 시 어드레스 결함이 생성되도록 MPU(26)를 재구성하는 것일 것이다. 이것은 단점이 될 수 있는데, 그 이유는 MPU 구성들이 스레드마다 핸들링되기를 요구하고 프로세스마다 핸들링되기를 요구하지 않으며 또한 두 안전한 도메인들에 대하여 MPU들(26-S, 26-NS)을 포함함에 따라 상당히 많은 안전/비-안전 상호작용을 필요로 할 것이므로, 보안 도메인들 중 하나에 대하여 MPU 구성 동작들을 생략할 수 있는 장점을 제거하게 된다. 예를 들어, 안전한 스레드를 실행하기 전에 덜 안전한 운영 체제는 덜 안전한 상태로 분기하려는 시도가 결함을 일으키도록 그것의 덜 안전한 MPU(26-NS)를 재구성할 필요가 있을 수 있다. 따라서, MPU(26)를 이용하여 결함을 생성하는 것은 어렵고 성능 집약적일 수 있고, 안전한 및 덜 안전한 운영 체제 코드를 제공하는 상이한 당사자들이 코딩하기에 더 힘들 수 있다. 대안적으로, 어느 스레드들이 하나의 안전한 도메인만을 사용하고 어느 것들이 둘 모두를 사용할 지 미리 공지되는 경우, 이 정보는 지연 할당을 회피하는 데 사용될 수 있지만, 그러나 이것을 신뢰할 수 없는데 그 이유는 소프트웨어가 충돌할 수 있고 다른 상태에 액세스하려고 시도할 수 있거나, 또는 공격자가 이것을 악용하려고 시도할 수 있는 것이 가능하기 때문이며, 따라서 리소스들이 하나의 도메인에 대해서만 설정되어 있을 때 다른 도메인으로의 전이의 검출 시 결함을 알리는 메커니즘을 제공하는 것이 여전히 바람직할 수 있다.
대신에, 스레드 모드에서 도메인 전이를 선택적으로 디스에이블하는 TMID 파라미터(34)를 제공함으로써, 덜 안전한 도메인에만 있을 것으로 예상되는 스레드들(도 18의 T₂)이 초기에 도메인 전이를 디스에이블하도록 설정된 그것의 TMID 파라미터(34)를 가질 수 있고, 도메인들을 전환하려는 시도를 하는 경우에만 적절한 리소스들이 구성될 수 있도록 결함이 생성될 수 있게 된다.
따라서, 도 18은 권한박탈된 예외 핸들러 본체(201)로의 진입 시 스레드 모드 전이가 디스에이블되는 예를 도시한다(그 이유는 모드간 호출 분기 명령어의 BLXT 변형은 예외 핸들러 본체(201)로 호출하는 데 사용되기 때문이다). 이 경우에, 예외 핸들러의 본체(201)는 덜 안전한 도메인 내에 남아 있고, 안전한 도메인으로 전환하려는 시도를 하지 않아서, 메인 본체(201)가 나중에 래퍼 코드(203)로의 함수 복귀를 하려는 시간까지, 스레드(T₂)를 위한 안전한 도메인에 대한 MPU 또는 스택 리소스들을 구성하는 데 프로셋싱 리소스 또는 메모리 할당이 소비되지 않았다. 따라서, 이는 성능을 개선한다. 메인 본체(201)의 프로세싱이 완료되면 모드간 더미 함수 복귀 어드레스(140)로의 분기가 단계(604)에서 수행된다. 이는 핸들러 모드로의 복귀를 트리거하고 일부 구현예들에서 제어 레지스터(32) 내의 TMID 플래그(34)의 표시가 도 15의 단계(462)에 설명된 바와 같이 소거되기 전에 (예를 들어 범용 레지스터에) 저장되게 할 수 있다. 이어서 프로그램 흐름은 다시 래퍼(203)로 계속되며, 여기서 래퍼는 TMID 플래그(34)의 저장된 표시를 체크하고, 모드간 함수 복귀 이전에 단계(604)에서 TMID 플래그(34)가 1이었음을 결정한다. 따라서 래퍼(203)는 보안 상태와 연관된 리소스들이 여전히 백그라운드 스레드(T_2,)에 대해 구성되어 있고, 이 리소스들은 T₂의 백그라운드 프로세싱으로 복귀하기 위하여 예외 복귀를 수행하기 전에 재구성될 필요가 없다고 결정한다.
도 19는 유사한 시나리오를 도시하지만, 이 경우에 BLXT 명령어를 이용하여 권한박탈된 예외 핸들러 본체(201)를 호출한 후에, 그리고 이로부터 스레드 모드에 있는 동안 도메인간 전이를 디스에이블하며, 이번에는 본체는 안전한 도메인으로의 전환을 시도하고 이것은 전술한 바와 같이 사용 결함을 트리거한다. 이 결함은 핸들러 모드에서 핸들러 코드(608)에 의해 핸들링되는 예외를 야기하는데,
이는 도 19의 시점(600)에서 덜 안전한 도메인에서 안전한 도메인으로의 전이를 재시도할 수 있는 예외 핸들러 본체(201)로 복귀하기 전에, 안전한 MPU(26-S) 및 안전한 스택 포인터 레지스터들 내에 스레드(T₂)를 위한 리소스들의 할당 또는 구성을 요청할 수 있다(프로세싱이 비-안전한 T₂로 복귀하는 시점과 도메인간 전이(600) 사이의 간극은 도 19에서 명확성을 위해 과장되었다 - 도메인간 전이(600)는 실제로 T₂로의 복귀 후에 바로 그 제1 명령어에서 일어날 수 있음이 이해될 것이다). 안전한 도메인에서 요구되는 프로세싱의 섹션을 마친 후에, 시점(602)에서 도메인간 복귀가 수행될 수 있고 이어서 후속 프로세싱은 도 18에서와 동일하다.
도 19는, 도 19의 일부(604)에서 모드간 복귀를 수행 시, 권한박탈된 예외 핸들러 본체(201)에서 래퍼 코드(203)로 다시 전이하기 위하여, 스레드(T₂)를 위해 수행되는 스레드 모드에서 비-안전한 프로세싱에 대해 모드간 복귀 이전에 TMID 값(34)이 0이었는지 아니면 1이었는지 나타내기 위한 표시가 저장되는 시나리오를 도시한다. 이는 모드간 복귀 시 TMID 플래그를 소거하기 전에 래퍼 코드(203)에 대한 도메인 전이를 다시 인에이블하도록 수행된다. 위에 설명된 바와 같이 도 15의 단계(462)에서, 도 19의 단계(604) 전에 TMID(34)가 0이었는지 아니면 1이었는지 여부의 이러한 표시는 임의의 편한 위치, 예컨대, 제어 레지스터들, 범용 레지스터 또는 조건 코드들 중 하나에 저장될 수 있다. 이는 유용한데, 그 이유는, 프로세싱이 핸들러 모드에서 프로세싱될 비-안전한 래퍼 코드(203)로 복귀하면, 610에서 후속 코드가 도 18에 도시된 상황을 도 19에 도시된 것과 비교할 수 있게 하기 때문이다. 도 18에 도시된 시나리오에서와 같이, 안전한 도메인에서 프로세싱이 없었고, 임의의 안전한 스택 포인터들 및 MPU 구성은 여전히 안전한 도메인에서의 백그라운드 코드의 이전 프로세싱 동안 시점(606)에서 이전과 같이 설정될 수 있다. 대조적으로, 도 19에서 단계(601)에서 시도된 스레드(T₂₎를 위한 안전한 도메인으로의 진입은(단계(600)에서 재시도될 때 순차적으로 성공함) 도 19의 시점(608)에서의 스레드(T₂)를 위한 MPU/스택 리소스의 구성은 스레드 모드를 위하여 관련 MPU 콘텐츠들 및 스택 포인터 레지스터들을 변경할 것임을 의미한다. 따라서, 도 18 및 도 19의 일부(610)에서 실행되는 나머지 래퍼 코드(203)는 안전한 스택 포인터들 및 안전한 MPU 구성을 업데이트하여 부분(606)에 존재했던 정보를 복원하기 위하여 스레드(T_1,)의 안전한 부분으로 프로세싱을 복귀시키기 전에 그것이 필요한 지 여부를 결정할 필요가 있을 수 있다. 모드간 함수 복귀에서 단계(604) 이전에 TMID가 0인지 아니면 1인지 여부의 표시는 이 결정을 내리는 데 사용될 수 있다.
다른 구현예들에서, 모드간 복귀 이전에 도메인 전이가 스레드 모드에서 디스에이블되었는지 아니면 인에이블되었는지 여부의 표시가 저장되는 것이 필수적이지 않으며, 이 경우에 도 18 및 도 19의 단계(610)에서 래퍼 코드(203)는 간단히 항상 단계(606)에서 존재했던 안전한 리소스들을 복원하기 위한 동작들을 수행할 수 있다. 그러나, 스레드 모드 상태간 전이가 디스에이블되었는지 여부의 표시를 저장하는 도 19에 도시된 예는 요구되지 않는 경우 중복되는 스택 포인터 업데이트 동작들을 회피함으로써 성능 상 더 좋을 수 있다.
비교를 위해, 도 20은 다른 시나리오를 도시하는데, 여기서, IRQ 예외 핸들러가 권한박탈되면, 이번에는 예외 핸들러가 안전한 도메인 및 덜 안전한 도메인 둘 모두를 사용할 것으로 예상되고, 따라서 시점(620)에서 래퍼 코드(203)가 실행되는 동안 두 도메인들에 대하여 안전한 및 덜 안전한 리소스들을 구성하는 적절한 동작들이 수행되고 스레드 모드에서 권한박탈된 상태로 실행될 예외 핸들러의 메인 본체(201)는 도 18 및 도 19에서와 같이 BLXT 대신에 모드간 함수 호출 분기의 BLXTI 변형을 이용하여 호출된다. 따라서, 핸들러 모드에서 스레드 모드로의 모드간 함수 호출을 수행할 때, TMID 값(34)은 0으로 설정되어 스레드 모드에서 도메인 전이가 인에이블됨을 나타내고 따라서 이번에는 단계(622)에서 인터럽트 핸들러 본체가 안전한 도메인으로 전이하려고 시도할 때 허용되고 도 19의 예에서와 같이 결함이 필요하지 않다. 다시, 모드간 함수 복귀(64) 시 모드간 복귀 이전에 TMID가 0이었다는 표시를 저장하는 것은 스레드(T1)와 연관된 안전한 측의 스택 포인터들 또는 MPU 구성을 인터럽트가 발생하기 전에 그것들이 시점(628)에서 있었던 상태로 복원할 필요가 있을 것이라고 결정하기 위하여 626에서 실행되는 래퍼 코드(203)에 의해 사용될 수 있다. 래퍼 코드의 일부 구현예들에서, 래퍼 코드(203)는 도 20의 예에서 모드간 함수 복귀 동안 저장된 TMID 플래그의 표시를 체크하지 않을 수 있는데, 그 이유는 래퍼가 메인 본체(201)를 실행하기 전에 두 도메인들의 구성을 수행했기 때문에, 래퍼는 백그라운드 스레드(T₁)로 복귀하기 전에 두 도메인들을 위한 리소스들이 복원될 필요가 있음을 미리 알고 있을 것이기 때문이다. 이것은 모드간 함수 복귀 동안 저장된 TMID의 표시를 중복적으로 체크하는 것보다 더 단순한 접근법인 것으로 보일 수 있지만, 상이한 예외 핸들러들에 대해 상이한 래퍼들 사이에서 코드를 공유하는 것이 더 어렵게 될 수 있다. 따라서 두 접근법이 유용할 수 있다.
도 21은 도메인들을 전환하려는 시도 시 TMID 값(34)을 체크하는 데 유용할 수 있는 더 구체적인 시나리오의 다른 예를 도시한다. 이는 도 17의 일반적인 접근법에 속하는 다른 구체적인 예이다. 다른 방법은, 덜 안전한 도메인에서, SAU(24)에 의해 정의된 안전한 어드레스 영역들 중 하나의 어드레스로부터 명령어를 페치하려는 시도가 있을 때 도메인 전이가 발생할 수 있는 것이다. 단계(700)에서 명령어 페치 회로부(8)는 현재 도메인이 덜 안전한 도메인인지 그리고 SAU(24)에 의해 정의된 바와 같이 안전한 영역들 중 하나 내의 어드레스를 갖는 명령어를 페치하려는 시도가 있었는지 결정한다. 그렇지 않다면, 명령어 페치는 정상적으로 계속된다. 현재 도메인이 덜 안전한 도메인이고 명령어가 안전한 어드레스 영역으로부터 페치되려고 시도되는 경우, 단계(702)에서 현재 모드가 스레드 모드인지 그리고 상태간 디스에이블 플래그(TMID(34))가 스레드 모드에서 도메인 전이가 디스에이블됨을 나타내는지 체크되고, 그렇다면 단계(704)에서 INVTMI UsageFault가 트리거되어 도메인 전이가 일어나는 것을 방지한다. 이 결함은 현재 도메인, 즉 덜 안전한 도메인에서 핸들링된다. 유의할 점은 안전한 어드레스 영역으로부터 페치된 명령어가 실제로 도메인 전이를 트리거하지 않았을 가능성이 있지만, 그럼에도 불구하고 후속 보안 체크들이 통과되는 경우 전이가 발생할 수 있다고 가정하여 보수적으로 결함이 생성된다는 것이다. 페치 스테이지(8)에서 결함을 생성함으로써, 디스에이블된 도메인 전이에 의해 트리거된 UsageFault는 수행될 필요가 있을 수 있는 다른 유형들의 보안 체크들에 비교하여 상대적으로 일찍 평가되어서, 단지 안전한 리소스들이 아직 구성되지 않았다는 이유만으로 이러한 다른 보안 체크들이 실패하지 않도록 보장한다.
한편, 단계(702)에서 페치 스테이지(8)에서 현재 모드가 핸들러 모드이거나 또는 TMID(34)가 스레드 모드에서 도메인 전이가 인에이블됨을 나타낸다고 결정되는 경우, 단계(706)에서 명령어 페치는 진행되도록 허용된다. 안전한 어드레스 영역으로부터 페치된 명령어가 디코딩 스테이지(10)에서 도메인의 변경을 트리거하는 명령어로서 식별되는 경우(예컨대 안전한 도메인에 유효 엔트리 시점을 표시하는 보안 게이트웨이 명령어) 명령어가 실행 스테이지(12)에 도달하면 임의의 추가 보안 체크들을 받게 되고, 이러한 체크들을 통과하면 안전한 도메인으로의 전이가 허용된다.
따라서, 도 21은 TMID 값(34)의 체킹이 실행 스테이지(12)에서 반드시 발생하지는 않지만 명령어 페치 시 수행될 수 있는 예이다.
도 22는 사용될 수 있는 시뮬레이터 구현예를 예시한다. 전술된 실시예들은 관심 기법들을 지원하는 특정 프로세싱 하드웨어를 동작시키기 위한 장치 및 방법들과 관련하여 본 발명을 구현하지만, 컴퓨터 프로그램의 사용을 통해 구현되는 본 명세서에서 기술되는 실시예들에 따라 명령어 실행 환경을 제공하는 것이 또한 가능하다. 그러한 컴퓨터 프로그램들은, 그들이 하드웨어 아키텍처의 소프트웨어 기반 구현예를 제공하는 한, 종종 시뮬레이터들로 지칭된다. 다양한 시뮬레이터 컴퓨터 프로그램들은 에뮬레이터들, 가상 머신들, 모델들, 및 동적 이진 변환기(dynamic binary translator)들을 포함한 이진 변환기들을 포함한다. 전형적으로, 시뮬레이터 구현예는 호스트 프로세서(830) 상에서 구동되어, 호스트 운영 체제(820)를 선택적으로 구동하여, 시뮬레이터 프로그램(810)을 지원할 수 있다. 일부 배열물들에서, 하드웨어와 제공된 명령어 실행 환경 사이에 다수의 시뮬레이션 층들이 있을 수 있고/있거나, 동일한 호스트 프로세서 상에 제공된 다수의 별개의 명령어 실행 환경들이 있을 수 있다. 이력상, 강력한 프로세서들이 합리적인 속도로 실행되는 시뮬레이터 구현예들을 제공하는 데 요구되었지만, 그러한 접근법은 호환성 또는 재사용 이유들을 위해 다른 프로세서에 고유한 코드를 구동하려는 요구가 있을 때와 같은 소정 상황들에서 정당화될 수 있다. 예를 들어, 시뮬레이터 구현예는 호스트 프로세서 하드웨어에 의해 지원되지 않는 추가적인 기능성을 명령어 실행 환경에 제공할 수 있거나, 또는 상이한 하드웨어 아키텍처와 전형적으로 연관된 명령어 실행 환경을 제공할 수 있다. 시뮬레이션의 개요가 문헌["Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, Pages 53 - 63]에서 주어진다.
실시예들이 특정 하드웨어 구성물들 또는 특징부들을 참조하여 전술되었음을 고려한 결과로, 시뮬레이션된 실시예에서, 동등한 기능성이 적합한 소프트웨어 구성물들 또는 특징부들에 의해 제공될 수 있다. 예를 들어, 특정 회로부는 시뮬레이션된 실시예에서 컴퓨터 프로그램 로직으로서 구현될 수 있다. 유사하게, 레지스터 또는 캐시와 같은 메모리 하드웨어가 시뮬레이션된 실시예에서 소프트웨어 데이터 구조로서 구현될 수 있다. 전술된 실시예들에서 언급된 하드웨어 요소들 중 하나 이상의 하드웨어 요소들이 호스트 하드웨어(예를 들어, 호스트 프로세서(830)) 상에 존재하는 배열물들에서, 일부 시뮬레이션된 실시예들은, 적합한 경우, 호스트 하드웨어를 사용할 수 있다.
시뮬레이터 프로그램(810)은 컴퓨터 판독가능 저장 매체(이는 비일시적 매체일 수 있음) 상에 저장될 수 있고, 타깃 코드(800)(이는 애플리케이션들, 운영 체제들, 및 하이퍼바이저를 포함할 수 있음)에 프로그램 인터페이스(명령어 실행 환경)를 제공하는데, 이는 시뮬레이터 프로그램(810)에 의해 모델링되는 하드웨어 아키텍처의 애플리케이션 프로그램 인터페이스와 동일하다. 따라서, 전술된 바와 같은 모드간 호출 분기 명령어들을 포함하는, 타깃 코드(800)의 프로그램 명령들은 시뮬레이터 프로그램(810)을 사용하여 명령 실행 환경 내로부터 실행되어, 상기에서 논의된 장치(2)의 하드웨어 특징부를 실제로 갖지 않는 호스트 컴퓨터(830)가 이들 특징부들을 에뮬레이팅할 수 있게 할 수 있다.
도 22에 도시된 바와 같이, 시뮬레이터 프로그램(810)은 명령어 디코더(10)와 동등한 기능을 수행하는 명령어 디코딩 프로그램 로직(811), 프로세싱 프로그램 로직(812), 예외 제어 프로그램 로직(813) 및 메모리 액세스 체킹 프로그램 로직(814), 전술된 실행 스테이지(12), 예외 제어 회로부(28) 및 메모리 액세스 체크 회로부(22)를 포함한다. 명령어 디코딩 프로그램 로직(811)은 타겟 코드(800)의 명령어들을 디코딩하고, 인코딩된 명령어 유형에 따라, 프로세싱 프로그램 로직(812) 내의 다수의 프로그램 코드 시퀀스들 중 하나를 선택하며, 이는 호스트 하드웨어(830)를 제어하여 타겟 코드(800)의 디코딩된 명령어를 위한 시뮬레이션된 명령어 세트 아키텍처에 정의된 것들과 동등한 동작들을 수행한다. 시뮬레이션된 예외들이 발생하면, 예외 제어 프로그램 로직(813)은 전술된 예외 제어 회로부(28)와 유사한 방법으로 예외 핸들링을 제어한다. 시뮬레이터 프로그램(810)은 또한 레지스터 모방 프로그램 로직(815)을 포함하며, 이는 타겟 코드(800)의 명령어들에 의해 요구되는 레지스터 참조들을 호스트 장치에 의해 사용되는 호스트 메모리 어드레스 공간에 대한 동등한 메모리 액세스들에 맵핑하여, 시뮬레이터 프로그램에 의해 시뮬레이션되고 있는 타겟 데이터 프로세싱 장치의 레지스터들(14)의 콘텐츠에 대응하는 호스트 메모리 어드레스 공간 내에 데이터 구조들이 유지될 수 있도록 한다. 유사하게, 메모리 액세싱 프로그램 로직(817)은 타겟 코드(800)에 의해 요구되는 메모리 액세스들 및 명령어 페치들을 맵핑하는데, 이는 시뮬레이션된 어드레스 공간(816)으로부터의 어드레스들을 이용하여, 호스트 데이터 프로세싱 하드웨어(830)에 의해 사용되는 호스트 메모리 어드레스 공간 상에 한정된다. 예를 들어, 메모리 액세싱 프로그램 로직(817)은 스택 데이터 구조들(818)에 대한 액세스를 제어할 수 있는데, 이는 실제로 호스트 메모리 어드레스 공간에 저장되지만, 타겟 코드(800)의 관점에서는 시뮬레이션된 어드레스 공간(816)에 저장된 것으로 보인다.
따라서, 레지스터 모방 프로그램 로직(815)에 의해 모방된 제어 레지스터들은 전술된 TMID 플래그(34)를 포함할 수 있고, 프로세싱 프로그램 로직(812)은 TMID 플래그(34)에 기초하여 스레드 모드에서 도메인간 전이가 허용되는지 시뮬레이션할 수 있다. 레지스터 모방 프로그램 로직(815)은 모드간 함수 호출들 및 복귀들의 실행, 예외 엔트리 또는 복귀, 또는 TMID 플래그(34)에 기록하기 위한 기타 명령어들과 같은 이벤트들에 응답하여 TMID 플래그(34)를 설정하는 구성 파라미터 설정 프로그램 로직(819)을 포함할 수 있다. 또한, 명령어 디코딩 프로그램 로직(811)은 프로세싱 프로그램 로직(812)에 의해 표현된 시뮬레이션된 프로세서의 현재 모드를 핸들러 모드에서 스레드 모드로 전환하는 모드간 호출 분기 명령어에 응답할 수 있고, 이는 전술한 바와 같다.
본 출원에서, "...하도록 구성된"이라는 말은 장치의 요소가 정의된 동작을 수행할 수 있는 구성을 갖는다는 것을 의미하는 데 사용된다. 이러한 맥락에서, "구성"은 하드웨어 또는 소프트웨어의 상호연결의 배열 또는 방식을 의미한다. 예를 들어, 장치는 정의된 동작을 제공하는 전용 하드웨어를 가질 수 있거나, 프로세서 또는 다른 프로세싱 디바이스가 기능을 수행하도록 프로그래밍될 수 있다. "하도록 구성된"은, 장치 요소가, 정의된 동작을 제공하기 위해 어떤 방식으로든 변경될 필요가 있음을 암시하지는 않는다.
본 발명의 예시적인 실시예들이 첨부 도면들을 참조하여 본 명세서에 상세히 설명되었지만, 본 발명은 그러한 정확한 실시예들로 제한되지 않는다는 것 그리고 첨부된 청구범위에 의해 정의되는 바와 같은 본 발명의 범주 및 사상으로부터 벗어나지 않으면서 당업자에 의해 다양한 변경들, 및 수정들이 이루어질 수 있다는 것이 이해될 것이다.

Claims (24)

1. 장치로서,
   적어도 핸들러 모드 및 스레드 모드를 포함하는 복수의 모드들 중 하나에서 데이터 프로세싱을 수행하기 위한 프로세싱 회로부;
   예외 조건에 응답하여 상기 프로세싱 회로부를 제어하여 상기 핸들러 모드에서 예외 핸들러의 프로세싱으로 전환하는 예외 제어 회로부; 및
   상기 프로세싱 회로부를 제어하여 상기 데이터 프로세싱을 수행하기 위한 명령어들을 디코딩하기 위한 명령어 디코더를 포함하고,
   적어도 상기 프로세싱 회로부가 상기 핸들러 모드에 있을 때, 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여:
   함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고;
   상기 프로세싱 회로부의 현재 모드를 상기 스레드 모드로 전환하고;
   상기 분기 타겟 어드레스에 의해 식별된 명령어로 분기하도록 구성된, 장치.
2. 제1항에 있어서, 상기 프로세싱 회로부는 적어도 안전한 도메인 및 덜 안전한 도메인을 포함하는 복수의 보안 도메인들 중 하나에서 상기 데이터 프로세싱을 수행하도록 구성되고;
   상기 장치는 상기 프로세싱 회로부의 현재 보안 도메인에 따라 메모리 액세스가 허용되는지 체크하기 위한 메모리 액세스 체크 회로부를 포함하고;
   분기 타겟 어드레스를 명시하는 도메인간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 상기 함수 복귀 어드레스를 상기 함수 복귀 어드레스 저장 위치에 저장하고, 상기 분기 타겟 어드레스에 의해 식별되는 명령어로 분기하고, 상기 프로세싱 회로부의 현재 보안 도메인을 전환하도록 구성된, 장치.
3. 제2항에 있어서, 상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 상기 프로세싱 회로부의 상기 현재 보안 도메인을 변경하지 않으면서 상기 프로세싱 회로부의 상기 현재 모드를 상기 스레드 모드로 전환하도록 구성된, 장치.
4. 제2항 또는 제3항에 있어서,
   모드간 함수 복귀 명령어에 응답하여, 상기 프로세싱 회로부는 상기 프로세싱 회로부의 상기 현재 모드를 상기 핸들러 모드로 전환하고; 상기 함수 복귀 어드레스에 의해 식별되는 명령어로 분기하도록 구성되고;
   상기 모드간 함수 복귀 명령어에 응답하여, 상기 프로세싱 회로부는 제1 보안 도메인 및 상기 스레드 모드에서의 프로세싱으로부터 제2 보안 도메인 및 상기 핸들러 모드에서의 프로세싱으로 도메인/모드 조합 전환을 수행할 수 있는, 장치.
5. 제4항에 있어서, 상기 모드간 함수 복귀 명령어에 응답하여, 상기 프로세싱 회로부는:
   상기 제1 보안 도메인이 상기 안전한 도메인이고 상기 제2 보안 도메인이 상기 덜 안전한 도메인일 때 상기 도메인/모드 조합 전환을 허용하고;
   상기 제1 보안 도메인이 상기 덜 안전한 도메인이고 상기 제2 보안 도메인이 상기 안전한 도메인일 때 상기 도메인/모드 조합 전환을 금지하도록 구성된, 장치.
6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부의 상기 현재 모드가 상기 스레드 모드일 때 결함의 시그널링을 트리거하도록 구성된, 장치.
7. 제1항 내지 제6항 중 어느 한 항에 있어서, 함수 복귀 명령어에 응답하여, 상기 프로세싱 회로부는:
   상기 함수 복귀 어드레스에 의해 식별되는 명령어로 분기하고,
   상기 함수 복귀 명령어가 모드간 함수 복귀 명령어일 때, 또한 상기 프로세싱 회로부의 상기 현재 모드를 상기 핸들러 모드로 전환하도록 구성된, 장치.
8. 제7항에 있어서, 상기 모드간 복귀 분기 명령어에 응답하여, 상기 프로세싱 회로부는 상기 프로세싱 회로부의 상기 현재 모드가 상기 핸들러 모드일 때 결함의 시그널링을 트리거하도록 구성된, 장치.
9. 제1항 내지 제8항 중 어느 한 항에 있어서,
   상기 모드간 호출 분기 명령어 이외의 적어도 하나의 호출 분기 명령어의 경우, 상기 함수 복귀 어드레스 저장 위치는 링크 레지스터를 포함하고;
   상기 모드간 호출 분기 명령어의 경우, 상기 함수 복귀 어드레스 저장 위치는 스택 데이터 구조 상의 위치를 포함하는, 장치.
10. 제9항에 있어서, 상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 더미 함수 복귀 어드레스를 상기 링크 레지스터에 저장하도록 구성되고, 상기 더미 함수 복귀 어드레스는 상기 모드간 호출 분기 명령어에 응답하여 상기 더미 함수 복귀 어드레스가 저장되었음을 나타내기 위한 모드간 호출 표시 값을 포함하고;
    상기 더미 함수 복귀 어드레스가 상기 모드간 호출 표시 값을 포함할 때 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려는 시도에 응답하여, 상기 프로세싱 회로부는 상기 스택 데이터 구조 상의 상기 위치로부터 획득된 상기 함수 복귀 어드레스에 의해 식별되는 명령어로 분기하고, 상기 프로세싱 회로부의 상기 현재 모드를 상기 핸들러 모드로 전환하도록 구성된, 장치.
11. 제10항에 있어서, 상기 더미 함수 복귀 어드레스는:
    상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여 스레드 모드에서 핸들러 모드로의 전환이 요청되는지 여부;
    상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여 상기 프로세싱 회로부의 현재 보안 도메인 내에서 전환이 요청되는 지 여부; 및
    복수의 스택 데이터 구조들 중 어느 것이 상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여 상기 함수 복귀 어드레스가 획득되는 상기 스택 데이터 구조로서 사용되어야 하는지 중 적어도 하나를 나타내는, 장치.
12. 제10항에 있어서, 상기 더미 함수 복귀 어드레스의 일부분은 상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여 상기 프로세싱 회로부의 상기 현재 보안 도메인 내에서 전환이 요청되는지 여부를 나타내고;
    상기 현재 보안 도메인이 상기 안전한 도메인일 때 보안 게이트웨이 명령어에 응답하여, 상기 명령어 디코더는 복귀 어드레스의 일부분을 상기 덜 안전한 상태를 나타내는 값으로 설정하도록 구성되고;
    상기 복귀 어드레스의 일부분과 상기 더미 함수 복귀 어드레스의 상기 일부분은 상기 각각의 복귀 어드레스 값들 내에서 동일한 상대적 위치에 있는, 장치.
13. 제12항에 있어서, 상기 더미 함수 복귀 어드레스의 상기 부분은 상기 최하위 비트인, 장치.
14. 제10항 내지 제13항 중 어느 한 항에 있어서,
    상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 크로스-체킹 값을 상기 스택 데이터 구조에 저장된 스택 프레임 내의 제1 상대적 위치의 적어도 일부에 저장하도록 구성되고;
    상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여, 상기 프로세싱 회로부는 상기 모드간 호출 표시 값을 인코딩하기 위한 상기 더미 함수 복귀 어드레스의 일부분과 상기 스택 데이터 구조로부터 획득된 상기 스택 프레임 내의 상기 제1 상대적 위치의 상기 적어도 일부의 값의 비교를 수행하고, 상기 비교에 기초하여 결함의 시그널링을 트리거할 지 결정하도록 구성된, 장치.
15. 제14항에 있어서,
    상기 모드간 호출 분기 명령어 이외의 적어도 하나의 유형의 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 상기 크로스-체킹 값 이외의 값을 상기 스택 데이터 구조에 저장된 상기 스택 프레임 내의 상기 제1 상대적 위치의 상기 적어도 일부에 저장하도록 구성된, 장치.
16. 제10항 내지 제15항 중 어느 한 항에 있어서,
    상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 상기 스택 데이터 구조에 저장된 스택 프레임 내의 제2 상대적 위치의 적어도 일부에 상기 핸들러 모드를 나타내는 값을 저장하도록 구성되고;
    상기 더미 함수 복귀 어드레스가 상기 모드간 호출 표시 값을 포함할 때 상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여, 상기 프로세싱 회로부는 상기 스택 프레임 내의 상기 제2 상대적 위치의 상기 적어도 일부의 값이 상기 핸들러 모드를 나타내지 않을 때 결함의 시그널링을 트리거하도록 구성된, 장치.
17. 제10항 내지 제16항 중 어느 한 항에 있어서, 상기 더미 함수 복귀 어드레스가 상기 모드간 호출 표시 값을 포함할 때 상기 적어도 하나의 유형의 명령어가 상기 더미 함수 복귀 어드레스로 분기하려고 시도하는 것에 응답하여, 상기 프로세싱 회로부는:
    상기 프로세싱 회로부의 상기 현재 모드를 상기 핸들러 모드로 전환하기 전에, 상기 스택 데이터 구조로부터 획득된 상기 함수 복귀 어드레스가 명령어 실행이 금지된 예약된 어드레스들의 사전결정된 범위 내에 있는지 체크하고, 상기 함수 복귀 어드레스가 상기 예약된 어드레스들의 사전결정된 범위 내에 있을 때, 상기 스레드 모드에서 실행되는 프로그램 코드에 귀속된 결함의 시그널링을 트리거하도록 구성된, 장치.
18. 제17항에 있어서,
    상기 모드간 호출 분기 명령어의 경우, 상기 함수 복귀 어드레스 저장 위치는 스택 데이터 구조에 저장된 스택 프레임 내의 제3 상대적 위치에 있는 위치를 포함하고;
    예외 조건에 의해 트리거되는 적어도 하나의 유형의 예외 전이의 경우, 상기 예외 제어 회로부는 상기 스택 프레임 내의 상기 제3 상대적 위치에 저장된 상기 사전결정된 범위의 예약된 어드레스들 중 하나를 포함하는 스택 프레임을 상기 스택 데이터 구조에 저장하도록 구성되는, 장치.
19. 제1항 내지 제18항 중 어느 한 항에 있어서,
    상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 에러 동기화 차단 동작을 수행하여 상기 에러 동기화 차단 동작 전에 수행된 데이터 프로세싱과 연관된 에러들의 검출을 상기 에러 동기화 차단 동작 후에 수행된 데이터 프로세싱과 연관된 에러들의 검출로부터 분리하도록 구성된, 장치.
20. 제7항 또는 제8항에 있어서, 상기 모드간 함수 복귀 명령어에 응답하여, 상기 프로세싱 회로부는 에러 동기화 차단 동작을 수행하여 상기 에러 동기화 차단 동작 전에 수행된 데이터 프로세싱과 연관된 에러들의 검출을 상기 에러 동기화 차단 동작 후에 수행된 데이터 프로세싱과 연관된 에러들의 검출로부터 분리하도록 구성된, 장치.
21. 제1항 내지 제20항 중 어느 한 항에 있어서, 상기 프로세싱 회로부는 적어도 하나의 보안 도메인에서 상기 데이터 프로세싱를 수행하도록 구성되고;
    상기 장치는:
    적어도 보안 도메인 당 프로세스 스택 포인터 레지스터 및 보안 도메인 당 메인 스택 포인터 레지스터를 포함하는 복수의 스택 포인터 레지스터들;
    각각의 보안 도메인에 대하여, 메모리 내의 스택 데이터 구조에 액세스하기 위하여 스택 포인터를 제공하는 데 상기 스택 포인터 레지스터들 중 어느 것이 사용되어야 하는지 선택하기 위한 선택 회로부; 및
    보안 도메인 당 스택 포인터 선택 값을 저장하기 위한 적어도 하나의 스택 포인터 선택 값 저장 위치를 포함하고,
    상기 핸들러 모드에서, 상기 선택 회로부는 상기 메인 스택 포인터 레지스터를 선택하도록 구성되고;
    상기 스레드 모드에서, 상기 선택 회로부는 상기 스택 포인터 선택 값에 기초하여 상기 프로세스 스택 포인터 레지스터와 상기 메인 스택 포인터 레지스터 사이에서 선택하도록 구성되고;
    상기 적어도 하나의 보안 도메인 중 현재 보안 도메인에서 수행되는 상기 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코더는 상기 프로세싱 회로부를 제어하여 상기 스레드 모드에 있을 때 상기 프로세스 스택 포인터 레지스터가 선택되어야 함을 나타내기 위하여 상기 현재 보안 도메인에 대한 상기 스택 포인터 선택 값을 설정하도록 구성된, 장치.
22. 적어도 핸들러 모드 및 스레드 모드를 포함하는 복수의 모드들 중 하나에서 데이터 프로세싱을 수행하기 위한 프로세싱 회로부; 및 예외 조건에 응답하여 상기 프로세싱 회로부를 제어하여 상기 핸들러 모드에서 예외 핸들러의 프로세싱으로 전환하기 위한 예외 제어 회로부를 포함하는 장치에 대한 데이터 프로세싱 방법으로서,
    상기 방법은:
    분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어를 디코딩하는 단계; 및
    적어도 상기 프로세싱 회로부가 상기 핸들러 모드에 있을 때, 상기 모드간 호출 분기 명령어에 응답하여:
    함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하는 단계;
    상기 프로세싱 회로부의 현재 모드를 상기 스레드 모드로 전환하는 단계; 및
    상기 분기 타겟 어드레스에 의해 식별되는 명령어로 분기하는 단계를 포함하는, 방법.
23. 호스트 데이터 프로세싱 장치를 제어하여 타겟 프로그램 코드로부터 명령어들의 실행을 위한 명령어 실행 환경을 제공하기 위한 컴퓨터 프로그램으로서,
    적어도 핸들러 모드 및 스레드 모드를 포함하는 복수의 모드들 중 하나에서 데이터 프로세싱을 수행하기 위한 프로세싱 프로그램 로직;
    예외 조건에 응답하여 상기 프로세싱 프로그램 로직을 제어하여 상기 핸들러 모드에서 예외 핸들러의 프로세승으로 전환하기 위한 예외 제어 프로그램 로직; 및
    상기 프로세싱 프로그램 로직을 제어하여 상기 데이터 프로세싱을 수행하도록 상기 타겟 프로그램 코드의 명령어들을 디코딩하기 위한 명령어 디코딩 프로그램 로직을 포함하고,
    적어도 상기 프로세싱 프로그램 로직이 상기 핸들러 모드에 있을 때, 분기 타겟 어드레스를 명시하는 모드간 호출 분기 명령어에 응답하여, 상기 명령어 디코딩 프로그램 로직은 상기 프로세싱 프로그램 로직을 제어하여:
    함수 복귀 어드레스를 함수 복귀 어드레스 저장 위치에 저장하고;
    상기 프로세싱 프로그램 로직의 현재 모드를 상기 스레드 모드로 전환하고;
    상기 분기 타겟 어드레스에 의해 식별되는 상기 타겟 프로그램 코드의 명령어로 분기하도록 구성된, 컴퓨터 프로그램.
24. 제23항의 상기 컴퓨터 프로그램을 저장하는 컴퓨터-판독가능 저장 매체.

Images