KR20230079253A

KR20230079253A - 동적으로 생성된 코드의 하드웨어 검증

Info

Publication number: KR20230079253A
Application number: KR1020237014485A
Authority: KR
Inventors: 제프리 이. 고니온; 마이클 디. 스나이더; 필립 제이. 피즐로
Original assignee: 애플 인크.
Priority date: 2020-10-30
Filing date: 2021-10-29
Publication date: 2023-06-05
Also published as: US20240045678A1; DE112021005699T5; WO2022094165A1; US20220138313A1; US11709675B2; CN116368489A; US11816484B2; US20220137968A1

Abstract

일 실시예에서, 동적으로 생성된 코드는, 코드가 메모리의 미리 정의된 영역 내에서 실행을 유지하거나 또는 유효 엑시트 어드레스들의 세트 중 하나로 빠져나가는 것을 보장함으로써, 시스템에서 지원될 수 있다. 허용되지 않는 특정 명령어들의 배제 및 브랜치 타겟 어드레스들의 제어를 포함하여 다양한 기준들이 충족되는 것을 보장하기 위해 동적으로 생성된 코드의 실행을 허용하기 전에 동적으로 생성된 코드가 스캔되는 소프트웨어 실시예들이 설명된다. 동적으로 생성된 코드가 실행되도록 허용되지만 실행 기준들이 충족되는 것을 보장하기 위해 모니터링되는 하드웨어 실시예들이 설명된다.

Description

동적으로 생성된 코드의 하드웨어 검증

본 명세서에서 설명되는 실시예들은 컴퓨터 시스템에서 동적으로 생성된 코드를 관리하는 것에 관한 것이다.

컴퓨터 시스템에서 실행되는 소프트웨어 코드는 정적 코드 및 동적으로 생성된 코드를 포함할 수 있다. 정적 코드는 신뢰되는 소스에 의해 암호화 방식으로 서명될 수 있고, 따라서 시스템에서의 실행을 위해 인증되고 신뢰될 수 있다(예컨대, 코드는, 어떠한 악의적인 목적도 시도하지 않거나 또는 시스템을 "공격"하여 시스템의 제어를 취하거나 시스템 내의 데이터를 손상시키려고 시도하지 않을 것이기 때문에 신뢰된다). 동적으로 생성된 코드는 이러한 방식으로 인증될 수 없으며, 따라서 신뢰되지 않는다. 시스템의 보안을 손상시키지 않으면서 동적으로 생성된 코드를 성공적으로 실행하는 것은 난제이다.

다음의 상세한 설명은 첨부 도면들을 참조하며, 이제 도면들이 간단히 설명된다.
도 1은 동적 코드 생성 및 검증의 일 실시예를 예시하는 블록도이다.
도 2는 동적 코드 검증의 일 실시예를 예시하는 흐름도이다.
도 3은 도 2에 도시된 흐름도의 일부의 일 실시예를 더 상세히 예시하는 흐름도이다.
도 4는 도 3에 도시된 흐름도의 일부의 일 실시예를 더 상세히 예시하는 흐름도이다.
도 5는 컴퓨팅 디바이스의 일 실시예의 블록도이다.
도 6은 도 5에 도시된 프로세싱 유닛의 일 실시예의 더 상세한 블록도이다.
도 7은 도 6에 도시된 프로세싱 유닛의 실시예의 동작을 예시하는 흐름도이다.
도 8은 도 7에 도시된 흐름도의 일부의 일 실시예를 더 상세히 예시하는 흐름도이다.
도 9는 컴퓨팅 디바이스의 일 실시예의 블록도이다.
도 10은 컴퓨터 액세스가능한 저장 매체의 일 실시예의 블록도이다.
본 발명에 설명된 실시예들은 다양한 수정들 및 대안적인 형태들을 허용할 수 있지만, 그의 특정 실시예들이 도면들에 예로서 도시되고, 본 명세서에서 상세히 설명될 것이다. 그러나, 그에 대한 도면들 및 상세한 설명은 실시예들을 개시된 특정 형태로 제한하는 것으로 의도되는 것이 아니라, 그와는 반대로, 의도는 첨부된 청구범위의 사상 및 범주 내에 속한 모든 수정들, 등가물들, 및 대안들을 커버하기 위한 것임을 이해하여야 한다. 본 명세서에서 사용되는 표제들은 오직 구성 목적들을 위한 것이며 설명의 범위를 제한하기 위해 사용되는 것으로 의도되지 않는다.

동적으로 생성된 코드의 실행을 허용하기 전에, 코드가 시스템에서의 실행을 위한 기준들의 세트를 충족함을 검증하기 위한 다양한 실시예들이 아래에서 설명된다. 소프트웨어-기반 실시예들은 주로 도 1 내지 도 5와 관련하여 먼저 설명되고, 이어서 하드웨어-기반 실시예들은 주로 도 6 내지 도 8과 관련하여 설명될 것이다.

소프트웨어 실시예들

도 1은 동적 코드 생성기(10) 및 동적 코드 검증기(12)의 일 실시예의 블록도이다. 동적 코드 버퍼(14), 격리 영역들(18A-18B)에 의해 둘러싸인 동적 코드 실행 영역(16), 및 하나 이상의 정적 코드 영역들(20)이 또한 도 1에 예시된다. 블록들(14, 16, 18A-18B, 및 20)은 모두 컴퓨터 시스템 내의 시스템 메모리 내의 영역들일 수 있다. 예를 들어, 컴퓨터 시스템에서 하나 이상의 프로세서들에 의해 발행된 판독 및 기록 동작들에 의해 어드레싱가능한 메모리 어드레스 공간은 시스템 메모리에 맵핑될 수 있다. 유사하게, 동적 코드 생성기(10) 및 동적 코드 검증기(12)는 시스템 메모리에 저장되고 하나 이상의 프로세서들에 의해 실행되는 코드 시퀀스들일 수 있다. 정적 코드 실행 영역(들)(20) 및 동적 코드 실행 영역(16)은 또한 하나 이상의 프로세서들에 의해 실행될 코드 시퀀스들을 저장할 수 있다.

동적 코드 생성기(10)는 시스템에서의 실행을 위한 동적 코드를 생성하도록 구성될 수 있다. "동적으로 생성된 코드" 또는 "동적 코드"는 프로그램의 일부로서 실행될 프로그램의 실행 동안 (예를 들어, "런타임에") 생성되는 임의의 코드를 지칭할 수 있다. 예를 들어, 일부 프로그래밍 언어 구현들은 JIT(just in time) 컴파일을 가능하게 한다. 특정 프로그래밍 언어들은 JIT 컴파일, 예를 들어, JavaScript를 사용할 때 더 높은 실행 성능을 경험할 수 있다. JIT JavaScript 구현은, JavaScript 코드가 실행되고 있을 때 JavaScript 코드를, 컴퓨터 시스템 내의 프로세서들에 의해 구현된 명령어 세트 아키텍처에 의해 정의된 이진 명령어들로 컴파일할 수 있다. 동적으로 생성된 코드의 다른 예는 자체 수정 코드일 수 있다. 이름에서 암시되는 바와 같이, 실행중인 프로그램의 코드는 실행을 위해 새로운 코드를 생성하거나 이전에 생성된 코드를 수정하고, 이어서, 새롭게 생성되거나 수정된 코드를 실행한다. 동적으로 생성된 코드의 다른 예는 이진 변환이 이용될 때 발생할 수 있다. 이진 변환에서, 하나의 명령어 세트로 표현된 코드는 다른 명령어 세트의 대응하는 코드로 변환되고, 변환된 코드는 오리지널 코드에 의해 표현된 동작을 구현하도록 실행된다. 이진 변환 메커니즘들은 정적(예를 들어, 실행 전의 전체 프로그램의 변환), 동적(예를 들어, 프로그램이 실행되고 있을 때 프로그램의 변환), 또는 정적 및 동적 메커니즘들의 조합일 수 있다. 일반적으로, "코드" 또는 "코드 시퀀스들"은 컴퓨터 시스템의 프로세서들의 명령어 세트 아키텍처에서 정의된 복수의 명령어들을 지칭하며, 따라서 프로세서들은 (예를 들어, 해석된 프로그램들, 또는 실행가능한 코드로 컴파일되는 주어진 프로그래밍 언어로 기록된 소스 프로그램과 대조적으로) 코드를 페치하고 코드를 직접 실행할 수 있다.

대조적으로, "정적 코드" 또는 "정적으로 생성된 코드"는 프로그램의 실행의 시작 시에 시스템 메모리에서 완전히 이용가능한(예를 들어, 프로그램을 실행하기 위한 커맨드에 기초한 다른 제어 코드 또는 운영 체제에 의해 시스템 메모리에 로딩되는) 임의의 프로그램을 지칭할 수 있다. 따라서, 운영 체제 커널 및/또는 시스템 하드웨어는 프로그램이 실행되기 시작하기 전에 전체 프로그램을 "인식"할 수 있다. 일부 경우들에서, 프로그램들은 다른 코드(예를 들어, 운영 체제 제공 서비스들 또는 기능들, 런타임 시에 이용가능한 다른 코드 등)에 동적으로 링크된다. 그러나, 동적으로 링크된 코드는 또한 런타임 시에 완전히 이용가능하며, 따라서 정적으로 생성된다. 정적 코드는 실행을 위해 정적 코드 실행 영역(들)(20) 내로 로딩될 수 있다. 정적 코드 실행 영역(들)(20)은, 기록 허가가 아닌 실행 허가(또는 가능하게는 판독 및 실행 허가)만을 갖도록 운영 체제에 의해 제어될 수 있다. 따라서, 정적 코드 실행 동안, 정적 코드는 불변(예를 들어, 수정 불가능)일 수 있다. 운영 체제 자체(예를 들어, 커널 및 다양한 운영 체제 서비스들)가 또한 정적 코드 실행 영역(들)(20)에 있을 수 있다.

일부 경우들에서, 정적으로 생성된 코드는, 코드를 생성한 엔티티 또는 컴퓨터 시스템 상에서의 프로그램 실행을 인가하는 엔티티(예를 들어, 컴퓨터 시스템의 제조자)에 의해 암호화 방식으로 서명될 수 있고, 따라서 엔티티는 프로그램의 진실성을 증명하고, 엔티티는, 프로그램이 악의적 공격자가 아닌 것 및/또는 시스템의 무결성을 손상시킬 수 있는 동작들을 수행하려고 시도하지 않는 것을 검증한다. 동적으로 생성된 코드에 대해서는 그러한 증명이 발생하지 않을 수 있다.

동적으로 생성된 코드 시퀀스의 악의적인 공격 또는 심지어 잘못된 동작으로부터 컴퓨터 시스템 및 컴퓨터 시스템 상의 다른 프로그램들/데이터를 보호하기 위해, 동적 코드 검증기(12)가 제공된다. 동적 코드 생성기(10)는 동적 코드 버퍼(14)에 동적으로 생성된 코드를 기록하도록 구성될 수 있다. 코드가 완료되면, 동적 코드 생성기(10)는 동적 코드의 실행을 개시하려고 시도할 수 있으며, 이는 동적 코드 검증기(12)로 하여금 동적 코드 버퍼(14)에서 동적으로 실행되는 코드를 검증하게 할 수 있다. 동적 코드 검증기(12)는 동적 코드 생성기(10)에 대해 투명할 수 있다(예를 들어, 동적 코드 생성기(10)는 동적 코드 검증기(12)가 인스턴스화되었고 동적으로 생성된 코드를 검증하고 있을 것이라는 것을 "인식"하지 못할 수 있다). 대안적으로, 동적 코드 생성기(10)는 동적 코드 검증기(12)를 인식할 수 있고 동적 코드 검증기(12)와 협력할 수 있다(예를 들어, 실행의 개시는 동적 코드가 동적 코드 버퍼(14)에서 이용가능하다는 것을 동적 코드 검증기(12)에 통신하는 것을 포함할 수 있다). 다른 실시예에서, 동적 코드 검증기(12)는 동적 코드가 생성될 때 동적 코드 생성기(10)와 병렬로 동작할 수 있다.

도 1에 예시된 바와 같이, 동적 코드 검증기(12)는 실행되는 커널 모드(22)에서 실행된다. 커널 모드(22)는 실행되는 사용자 모드(24)와 상이할 수 있다. 사용자 모드(24)는 동적 코드 생성기(10), 동적 코드 실행 영역(16) 및 정적 코드 실행 영역(들)(20)에 대해 유효할 수 있다. 일 실시예에서, 정적 코드 실행 영역(들)(20) 내의 일부 코드는 또한 커널 모드(22)에서 실행될 수 있다. 예를 들어, 사용자 모드(24)는 커널 모드(22)보다 낮은 특권 레벨을 가질 수 있다. 상위 특권 코드는 하위 특권 코드가 액세스할 수 없는(또는 적어도 수정할 수 없는) 제한된 프로세서 자원들에 액세스할 수 있다(그리고 그러한 제한된 자원들을 수정할 수 있다). 상위 특권 코드는 또한 하위 특권 코드에 대한 일부 자원들(예를 들어, 메모리 페이지들)의 할당에 대한 제어를 가질 수 있다.

동적 코드 검증기(12)는 코드에 의해 특정 속성들이 충족됨을 보장하기 위해 동적 코드를 분석하고, 동적 코드로부터의 성공적인 불법 활동 또는 동적 코드를 악용하는 것을 방지하기에 충분하게 동적 코드가 포함된다는 적어도 일부 보장을 제공하고, 동적 코드의 잘못된 동작이 다른 프로그램들 또는 운영 체제 자체에 영향을 미치는 것을 방지하도록 구성될 수 있다. 일 실시예에서, 동적 코드 검증기(12)는 동적 코드 실행 영역(16)으로의 이동을 위해 코드를 검증할 수 있다. 동적 코드 검증기(12)는 동적 코드의 임의의 브랜치들이 동적 코드 실행 영역(16) 내에서만 브랜치 타겟들을 가질 수 있음을 보장하기 위해 동적 코드를 분석할 수 있거나, 또는 타겟이 동적 코드 실행 영역(16) 외부에 있는 경우, 타겟은 복수의 유효 타겟 어드레스들 중 하나이다. 예를 들어, 정적 코드 실행 영역들(20) 중 하나 내의 타겟 어드레스들은 동적 코드에 대한 유효 타겟 어드레스들로서 (예를 들어, 운영 체제에 의해) 미리 정의될 수 있다. 예를 들어, 커널 또는 운영 체제 서비스들에 대한 특정 엔트리 포인트들은 동적 코드에 대해 허용될 수 있고, 따라서 유효 타겟 어드레스들일 수 있다. 다양한 실시예들에서, 임의의 세트의 유효 타겟 어드레스들이 정의될 수 있다. 일 실시예에서, 유효 타겟 어드레스들은 동적 코드의 생성 전에 판독-전용 메모리에 잠금된 유효 타겟 리스트로서 동적 코드 검증기(12)에 공급될 수 있다. 다른 실시예에서, 유효 타겟들은 게이트들(예를 들어, 유효 타겟들의 벡터)로서 특정될 수 있고, 동적 코드 검증기(12)는 동적 코드 실행 영역(16)으로부터의 임의의 브랜치들이 브랜치(예를 들어, 점프)가 이루어지는 인식된 게이트를 로딩하는 시퀀스를 사용하는 것을 보장하도록 구성될 수 있다.

일 실시예에서, 동적 코드 검증기(12)는 동적 코드의 다른 속성들을 검증할 수 있다. 예를 들어, 명령어 세트 아키텍처에 정의된 일부 명령어들은 동적 코드에서 허용되지 않을 수 있다(예를 들어, 프로세서들의 모델 특정 레지스터들 또는 모드 구성 레지스터들, 특권 명령어들 등과 같은 특수 목적 레지스터들에 대한 액세스들). 아래에서 일 실시예에 대해 추가적인 세부사항들이 제공된다.

명령어 세트 아키텍처는 하나 이상의 레지스터 값들(및 가능하게는 또한 브랜치 명령어들로 코딩된 변위들)으로부터 타겟 어드레스를 형성하는 "간접 브랜치들"을 지원할 수 있다. 레지스터 값들이 일반적으로 예측 불가능할 수 있기 때문에(예를 들어, 레지스터 콘텐츠들은 메모리로부터 판독되거나 또는 다른 레지스터 콘텐츠들로부터 ALU(arithmetic/logic) 명령어들을 통해 컴퓨팅될 수 있음), 일 실시예에서 생성된 포인터를 허용가능한 타겟 어드레스들로 제한하기 위해 추가적인 명령어들이 사용될 수 있다. 더 구체적으로, 일 실시예에서, 타겟 어드레스를 형성하기 위해 간접 브랜치에 의해 사용되는 레지스터 또는 레지스터들의 콘텐츠들에 대해 동작하는 하나 이상의 다른 명령어들이 간접 브랜치들에 선행할 수 있다. 이러한 다른 명령어들은 유효 타겟 리스트 내의 유효 타겟 어드레스들 중 하나에 대한 것을 제외하고는 동적 코드 실행 영역(16) 외부의 어드레스들을 생성할 수 없음을 보장하기 위해 레지스터(들)의 콘텐츠를 수정할 수 있다(예를 들어, 타겟 어드레스를 "케이징(caging)"하거나, 또는 타겟 어드레스를 "제약"하거나, 또는 타겟 어드레스를 "한정"함). 하나 이상의 선행 명령어들 및 간접 브랜치 명령어들은 "명령어 패킷" 또는 간단히 "패킷"으로 지칭될 수 있고, 동적 코드 검증기(12)는 동적 코드에서 인스턴스화된 임의의 간접 브랜치 명령어들이 패킷에 포함됨을 검증할 수 있다. 일 실시예에서, 동적 코드 검증기(12)는 추가로, 패킷의 크기에 기초하여 정의되는 경계에 패킷이 정렬됨을 검증할 수 있다. 예를 들어, 일 실시예에서, 명령어들은 크기가 4 바이트일 수 있고, 16 바이트의 패킷 크기에 대해, 패킷에 4개의 명령어들(간접 브랜치 명령어를 포함함)이 있을 수 있다. 그러한 패킷들은 16 바이트 경계로 정렬될 수 있다. 즉, 패킷의 초기 명령어는 패킷의 크기(예를 들어, 16 바이트 패킷에 대해 4 비트)에 기초하여 0으로 설정된 다수의 최하위 비트(LSB)들을 갖는 어드레스에 저장된다. 더 적거나 더 많은 수의 명령어들, 명령어 크기들 및 패킷 크기들을 포함하는 다른 수들의 명령어들, 명령어 크기들 및 패킷 크기들이 다른 실시예들에서 지원될 수 있다.

명령어 패킷 내의 케이징/제약/한정 명령어들은 임의의 형태를 가질 수 있다. 예를 들어, 명령어들은 타겟 어드레스를 패킷 경계에 정렬시키기에 충분한 LSB들이 0인 것을 보장하기 위해 간접 브랜치에 대한 레지스터 콘텐츠를 마스킹할 수 있고, 동적 코드 실행 영역(16)의 크기 위에서 최상위 비트(MSB)들을 0으로 마스킹할 수 있다. 마스킹된 값은 동적 코드 실행 영역(16)의 베이스 어드레스에 추가될 수 있고, 그 결과는 간접 브랜치 명령에 대한 타겟 어드레스 레지스터일 수 있다. 타겟 어드레스를 생성하기 위해 다수의 레지스터들이 함께 추가되거나 변위가 추가될 경우, 이러한 추가들은 초기에 수행될 수 있고, 결과는 전술된 바와 같이 마스킹될 수 있다.

다른 유형들의 브랜치 명령어들이 또한 명령어 패킷들에서 인스턴스화될 수 있다. 예를 들어, (동적 코드 실행 영역(16) 외부에 있을 수 있는 잠재적으로 원거리 타겟 어드레스들을 갖도록 정의되는) 명시적 원거리 호출들 및 점프 명령어들은 명령어 패킷들에서 인스턴스화되도록 요구될 수 있다.

"브랜치 명령어"라는 용어는, 실행될 다음 명령어가 브랜치 명령어의 타겟 어드레스에 있는 명령어가 되게 하는(또는 조건부 브랜치 명령어들의 경우, 되게 할 수 있는) 임의의 유형의 명령어를 지칭할 수 있다는 것이 유의한다． 다른 명령어들(예를 들어, ALU 명령어들 및 로드/저장 명령어들)은, 명령어의 실행 동안 어떤 잘못된 발생으로 인해 명령어에 대해 예외가 시그널링되지 않는 한, 실행될 다음 명령어가 현재 명령어 이후의 다음 순차적인 어드레스에 있는 명령어가 되게 한다. 예외들은 현재 코드 시퀀스가 플러시되게 하고 프로세서는 예외에 대해 정의된 예외 벡터 어드레스로부터 실행된다. 브랜치 명령어들의 예들은 간접 브랜치들, 호출들, 리턴들, 점프들(조건부 또는 비조건부), 조건부 브랜치들, 상대적 브랜치가 변위에 기초하여 생성된 타겟 어드레스들 및 상대적 브랜치가 저장된 어드레스 등을 갖는 것이다.

일 실시예에서, 동적 코드 생성기(10)는 명령어 패킷들의 정렬을 보장하기 위해 동적 코드에 연산 없음 명령어들("nops")을 삽입할 수 있다. nop는, 실행될 때, 코드를 실행하는 프로세서의 상태, 메모리 내의 상태 데이터, 또는 컴퓨터 시스템의 임의의 다른 상태에 영향을 미치지 않는 명령어일 수 있다.

더 구체적으로, 일 실시예에서, 명령어 패킷들은 다음의 속성들을 보장할 수 있다:

명시적인 원거리 점프들 및 호출들의 경우, 타겟 어드레스는 유효 타겟 리스트(또는 인식된 게이트) 상에서 발견되거나 또는 타겟은 동적 코드 실행 영역(16) 내에 있다.

레지스터-기반 간접 브랜치들(예를 들어, 점프들, 호출들 및 리턴들)의 경우, 타겟 어드레스는 동적 코드 실행 영역(16)에 한정되고, 명령어 패킷의 크기에 의해 정의된 경계에 정렬된다. 명령어 패킷들이 또한 동일한 경계에 정렬되기 때문에, 이 규칙은 하나의 동적으로 생성된 간접 브랜치가 다른 간접 브랜치에 대한 케이징 명령어들을 우회하지 않을 수 있음을 보장한다.

간접 브랜치들에 대한 상기 제약들로 인해, 동적 코드 실행 영역(16)으로부터의 엑시트(exit)들은 유효 타겟 리스트 내의 타겟들로 제한될 수 있다. 정적 코드는 동적 코드로 점프(또는 호출 명령어 대신에 함수 또는 다른 코드 시퀀스의 끝에서 점프를 사용하는 "테일 호출")할 수 있지만, 동적 코드로부터 호출 정적 코드로의 리턴은, 정적 명령어들이 인스턴스화되어 호출 정적 코드로의 리턴을 완료하는 유효 타겟 리스트 내의 타겟 어드레스로의 리턴이 이루어지는 "트램폴린" 메커니즘을 사용할 수 있다. 따라서, "트램폴린"은, 제어된 포인트를 통한 호출/리턴 코드 사이의 전환들을 허용하여, 호출/리턴 코드가 호출되는/리턴되는 코드에 대한 임의적인 액세스를 갖는 것을 방지하기 위해 호출/리턴 코드(동적 코드 또는 정적 코드)와 호출되는/리턴되는 코드(정적 코드 또는 동적 코드) 사이의 중간 코드 시퀀스일 수 있다. 즉, 일반적으로, 동적 코드로의 호출 또는 리턴을 제어하기 위해 정적 코드에 트램폴린이 있을 수 있어서, 요구될 수 있는 정적 코드에 대한 임의의 제한들을 강제할 수 있다(예를 들어, 정적 코드가 브랜치에 대한 명령어 패킷의 시작을 포함하는 적절한 포인트에 동적 코드에 진입하는 것을 보장함). 정적 코드로의 리턴 또는 호출을 제어하기 위해 동적 코드에 트램폴린들이 있을 수 있어서, 요구될 수 있는 동적 코드에 대한 임의의 제한들을 강제할 수 있다(예를 들어, 정적 코드에 대한 적절한 엔트리 포인트를 보장함).

일 실시예에서, 동적 코드 검증기(12)는 명령어 기반으로 동적 코드를 검증할 수 있다. 동적 코드 검증기(12)는 예를 들어, 명령어들이 잘 형성되고 유효한 인코딩들을 갖는다는 것을 검증할 수 있다. 동적 코드 검증기(12)는 브랜치들이 하나 이상의 유효 명령어 패킷 유형들의 일부임을 검증할 수 있다. 명시적인 타겟 어드레스들을 갖는 브랜치들의 경우, 타겟 어드레스들은 동적 코드 실행 영역(16) 내에 또는 유효 타겟 리스트 상에 있는 것으로 검증된다. 다른 간접 브랜치들은 동적 코드 실행 레지스터(16)에 한정된 그들의 타겟 레지스터의 콘텐츠를 갖는 것으로 검증된다.

일 실시예에서, 동적 코드 검증기(12)는 다음의 명령어들을 허용하지 않을 수 있다(명령어들은 이러한 예에 대해 ARM 명령어 세트 아키텍처로부터 유래하지만, 다양한 실시예들에서 임의의 다른 명령어 세트 아키텍처가 사용될 수 있음): 브랜치-관련 포인터 인증 명령어들, 시스템 호출들(SVC)과 관련된 명령어들, 시스템 레지스터들로/로부터의 대부분의 이동, nop를 제외한 힌트 명령어들, dc를 제외한 캐시 제어 명령어들, 및 불법적 명령어 인코딩들. 동적 코드 검증기(12)는 부적절한 명령어 시퀀스(예를 들어, 동적 코드를 포함하는 프로세스를 종료하는 것 또는 프로세스를 "크래싱(crashing)"하는 것)가 발견되면 명령어 시퀀스를 거부할 수 있다. 더 일반적으로, 허용불가능한 명령어들은 동적 코드 실행 영역(16)으로부터 직접적으로 또는 간접적으로 안전하지 않은 어드레스로 점프하거나 또는 운영 체제 호출을 통해 프로그램을 손상시키는 데 사용될 수 있는 임의의 명령어들을 포함할 수 있다.

본 실시예가 위에서 논의된 바와 같이 명령어 패킷들을 사용하지만, 다른 실시예들은 다른 방식들로 브랜치 타겟 제약들을 구현할 수 있다. 예를 들어, 모든 상대적 브랜치들이 명령어 패킷 경계들에 정렬된 타겟 어드레스들을 가짐을 보장하기보다는, 일 실시예는 동적 코드 내의 명령어 패킷들의 위치를 추적할 수 있고, 타겟이 명령어 패킷에 있지 않으면 비-경계 정렬된 타겟에 대한 상대적 브랜치가 허용될 수 있다. 비-경계 정렬된 타겟에 있는 코드가 동적 코드 검증기(12)에 의해 아직 직면되지 않았다면, 동적 코드 검증기(12)는 비-경계 정렬된 타겟을 또한 추적하고, 비-경계 정렬된 타겟이 명령어 패킷 내에 있는 경우(또는 동적 코드에서 전혀 발견되지 않는 경우, 이는 또한 부정 행위 또는 단순히 에러일 수 있음) 동적 코드를 거부할 수 있다.

다른 실시예는 명령어 패킷들보다는 또는 그에 추가하여 포인터 인증 브랜치들("PAC 브랜치들")을 이용할 수 있다. PAC 브랜치들은, 예를 들어, 운영 체제가 유효 타겟 어드레스들에 서명하기 위해 사용하는 운영 체제에 의해 공급되는 특정 다양화기(diversifier) 또는 키를 사용하도록 보장되는 경우, 허용가능할 수 있다. 이러한 실시예에서, 동적 코드 검증기(12)는 동적 코드가 포인터를 서명하기 위해 특정 다양화기/키를 사용하지 않음을 추가로 보장할 수 있다. 대안적으로, 하나 초과의 특정 다양화기/키가 사용될 수 있고, 특정 다양화기들/키들 중 하나는 브랜치 타겟 인증에 사용될 수 있고, 포인터들에 서명하기 위해 동적 코드에 의해 사용되지 않을 수 있지만, 다른 포인터들에 서명 및 인증하기 위해 동적 코드에 의해 특정 다양화기들/키들 중 다른 것들이 사용될 수 있다. 특정 다양화기/키가 사용되는 것을 보장하기 위한 다양한 메커니즘들이 있을 수 있다. 예를 들어, 레지스터는 예비될 수 있고(동적 코드 내의 명령어들의 목적지가 되도록 허용되지 않음), 특정 다양화기/키는 예비된 레지스터에 저장될 수 있다. 동적 코드 검증기(12)는 예비된 레지스터가 동적 코드 내의 명령어들의 목적지가 아니며 예비된 레지스터가 포인터 인증에 사용됨을 검증할 수 있다.

일 실시예에서, 격리 영역들(18A-18B)이 제공될 수 있다. 격리 영역들(18A-18B)은 액세스불가능할 수 있다(예를 들어, 격리 영역에 대해 판독, 기록 및 실행 허가들이 오프될 수 있음). 따라서, 동적 코드로부터 격리 영역들(18A-18B)에 액세스하려는 임의의 시도는 동적 코드에서 예외를 야기할 수 있다. 운영 체제는, 예를 들어 그러한 예외가 발생하면, 동적 코드를 포함하는 프로세스를 종료할 수 있다. 실시예에서, 격리 영역들(18A-18B)은 상대적 브랜치가 명령어 세트 아키텍처에서 가질 수 있는 최대 변위에 기초하여 크기설정될 수 있다. 즉, 격리 영역들(18A-18B)은 적어도, 동적 코드 영역(16) 내의 임의의 포인트에서 상대적 브랜치 명령어에 의해 생성될 수 있는 임의의 브랜치 타겟 어드레스를 포함하기에 충분히 클 수 있다. 주어진 명령어 세트 아키텍처는 상대적 브랜치 명령어 내에서 변위의 다수의 비트들을 지원하며, 따라서, 비트들의 수로부터 가장 큰 변위가 결정된다. 따라서, 동적 코드 실행 영역(16) 내의 가장 작은 수치 어드레스에 배치되고 가장 큰 네거티브 변위로 코딩된 상대적 브랜치 명령어는 격리 영역들(18A-18B)(예를 들어, 격리 영역(18B)) 내에 어드레스를 생성할 것이다. 유사하게, 동적 코드 실행 영역(16) 내의 가장 큰 수치 어드레스에 배치되고 가장 큰 포지티브 변위로 코딩된 상대적 브랜치 명령어는 격리 영역들(18A-18B)(예를 들어, 격리 영역(18A)) 내에 어드레스를 생성할 것이다. 격리 영역들(18A-18B)의 사용으로, 상대적 브랜치 명령어들은 동적 코드 검증기(12)에 의해 그들의 타겟 어드레스들을 검증할 필요없이 허용될 수 있다. 정확하게 코딩된 상대적 브랜치 명령어들은 동적 코드 실행 영역(16) 내의 타겟 어드레스를 가질 것이고, 부정확하게 코딩된 상대적 브랜치 명령어들은 예외를 야기할 것이다. 다른 실시예들은 상대적 브랜치 명령어들의 타겟 어드레스들을 검증할 수 있고, 격리 영역들(18A-18B)은 필요하지 않을 수 있거나, 또는 다른 고려사항들에 기초하여 크기설정될 수 있다.

일 실시예에서, 동적 코드 검증기(12)에 의해 실행에 허용가능한 것으로 검증된 동적 코드는 동적 코드 실행 영역(16)으로 이동될 수 있다(또는 각각의 명령어는 검증될 때 이동될 수 있다). 다양한 실시예들에서, 동적 코드 검증기(12)가 이동을 수행할 수 있거나, 또는 다른 코드 또는 하드웨어가 이동을 수행할 수 있다. 다른 실시예들에서, 동적 코드 검증기(12)는 동적 코드 버퍼(14) 내의 제자리에서 동적 코드를 검증할 수 있고, 동적 코드는 동적 코드 버퍼(14)로부터 실행될 수 있다. 즉, 동적 코드 버퍼(14)는 또한 동적 코드 실행 영역(16)일 수 있다. 그러한 실시예에서, 동적 코드 버퍼(14)는 격리 영역들(18A-18B)에 의해 둘러싸일 수 있다. 추가적으로, 이러한 실시예들에서, 동적 코드 검증기(12) 또는 운영 체제는 동적 코드 버퍼(14)에 대한 판독/기록 독점 속성을 보장할 수 있다. 즉, 동적 코드 버퍼(14)는 기록가능하지만 실행가능하지 않을 수 있거나, 또는 실행가능하지만 기록가능하지 않을 수 있지만, 동시에 기록가능 및 실행가능 둘 모두는 아닐 수 있다.

위에서 언급된 바와 같이, 동적 코드 검증기(12)는 운영 체제의 일부(예를 들어, 커널의 일부)일 수 있고, 따라서 동적 코드 생성기(10)와 같은 사용자 코드보다 높은 특권 레벨에서 실행될 수 있다. 예를 들어, 커널 기반 구현에서, 동적 코드 생성기(10)는 동적 코드 버퍼(14)의 코드가 실행을 위해 동적 코드 실행 영역(16)에 설치되도록 요청하기 위해 시스템 호출을 수행할 수 있다. 커널이 동적 코드 검증기(12)보다 높은 특권 레벨에서 실행되기 때문에, 커널은 기록 허가와 함께 동적 코드 실행 영역(16)으로의 변환을 자신에게 제공할 수 있다. 동적 코드 생성기(10) 및 다른 사용자 코드에 액세스가능한 더 낮은 특권의 변환은 기록 허가가 아닌 실행 허가(그리고 아마도 판독 허가)를 가질 수 있다.

예시된 실시예가 하나의 동적 코드 버퍼(14) 및 하나의 동적 코드 실행 영역(16)을 도시하지만, 다른 실시예들에서 다수의 동적 코드 버퍼들(14) 및/또는 동적 코드 실행 영역들(16)이 있을 수 있다.

도 2는 동적 코드 검증기(12)의 일 실시예의 동작을 예시하는 고레벨 흐름도이다. 블록들이 특정 순서로 도시되어 있지만, 다른 순서들이 사용될 수 있다. 동적 코드 검증기(12)는 컴퓨터 시스템의 프로세서 상에서 실행될 때, 컴퓨터 시스템으로 하여금 도 2에 도시된 동작들을 수행하게 하는 복수의 명령어들을 포함할 수 있다.

동적 코드 검증기(12)는 본 명세서에 설명된 다양한 규칙들 및 제약들("요건들" 또는 "기준")을 적용하여 동적 코드 버퍼(14)에서 동적으로 생성된 코드를 분석할 수 있다(블록(30)). 동적으로 생성된 코드가 기준들을 충족하면(결정 블록(32), "예" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드의 실행을 허용할 수 있다(예를 들어, 동적 코드 실행 영역(16)에 코드를 복사함 - 블록(34)). 동적으로 생성된 코드가 기준들 중 하나 이상을 위반하면(결정 블록(32), "아니오" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드를 거부할 수 있다(블록(36)). 동적으로 생성된 코드를 거부하는 것은 다양한 방식들로 구현될 수 있다. 예를 들어, 동적으로 생성된 코드를 포함하는 프로세스가 종료될 수 있다. 다른 실시예들에서, 동적 코드 생성기(10)는 동적으로 생성된 코드가 검증에 실패했음을 통지받을 수 있다. 다양한 실시예들에서, 실패에 대한 이유가 제공될 수 있거나, 또는 보안을 보호하기 위한 어떠한 이유도 제공되지 않을 수 있다.

도 3은 도 2에 도시된 흐름도의 일부의 일 실시예를 더 상세히 예시하는 흐름도이다. 더 구체적으로, 동적으로 생성된 코드가 실행을 위한 기준들을 충족시키는지 여부의 결정(결정 블록(32))이 더 상세히 도시된다. 블록들이 특정 순서로 도시되어 있지만, 다른 순서들이 사용될 수 있다. 동적 코드 검증기(12)는 컴퓨터 시스템의 프로세서 상에서 실행될 때, 컴퓨터 시스템으로 하여금 도 3에 도시된 동작들을 수행하게 하는 복수의 명령어들을 포함할 수 있다.

동적 코드 검증기(12)는 주어진 명령어를 분석하고 명령어가 유효 명령어인지 여부를 결정할 수 있다(결정 블록(40)). 예를 들어, 동적 코드 검증기(12)는, 명령어의 오피코드가 명령어 세트 내의 유효한 오피코드인 것, 피연산자들 및 명령어의 다른 코딩이 오피코드와 일치하는 것 등을 검증할 수 있다. 명령어가 유효 명령어가 아니면(결정 블록(40), "아니오" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드를 거부할 수 있다(블록 36). 반면에, 명령어가 유효하다면(결정 블록(40), "예" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드에서 명령어가 허용되는지 여부를 결정할 수 있다(결정 블록(42)). 전술된 바와 같이, 명령어들을 실행하는 것이 동적 코드 실행 영역(16)으로부터의 엑시트로 이어질 수 있는 잠재적 위험 때문에 특정 명령어들은 허용되지 않을 수 있다. 명령어가 유효하지만 허용되지 않으면(결정 블록(42), "아니오" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드를 거부할 수 있다(블록(36)).

명령어가 유효하고 허용되고(결정 블록들(40 및 42), "예" 레그들), 명령어가 브랜치이면(결정 블록(44), "예" 레그), 동적 코드 검증기(12)는, 브랜치가 동적 코드 실행 영역(16)을 빠져나갈 수 없음(cannot exit)을 검증할 수 있거나(결정 블록(46), "예" 레그), 또는 브랜치가 빠져나갈 수 있으면(could exit)(결정 블록(46), "아니오" 레그), 엑시트가 유효 엑시트인 것을 검증할 수 있다(예를 들어, 엑시트는 동적 코드 실행 영역 외부의 허용된 어드레스에 대한 것임 - 결정 블록(48), "예" 레그). 어느 경우이든, 브랜치 명령어는 동적으로 생성된 코드에서 허용될 수 있다. 동적 코드 검증기(12)는 동적으로 생성된 코드 시퀀스에 더 많은 명령어들이 있는지 여부를 결정할 수 있고, 존재한다면(결정 레그(50), "예" 레그), 다음 명령어를 선택하고 분석을 반복할 수 있다. 더 이상 명령어들이 존재하지 않는 경우(결정 블록(50), "아니오" 레그), 동적으로 생성된 코드는 실행이 허용될 수 있다(블록(34)). 반면에, 브랜치 명령어가 빠져나갈 수 있고(결정 블록(46), "아니오" 레그), 엑시트가 유효한 것으로서 검증될 수 없으면(결정 블록(48), "아니오" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드 시퀀스를 거부할 수 있다(블록(36)).

브랜치가 유효 엑시트를 제외하고는 빠져나갈 수 있는지 여부의 결정은, 브랜치 명령어의 유형, 및 일부 유형들의 브랜치 명령어들의 경우, 브랜치의 타겟 어드레스를 동적 코드 실행 영역(16) 또는 유효 엑시트로 제한할 수 있는 다른 명령어들의 존재 둘 모두에 기초할 수 있다. 따라서, 일부 경우들에서, 브랜치 타겟 어드레스는 동적 코드 검증기(12)에 의해 결정가능하지 않을 수 있고, 따라서 브랜치 타겟 어드레스가 실행 동안 동적 코드 실행 영역(16) 내에 실제로 유지되거나 유효한 엑시트를 사용할 수 있더라도 거부될 수 있다. 즉, 브랜치가 동적 코드 실행 영역(16)에 유지되는 것으로 입증될 수 있거나 유효 엑시트일 수 있는 경우가 아니면, 브랜치를 포함하는 동적으로 생성된 코드는 거부될 수 있다.

도 4는 도 3에 도시된 흐름도의 일부의 일 실시예를 더 상세히 예시하는 흐름도이다. 더 구체적으로, (브랜치가 빠져나갈 수 없거나 유효한 엑시트임을 결정하는) 결정 블록들(46 및 48)의 조합이 더 상세히 도시된다. 따라서, 동적 코드 검증기(12)가 명령어가 브랜치임을 결정하면, 도 4의 동작이 수행될 수 있다. 블록들이 특정 순서로 도시되어 있지만, 다른 순서들이 사용될 수 있다. 동적 코드 검증기(12)는 컴퓨터 시스템의 프로세서 상에서 실행될 때, 컴퓨터 시스템으로 하여금 도 4에 도시된 동작들을 수행하게 하는 복수의 명령어들을 포함할 수 있다.

브랜치 명령어들은 일반적으로, 실행될 다음 명령어가 브랜치 명령어 또는 다음 연속적(순차적) 명령어의 타겟 어드레스에서의 명령어가 되게 할 수 있는 명령어들이다. 브랜치 명령어들은 무조건부(여기서, 타겟 어드레스는 항상 실행될 다음 명령어의 어드레스임) 또는 조건부일 수 있다(여기서, 다음 명령어의 어드레스는 프로세서 내의 조건 코드를 통해 또는 직접 통신되는 이전 명령어의 결과에 기초하여 타겟 어드레스 또는 순차적 어드레스일 수 있음). 브랜치 명령어들은 타겟 어드레스를 형성하기 위해 적어도 하나의 레지스터 피연산자가 사용되는 간접 브랜치들, 또는 명령어에 직접 코딩된 즉각적 필드(또는 변위 필드)로부터 타겟 어드레스가 형성되는 직접 브랜치들일 수 있다. 직접 브랜치들은 절대 브랜치들(타겟 어드레스는 변위/즉각적 값임) 또는 상대적 브랜치들(타겟 어드레스는 변위/즉각적 필드 및 브랜치 명령어 자체의 어드레스에 기초하여 결정됨)일 수 있다.

브랜치 명령어가 간접 브랜치이면(결정 블록(60), "예" 레그), 브랜치 명령어는, 타겟 어드레스가 동적 코드 실행 영역(16) 내에 있거나 또는 유효한 엑시트임을 보장하는 명령어 패킷 내에 포함될 것이 요구된다. 간접 브랜치가 동적 코드 실행 영역에 타겟 어드레스를 한정하기 위해 또는 타겟 어드레스가 유효한 엑시트임을 보장하기 위해(결정 블록(62), "예" 레그) 명령어들의 정확한 세트를 갖는 명령어 패킷에 있고, 명령어 패킷이 명령어 패킷의 크기의 배수인 어드레스에 정렬되면(결정 블록(64), "예" 레그), 브랜치는 유효하고 동적 코드 검증기(12)는 다음 명령어를 프로세싱할 수 있다(블록(50)). 그러나, 간접 브랜치가 명령어 패킷에 있지 않거나(결정 블록(62), "아니오" 레그) 명령어 패킷이 정렬되지 않으면(결정 블록(64), "아니오" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드를 거부할 수 있다(블록(36)).

브랜치 명령어가 간접 브랜치가 아니라(결정 블록(60), "아니오" 레그) 직접 브랜치이면(결정 블록(66), "예" 레그), 타겟 어드레스는 명령어 자체(및 잠재적으로 어드레스 명령어 자체의 어드레스)로부터 결정될 수 있다. 그러나, 타겟 어드레스는 명령어 패킷 경계에 정렬되도록 요구될 수 있어서, 직접 브랜치는 명령어 패킷 내의 명령어들 주위에서 간접 브랜치로 분기하는 데 사용되지 않을 수 있고, 따라서 가능하게는 비-유효 타겟으로 동적 코드 실행 영역을 빠져나갈 수 있다. 타겟 어드레스가 정렬되면(결정 블록(68), "예" 레그), 브랜치 명령어가 허용될 수 있고 동적 코드 검증기(12)는 추가적인 명령어를 체크할 수 있다(블록(50)). 타겟 어드레스가 정렬되지 않으면(결정 블록(68), "아니오" 레그), 동적 코드 검증기(12)는 동적으로 생성된 코드를 거부할 수 있다(블록(36)). 추가적으로, 브랜치 명령어가 직접적이지도 간접적이지도 않은 경우(결정 블록들(60 및 66), 레그들 "아니오"), 브랜치 명령어는, 타겟 어드레스가 보장되지 않을 수 있기 때문에 허용되지 않는 유형이다. 직접적이지도 간접적이지도 않은 브랜치 명령어들은, 예를 들어 메모리 위치로부터 타겟 어드레스를 판독하는 리턴 명령어들을 포함할 수 있다.

이제, ARM 64 명령어 세트를 사용하는 더 상세한 예가 제시될 것이며, 동적 코드는 JIT JavaScript 코드이고, 정적 코드는 프리컴파일된 C++ 코드(더 간략하게는 JIT 코드 및 C++ 코드로 지칭됨)이다. 그러나, 다른 실시예들은 ARM 명령어 세트, Intel x86 명령어 세트, Power 명령어 세트, RISC5 명령어 세트 등의 다른 버전들을 포함하는 임의의 명령어 세트를 사용할 수 있다. 예시적인 명령어 시퀀스들이 도시될 때, 명령어 어드레스들(16진수 표기에서, "0x"로 시작함) 및 명령어들은 이들을 텍스트의 나머지로부터 구별하기 위해 Arial Narrow 폰트로 도시된다.

ARM64 상에서, PC 상대적 브랜치에 대한 최대 스트라이드는 28 비트(±128M)이다. 이와 같이, 격리 영역들(18A-18B)의 할당은 크기가 적어도 128M일 수 있다. 일 실시예에서, 타겟 어드레스 한정을 단순화할 뿐만 아니라 어드레스 공간 엔트로피를 최대화하기 위해, 동적 코드 실행 영역(16)의 베이스 어드레스는 동적 코드 실행 영역(16)에 대해 변하는 최소 수의 유효 비트들을 최소로 유지할 수 있다. 일 실시예에서, 레지스터 간접 어드레스 마스킹을 위한 마스킹 시퀀스가 컴퓨팅되어 유효 타겟 리스트에 의해 사용되는 동일한 판독-전용 구성 메모리에 저장될 수 있다.

리터럴 원거리 점프 패킷들

패치가능한 브랜치들을 포함하는 리터럴 어드레스들을 갖는 패킷들은 타겟 어드레스에 의존하여 약간의 변화들로 생성될 수 있다. 타겟 어드레스가 동적 코드 실행 영역(16) 외부에 있으면, 어드레스는 유효 타겟 리스트에 있도록 요구될 수 있다. 동적 코드 실행 영역(16) 내부의 리터럴 어드레스들의 경우, 타겟 어드레스는 패킷 경계(예를 들어, 16 바이트 경계)를 가리키도록 요구될 수 있다. 리터럴 어드레스의 구체화 및 후속 간접 브랜치는 패킷 경계에 정렬된 이러한 명령어들의 제1 어드레스를 갖는 패킷으로서 함께 방출될 수 있다. 일 실시예에서, 매크로 어셈블러는 구체화된 타겟 어드레스가 패킷 경계에 정렬되는 것을 보장할 수 있다.

C++ 코드에 대한 예시적인 호출

0xe567ba160: movz x16, #0x8c48

0xe567ba164: movk x16, #0x152, lsl #16

0xe567ba168: movk x16, #0x1, lsl #32

0xe567ba16c: blr x16

동적 코드 실행 영역 16을 타겟팅하는 예시적인 호출

0xe567b90e0: movz x16, #0x98c0

0xe567b90e4: movk x16, #0x567b, lsl #16

0xe567b90e8: movk x16, #e, lsl #32

0xe567b90ec: blr x16

레지스터 패킷들

레지스터 내의 타겟 어드레스를 갖는 패킷들은 또한 16 바이트 정렬될 수 있다. 타겟 어드레스들은 16 바이트 어드레스들로 정렬되고, 타겟 어드레스는, 동적 코드 실행 영역(16) 모듈로(modulo) 실제 동적 코드 실행 영역 메모리의 양측의 격리 영역들(18A-18B)을 가리키도록 케이징된다. 동일한 시퀀스의 명령어들이 점프, 호출들, 및 리턴들에 대해 사용될 수 있다.

예시적인 호출 패킷

0xe567bb308: ldr x8, [x2], #16

...

0xe567bb320: and x8, x8, #0xffffff0

0xe567bb324: movz x17, #0xe5, lsl #16

0xe567bb328: add x8, x8, x17, lsl #12

0xe567bb32c: blr x8

동적 코드 실행 영역(16)의 베이스 어드레스에 따라, 이동 및 추가 명령어들에 대한 즉각적 값들이 변할 수 있음에 유의한다.

예시적인 리턴 패킷:

0xe567b824c: ldp fp, lr, [sp], #16

...

0xe567b8250: and lr, lr, #0xffffff0

0xe567b8254: movz x17, #0xe5, lsl #16

0xe567b8258: add lr, lr, x17, lsl #12

0xe567b825c: ret

타겟 어드레스가 정적 코드 실행 영역(20)에 있을 때, 타겟 기능을 테일 호출하기 위해, 트램폴린이 자동으로 생성될 수 있다. 이러한 트램폴린들은 리터럴 패킷들의 형태일 수 있다.

PAC 서명된 리터럴 패킷들

일 실시예에서, PAC 브랜치들은 동적 코드에서 허용되지 않을 수 있다. 그러나, 다른 실시예들은, 타겟 어드레스들이 유효 타겟 리스트에 있거나 또는 16-바이트 정렬되어 동적 코드 실행 영역(16)에 있음을 검증하는 것과 함께, 확장 PAC 브랜치 패킷과의 이들의 사용을 허용할 수 있다. 리터럴 어드레스를 사용하여 서명된 간접 점프 또는 호출을 행하기 위한 아래의 예시적인 명령어 시퀀스는 6개의 명령어들: 즉, 64 비트 부호있는 포인터를 구체화하기 위한 4, 태그 또는 다양화기를 lr(이 시점에서 임시 레지스터)로 구체화하기 위한 1, 및 이어서 인증 및 브랜치 명령어를 포함한다. 이 시퀀스에 2개의 브랜치들을 추가하는 것은 이 시퀀스가 16 바이트 경계 상에 정렬될 수 있게 하며, 패킷으로의 가능한 엔트리는 안전하다. 아래는 추가된 PC 상대적 브랜치들을 갖는 8개의 명령어 패킷의 예이다.

0xe567bea60: movz lr, #0xb38a

0xe567bea64: movz x16, #0x985c

0xe567bea68: movk x16, #0x5a1, lsl #16

0xe567bea6c: b 0xe567bea74

0xe567bea70: b 0xe567bea60

0xe567bea74: movk x16, #0xf501, lsl #32

0xe567bea78: movk x16, #0xd840, lsl #48

0xe567bea7c: blrab x16, lr

C++와 JIT 코드 사이의 트램폴린들

동적 코드 실행 영역(16)에 케이징된 리턴 어드레스로 인해 JIT 코드가 C++ 코드로 직접 리턴하도록 허용되지 않기 때문에, C++ 코드로부터의 이러한 호출들에 대해 다른 기술이 사용될 수 있다. 또한, 동적 코드 실행 영역(16) 또는 정적 코드 실행 영역(20)에 있을 수 있는 함수에 대한 가상 호출이 이루어질 수 있는 경우들이 있다. 이러한 경우들에 대해, 다양한 트램폴린들이 사용될 수 있다. 이들 중 일부는, 정적 코드 실행 영역(20) 및 동적 코드 실행 영역(16) 둘 모두에서 밀접하게 결합된 컴포넌트들을 가질 수 있다. C++ 코드로부터의 호출들에 대해 사용되는 트램폴린들은 유효 타겟 나열된 점프 어드레스를 통해 정적 코드 실행 영역(20)으로의 리턴으로 동적 코드 실행 영역(16)에서 호출할 수 있다.

직접 C++ 코드 대 JIT 코드 트램폴린

C++ 코드로부터 JIT 코드로의 주요 엔트리를 고려한다. 이러한 엔트리 포인트는 vmEntryToJavascript로 지칭되며, C++ 측의 인라인 트램폴린 및 JIT 컴포넌트를 포함한다:

C++ 영역 JIT 영역

JavaScriptCore`vmEntryToJavaScript: VMEntryToJS에 대한 JIT 코드

트램폴린:

이 트램폴린이 작동하는 방식은 리턴 위치, vmEntryReturn이 유효 타겟 리스트에 배치되는 것이다. 레지스터 x0에서 타겟 JIT 엔트리 포인트를 예상하여 JIT 측 코드가 생성된다. JIT 코드는 x0을 동적 코드 실행 영역(16)에 한정하고, 이어서 호출을 행한다. 그 호출로부터 리턴할 시에, 트램폴린의 JIT 측은 유효 타겟 나열된 vmEntryReturn 라벨로 원거리 점프한다. 결과적인 JIT 코드의 시작 어드레스는 판독 전용으로서 락 다운된 변수에 저장된다. 그 변수의 콘텐츠는 C++ 측에서 타겟으로서 사용된다. JIT 트램폴린들에 대한 이러한 유형들의 C++ 호출들의 많은 다른 인스턴스들이 있으며, 여기서 C++는 동적 코드 실행 영역(16) 내의 트램폴린에 대한 함수 포인터를 통해 호출한다. 트램폴린은 JIT 코드를 호출하고, 이어서 유효 타겟에 대한 직접 브랜치를 사용하여 호출 C++ 코드로 다시 리턴한다. 사용자 코드가 JIT 컴파일 및 실행되기 전에, JIT 시스템이 초기화되고 있을 때, 이러한 트램폴린들이 생성된다.

호출가능한 C++ 대 JIT 트램폴린

일 실시예에서, 이전 섹션에서 설명된 트램폴린들이 충분할 수 있다. 원하는 대로, 추가적인 트램폴린들이 구현될 수 있다.

JIT 대 C++ 테일 호출 트램폴린

C++ 함수에 대한 가상 호출이 행해질 때, 그 C++ 함수에 대한 유효한 타겟 나열된 엔트리 포인트를 이용하여 트램폴린을 생성할 필요가 있다. 이어서, 임의의 다른 JIT 함수 포인터와 유사한 그 트램폴린을 사용한다. 트램폴린은 C++ 함수에 대해 테일 호출한다.

호스트 기능 트램폴린 떵크(Thunk):

0xe99e3cb50: movz x16, #0x56ec

0xe99e3cb54: movk x16, #0x1aa, lsl #16

0xe99e3cb58: movk x16, #0x1, lsl #32

0xe99e3cb5c: br x16

링킹 및 JIT 복사

JIT 코드가 동적 코드 버퍼(14)로부터 동적 코드 실행 영역(16)으로 복사되고 링크될 때, 코드는, 명령어들이 안전한지를 체크하는 동적 코드 검증기(12)를 통과한다. 동적 코드 검증기(12)는 각각의 명령어가 복사될 때 이를 체크하여, 그 각각의 명령어가 유효한지 그리고 적절한 경우 패킷의 유효 위치에 있는지를 확인한다. 어떠한 검증 실패들 없이 명령어들이 복사되는 경우, 코드는 VM에 의한 사용을 위해 이용가능하게 된다. 임의의 검증 실패들이 존재했다면, 동적 코드 검증기는 프로세스를 즉시 종료(충돌)시킬 수 있다.

동적 코드 검증기 명령어 검증기

이 실시예에서, 동적 코드 검증기(12)의 명령어 검증기는 ARM64 디스어셈블러의 리팩토링 시에 구축된다. 새로운 isvalid() 방법이 디스어셈블러의 각각의 명령어 그룹에 추가되었다. 대부분의 명령어 그룹들은 정의되지 않은 명령어 패턴들을 체크하는 간단한 검증을 수행한다. 다른 명령어 그룹들은 그 그룹 내의 다양한 허용되지 않는 명령어들을 체크한다. 브랜치 명령어들은 더 많은 수반되는 체크들을 갖는다. 아래는 명령어 검증기의 일 실시예에 의해 이루어진 상세한 체크들의 예들이다.

무효 명령어 인코딩들을 허용하지 않는다.

svc, hvc, smc, hlt, 또는 dpcs 명령어들 중 임의의 것을 허용하지 않는다.

인증된 브랜치 명령어들(braa, brab, blraa, blrab, blraaz, blrabz, braaz, brabz, eretaa, eretab, retaa, retab)을 허용하지 않는다.

사용자 모드 상태 플래그들을 판독하는 명령어들을 제외하고 mrs, msr을 허용하지 않는다.

bl 및 blr 명령어들이 0xc로 끝나는 어드레스들에 있는지를 체크한다.

간접 브랜치들의 경우, 3개의 선행 명령어들이 동일한 타겟 레지스터를 갖는 일련의 무브 와이드 명령어들인지를 체크한다. 만약 그렇다면, 그 무브 와이드 시퀀스에 의해 구체화된 어드레스가 유효 타겟 리스트 상에, JIT 영역의 16 바이트 정렬된 타겟에 대해, 또는 어드레스 0에 대해 있는지를 보기 위해 체크한다. 그들이 실제로 사용되기 전에 0으로의 브랜치들이 패치된다. 3개의 선행 명령어들이 동일한 타겟 레지스터에 대한 일련의 무브 와이드 명령어들이 아니면, 3개의 선행 명령어들이 유효한 JIT 케이징 시퀀스를 구성하는지를 체크한다.

일 실시예에서, 시스템은 JIT 코드를 패치하는 능력을 허용하여, 패치될 의도로 방출하는 0 명령어들로의 브랜치와 같은 브랜치 타겟들을 매우 자주 대체한다. 동적 코드 검증기(16)는 호출될 때마다, 이전의 16 바이트 정렬된 경계로부터 다음의 16 바이트 정렬된 경계까지 검증한다. 0을 레지스터로 구체화한 후 그 레지스터를 통한 브랜치가 뒤따르는 무브 와이드 시퀀스가 있는 경우, 무브 와이드 시퀀스를 검증할 때, 조합된 브랜치 패킷이 패킷 규칙들을 준수한다는 것을 검증하기 위해 기존의 브랜치를 포함시킬 것이다.

유효 타겟 리스트 구성

소스 주석들은 정적으로-컴파일된 C++ 코드에서 유효 타겟들을 추출하는 데 사용될 수 있다. 소스 주석들은, 함수의 어드레스를 취하고 그 어드레스를 오브젝트 파일의 판독-전용 공간에 저장하는 컴파일러 지시자들일 수 있다. 유효 타겟 리스트를 실제로 생성하는 코드는, 그 판독-전용 공간으로부터 어드레스들을 판독하고, 이를 프로세스의 나머지 수명 동안 판독-전용이 되게 함으로써 락 다운될 수 있는 정적으로 크기설정된 해시 테이블에 넣는다. 해시 테이블은, "이것이 JIT 코드가 호출하기에 유효한 타겟인가?"라는 질문에 대답할 필요가 있다.

함수 foo()에 대한 소스 주석은 다음과 같이 보일 수 있다:

오리지널 코드 유효 타겟 주석들

VALID_JIT_TARGET 주석은 컴파일러에 대한 다음의 추가적인 소스를 효과적으로 생성한다:

void* _JITTarget_void

__attribute__((used, section("__DATA_CONST,__jit_targets"))) =

reinterpret_cast<void*>(foo);

일 실시예에서, 유효 타겟 리스트 생성은, 주석이 달린 함수 포인터들을 집계하고, 이어서 완벽한 해싱을 사용하여 판독 전용 해시 테이블을 생성할 컴파일러 툴링을 포함할 수 있다. 이는 정적으로 생성된 C++ 코드를 생성할 때 사용되는 프로세스와 유사할 수 있다.

잠금가능한 구성 데이터

이 예의 몇몇 위치들에서, 다양한 데이터가 판독-전용 영역에 놓인다. 이 소프트웨어 검증 JIT 노력보다 약간 더 긴 이 능력을 가졌다. 유효 타겟 리스트, 트램폴린 어드레스들, JIT 영역 세부사항들 및 레지스터 케이징 시퀀스를 포함하는, 이 특징의 많은 부분들에 대해 그 메모리 영역을 사용한다. 이 영역은 프로세스 초기화 동안 이용가능하다. JavaScript 가상 머신이 이용가능하기 전에, 그리고 그에 따라, 사용자 제공 JavaScript 코드로부터 유도된 JIT 코드가 실행되기 전에. JIT 엔진이 초기화된 후에, 전체 구성 영역을 판독-전용으로 만든다. OS는 프로세스의 나머지 수명 동안 영역을 다시 판독-기록으로 되돌리기 위한 메커니즘을 제공하지 않는다.

컴퓨터 시스템

이제 도 5를 참조하면, 일부 실시예들에 따른, 컴퓨팅 디바이스(컴퓨팅 시스템 또는 컴퓨터 시스템으로 또한 지칭될 수 있음)의 블록도가 도시된다. 컴퓨팅 디바이스(1510)는 본 개시내용의 다양한 부분들을 구현하는 데 사용될 수 있다. 컴퓨팅 디바이스(1510)는 모바일 디바이스, 서버 컴퓨팅 시스템, 클라이언트 컴퓨팅 시스템, 또는 본 개시내용의 부분들을 구현하는 임의의 다른 컴퓨팅 시스템으로서 사용될 수 있는 디바이스의 일 예이다.

컴퓨팅 디바이스(1510)는 개인용 컴퓨터 시스템, 데스크톱 컴퓨터, 랩톱 또는 노트북 컴퓨터, 모바일 폰, 메인프레임 컴퓨터 시스템, 웹 서버, 워크스테이션 또는 네트워크 컴퓨터를 포함하지만 이에 제한되지 않는 임의의 적합한 유형의 디바이스일 수 있다. 도시된 바와 같이, 컴퓨팅 디바이스(1510)는 상호연결부(1560)(예를 들어, 시스템 버스)를 통해 결합된 프로세싱 유닛(1550), 저장 서브시스템(1512) 및 입력/출력(I/O) 인터페이스(1530)를 포함한다. I/O 인터페이스(1530)는 하나 이상의 I/O 디바이스들(1540)에 결합될 수 있다. 컴퓨팅 디바이스(1510)는 예를 들어, 다른 컴퓨팅 디바이스들과의 통신들을 위해 네트워크(1520)에 결합될 수 있는 네트워크 인터페이스(1532)를 더 포함한다.

프로세싱 유닛(1550)은 하나 이상의 프로세서들을 포함한다. 일부 실시예들에서, 프로세싱 유닛(1550)은 하나 이상의 코프로세서 유닛들을 포함한다. 일부 실시예들에서, 프로세싱 유닛(1550)의 다수의 인스턴스들이 상호연결부(1560)에 결합될 수 있다. 프로세싱 유닛(1550)(또는 프로세싱 유닛(1550) 내의 각각의 프로세서)은 캐시 또는 다른 형태의 온-보드 메모리를 포함할 수 있다. 일부 실시예들에서, 프로세싱 유닛(1550)은 범용 프로세싱 유닛으로서 구현될 수 있고, 다른 실시예들에서는 특수 목적 프로세싱 유닛(예를 들어, ASIC)으로서 구현될 수 있다. 일반적으로, 컴퓨팅 디바이스(1510)는 임의의 특정 유형의 프로세싱 유닛 또는 프로세서 서브시스템으로 제한되지 않는다.

저장 서브시스템(1512)은 (예를 들어, 프로세싱 유닛(1550)에 의해 실행가능한 명령어들 및 그에 의해 사용되는 데이터를 저장하기 위해) 프로세싱 유닛(1550)에 의해 사용가능하다. 저장 서브시스템(1512)은 하드 디스크 저장소, 플로피 디스크 저장소, 착탈식 디스크 저장소, 플래시 메모리, 랜덤 액세스 메모리(RAM - SRAM, EDO RAM, SDRAM, DDR SDRAM, RDRAM 등), ROM(PROM, EEPROM 등) 등을 포함하는 임의의 적합한 유형의 물리적 메모리 매체들에 의해 구현될 수 있다. 저장 서브시스템(1512)은 일부 실시예들에서 휘발성 메모리로만 구성될 수 있다. 저장 서브시스템(1512)은 컴퓨팅 디바이스(1510)로 하여금 본 명세서에 개시된 다양한 기술들을 구현하게 하도록 실행가능한 프로그램 명령어들을 포함하여, 프로세싱 유닛(1550)을 사용하여 컴퓨팅 디바이스(1510)에 의해 실행가능한 프로그램 명령어들을 저장할 수 있다. 저장 서브시스템(1512)은 예를 들어, 전술된 시스템 메모리를 포함할 수 있다. 적어도 일부 실시예들에서, 저장 서브시스템(1512)은 실행가능한 명령어들을 저장할 수 있는 비일시적 컴퓨터 판독가능 매체의 예를 표현할 수 있다.

예시된 실시예에서, 컴퓨팅 디바이스(1510)는 저장 서브시스템(1512)과의 가능하게는 별개의 엘리먼트로서 비일시적 매체(1514)를 더 포함한다. 예를 들어, 비일시적 매체(1514)는 디스크, 비휘발성 메모리, 테이프, 광학 매체들, 홀로그래픽 매체들 또는 다른 적합한 유형들의 저장소와 같은 영구적인 유형적 저장소를 포함할 수 있다. 저장 서브시스템(1512)과 별개인 것으로 도시되지만, 일부 실시예들에서, 비일시적 매체(1514)는 저장 서브시스템(1512) 내에 통합될 수 있다. 비일시적 매체(1514)는 또한, 실행될 때, 컴퓨팅 디바이스(1510)로 하여금 본 명세서에 설명된 바와 같은 동작들을 수행하게 하는 명령어들을 저장할 수 있는 매체의 예일 수 있다.

I/O 인터페이스(1530)는 하나 이상의 인터페이스들을 표현할 수 있고, 다양한 실시예들에 따라 다른 디바이스들에 결합하고 그와 통신하도록 구성된 다양한 유형들의 인터페이스들 중 임의의 것일 수 있다. 일부 실시예들에서, I/O 인터페이스(1530)는 프론트-사이드로부터 하나 이상의 백-사이드 버스들로의 브리지 칩이다. I/O 인터페이스(1530)는 하나 이상의 대응하는 버스들 또는 다른 인터페이스들을 통해 하나 이상의 I/O 디바이스들(1540)에 결합될 수 있다. I/O 디바이스들의 예들은 저장 디바이스들(하드 디스크, 광학 드라이브, 착탈식 플래시 드라이브, 저장 어레이, SAN 또는 연관된 제어기), 네트워크 인터페이스 디바이스들, 사용자 인터페이스 디바이스들 또는 다른 디바이스들(예를 들어, 그래픽들, 사운드 등)을 포함한다.

본 개시내용에 따르면, 방법이 개시된다. 방법은, 사용자 실행 모드와 상이한 커널 실행 모드에서 실행되는 커널에서, 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 요청을 수신하는 단계; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들을 충족함을 검증하는 단계 - 하나 이상의 기준들은 동적으로 생성된 코드에서 허용되지 않는 명령어들의 서브세트의 부재를 포함함 -; 및 성공적인 검증에 기초하여, 커널 모드에서 실행되는 커널에 의해, 동적으로 생성된 코드 시퀀스를 동적 코드 실행 영역으로 이동시키는 단계를 포함할 수 있다. 하나 이상의 기준들은 또한, 동적으로 생성된 코드 시퀀스가 하나 이상의 미리 정의된 어드레스들을 제외하고는 동적 코드 실행 영역을 빠져나갈 수 없음을 보장할 수 있다. 일 실시예에서, 동적으로 생성된 코드 시퀀스가 빠져나갈 수 없음을 보장하는 것은, 동적으로 생성된 코드 시퀀스의 브랜치 명령어들이 동적 코드 실행 영역 내의 타겟 어드레스들을 갖는 것 또는 타겟 어드레스들이 미리 정의된 어드레스들 중 하나임을 보장하는 것을 포함할 수 있다. 일 실시예에서, 동적으로 생성된 코드 시퀀스의 제1 브랜치 명령어는, 제1 브랜치 명령어의 제1 타겟 어드레스를 동적 코드 실행 영역으로 제한하는 하나 이상의 선행 명령어들과 함께 명령어 패킷에 포함될 수 있다. 일 실시예에서, 명령어 패킷은 명령어 패킷의 크기에 기초하는 경계에 정렬될 수 있다. 일 실시예에서, 하나 이상의 기준들은 명령어 패킷 내에 있는 브랜치 타겟 어드레스들의 부재를 더 포함할 수 있다. 일 실시예에서, 방법은, 커널 모드에서 실행되는 커널에서, 제2 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 다른 요청을 수신하는 단계; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 제2 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들 중 적어도 하나를 충족하지 않는다고 결정하는 단계; 및 제2 동적으로 생성된 코드가 적어도 하나 이상의 기준들을 충족하지 않는다고 결정하는 것에 기초하여, 동적 코드 실행 영역으로의 제2 동적으로 생성된 코드 시퀀스의 이동을 방지하는 단계를 더 포함할 수 있다. 일 실시예에서, 방법은, 커널 모드에서 실행되는 커널에서, 제2 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 다른 요청을 수신하는 단계; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 제2 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들 중 적어도 하나를 충족하지 않는다고 결정하는 단계; 및 제2 동적으로 생성된 코드가 적어도 하나 이상의 기준들을 충족하지 않는다고 결정하는 것에 기초하여, 제2 동적으로 생성된 코드 시퀀스를 거부하는 단계를 더 포함한다. 일 실시예에서, 방법은 성공적이지 않은 검증에 기초하여, 동적으로 생성된 코드 시퀀스를 동적 코드 실행 영역으로 이동시키기 위한 요청을 송신한 프로세스를 종료하는 단계를 더 포함한다.

일 실시예에서, 비일시적 컴퓨터 액세스가능 저장 매체는 복수의 명령어들을 저장할 수 있고, 명령어들은, 컴퓨터 시스템 상에서 실행될 때, 사용자 실행 모드와 상이한 커널 실행 모드에서 실행되는 커널에서, 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 요청을 수신하는 것; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들을 충족함을 검증하는 것 - 하나 이상의 기준들은 동적으로 생성된 코드에서 허용되지 않는 명령어들의 서브세트의 부재를 포함함 -; 및 성공적인 검증에 기초하여, 커널 모드에서 실행되는 커널에 의해, 동적으로 생성된 코드 시퀀스를 동적 코드 실행 영역으로 이동시키는 것을 포함하는 동작들을 구현한다. 일 실시예에서, 하나 이상의 기준들은 또한, 동적으로 생성된 코드 시퀀스가 하나 이상의 미리 정의된 어드레스들을 제외하고는 동적 코드 실행 영역을 빠져나갈 수 없음을 보장할 수 있다. 일 실시예에서, 동적으로 생성된 코드 시퀀스가 빠져나갈 수 없음을 보장하는 것은, 동적으로 생성된 코드 시퀀스의 브랜치 명령어들이 동적 코드 실행 영역 내의 타겟 어드레스들을 갖는 것 또는 타겟 어드레스들이 미리 정의된 어드레스들 중 하나임을 보장하는 것을 포함할 수 있다. 일 실시예에서, 동적으로 생성된 코드 시퀀스의 제1 브랜치 명령어는, 제1 브랜치 명령어의 제1 타겟 어드레스를 동적 코드 실행 영역으로 제한하는 하나 이상의 선행 명령어들과 함께 명령어 패킷에 포함될 수 있다. 일 실시예에서, 명령어 패킷은 명령어 패킷의 크기에 기초하는 경계에 정렬될 수 있다. 일 실시예에서, 하나 이상의 기준들은 명령어 패킷 내에 있는 브랜치 타겟 어드레스들의 부재를 더 포함할 수 있다. 일 실시예에서, 동작들은, 커널 모드에서 실행되는 커널에서, 제2 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 다른 요청을 수신하는 것; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 제2 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들 중 적어도 하나를 충족하지 않는다고 결정하는 것; 및 제2 동적으로 생성된 코드가 적어도 하나 이상의 기준들을 충족하지 않는다고 결정하는 것에 기초하여, 동적 코드 실행 영역으로의 제2 동적으로 생성된 코드 시퀀스의 이동을 방지하는 것을 더 포함할 수 있다. 일 실시예에서, 동작들은, 커널 모드에서 실행되는 커널에서, 제2 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 다른 요청을 수신하는 것; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 제2 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들 중 적어도 하나를 충족하지 않는다고 결정하는 것; 및 제2 동적으로 생성된 코드가 적어도 하나 이상의 기준들을 충족하지 않는다고 결정하는 것에 기초하여, 제2 동적으로 생성된 코드 시퀀스를 거부하는 것을 더 포함할 수 있다. 일 실시예에서, 동작들은 성공적이지 않은 검증에 기초하여, 동적으로 생성된 코드 시퀀스를 동적 코드 실행 영역으로 이동시키기 위한 요청을 송신한 프로세스를 종료하는 것을 더 포함할 수 있다.

일 실시예에서, 컴퓨터 시스템은 하나 이상의 프로세서들; 및 복수의 명령어들을 저장하는 비일시적 컴퓨터 액세스가능 저장 매체를 포함할 수 있고, 명령어들은, 컴퓨터 시스템 상에서 실행될 때, 사용자 실행 모드와 상이한 커널 실행 모드에서 실행되는 커널에서, 동적으로 생성된 코드 시퀀스를 메모리 내의 버퍼로부터 메모리 내의 동적 코드 실행 영역으로 이동시키기 위한 요청을 수신하는 것; 커널 모드에서 실행되는 커널에서, 메모리에 저장된 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서의 실행을 위한 하나 이상의 기준들을 충족함을 검증하는 것 - 하나 이상의 기준들은 동적으로 생성된 코드에서 허용되지 않는 명령어들의 서브세트의 부재를 포함함 -; 및 성공적인 검증에 기초하여, 커널 모드에서 실행되는 커널에 의해, 동적으로 생성된 코드 시퀀스를 동적 코드 실행 영역으로 이동시키는 것을 포함하는 동작들을 구현한다. 일 실시예에서, 하나 이상의 기준들은 또한, 동적으로 생성된 코드 시퀀스가 하나 이상의 미리 정의된 어드레스들을 제외하고 동적 코드 실행 영역 외부의 타겟 어드레스들을 갖는 브랜치 명령어들을 배제하는 것을 보장할 수 있다.

하드웨어 실시예들

다른 실시예들에서, 동적으로 생성된 코드에 대한 실행 기준들의 시행은 하드웨어로(예를 들어, 동적으로 생성된 코드를 실행하는 하나 이상의 프로세서들 상에서) 구현될 수 있다. 동적 코드 검증기(12) 대신에, 커널 모드(22)가 동적 코드 실행 영역(16)에 동적으로 생성된 코드를 설치하는 코드를 포함할 수 있다는 점을 제외하고, 도 1에 관한 위의 설명이 여전히 일반적으로 적용될 수 있다. 프로세서들은 동적 코드 실행 영역(16)을 식별하도록 프로그래밍될 수 있고, 따라서 동적 코드 실행 영역(16) 내에서 실행이 발생한다고 결정함으로써 동적으로 생성된 코드에 대한 실행 기준들을 시행할 수 있다. 일부 경우들에서, 실행 기준들은 또한, 아래에서 더 상세히 설명되는 바와 같이 상이할 수 있다.

이제 도 6을 참조하면, 프로세싱 유닛(1550)의 일 실시예의 블록도가 더 상세히 도시된다. 예시된 실시예에서, 프로세싱 유닛(1550)은 적어도 하나의 프로세서(160)를 포함한다. 프로세서(160)는 하나 이상의 구성 레지스터들(162), 모니터 회로(164) 및 실행 코어 회로(또는 더 간략하게, "실행 코어")(166)를 포함할 수 있다. 구성 레지스터들(162)은 메모리 내에 동적 코드 실행 영역(16)을 정의하도록 프로그래밍가능할 수 있다. 이전에 논의된 바와 같이, 동적으로 생성된 코드는 사용 동안 동적 코드 실행 영역(16)에서 실행된다. 모니터 회로(164)는 실행 코어(166)에 추가로 결합된다. 일부 실시예들에서, 하나 초과의 프로세서(160)가 포함될 수 있다(예를 들어, 제2 프로세서(160)가 도 6에 도시됨).

모니터 회로(164)는 동적으로 생성된 코드 시퀀스가 하나 이상의 실행 기준들을 충족하는 것을 보장하기 위해 프로세서(160)에서 실행되고 있는 동적으로 생성된 코드 시퀀스를 모니터링하도록 구성될 수 있다. 예를 들어, 모니터 회로(164)는, 실행 코어(166)에 의해 실행되고 있는 명령어들에 관한 다양한 데이터, 이를테면, 명령어가 메모리에 저장되고 그로부터 명령어가 페칭된 프로그램 카운터 어드레스(PC), 명령어 자체(또는, 명령어로부터 디코딩된 다양한 신호들, 이를테면 브랜치인지 여부, 브랜치의 유형, 동적으로 실행되는 코드에서 허용되지 않는 명령어인지 여부 등) 및 브랜치 명령어들에 대한 타겟 어드레스(TA)를 수신할 수 있다. 모니터 회로(164)는 하나 이상의 실행 기준들의 위반을 검출하는 것에 기초하여 프로세서에서 예외를 야기하도록 구성될 수 있다(예를 들어, 모니터 회로(164)는 실행 코어(166)에 대한 명령어에 대한 예외 신호를 어서트할 수 있음). 예외는 프로세서(160)로 하여금 동적으로 생성된 코드 시퀀스의 실행을 중단하게 할 수 있고, 그에 따라, 실행 기준들을 위반하는 코드의 실행을 방지할 수 있다. 따라서, 동적으로 실행되는 코드의 실행을 허용하기 전에 이를 체크하기보다는, 실행 기준들이 충족되지 않으면, 하드웨어 실시예는 실행을 허용하고 실행을 종료할 수 있다. 간접 브랜치들의 타겟 어드레스들을 한정하는 데 사용되는 명령어 패킷들은 이 실시예에서 이용되지 않을 수 있는데, 이는 타겟 어드레스가 동적 코드 실행 영역(16)을 빠져나가는지 여부, 그리고 만약 그렇다면, 엑시트가 허용된 타겟에 대한 것인지 여부를 모니터 회로가 검출할 수 있기 때문이다.

전술한 바와 같이, 실행 기준들은 동적으로 생성된 코드 시퀀스에서 허용되지 않는 명령어들의 서브세트의 부재를 포함할 수 있다. 허용되지 않는 명령어들의 동일한 서브세트가 위의 소프트웨어 실시예들에 대해 정의된 바와 같이 이 실시예에 대해 정의될 수 있다. 예를 들어, 하기 명령어들은 동적으로 생성된 코드 시퀀스들에서 허용되지 않을 수 있다(명령어들은 이러한 예에 대해 ARM 명령어 세트 아키텍처로부터 유래하지만, 다양한 실시예들에서 임의의 다른 명령어 세트 아키텍처가 사용될 수 있음): 미인증 간접 브랜치 명령어들, 시스템 호출들(SVC)과 관련된 명령어들, 시스템 레지스터들로/로부터의 대부분의 이동, nop를 제외한 힌트 명령어들, dc를 제외한 캐시 제어 명령어들, 및 불법적 명령어 인코딩들. 더 일반적으로, 허용불가능한 명령어들은 동적 코드 실행 영역(16)으로부터 직접적으로 또는 간접적으로 안전하지 않은 어드레스로 점프하거나 또는 운영 체제 호출을 통해 프로그램을 손상시키는 데 사용될 수 있는 임의의 명령어들을 포함할 수 있다.

추가적으로, 프로세서(160)는 동적으로 생성된 코드 시퀀스에 의한 사용을 위한 암호화 키들("키들")의 추가적인 세트를 지원할 수 있다. 키들의 오리지널 세트("표준 키들")는, 동적 코드 실행 영역(16)으로부터 분기하기 위해 동적으로 생성된 코드에 의해 사용될 포인터들을 포함하는 포인터들을 서명하기 위해 정적 코드에 의해 사용될 수 있다. 따라서, 동적으로 생성된 코드 시퀀스 외부의 코드는 표준 키들로 포인터들을 서명하고, 서명된 포인터들을 사용을 위해 동적으로 생성된 코드 시퀀스에 제공하여, 동적 코드 실행 영역(16)으로부터의 엑시트 포인트들을 제어할 수 있다. 추가적인 키들("동적 코드 키들")은 동적 코드 실행 영역(16) 내의 타겟 어드레스들에 대한 포인터들을 서명하기 위해 동적으로 생성된 코드에 의해 사용될 수 있지만, 동적 코드 키들이 동적 코드 실행 영역 외부의 어드레스들에 대한 포인터들을 서명하는 데 사용된다면, 포인터들을 사용하려는 시도가 이루어질 때 포인터들은 인증을 실패할 것이다. 따라서, 동적으로 생성된 코드는, 동적 코드 실행 영역(16) 외부의 위치들에 대한 포인터들이 외부 코드에 의해 서명되고 동적으로 생성된 코드에 제공된 경우에만 이들을 사용할 수 있다. 동적으로 생성된 코드와 외부 코드 사이의 키들의 분리는 예를 들어, 동적으로 생성된 코드와 외부 코드 사이에서 공통 스택의 안전한 공유를 허용할 수 있다. 일 실시예에서, 동적으로 생성된 코드의 암호화 서명/인증 명령어들은 표준 키들을 특정하지 못할 수 있다(예를 들어, 이러한 명령어들은 프로세서(160)에 의해 nop들로서 취급될 수 있거나 또는 결함을 야기할 수 있음). 따라서, 표준 키들은 동적으로 생성된 코드에 액세스가능하지 않을 수 있다. 또한, 일 실시예에서, 다수의 표준 키들이 존재할 수 있다. 이러한 실시예에서, 표준 키들 중 하나는 동적으로 생성된 코드 및 외부 코드 둘 모두에 대해 이용가능하게 될 수 있는 한편, 표준 키들 중 다른 하나는 외부 코드로만 제한될 수 있다. 일 실시예에서, 하나는 서명 및 인증 명령어들을 위한 것이고 다른 하나는 인증 브랜치/리턴 명령어들을 위한 것인 별개의 프로그래밍가능 제어들이 있을 수 있다. 서명 명령어가 실행되고 대응하는 제어가 서명 동작을 허용하지 않으면, 프로세서(160)는 명령어를 "nop"(예를 들어, 서명 동작을 실행하지 않음)할 수 있다. 따라서, 후속 인증 명령어(또는 포인터를 사용하는 인증된 브랜치 명령어)는 인증에 실패할 수 있다. 특정 구현에서, 서명/인증하는 능력은 동적 실행 영역 외부에 있는 포인터들에 서명/인증하기 위해 그리고 동적 실행 영역 내부에 있는 포인터들에 서명/인증하기 위해 별개로 제어될 수 있다.

일 실시예에서, 프로세서(160)는 또한, 외부 코드에 의해 실행되는 포인터 서명 명령어들이 동적 코드 키들로 서명되도록 강제되는 "강제 서명"을 지원할 수 있어서, 이들은 동적 코드 실행 영역(16) 내에서 정확하게 인증될 것이다.

구성 레지스터들(162)은 동적 코드 실행 영역(16)(예를 들어, 베이스 어드레스 및 범위, 베이스 어드레스 및 종료 어드레스 등)을 정의할 수 있다. 추가적으로, 구성 레지스터들(162)은 프로세서에서의 동적 코드 실행을 위해 다양한 다른 프로그래밍가능한 속성들을 선택하도록 프로그래밍될 수 있다. 예를 들어, 일 실시예에서, 구성 레지스터들(162)은 동적 코드 실행 영역(16) 외부의 하나 이상의 어드레스 범위들로 프로그래밍가능할 수 있다. 동적으로 생성된 코드는 표준 키들을 이용하여 어드레스 범위들의 포인터들을 서명하도록 허용될 수 있다. 이는, 동적으로 생성된 코드가 표준 키들로 포인터들을 서명하도록 허용되지 않는다는 위에서 언급된 일반적인 규칙에 대한 예외일 수 있다.

일 실시예에서, 모니터 회로는 동적 코드 실행 영역(16) 내의 타겟들로의 직접 브랜치들을 허용할 수 있지만, 직접 브랜치들이 동적 코드 실행 영역(16) 외부의 타겟들을 가지면 예외를 강제할 수 있다. 다른 실시예에서, 격리 영역들(18A-18B)이 정의될 수 있고, 동적 코드 실행 영역(16) 외부의 직접 브랜치의 최대 범위를 커버할 수 있다. 격리 영역들(18A-18B)은 액세스불가능(판독, 기록 또는 실행 허가 없음)으로서 마킹될 수 있고, 이들 타겟들로의 직접 브랜치들은 승인 실패들로 인해 실행 코어(166)에서 예외를 경험할 수 있다. 또 다른 실시예에서, 모니터 회로(164)는 격리 영역들(18A-18B)에서 타겟을 검출하고 예외를 강제할 수 있다.

명확성을 위해 모니터 회로(164)가 도 6에서 실행 코어(166)와 별개로 도시되지만, 모니터 회로(164)는 실제로 실행 코어(166)에 통합될 수 있으며, 회로부는 모니터 체크들이 이루어지는 다양한 파이프라인 스테이지들에 걸쳐 분산된다. 추가적으로, 실행 코어(166)의 다양한 실시예들은 다수의 명령어들을 병렬로 실행하기 위해 수퍼스칼라(superscalar) 설계들 등을 이용할 수 있다. 따라서, 모니터 회로(164)는 상이한 파이프라인들 내의 다수의 명령어들을 동시에 모니터링하도록 구성될 수 있고, 상이한 파이프라인 스테이지들에서의 명령어들을 또한 동시에 모니터링할 수 있다.

다양한 실시예들에서, 실행 코어(166)는 임의의 구성 및 마이크로아키텍처 특징들을 가질 수 있다. 예를 들어, 실행 코어(166)는 수퍼스칼라 또는 스칼라 구현들을 포함할 수 있다. 실행 코어(166)는 순차 및 비-순차 구현들, 및 추론적 또는 비-추론적 구현들을 포함할 수 있다. 실행 코어(166)는 위의 특징들의 임의의 조합을 포함할 수 있다. 일부 실시예들에서 구현들은 마이크로코드를 포함할 수 있다. 실행 코어(166)는 다양한 실행 유닛들을 포함할 수 있으며, 각각의 실행 유닛은 다양한 유형들(예컨대, 정수, 부동 소수점, 벡터, 로드/저장 등)의 동작들을 실행하도록 구성된다. 실행 코어(166)는 상이한 수의 파이프라인 스테이지들 및 분기 예측과 같은 다양한 기타 성능-향상 특징들을 포함할 수 있다. 실행 코어(166)는 하나 이상의 명령어 디코딩 유닛들, 스케줄러들 또는 예약 스테이션들, 재주문 버퍼들, 메모리 관리 유닛들, I/O 인터페이스들 등을 포함할 수 있다.

전술된 바와 같이, 프로세서(160)와 같은 하나 이상의 프로세서들을 포함하는 프로세싱 유닛(1500)은 컴퓨팅 디바이스(1510)와 같은 컴퓨터 시스템에 배치될 수 있다. 컴퓨터 시스템은 메모리 시스템(예를 들어, 저장소(1512) 및/또는 매체(1514)의 일부)을 포함할 수 있다. 동적 코드 실행 영역(16)은 메모리 시스템 내의 어드레스 범위에서 정의될 수 있고, 동적으로 생성된 코드는 사용 동안에 동적 코드 실행 영역에서 실행된다. 적어도 하나의 프로세서(160)는 메모리 시스템에 결합될 수 있고, 프로세서는, 동적으로 생성된 코드 시퀀스가 하나 이상의 실행 기준들을 충족하는 것을 보장하기 위해 컴퓨터 시스템에서 실행되고 있는 동적으로 생성된 코드 시퀀스를 모니터링하도록 구성되는 모니터 회로를 포함하고, 하나 이상의 실행 기준들은 동적으로 생성된 코드 시퀀스에서 허용되지 않는 명령어들의 서브세트의 부재를 포함하고, 동적으로 생성된 코드 시퀀스는 동적 코드 실행 영역에 저장되고, 프로세서는 하나 이상의 실행 기준들의 위반의 검출에 기초하여 예외를 야기하도록 구성된다. 일 실시예에서, 하나 이상의 실행 기준들은 동적 코드 실행 영역 외부에 있는 브랜치 타겟이 하나 이상의 암호화 키들의 세트 중 하나를 이용하여 암호화 방식으로 서명된다는 요건을 포함한다. 일 실시예에서, 하나 이상의 암호화 키들의 세트는 동적으로 생성된 코드 시퀀스에 액세스가능하지 않다. 일 실시예에서, 하나 이상의 암호화 키들의 제2 세트는, 하나 이상의 타겟 어드레스들을 외부 소스로부터 동적으로 생성된 코드 시퀀스에 암호화 방식으로 서명하기 위해 동적으로 생성된 코드 시퀀스를 위해 제공된다. 일 실시예에서, 하나 이상의 실행 기준들은 브랜치 타겟이 동적 코드 실행 영역 외부의 하나 이상의 미리 정의된 어드레스 범위들 중 하나 내에 있다는 요건을 포함한다. 일 실시예에서, 프로세서는 동적 코드 실행 영역에 대응하는 어드레스 범위에 인접한 한 쌍의 어드레스 범위들 내에서 액세스하려는 시도를 검출하고, 예외를 취함으로써 액세스를 방지하도록 구성되고, 한 쌍의 어드레스 범위들 중 주어진 어드레스 범위의 크기는 동적 코드 실행 영역 내에서 직접 브랜치 명령어로 도달가능한 범위에 기초한다. 일 실시예에서, 서명/인증 명령어들 및 인증 브랜치/리턴 명령어들을 위한 별개의 프로그래밍가능 제어들이 있을 수 있다. 별개의 제어들은, 동적으로 생성된 코드 시퀀스들을 실행하는 동안 포인터 어드레스들에 서명하는 능력을, 예를 들어, 동적으로 생성된 코드 시퀀스들에 다른 코드에 의해 제공된 적절히 "미리 서명된" 어드레스들을 인증 및 분기하기 위한 동적으로 생성된 코드 시퀀스들의 능력으로부터 분리하는 능력을 제공할 수 있다. 특정 구현에서, 서명/인증하는 능력은 동적 실행 영역 외부에 있는 포인터들에 서명/인증하기 위해 그리고 동적 실행 영역 내부에 있는 포인터들에 서명/인증하기 위해 별개로 제어될 수 있다.

도 7은 도 6에 도시된 프로세싱 유닛(1550)/프로세서(160)의 실시예의 동작을 예시하는 흐름도이다. 블록들이 이해의 용이함을 위해 특정 순서로 도시되었지만, 다른 순서들도 사용될 수 있다. 블록들은 프로세서(160), 더 구체적으로는 모니터 회로(164) 내의 조합 로직에서 병렬로 수행될 수 있다. 블록들, 블록들의 조합들 및/또는 흐름도는 전체적으로 하나 이상의 클록 사이클들에 걸쳐 파이프라인화될 수 있다. 프로세서(160), 더 구체적으로는 모니터 회로(164)는 도 7에 도시된 그 동작을 구현하도록 구성될 수 있다.

모니터 회로(164)는, 동적으로 생성된 코드 시퀀스가 하나 이상의 실행 기준들을 충족하는 것을 보장하기 위해 동적으로 생성된 코드 시퀀스가 컴퓨터 시스템에서 실행되고 있을 때를 결정하기 위해 PC와 같은 명령어 정보를 사용하여, 실행되고 있는 명령어들을 분석하도록 구성될 수 있다. 모니터 회로(60)는 명령어 정보를 분석할 수 있고(블록(70)), 명령어들이 동적 코드 실행 영역(16)으로부터 페칭되는지 여부를 검출할 수 있다(결정 블록(72)). 명령어들이 동적 코드 실행 영역(16)으로부터의 것이 아니라면(결정 블록(72), "아니오" 레그), 명령어들은 프로세서(160)에 의해 구현된 명령어 세트 아키텍처에 따라 정상적으로 실행될 수 있다(블록(74)). 정상 실행은 동적으로 생성된 코드에 대한 실행 기준들의 시행과 관련되지 않은 다양한 예외들(예를 들어, 실패한 변환들에 대해, 명령어 세트 아키텍처에 정의된 예외들, 사용자 모드(24)와 같은 비특권 모드들에서 특권 명령어들을 실행하려는 시도들 등)을 검출하고 취하는 것을 포함할 수 있다. 명령어들이 동적 코어 실행 영역(16)으로부터의 것이면(결정 블록(72), "예" 레그), 모니터 회로(164)는 명령어들이 하나 이상의 실행 기준들을 충족시키는지 여부를 결정할 수 있다(결정 블록(76)). 명령어들이 실행 기준들을 충족하면(결정 블록(76), "예" 레그), 명령어들은 정상적으로(예를 들어, 이전에 언급된 바와 같이 가능하게는 동적 코드 실행을 위해 수정된 프로세서(160)에 의해 구현된 명령어 세트 아키텍처에서 정의된 바와 같이) 계속해서 정상적으로 실행될 수 있다(블록(78)). 모니터 회로(164)가 하나 이상의 실행 기준들의 위반을 검출하면(결정 블록(76), "아니오" 레그), 모니터 회로(164)는 예외를 강제하도록 구성될 수 있다(블록(80)). 즉, 모니터 회로(164)는 프로세서(160)(예를 들어, 실행 코어(166))로 하여금, 실행 기준들을 위반하는 명령어에 대해 예외를 취하게 할 수 있다. 일부 경우들에서, 모니터 회로(164)는 예외를 강제하기보다는 명령어의 실행을 수정하도록 구성될 수 있다(블록(80)). 예를 들어, 동적으로 생성된 코드가 특정 포인터들(예를 들어, 동적 코드 실행 영역(16) 외부의 포인터)에 서명하도록 허용되지 않으면, 모니터 회로(164)는 서명 명령어의 "nop"을 강제하도록 구성될 수 있다.

도 7(및 아래에서 설명되는 도 8)의 동작은, 프로세서(160)에 의해 병렬로(예를 들어, 수퍼스칼라 방식으로 및/또는 파이프라인 방식으로) 프로세싱되는 하나 이상의 명령어들에 대해 병렬로 수행될 수 있다는 것에 유의한다.

도 8은 도 7에 도시된 흐름도의 일부의 일 실시예를 더 상세히 예시하는 흐름도이다. 더 구체적으로, (동적 코드 실행 영역(16)으로부터 페칭된) 동적 코드 시퀀스 내의 명령어들이 실행 기준들을 충족하는지 여부의 결정이 더 상세히 도시된다(결정 블록(76)). 블록들이 이해의 용이함을 위해 특정 순서로 도시되었지만, 다른 순서들도 사용될 수 있다. 블록들은 프로세서(160), 더 구체적으로는 모니터 회로(54) 내의 조합 로직에서 병렬로 수행될 수 있다. 블록들, 블록들의 조합들 및/또는 흐름도는 전체적으로 하나 이상의 클록 사이클들에 걸쳐 파이프라인화될 수 있다. 프로세서(160), 더 구체적으로는 모니터 회로(164)는 도 8에 도시된 그 동작을 구현하도록 구성될 수 있다.

모니터 회로(70)는 명령어가 유효한 명령어인지 여부(예를 들어, 명령어가 유효 오피코드를 갖는지, 피연산자들이 명령어에 대해 정확한지 등)를 결정할 수 있다(결정 블록(90)). 명령어가 무효이면, 프로세서는 예외를 취할 수 있다(블록(80)). 일 실시예에서, 무효 명령어의 검출은 (예를 들어, 명령어를 디코딩하는 것의 일부로서) 실행 코어(166) 자체에 의해 수행될 수 있다. 다른 실시예들에서, 모니터 회로(164)는 무효 명령어를 검출할 수 있거나, 또는 실행 코어(166)로부터 무효 명령어의 표시를 수신할 수 있다. 명령어가 유효하다면, 모니터 회로(164)는 명령어가 허용되는지 여부를 결정할 수 있다(결정 블록(92)). 즉, 하나 이상의 실행 기준들 중 하나는 동적으로 생성된 코드 시퀀스에서 허용되지 않는 명령어들의 서브세트의 부재를 포함할 수 있고, 명령어가 서브세트에 있으면, 허용되지 않는다. 명령어가 허용되지 않으면(결정 블록(92), "아니오"), 모니터 회로(164)는 예외를 강제할 수 있다(블록(80)).

명령어가 허용되고 브랜치 명령어(결정 블록(92)의 "예" 레그 및 결정 블록(94)의 "예" 레그)인 경우, 모니터 회로(164)는, 브랜치 명령어가 동적 코드 실행 영역(16)을 빠져나가려고 시도하는지 여부를 결정할 수 있다(결정 블록(96)). 즉, 브랜치 명령어가 동적 코드 실행 영역(16) 외부에 있는 브랜치 타겟 어드레스를 갖는 경우, 브랜치 명령어는 동적 코드 실행 영역(16)을 빠져나가려고 시도할 수 있고, 모니터 회로는 브랜치 타겟 어드레스가 표준 키들 중 하나로 암호화 방식으로 서명되는지 여부(결정 블록(98))를 결정할 수 있다. 그렇지 않으면(결정 블록(98), "아니오" 레그), 브랜치는 동적으로 생성된 코드에 대한 실행 기준들을 위반하고, 모니터 회로는 예외를 강제하도록 구성될 수 있다(블록(80)). 브랜치 타겟 어드레스가 표준 키들 중 하나로 서명되면(결정 블록(98), "예" 레그), 명령어가 실행될 수 있다(블록(78)). 전술된 바와 같이, 일 실시예에서, 표준 키들은 동적으로 생성된 코드 시퀀스에 액세스가능하지 않을 수 있다. 동적으로 생성된 코드 시퀀스는 암호화 서명 목적들을 위해(예를 들어, 외부 소스로부터 동적으로 생성된 코드 시퀀스에 하나 이상의 타겟 어드레스들을 암호화 방식으로 서명하기 위해) 하나 이상의 동적 코드 키들을 가질 수 있다. 다른 실시예에서, 브랜치 타겟 어드레스는 브랜치 타겟 어드레스의 요건이 동적 코드 실행 영역 외부의 하나 이상의 미리 정의된 어드레스 범위들 중 하나 내에 있으면 유효하고 실행 기준들을 위반하지 않을 수 있다. 어드레스 범위들은 예를 들어 구성 레지스터들(162)에 프로그래밍될 수 있다. 명령어가 동적 코드 실행 영역(16)을 빠져나가지 않는 브랜치 명령어이거나(결정 블록(94), "예" 레그 및 결정 블록(96), "아니오" 레그), 또는 명령어가 브랜치가 아닌 경우(결정 블록(94), " 아니오" 레그), 명령어는 계속해서 정상적으로 실행될 수 있다.

일 실시예에서, 모니터 회로(164)(또는 허가 체크들을 통한 실행 코어(166))는 직접 브랜치가 격리 영역들(18A 또는 18B) 내에 브랜치 타겟 어드레스를 갖는지를 검출할 수 있다. 직접 브랜치가 동적 코드 실행 영역(16)(즉, 격리 영역들(18A-18B))에 인접한 한 쌍의 어드레스 범위들 중 하나에서 이러한 타겟 어드레스를 가지면, 영역들은 상대적 브랜치 명령어들이 동적 코드 실행 영역을 빠져나가는 것을 방지하기 위해 액세스불가능할 수 있다. 한 쌍의 어드레스 범위들 중 주어진 어드레스 범위의 크기는 동적 코드 실행 영역 내에서 주어진 직접 브랜치 명령어로 도달가능한 범위에 기초한다.

추가적인 시스템 실시예들

다음으로 도 9를 참조하면, 시스템(700)의 일 실시예의 블록도가 도시된다. 예시된 실시예에서, 시스템(700)은 컴퓨팅 디바이스(1510)의 적어도 하나의 인스턴스를 포함한다. 예시된 바와 같이, 시스템(700)은 넓은 범위의 영역들의 애플리케이션을 갖는 것으로 도시되어 있다. 예를 들어, 시스템(700)은 데스크톱 컴퓨터(710), 랩톱 컴퓨터(720), 태블릿 컴퓨터(730), 셀룰러 또는 모바일 폰(740), 또는 텔레비전(750)(또는 텔레비전에 결합된 셋톱 박스)의 칩들, 회로부, 컴포넌트들 등의 부분으로서 이용될 수 있다. 스마트워치 및 건강 모니터링 디바이스(760)가 또한 예시된다. 일부 실시예들에서, 스마트워치는 다양한 범용 컴퓨팅 관련 기능들을 포함할 수 있다. 예를 들어, 스마트워치는 이메일, 셀폰 서비스, 사용자 캘린더 등에 대한 액세스를 제공할 수 있다. 다양한 실시예들에서, 건강 모니터링 디바이스는 전용 의료 디바이스일 수 있거나, 또는 그렇지 않으면 전용 건강 관련 기능을 포함할 수 있다. 예를 들어, 건강 모니터링 디바이스는 사용자의 바이탈 사인(vital sign)들을 모니터링하고, 역학적인 사회적 거리두기의 목적을 위해 다른 사용자들에 대한 사용자의 근접도를 추적하고, 접촉을 추적하고, 건강 위험의 경우 응급 서비스에 통신을 제공하는 등일 수 있다. 다양한 실시예들에서, 위에서 언급된 스마트워치는 일부 또는 임의의 건강 모니터링 관련 기능들을 포함할 수 있거나 포함하지 않을 수 있다. 목부 주위에 착용된 디바이스들, 인체에서 이식가능한 디바이스들, 증강 및/또는 가상 현실 경험을 제공하도록 설계된 안경 등과 같은 다른 웨어러블 디바이스들이 또한 고려된다.

시스템(700)은 클라우드 기반 서비스(들)(770)의 일부로서 추가로 사용될 수 있다. 예를 들어, 이전에 언급된 디바이스들, 및/또는 다른 디바이스들은 클라우드 내의 컴퓨팅 리소스들(즉, 원격으로 위치된 하드웨어 및/또는 소프트웨어 리소스들)에 액세스할 수 있다. 더 추가적으로, 시스템(700)은 이전에 언급된 것들 이외의 홈(home)의 하나 이상의 디바이스들에서 이용될 수 있다. 예를 들어, 홈 내의 기기들은 주의를 요하는 조건들을 모니터링하고 검출할 수 있다. 예를 들어, 홈 내의 다양한 디바이스들(예를 들어, 냉장고, 냉각 시스템 등)은 디바이스의 상태를 모니터링하고, 특정 이벤트가 검출되면 경보를 집주인(또는 예를 들어, 수리 설비)에게 제공할 수 있다. 대안적으로, 서모스탯(thermostat)은 홈 내의 온도를 모니터링할 수 있고, 집주인에 의한 다양한 조건들에 대한 응답들의 이력에 기초하여 가열/냉각 시스템에 대한 조정들을 자동화할 수 있다. 또한, 다양한 운송 모드들에 대한 시스템(700)의 적용이 도 9에 예시되어 있다. 예를 들어, 시스템(700)은 항공기, 기차들, 버스들, 임대용 자동차들, 개인용 자동차들, 개인용 보트들로부터 유람선(cruise liner)들까지의 수상 선박들, (대여 또는 소유를 위한) 스쿠터들 등의 제어 및/또는 엔터테인먼트 시스템들에서 사용될 수 있다. 다양한 경우들에서, 시스템(700)은 자동화된 안내(예를 들어, 자율-주행 차량들), 일반적인 시스템 제어 등을 제공하기 위해 사용될 수 있다. 이들 임의의 많은 다른 실시예들이 가능하고 고려된다. 도 9에 예시된 디바이스들 및 애플리케이션들이 단지 예시적인 것이며 제한하려는 의도가 아니라는 것을 유의한다. 다른 디바이스들이 가능하고 고려된다.

컴퓨터 액세스가능 저장 매체

이제 도 10을 참조하면, 컴퓨터 액세스가능 저장 매체(800)의 일 실시예의 블록도가 도시된다. 일반적으로 말하면, 컴퓨터 액세스가능 저장 매체는 명령어들 및/또는 데이터를 컴퓨터에 제공하기 위하여 사용 동안 컴퓨터에 의해 액세스가능한 임의의 저장 매체를 포함할 수 있다. 예를 들어, 컴퓨터 액세스가능 저장 매체는, 자기 또는 광학 매체, 예를 들어, 디스크(고정식 또는 착탈식), 테이프, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, 또는 블루레이(Blu-Ray)와 같은 저장 매체들을 포함할 수 있다. 저장 매체들은, RAM(예를 들어, 동기식 동적 RAM(SDRAM), 램버스 DRAM(RDRAM), 정적 RAM(SRAM) 등), ROM, 또는 플래시 메모리와 같은 휘발성 또는 비휘발성 메모리 매체들을 더 포함할 수 있다. 저장 매체들은 저장 매체들이 명령어들/데이터를 제공하는 컴퓨터 내에 물리적으로 포함될 수 있다. 대안적으로, 저장 매체들은 컴퓨터에 연결될 수 있다. 예를 들어, 저장 매체들은 네트워크 부착형 저장소와 같이, 네트워크 또는 무선 링크를 통해 컴퓨터에 연결될 수 있다. 저장 매체들은 USB(Universal Serial Bus)와 같은 주변기기 인터페이스를 통해 연결될 수 있다. 일반적으로, 컴퓨터 액세스가능 저장 매체(800)는 비일시적 방식으로 데이터를 저장할 수 있고, 이러한 맥락에서 비일시적은 신호 상에서 명령어들/데이터를 송신하지 않는 것을 지칭할 수 있다. 예를 들어, 비일시적 저장소는 휘발성(그리고 전력 차단에 응답하여 저장된 명령어들/데이터를 상실할 수 있음) 또는 비휘발성일 수 있다.

도 10의 컴퓨터 액세스가능 저장 매체(800)는 동적 코드 생성기(10), 동적 코드 검증기(12) 및/또는 정적 코드(802) 중 하나 이상을 저장할 수 있으며, 이들은 실행을 위해 정적 코드 실행 영역(들)(20)으로 로딩되는 다양한 정적 코드를 포함할 수 있다. 동적 코드 생성기(10)는, 컴퓨터 시스템 상에서 실행될 때, 컴퓨터 시스템으로 하여금, 동적 코드 생성기(10)에 대해 전술된 동작들을 포함하는 동작들을 수행하게 하는 복수의 명령어들을 포함할 수 있다. 동적 코드 검증기(12)는, 컴퓨터 시스템 상에서 실행될 때, 컴퓨터 시스템으로 하여금, 동적 코드 검증기(12)에 대해 전술된 동작들을 포함하는 동작들을 수행하게 하는 복수의 명령어들을 포함할 수 있다. 정적 코드(802)는, 컴퓨터 시스템 상에서 실행될 때, 컴퓨터 시스템으로 하여금, 정적으로 생성된 코드에 대해 전술된 동작들을 포함하는 동작들을 수행하게 하는 복수의 명령어들을 포함할 수 있다.

컴퓨터 액세스가능 저장 매체(800)는 집적 회로를 표현하는 데이터베이스(804)를 저장할 수 있다. 일반적으로, 데이터베이스(804)는, 프로그램에 의해 판독될 수 있고 집적 회로를 포함하는 하드웨어를 제조하기 위해 직접적으로 또는 간접적으로 사용될 수 있는 데이터베이스일 수 있다. 예를 들어, 데이터베이스는 베릴로그(Verilog) 또는 VHDL과 같은 고레벨 설계 언어(high level design language, HDL)에서 하드웨어 기능의 거동-레벨 디스크립션(behavioral-level description) 또는 레지스터-전송 레벨(register-transfer level, RTL) 디스크립션일 수 있다. 디스크립션은 합성 라이브러리로부터의 게이트들의 목록을 포함하는 넷리스트(netlist)를 생성하기 위해 디스크립션을 합성할 수 있는 합성 도구에 의해 판독될 수 있다. 넷리스트는 집적 회로를 포함하는 하드웨어의 기능을 또한 표현하는 한 세트의 게이트들을 포함한다. 이어서, 넷리스트는 마스크들에 적용될 기하학적 형상들을 설명하는 데이터 세트를 생성하기 위해 배치되고 라우팅될 수 있다. 이어서, 마스크들은 집적 회로에 대응하는 반도체 회로 또는 회로들을 생성하기 위한 다양한 반도체 제조 단계들에서 사용될 수 있다. 대안적으로, 컴퓨터 액세스가능 저장 매체(800) 상의 데이터베이스(804)는, 원하는 대로, 넷리스트(합성 라이브러리가 있거나 없음) 또는 데이터 세트일 수 있다.

컴퓨터 액세스가능 저장 매체(800)가 집적 회로의 표현을 저장하지만, 다른 실시예들은 도 6에 도시된 컴포넌트들의 임의의 서브세트를 포함하여, 원하는 대로, 집적 회로의 임의의 부분의 표현을 반송할 수 있다. 데이터베이스(804)는 위의 것의 임의의 부분을 표현할 수 있다.

본 개시내용은 "실시예" 또는 "실시예들의 그룹들"(예를 들어, "일부 실시예들" 또는 "다양한 실시예들")에 대한 언급들을 포함한다. 실시예들은 개시된 개념들의 상이한 구현들 또는 인스턴스들이다. "일 실시예", "하나의 실시예", "특정 실시예" 등에 대한 언급들은 반드시 동일한 실시예를 지칭하는 것은 아니다. 구체적으로 개시된 것들 뿐만 아니라, 본 개시내용의 사상 또는 범주 내에 속하는 수정들 또는 대안들을 포함하는 많은 가능한 실시예들이 고려된다.

본 개시내용은 개시된 실시예들로부터 발생할 수 있는 잠재적인 이점들을 논의할 수 있다. 이들 실시예들의 모든 구현들이 반드시 잠재적인 이점들 중 임의의 또는 모든 것을 나타내는 것은 아닐 것이다. 특정 구현에 대해 이점이 실현되는지 여부는 많은 인자들에 의존하며, 이들 중 일부는 본 개시내용의 범위를 벗어난다. 실제로, 청구항들의 범위 내에 속하는 구현이 임의의 개시된 이점들 중 일부 또는 전부를 나타내지 않을 수 있는 많은 이유들이 있다. 예를 들어, 특정 구현은 개시된 실시예들 중 하나와 함께, 하나 이상의 개시된 이점들을 무효화하거나 약화시키는, 본 개시내용의 범위 밖의 다른 회로부를 포함할 수 있다. 더욱이, 특정 구현의 차선의 설계 실행(예를 들어, 구현 기법들 또는 도구들)은 또한 개시된 이점들을 무효화하거나 약화시킬 수 있다. 숙련된 구현을 가정하더라도, 이점들의 실현은 구현이 전개되는 환경 상황들과 같은 다른 인자들에 여전히 의존할 수 있다. 예를 들어, 특정 구현에 공급되는 입력들은 본 개시내용에서 해결되는 하나 이상의 문제들이 특정 기회에 발생하는 것을 방지할 수 있으며, 그 결과, 그 해결책의 이익이 실현되지 않을 수 있다. 본 개시내용 외부의 가능한 인자들의 존재를 고려할 때, 본 명세서에서 설명되는 임의의 잠재적인 이점들은, 침해를 입증하기 위해 충족되어야 하는 청구항 제한들로서 해석되지 않아야 한다는 것이 명백하게 의도된다. 오히려, 그러한 잠재적 이점들의 식별은 본 개시내용의 이익을 갖는 설계자들에게 이용가능한 개선의 유형(들)을 예시하도록 의도된다. 그러한 이점들이 허용가능하게 설명된다는 것(예를 들어, 특정 이점이 "발생할 수 있다"고 언급함)은 그러한 이점들이 실제로 실현될 수 있는지에 대한 의구심을 전달하도록 의도되는 것이 아니라, 그러한 이점들의 실현이 종종 부가적인 인자들에 의존한다는 기술적 현실을 인식하도록 의도된다.

달리 언급되지 않는 한, 실시예들은 비제한적이다. 즉, 개시된 실시예들은, 특정 특징에 대해 단일 예만이 설명되는 경우에도, 본 개시내용에 기초하여 작성되는 청구항들의 범위를 제한하도록 의도되지 않는다. 개시된 실시예들은, 이에 반하는 본 개시내용의 어떠한 진술도 없이, 제한적이기보다는 예시적인 것으로 의도된다. 따라서, 본 출원은 개시된 실시예들을 커버하는 청구항들뿐만 아니라, 본 개시내용의 이익을 갖는 당업자에게 명백할 그러한 대안들, 수정들 및 등가물들을 허용하도록 의도된다.

예를 들어, 본 출원에서의 특징들은 임의의 적합한 방식으로 조합될 수 있다. 따라서, 특징부들의 임의의 그러한 조합에 대해 본 출원(또는 그에 대한 우선권을 주장하는 출원)의 심사 동안에 새로운 청구범위가 작성될 수 있다. 특히, 첨부된 청구항들을 참조하면, 종속 청구항들로부터의 특징들은 다른 독립 청구항들로부터 의존하는 청구항들을 포함하여, 적절한 경우 다른 종속 청구항들의 특징들과 조합될 수 있다. 유사하게, 개개의 독립 청구항들로부터의 특징들은 적절한 경우 조합될 수 있다.

따라서, 첨부된 종속 청구항들은 각각이 단일의 다른 청구항에 의존하도록 작성될 수 있지만, 부가적인 종속성들이 또한 고려된다. 본 개시내용과 일치하는 종속물에서의 특징들의 임의의 조합들이 고려되며, 이러한 또는 다른 출원에서 청구될 수 있다. 간단히 말하면, 조합들은 첨부된 청구항들에 구체적으로 열거된 것들로 제한되지 않는다.

적절한 경우, 하나의 포맷 또는 법정 유형(예를 들어, 장치)으로 작성된 청구항들은 다른 포맷 또는 법정 유형(예를 들어, 방법)의 대응하는 청구항들을 지원하도록 의도되는 것으로 또한 고려된다.

본 개시내용은 법적인 문서이기 때문에, 다양한 용어들 및 문구들은 행정적 및 사법적 해석의 대상이 될 수 있다. 본 개시내용 전반에 걸쳐 제공되는 정의들뿐만 아니라 다음의 단락들이 본 개시내용에 기초하여 작성되는 청구항들을 해석하는 방법을 결정하는 데 사용될 것이라는 공지가 본 명세서에 주어진다.

물품의 단수 형태(즉, "a", "an" 또는 "the"가 선행되는 명사 또는 명사 문구)에 대한 언급들은, 문맥상 명확하게 달리 지시되지 않는 한, "하나 이상"을 의미하는 것으로 의도된다. 따라서, 청구항에서 "항목"에 대한 언급은, 수반되는 상황 없이, 항목의 추가적인 인스턴스들을 배제하지 않는다. "복수"의 항목들은 항목들 중 2개 이상의 세트를 지칭한다.

"~할 수 있다"라는 단어는 본 명세서에서 강제적인 의미(즉, ~ 해야 하는)가 아니라 허용적인 의미(즉, ~할 가능성을 갖는, ~할 수 있는)로 사용된다.

용어들 "포함하는"("comprising" 및 "including") 및 이들의 형태들은 개방형(open-ended)이며, "포함하지만 이로 한정되지 않는"을 의미한다.

용어 "또는"이 옵션들의 리스트에 관하여 본 개시내용에서 사용될 때, 문맥이 달리 제공하지 않는 한, 일반적으로 포괄적인 의미로 사용되는 것으로 이해될 것이다. 따라서, "x 또는 y"의 언급은 "x 또는 y, 또는 둘 모두"와 동등하고, 따라서 1) x지만 y 아님, 2) y지만 x 아님 및 3) x 및 y 둘 모두를 커버한다. 반면에, "둘 모두가 아니라 x 또는 y 중 어느 하나"와 같은 문구는 "또는"이 배타적인 의미로 사용되고 있다는 것을 명확하게 한다.

"w, x, y, 또는 z, 또는 이들의 임의의 조합" 또는 "... w, x, y, 및 z 중 적어도 하나"의 언급은 세트 내의 요소들의 총 개수까지 단일 요소를 수반하는 모든 가능성들을 커버하도록 의도된다. 예를 들어, 세트 [w, x, y, z]가 주어지면, 이러한 문구들은 세트의 임의의 단일 요소(예를 들어, w지만 x, y, 또는 z 아님), 임의의 2개의 요소들(예를 들어, w 및 x지만 y 또는 z 아님), 임의의 3개의 요소들(예를 들어, w, x 및 y지만, z 아님) 및 4개의 요소들 모두를 커버한다. 따라서, "... w, x, y, 및 z 중 적어도 하나"라는 문구는 세트 [w, x, y, z]의 적어도 하나의 요소를 지칭하고, 이로써 요소들의 이러한 리스트 내의 모든 가능한 조합들을 커버한다. 이 문구는 w의 적어도 하나의 인스턴스, x의 적어도 하나의 인스턴스, y의 적어도 하나의 인스턴스, 및 z의 적어도 하나의 인스턴스가 있음을 요구하도록 해석되지 않아야 한다.

본 개시내용에서 다양한 "라벨들"이 명사들 또는 명사 문구들에 선행할 수 있다. 문맥이 달리 제공하지 않는 한, 특징에 대해 사용되는 상이한 라벨들(예를 들어, "제1 회로", "제2 회로", "특정 회로", "주어진 회로" 등)은 특징의 상이한 인스턴스들을 지칭한다. 부가적으로, 특징에 적용될 때, "제1", "제2" 및 "제3" 라벨들은, 달리 언급되지 않는 한, 어떠한 유형의 순서화(예를 들어, 공간적, 시간적, 논리적 등)를 의미하지 않는다.

문구 "기초하여"는 결정에 영향을 주는 하나 이상의 인자들을 설명하기 위해 사용된다. 이러한 용어는 부가적인 인자들이 결정에 영향을 줄 수 있는 가능성을 배제하지 않는다. 즉, 결정은 단지 특정된 인자들에 기초하거나 또는 그 특정된 인자들뿐만 아니라 다른, 불특정된 인자들에 기초할 수 있다. "B에 기초하여 A를 결정한다"라는 문구를 고려한다. 이러한 문구는 B가 A를 결정하는 데 사용되거나 A의 결정에 영향을 주는 인자라는 것을 명시한다. 이러한 문구는 A의 결정이 C와 같은 일부 다른 인자에 또한 기초할 수 있음을 배제하지 않는다. 또한, 이 문구는 A가 B만에 기초하여 결정되는 실시예를 커버하도록 의도된다. 본 명세서에서 사용되는 바와 같이, "에 기초하여"라는 문구는 "적어도 부분적으로 기초하여"라는 문구와 동의어이다.

문구들 "~ 에 응답하여" 및 "~ 에 응답으로"는 효과를 트리거하는 하나 이상의 인자들을 설명한다. 이러한 문구는 부가적인 인자들이 특정 인자들과 공동으로 또는 특정 인자들과는 독립적으로 영향을 주거나 또는 달리 효과를 트리거할 수 있는 가능성을 배제하지 않는다. 즉, 효과는 단지 이들 인자들에만 응답할 수 있거나 또는 특정 인자들 뿐만 아니라 다른 불특정 인자들에 응답할 수 있다. "B에 응답하여 A를 수행한다"라는 문구를 고려한다. 이러한 문구는 B가 A의 수행을 트리거하는 또는 A에 대한 특정 결과를 트리거하는 인자라는 것을 명시한다. 이러한 문구는 A를 수행하는 것이 C와 같은 일부 다른 인자에 또한 응답할 수 있음을 배제하지 않는다. 이러한 문구는 또한 A를 수행하는 것이 B와 C에 응답하여 공동으로 수행될 수 있다는 것을 배제하지 않는다. 이러한 문구는 또한 A가 B에만 응답하여 수행되는 실시예를 커버하도록 의도된다. 본 명세서에서 사용되는 바와 같이, 문구 "응답하여"는 문구 "적어도 부분적으로 응답하여"와 동의어이다. 유사하게, 문구 "~ 에 응답하여"는 문구 "적어도 부분적으로 응답하여"와 동의어이다.

본 개시내용 내에서, 상이한 엔티티들(이는, "유닛들", "회로들", 다른 컴포넌트들 등으로 다양하게 지칭될 수 있음)은 하나 이상의 태스크들 또는 동작들을 수행하도록 "구성된" 것으로 설명되거나 또는 청구될 수 있다. 이러한 표현-[하나 이상의 태스크들을 수행]하도록 구성된 [엔티티]-은 본 명세서에서 구조(즉, 물리적인 것)를 지칭하는 데 사용된다. 더 상세하게는, 이러한 표현은 이러한 구조가 동작 동안 하나 이상의 태스크들을 수행하도록 배열됨을 나타내는 데 사용된다. 구조는 그 구조가 현재 동작되고 있지 않더라도 일부 태스크를 수행하도록 "구성된다"고 말할 수 있다. 따라서, 일부 태스크를 수행"하도록 구성된" 것으로 설명된 또는 언급된 엔티티는 디바이스, 회로, 태스크를 구현하도록 실행가능한 프로그램 명령어들을 저장하는 메모리 및 프로세서 유닛을 갖는 시스템 등과 같은 물리적인 것을 지칭한다. 이러한 문구는 본 명세서에서 무형인 것을 지칭하기 위해 사용되지는 않는다.

일부 경우들에서, 다양한 유닛들/회로들/컴포넌트들은 태스크 또는 동작들의 세트를 수행하는 것으로 본 명세서에서 설명될 수 있다. 이들 엔티티들은, 구체적으로 언급되지 않더라도, 그러한 태스크들/동작들을 수행하도록 "구성"된다는 것이 이해된다.

용어 "~ 하도록 구성된"은 "~하도록 구성가능한"을 의미하도록 의도되지 않는다. 예를 들어, 프로그래밍되지 않은 FPGA는 특정 기능을 수행하도록 "구성된" 것으로 간주되지 않을 것이다. 그러나, 이러한 프로그래밍되지 않은 FPGA는 그 기능을 수행하도록 "구성가능"할 수 있다. 적절한 프로그래밍 후에, 이어서 FPGA는 특정 기능을 수행하도록 "구성된다"고 말할 수 있다.

상이한 "회로들"이 본 개시내용에서 설명될 수 있다. 이러한 회로들 또는 "회로부"는 조합 로직, 클로킹된 저장 디바이스들(예를 들어, 플립-플롭들, 레지스터들, 래치들 등), 유한 상태 머신들, 메모리(예를 들어, 랜덤 액세스 메모리, 내장형 동적 랜덤 액세스 메모리), 프로그래밍가능 로직 어레이들 등과 같은 다양한 유형들의 회로 요소들을 포함하는 하드웨어를 구성한다. 회로부는 맞춤 설계되거나 표준 라이브러리들로부터 취해질 수 있다. 다양한 구현들에서, 회로부는 적절하게 디지털 컴포넌트들, 아날로그 컴포넌트들, 또는 둘 모두의 조합을 포함할 수 있다. 특정 유형들의 회로들은 일반적으로 "유닛들"(예를 들어, 디코드 유닛, 산술 로직 유닛(ALU), 기능 유닛, 메모리 관리 유닛(MMU) 등)로 지칭될 수 있다. 그러한 유닛들은 또한 회로들 또는 회로부를 지칭한다.

따라서, 도면들에 예시되고 본 명세서에서 설명된 개시된 회로들/유닛들/컴포넌트들 및 다른 요소들은 이전 단락에서 설명된 것들과 같은 하드웨어 요소들을 포함한다. 많은 경우들에서, 특정 회로 내의 하드웨어 요소들의 내부 배열은 그 회로의 기능을 설명함으로써 특정될 수 있다. 예를 들어, 특정 "디코드 유닛"은 "명령어의 동작코드를 처리하고 그 명령어를 복수의 기능 유닛들 중 하나 이상에 라우팅하는" 기능을 수행하는 것으로 설명될 수 있으며, 이는 디코드 유닛이 이러한 기능을 수행하도록 "구성됨"을 의미한다. 이러한 기능의 규격은, 컴퓨터 분야의 당업자들에게, 회로에 대한 가능한 구조들의 세트를 암시하기에 충분하다.

다양한 실시예들에서, 이전 단락에서 논의된 바와 같이, 회로들, 유닛들, 및 이들이 구현하도록 구성된 기능들 또는 동작들에 의해 정의된 다른 요소들, 배열 및 그러한 회로들/유닛들/컴포넌트들은 서로에 대해 그리고 이들이 상호작용하는 방식으로, 마이크로아키텍처 정의의 물리적 구현을 형성하도록 집적 회로에서 궁극적으로 제조되거나 FPGA로 프로그래밍되는 하드웨어의 마이크로

아키텍처 정의를 형성한다. 따라서, 마이크로아키텍처 정의는 많은 물리적 구현들이 유도될 수 있는 구조로서 당업자들에 의해 인식되며, 이들 모두는 마이크로아키텍처 정의에 의해 설명된 더 넓은 구조에 속한다. 즉, 본 개시내용에 따라 공급되는 마이크로아키텍처 정의를 제공받는 당업자는, 과도한 실험 없이 그리고 통상의 기술의 적용으로, 회로들/유닛들/컴포넌트들의 디스크립션을 Verilog 또는 VHDL과 같은 하드웨어 디스크립션 언어(HDL)로 코딩함으로써 구조를 구현할 수 있다. HDL 디스크립션은 종종, 기능적으로 보일 수 있는 방식으로 표현된다. 그러나, 당업자들에게, 이러한 HDL 디스크립션은 회로, 유닛 또는 컴포넌트의 구조를 다음 레벨의 구현 세부사항으로 변환하는 데 사용되는 방식이다. 그러한 HDL 디스크립션은 (통상적으로 합성가능하지 않은) 거동 코드, (거동 코드와는 대조적으로, 통상적으로 합성가능한) 레지스터 전송 언어(RTL) 코드, 또는 구조적 코드(예를 들어, 로직 게이트들 및 그들의 연결성을 특정하는 넷리스트)의 형태를 취할 수 있다. HDL 디스크립션은 주어진 집적 회로 제조 기술을 위해 설계된 셀들의 라이브러리에 대해 순차적으로 합성될 수 있고, 타이밍, 전력 및 다른 이유들로 인해 수정되어 최종 설계 데이터베이스를 생성할 수 있으며, 이는 파운드리(foundry)로 송신되어 마스크들을 생성하고 궁극적으로 집적 회로를 생성할 수 있다. 일부 하드웨어 회로들 또는 그의 부분들은 또한 회로도 편집기(schematic editor)로 맞춤 설계될 수 있고 합성된 회로부와 함께 집적 회로 설계 내로 캡처될 수 있다. 집적 회로들은 트랜지스터들, 및 다른 회로 요소들(예를 들어, 커패시터들, 저항기들, 인덕터들 등과 같은 수동 요소들) 및 트랜지스터들과 회로 요소들 사이의 상호연결부를 포함할 수 있다. 일부 실시예들은 하드웨어 회로들을 구현하기 위해 함께 결합된 다수의 집적 회로들을 구현할 수 있고, 그리고/또는 일부 실시예들에서는 별개의 요소들이 사용될 수 있다. 대안적으로, HDL 설계는 FPGA(Field Programmable Gate Array)와 같은 프로그래밍가능 로직 어레이로 합성될 수 있으며 FPGA에서 구현될 수 있다. 회로들의 그룹의 설계와 이들 회로들의 후속 저레벨 구현 사이의 이러한 분리는 일반적으로, 회로 또는 로직 설계자가 회로가 무엇을 하도록 구성되는지의 설명을 넘어서 저레벨 구현에 대한 특정 세트의 구조들을 결코 특정하지 않는 시나리오를 도출하는데, 이는 이러한 처리가 회로 구현 처리의 상이한 스테이지에서 수행되기 때문이다.

회로 요소들의 많은 상이한 저레벨 조합들이 회로의 동일한 규격을 구현하는 데 사용될 수 있다는 사실은 그 회로에 대한 다수의 등가 구조들을 초래한다. 언급된 바와 같이, 이러한 저레벨 회로 구현들은 제조 기술의 변화들, 집적 회로를 제조하기 위해 선택된 파운드리, 특정 프로젝트를 위해 제공된 셀들의 라이브러리 등에 따라 변할 수 있다. 많은 경우들에서, 이들 상이한 구현들을 생성하기 위해 상이한 설계 도구들 또는 방법론들에 의해 이루어지는 선택들은 임의적일 수 있다.

게다가, 회로의 특정 기능 규격의 단일 구현이 주어진 실시예에 대해 많은 수의 디바이스들(예를 들어, 수백만 개의 트랜지스터들)을 포함하는 것이 일반적이다. 따라서, 엄청난 볼륨의 이러한 정보는, 등가의 가능한 구현들의 방대한 어레이는 말할 것도 없이, 단일 실시예를 구현하는 데 사용되는 저레벨 구조의 완전한 설명을 제공하는 것을 비실용적으로 만든다. 이러한 이유로, 본 개시내용은 업계에서 일반적으로 사용되는 기능적 속기(shorthand)를 사용하여 회로들의 구조를 설명한다.

일단 위의 개시내용이 완전히 이해되면 다수의 변형들 및 수정들이 당업자들에게 명백해질 것이다. 다음의 청구범위는 모든 그러한 변형들 및 수정들을 망라하는 것으로 해석되도록 의도된다.

Claims

방법으로서,
컴퓨터 시스템 내의 프로세서 내의 모니터 회로에서, 동적으로 생성된 코드 시퀀스가 하나 이상의 실행 기준들을 충족하는 것을 보장하기 위해 상기 컴퓨터 시스템에서 실행되고 있는 상기 동적으로 생성된 코드 시퀀스를 모니터링하는 단계 - 상기 하나 이상의 실행 기준들은 상기 동적으로 생성된 코드 시퀀스에서 허용되지 않는 명령어들의 서브세트의 부재를 포함하고, 상기 동적으로 생성된 코드 시퀀스는 동적 코드 실행 영역에 저장됨 -;
상기 모니터 회로에 의한 상기 하나 이상의 실행 기준들의 위반을 검출하는 단계; 및
상기 모니터 회로에 의해, 상기 위반의 검출에 기초하여 예외를 강제하는 단계를 포함하는, 방법.
제1항에 있어서, 상기 하나 이상의 실행 기준들은 상기 동적 코드 실행 영역 외부에 있는 브랜치 타겟이 하나 이상의 암호화 키들의 세트 중 하나를 이용하여 암호화 방식으로 서명된다는 요건을 포함하는, 방법.
제2항에 있어서, 상기 하나 이상의 암호화 키들의 세트는 암호화 서명 동작들을 위해 상기 동적으로 생성된 코드 시퀀스에 액세스가능하지 않은, 방법.
제3항에 있어서, 하나 이상의 암호화 키들의 제2 세트는, 하나 이상의 타겟 어드레스들을 외부 소스로부터 상기 동적으로 생성된 코드 시퀀스에 암호화 방식으로 서명하기 위해 상기 동적으로 생성된 코드 시퀀스에 의한 사용을 위해 제공되는, 방법.
제2항 내지 제4항 중 어느 한 항에 있어서, 상기 하나 이상의 실행 기준들은 상기 브랜치 타겟이 상기 동적 코드 실행 영역 외부의 하나 이상의 미리 정의된 어드레스 범위들 중 하나 내에 있다는 요건을 포함하는, 방법.
제1항 내지 제5항 중 어느 한 항에 있어서, 상기 동적 코드 실행 영역에 대응하는 어드레스 범위에 인접한 한 쌍의 어드레스 범위들은 직접 브랜치 명령어들이 상기 동적 코드 실행 영역을 빠져나가는 것을 방지하기 위해 상기 동적으로 생성된 코드 시퀀스의 명령어들에 대해 액세스가능하지 않은, 방법.
제6항에 있어서, 상기 한 쌍의 어드레스 범위들 중 주어진 어드레스 범위의 크기는 상기 동적 코드 실행 영역 내에서 주어진 직접 브랜치 명령어로 도달가능한 범위에 기초하는, 방법.
프로세서로서,
메모리 내에 동적 코드 실행 영역을 정의하도록 프로그래밍가능한 하나 이상의 구성 레지스터들 - 동적으로 생성된 코드는 사용 동안 상기 동적 코드 실행 영역에서 실행됨 -; 및
상기 하나 이상의 구성된 레지스터들에 결합되는 모니터 회로를 포함하고, 상기 모니터 회로는,
동적으로 생성된 코드 시퀀스가 하나 이상의 실행 기준들을 충족하는 것을 보장하기 위해 상기 프로세서에서 실행되고 있는 상기 동적으로 생성된 코드 시퀀스를 모니터링하고, 그리고
상기 하나 이상의 실행 기준들의 위반의 검출에 기초하여 상기 프로세서에서 예외를 야기하도록 구성되고,
상기 하나 이상의 실행 기준들은 상기 동적으로 생성된 코드 시퀀스에서 허용되지 않는 명령어들의 서브세트의 부재를 포함하는, 프로세서.
제8항에 있어서, 상기 하나 이상의 실행 기준들은 상기 동적 코드 실행 영역 외부에 있는 브랜치 타겟이 하나 이상의 암호화 키들의 세트 중 하나를 이용하여 암호화 방식으로 서명된다는 요건을 포함하는, 프로세서.
제9항에 있어서, 상기 하나 이상의 암호화 키들의 세트는 상기 동적으로 생성된 코드 시퀀스에 액세스가능하지 않은, 프로세서.
제10항에 있어서, 하나 이상의 암호화 키들의 제2 세트는, 하나 이상의 타겟 어드레스들을 외부 소스로부터 상기 동적으로 생성된 코드 시퀀스에 암호화 방식으로 서명하기 위해 상기 동적으로 생성된 코드 시퀀스를 위해 제공되는, 프로세서.
제9항 내지 제11항 중 어느 한 항에 있어서, 상기 하나 이상의 실행 기준들은 상기 브랜치 타겟이 상기 동적 코드 실행 영역 외부의 하나 이상의 미리 정의된 어드레스 범위들 중 하나 내에 있다는 요건을 포함하는, 프로세서.
제8항 내지 제12항 중 어느 한 항에 있어서, 상기 모니터 회로는 상기 동적 코드 실행 영역에 대응하는 어드레스 범위에 인접한 한 쌍의 어드레스 범위들 내에서 액세스하려는 시도를 검출하고, 상기 프로세서에서 예외를 야기함으로써 상기 액세스를 방지하도록 구성되는, 프로세서.
제13항에 있어서, 상기 한 쌍의 어드레스 범위들 중 주어진 어드레스 범위의 크기는 상기 동적 코드 실행 영역 내에서 직접 브랜치 명령어로 도달가능한 범위에 기초하는, 프로세서.
컴퓨터 시스템으로서,
메모리 시스템 - 동적 코드 실행 영역이 상기 메모리 시스템 내의 어드레스 범위에서 정의되고, 동적으로 생성된 코드가 사용 동안에 상기 동적 코드 실행 영역에서 실행됨 -; 및
제8항 내지 제14항 중 어느 한 항에 언급된 적어도 하나의 프로세서를 포함하고, 상기 동적으로 생성된 코드 시퀀스는 상기 동적 코드 실행 영역에 저장되는, 컴퓨터 시스템.