KR101015456B1 - 디바이스에 의한 메모리로의 억세스 제어 - Google Patents

디바이스에 의한 메모리로의 억세스 제어 Download PDF

Info

Publication number
KR101015456B1
KR101015456B1 KR1020057008761A KR20057008761A KR101015456B1 KR 101015456 B1 KR101015456 B1 KR 101015456B1 KR 1020057008761 A KR1020057008761 A KR 1020057008761A KR 20057008761 A KR20057008761 A KR 20057008761A KR 101015456 B1 KR101015456 B1 KR 101015456B1
Authority
KR
South Korea
Prior art keywords
secure
memory
mode
access
processor
Prior art date
Application number
KR1020057008761A
Other languages
English (en)
Other versions
KR20050085000A (ko
Inventor
시몬 찰스 와트
리오넬 벨넷
다비드 헨나 만셀
니콜라 쇼샤드
피터 가이 미들턴
Original Assignee
에이알엠 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0226875A external-priority patent/GB0226875D0/en
Priority claimed from GB0226879A external-priority patent/GB0226879D0/en
Priority claimed from GB0303446A external-priority patent/GB0303446D0/en
Application filed by 에이알엠 리미티드 filed Critical 에이알엠 리미티드
Publication of KR20050085000A publication Critical patent/KR20050085000A/ko
Application granted granted Critical
Publication of KR101015456B1 publication Critical patent/KR101015456B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82Protecting input, output or interconnection devices
    • G06F21/85Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2105Dual mode as a secondary aspect
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2149Restricted operating environment

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • Storage Device Security (AREA)

Abstract

본 발명은 데이터 처리장치와 메모리로의 억세스 제어방법을 제공한다. 이 데이터 처리장치는, 보안 도메인과 비보안 도메인을 갖고, 상기 보안 도메인에서 데이터 처리장치는 비보안 도메인에서 억세스 가능하지 않은 보안 데이터에의 억세스를 하게 한다. 데이터 처리장치는, 디바이스 버스를 통해 메모리에 연결되고, 그 메모리 내의 데이터 항목을 상기 디바이스에서 필요로 하는 경우, 상기 디바이스 버스 상에서 상기 보안 도메인 또는 비보안 도메인에 관련되는 메모리 억세스 요구를 발행가능하도록 동작하는 디바이스를 구비한다. 메모리는, 디바이스에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 메모리와 비보안 데이터 저장용 비보안 메모리를 포함한다. 본 발명에 따르면, 데이터 처리장치는, 디바이스 버스에 연결되고, 디바이스에서 발행된 것과 같은 메모리 억세스 요구가 비보안 도메인과 관련될 때마다, 그 메모리 억세스 요구가 보안 메모리를 억세스 하려고 하는지를 검출가능하도록 동작하고, 그 검출시에 그 메모리 요구에서 특정된 억세스를 방지하는 파티션 검사 로직부를 더 구비한다. 이러한 방법으로 메모리의 보안부 내에 포함된 데이터의 보안성을 상당히 향상시킨다.
데이터 처리장치, 보안, 비보안, 파티션 검사 로직부, 메모리

Description

디바이스에 의한 메모리로의 억세스 제어{CONTROL OF ACCESS TO A MEMORY BY A DEVICE}
본 발명은 디바이스에 의한 메모리로의 억세스를 제어하는 기술에 관한 것이다.
데이터 처리 장치는 전형적으로 데이터 처리 장치에 적재된 어플리케이션을 실행하기 위한 프로세서를 포함한다. 상기 프로세서는 운영체계의 제어하에 동작한다. 일반적으로, 특정한 애플리케이션을 수행하기 위하여 필요한 데이터는 데이터 처리 장치의 메모리 내부에 저장된다. 상기 데이터는 애플리케이션에 포함된 명령어 및/또는 이러한 명령어들이 프로세서에서 실행되는 동안 사용되는 실제 데이터 값일 수 있다.
하나 이상의 애플리케이션에서 사용되는 데이터는, 프로세서상에서 실행되는 다른 어플리케이션에 의하여 억세스 가능하지 않아야 하는 민감한 데이터인 다양한 경우가 있을 수 있다. 예를 들어, 데이터 처리 장치가 스마트 카드인 경우, 어플리케이션들 중 한가지가 검증(validation), 인증(authentication), 복호화(decryption) 등을 수행하기 위하여 예를 들면 보안 키와 같은 민감한 데이터를 사용하는 보안 어플리케이션이다. 이러한 상황에서는 그러한 민감한 데이터가 보안을 유지하여, 그것이 데이터 처리장치에 적재된 다른 어플리케이션, 예를 들어, 보안 데이터에 억세스하기 위하여 검색하는 것을 목적으로 하는 데이터 처리장치에 적재된 해킹 어플리케이션에 의하여 억세스 될 수 없도록 하는 것이 명백히 중요하다.
공지의 시스템에서는, 운영체계가 하나의 어플리케이션의 보안 데이터가 운영체계의 제어하에 실행되는 다른 어플리케이션에 의하여 억세스 될 수 없도록 충분한 보안성을 제공하도록 하는 것이 일반적으로, 운영체계 개발자의 업무였다. 그러나, 시스템이 점점 복잡해지면서 운영체계의 경향은 점점 커지고 복잡해지며, 이러한 상황에서 운영체계 자체내에서 충분한 보안성을 확보하는 것은 점점 어려워졌다.
민감한 데이터에 대한 안전한 저장공간을 제공하고 악의적인 프로그램 코드로부터 보호하기 위한 시스템의 예로는, 미국특허출원 US 2002/0007456 A1 및 미국특허 US 6,282,657B, US 6,292,874B가 있다.
따라서, 데이터 처리장치의 메모리 내부에 포함된 보안 데이터의 보안성을 확보하려고 하는 개선된 기술을 제공하는 것이 바람직하다.
본 발명의 제 1 측면은, 보안 도메인과 비보안 도메인을 갖고, 그 비보안 도메인에서 억세스 가능하지 않은 보안 데이터에 대해 보안 도메인에서 억세스를 하는 데이터 처리장치를 제공하는 것으로, 상기 데이터 처리장치는, 디바이스 버스와, 이 디바이스 버스에 연결되어 상기 보안 도메인 또는 상기 비보안 도메인에 관련된 메모리 억세스 요구를 발행가능하도록 동작하는 디바이스와, 상기 디바이스 버스에 연결되고, 메모리에 있는 데이터 항목으로의 억세스를 필요로 하는 경우 상기 디바이스 버스 상에서 메모리 억세스 요구를 발행가능하도록 동작하는 상기 디바이스에서, 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 메모리와 비보안 데이터 저장용 비보안 메모리로 이루어진 메모리와, 상기 디바이스 버스에 연결되고, 상기 디바이스에서 발행한 것과 같은 상기 메모리 억세스 요구가 상기 비보안 도메인에 관련될 때마다 그 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출가능하도록 동작하고, 상기 검출시에 상기 메모리 억세스 요구에서 특정된 억세스를 방지하는 파티션 검사 로직부를 구비한다.
본 발명에 따른 디바이스는, 디바이스 버스를 통해 메모리와 연결되고, 보안 도메인 또는 비보안 도메인에 관련된 메모리 억세스 요구를 발행가능하도록 동작한다. 상기 메모리는, 디바이스에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터용 보안 메모리와 비보안 데이터용 비보안 메모리로 이루어진다. 상기 디바이스가 메모리에 있는 데이터 항목을 억세스하길 원하는 경우, 상기 디바이스는 디바이스 버스 상에서 메모리 억세스 요구를 발행하도록 구성되어 있다. 본 발명에 따른 파티션 검사 로직부는, 디바이스 버스에 연결되고, 상기 디바이스에서 발행된 것과 같은 메모리 억세스 요구가 상기 비보안 도메인과 관련될 때마다 상기 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출가능하도록 동작하고, 그 검출시에 메모리 억세스 요구에서 특정된 억세스를 방지하도록 구성된다.
따라서, 상기 파티션 검사 로직부는, 상기 디바이스에서 발생된 메모리 억세스 요구가 비보안 도메인과 관련되는 경우 상기 보안 메모리로의 억세스들이 반드시 일어나지 않도록 하기 위해서 메모리로의 억세스들을 단속하도록 구성되어 있다.
일 실시예에서, 상기 디바이스는, 비보안 도메인에서의 모드인 적어도 하나의 비보안 모드와 보안 도메인에서의 모드인 적어도 하나의 보안 모드로 이루어진 다수의 모드에서 동작가능하다.
상기 파티션 검사 로직부는, 상기 보안 메모리와 비보안 메모리 사이의 파티션들에 대한 정보로 억세스를 한다. 본 파티션 정보는, 보안 메모리와 비보안 메모리 사이의 물리 파티션을 변경할 수 없는 실시예들에서 고정 배선될 수 있다는 것을 알아야 할 것이다. 그러나, 바람직한 실시예에서, 보안 메모리와 비보안 메모리 간의 파티션을 하는 것은, 상기 디바이스가 소정의 보안 모드에서 동작하고 있을 때 상기 디바이스에 의해 변경가능하고, 이러한 실시예에서, 파티션 검사 로직부는, 그 소정의 보안 모드에서 동작하고 있을 때 상기 디바이스에 의해 관리된다. 따라서, 불량 어플리케이션이 보안 데이터를 억세스하려고 하는 목적으로 상기 디바이스에 설치되는 경우, 그 불량 어플리케이션은 보안 도메인에서 실행될 수 없어서, 파티션 정보를 변경할 수 없다. 따라서, 그 불량 어플리케이션이 보안 메모리 내의 위치를 억세스하려고 하고 있는 메모리 억세스 요구를 출력하는 경우라도, 상기 파티션 검사 로직부는, 상기 디바이스의 비보안 모드에서 실행하는 상기 어플리케이션이 보안 메모리 위치를 억세스하려고 하고 있다는 것을 검출하여, 그 억세스가 일어나지 않도록 할 것이다.
상기 파티션 검사 로직부는, 메모리 억세스 요구가 어느 도메인과 관련되는지에 대한 상기 디바이스로부터의 정보를 수신할 수도 있는 다수의 서로 다른 방법들이 있다는 것을 알 수 있을 것이다. 그러나, 바람직한 실시예에서, 상기 디바이스에서 발행된 메모리 억세스 요구는, 그 메모리 억세스 요구가 상기 보안 도메인 또는 상기 비보안 도메인에 관련되어 있는지를 식별하는 도메인 신호를 포함한다.
일 실시예에서, 이에 따라서, 이러한 도메인 신호는 상기 디바이스가 보안 도메인 또는 비보안 도메인에서 동작하고 있는지를 식별하여서, 상기 파티션 검사 로직부를 트리거하여 상기 디바이스가 비보안 도메인에서 동작하고 있는 것을 상기 도메인 신호가 나타내는 경우에 상기 메모리 억세스 요구를 검사할 수 있다. 바람직한 실시예에서, 파티션 검사 로직부는, 상기 디바이스가 보안 도메인에서 동작하고 있을 때 어떠한 파티션 검사도 수행하지 않는데, 그 이유는 바람직한 실시예에서 상기 디바이스가, 보안 모드에서 동작하고 있을 때 상기 보안 메모리와 상기 비보안 메모리 양쪽을 억세스할 수 있기 때문이다.
상기 도메인 신호는, 다양한 방식으로 메모리 억세스 요구 내에 포함될 수 있다는 것을 알 수 있을 것이다. 상기 도메인 신호는 하드웨어 레벨에서 어서트(assert)되어서, 검증된 상기 디바이스 자체를 보안 도메인에서 실행할 수 있는 어플리케이션에 의해 어서트 가능할 뿐이다. 따라서, 상기 디바이스에서 실행하는 불량 어플리케이션이 상기 도메인 신호의 설정을 함부로 변경하는 것이 가능하지 않을 것이다. 보다 구체적으로, 바람직한 실시예에서, 상기 디바이스는, 디바이스 버스 상에 도메인 신호를 출력하기 위한 소정의 핀을 갖고, 상기 도메인 신호는, 그 디바이스가 비보안 모드에서 동작하고 있다는 것을 나타내도록 디폴트로 설정된다. 따라서, 일 실시예에서, 상기 디바이스가 보안 도메인에서의 보안 어플리케이션을 실행하고 있을 때만, 상기 도메인 신호는 상기 디바이스가 보안 도메인에서 동작하고 있다는 것을 나타낼 것이고, 그 도메인 신호가 설정될 때만, 상기 파티션 검사 로직부는, 메모리 내의 보안 데이터로의 억세스를 할 수 있다.
상기 파티션 검사 로직부는 다양한 방식으로 실현될 수 있다는 것을 알 수 있을 것이다. 그러나, 바람직한 실시예에서, 파티션 검사 로직부는, 상기 디바이스 버스에 연결되어 상기 디바이스 버스 상에서 발행된 메모리 억세스 요구들간의 중재를 행하는 중재기 내에 구비된다. 상기 파티션 검사 로직부와 중재기를 연관시키기 편하다는 것을 알았고, 이때의 중재기는 충돌하는 메모리 억세스 요구들간의 우선순위를 결정하고, 파티션 검사 로직부는 상기 중재기에서 인정된 메모리 억세스 요구가 실제로 일어나게 허용되는지를 결정한다.
바람직한 실시예에서, 상기 디바이스는 상기 비보안 도메인에서 비보안 운영체계의 제어하에 동작가능하고, 상기 디바이스는 상기 보안 도메인에서 보안 운영체계의 제어하에 동작가능하다. 일반적으로, 상기 보안 운영체계는, 비보안 운영체계보다 상당히 작을 것이고 특정 보안 기능을 제어하도록 제공된 보안 커널로서 생각될 수 있다. 이러한 방법으로, 보안 도메인은, 제어 환경에서 특정의 감지 동작을 실행가능하게 하는 보안계를 제공하는 것으로서 보여질 수 있다. 그래서, 다른 어플리케이션은, 비보안계로서 생각될 수 있는 비보안 도메인인 채로 있을 것이다.
상기 디바이스는 다양한 형태를 취할 수 있고, 실제로 버스에 연결된 상기와 같은 다수의 디바이스이어도 된다는 것을 알 수 있을 것이다. 상기 버스에 연결된 다수의 디바이스일 경우, 보안 및 비보안 모드 양쪽에서 동작할 수 있는 각 디바이스는, 상기 파티션 검사 로직부가 별도의 디바이스 고유의 파티션 정보로 억세스를 하는 상기와 같은 상황에서, 그 디바이스가 보안 모드에서 동작하고 있을 때 상기 파티션 검사 로직부를 독립적으로 제어하기도 한다. 그러나, 상기 디바이스들 중 하나는, 파티션 검사 로직부의 관리에 책임이 있다는 것이 바람직하다.
바람직한 실시예에서, 적어도 한 개의 디바이스는 프로세서를 내장한 칩으로, 상기 칩은, 상기 프로세서가 메모리 억세스 요구를 발생하는 경우, 1개 이상의 소정의 억세스 제어 기능을 수행하여 상기 디바이스 버스 상에 메모리 억세스 요구를 발행하는 것을 제어가능하도록 동작하는 메모리 관리부를 더 구비한다. 데이터 처리장치의 1개 이상의 다른 부분들은, 동일한 칩 상에 설치되거나 오프(off) 칩 상에 설치되어도 된다.
상기 디바이스 버스에 연결된 메모리의 예로는 랜덤 억세스 메모리(RAM), 판독전용 메모리(ROM), 하드디스크, 특정 주변 디바이스 내의 레지스터 등과 같은 다양한 형태를 취할 수 있다는 것을 알 수 있을 것이다. 상기 메모리와 아울러, 상기 디바이스가 프로세서와 관련된 시스템 버스를 갖는 프로세서를 내장한 칩일 경우, 상기 시스템 버스에 연결된 특정의 메모리, 예를 들면, 캐시 메모리, 밀결합 메모리(TCM;Tightly Coupled Memory) 등이어도 된다는 것도 알 수 있을 것이다.
따라서, 바람직한 실시예에서, 상기 칩은, 시스템 버스를 통해 프로세서에 연결되고, 상기 프로세서에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 추가 메모리와 비보안 데이터 저장용 비보안 추가 메모리를 포함한 추가 메모리와, 상기 시스템 버스에 연결되고, 상기 비보안 도메인에서의 비보안 모드에서 동작하고 있을 때 상기 프로세서에서 메모리 억세스 요구를 발생할 때마다, 상기 메모리 억세스 요구가 상기 보안 메모리 또는 상기 보안 추가 메모리를 억세스하려고 하고 있는지를 검출가능하도록 동작하여, 그 검출시에 그 메모리 억세스 요구에서 특정한 억세스를 방지하는 추가의 파티션 검사 로직부를 더 구비한다.
상기 디바이스 버스에 연결된 파티션 검사 로직부가 상기 시스템 버스에 연결된 메모리에 관하여 어떠한 파티션 검사 기능도 수행할 수 없으므로, 상기와 같은 실시예에서는, 추가의 파티션 검사 로직부를 설치하여, 그 프로세서가 비보안 모드에서 동작하고 있을 때, 보안 메모리 시스템의 어떠한 부분이 상기 디바이스 버스에 연결된 보안 메모리의 부분들인지 보안 데이터를 포함하는 추가의 메모리의 부분들이든지 간에 보안 메모리 시스템의 어떠한 부분도 프로세서가 반드시 억세스할 수 없도록 한다.
본 발명의 일 실시예에 따른 프로세서는, 비보안 도메인에서의 모드인 적어도 하나의 비보안 모드와, 보안 도메인에서의 모드인 적어도 하나의 보안 모드로 이루어진 다수의 모드에서 동작가능하다. 비보안 모드에서 동작하는 경우, 프로세서는 예를 들면, 표준 선재성 운영체계와 같은 비보안 운영체계의 제어하에서 동작가능하다. 그러나, 보안모드에서 동작하는 경우, 프로세서는 보안 운영체계의 제어하에서 동작가능하다. 보안 운영체계는, 비보안 운영체계와 비교하여 상대적으로 작아서, 특정 보안기능을 실행하는 경우 사용하도록 보안 커널의 형태를 취하는 것이 바람직하다. 이러한 방법으로, 보안 도메인은, 제어 환경에서 특정의 감지동작을 실행가능하게 하는 보안계를 제공하는 것으로서 생각될 수 있다. 그래서, 다른 어플리케이션은, 비보안계로서 생각될 수 있는 비보안 도메인인 채로 있다.
일 실시예에서, 메모리 관리부는, 프로세서가 메모리 내의 데이터 항목을 억세스하기를 원할 때 프로세서에서 발행한 메모리 억세스 요구의 수신시에, 상기 메모리에의 상기 메모리 억세스 요구의 발행을 제어하는 1개 이상의 소정의 억세스 제어 기능을 수행가능하도록 동작하게 구성되어 있다. 일례로서, 상기 소정의 억세스 제어기능은, 당업자라면 알 수 있는 것처럼, 복수의 가상 어드레스의 물리 어드레스로의 변환, 현재의 동작모드에서 프로세서가 요구된 데이터 항목을 억세스하는데 반드시 권리가 있도록 하기 위한 억세스 허가권의 검사, 예를 들면 데이터 항목이 캐시 가능한지, 버퍼링 가능한지를 결정하기 위해 영역 속성들의 분석을 포함할 수 있다.
또한, 본 실시예에 따른 추가의 파티션 검사 로직부는, 보안 운영체계에 의해 관리된다. 상기 추가의 파티션 검사 로직부가 보안 운영체계에 의해 관리되므로, 상기 추가의 파티션 검사 로직부의 설정은, 비보안 어플리케이션에 의해 변경될 수 없어, 보안 데이터에의 비인증 억세스를 방지한다.
상기 추가의 파티션 검사 로직부는, 보안 메모리와 비보안 메모리 사이의 파티션에 대한 정보를 억세스할 것이다. 이러한 파티션 정보는, 보안 메모리와 비보안 메모리 사이의 물리 파티션을 변경할 수 없는 실시예들에서 고정 배선될 수 있다는 것을 알 수 있다. 그러나, 바람직한 실시예에서, 보안 메모리와 비보안 메모리간의 파티셔닝을 하는 것은, 프로세서가 소정의 보안 모드에서 동작하고 있는 경우 그 프로세서에 의해 변경가능하고, 이러한 실시예에서, 추가의 파티션 검사 로직부는, 소정의 보안모드에서 동작하고 있는 경우 그 프로세서에 의해 관리된다. 따라서, 불량 어플리케이션이 보안 데이터를 억세스하려고 할 목적으로 프로세서 상에 설치된 경우, 그 어플리케이션은 보안 도메인에서 실행가능하지 못할 것이어서, 그 어플리케이션은 그 파티션 정보를 변경할 수 없다. 따라서, 그 어플리케이션이 보안 메모리 내의 위치를 억세스하려고 하는 메모리 억세스 요구를 출력할 수 있는 경우라도, 그 추가의 파티션 검사 로직부는, 프로세서의 비보안 모드에서 실행하는 상기 불량 어플리케이션이 보안 메모리 위치를 억세스하려고 하고 있는 것을 검출하여, 그 억세스가 일어나지 못하게 할 것이다.
당업자라면, 메모리 억세스 요구가 가상 어드레스들을 특정하거나, 특정 실시예에서 데이터 처리 시스템의 구조에 따라 물리 어드레스들을 특정하기도 한다는 것을 알 수 있을 것이다. 그러나, 바람직한 실시예에서, 프로세서가 비보안 모드에서 동작하고 있는 경우, 메모리 억세스 요구는 가상 어드레스를 특정할 것이고, 상기 메모리 관리부는 비보안 운영체계에 의해 제어된다. 이러한 실시예들에서, 메모리 관리부에서 수행된 바람직한 억세스 제어 기능들 중 하나는, 가상 어드레스를 물리 어드레스로 변환하는 것을 포함하고, 추가의 파티션 검사 로직부는, 메모리 관리부가 발생하는 물리 어드레스가 보안 메모리 내에 있으면 그 메모리 억세스 요구에 의해 특정된 억세스를 방지가능하도록 동작한다.
또한, 바람직한 실시예에서, 프로세서가 보안 모드에서 동작하고 있을 때, 메모리 억세스 요구는 가상 어드레스를 특정하고, 그 경우에, 상기 메모리 관리부는 보안 운영체계에 의해 제어되고, 상기 메모리 관리부에 의해 수행된 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 상기 추가의 파티션 검사 로직부는 적어도 하나의 보안 모드에서 사용되지 않는다.
일 실시예에서, 프로세서의 모든 동작모드는, 메모리 억세스 요구용 가상 어드레스들을 이용하고, 추가의 파티션 검사 로직부는 메모리 관리부 내에 설치되고, 프로세서가 비보안 모드에서 동작하고 있을 때마다 동작가능하다. 따라서, 동작 모드에 상관없이, 메모리 관리부를 사용하여 필요한 어드레스 변환과 임의의 다른 필요한 억세스 제어 기능들을 수행하지만, 추가의 파티션 검사 로직부는, 일반적으로 프로세서가 보안 모드에서 동작하고 있을 때, 그 메모리 내의 데이터로의 억세스에 관한 제한이 없으므로, 상기 프로세서가 비보안 모드에서 동작하고 잇는 경우만 사용되는 것이 바람직하다. 그러나, 다른 실시예에서, 어느 정도의 파티션 검사는 동작의 특정의 보안모드를 위해 제공되어도 된다는 것을 알 것이다.
본 발명의 다른 실시예에서, 물리 어드레스가 직접 메모리 억세스 요구를 특정하는 동작의 적어도 하나의 특정 보안모드가 있음에 따라서, 상기와 같은 특정 보안 모드에서는, 임의의 가상 어드레스의 물리 어드레스로의 변환을 수행할 요구사항이 없다. 물리 어드레스를 직접적으로 특정하는 방법이 가상 어드레스 방법보다 덜 융통적이지만, 가상 어드레스들과 물리 어드레스들 사이에서 수행되는 매핑이 없으므로 본래 더욱 안전하다. 따라서, 특히 일 실시예에서, 메모리 억세스 요구에 대한 물리 어드레스들을 직접 특정하는 보안 모드는, 동작의 가장 좋은 보안모드이고, 바람직한 실시예에서는 이러한 모드를 동작의 모니터 모드라고 하고, 비보안 도메인과 보안 도메인 사이의 데이터 처리장치의 변화를 관리하는데 역할을 한다.
이러한 바람직한 실시예에서, 데이터 처리장치는, 추가의 파티션 검사 로직부가 내부에 설치된 메모리 보호부를 더 구비하고, 상기 메모리 보호부는, 보안 운영체계에 의해 관리되고, 프로세서가 특정 보안모드에서 동작하고 있는 경우, 메모리 억세스 요구는 메모리 위치에 대한 물리 어드레스를 특정하고, 메모리 관리부는 사용되지 않고, 그 메모리 보호부는 적어도 메모리 억세스 허가처리를 수행하고 그 물리 어드레스에 의해 특정된 메모리 위치가 상기 특정 보안 모드에서 억세스 가능한지를 검증가능하도록 동작한다. 따라서, 프로세서가 특정 보안 모드에서 동작하고 있는 경우, 그 억세스는 보안 운영체계에 의해 관리된 메모리 보호부에 의해서만 관리된다.
바람직한 실시예들에서, 메모리는, 다수의 메모리 영역마다 관련 디스크립터를 포함하는 적어도 한개의 테이블을 포함하고, 상기 메모리 관리부는, 디스크립터로부터 얻어지고 메모리 관리부에서 사용된 억세스 제어 정보를 저장하여 메모리 억세스 요구에 대한 소정의 억세스 제어 기능들을 수행하는 내부 저장부를 구비하고, 상기 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리로의 억세스를 허용할 억세스 제어정보를 상기 내부 저장부가 저장하는 것을 방지가능하도록 동작한다.
당업자가 알 수 있듯이, 상기와 같은 디스크립터의 테이블은 다양한 형태를 취할 수 있지만, 바람직한 실시예에서 이러한 테이블들은, 메모리의 다수의 페이지마다 메모리의 그 페이지와 관련된 억세스 제어정보를 기술한 대응한 디스크립터를 정의하는 페이지 테이블들이다. 따라서, 예를 들면, 상기 디스크립터는, 그 페이지에 대한 가상 어드레스부와 이에 대응한 물리 어드레스부와, 그 페이지가 감시모드, 사용자 모드 등에서 억세스가능한지의 여부 등의 억세스 허가정보와, 그 페이지 내에 포함된 데이터가 캐시가능하고 버퍼가능한지 등의 영역 속성을 정의할 수도 있다.
메모리 억세스 요구가 가상 어드레스를 특정하고, 그에 따라서 테이블 내의 디스크립터가 적어도 가상 어드레스부와 그에 대응한 메모리 영역에 대한 대응 물리 어드레스부를 포함하는 실시예에서, 상기 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 가상 어드레스에 대해 생성되는 물리 어드레스가 보안 메모리 내에 있으면 억세스 제어 정보로서 물리 어드레스부를 상기 내부 저장부가 저장하는 것을 방지가능하도록 동작한다.
정확하게 실행하는 시스템에서, 알 수 있듯이, 비보안 모드에서 프로세서가 실행하는 비보안 어플리케이션은, 보안 메모리를 일반적으로 알지 못할 것이고, 프로세서가 상기 비보안 모드에서 동작하고 있을 때 가상 어드레스들을 물리 어드레스로 변환하는 프로세서가 참조하는 테이블은 상기 보안 메모리의 임의의 일부를 포함하는 메모리 영역들을 참조하지 않는다. 그러나, 비보안 어플리케이션이 보안 정보로의 억세스만을 하려고 설계된 해킹 어플리케이션인 예에서, 비보안 모드일 경우 프로세서에서 참조한 테이블내의 디스크립터들을 변조하여, 보안 메모리의 일부를 가리키는 매핑을 생성할 수 있을지도 모른다. 그러나, 상기 추가의 검사 로직부가 보안 운영체계에 의해 보안 도메인에서 관리되므로, 상기 활동들에 의해 변조되지 않음에 따라서, 디스크립터로부터 검색된 물리 어드레스부는 특정 가상 어드레스에 대해 생성될 가상 어드레스가 보안 메모리 내에 포함되도록 하는 이러한 경우를 검출할 수 있다. 따라서, 메모리 내의 테이블이 부정하게 변경된 경우, 추가의 파티션 검사 로직부는, 보안 메모리로의 억세스를 일으킬 경우 상기 변경된 억세스 제어정보를 상기 메모리 관리부의 내부 저장부가 저장하는 것을 방지하여서, 그 억세스가 생기는 것을 방지할 것이다.
메모리 관리부 내의 상기 내부 저장부는, 다양한 형태를 취하기도 한다. 그러나, 바람직한 실시예에서, 내부 저장부는, 다수의 가상 어드레스부마다 상기 적어도 한 개의 테이블로부터 검색된 대응한 디스크립터들로부터 얻어진 대응한 물리 어드레스부를 저장가능하도록 동작하는 변환 색인 버퍼(TLB)이다.
일 실시예에서, 단일 TLB는 메모리 관리부 내에 포함될 것이고, 추가의 파티션 검사 로직부는, 프로세서가 비보안 모드에서 동작하고 있고 그 디스크립터 내의 억세스 제어정보에 의거하여 생성될 물리 어드레스가 보안 메모리 내의 위치를 가리킬 경우, 메모리 내의 테이블로부터 검색된 임의의 디스크립터가 반드시 TLB 내에 저장될 수 없도록 동작한다. 동작의 보안 모드와 비보안 모드 사이에서 스위칭을 하는 경우, TLB는 보안 모드에 관련된 디스크립터가 비보안 모드에서 반드시 사용가능하지 않도록 또는 이와는 반대로 되지 않도록 플러시(flush)될 것이다.
그러나, 다른 실시예에서, 내부 저장부는, 마이크로 TLB와 메인 TLB로 구성되고, 이때 메인 TLB는 메모리 내의 적어도 한개의 테이블로부터 메모리 관리부에서 검색된 디스크립터를 저장하는데 사용되고, 억세스 제어정보를 메모리 관리부에서 사용하고 그 메모리 억세스 요구에 대한 소정의 억세스 제어기능들을 수행하기 전에 메인 TLB로부터 마이크로 TLB로 전송된다. 이러한 실시예들에서, 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 메인 TLB로부터 상기 보안 메모리로의 억세스를 허용할 마이크로 TLB로의 임의의 억세스 제어정보의 전송을 방지가능하도록 동작한다.
따라서, 이러한 실시예에서, 디스크립터는 메인 TLB내에 복사될 수 있지만, 추가의 파티션 검사 로직부는 메인 TLB와 마이크로 TLB 사이에서 상기 프로세서가 비보안 모드에서 동작하고 있을 때 인터페이스를 단속하여, 반드시 억세스 제어정보가 보안 메모리로의 억세스를 허용하는 마이크로 TLB를 통과할 수 없도록 동작한다.
바람직한 실시예에서는, 메모리내에 1개보다 많은 테이블이 설치되어 있고, 서로 다른 테이블이 동작의 모드에 따라 사용되어서, 이것에 의해 서로 다른 억세스 제어정보를 서로 다른 동작의 모드에 대해 정의할 수 있다. 보다 구체적으로, 바람직한 실시예에서, 그 적어도 한개의 테이블은, 프로세서가 상기 적어도 한 개의 비보안 모드에서 동작하고 상기 비보안 운영체계에서 발생된 디스크립터들을 포함하고 있는 경우 사용하도록 비보안 테이블로 이루어지고, 그 경우에, 비보안 테이블 내의 디스크립터는 적어도 부분적으로 상기 보안 메모리의 일부를 포함하는 메모리 영역과 관련되고, 추가의 파티션 검사 로직부는, 프로세서가 비보안 모드에서 동작하고 있을 때, 가상 어드레스에 대해 생성된 물리 어드레스가 보안 메모리 내에 있으면 그 디스크립터에 의해 특정된 물리 어드레스부를 내부 저장부가 억세스 제어정보로서 저장하는 것을 방지가능하도록 동작한다.
추가로, 가상 어드레스의 물리 어드레스로의 변환이 적어도 하나의 모드에서 일어나는 상기의 바람직한 실시예에서, 적어도 한 개의 테이블은, 보안 운영체계에서 발생된 디스크립터를 포함한 보안 메모리 내의 보안 테이블을 더 구비하고, 상기 메인 TLB는, 그 메인 TLB 내에 저장된 각 디스크립터와 관련된 플래그를 갖고서 그 디스크립터가 상기 비보안 테이블로부터의 것인지 상기 보안 테이블로부터의 것인지를 식별하게 한다.
대응한 디스크립터가 비보안 테이블 또는 보안 테이블로부터의 것인지를 나타내는 메인 TLB 내에 플래그를 포함함으로써, 프로세서의 동작이 보안 도메인과 비보안 도메인 사이에서 이동하거나, 이와는 반대로 이동하는 경우에, 메인 TLB를 플러시 할 필요가 없다. 억세스 제어정보가 메인 TLB 내의 디스크립터로부터 마이크로 TLB로 전달되는 경우, 프로세서가 동작하고 있는 현재의 도메인을 적절하게 나타낸 디스크립터들만 고안될 것이다. 따라서, 프로세서가 비보안 모드에서 동작하고 있어 비보안 도메인에 있으면, 비보안 테이블로부터의 관련된 플래그 표시를 갖는 메인 TLB에 있는 디스크립터들만은 마이크로 TLB에 전달되는 억세스 제어정보를 얻는 곳으로부터 후보 디스크립터들로서 재검토될 것이다.
이러한 바람직한 실시예에서, 마이크로 TLB는, 프로세서의 동작모드가 보안모드와 비보안 모드 사이에서 변화할 때마다 플러시되는 것이 바람직하고, 보안 모드에서 억세스 제어정보는 상기 관련 플래그 표시가 보안 테이블로부터 얻어지는 메인 TLB에 있는 디스크립터로부터 마이크로 TLB에 전달되기만 하고, 비보안 모드에서 억세스 제어정보는 상기 관련된 플래그 표시가 비보안 테이블로부터 얻어지는 상기 메인 TLB의 디스크립터로부터 마이크로 TLB에 전달되기만 한다. 일반적으로, 이 마이크로 TLB는 메인 TLB보다 상당히 작아서, 프로세서가 보안 도메인과 비보안 도메인 사이에서 이동할 때마다 마이크로 TLB의 플러싱은 성능에 관한 상당한 영향을 받지 않는다. 메모리 관리부에서 수행된 소정의 억세스 제어 기능이 마이크로 TLB에 있는 억세스 제어정보에 관하여 수행되기만 하므로, 상술한 메카니즘은, 프로세서의 동작의 임의의 특정한 모드에 대해, 반드시 마이크로 TLB가 적절한 메모리 테이블로부터 얻어진, 즉 프로세서가 비보안 모드에서 동작하고 있을 때 비보안 테이블로부터 또는, 프로세서가 보안 모드에서 동작하고 있을 때 보안 테이블로부터 얻어진 디스크립터들로부터 얻어진 억세스 제어정보만을 포함하도록 할 것이다.
모든 동작의 보안 모드들은 그들의 메모리 억세스 요구 내에서 적절하게 물리 어드레스를 특정하는 실시예들에서, 메인 TLB가 비보안 디스크립터들만을 저장하므로, 메인 TLB 내의 상기 플래그에 대한 필요성이 없을 것이라는 것을 알 것이다.
상기 메모리가, 다양한 형태를 취할 수 있고 데이터 처리장치 내의 다양한 장소에 위치될 수 있다는 것을 알 것이다. 메모리의 예로는, 예를 들면 랜덤 억세스 메모리(RAM), 판독전용 메모리(ROM), 하드디스크 드라이브, 밀결합 메모리(TCM), 1개 이상의 캐시, 주변장치 내에 설치된 다양한 레지스터 등과 같은 1개 이상의 다양한 소자들이 있고, 그 메모리 어드레스 범위는 이들 메모리의 다양한 소자들이 별도로 어드레스 될 수 있도록 하는 범위이다. 따라서, 일부의 실시예들에서 상기 메모리 중 적어도 일부는, 상술한 것처럼 디바이스 버스에 결합되어도 되고, 그 메모리 중 나머지 부분은 서로 다른 버스에 결합되어도 된다.
예를 들면, 일 실시예에서, 프로세서는 시스템 버스에 연결되고, 그 메모리 중 일부는 그 시스템 버스에 연결된 밀결합 메모리(TCM)을 구비한다. 당업자가 알 수 있듯이, 상기와 같은 TCM을 종종 사용하여 프로세서가 자주 사용한 데이터를 저장하는데, 그 이유는, 상기 시스템 버스를 통해 TCM에의 억세스가 외부 메모리, 예를 들면 디바이스 버스상의 메모리에의 억세스보다 상당히 빠르기 때문이다. 종종 TCM에 대한 물리 어드레스 범위는, 데이터 처리장치의 제어 레지스터 내에 정의가능하다. 그러나, 이것은, 이하의 예로 나타낼 수 있는 것처럼, 특정한 보안성 문제를 일으킬 수 있다.
프로세서가 비보안 모드에서 동작하고 있을 때, 비보안 운영체계는, 보안 메모리의 일부와 중첩하는 물리 어드레스 공간을 TCM 메모리로서 정의하기 위해서 그 제어 레지스터를 프로그래밍하게 하여도 된다. 연속적으로 프로세서가 보안 도메인에서 동작할 때, 보안 운영체계는 이러한 보안 메모리 부분에 보안 데이터를 저장되게 하고, 그 경우에, 보안 데이터는 일반적으로 외부 메모리라기보다는 오히려 TCM에서 저장될 것인데, 그 이유는 상기 TCM이 일반적으로 보다 높은 우선권을 가지기 때문이다. 그러나, 연속적으로 비보안 운영체계가 TCM의 물리 어드레스 범위의 설정을 다시 변경하여 이전의 보안 메모리 부분을 메모리의 비보안 물리영역에 매핑하는 경우, 그 비보안 운영체계는 보안 데이터를 억세스할 수 있다는 것을 알 것인데, 그 이유는 추가의 파티션 검사 로직부는 상기 영역을 비보안으로서 참조하고 취소를 어서트하지 않을 것이기 때문이다. 따라서, 요약하면, TCM이 통상의 로컬 RAM으로서 작용하고 스마트캐시로서 동작하지 않도록 구성되는 경우, 비보안 물리 어드레스로 TCM 기저 레지스터를 이동할 수 있는지를 비보안 운영체계가 보안계 데이터를 판독하는 것이 가능하기도 하다.
이러한 시나리오를 피하기 위해서, 바람직한 실시예들의 데이터 처리장치는, 특권을 가진 보안 모드에서 실행하는 경우만 프로세서에 의해 밀결합 메모리가 제어가능하거나, 또는 적어도 한개의 비보안 모드에서 실행하는 경우 프로세서에 의해 밀결합 메모리가 제어가능한지를 나타내기 위해서 특권을 가진 보안 모드에서 동작하는 경우 프로세서에 의해 설정가능한 제어 플래그를 구비하는 것이 바람직하다. 상기 제어 플래그는, 보안 운영 체계에 의해 설정되고, 사실상 TCM이 특권을 가진 보안 모드 또는 비보안 모드에 의해 제어되는지를 정의한다. 따라서, 정의되는 일 구성으로는, TCM이 프로세서가 동작의 특권을 가진 보안모드에서 동작하고 있는 경우만 제어된 것이 있다. 이러한 실시예들에서, TCM 제어 레지스터에 시도하려고 한 임의의 비보안 억세스에 의해, 선택되는 미정의된 명령어 예외가 생길 것이다.
다른 구성에서, TCM은 동작의 비보안 모드에서 동작하고 있을 때 프로세서에 의해 제어될 수 있다. 이러한 실시예들에서, TCM은 비보안 어플리케이션에 의해서만 사용된다. 보안 데이터는 TCM에 저장될 수 없거나 그 TCM으로부터 로딩될 수 없다. 따라서, 보안 억세스가 수행되는 경우, 상기 어드레스가 TCM 어드레스 범위와 일치하였는지를 참조하기 위해서 TCM 내에서 검색하지 않는다. 일 바람직한 실시예에서, TCM은, 비보안 운영체계에 의해서만 사용되도록 구성되고, 이것은, 비보안 운영체계가 변경될 필요가 없다는 이점을 갖는데, 그 이유는, 동작이 비보안 운영체계에 사용가능한 TCM에 의한 통상의 방법으로 진행하기 때문이다.
제 2 측면에 따른 본 발명은, 보안 도메인과 비보안 도메인을 갖는 데이터 처리장치에서의 메모리로의 억세스 제어방법을 제공하는 것으로, 보안 도메인에 있어서 상기 데이터 처리장치는 비보안 도메인에서 억세스 가능하지 않은 보안 데이터에 억세스하게 하고, 상기 데이터 처리장치는, 디바이스 버스와, 이 디바이스 버스에 연결되어 상기 보안 도메인 또는 상기 비보안 도메인에 관련된 메모리 억세스 요구를 발행가능하도록 동작하는 디바이스와, 상기 디바이스 버스에 연결되고, 상기 디바이스에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 메모리와 비보안 데이터 저장용 비보안 메모리로 이루어진 메모리를 구비하되, 상기 방법은, (i) 메모리에 있는 데이터 항목으로의 억세스를 필요로 하는 경우 상기 디바이스 버스 상에서 메모리 억세스 요구를 상기 디바이스로부터 발행하는 단계와, (ii) 상기 디바이스에서 발행한 것과 같은 상기 메모리 억세스 요구가 상기 비보안 도메인에 관련될 때마다 그 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출하기 위해 상기 디바이스에 연결된 파티션 검사 로직부를 사용하는 단계와, (iii) 상기 검출시에 상기 메모리 억세스 요구에서 특정된 억세스를 방지하는 단계를 포함한다.
본 발명의 또 다른 측면에 따른 데이터 처리장치는, 디바이스 버스와, 이 디바이스 버스에 연결되고, 비보안 도메인에서의 모드인 적어도 한개의 비보안 모드와, 보안 도메인에서의 모드인 적어도 한개의 보안 모드로 구성된 다수의 모드와 보안 도메인 또는 비보안 도메인에서 동작가능한 디바이스와, 상기 디바이스 버스에 연결되고, 메모리에 있는 데이터 항목으로의 억세스를 필요로 하는 경우 상기 디바이스 버스 상에서 메모리 억세스 요구를 발행가능하도록 동작하는 상기 디바이스에서, 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 메모리와 비보안 데이터 저장용 비보안 메모리로 이루어진 메모리와, 상기 디바이스 버스에 연결되고, 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때 상기 디바이스에서 메모리 억세스 요구를 발행할 때마다, 그 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출가능하도록 동작하고, 상기 검출시에 상기 메모리 억세스 요구에서 특정된 그 억세스를 방지하는 파티션 검사 로직부를 구비한다.
또 다른 측면에 따른 본 발명은, 데이터 처리장치에서의 메모리로의 억세스 제어방법을 제공하는 것으로, 상기 데이터 처리장치는 디바이스 버스와, 이 디바이스 버스에 연결되고, 비보안 도메인에서의 모드인 적어도 한 개의 비보안 모드와, 보안 도메인에서의 모드인 적어도 한개의 보안 모드로 구성된 다수의 모드와 보안 도메인 또는 비보안 도메인에서 동작가능한 디바이스와, 상기 디바이스 버스에 연결되고, 상기 디바이스에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 메모리와 비보안 데이터 저장용 비보안 메모리로 이루어진 메모리를 구비하고, 상기 방법은, (i) 메모리에 있는 데이터 항목으로의 억세스를 필요로 하는 경우 상기 디바이스 버스 상에서 메모리 억세스 요구를 상기 디바이스로부터 발행하는 단계와, (ii) 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때 상기 디바이스에서 메모리 억세스 요구를 발행할 때마다, 상기 디바이스 버스에 연결되어, 그 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출하는 파티션 검사 로직부를 사용하는 단계와, (iii) 상기 검출시에 상기 메모리 억세스 요구에서 특정된 그 억세스를 방지하는 단계를 포함한다.
본 발명에 대하여 첨부하는 도면에 도시된 실시예를 참조하여 예시적인 방법으로 설명한다.
도 1은 본 발명의 바람직한 실시예에 따른 데이터 처리 장치를 개략적으로 도시하는 블록도이며,
도 2는 비보안 도메인과 보안 도메인에서 동작하는 서로 다른 프로그램을 도시하는 개략도이며,
도 3은 서로 상이한 보안 도메인에 연관된 처리(processing) 모드의 행열을 도시하는 개략도이며,
도 4 및 5는 프로세싱 모드와 보안 도메인 사이의 상이한 관계를 도시하는 개략도이며,
도 6은 프로세싱 모드에 따른 프로세서의 레지스터 뱅크의 프로그래머 모델을 도시하며,
도 7은 보안 도메인과 비보안 도메인에 대한 각각의 레지스터 뱅크를 제공하는 예를 도시하는 예시도이며,
도 8은 각각의 모니터 모드를 통하여 수행되는 보안 도메인 사이의 스위칭과 관련된 다수의 프로세싱 모드를 도시하는 개략도이며,
도 9는 모드 스위칭 소프트웨어 인터럽트 명령어를 이용한 보안 도메인 스위칭의 과정을 도시하는 개략도이며,
도 10은 비보안 인터럽트 요구과 보안 인터럽트 요구가 시스템에 의하여 어떻게 되는지 예를 들어 도시하는 개략도이며,
도 11A 및 11B는 도 10에 의한 보안 인터럽트 요구 처리의 예와 비보안 인터럽트 요구 처리의 예를 도시하는 개략도이며,
도 12는 도 10에 도시된 것과 비교하여 비보안 인터럽트 요구 신호와 보안 인터럽트 요구 신호를 처리하는 다른 개요를 도시하는 개략도이며.
도 13A 및 13B는 도 12에 도시된 개요에 의한 비보안 인터럽트 요구 및 보안 인터럽트 요구를 처리하는 예시적인 과정을 도시하는 예시도이며,
도 14는 벡터 인터럽트 테이블의 예시도이며,
도 15는 서로 상이한 보안 도메인과 연관된 멀티 벡터 인터럽트 테이블을 예시하는 개략도이며,
도 16은 예외 제어 레지스터를 도시하는 개략도이며,
도 17은 보안 도메인 세팅을 변경하는 방식으로 프로세싱 상태 레지스터를 변경하는 명령어가 모니터 모드에 대한 진입을 발생시켜 모니터 프로그램을 실행시키는 개별 모드 변경 예외를 어떻게 발생시키는지 도시하는 흐름도이며,
도 18은 모니터 모드의 태스크가 인터럽트된 경우의, 다수의 모드에서 동작하는 프로세서의 제어 쓰레드(thread)를 도시하는 개략도이며,
도 19는 다수의 모드에서 동작하는 프로세서의 서로 다른 제어 쓰레드를 도시하는 개략도이며,
도 20은 모니터 모드에서 인터럽트가 활성화(enable)된 경우, 다수의 모드에서 동작하는 프로세서의 다른 제어 쓰레드를 도시하는 개략도이며,
도 21 내지 23은 제 2 실시예에 따른 보안 도메인과 비보안 도메인 사이의 스위칭에 관한 시나리오와 다른 프로세싱 모드의 관점을 도시하며,
도 24는 전통적인 ARM 코어에 보안 프로세싱 옵션을 부가하는 개념을 도시하는 개략도이며,
도 25는 보안 도메인과 비보안 도메인과 리셋을 구비하는 프로세서를 도시하는 개략도이며,
도 26은 소프트웨어 페이크(fake) 인터럽트를 이용하여 일시 중단된 운영체계에 프로세싱 요구를 전달하는 것을 도시하는 개략도이며,
도 27은 소프트웨어 페이크 인터럽트를 통하여 일시 중단된 운영체계에 프로세싱 요구를 전달하는 다른 예를 도시하는 개략도이며,
도 28은 도 26 및 27에서 생성된 것과 같은 종류의 소프트웨어 페이크 인터럽트를 수신한 경우의 처리 과정을 개략적으로 도시하는 흐름도이며,
도 29 및 30은 비보안 운영체계에 의하여 생성된 가능한 태스크 스위칭을 추적하기 위한 보안 운영체계에 의한 태스크를 도시하는 개략도이며,
도 31은 도 29 및 30의 보안 운영체계의 호출을 수신한 경우의 처리 과정을 개략적으로 도시하는 흐름도이며,
도 32는 서로 다른 운영체계에 의하여 다른 인터럽트들이 처리되는 다수의 운영체계를 갖는 시스템에서 발생할 수 있는 인터럽트 우선순위 역전의 문제점을 개략적으로 도시하는 개략도이며,
도 33은 도 32에 도시된 문제점을 피하기 위한 스텁(stub) 인터럽트 핸들러의 사용법을 개략적으로 도시한 개략도이며,
도 34는 서로 다른 종류와 다른 우선순위의 인터럽트들이 다른 운영체계를 사용하여 제공되는 인터럽트에 의하여 일시중단될 수 있는지 여부에 따라 어떻게 처리되는지 도시하며,
도 35는 프로세서가 모니터 모드에서 동작중일때 어떻게 모니터 모드에 특화된 프로세서 환경설정 데이터(configuration data)로 프로세서 조정 데이터를 덮어쓰는지 도시하며,
도 36는 본 발명의 제 1 실시예에 따른 보안 도메인과 비보안 도메인 사이의 전이시 어떻게 프로세서 조정 데이터가 스위칭되는지 도시하는 흐름도이며,
도 37은 본 발명의 제 1 실시예에서 메모리 억세스를 제어하기 위하여 사용되는 메모리 운영 로직을 도시하는 블록도이며,
도 38은 본 발명의 제 2 실시예에서 메모리 억세스를 제어하기 위하여 사용되는 메모리 운영 로직을 도시하는 블록도이며,
도 39는 본 발명의 제 1 실시예에 따른 가상주소를 지시하는 메모리 억세스 요구를 처리하기 위한 메모리 운영 로직 내에서 이루어지는 프로세서를 도시한 흐름도이며,
도 40은 본 발명의 제 1 실시예에 따른 물리주소를 지시하는 메모리 억세스 요구를 처리하기 위한 메모리 운영 로직 내에서 이루어지는 프로세서를 도시한 흐름도이며,
도 41은 바람직한 실시예의 파티션 체커(partition checker)가 메모리 억세스를 처리하려는 장치가 비보안 모드에서 동작중일때 보안 메모리 내부의 물리 주소에 대한 억세스를 방지하기 위하여 어떻게 동작하는지 개략적으로 도시하는 개략도이며,
도 42는 본 발명의 바람직한 실시예에 따른 비보안 페이지 테이블 및 보안 페이지 테이블 양자의 사용을 도시하는 블록도이며,
도 43은 바람직한 실시예의 주(main) 변환색인버퍼(TLB)에서 사용된 두가지 형태의 플래그를 도시한 블록도이며,
도 44는 본 발명의 제 1 실시예에서 부팅 단계 이후 메모리가 어떻게 파티션 나눠지는지를 도시하며,
도 45는 본 발명의 실시예에 따른 부트 파티션의 동작이후 메모리 운영 유니트에 의한 비보안 메모리의 매핑을 도시하며,
도 46은 본 발명의 실시예에 따른 보안 어플리케이션이 비보안 어플리케이션과 메모리를 공유하도록 메모리 일부의 권한이 어떻게 변경되는지를 도시하며,
도 47은 본 발명의 제 1 실시예에 따른 데이터 처리 장치의 외부 버스에 장치가 어떻게 접속하는지를 도시하며,
도 48은 본 발명의 제 2 실시예에 따른 외부 버스에 장치가 어떻게 커플링되는지 도시하는 블록도이며,
도 49는 단일한 페이지 테이블 셋이 사용되는 실시예에서 물리 메모리의 배열을 도시하며,
도 50A는 두개의 MMU가 매개주소를 이용하여 가상주소에서 물리주소로 변환되는 배열을 도시하며,
도 50B는 두개의 MMU가 매개주소를 이용하여 가상주소에서 물리주소로 변환되는 다른 배열을 도시하며,
도 51은 보안 도메인과 비보안 도메인의 물리 주소 공간과 매개 주소 공간(intermediate address space)의 일치여부를 예시적으로 도시하며,
도 52는 제 2 MMU와 연관된 페이지 테이블의 조작을 통한 보안 도메인과 비보안 도메인의 메모리 영역의 스와핑을 도시하며,
도 53은 주 TLB에서 놓치는 경우 가상에서 물리 주소로의 변환을 판단하기 위하여 발동되는 예외를 발생시키는 단일 MMU를 이용한 실시예를 도시하며,
도 54는 도 53의 MMU의 주 TLB에서 놓치는 경우 발생되는 예외을 처리하기 위하여 프로세서 코어에 의하여 수행되는 처리과정을 도시하는 흐름도이며,
도 55는 일 실시예에 따른 데이터 처리 장치 내부에 제공되는 부재를 도시하는 블록도로서, 캐쉬는 개별 캐쉬 라인에 저장되는 데이터가 보안 데이터인지 비보안 데이터인지 나타내는 정보를 제공받으며,
도 56은 도 55에 도시된 메모리 운영 유니트의 구성을 도시하며,
도 57은 도 55의 데이터 처리 장치 내부에서 비보안 메모리 억세스 요구를 처리하기 위하여 수행되는 처리과정을 도시하는 흐름도이며,
도 58은 도 55의 데이터 처리 장치 내부에서 보안 메모리 억세스 요구를 처리하기 위하여 수행되는 처리과정을 도시하는 흐름도이며,
도 59는 프로세서에서 수행되는 서로 다른 모드와 어플리케이션을 위한 모니터링 함수의 가능한 입상(granularity)를 도시하는 개략도이며,
도 60은 상이한 모니터링 함수를 구동하는 가능한 방법들을 도시하며,
도 61은 상이한 모니터링 함수를 제어가능한 제어 값의 테이블을 도시하며,
도 62는 포지티브 엣지 트리거드 플립플롭(positive-edge triggered FILP FLOP)을 도시하며,
도 63은 스캔 체인 셀(scan chain cell)을 도시하며,
도 64는 스캔 체인 내의 다수의 스캔 체인 셀을 도시하며,
도 65는 디버그 TAP 콘트롤러를 도시하며,
도 66A는 JADI 입력을 구비한 디버그 TAP 콘트롤러를 도시하며,
도 66B는 바이패스 레지스터를 구비한 스캔 체인 셀을 도시하며,
도 67은 코어, 스캔 체인 및 디버그 상태/제어 레지스터를 구비한 프로세서를 도시한 개략도이며,
도 68은 디버그 또는 트레이스 초기화를 제어하는 인자를 개략적으로 도시하는 개략도이며,
도 69A 및 69B는 디버그 입상을 요약하여 도시하며,
도 70은 디버그의 실행중 디버그의 입상을 도시하는 개략도이며,
도 71A 및 71B는 보안계에서 디버그가 활성화된 경우와 비활성화된 경우 각각의 모니터 디버그를 도시한다.
도 1은 본 발명의 바람직한 실시예에 따른 데이터 처리 장치를 도시하는 블록도이다. 데이터 처리장치는 일련의 명령어를 처리하기 위한 산술논리연산장치(ALU) 16를 구비한 프로세서 코어 10를 포함한다. ALU 16에 필요한 데이터는 레지스터 뱅크 14에 저장된다. 코어 10는 프로세서 코어의 활동을 나타내는 진단(diagnostic) 데이터가 수집되는 것을 활성화 할 수 있는 다수의 모니터링 함수를 포함한다. 예를들어, 엠베디드 트레이스 모듈(ETM) 22은 어떤 활동이 추적(trace)될 것인지 결정하는 ETM 22내부의 제어 레지스터의 내용에 따라 프로세서 코어에 대한 실시간 추적을 제공한다. 트레이스 신호는 전형적으로 이들이 순서대로 분석 될 수 있는 트레이스 버퍼의 출력이다. 다양한 주변장치(미도시)에 의하여 발생할 수 있는 다수의 인터럽트의 처리를 수행하기 위하여 벡터 인터럽트 콘트롤러 21가 제공된다.
나아가, 도 1에 도시된 바와 같이, 코어 10 내부에 제공되는 다른 모니터링 함수는 디버그 함수 일 수 있는데, 데이터 처리 장치 외부의 디버깅 어플리케이션이 하나 또는 그 이상의 스캔 체인 12와 커플링된 제이태그(Joing Test Access Gropup : JTAG) 콘트롤러 18를 통하여 상기 코어 10와 통신할 수 있다. 프로세서 코어 10의 여러 부분의 상태에 관한 정보는 스캔 체인 12와 제이태그 콘트롤러 18을 통해 외부 디버깅 어플리케이션으로 출력될 수 있다. 인서킷에뮬레이터(ICE) 20은 레지스터 24 없이 디버그 기능이 시작되거나 종료될 때를 인지하면서 상태를 저장할 때 사용되므로, 예를 들어 브레이크 포인트, 왓치 포인트 등을 저장하는데 사용될 것이다.
코어 10은 데이터 프로세싱 장치의 메모리 안의 위치에 억세스하기 위한 코어 10에 의해 요구된 메모리 억세스 요구를 관리하기 위해 준비된 메모리 관리 로직 30을 통해 시스템 버스 40에 연결된다. 단단히 연결된 메모리(TCM) 36과 도 1에 설명된 캐쉬 38과 같은 메모리의 특정 부분은 시스템 버스 40에 직접적으로 연결된 메모리 유닛들에 의해 수록될 것이다. 직접 메모리 억세스(DMA) 콘트롤러 32와 같은 추가적인 디바이스들 또한 이러한 메모리를 억세스하기 위해 제공될 것이다. 대표적으로, 여러 개의 제어 레지스터 34는 칩의 다양한 소자들을 특정한 제어 파라미터를 정의하기 위해 제공될 것이며, 이러한 제어 레지스터들도 이 문서에 보조처리기 15(CP15) 레지스터로써 언급될 것이다.
코어 10을 포함하고 있는 칩은 외부 버스 인터페이스 42를 통해 외부 버스 70(예를 들어 ARM사에 의해 개발된 “어드밴스 마이크로콘트롤러 버스 구조”(AMBA)의 명세에 따라 작동되는 버스)에 연결될 것이고, 여러 디바이스들도 외부 버스 70에 연결 될 것이다. 이러한 디바이스들에는 디지털 신호 프로세서(DSP) 50이나 직접 메모리 억세스(DMA) 컨트롤러 52와 같은 마스터 디바이스와 부트 롬 44, 화면 드라이버 46, 외부 메모리 56, 입출력(I/O) 인터페이스 60 혹은 키 스토리지 유닛 64와 같은 슬래이브 디바이스가 포함될 것이다. 도 1에 설명된 다양한 슬래이브 디바이스들도 또한 완전히 데이터 프로세싱 장치의 전체 메모리에 통합된 부분으로 간주될 수 있다. 예를 들어, 부트 롬 44 데이터는 외부 메모리 56의 경우와 같이 프로세싱 장치의 주소지정 가능 메모리의 일부를 형성할 것이다. 더 나아가, 화면 드라이버 46, 입출력 인터페이스 60 및 키 스토리지 유닛 64와 같은 디바이스들은, 데이터 프로세싱 장치의 전체 메모리의 일부분으로서 완전히 독자적인 주소지정이 가능한 일부 레지스터 혹은 48, 62, 66 버퍼와 같은 내부 스토리지 소자들을 각각 포함할 것이다. 차후 상세히 논의될 것처럼, 메모리의 일부, 즉 외부 메모리 56의 일부는 메모리 억세스의 제어와 관련된 정보들을 정의하는 페이지 테이블 58을 저장하는데 사용될 것이다.
당업자의 평가에 따르면, 전형적으로 외부 버스 70은 코어 10, DMA 32, DSP 50, DMA 52 등과 같은 다중 마스터 디바이스들에 의해 생성되는 다중 메모리 억세스 요구들 간의 중재에 활용되는 아비터와, 외부 버스의 어느 슬래이브 디바이스가 특정 메모리 억세스 요구를 처리할 것인지를 결정하는데 사용되는 디코더 로직 54를 제공할 것이다.
어떤 구현에서는 외부 버스가 코어 10을 보유한 칩에 외부적으로 제공되는 반면에, 다른 구현에서는 외부 버스가 코어 10과 함께 칩 안에 제공될 것이다. 이것은 외부 버스가 칩의 외부에 있을 때와 비교하여 외부 버스상의 보안 데이터의 보안 유지가 용이하다는 장점을 갖는다. 외부 버스가 칩 외부에 있을 때에는 보안 데이터의 보안성 증가를 위해 데이터 암호화 기술이 사용될 것이다.
도 2는 보안 도메인과 비보안 도메인을 가진 프로세싱 시스템 상에서 작동되는 여러 프로그램들에 대해 설명하고 있다. 이 시스템에는 최소한으로 모니터 모드에서 부분적으로 작동하는 모니터 프로그램 72를 제공한다. 이와 같은 구현의 예에서, 보안 상태 플래그는 단지 모니터 모드 안에서만 기록 억세스가 가능하며 모니터 프로그램 72에 의해 기록될 것이다. 모니터 프로그램 72는 보안 도메인과 비보안 도메인 사이에서 각각의 방향의 모든 변화를 관리하는 책임을 진다. 코어를 향한 외부 관점으로부터 모니터 모드는 항상 안전하며, 모니터 프로그램은 보안 메모리 안에 존재한다.
비보안 도메인 안에 비보안 운영 체제 74와, 비보안 운영 체제 74와 함께 운영되는 다수의 비보안 어플리케이션 프로그램 76, 78이 제공된다. 보안 도메인에는 보안 커널 프로그램 80이 제공된다. 보안 커널 프로그램 80은 보안 운영 체제를 형성하는 것으로 이해될 수 있다. 전형적으로 보안 커널 프로그램 80과 같은 프로그램은 보안 도메인에서 반드시 제공되어야 하는 프로세싱 액티비티에 필수적인 기능 들만을 제공하기 위해 설계된다. 따라서 보안 커널 80은 가능한 작고 간단해야 하는데, 왜냐하면 이렇게 함으로써 더욱 안전한 처리가 가능하기 때문이다. 보안 커널 80과의 결합의 형태로 수행되는 다수의 보안 어플리케이션 82, 84가 설명되어 있다.
도 3은 다른 보안 도메인과 연관된 프로세싱 모드의 매트릭스에 관해 설명하고 있다. 이러한 상세 예제에서 프로세싱 모드는 보안 도메인과 관련하여 대칭적이며, 따라서 모드1과 모드2는 보안형식과 비보안 형식의 두 가지로 존재한다.
모니터 모드는 시스템에서 보안 억세스의 최고 수준을 보유하며 이러한 예에서 구현은 비보안 도메인과 보안 도메인 사이에서 각자 방향으로의 시스템 변환이 가능한 유일한 모드이다. 따라서 모든 도메인 변환은 모니터 모드로의 전환과 모니터 모드 하에서의 모니터 프로그램 72의 실행에 의해서 발생한다.
도 4는 비보안 도메인 프로세싱 모드 1, 2, 3, 4와 보안 도메인 프로세싱 모드 a, b, c의 또다른 설정에 관해 도식적으로 설명한다. 도 3의 대칭 배열과는 반대로, 도 4는 어떤 프로세싱 모드의 경우 한개 혹은 그 이상의 보안 도메인에서 나타나지 않음을 보여준다. 모니터 모드 86이 비보안 도메인과 보안 도메인의 양쪽에 걸쳐 있는 것으로 재차 설명되고 있다. 모니터 모드 86는, 보안 상태 플래그가 이 모드에서 변경되며 모니터 모드 하의 모니터 프로그램 72가 스스로가 보안 상태 플래그를 설정할 수 있는 능력을 가지고 있으므로, 보안 프로세싱 모드로 간주될 수 있다. 이는 시스템 안에서 효과적으로 최후 수준의 전체적인 보안을 제공한다.
도 5는 보안 도메인에 따른 프로세싱 모드의 또 다른 배치를 설명하고 있다. 이배치에서는 보안과 비보안 도메인들이 기타 나머지 도메인과 함께 확인되고 있다. 기타 도메인이란 설명되어 있는 보안과 비보안 도메인들과 서로 영향을 미치지 않고 연관성이 없도록 다른 시스템과 격리되어있음을 말한다.
프로세싱 시스템이 그렇듯이 마이크로프로세서는 보통 레지스터 뱅크 88과 함께 공급되며 피연산자 값이 저장된다. 도 6은 특정한 레지스터 번호와 특정한 프로세싱 모드를 위한 전담 레지스터들의 실례의 레지스터 뱅크의 프로그래머의 모델 뷰를 도시하고 있다. 또한 도 6의 예는 전용으로 저장된 프로그램 상태 레지스터, 전용 스택 포인터 레지스터 및 각각의 프로그램 모드 전용의 링크 레지스터 R14와 함께 제공되는 유명한 ARM 레지스터 뱅크 (잉글랜드 캠브리지의 ARM 사의 ARM7 프로세서가 제공되듯이)의 연결선이나 이번에는 모니터 모드의 공급과 연결되어있다. 도 6에서 도시된 바와 같이 신속한 인터럽트 모드는 실행되었을 때 다른 모드로부터 레지스터 문맥을 저장하고 재 저장 할 필요가 없게끔 여분의 지정된 레지스터를 가지고 있다. 모니터 모드는 지정된 다른 레지스터들과 비슷한 방법으로 신속한 인터럽트 모드가 보안 도메인 스위치의 빠른 프로세싱과 이 스위치들의 대기시간을 줄일 수 있도록 한다.
도 7에서는 레지스터 뱅크 88이 각각 보안과 비보안 도메인에 사용되는 완벽하고 분리된 두 가지 형태의 또 다른 구체화를 도시하고 있다. 이것은 보안 도메인 안에서 작동중인 레지스터에 저장되어 있는 보안 데이터가 안전하지 않은 도메인으로 변경되었을 때 억세스를 방지할 수 있게 하는 하나의 방법이다. 그러나 이러한 구성은 보안 도메인과 비보안 도메인 모두에 억세스할 수 있는 레지스터 안에 빠르 고 효율적인 메커니즘을 이용하여 비보안 도메인에서 보안 도메인으로 데이터를 옮기는 가능성을 지연시킨다.
보안 레지스터 뱅크 소유가 갖는 한가지 중요한 장점은 하나의 계(world)에서 다른 계로 스위칭 하기 전에 레지스터의 문맥(context)의 일부분을 비우는 동작이 필요한 상황을 모면할 수 있다는 것이다. 지연(latency)이 중대한 문제가 아닐 경우에는 도 6의 예와 같이 보안 도메인 계를 위한 복제 레지스터를 미보유한 간단한 하드웨어 시스템이 사용될 것이다. 모니터 모드는 하나의 도메인에서 다른 도메인으로의 스위칭에 관해 책임이 있다. 레지스터의 일부 소거뿐만 아니라 문맥의 복원, 이전 문맥의 저장 등은 적어도 일부분은 모니터 모드에서 실행되는 모니터 프로그램에 의해 작동된다. 그러므로 이 시스템은 마치 가상 모형처럼 작동된다. 이와 같은 실시예는 이 글의 뒷부분에 언급되어 있다. 예를 들자면 여기에 설명된 보안의 특징들이 생성되어 질 때 ARM7의 프로그램 모델이 참고될 수 있다.
프로세서 모드
보안계의 모드를 복사하기 전에 같은 모드가 보안과 비보안 도메인을 함께 지원한다.(도 8 참조) 모니터 모드가 그것이 보안이든 비보안이든 현재의 코어 상태를 인식한다. (예: S에서 읽은 저장 비트는 코프로세서 설정 레지스터다)
도 8에서는 SMI(소프트웨어 모니터 인터럽트 명령어)이 발생할 때마다 코어가 하나의 계에서 다른 계로 제대로 이동하기 위해 모니터 모드로 들어간다.
SMI가 사용자 모드로부터 허가된 도 9를 참고하면:
1. 스케쥴러가 쓰레드 1을 실행시킨다.
2. 쓰레드 1이 보안 기능을 실행한다 => SMI 보안이 작동되며 코어가 모니터 모드로 들어간다. 하드웨어 컨트롤 안에서 현재의 PC와 CPSR (현재 프로세서 상태 레지스터)가 R14_mon 안에 저장되며 SPSR_mon (모니터 모드를 위해 저장된 프로세서 상태 레지스터)와 IRQ/FIQ 인터럽트가 사용 금지된다.
3. 모니터 프로그램이 다음 사항들을 실행시킨다:
- S 비트가 정해진다 (보안 상태 플래그)
- 보안 어플리케이션이 실행될 때 비보안 문맥이 사라지지 않도록 R14_mon 과 SPSR_mon을 저장한다.
- 실행할 새로운 쓰레드가 있는지 확인 한다: 보안 쓰레드 1. 메카니즘 (몇몇 예의 통합체에서 쓰레드 아이디 테이블을 통해)은 쓰레드 1이 보안계에서 수행중임을 보여준다.
- IRQ/FIQ의 인터럽트가 재가동 된다. 보안 어플리케이션이 보안 사용자 모드로 실행될 수 있다.
4. 보안 쓰레드 1의 실행이 끝난후에 모니터 프로그램 모드 의 "보안으로부터의 복귀" 기능으로 분리된다. (코어가 모니터 모드에 들어갈 때 IRQ/FIQ 방해가 불가능해진다.)
5. "보안으로부터의 복귀"의 기능은 다음과 같은 업무를 수행한다:
- 보안 쓰레드 1의 끝남을 알린다. (예: 쓰레드 아이디 테이블에서 tread 1을 삭제한다.)
- 스택 비보안 문맥을 복구시키며 필요한 레지스터들을 분출함으로 비보안 도메인으로 돌아왔을 때 보안 데이터가 읽히지 않게 한다.
- SUBS 명령어과 함께 비보안 도메인으로 돌아오며 (이것으로 알맞은 포인트로 프로그램 카운터를 재저장하고 상태 플래그가 업데이트된다) PC (R14_mon 으로부터 저장된)와 CPSR (SPSR_mon으로부터 저장된)이 재저장된다. 그러므로 비보안 도메인의 복귀 포인트가 그전에 실행되었던 쓰레드 1 안의 SMI의 뒤에오는 명령어 이다.
6. 쓰레드 1이 끝까지 실행되며 스케쥴러로 넘어간다.
위에 설명된 기능들 중에서 몇 개는 특징적인 구현에 따라 모니터 프로그램과 보안 작동 시스템으로 나뉘어 진다.
그 밖의 다른 구현들은 사용자 모드에서 SMI들이 허가되지 않게 하도록 한다.
보안계 진입
리셋
하드웨어 리셋이 일어날 때, MMU가 사용불가 상태가 되고 ARM 코어 (프로세서)가 S 비트 세트와 함께 보안 감독자 모드로 분리된다. 보안 부트가 실행되었을 때 모니터 모드로 가야하는 SMI이 실행되며, 원한다면 모니터는 비보안계 (비보안 서비스 모드)의 OS로 바뀔 수 있다. OS가 사용되길 원한다면 간단히 보안 감독자 모드 안에서 부팅하며 보안 상태를 무시할 수 있다.
SMI 명령어
이 명령어(소프트웨어 인터럽트 명령어로 바꾸는 모드)은 비보안 도메인(전에서도 말했듯이 SMI를 특권을 가진 모드로 제한하는 것이 바람직하다)의 어떤 비보안 모드로부터 가져올 수 있지만 연관된 벡터가 지정한 타겟 입장 포인트는 항상 조정되어 있어야 하며 모니터 모드 안에 있어야한다. 실행되어야하는 알맞은 보안기능은 SMI 핸들러의 분리에 달려있다. (예: 명령어와 전달된 피연산자가 제어한다)
매개변수를 비보안계에서 보안계로 전달하는 일은 도 6 타입의 레지스터 뱅크 안에 속해있는 레지스터 뱅크의 공용 레지스터들을 사용하여 이루어진다.
비보안계에서 SMI가 일어날 경우 ARM 코어는 하드웨어 안에서 다음의 액션들을 실행한다 :
- 모니터 모드로 들어가며 SMI 벡터로 분리된다. (모니터 모드에 있기 때문에 보안 메모리 억세스가 허락된다)
- PC가 R14_mode 로 CPSR이 SPSR_mon로 저장된다.
- 모니터 모드를 이용함으로 S 비트가 세팅된다.
- 모니터 모드 안의 보안 예외 핸들러가 실행되기 시작한다.(멀티-쓰레드 케이스의 문맥이 저장 또는 재저장 된다.
- 알맞은 기능을 실행하기 위해 보안사용자 모드 (또는 서비스 모드와 같은 또 다른 모드)로 분리된다.
- 코어가 모니터 모드에 있음과 동시에 IRQ와 FIQ가 사용불가 된다. (지연시간이 길어진다)
보안계 퇴거
보안계를 빠져나가는 경우는 두 가지가 있다:
- 보안 기능이 끝나면 기능을 실행시켰던 그전의 비보안 모드로 돌아간다.
- 보안 기능은 비보안 예외의 인터럽트를 받는다 (예: IRQ/FIQ/SMI).
보안 기능의 정상 종료
보안 기능이 정상적으로 끝나면 우리는 SMI가 끝나자마자 비보안계 안의 어플리케이션을 재 시작한다. 보안 사용자 모드에서 "보안 상태부터의 복귀"의 루틴에 맞는 매개변수들과 함께 모니터 모드로 돌아올 수 있게 SMI 명령어가 실행된다. 이 단계에서 레지스터들은 비보안과 보안계안에서 데이터 누수를 방지하기 위해 일부분을 비우는 작업을 수행하며, 그다음에 비보안 문맥 일반적인 목적의 레지스터들은 재 저장되고 비보안 뱅크화 레지스터 들은 비보안계에서 가졌던 값으로 업데이트 된다. R-14_mon 과 SPSR_mon은 'MOVSPC,R14' 명령어를 실행시킴으로 SMI 다음의 비보안 어플리케이션으로 돌아올 수 있도록 그후 알맞은 값을 갖게 된다.
비보안 예외로 생긴 보안 기능의 종료
이러한 경우에는 보안 기능이 끝나지 않았으며 보안 문맥은 처리되어야할 인터럽트가 무엇이던 간에 비보안 예외 핸들러로 가기 전에 저장되어야 한다.
보안 인터럽트
보안 인터럽트는 몇 가지 경우에 발생한다.
가능한 두 가지 해결책은 다음의 경우에 따라 결정된다.
- 인터럽트의 종류 (보안 또는 비보안)
- IRQ가 일어날 때 코어가 있는 모드 (보안 또는 비보안계 )
해결책 하나
이 해결책에서는 보안과 비보안 인터럽트를 지원하는 상반되는 두개의 핀이 필요하다.
비보안계에 있는 경우는 다음과 같다:
- IRQ가 발생하며 코어는 인터럽트를 처리하기위해 ARM 코어 안의 ARM7과 같이 IRQ 모드로 간다.
- SIRQ가 발생하며 코어는 비보안 문맥을 저장하기위해 모니터 모드로 간다음 보안 인터럽트응 처리하기 위해 보안 IRQ 핸들러로 간다.
보안계에 있는 경우는 다음과 같다:
- SIRQ가 발생하며 코어는 보안 IRQ 핸들러로 간다. 코어는 보안계를 벗어나 지 않는다.
- IRQ가 발생하며 코어는 보안 문맥이 저장되어 있는 모니터 모드로 간 다음 비보안 인터럽트들을 처리하기위해 비보안 IRQ 핸들러로 간다.
다시 말하자면, 현재의 계에 속한 인터럽트가 아니라면 코어는 곧바로 모니터 모드로 들어가거나 현재의 계를 벗어나지 않는다. (도10 참조)
보안계 안에서 생기는 IRQ
도 11A 참조:
1. 스케쥴러가 쓰레드 1을 실행시킨다.
2. 쓰레드 1이 안전 기능을 실행 한다. => SMI 보안 콜, 코어가 모니터 모드로 들어간다. 현재의 PC 와 CPSR 이 R14_mon 과 SPSR_mon 에 저장되며 IRQ/FIQ가 사용이 불가능하게 된다.
3. 모니터 핸들러(프로그램)가 다음의 일을 실행 한다:
- S 비트가 결정된다.
- 보안 어플리케이션이 실행되는 동안 예상치 못한 문제로 인하여 비보안 문맥이 사라지는 경우를 방지하기위해 R14_mon and SPSR-mon이 같은 곳에 저장된다 (다른 레지스터들도 들어가는 경우가 있다).
- 실행되어야 할 새로운 쓰레드가 있는지 확인한다: 보안 쓰레드 1. 메카니즘 (쓰레드 아이디 테이블을 통한)은 쓰레드 1이 보안계에서 활성중 이라는 뜻이다.
- 보안 어플리케이션 이 그후에 보안 사용자 모드에서 실행될 수 있다. IRQ/FIQ 가 재활성화된다.
4. IRQ는 쓰레드 1이 실행중 일때 발생한다. 코어는 곧바로 모니터 모드 (특수 벡터)로 들어가고 R14_mon안의 현재의 PC와 SPSR-mon 안의 CPSR을 모니터 모드 안에 저장 시킨다 (IRQ/FIQ가 사용불가 된다).
5. 보안 문맥은 반드시 저장되어야 하며 그전의 비보안 문맥은 재저장 된다. 모니터 핸들러는 R14_irq/SPSR_irq를 알맞은 값으로 업데이트 하기위해 IRQ 모드로 바뀐다음 컨트롤을 비보안 IRQ 핸들러로 넘긴다.
6. IRQ 핸들러가 IRQ 서비스를 한다음 비보안계 안에있는 쓰레드 1을 컨트롤한다. SPSR_irq 와 R14_irq를 CPSR과 PC에 재저장함으로 쓰레드 1은 인터럽트된 적있는 SMI 명령어를 가르키게 된다.
7. SMI 명령어가 재실행된다. (명령어 2와 같음).
8. 모니터 핸들러가 인터럽트된 적 있는 쓰레드를 인식하며 쓰레드 1 문맥을 재저장 한다. 사용자 모드 안에 있는 보안 쓰레드 1으로 분리되며 인터럽트된 적 있는 명령어를 가르친다.
9. 보안 쓰레드 1이 끝까지 실행되며 모니터 모드 안에 있는 '보안으로의 복귀' 기능으로 분리 된다. (전문 SMI).
10. '보안으로의 복귀' 기능이 다음과 같은 일을 한다:
- 쓰레드1이 끝남을 알린다. (예: 쓰레드 ID 테이블의 경우 쓰레드 1을 테이블에서 삭제한다).
- 비보안계로 돌아왔을 때 보안 데이터가 읽혀지게 비보안 문맥으로부터 재저장되며 필요한 레지스터들을 분출시킨다.
- PC (R14_mon으로부터 재 저장된) 와 CPSR (SPSR_mon으로부터)을 재저장하며 SUBS 명령어 과 함께 비보안계로 다시 분리된다. 그러므로 비보안계의 회기 포인트는 쓰레드1 에 있는 실행되었던 SMI 다음의 명령어가 되어야한다.
11. 쓰레드1이 끝까지 실행되며 그 후 스케쥴러에서 제어한다.
비보안계에서 실행되는 SIRQ
도 11B를 참조:
1. 스케쥴러가 쓰레드1을 실행시킨다
2. 보안 쓰레드1이 실행되는 동안 SIRQ가 발생한다. 코어가 곧바로 모니터 모드 (구체적인 벡터)로 들어가며 R14_mon에 있는 현재의 PC 와 SPSR_mon에 있는 CPSR을 모니터 모드안에 저장하며 IRQ/FIQ가 비활성화 된다.
3. 비보안 문맥이 저장되어야 하며 코어가 보안 IRQ 핸들러로 간다.
4. IRQ 핸들러가 SIRQ를 서비스 한 다음, 알맞은 매개변수의 SMI을 이용하여 모니터 모드 핸들러에게 컨트롤을 준다.
5. 모니터 핸들러가 비보안 문맥을 재저장하여 SUBS 명령어는 코어가 비보안계 로 회기할 수 있게 하고 인터럽트된 쓰레드1을 재개 한다.
6. 쓰레드1이 끝까지 실행된 다음 스케쥴러에게 넘어 간다
도 11A의 메카니즘은 보안계로 들어가는 결정적인 방법이란 장점을 가지고 있다. 그러나, 거기엔 인터럽트 우선권에 관한 몇 가지 문제점이 있다: 예)SIRQ가 보안 인터럽트 핸들러 에서 실행되고 있을 때 높은 우선순위를 가진 IRQ가 발생할 수 있다. 비보안 IRQ가 끝나면 코어가 보안 인터럽트를 재개 할 수 있도록 SIRQ 가 재 생성되어야 한다.
해결책 둘
이 메카니즘에서는 (도 12 참조) 두 가지 전혀다른 핀 또는 한개가 보안과 비보안 인터럽트를 지원한다. 두개의 핀을 가지고 있음으로써 인터럽트 지연을 줄일 수 있다.
비보안계에 있는 경우는 다음과 같다:
-IRQ가 발생하며 코어는 ARM7 시스템과 같은 인터럽트를 처리하기위해 IRQ로 간다.
-SIRQ가 발생하며 코어는 SMI 명령어가 비보안 문맥을 저장하기 위함과 보안 인터럽트를 처리하기 위해 모니터 모드를 코어 브랜치로 만들며 IRQ 핸들러로 간다.
보안계에 있는 경우는 다음과 같다:
-SIRQ가 발생하며 코어가 보안 IRQ 핸들러로 간다. 코어는 보안계를 떠나지 않는다.
-IRQ가 발생하며 코어는 SMI 명령어가 코어 브랜치를 모니터 모드(보안 문맥 은 저장된다)로 만드는 보안 IRQ 핸들러로 가고 이 비보안 인터럽트를 처리하도록 비보안 IRQ 핸들러로 간다.
보안계 안에서 발생하는 IRQ
도 13A 참조:
1. 스케쥴러가 쓰레드1을 실행한다.
2. 쓰레드 1 보안 기능을 실행시켜야한다 => SMI 보안 은 R14_mon과 SPRP_mon에 저장되며 IRQ/FIQ가 사용 불가능하게 된다.
3. 모니터 핸들러가 다음의 일들을 한다:
-S 비트를 초기화 한다.
-보안 어플리케이션이 실행되는 동안 비보안 문맥이 지워지지 않게 함께 있는 R14_mon 과 SPSR_mon이 (결국엔 모든 레지스터 들이) 저장된다.
-실행될 새로운 쓰레드가 있는지 확인한다: 보안 쓰레드 1. 메카니즘은 (쓰레드 ID 테이블을 통한) 쓰레드1이 보안계에서 활동 중인지를 보여준다.
-보안 어플리케이션 이 보안 사용자 모드에서 시작할 수 있다. IRQ/FIQ가 재활성화 된다.
4. 보안 쓰레드1이 실행될 때 IRQ가 발생한다. 코어가 곧바로 보안 IRQ 모드로 들어간다.
5. 코어가 R14_irq 안에 있는 현재의 PC와 SPSR_irq에 있는 CPSR을 저장한다. IRQ 핸들러는 이것을 비보안 인터럽트로 인식하고 SMI 가 알맞은 매개변수s와 함께 모니터 모드로 들어가게 한다.
6. 보안 문맥이 반드시 저장되어야 하고 그전의 비보안 문맥이 재저장 된다. 모니터 핸들러는 CPSR을 읽음으로 SMI가 어디서 왔는지 알수 있다. 그리고 그것은 IRQ mode로 가서 R14_irq/SPSR_irq를 읽음으로 알맞은 보안 문맥을 저장한다. 또한 그것은 IRQ 루틴이 끝날 때 재저장 되어야 하는 비보안 문맥안의 같은 레지스터들을 저장한다.
7. IRQ 핸들러는 IRQ를 서비스 하고 비보안계 안에 있는 쓰레드1에게 컨트롤을 준다. CPSR과 PC안에 있는 SPSR_irq와 R14_irq를 재저장함으로 코어가 인터럽트 받은 적 있는 SMI 명령어를 가르킨다.
8. SMI 명령어가 재실행된다 (2와 같은 명령어).
9. 모니터 핸들러는 이 쓰레드를 인터럽트받을 적이 있는지를 보고 쓰레드1 문맥을 재저장한다. 그런 다음 사용자 모드안의 보안 쓰레드1으로 분리되며 인터럽트된 명령어를 가르킨다.
10. 보안 쓰레드1 이 끝까지 실행되며 모니터 모드안에 있는 "보안으로 복귀" 기능으로 분리된다.
11. "보안으로 복귀" 기능은 다음의 일들을 한다:
- 보안 쓰레드 1이 끝남을 알린다. (예: 쓰레드 ID 테이블 와 같은 경우, 쓰레드1을 테이블로부터 분리한다)
- 비보안 문맥으로부터 재저장하고 비보안계로 돌아왔을 때 보안 정보를 읽어지지 않게 필요한 레지스터들이 분출되게 한다.
- PC (R14_mon에서 재저장된)와 CPSR (SPSR_mon 으로부터)가 재저장되며 SUBS 명령어와 함께 비보안계로 다시 분출되었다. 비보안 계안의 리턴 포인트는 쓰레드1 안에서 실행되었던 SMI 다음의 명령어가 되어야 한다.
12. 쓰레드1 이 끝까지 실행되며 스케쥴러에게 넘어간다.
비보안계에서 발생하는 SIRQ
도 13B 참조:
1. 스케쥴러가 쓰레드1을 실행한다
2. 쓰레드1이 실행하는 동안 SIRQ가 발생한다
3. 코어가 곧바로 irq mode 로 들어가고 R14_irq 안에 있는 현재의 PC와 SPSR_irq에 있는 CPSR이 저장된다. 그다음 IRQ 는 사용 불가능하게 된다. IRQ 핸들러는 이것이 SIRQ 인지를 확인하고 알맞은 매개변수들과 함께 SMI 명령어를 실행한다.
4. 모니터 모드에 있을때 비보안 문맥은 저장되어야 하며 코어는 보안 IRQ 핸들러로 간다.
5. 보안 IRQ 핸들러는 SIRQ의 정기적 서비스를 서비스한다음 알맞은 매개변수들을 가지고 있는 SMI를 모니터하는 능력을 다시 부여받는다.
6. 모니터 핸들러 는 비보안 문맥을 재저장함으로 SUBS 명령어는 코어가 비보안계로 다시 돌아오게 하고 인터럽트 IRQ 핸들러가 재작동 하게한다.
7. IRQ 핸들러 가 SUBS를 실행함으로 비보안 쓰레드로 돌아올수있다.
8. 쓰레드 1 이 끝까지 실행되며 스케쥴러에게 넘어간다.
도12에 나와 있는 메커니즘에는 집합적인 인터럽트가 일어나는 경우에 SIRQ를 재생성할 필요가 없지만 보안 인터럽트들이 실행될 거란 보장은 없다.
예외 벡터
최소한 두개의 물리적 벡터 테이블들이 저장된다. (실질적으로 싱글 벡터 테이블로 보일수 있다). 하나는 비보안 메모리 안에 있는 비보안계와 또 하나는 보안 메모리 안에 있는 보안계 (비보안계에서 억세스할 수 없는) 이다. 보안과 비보안계들에 사용된 물리적 메모리 매핑은 똑같은 가상 메모리 주소들이 다른 벡터 테이블들을 물리적 메모리 안에 저장되는 일을 효율적으로 허용한다. 모니터 모드는 항상 플랫 메모리 매핑을 사용하여 물리적 테이블 안에 있는 세 번째 벡터 테이블을 지원한다.
도12 메커니즘의 인터럽트가 일어날 때는 도 14에 보이는 다음의 벡터들이 각각의 테이블 마다 있다. 이 벡터 셋 은 보안과 비보안 메모리 안에서 복사된다.
NB. 리셋 엔트리는 보안 벡터 테이블 안에만 있다. 비보안계에서 리셋이 실행되면 코어 하드웨어는 리셋 벡터가 보안 메모리에 억세스할 수 있도록 관리자 모드의 진입과 S 비트의 초기화를 강요한다.
도 15는 세 개의 예외 벡터 테이블을 설명 한다: 보안 모드, 비보안 모드, 모니터 모드. 이러한 예외 벡터 테이블들은 예외 벡터들과 함께 프로그램 됨으로써 요구사항들과 보안과 비보안 작동 시스템들의 성격과 매치시킨다. 각각의 예외 벡터 테이블들은 메모리 안에서의 기반 어드레스가 가르치는 테이블을 저장하며 CP15안에서의 관련된 벡터 테이블 기반 어드레스 레지스터를 가지고 있다. 예외 이 일어난 경우 하드웨어는 벡터 테이블 기반 어드레스 레지스터를 관련된 현재의 시스템으로 참고함으로써 사용된 벡터 테이블 기반 어드레스를 결정한다. 또는, 다른 모드에 있는 물리적 메모리 매핑에 대한 가상주소가 사용되어 같은 물리적 메모리 어드레스들에 있는 세 개의 지정된 벡터 테이블이 분리된다.
도 16에서 설명되었듯이 예외 트랩 마스크 레지스터는 프로세서 코어와 관련된 시스템(설정 제어) 코프로세서 (CP15)로 지원되고 있다. 이 예외 트랩 마스크 레지스터는 각각의 예외 타입으로 관련된 플래그들을 제공한다. 이와 같은 플래그들은 하드웨어가 현재 도메인에 있는 예외에 맞는 벡터에게 다이렉트 프로세싱을 작동해야 하는지 아님 모니터 모드 (보안 모드 타입중의 한 가지)로 바꾼 다음 모니터 모드 벡터 테이블에 있는 벡터를 따라야 하는지를 보여주고 있다. 예외 트랩 마스크 레지스터는 모니터 모드에서만 쓰기가 가능하다. 이는 읽기 권한이 또한 금지되어 있으며, 예외 트랩 마스크는 도 16에 포함되어 있지 않은 플래그 상의 리셋 백터가 시스템이 항상 보안 관리자 모드 상에서 리셋 백터로 건너 뛰도록 설정되어 있는 경우에 해당하는데, 이는 보안 벡터 테이블이 리셋 백터 테이블을 내부 호환성 측면, 부트의 보안을 확보하기 위함이다. 이는 도 15번에서 보여지며, 완벽함을 위해서, 보안 벡터는 보여지는 대로 벡터 테이블에서 다른 보안 관리 모드가 보안 벡터 테이블에 비해 앞서게 된다.
도 16은 또한 예외 트랩 마스크 레지스터가 프로그래밍이 가능한 상태에서의 예외의 종류를 나타내고 있다. 예를 들어 보안 부트 상의 모니터 프로그램 등이다. 또 다르게 일부 혹은 모든 플래그는 특정한 설치 조건에 들게 되는데, 이는 물리적 입력 시그널, 예를 들어서 보안 인터럽트 플래그 SIRQ와 같은 것이 모니터 모드 상에서 설치된 경우에 강제 입력된 값들과 보안 인터럽트가 전송 되었을 때의 인터럽트 요구 벡터가 보안 모드일 경우이다. 도 16은 예외 트랩 레지스터가 비보안 도메인의 예들과, 비슷한 종류의 프로그램 가능 비트 등이 보안 도메인 예외 사항에 의해 제공될 것이라는 것을 표시 하고 있다.
위에서 이해 된 대로, 한 레벨에서 하드웨어는 현재 도메인 예외 사항에서 강제로 인터럽트를 발생하거나, 혹은 모니터 모드의 예외 사항을 관리하는 관리자의 조건에 따라 제어 레지스터 플래그를 관리하며, 단지 처음 레벨의 플래그만 적용된다. 예를 들어, 보안 모드상에서 예외가 발생하는 것은 가능한 일이고, 보안 모드의 예외 벡터 상에서는 보안 모드 예외 관리자를 따르게 되나, 이 보안 모드 예외 관리자는 보안 관리자 보다는 특성상 비보안 예외 관리자 쪽에서 관리하는 것이 옳다고 판단하여 SMI 설정을 따라서 비보안 모드로 전환하여 비보안 예외 관리자에게 인계하게 된다. 이 전환은 비보안 관리자 모드가 초기화 할 수 있도록 하는데 역할을 하며, 보안 예외 관리자가 모니터 모드 예외 관리자로부터 직접 프로세스를 할 수 있도록 하는데 도움을 준다.
도 17은 흐름도 상에서 시스템의 운영 상태를 다른 가능한 종류의 전환 요구가 연계된 예외에 의해 실행되는 것을 보여 준다. 단계 98에서 보면, 하드웨어는 모니터 모드로 전환 하려고 하는 어떤 시도에 대해서도 현재 프로그램 상태 레지스터로 등록하게 된다. 그러한 시도가 나타나게 되면, 새로운 종류의 예외가 발생하게 되고, CPSR 위반 예외 사항이 전달된다. 이 CPSR 위배 예외는 단계 100에서 적당한 예외 벡터를 모니터 모드 상에서 실행하여, 모니터 프로그램이 단계 102를 실행하여 CPSR위배 예외 사항을 관리 할 수 있도록 해 준다.
보안 도메인과 비보안 도메인 사이의 관계되는 부분은 도 17에 나타나 있으며, 기존에 언급된 SMI 설정을 사용한다. 부분 적으로, 그러한 기술 구현은 존재 하는 코드에 대하여 호환성 측면을 보장하고, 프로세스 상태 레지스터를 제공할 수 있도록 한다. 이는 보안 도메인과 비보안 도메인 상에서도 승인 되지 않은 시도를 만들기 위해 쓰여진다.
위의 언급한 대로 일반적으로 인터럽트들은 프로세스가 모니터 모드에서 동작하는 경우에 비활성화 된다. 이는 시스템의 보안을 위한 것이다. 인터럽트가 인터럽트 포인터 상에서의 기능 구현에서 레지스터에 예외를 등록해서 보안 데이터가 누수 되는 패스로 진행 할 수 있도록 모니터 모드 상에서의 보안을 유지 하는 기능을 한다. 그러나 한 가지 순서가 인터럽트를 모니터 모드상의 대기 시간이 길어 질 때 비활성화 하게 된다.
프로세서 수행 상태가 만약 모니터 모드 상에서 인터럽트를 가능하게 한다면, 그 기능은 저장되지 않는다. 그러므로 모니터 모드 상에서의 인터럽트 문제는, 안전하게 재 시작 된 상태에서의 인터럽트가 가능하도록 모니터 모드에서 수행 하는 수밖에 없다. 이런 경우에 인터럽트는 모니터 모드의 단지 기능만 안전하게 재 시작 하게 된다. 이런 경우에, 모니터 모드에서의 인터럽트는, 특정 기능이 재 시작되어 계속되는 결과를 도출해 낼 때 보여 진다. 만약 기능이 프로세서의 어떤 상태, 예를 들어서 재 시작 되어 다른 결과를 나타내는 것은 좋은 아이디어가 아니다. 이러한 이유로, 단지 그와 같은 기능만이 안전하게 모니터 모드에서 인터럽트가 있을 수 있도록 재 시작 할 수 있게 하며, 다른 기능들의 인터럽트는 비활성화 되는 것이다.
도 18은 본 발명의 모니터 모드에서의 구현 방법에 대한 설명을 하고 있다. SMI는 작업 A가 비보안 모드에서 프로세스를 모니터 모드로 스위치 하게 한다. SMI설정에서는 모니터 모드가 비보안 SMI 벡터에 배정 되어 있다.
PC의 현 상태는 저장 되어 있는 것이고 s비트는 인터럽트가 비활성화 하도록 설정되어 있다. 일반적으로 LR_mon 과 SPSR_mon 은 CP와 CPSR에 비보안 모드로 저장된다.
기능C에 나와 있는 기능들은 모니터 모드에서 초기화 된다. 첫번 째의 것은 기능 C가 인터럽트를 활성화 하고, 기능 C가 이후에 수행된다. 만약 인터럽트 그 기능 C의 프로세스 상에서 수행 되는 경우에는, 인터럽트는 비활성화 되지 않은 상태에서, 응답되어 진행된다. 그러나, 모니터 모드 표시자 에서는 모니터 모드로의 재실행이 아니라, 재 시작을 표시하게 된다. 그러므로, 인터럽트는 인터럽트 예외 벡터가 LR_mon 과 SPSR_mon등으로 현재 상태가 저장되지는 않는다.
도 18에서 보여지듯이, 인터럽트 작업, 작업 B등은 프로세스가 SMI설정의 어드레스를 읽어서 이를 인터럽트 레지스터에 복사하여 SMI가 다시 기능 C를 구현할 수 있도록 한다.
위의 프로세스는 단지 기능 C가 재 시작이 가능하다는 것을 보여 주는 것뿐이며, 이것은 재 시작된 프로세스 C가 연속적인 프로세스 과정을 지나게 된다는 것을 의미한다. 이것은 프로세스 상에서 기능 C가 작업에 관한 프로세서의 모드를 변경하는 것은 아니며, 차후의 스택 프로세싱 등에 영향을 미친 다는 것을 의미한다. 계속 적으로 수행되는 A기능 같은 경우에는 멱등원이라는 이름을 붙이기도 한다. 멱등원의 기능을 제대로 수행하지 못하는 프로세스 문제를 해결하기 위해서는, 멱등원의 코드 값을 가지는 첫 번째 부분을 비활성화 시키는 것이 있다. 예를 들어서, 코드 C가 스택에 기록을 하는 과정에서 처음에 스택 포인터를 업데이트 하지 않는 경우가 있고, 기능 C를 위한 코드는 프로세서가 인터럽트를 비활성화 시켜서 스택 포인터를 현재의 위치로 업데이트 할 수 있도록 한다. 이것은 도 18에 나와 있으며, 기능 C의 프로세싱이 특정한 방법을 통해서 인터럽트가 비활성화 되었음을 보여준다.
도 19는 약간 다른 예가 될 수 있다. 이것은 작업 C가 프로세스 하는데 있어서 약간 다른 방법으로, 관리 파라미터가 설정 된 상태에서의 예이다. 이것은 작업 C의 포인터가 멱등원 상태가 아니고, 안전하게 재 시작 된 상태에서 똑 같은 프로세스 상태를 만들어내는 것을 마지막에 수행하여 인터럽트 되지 않도록 한다. 몇몇 실시 예에서 보듯이 스택 포인터가 업데이트 되는 등의 프로세스 변경에 일어난 경우에는, 프로세스가 멱등원 상태에서 이후에 복구 될 수 있도록 하게 하는 기능을 가지고 있다.
인터럽트의 관리 파라미터가 지정 되어 있는 경우에는, 두 개의 가능한 방법 이 진행 된다. 이것은 루틴을 수정하여 실행할 수 있도록 하거나 혹은 SMI가 실행된 상태에서 이전의 작업 C의 루틴을 수정하여 실행 할 수 있도록 하는 것이다. 보여질 수 있는 대로, 두 개의 각각의 수행 방법은 루틴을 수정하여서, 모니터 모드 상에 있게 하고, 실행은 비보안 도메인 상에서 하게 된다. 이것은 보안 도메인이나 모니터 모드에는 영향을 미치지는 않는다.
도 19에서 볼 수 있듯이 코드 C의 첫 번째 부분은 멱등원 상태이고, 인터럽트 상에서 재 시작 된다. 두 번째 부분은 루틴이 수정 된 이후에 재 시작 될 수 있으며, 이것은 이후의 제거 파라미터를 설정하게 된다. 이 마지막 부분의 코드는 재실행 할 수 없으며, 각각의 코드 프로세스 되는 동안에 비활성화 된다.
도 20은 다른 예를 보여 주는데, 이는 다른 실시예와는 차이가 나며, 모니터 모드 상에서 실행된다. 기능은 모니터 모드에서 인터럽트를 비활성화 시켜서 더 이상 안전한 재실행이 없도록 한다. 이것은 단지 기능이 모니터 모드 상에서 재실행 되는 것을 보여준다.
모니터 모드 상에서 인터럽트가 설정 순서에 맞게 주소의 시작을 저장하여 새로운 프로세스를 추가하고 이것이 전부 새로운 기능을 수행 할 수 있도록 하게 하는 역할을 한다. 다른 방법으로는 기능이 시작하는 부분의 주소를 미리 로딩하여서, 프로세스의 상태를 인터럽트 예외 레지스터로 쓰게 할 수 있도록 한다.
도 20에 구현된 방법으로는, 기능의 재 시작이 인터럽트 기능의 종료나 혹은 루틴을 수정하는 것으로 끝난다. 이것은 안전하게 재 시작할 수 있는 기능을 제공한다.
위의 인터럽트 대기가 시스템을 보안 및 비보안 모드에서 일반적으로 기능들은 전부 인터럽트를 비활성화 하는 것에서 시작한다. 이는 인터럽트가 인터럽트 대기 시간을 줄이는 역할을 하며, 예를 들어 일반적인 운영 체계의 내용 변환 등의 예가 있다.
보안 및 비보안 메모리 억세스
도 1에 나타나 있듯이, 데이터 프로세싱 과정은 TCM 36, 캐쉬 38, 롬 44, 외부 메모리 56등을 포함하는 기타 장비들로 구성되어 있다. 도 37에 도시된 바와 같이 메모리는 보안 메모리와 비보안 메모리로 구성 되어 있다. 이것은 일반적으로 어떤 물리적인 구분이 보안 메모리 영역과 비보안 메모리 영역에서 이 영역이 대신에 보안 운영체계의 데이터 프로세싱 과정에서 결정되는 것으로 볼 수 있다. 이는 보안 도메인 상에서 실행된다. 그러므로, 모든 보안 메모리 , 물리적 메모리의 접속은 보안 메모리 내에 위치하게 되면, 모든 물리적인 부분은 비보안 메모리에 속하게 된다.
도 2와 5에 도시되어 있는 것처럼, 프로세싱 시스템은 보안 도메인과 비보안 도메인을 가지고 있다. 보안 도메인 상에서는 보안 커널 프로그램 80이 동작하여 보안 모드를 수행한다. 모니터 프로그램 72는 보안 및 비보안 도메인이 모니터 모드 상에서 부분적으로 수행 하는 것을 관리 하게 된다. 실시예 상에서 모니터 프로그램은 부분적으로 모니터 모드와 부분적인 보안 모드로 수행 되게 된다. 보안 모드는 내부 알리아스와 관리 모드 SVC등을 가지게 된다.
모니터 프로그램 72는 보안과 비보안 도메인 사이의 각각의 방향에서의 관리를 맡는다. 일부 기능은 도 8과 9에 나타나 있으며, 프로세서 모드 부분을 참조하면 된다. 모니터 프로그램은 비보안 모드에서 보안 모드로의 전환을 주 역할로 하고 있으며, 위의 설명된 부분인 "보안 영역 전환" 은 모니터 모드 상에서 하나 이상의 레지스터 보안 혹은 비보안 도메인 상에 존재 할 때 이 위치를 바꾸어 주는 역할을 맡게 된다. 여기 소개된 대로, 어떤 레지스터는 전환이 실행 될 때 비활성화 되기도 한다. 모니터 모드 상에서는 모든 인터럽트가 정지 한다.
모니터 모드가 모니터 프로그램이 설치되어 불규칙 적인 보안 및 비보안 메모리 영역을 수행 했을 때 모니터 프로그램은 보안화 된다. 이것은 단지 기능이 단순하게 실행 되었을 때에 한한다. 모니터 프로그램이 단순할수록 이로 인한 이점은 더 많아지게 된다. 특정된 보안 모드에서 모니터 프로그램의 단순화가 보안 모드를 수행하게 되는 경우에는, 운영 체계가 보안 모드를 수행 할 수 있도록 권한을 부여한다. 특정화 되지 않은 보안 모드는 리셋을 야기 한다. 모니터 모드와 특정화된 보안 모드의 전환 과정은 도메인 간의 이동에 있을 때의 상태를 저장하도록 한다.
S 플래그와 관련된 실시예에 있어서, 특정화된 보안 모드는 또한 모니터 모드로도 불린다. 만약 보안화된 모니터 모드가 프로세서 상에서 변환된 모니터 모드로 유지되어 제어 프로그램 상에 S 플래그가 변환 될 수 있도록 한다. 그리므로, S 플래그가 제공 됨으로써, 모니터 모드는 일반화 되지 않는 다고 할 수 있다. 이러한 실시예는 현재의 기술 한계에서 특정화 된 보안 모드중의 하나로 S 플래그가 위치 하게 된다.
이미 제기된 예의 실시예를 보면, 코어 10의 상태가 특정화 모드를 결정짓는 역할을 한다.
이는 일부 모드가 기능을 설정할 수 있도록 해준다. 그러므로, 프로세서 코어 10은 보안 모드를 가능하게 해서 모니터 모드 상에서 보안 및 비보안 상에서의 접속을 가능할 수 있도록 메모리 모드를 모니터 모드 상에서 특정화된 보안 모드로 변경하여 모니터 모드나 혹은 그 반대로 작동할 수 있도록 해 준다. 프로세서 코어 10은 이와 같이 기능을 가능할 수 있도록 해 준다.
메모리는 부분화 되어 보안 및 비보안 메모리로 구분이 되면 마찬가지고 두 개의 메모리는 모니터와 비보안 메모리 상태로 구분된다. 선택적으로 비보안 메모리는 모니터 모드 상에서 인식되고, 보안 모드와 비보안 모드로 다시 구분된다.
다른 상황의 예로는, 모니터모드와 여러 중 하나의 보안 모드는 비보안 메모리 모드로의 억세스를 거부하고 보안 모드로 전송을 하게 된다. 그리고 보안 메모리는 단지 모니터 모드에서 억세스가 가능하며, 보안 모드와 비보안 모드는 단지 보안 모드에서만 억세스가 가능하다.
상황의 다른 예로는, 모니터 모드가 보안 모드상에 좀 더 다른 특권을 가지게 되는 것에 대해서 부팅 및 리셋이 실행되기도 한다. 그러나 상황적인 다른 많은 예에서, 직접 변환이 보안 모드와 모니터 모드 상에서 이루어 질 수 있도록 하게 한다.
도 2에 도시된 바와 같이 보안 도메인은 보안 모드에서 보안 커널 80이나 운영 체계에 의해서, 그리고 보안 어플리케이션 82, 84 등에 대해 보안 커널 80을 수 행하게 된다. 보안 커널과 보안 어플리 케이션 프로그램은 다른 프로그램 코드가 보안 모드에서 가능할 수 있도록 억세스를 각각의 보안 및 비보안 메모리 상에서의 작업으로 볼 수 있다.
이 발명의 예들에서 확인할 수 있지만, 상황에서 프로세스가 운용이 될 때, 본 발명은 컴퓨터 프로그램이 이 부분에서 적당한 프로세서와 프로세싱에 맞게 운용되는 경우에 적용될 수 있다는 것을 알 수 있다.
선택적인 구현 방법에 있어서 현재 기술이 고려하는 프로그램의 모델은 아래에 주어진 대로 도 21과 23에서 볼 수 있다.
아래 표현에서 우리는 아래의 용어들을 지정하여 이해 함으로써, ARM 프로세서가 ARM 사에 의해 디자인 되어 있다는 것을 알아야 할 것이다.
S 비트 : 보안 상태 비트, CP 15레지스터에 지정되어 있다.
"보안/ 비보안 상태" 이것은 S 비트값으로 지정되어 있다. 이것은 코어가 보안계에 억세스할 수 있거나 혹은 비보안 모드에서 제한 되어 있을 수 있다. 이것은 S 비트 상태로 강제 될 수 있다.
"비보안계" 그룹은 모든 하드웨어 소프트웨어 억세스가 비보안 어플리케이션 상에서 이루어지는 것을 의미한다.
"보안계" 그룹은 모든 하드웨어 소프트웨어 그룹 중에 보안 모드로 수행이 되는 보안 코드를 의미한다.
모니터 모드: 새 모드로서 보안 모드와 비보안 모드를 변환 시키는 책임을 지게 된다.
요약
코어는 언제나 비보안 모드에서 억세스된다.
코어는 단지 보안 상태와 모니터 모드에서만 보안 상태로 억세스 된다.
SMI: 소프트웨어 모니터 인터럽트: 새 설정으로서, 지정된 SMI를 통한 예외 벡터를 이용한 코어 벡터에 모니터 모드를 실행한다.
스레드 ID: 각각의 스레드 구분자에 연관된 것이다. 몇몇 종류의 운영 체제에서 운영 체제가 비보안 모드에서 운용이 되고, 각각의 경우에 보안 기능이 요구되면, 그것은 파라미터를 통해 스래드 ID를 통해서 보안 기능으로 비보안 어플리케이션에서의 링크를 연결하는 기능을 한다.
프로그래머 모델
카본 코어 개관
카본 기술의 개념은 프로세서가 현재 기술을 이용하는데 있어서, 두 가지의 개념을 볼 수 있는데 하나는 보안 혹은 비보안 상태이다. 보안 상태는 반드시 비보안상태의 데이터로 누수 되어 서는 안된다.
제안된 솔루션에서, 보안과 비보안 상태는 같은 레지스터 뱅크를 공유하게 된다. 그 결과로, 모든 현존하는 모드는 ARM코어 상에서 각각의 상태로 존재하게 된다.
코어는 보안 및 비보안 상태에서 새로운 상태 비트로, S비트로 초기화 되어 CP 15레지스터로 지정된다.
S비트로 수정되어 각각의 설정을 통제 받는 상황에서, 각각의 상태를 다른 형태로 변환하면서, 새 모드를 추가하고, 모니터 모드가 관리를 하는 차원에서 각각의 모드를 관리 하게 된다. 모니터 모드에서 적당한 CP 15레지스터를 통해 쓰기를 수행하며, S비트로 쓰기가 가능할 수 있도록 한다.
마지막으로, 관리 예외에 대한 유연성을 추가할 수 있다. 모든 예외사항에서, 리셋을 제외 하고는 상황적으로 발생할 수 있는 것에 맞추어 모니터 모드로 전환이 된다. 이것은 CP 15 레지스터에 지정되어 설정될 수 있도록 한다.
해당 도표에 이 솔루션에 대한 자세한 사항이 표시 되어 있다.
프로세서 상태 및 모드
신규 카본 특징
보안 혹은 비보안 상태(S 비트)
카본 코어의 특징 중의 하나는 코어가 보안 (S=1)상태 혹은 비보안 상태(S=0)에 있음을 나타내는 S 비트가 존재하는 것이다. 보안 상태 하에서 코어는 보안 혹은 비보안계 안의 어떠한 자료도 억세스할 수 있을 것이다. 비보안 상태에 있을 때에 코어는 비보안 계의 자료로의 억세스가 제한될 것이다.
이러한 규칙의 유일한 예외는 S 비트를 비활성화하는 모니터 모드와 관련이 있다. S=0인 비보안 상태일지라도, 모니터 모드에서는 코어가 보안특권 억세스가 수행할 것이다. 모니터 모드와 관련한 자세한 정보를 위해서는 다음의 구절을 참고 하면 된다.
S 비트는 모니터 모드 안에서만이 읽기와 쓰기가 수행될 수 있다. 어떠한 S 비트 값이라도, 기타의 다른 모드가 S 비트 값에 억세스하려고 한다면, 이러한 억세스는 무시되거나 혹은 정의되지 않은 예외의 결과를 낳게 될 것이다.
리셋과는 다르게 모든 예외들은 보안 상태의 비트에 아무런 영향을 미치지 않는다. 리셋 수행 시에는 , S 비트는 세팅되며, 코어는 감시 모드에서 시작될 것이다. 상세한 정보를 위해서는 부트 섹션을 참조하면 된다.
보안/비보안 상태는 ARM/Thumb/Java 상태와는 무관하게 분리되어 작동된다.
모니터 모드
카본 시스템의 또 다른 중요한 특징은 새로운 모드인 모니터 모드의 생성에 있다. 이것은 보안 혹은 비보안 상태의 변환하는 코어를 컨트롤하는 데 이용될 것이다. 그것은 언제든지 보안모드로 간주될 것이다. 즉, S 비트 값이 어떠한 값이든 간에 모니터 모드상에서는 코어가 항상 외부 계로의 보안특권 억세스를 수행할 것이다.
어느 보안특권 모드(즉 보안 상태하의 특권 모드)일지라도 단순히 CPSR 모드 비트들(MSR, MOVS, 혹은 동등한 명령어)의 기록을 통해 모니터 모드로 변환할 수 있을 것이다. 그러나 이러한 작동은 비보안 사용자 모드 혹은 보안 사용자 모드에서는 금지될 것이다. 이와 같은 작동이 발생하는 경우에는, 그 명령어는 무시되거나 예외를 발생시킬 것이다.
전용 CPSR 위반 예외에 관한 어떠한 필요성이 제기될 수도 있다. 비보안 사용자 모드 혹은 보안 사용자모드로부터 CPSR의 직접 쓰기를 통해 모니터 모드로의 변환 시도에 의해 이러한 예외가 발생될 수도 있다.
리셋을 제외한 모든 예외들은 모니터 모드가 작동될 때 사실상 금지된다 :
- 모든 인터럽트들은 제한된다.
- 모든 메모리 예외들은 무시되거나 치명적인 예외를 발생시킨다.
- 미정의된 명령어들/SWI/SMI는 무시되거나 치명적인 예외를 발생시킨다.
모니터 방식으로의 진입 시에는 인터럽트들은 자동적으로 금지되며 또한 시스템 모니터가 작동되고 있는 동안 발생할 수 없는 다른 종류들의 예외들처럼 시스템 모니터가 기록되어야 한다.
모니터 모드는 몇몇의 사설 레지스터들을 보유할 필요가 있다. 이러한 솔류션은 R13(sp_mon), R14 (lr_mon) 및 SPSR (spsr_mon)과 같은 레지스터들의 최소 집합만을 복제하도록 제안한다.
모니터 모드상에서 MMU(flat address map)는 MPU 혹은 파티션 체커처럼 사용 금지된다. (모니터 모드는 보안 특권 외부 접속을 항상 수행할 것이다.) 그러나 특별하게 프로그래밍된 MPU 영역 속성들(캐쉬능력 등)은 동작될 수 있다. 선택에 따라서는 모니터 모드는 보안 도메인에 사용되는 어떠한 매핑이라도 활용할 것이다.
새로운 명령어
이 제안은 현존하는 ARM 명령어 세트에 새로운 하나의 명령어를 추가하는 것 을 요구한다.
고정된 SMI 예외 벡터에서 가름 명령을 실행하면서, SMI (소프트웨어 모니터 인터럽트) 명령어는 모니터 방식으로 진입하는 데 이용될 것이다. 이 명령어는 주로 비보안 상태와 보안 상태 사이에서 교환토록 모니터를 표시하는 데 이용될 것이다.
선택(혹은 추가)에 따라 문맥 변환 성능을 개선하기 위하여 모니터 모드가 모니터 스택으로부터(혹은 모니터 스택으로) 다른 모드의 상태를 저장하거나 복원하는 것을 가능케 하기 위해 새로운 명령어를 추가할 수도 있다.
프로세서 모드
앞서 논의된 대로, 코어에 단지 하나의 새로운 모드인 모니터 모드가 추가 되었을 뿐이다. 존재하는 모든 모드들은 사용이 가능하며, 또한 보안 상태와 비보안 상태 둘다에서 존재할 수 있다.
실제로 카본 유저들은 도 21에 설명된 구조를 볼 수 있을 것이다.
프로세서 레지스터
이러한 구체화는 보안계와 비보안계가 동일한 레지스터 뱅크를 공유하도록 제안 한다. 이것이 뜻하는 바는 모니터 모드를 통해 하나의 계로부터 다른 계로 변환할 시에 시스템 모니터가 첫 번째 계의 문맥을 저장하고 두 번째 계의 문맥을 생성(혹은 복원)해야할 필요가 있다는 것이다.
매개변수의 전달이 용이해진다: 시스템 모니터가 S 비트를 한번 변환하면, 동일한 레지스터에 저장된 어떠한 자료라도 첫 번째 계에서처럼 두 번째 계에서도 동일하게 사용이 가능할 것이다.
그러나 엄격하게 제어되어야 하는 제한된 수의 매개변수 전달 전용 레지스터와는 달리 대부분의 다른 레지스터들은 보안상태에서 비보안 상태로 전환시에 보안 데이터의 누수를 방지하기 위해 일부분을 비워야 할 필요가 있을 것이다. 이것은 모니터 커널에 의해 보증될 필요가 있을 것이다.
하드웨어 메커니즘이나 새로운 명령어에게 보안 상태에서 비보안상태로의 전환시에 직접적으로 레지스터를 비울 수 있는 권한을 주는 것도 또다른 하나의 실현 가능한 일이다.
제안된 또다른 솔루션은 보안 상태와 비보안 상태간에 물리적으로 분리된 두개의 레지스터 뱅크를 보유하여 모든 (혹은 대부분의) 현존 레지스터 뱅크를 복제하는 것을 필요로 한다. 이 솔루션은 레지스터 안에 저장된 보안/비보안 데이터를 명확히 분리하는 장점을 가지고 있다. 그것은 또한 보안 상태와 비보안 상태간의 빠른 문맥 변환을 가능케 한다. 그럼에도 불구하고, 보안계가 비보안 레지스터를 억세스하는 것을 허가하는 전용 명령어를 생성하지 않는 경우에는 레지스터를 통한 매개변수의 전달이 어렵게 된다는 것이 단점이다.
도 22는 프로세서 모드에 따라 사용 가능한 레지스터에 대해 설명하고 있다. 프로세서 상태가 현 논제에 어떤 영향도 미치지 않는다는 것을 유의해야 한다.
예외들
보안 인터럽트
현행 솔루션
일반적으로 현재 코어에서처럼 IRQ나 FIQ와 같은 동일한 인터럽트 핀을 유지시키는 것이 제안된다. 예외 트랩 마스크 레지스터 (추후 이 문서상에서 정의될 것임)와 연계하면, 어떤 시스템도 다른 종류의 인터럽트를 구현하고 다루는 충분한 융통성이 있을 것이다.
VIC 강조
우리는 다음의 방법으로 VIC (벡터 인터럽트 콘트롤러)를 강화할 수 있었다. VIC는 개개의 벡터 주소들과 연관된 하나의 보안 정보 비트를 수록하고 있을 것이다. 이러한 비트는 단지 모니터나 보안 특권 모드에 의해 프로그래밍이 가능할 것이며, 그것은 고려되는 인터럽트가 보안측면에서 다루어지거나 처리되어야 하는지의 여부를 나타낼 것이다.
우리는 또한 두 새로운 벡터 어드레스를 추가할 것인데, 한 개의 벡터 어드레스는 비보안 상태에서 발생하는 모든 보안 인터럽트를 위한 것이며, 다른 한개는 보안 상태에서 발생하는 모든 비보안 인터럽트를 위한 것이다.
CP15에 포함된 S 비트 정보는 신규 VIC 입력처럼 VIC로의 사용 또한 가능하게 될 것이다.
다음의 테이블은 입력되는 인터럽트의 상태(각자의 인터럽트 라인과 연관된 S 비트에 의해 표시되는 보안 혹은 비보안)에 따라 실현될 수 있는 각각의 시나리오에 대해 요약하여 표시하고 있다.
Figure 112005025465258-pct00001
예외 처리 구성능력
카본 융통성의 개선을 위하여 새로운 레지스터인 예외트랩마스크가 CP15에 추가되어야 한다. 이 레지스터는 다음의 비트들을 포함할 것이다:
Bit 0: Undef 예외 (비보안 상태)
Bit 1: SWI 예외 (비보안 상태)
Bit 2: Prefetch abort 예외 (비보안 상태)
Bit 3: Data abort 예외 (비보안 상태)
Bit 4: IRQ 예외 (비보안 상태)
Bit 5: FIQ 예외 (비보안 상태)
Bit 6: SMI 예외 (보안/비보안 상태 둘 다)
Bit 16: Undef 예외 (보안 상태)
Bit 17: SWI 예외 (보안 상태)
Bit 18: Prefetch abort 예외 (보안 상태)
Bit 19: Data abort 예외 (보안 상태)
Bit 20: IRQ abort 예외 (보안 상태)
Bit 21: FIQ abort 예외 (보안 상태)
이 레지스터에서 리셋 예외는 어떠한 일치되는 비트도 가지고 있지 않다. 리셋은 항상 코어가 전용 벡터를 통해 보안 감시자 모드로 들어가도록 한다.
비트가 세팅되면, 관련 예외는 코어가 모니터 모드에 진입하도록 만든다. 그렇지 않으면, 그 예외는 발생된 계에서 연관된 핸들러에 의해 다뤄질 것이다.
이 레지스터는 단지 모니터 모드에서만 보여질 것이다. 어떤 다른 모드에서의 억세스를 시도하려는 명령어는 모두 무시될 것이다.
이 레지스터는 시스템이 모니터를 지원하는지의 여부에 따라 시스템 특정값으로 초기화되어야 한다. 이것은 기능적으로 VIC에 의해 관리될 수 있다.
예외 벡터 테이블
분리된 보안계와 비보안계에 따라, 보안 예외 벡터 테이블과 비보안 예외 벡터테이블 또한 분리하여야 한다.
더욱이, 모니터가 몇몇의 예외들을 잡을 수 있으므로, 제 3의 모니터 전용 예외 벡터테이블 또한 필요로 할 수도 있다.
다음의 테이블은 이러한 세 개의 각자 다른 예외 벡터 테이블을 요약한다 :
비보안 메모리의 경우:
Figure 112005025465258-pct00002
보안 메모리의 경우:
Figure 112005025465258-pct00003
* 리셋 메커니즘에 관련한 상세한 정보를 위해서는 “부트” 섹션을 참고할 것.
모니터 메모리의 경우 (플랫 맵핑):
Figure 112005025465258-pct00004
모니터 모드에서, 각각의 예외가 다른 두개의 연관된 벡터를 가지고 있도록, 예외 벡터는 복제될 것이다:
- 하나는 비보안 상태에서 발생되는 예외를 위한 것임.
- 다른 하나는 보안 상태에서 발생되는 예외를 위한 것임.
모니터 커널이 예외가 발생된 초기의 상태를 감시할 필요가 없으므로, 이것은 더 이상의 예외 지연을 감소시키는 데에 유용할 수도 있다.
이러한 특징은 보안 상태와 비보안 상태간의 변환의 개선을 위한 가장 적합한 지원중에 하나인 SMI와 같은 몇몇의 예외들로만 제한될 수 있음을 유의하여야 한다.
계간 변환
상태간 변환시, 모니터 모드는 첫 번째 상태의 문맥을 모니터 스택에 반드시 저장하여야 하며, 모니터 스택으로부터 두 번째 상태 문맥을 복원해야 한다.
따라서 모니터 모드는 사설 레지스터(r14, SPSR, ..)를 포함하는 모든 모드에서의 모든 레지스터를 억세스할 필요가 있다.
이것을 다루기 위해, 제안된 솔루션은 CPSR의 단순한 기록을 통해 모니터 모드로의 직접적인 변환의 권한을 보안 상태에서 어느 특권 모드에 제공하는데 있다.
이러한 시스템을 이용하여 다음과 같이 계간 변환이 수행된다:
-모니터 모드로 진입한다.
-S 비트를 세팅한다.
-감독자 모드로 변환한다.
-모니터 스택 (물론 감독자 모드는 모니터 스택 포인터로의 억세스가 필요하지만, 예를 들면 R0에서 R8같은 일반 레지스터를 사용하면 이것은 간단히 실행될 수 있다.)에 감독자 레지스터를 저장한다.
-모니터 스택에 IRQ 레지스터를 저장한다.
-등등...모든 모드에 대하여
-한번 모든 모드의 사설 레지스터 전부가 저장되면, 간단한 MSR 명령어(단순희 CPSR 모드 필드에 모니터 값을 기록한다.)와 함께 모니터 모드로 복귀한다.
기타 솔루션들도 또한 고려되었다:
-모니터가 다른 모드들의 사설 레지스터들을 자신의 스택에 저장할 수 있도록 새로운 명령어를 추가한다.
-새로운 "상태"로서 모니터를 구현한다. 예를 들면 모니터 상태(적당한 억세스 권한을 갖기 위하여)나 IRQ(혹은 다른) 모드에서 IRQ(혹은 다른) 사설 레지스터를 볼 수 있도록 하기 위해 새로운 "상태"로 구현한다.
기본 시나리오 (도 23 참조)
1. 쓰레드 1이 비보안계(S 비트=0)에서 작동중이다.
2. SMI 명령은 그 코어를 비보안 SMI 벡터를 통해 모니터 모드에 들어가게 만든다.
LR_mon과 SPSR_mon은 비보안 모드의 PC와 CPSR를 저장하는데 활용된다.
이 단계에서 시스템이 현재 보안상태에 있더라도 S 비트는 변환되지 않은 상태로 남아있다.
모니터 커널이 모니터에 비보안 문맥을 저장한다.
그것은 또한 LR_mon과 SPSR_mon을 더한다.
모니터 커널은 CP15 레지스터에 기록함으로써 "S" 비트를 변환한다.
이 구현에서, 모니터 커널은 "보안 쓰레드 1"이 보안계에서 시작될 수 있도 록 트랙을 유지한다. (예컨대 쓰레드 아이디 테이블의 업데이트를 통해)
결국, 모니터 모드가 존재하며 보안 감독자 모드로 변환된다.(LR_mon and SPSR_mon의 업데이트 이후 MOVS 명령어)
3. 보안 커널은 어플리케이션을 정확한 보안 메모리 장소로 신속히 전달하며, 이후에 사용자 모드로 전환한다. (예를 들면 MOVS를 사용하여)
4. 보안 사용자 모드에서 보안 기능이 실행된다.
한번 종료되면, 이는 적절한 SWI를 수행함으로써 "종료" 기능을 호출한다.
5. SWI 명령어는 코어가 전용 SWI 벡터를 통해 보안 SVC 모드에 진입하게 한다. 차례에 따라 "종료" 기능을 수행한다.
이러한 "종료" 기능은 모니터 모드로 복구하는 SMI와 함께 종료된다.
6. SMI 명령어는 코어를 전용 보안 SMI 벡터를 통해 모니터 모드에 진입하도록 한다.
LR_mon과 SPSR_mon은 Secure svc 모드의PC와 CPSR을 저장하는 데 이용된다.
S 비트는 변하지 않은 상태로 남아있다. (즉, 보안 상태)
모니터 커널은 보안 쓰레드 1이 종료되었다는 사실을 기록한다. (쓰레드 아이디 테이블로부터 보안 쓰레드 1를 삭제한다)
이후 CP15 레지스터에 기록하고, 비보안 상태로 돌아감으로써 "S"비트를 변환한다.
모니터 커널은 모니터 스택으로부터 비보안 문맥을 복원한다.
모니터 커널은 또한 2단계에서 저장된 이전의 LR_mon과 CPSR_mon을 로딩한 다.
마지막으로, SUBS와 함께 모니터 모드를 종료하며, 이는 명령어에서 코어가 비보안 사용자 모드로 복귀하도록 한다.
7. 쓰레드 1은 정상적으로 회복될 수 있다.
도 6을 참조하면, 보안 도메인과 비보안 도메인 사이에 모든 레지스터들은 공유되고 있음을 알 수 있다. 모니터 모드에서 변환은 보안 도메인과 비보안 도메인의 어느 한쪽에서 다른 반대쪽으로 레지스터를 변환하면서 발생한다. 이것은 상기 "계간의 변환" 단락에서 설명되어진 것처럼, 한쪽의 도메인에 현재의 레지스터의 상태를 저장하고 반대쪽의 도메인에 새로운 레지스터 상태를 기록(혹은 레지스터에 기록되어 있는 이전 상태의 복원)하는 것을 수반한다.
이런 변환을 수행함에 있어 수행시간을 단축하는 것이 바람직하다. 변환의 실행에 걸린 시간을 단축하기 위하여 보안 도메인과 비보안 도메인간에 변환이 수행될 때 그 속에 저장된 데이터 값들을 변경시키지 않은 채 공유된 레지스터들의 사용을 금지시킨다. 예를 들어 비보안 도메인으로부터 보안 도메인으로의 변환을 생각해 보자. 보안계에서 도 6에 설명된 FIQ 레지스터들이 필요가 없다고 예를 들어 가정해 보자. 그러면, 이러한 레지스터들은 사용이 불가능한 상태이며 그것들을 보안 도메인으로 변환하거나 이러한 레지스터들의 문맥을 저장할 필요가 없다.
레지스터의 불가용화는 여러 방법을 통해 달성될 수 있다. 한가지 방법은 이러한 레지스터들을 이용하는 모드를 잠그는 것이다. 그것은 모드의 불용화를 나타내는 CP15 레지스터의 제어비트를 기록함으로써 수행된다.
선택에 의해, CP15 레지스터에 제어 비트를 기록함으로써 명령어순의 원리에 따라 레지스터에 억세스하는 것이 불가능할 수도 있다. CP15 레지스터에 기록된 S 비트는 모드가 아닌 그 레지스터와 명백한 관계가 있다. 따라서 그 모드는 사용금지 되지는 않지만 금지된 모드에서의 레지스터로의 억세스은 금지된다.
FIQ 레지스터들은 빠른 인터럽트와 연결된 데이터를 저장한다. FIQ 레지스터(들)가 사용이 금지되고 신속한 인터럽트가 발생하는 경우, 프로세서는 모니터상에 예외를 표시한다. 예외 발생에 대한 응답상황에서 모니터 모드는 하나의 도메인과 연관되거나 상기 사용금지된 레지스터에 저장된 어떠한 데이터 값의 저장을 수행가능하고, 또한 다른 도메인과 연관된 새로운 데이터 값을 레지스터에 로드하는 것도 가능하며, 그러고 난 다음 FIQ 모드 레지스터를 재사용할 수 있다.
프로세서의 도메인 변환시에 모든 뱅크 레지스터가 사용이 금지되도록 하기 위해 프로세서가 조절될 수 있다. 대신하여, 레지스터의 불용화는 프로그래머의 선택시에 도메인의 변경과 다른 것들이 사용금지되는 때에 미리 결정된 몇몇의 공유된 레지스터들 중의 하나가 불용화 되는 것에 의해 선택이 가능하다.
모니터 모드상에서 도메인이 변경될 때에 공유 레지스터들 중의 하나 이상이 불용화되고, 하나의 도메인이 존재할 때 다른 공유 레지스터 중의 하나 이상이 그들의 저장된 데이터를 갖도록 하는 한편 다른 도메인에서는 로딩된 새로운 데이터를 가질 수 있도록 하기 위해 프로세서는 조절될 수 있다. 그 새로운 자료는 공 자료일 수도 있다.
도 24는 전통적인 ARM 코어에 보안 프로세싱 옵션을 추가하는 개념에 대해 설명하고 있다. 도는 현존하는 코어에 보안 프로세싱 옵션을 추가함으로써 보안 프로세싱 옵션을 내재한 프로세서가 어떻게 형성될 수 있는지를 도식적으로 보여주고 있다. 만약에 시스템이 현존하는 레거시 운영 체계와의 후방 호환성이 있다면, 이것은 레거시 시스템이 프로세서의 전통적인 비보안 부분에서 실행되고 있음을 직관적으로 생각될 수 있다. 그러나, 도의 아래 부분에서 도식적으로 나타나 있으며 그 아래에 설명되어 있듯이 사실은 레거시 시스템이 운영되는 보안 부분에서 실행되고 있는 것이다.
도 25는 보안 및 비보안 도메인을 가지고 있으며 리셋을 설명하고 있는 프로세서에 대해 보여주고 있으며, 이는 도 2와 비슷하다. 도 2는 보안 도메인에서 처리되는 것을 관리하는 보안 OS 시스템 및 비보안 도메인에서 처리되는 것을 관리하는 비보안 OS 시스템을 이용한 보안 민감도 타입을 수행하기 위해 개조된 프로세서에 대해 설명하고 있다. 그러나 프로세서는 또한 전통적인 레거시 운영 체계와의 후방향 호환성을 가지고 있고, 따라서 그 프로세서는 레거시 운영 체계를 활용하며 보안에 민감하지 않은 방법으로 운영될 수도 있다.
도 25에서 보여지듯이, 리셋은 보안 도메인에 있으며, 어떠한 종류의 수행 리셋이라도 여기서 S 비트 혹은 보안 상태 플래그 셋과 함께 발생한다. 보안에 민감하지 않은 운영 타입인 경우 리셋은 보안 도메인과 프로세싱에서 발생되며 이후에 보안 도메인 안에서 지속된다. 그러나 처리를 관리하는 레거시 운영 체계는 그 시스템의 안전 관점에 대해 알지 못한다.
도 25에서 보여지듯이 보안에 민감한 것이든 혹은 실제 보안에 민감하지 않던 간에 보안 감독자 모드 안에서 실행이 시작되는 주소를 세팅하기 위해 리셋이 수행된다. 한번 리셋이 수행되면, 추가적인 업무들이 부트나 리부트 매카니즘이 수행되는 동안 나타나게 된다. 부트 메카니즘은 아래에 설명되어 있다.
부트 메카니즘
그 부트 메카니즘은 아래의 특징들을 따라야 한다.
-레거시 OS와의 호환성을 유지해야 한다.
-시스템의 보안을 보증하기 위해 최고 특권 모드에서 부팅한다.
결과적으로 카본 코어는 보안 감독자 모드에서 부팅될 것이다.
그리고 나서 다른 시스템이 있을 것이다:
-레가시 OS를 수행하길 원하는 시스템들을 위해 S 비트는 계정에 입력되지 않을 것이며 코어는 감독자 모드에서 부팅되는 것을 단지 관찰할 것이다.
- 카본 특징을 사용하는 것을 원하는 시스템을 위해, 코어는 그 시스템의 모든 보안 방어를 설정할 수 있도록 하기 위해 보안 특권 모드에서 부팅한다. (잠재적으로 모니터 모드로 변환한 이후)
상기 부트 메카니즘의 세부사항에 관해서, 본 발명의 실시예에 의한 프로세서는 모든 경우에 있어서 보안 감독자 모드에서 프로세싱을 시작하기 위해 프로세서를 리셋시킨다. 보안에 민감하지 않은 경우의 운영시에는 (운영체제가 알고 있지 못하더라도) S 비트가 세팅되어 있으므로, 보안이 문제거리가 아닐지더라도 운영 체제는 실제적으로 보안 도메인에서 작동되고 있다. 이것은 비보안 모드에서 억세 스가 가능한 메모리의 부분들이 이 상황에서는 억세스가 불가능하다는 장점을 가지고 있다.
모든 경우에 있어서 보안 감독자 모드에서 부팅하는 것은 시스템의 보안을 보증하는 것이므로 보안에 민감한 시스템에서도 장점을 가지고 있다. 보안에 민감한 시스템에서, 부팅시에 제공된 어드레스는 비보안 관리자 모드가 저장된 부트 프로그램을 가리키고 있으며 또한 보안 시스템으로의 설정과 모니터 모드로의 변환을 가능케 한다. 보안 감독자 모드로부터 모니터 모드로의 변환은 대부분 가능하며, 모니터 모드 설정을 초기화하기 위한 모니터 모드에서의 프로세싱을 적합한 순간에 시작할 수 있도록 해준다.
도 26은 1 단계에서 비보안 쓰레드 NSA가 비보안 운영 체계에 의해 실행되는 것을 설명하고 있다. 2 단계에서 비보안 쓰레드 NSA가 모니터 모드를 통해 3단계의 모니터 모드 프로그램을 수행하며 보안 도메인을 호출한다. 모니터 모드 프로그램은 도메인 변환을 위해 S 비트를 변경하고, 5단계의 보안 운영시스템으로 이동하기 앞서 필요로 하는 문맥의 저장 및 문맥의 복원을 수행한다. 그리고 나서, 일치하는 보안 쓰레드 SA는 그것이 6 단계의 인터럽트 irq에 종속되기 전에 실행된다. 하드웨어를 다루는 인터럽트는 그 인터럽트가 보안 운영 체계 혹은 비보안 운영 체계에 의해 다뤄지게 될지를 결정하게 되는 7단계에서 모니터 모드로의 귀환을 작동시킨다. 이 상황에서, 인터럽트는 9단계에서 시작하는 비보안 운영 체계에 의해 다루어진다. 인터럽트가 비보안 운영 체계에 의해 다루어졌을 때, 비보안 쓰레드 NSA는 일반 쓰레드가 작동을 교환하는 11단계에 앞서, 비보안 운영 체계에서 현재의 작업으로 재개된다. 이러한 쓰레드의 변경은 타이밍 이벤트 혹은 유사한 이벤트의 결과일 수 있다. 다른 쓰레드 NSB는 12단계에서 비보안 운영 체계에 의해 비보안 도메인 안에서 실행되며, 그때 이것은 14단계에서는 모니터 도메인과 프로그램을 통해 보안 도메인을 호출한다. 7단계에서 보안 운영 체계가 보안 쓰레드가 실행이 중지되었거나 종료의 일반적인 요구 때문에 남겨졌다기 보다는 인터럽트의 결과로써 최종으로 중지된 것을 알려주기 위해 플래그를 저장한 모니터 프로그램은 몇몇의 다른 메카니즘을 사용했다. 따라서, 그 보안 운영 체계가 인터럽트에 의해 중지된 이후로, 15단계에서의 모니터 프로그램은 귀환 쓰레드 아이디를 명시하고 있는 조작된 인터럽트의 소프트웨어를 사용하며 보안 운영 시스템에 재입장한다.(예를 들어, 쓰레드의 구분자가 기타 매개변수 데이터와 같은 비보안 쓰레드 NSB의 요구에 의해 보안 운영 체계에 의해 시작된다.) 이러한 조작된 인터럽트 소프트웨어의 매개변수가 레지스터 값으로 옮겨질 수도 있다.
조작된 인터럽트 소프트웨어가 15단계의 보안 운영 체계의 인터럽트 귀환 핸들러 루틴을 작동시킨다. 이러한 귀환 인터럽트 핸들러 루틴은 중지에 앞서 수행되었던 보안 운영 체계가 최종으로 중지된 보안 쓰레드 SA의 쓰레드 아이디와 일치하는지의 여부를 확인하기 위해 검사한다. 이 경우에, 매치되는 것이 없으며 따라서, 16단계에서 보안 쓰레드 SA의 문맥이 저장된 이후에 비보안 쓰레드 NSB에 의해 명시되는 대로 귀환 쓰레드로의 쓰레드 변환을 수행하기 위해 보안 운영 체계가 작동된다. 그리고 나서, 보안 쓰레드 SA는 그것이 요구에 따라 인터럽트된 포인트로부터 차후에 다시 시작될 수 있다.
도 27은 도 26에 설명된 행동의 형태의 또다른 예를 도식적으로 설명하고 있다. 이러한 예에서 IRQ를 핸들링하기 위해 조용한 프로세싱이 비보안 운영 체계의 제어 아래 수행되며, 비보안 쓰레드 변환이 없어서, 결과적으로 조작된 인터럽트 소프트웨어가 보안 운영 체계의 귀환 인터럽트 핸들러에 의해 받게 될 때 아무런 쓰레드 변환이 필요가 없음과 단지 보안 쓰레드 SA가 15단계에서 재개되는 것이 결정된다.
도 28은 귀환 쓰레드 핸들러에 의해 수행되는 프로세싱을 도식적으로 설명하고 있는 흐름도이다. 4002 단계에서, 귀환 쓰레드 핸들러가 시작된다. 소프트웨어로부터의 귀환 쓰레드 확인자가 날조된 4004단계에서, 인터럽트는 검사되고 보안 운영 체계가 종료되었을 때에 현재 수행중인 보안 쓰레드와 비교된다. 이것이 일치하면, 프로세싱은 안전 쓰레드가 재개되는 4006 단계까지 진행된다. 4004 단계에서의 비교가 일치되지 않는다면, 신규 보안 쓰레드로의 변환이 일어나는 4010 단계에 앞서, 프로세싱은 구 보안 쓰레드의 문맥이 저장된 4008단계까지 진행된다. (차후의 재개를 위해) 새로운 쓰레드는 이미 진행중일 지도 모른다. 4010은 재개이다.
도 29는 마스터 비보안 운영 체계에 의해 변환된 작업을 따라서 수행하는 슬레이브 보안 운영시스템의 프로세싱을 도식적으로 설명하고 있다. 마스터 비보안 운영 체계는 자신의 활동에 대해 다른 운영 체계와 함께 커뮤니케이션하거나 협력을 하기 위한 메커니즘이 없는 관계로 마스터로서만 작동되는 레거시 운영 체계일 수 있다. 도 29에서처럼 최초의 엔트리 포인트로서, 비보안 운영 체계는 비보안 쓰레드 NSA를 실행시킨다. 이 비보안 쓰레드 NSA는 SMI라는 소프트웨어 인터럽트를 사용하는 보안 운영 체계에 의해 실행되는 보안 쓰레드에 대해 호출을 한다. SMI 호출은 2단계인 모니터 모드에서 수행중인 모니터 프로그램에 도달하고 그후에 호출을 4단계에서 보안 운영 체계로 전달하기 앞서 필요한 문맥의 저장 및 변환을 수행한다. 보안 운영 체계는 이후 일치하는 SA 보안 쓰레드를 시작하고, 타이머 이벤트의 혹은 유사 이벤트의 결과에 따라 이 보안 쓰레드는 모니터 모드를 통해 비보안 운영 체계로 제어권을 돌려줄 수도 있다. 비보안 쓰레드인 NSA가 9단계에서 다시 보안 운영 체계에 제어권을 넘겨줄 때에 최초의 소프트웨어 인터럽트를 재발행하면서 제어권 이전 작업을 수행한다. 소프트웨어 인터럽트는 비보안 쓰레드 아이디 확인 NSA, 타겟 보안 쓰레드가 작동될 수 있는 보안 쓰레드 아이디를 포함한다. 다시 말해서, 다른 매개변수와 같이 쓰레드 아이디는 보안 쓰레드인 SA를 인식한다.
9단계에서 생성된 호출이 모니터 프로그램에 의해 전해져서 12단계에서 보안 운영 체계에 의해 보안 도메인에서 접수될 때, 비보안 쓰레드 아이디는 비보안 운영 체계에 의해 문맥 변환이 있었는지를 결정하기 위하여 검사될 수 있다. 타겟 쓰레드의 보안 쓰레드 아이디도 또한 보안 운영 체계가 재가동되거나 새로운 쓰레드로 시작된 상황 하에서 정확한 쓰레드인지를 확인하기 위해 검사될 수 있다.
도 30은 쓰레드에 있는 스위치가 9단계 시에 비보안 운영 체계의 제어 아래에 비보안 도메인에서 발생하는 것만을 제외하고는 도 29와 유사하다. 따라서, 그것은 11단계에서 소프트웨어를 보안 운영 체계로의 호출을 방해하게 만드는 다른 비보안 쓰레드 NSB이다. 14단계에서, 보안 운영 체계는 비보안 쓰레드 NSB의 다른 쓰레드 아이디를 인식하고 이에 따라 보안 쓰레드 SA의 문맥을 저장하고 보안 쓰레드 SB를 시작하면서 수반하는 직무 스위치를 수행한다.
도 31은 보안 운영 체계의 쓰레드의 시작 혹은 쓰래드의 재개를 위한 호출로로써 소프트웨어 인터럽트를 받은 상황에서 보안 운영 체계에 의해 수행된 처리를 도식적으로 설명하는 흐름도이다. 4012 단계에서, 그 호출은 받아진다. 4014 단계에서, 보안 운영 체계 위에 현재 구동중인 보안 쓰레드와 일치하는지를 확인하기 위해 호출의 매개변수들은 검사된다. 매치되는 경우가 발생하면, 안전 쓰레드는 4016단계에서 재시작 된다. 매칭이 발생하지 않는 경우에는 프로세싱이 신규 요구 쓰레드의 가능 여부가 판단되는 4018 단계까지 진행한다. 신규 요구 쓰레드는 보안 운영 체계 상에서 이미 다른 작동중인 쓰레드에 의해 사용되고 있는 외부 자원들이 있거나 그것의 요구 때문에 사용이 불가능할 수도 있다. 그런 경우에, 그 호출은 비보안 운영 체계로 돌아가지는 적절한 메시지를 가진 4020 단계에서 거절된다. 4018 단계에서의 결정이 신규 쓰레드가 사용 가능하다고 한 것이라면, 가능한 차후의 재개를 위해 오래된 보안 쓰레드를 저장하게 되는 4022단계까지 진행하게 된다. 4024 단계에서, 보안 운영 체계로의 소프트웨어 인터럽트 호출에 특화된 새로운 보안 쓰레드에 스위치가 생성되어 진다.
도 32는 각자 다른 운영 체계에 의해 각각의 인터럽트가 조작되는 병렬 운영 체계 하에서 인터럽트가 조작될 때 우선권 전도가 발생할 수도 있음을 도식적으로 설명하고 있다.
프로세싱은 SA 보안 쓰레드를 실행시키는 보안 운영 체계와 함께 시작된다. 그리고 나서, 이것은 첫 번째 인터럽트 Int1에 의해 중단된다. 이것은 인터럽트가 보안 도메인에서 조작되거나 혹은 비보안 도메인에서 조작되는지를 결정짓기 위해 모니터 모드 안에서 모니터 프로그램을 작동시킨다. 이러한 경우, 인터럽트는 보안 도메인 상에서 조작될 것이며 프로세싱은 보안 운영 체계로 돌아가고, 인터럽트 핸들링 루틴은 인터럽트 Int1이 시작되도록 할 것이다. 인터럽트 핸들링 루틴이 Int1를 위해 조작되는 중간에도, 상위 우선권을 갖는 인터럽트 Int2가 받아질 수 있다. 그러면 Int1을 위한 인터럽트 핸들러는 정지하게 되며, 모니터 모드의 모니터 프로그램이 인터럽트 Int2가 어디서 조작되는지를 파악하기 위해 사용된다. 이러한 경우 인터럽트 Int2는 비보안 운영 체계에 의해 조작이 될 것이며, 순차적으로 제어권이 비보안 운영 체계로 넘어가서 Int2를 위한 인터럽트 핸들러가 작동을 시작한다. 인터럽트 Int2를 위한 인터럽트 핸들러의 사용이 만료되었을 때에는 비보안 운영 체계는 보안 도메인에서 서비스가 종료된 보류 인터럽트 Int1이 있다는 것을 가리킬 수 있는 정보를 아무것도 가지고 있지 않게 된다. 따라서, 비보안 운영시스템은 최초의 인터럽트 Int1이 서비스되지 않은 상태로 남아있을 때에, 작업 변환이나 다른 비보안 쓰레드인 NSB의 작동과 같이 차후의 몇몇 프로세싱을 수행할 수도 있다.
도 33은 도 32의 작동이 회피되는 경우와 연관된 문제점들에 관한 기술사항들을 설명하고 있다. 인터럽트 Int1이 발생될 때, 모니터 프로그램은 이것을 스터브 인터럽트 핸들러가 시작되는 비보안 도메인으로 전달한다. 스터브 인터럽트 핸들러는 비교적 크기가 작으며, 보안 도메인 내부에서 인터럽트 Int1을 위한 인터럽 트 핸들러를 작동시키고, 모니터 모드를 통해 프로세싱을 보안 도메인쪽으로 재빠르게 복귀시킨다. 인터럽트 Int1은 보안 도메인 안에서 첫째로 처리되며, 비보안 도메인에서의 스터브 인터럽트 핸들러의 작동 시작은 보안 도메인에서의 인터럽트가 보류되고 있다는 것을 비보안 도메인에 알려주는 일종의 위치 보유자라고 생각되어질 수 있다.
인터럽트 Int1와 관련 있는 보안 도메인 상의 인터럽트 핸들러는 또다시 상위 우선권을 보유한 Int2에게 권한을 넘긴다. 이것은 그전처럼 비보안 도메인에서의 인터럽트 Int2를 위한 인터럽트 핸들러의 실행을 작동시킨다. 그러나 이와 같은 상황에서 Int2를 위한 인터럽트 핸들러의 사용이 만료되었을 때에, 비보안 운영체제는 인터럽트 Int1을 위한 스터브 인터럽트 핸들러가 여전히 미완료 상태로 남아 있으며, 따라서 스터브 인터럽트 핸들러를 재개할 것을 가리키고 있는 데이터를 보유하고 있다. 이러한 스터브 인터럽트 핸들러는 자신을 보안 모드로 콜백 하였던 포인트에서 정지되었던 것처럼 나타날 것이다. 포인트에서 순차적으로 이 호출은 다시 수행될 것이며 따라서 보안 도메인으로의 전환을 만들어 낼 것이다. 보안 도메인으로 복귀하게 되면, 보안 도메인은 인터럽트 Int1을 위한 인터럽트 핸들러를, 전에 종료되었던 포인트에서 스스로 다시 작동시킬 수 있다. 보안 도메인 내에서 인터럽트 Int1을 위한 인터럽트 핸들러가 완료되면, 호출은 초기에 작동되던 보안 쓰레드 SA가 다시 시작되기 전에 비보안 도메인에서의 스터브 인터럽트 핸들러를 종료시키기 위해 비보안 도메인으로 돌아간다.
도 34는 각자 다른 인터럽트 및 이와 연관된 우선권, 그리고 어떻게 인터럽 트들이 조작되는 지에 대해 도식적으로 설명되고 있다. 상위의 우선권을 지닌 인터럽트들은 비보안 도메인에 의해 조작되는 상대적으로 상위의 우선권을 지닌 인터럽트가 존재하지 않음을 규정하면서, 순수한 보안 도메인 인터럽트 핸들러들을 이용하여 조작될 것이다. 하위의 인터럽트들보다 상위의 우선권을 지닌 인터럽트가 비보안 도메인에서 조작되면, 모든 하위 인터럽트들은 순수하게 비보안 도메인에서 조작되거나 도 33에 도시된 바와 같이 이들 인터럽트들의 주된 조작이 보안 도메인 내부에서 발생되더라도 비보안 도메인이 인터럽트들을 추적할 수 있도록 하기 위해 스터브 인터럽트 핸들러 기술을 활용하여야 한다.
앞서 언급된 대로, 모니터 모드는 보안 도메인과 비보안 도메인 사이의 전환을 수행하는 데 사용된다. 레지스터들이 두 개의 다른 도메인 사이에서 공유되는 구체화에서, 이것은 레지스터의 상태를 메모리 안에 저장하는 것을 수반한다. 그리고 나서 메모리로부터 새로운 목적 도메인의 상태를 로딩하여 그들의 레지스터들에 기록한다. 두 개의 다른 도메인 사이에 공유되지 않는 레지스터들을 위해서는 상태가 기록될 필요가 전혀 없으며, 그러므로 이러한 레지스터들은 다른 도메인들로부터 억세스되지 않을 것이며, 상태간의 변환은 보안 도메인과 비보안 도메인 간의 직접적인 변환의 결과처럼 수행되질 것이다. (즉, CP15 레지스터들 중의 하나에 기록된 S 비트의 값이 공유되지 않은 레지스터들을 사용할 것인지를 결정한다.)
모니터 모드 중에 변환이 필요한 상태 정보의 부분은 프로세서에 의한 프로세서 설정 데이터 컨트롤 메모리 억세스과 관련된 부분이다. 각각의 도메인 안에는 다른 관점의 메모리가 존재한다. 예를 들면, 보안 데이터를 저장하기 위해 보안 도메인이 보안 메모리를 억세스하고 있을 때에는 이 보안 메모리는 비보안 도메인으로부터 억세스가 금지되며, 각각의 도메인 사이에서 변환 시에 프로세서 설정 데이터가 변경되어야 할 것이라는 것은 확실하다.
도 35에서 볼 수 있듯이, 프로세서 설정 데이터는 CP15 레지스터 34 안에 저장되며, 또한 이러한 레지스터들은 하나의 통합체에서 도메인들에게 공유되어진다. 그런 까닭에, 모니터 모드가 보안 도메인과 비보안 도메인 사이에서 변경될 때, 현재 CP15 레지스터 34에 들어있는 프로세서 설정 데이터는 CP15 레지스터의 외부에서 메모리 내부쪽으로 위치가 변경되어야 할 필요가 있으며, 또한 목적 도메인과 연관된 프로세서 설정 데이터도 CP15 레지스터 34 안에 로딩 되어야 한다.
일반적으로 CP15 레지스터에 있는 프로세서 설정 데이터가 시스템 안에서 메모리로의 억세스에 대한 즉각적인 효과를 가지고 있으므로, 프로세서가 모니터 모드에서 작동되고 있을 시에 프로세서에 의해 업데이트 되면, 즉각적으로 이러한 설정값들이 작용할 것이 분명하다. 그럼에도 불구하고, 모니터 모드에는 메모리로의 억세스를 조절하는 프로세서 설정 데이터가 정적 세트인 경우가 더욱 바람직하므로, 위의 경우는 바람직하지 못하다.
따라서, 도 35에서도 볼 수 있듯이, 동 발명의 통합체에서 모니터 모드 특수 프로세서 설정 데이터 2000이 제공되며, 이는 프로세서가 모니터 모드에서 작동되는 동안 CP15 레지스터 34 안의 프로세서 설정 데이터를 비활성화하는 데에 사용될 수도 있다. 이것은 CP15 레지스터에 저장된 프로세서 설정 데이터 및 모니터 모드 특수 프로세서 설정 데이터 2000 둘 다를 입력받을 수 있는 멀티플렉서(다중화기) 2010를 갖춤으로써 도 35에 설명된 통합체에서 달성되었다. 또한, 멀티플렉서 2010은 2015 경로를 따라 제어신호를 받는데, 이 제어신호는 프로세서가 현재 모니터 모드에서 작동하고 있는지의 여부를 알려준다. 프로세서가 모니터 모드에서 작동되지 않을 경우 CP15 레지스터 34에 있는 프로세서 설정 데이터가 시스템으로 출력되나, 모니터 모드에서 프로세서가 작동되는 경우에는 멀티플렉서 2010이 프로세서가 모니터 모드에서 동작될 때에 무모순의 프로세서 설정 데이터 집합이 적용되고 있음을 보장하기 위해 대신 모니터 모드 특수 프로세서 설정 데이터 2000을 출력한다.
조작될 수 없음을 보장하기 위하여, 모니터 모드 특수 프로세서 설정 데이터는 시스템 안에 하드코딩 될 수도 있다. 그러나 모니터 모드 특수 프로세서 설정 데이터 2000이 보안문제와 절충되지 않은 채 프로그래밍 될 수도 있으므로, 제공되는 모니터 모드 특수 프로세서 설정 데이터는 보안 특권 모드에서 수행되는 경우에만 한해서 프로세서에 의해 변경될 수 있다. 이것은 모니터 모드 특수 프로세서 설정 데이터의 세팅과 관련하여 어느 정도의 융통성을 허락할 것이다. 모니터 모드 특수 프로세서 설정 데이터가 프로그래밍이 가능토록 조정되는 경우에는, 그 설정 데이터가 시스템 내의 어느 적절한 장소, 즉 예를 들면 CP15 레지스터 34 내부 안에 구별된 레지스터 세트 내부와 같은 곳에 저장 될 수도 있다.
일반적으로, 모니터 모드에서 프로세서가 작동하는데 있어서 가장 안전한 환경을 제공하기 위해 모니터 모드 특수 프로세서 설정 데이터는 세팅 될 것이다. 그런 까닭에, 상기 실시예에서, 모니터 모드 특수 프로세서 설정 데이터는 프로세서가 모니터 모드 상에서 작동될 때에 메모리 관리 유닛 30을 사용금지하도록 지정할 것이며, 또한 메모리 관리 유닛이 억세스하지 못하도록 가상 어드레스를 물리적 어드레스로 변환하는 것을 금지한다. 이와 같은 상황에서, 메모리 억세스 요구를 송신할 때 프로세서는 플랫 매핑 등을 활용하여 항상 직접적으로 물리적 어드레스로 조정될 것이다. 이것은 가상 어드레스가 물리적 어드레스로 매핑되어 변경되었는지의 여부와는 상관 없이 프로세서가 모니터 모드에서 작동되고 있을 때에 신뢰성 있게 메모리에 억세스할 수 있도록 보장한다.
모니터 모드 특수 프로세서 설정 데이터는 또한 일반적으로 프로세서가 모니터 모드에서 수행될 때에 프로세서가 보안 데이터로의 억세스가 가능하도록 지정할 것이다. 이것은 도메인 상태 비트의 형태를 취하여 메모리 허가 데이터에 의해 즐겨 명시되며, 이 도메인 상태 비트는 보안 프로세서 설정 데이터 안에서 연관된 도메인 상태 비트("S"비트)를 위해 명시된 것과 동일한 값을 갖는다. 따라서 CP15 레지스터 내부에 저장된 도메인 상태 비트의 실제 값과는 상관없이 모니터 모드 특수 프로세서 설정 데이터에 의해 명시된 그 값은, 모니터 모드가 보안 데이터에 억세스하는 것을 보증하기 위해, 도메인 상태 비트에 의해 비활성화될 것이다.
모니터 모드 특수 프로세서 설정 데이터는 또한 메모리의 부분에 제어 억세스하기 위한 기타 데이터들에 관해서도 명시하고 있다. 예를 들면, 모니터 모드 특수 프로세서 설정 데이터는, 프로세서가 모니터 모드에서 작동되는 동안 캐시 38이 데이터에 억세스할 수 없도록 명시할 수 있다.
상기 설명된 통합체에서 프로세서 설정 데이터를 포함하고 있는 모든 CP15 레지스터들은 전부 다 도메인 간에 공유되고 있다고 생각되어진다. 그러나, 다른 대안의 통합체의 경우에서는 CP15 레지스터 중의 다수가 "뱅크화"되어, 예를 들면 프로세서 설정 데이터의 특별한 아이템을 저장하기 위해서 두 개의 레지스터가 있을 수 있도록 하게 된다; 하나의 레지스터는 비보안 도메인 상태에서 억세스할 수 있으며 비보안 도메인과 관련된 프로세서 설정 데이터의 아이템 값을 포함하고 있고, 다른 하나의 레지스터는 보안 도메인 상태에서 억세스할 수 있으며 보안 도메인과 관련된 프로세서 설정 데이터의 아이템 값을 포함하고 있다.
뱅크화 되지 않을 한 개의 CP15 레지스터는 "S" 비트 값을 갖게 되는 레지스터이지만, 원칙적으로는 CP15 레지스터의 다른 레지스터들은 원하는 경우 모두 뱅크화 될 수 있다. 이러한 구체화에 있어서, 모니터 모드에 의한 프로세서 설정 데이터의 변환은 공유된 레지스터들 안에 현재 존재하는 프로세서 설정 데이터를 공유된 CP15 레지스터로부터 꺼내와 메모리 안으로 옮기는 것이나, 목적 도메인과 연관된 프로세서 설정 데이터를 공유된 CP15 레지스터로 로딩하는 것과 연관된다. 뱅크화 된 레지스터들을 위하여 프로세서 설정 데이터가 메모리에 저장될 필요는 없으며, 대신에 공유된 CP15 레지스터와 연관 있는 S 비트 값의 변환의 결과로써 변환이 자동적으로 발생할 것이다.
앞서 언급된 대로, 모니터 모드 프로세서 설정 데이터는 연관된 CP15 레지스터에 저장된 것을 비활성화시키지만 보안 도메인에서 도메인 상태 비트로 사용되어진 것과 같은 값을 가지는 도메인 상태 비트를 포함할 것이다. (즉, 상기 서술된 통합체에서의 S 비트 값이 1인 경우) 많은 수의 CP15 레지스터들이 뱅크화 되었을 때, 이는 적어도 도 35에서 기술된 모니터 모드 특수 프로세서 설정 데이터 200의 일부분이, 이러한 레지스터들의 문맥이 변환 프로세스 도중에 메모리의 바깥에 적혀지지 않기 때문에, 뱅크화된 레지스터에 저장되어 있던 보안 프로세서 설정 데이터로부터 파생된 것일 수 있다는 것을 의미한다.
따라서, 하나의 예로써, 모니터 모드 특수 프로세서 설정 데이터는 도메인 상태 비트가 모니터 모드상에 있지 않을 경우에 사용될 것들과, 우선시 되는 통합체들에서 동일한 값을 가지고 있어서 보안 도메인에서 활용되던 것들을 비활성화시킬 것을 명시할 것이며, 이는 억세스가 가능한 뱅크화된 CP15 레지스터 중에서 어떤 것을 선별하는 로직이 보안 CP15 레지스터들에 억세스하는 것을 허용할 것이다. 모니터 모드가 이러한 보안 프로세서 설정 데이터를 모니터 모드 특수 프로세서 설정 데이터의 관련 분야로써 사용할 수 있도록 허가함으로써, 모니터 모드 특수 프로세서 설정 데이터의 아이템을 위해 분리된 레지스터 세트를 제공할 필요가 더 이상 없어짐에 따라 자원의 절약이 실현될 수 있다.
도 36은 한 도메인과 다른 도메인 사이에 변환이 요구되는 경우 프로세서 설정 데이터를 전환하기 위해 수행하였던 단계들을 설명하는 흐름도이다. 이전에 언급된 대로, SMI 명령어는 도메인 사이에서의 변환을 부추기기 위해서 호출된다. 따라서, 2020 단계에서, SMI 명령의 발행은 기다려진다. SMI 명령어를 받으면, 프로세서는 프로세서가 모니터 모드에서 모니터 프로그램을 수행시키기 시작하는 2030 단계까지 진행하며, 이는 모니터 모드 특수 프로세서 설정 데이터가 멀티플렉서 2010을 향한 2015 경로를 따른 제어 신호의 결과로써 사용되어지는 원인이 된다. 앞서 언급된 대로, 이것은 스스로 포함하고 있는 데이터의 세트일 수 있으며, 혹은 뱅크화 레지스터에 저장되었던 보안 프로세서 설정 데이터로부터 파생된 일정 부분일 수도 있다.
그 뒤로는, 2040 단계에서, 현재의 상태는 SMI 명령어를 호출하는 도메인으로부터 메모리를 향해 저장되며, 이것은 공유된 CP15 레지스터로부터 도메인과 연관된 프로세서 설정 데이터의 상태의 저장도 포함한다. 일반적으로, 그런 상태의 저장을 위해 남겨둔 메모리 부분이 있을 것이다. 그러면, 2050 단계에서, 상태 지시자는 그 목적 도메인을 위해 일치 한 상태를 포함하는 메모리의 부분을 가리키기 위해 교환된다. 그런 까닭에, 일반적으로, 상태 정보를 저장하는 데 대해서 할당된 메모리의 두 부분이 있을 것이다. 하나는 비보안 도메인을 위해 상태를 저장하는 데 대해서 할당했으며 다른 하나는 보안 도메인에서의 상태를 저장하기 위한 것이다.
상태 포인터가 2050단계에 위치하게 되면, 해당 하는 위치는 2060단계에서 등록 되는 공유된 CP15이며, 이는 목적지 도메인을 위한 데이터 구성 프로세스에 전달되는 데이터를 포함하게 된다. 그런 이유로, 모니터 프로그램은 종료되며, 프로세서는 모니터 모드 이후 목적도메인을 위한 필요한 다른 모드로 스위치 하게 된다.
도 37은 본 발명의 일 실시예에 의한 로직 30의 메모리 관리 유닛의 운용에 대해 자세한 설명을 나타낸다. 메모리 관리 로직은 메모리 관리 유닛(MMU) 200과메모리 보안 유닛(MPU) 220으로 구성된다. 코어 10에 의해서 요구되어, 가상의 어드레스를 부여 받은 어떤 메모리 억세스 이라도 패스 234 를 통해 MMU 200으로 도달하게 되며, MMU 200은 지정된 억세스 제한 기능을 수행하게 된다. 좀 더 자세히 볼때 이는 가상 어드레스에 상응하는 물리적 어드레스를 지정하고, 각 부분별 특질에 맞추어 억세스 허가 권한을 부여 할 수 있도록 한다.
데이터 프로세싱 장치의 메모리 시스템은 보안 메모리와 비보안 메모리로 구성되어 있으며, 보안 메모리는 보안 데이터를 저장하는데 쓰이며, 코어 10에 의해서만 억세스가 가능하거나 혹은 주 장비에서만 가능한데, 이 때는 핵심 혹은기타 장비가 보안 모드에서 동작하고, 그에 다른 보안 도메인이 동작하는 조건에 해당한다.
도 37에 표현되어 있는 본 발명의 실시예는, MPU 220내부의 파티션 체커에 의해 수행된 코어10에서 실행되는 어플리케이션에 의한 보안 데이터의 억세스 시도 정책에 대한 설명을 보충한다. MPU 220은 보안 운영 체제에 의해서 운영되며, 또한 보안 커널로도 불린다.
본 발명의 바람직한 실시예에 대해서, 보안 페이지 테이블 58은 비보안 메모리에 의해 제공이 되는데, 예를 들어서 외부 메모리 56의 비보안 메모리 부분은 해당하는 디스크립터 페이지 테이블 내부에서 지정된 영역으로 각각의 비보안 메모리가 저장된다.
디스크립터는 MMU가 기 지정된억세스 조절 기능을 수행할 수 있도록 요구되는 정보의 억세스 관리 정보를 수집하는 역할을 하며, 그에 따라 도 37를 참고하여 서술된 실시예는 가상 메모리의 물리적 메모리로의 매핑과, 억세스 허가 권한, 그리고 각각의 영역에 대한 속성의 정보를 제공한다.
게다가, 본 발명의 실시예 의하면, 최소한의 보안 메모리 58은 전체 보안 메모리 시스템에 의해서 제공되는데, 예를 들어서 외부 메모리 56의 보안 구역내부에서, 일부 메모리 영역이 디스크립터에 연계된 테이블 네에서 지정된 메모리 영역으로 다시 지정된다. 프로세서가 비보안 모드에서 동작될 때, 비보안 페이지 테이블은 메모리 억세스 관리 용도로써, 상응하는 디스크립터를 구하기 위해 지향된다. 그 동안 프로세서는 보안 모드에서 동작하고, 보안 페이지 상의 디스크립터가 사용된다.
MMU로의 상응하는 페이지 테이블을 추출하는 데는 다음의 절차가 진행된다. 코어10이 가상의 주소를 지정하여 메모리 억세스 요구를 수행하는 경우에, 해당되는 페이지 테이블에서 구해지는 물리적 어드레스 부분에 해당하는 가상 어드레스 부분 중의 하나를 저장하는 마이크로 TLB 206에서 찾기가 실행된다. 그래서, 마이크로 TLB206은 그 스스로의 내부에서 부합 되는 가상 어드레스 포션이 있는지 확인 하고, 비교하게 된다. 비교된 부분은 가상 주소의 비트 중 가장 중요한 몇 가지의 기지정된 숫자이며, 비트 수는 페이지 테이블 58내부 페이지의 입상(granularity)에 의존한다. 마이크로 TLB 206 내부의 찾기 기능은 상태적으로 빠른데, 8개와 같은 적은 수의 입력 수를 가지고 있기 때문이다.
마이크로 TLB 206상에서 부합되는 경우가 발생하지 않을 때, 메모리 억세스 요구는 패스 242를 거쳐서 주 TLB 208로 향하게 되며, 이는 페이지 테이블에서 구한 몇 가지의 디스크립터로 구성되어 있다.
이후 몇 가지 더 자세한 사항을 볼 것이나, 각각의 비보안 페이지 테이블에서 구한 디스크립터와 보안 페이지에서 구한 디스크립터는 주 TLB 208에서 공존 할 수 있으며, 주 TLB내부의 엔트리는 각각 해당하는 플래그(여기서는 도메인 플래그에 해당) 보안 페이지 테이블에서 구해진 디스크립터가 보안 페이지 테이블 혹은 비보안 페이지 테이블에서 구해진 건지 표시할 수 있는 가질 수 있다. 어떤 실시예에서도 모든 보안 모드 메모리 억세스 권한 요구에서 물리적 어드레스를 지정하는 모든 보안 모드에서, 주 TLB내에서 그러한 플래그의 요구가 없다는 것이 주목할 만하고, 해당 TLB는 단순히 저장 비보안 디스크립터이다.
주 TLB 208에서, 비슷한 검색이 TLB 208 의 특수한 모드에서 수행되는 디스크립터와 관련한 가상 어드레스 부분 모두에 상응하는 메모리 억세스 요구에서 제기된 가상 주소의 부분인지 하는 결정을 한다. 그러므로, 만약 코어10이 비보안 모드에서 동작하면, 그와 같은 디스크립터 만을, 비보안 페이지 테이블 로부터 구해진 주 TLB 208에 의해 체크를 받으며, 반면에 만약 코어10 이 보안 모드에서 동작한다면, 보안 페이지 테이블에서 구해진 TLB만이 체크를 받는다.
그와 같은 검사 프로세스의 결과가 주 TLB안에 있다면 억세스 관리정보는 해당하는 디스트립터에서 추출되며, 패스 242로 다시 전달 된다. 특별히 가상 어드레스 부분과 그에 해당하는 물리적 어드레스 부분의 디스크립터는 패스 242를 통해 마이크로 TLB 204로 라우트 되며, 마이크로 TLB의 입력값의 저장을 위해서, 억세스 권한이 억세스 권한로직 202로 로드되며, 영역 특성값은 억세스 권한 204로 로드되게 된다. 억세스 억세스 권한 202와 영역 특성값 204는 마이크로 TLB를 향해 분산되거나, 혹은 마이크로 TLB로 합쳐 지게 된다.
이 부분에서 MMU 200은, 마이크로 TLB 206 내부에서 발생 할 것이기 때문에, 메모리 억세스 요구를 제어 할 수 있게 된다. 그에 따라서, 마이크로 TLB206 은 해당 메모리로 라우트 하기 위한 시스템 버스 40으로의 패스 238로 출력 될 수 있는 물리적인 어드레스를 생성하며, 이는 TCM36, 캐쉬 38, 기타 등등의 온칩 메모리에 존재 하거나, 혹은 외부 버스 인터페이스 42를 통한 외부 메모리 유닛에 존재 할 수 있다. 동시에, 억세스 권한 202는 메모리가 허가를 받은 것인지 결정하게 되고, 그리고 패스 230을 통해 코어 10으로 시그널을 취소하는데, 이는 만약 코어가 특정한 메모리 위치의 억세스 권한 동작모드에 지정되어 작동할 수 있도록 하지 않았을 때 이다. 예를 들어서, 특정 부분의 메모리가 보안 모드에 있거나 혹은 비보안 모드에 있을 때, 단지 코어가 관리자 모드에 있을 때 억세스가 가능하거나, 그에 따라 혹은 코어 10이 유저 모드 같은 메모리 위치에 있을 때 검색을 하는 경우 억세스 권한 로직202는 코어 10이 현재 적당한 억세스 권한을 가지고 있지 않을 때 패스 230으로의 시그널을 취소하게 된다. 이는 메모리 억세스를 취소하는 것을 야기 하게 된다. 최종적으로, 영역 속성 로직 204는 특정한 부분의 메모리 속성을 결정하게 되고, 예를 들어서 억세스가 캐쉬를 사용하는가, 버퍼를 사용하는가 등이고, 패스 232와 같은 시그널을 발생 시키는데, 패스 232는 메모리의 데이터가 억세스 요구가 캐쉬화 될 수 있는지, 예를 들어서 캐쉬 38 등, 데이터 쓰기 권한 이 버퍼화 될 수 있는가등등 이다.
주 TLB 208에서 어떤 요구가 없을 때, 해석 테이블 로직 210이 해당하는 페이지 테이블 58을 패스 248을 통해 요구되는 디스크립터를 추출해 내기 위해서 사용되고, 그리고 패스 246을 통해 디스크립터는 주 TLB208에 저장하기 위함이다. 비보안 메모리와 보안 메모리는 주 어드레스 를 CP 15 34 등의 레지스터에 저장되게 되고, 보안 도메인이나 혹은 비보안 도메인 같은 프로세서 코어 10이 동작하는 현재 도메인 등에서 도메인 상태는 비보안 도메인과 보안 도메인 혹은 그 반대의 경우에 발생하는 작업등이있을 때, 모니터 모드에 의해 도메인 상태 레지스터가 지정된다. 도메인 상태 레지스터의 내용은 그의 도메인 비트로 이해 되기도 한다. 그에 따라, 만약 해석 테이블 작동 프로세스는 수행되고, 해석 테이블 수행 로직 210은 코어 10이 수행되는 도메인에 대해 알게 되고,
그에 따라 베이스 어드레스에 해당하는 테이블에 사용된다. 가상 어드레스는 주 어드레스에 요구되는 디스크립터를 구하기 위한 적당한 페이지 테이블 내부에서 적합한 엔트리로의 접속을 위해 주 어드레스로의 오프셋으로 사용되게 된다.
디스크립터가 해석 테이블 운용 로직 210에 의해 추출되고, 주 TLB 208에 위치하면, 억세스가 주 TLB내부에서 구해지게 되며, 이전에 설명한 프로세스가 억세스 관리 정보를 받기 위해 호출하게 된다. 그리고 마이크로 TLB 206에 이를 저장하며, 억세스 권한 로직 202와 영역 속성 로직 204에도 저장이 된다. 메모리 억세스는 MMU 200에 의해 수행된다.
기존에 언급한, 수행 방법에 대해서, 주 TLB 208은 보안 페이지 테이블과 비보안 페이지 테이블에 저장을 할 수 있으나, 메모리 억세스 요구는 단지 MMU 200에 의해서며, 이는 마이크로 TLB 206에 그 정보가 저장 되었을 때 의한다. 수행 방법에서, 주 TLB 208 과 마이크로 TLB 208사이의 데이터전송에 대해서는, MMU 220 하의 부분 체커 202에 의해 모니터를 하게 되며, 이를 확실하게 하기 위해, 그 환경에서 코어 10은 비보안 모드에서 동작하게 되고, 보안 메모리 내에서 생성되도록 물리적 주소가 작용한다면, 주 TLB 208의 디스크립터로부터 마이크로 TLB 206으로 전송되는 정보에 대한 어떤 권한도 거부하게 된다.
메모리 보안 유닛은 보안된 운영체제에서 관리 되는데, 이는 CP 15 34등의 레지스터의 부분 정보 를 지정하고 보안 메모리와 비보안 메모리를 판단할 수 있다. 파티션 체커 222는 비보안 모드를 보안 모드로, 코어 10에 의해 억세스를 허가 할 수 있도록 마이크로 TLB 206으로 전송되는 억세스 관리 정보인지 판단할 수 있기 위한 부분 정보를 참고할 수 있게 한다. 좀 더 특별하게, 수행 방법에 있어서, 코어 10이 비보안 모드 운영체계로 동작하는 경우에, 지적 하였듯이 도메인 모드에서 도메인 비트로 지정된 도메인 상태 레지스터에서, 부분 체커 222는 패스 244를 주 TLB 208에서 마이크로 TLB 206으로 물리적인 어드레스를 받기 위해 동작하거나, 보안 메모리 내의 물리적 어드레스 부분에 기인한 가상 어드레스를 통한 물리적 어드레스인지 결정하는 부분에 사용 된다. 그러한 환경에서는, 부분 체커 222는 코어 10에 패스 230을 통해서 발생 지점에 대한 메모리 억세스를 방지하는 취소 시그널을 보내게 된다.
부분 체커 222가 실제로 마이크로 TLB 206에서 저장되는 물리적 어드레스 포션을 방지 할 수 있도록 준비 되거나 혹은 마이크로 TLB 206에 저장되어 있는 점은주목할 만하나, 그 취소 프로세스의 일 부분은 마이크로 TLB 206에서의 잘못된 물리적 어드레스를 제거하는 것인데, 예를 들어 마이크로 TLB 206으로 모으는 것 등이다.
코어 10이 보안 모드 혹은 비보안 모드상에서 모니터 모드를 통에 동작 형태를 바꿀 때 마다, 모니터 모드는 도메인 상태 레지스터인 CP15를 프로세서의 운영이 바뀔 때마다 표시 하기 위해 변경된다. 도메인 사이의 전송 절차의 부분 중 하나로, 마이크로 TLB 206은 보안 도메인과 비보안 도메인 사이의 데이터 전송을 한데로 모으게 되고, 마이크로 TLB 206 상에서의 오류를 만들게 되며, 주 TLB 208에서 억세스 정보를 받도록 요구하거나, 혹은 해당하는 페이지 테이블에서디스크립터를 받을 수 있도록한다.
위와 같은 억세스에 의해, 부분 체커 222는 코어가 비보안 모드에서 동작을 할 때, 보안 메모리로의 억세스를 시도 하는 마이크로 TLB 206에서의 억세스 정보를 받을 수 있게 되었을 때, 메모리 억세스 취소 프로세스가 생성이 되게 된다.
프로세서 코어 10의 어떤 동작 모드에서든 메모리 억세스 요구는 지정된 물리적 어드레스로 준비 되고, 그와 같은 동작모드에서 MMU 200은 비활성화 되며, 물리적 어드레스는 패스 236을 통해 MPU 220으로 향하게 된다. 보안 모드로 동작하는 중에는 억세스 권한 로직 224와 영역 특성 로직 226은 요구되는 억세스 권한을 수행하게 되며, 영역 속성 조사를 CP 15 34내의 부분 정보 레지스터의 해당하는 영역을 구분 하기위한 억세스 권한 과 영역 정보를 이용하게 된다. 어떤 특정한 모드에서 동작하도록 보안 메모리 내의 일부가, 보안 메모리 내를 검색하도록 되어 있다면, 예를 들어서 보안 특별 모드에서라면, 그와 같은 환경에서 취소 프로세스를 생성하도록 MMU의 억세스 권한 로직202가 코어 내에서 억세스 권한 로직 224를 야기 시켜서 패스 230을 통해 취소를 실행한다. 비슷한 방법으로, 영역 속성 206은 캐쉬나 혹은 버퍼가 가능한 시그널을 비슷한 방법으로 생성하며, 그 방법은 가상 어드레스로 이루어진 MMU의 영역 속성 로직 204 가 만들어내는 메모리 억세스 요구이다. 그 억세스가 가능하다고 가정해 보면 그 프로세스는 패스 240을 거쳐 시스템 버스 40에 도달하게 되며, 그 곳은 해당하는 메모리 유닛이 라우트 되는 곳이다.
물리적 어드레스로 억세스 요구가 지정되는 비보안 모드를 위해, 억세스 요구는 패스 236을 통해 부분 체커 222로 라우트 되고, 이는 취소 시그널이 패스 230을 통해 다시 만들어지는 이벤트 내에서 위치가 보안 메모리로 지정되는 물리적 어드레스인가를 결정하기 위한 CP15의 레지스터 34의 부분 정보를 참고하기 위한 부분검사를 수행하게 된다.
위의 묘사된 메모리 관리 유닛의 프로세싱은 도 39와 40에 흐름도를 통해 자세히 표현되어 있다. 도 39는 단계 300에 표시 되어있는 대로 코어 10에서 프로그램에 동작하며 물리적 어드레스를생성하는 것을 볼 수 있다.
CP 15의 도메인 상태 레지스터 34가 모니터 모드에서 이후 보안 도메인이나 혹은 비보안 도메인 상태로 현재 동작하는 지를 표시 하게 된다. 그 이벤트 상에서 만약 코어가 보안 도메인으로 동작하고 있다면, 마이크로 TLB 상의 가상 어드레스 부분 중의 하나가 가상 어드레스 주소 내에서 일치하는 지, 마이크로 TLB 상에서 검색을 수행하게 된다. 단계 302에서 발생하는 이벤트에서, 프로세스 분기는 단계 312를 향하게 되며, 이는 억세스 권한로직 202가 필요한 억세스 권한 분석을 수행하게 되는 곳이다. 단계 312는 억세스 권한 위배가 있는지, 만약에 프로세스가 패스 230을 통한 억세스권한 로직 202을 제기하는 단계 316에 있는 지를 결정하게 된다. 그렇지 않다면, 그러한 억세스 권한 위배 상황에서, 프로세스는 단계 314에서 318 까지 진행 되며, 이는 메모리 억세스가 진행되는 것으로 볼수 있다. 특별히 영역 속성 로직 204는 필요한 캐쉬 와 버퍼가 가능한 속성등을 패스 232를 통해 발생시키고, 마이크로 TLB 206은 기존에 설명한대로 패스 238을 통해 물리적인 어드레스를 생성한다.
만약 단계 302에서 마이크로 TLB상의 오류가 있는 경우에는, 주 TLB 208에서의 단계 304가 주 TLB상의 필요한 주 디스크립터가 실행 중인지 검사 프로세스가 수행된다. 그렇지 않은 경우에는, 페이지 테이블 업무 프로세스가 단계 306에서 수행되고, 그 반면에 해석 테이블 수행 로직210 은 보안 테이블 모드에서 필요한 디스크립터를 구하고, 이전에 도 37에 설명된 방법과 같다. 프로세스는 단계 308로 진행이 되거나 혹은, 단계 304에서 308로 바로 진행되는데, 이는 보안 디스크립터가 이미 주 TLB 208에 있는 경우에 한한다.
단계 308에서, 옳은 표시가 된 보안 디스크립터를 포함했다는 것을 결정하고, 그에 따라 프로세스는 단계 310으로 진행되는데, 마이크로 TLB는 물리적 어드레스 부분을 포함한 디스크립터의 부분 섹션과 함께 로드 된다. 코어 10이 보안 모드에서 동작하는 관계로, 부분 체커 222가 부분 검사 기능을 수행할 필요는 없다.
메모리 억세스의 나머지 부분인 단계 321로의 진행은 이미 전에 설명 된 부분이다.
비보안 메모리 억세스 이벤트에서, 프로세스는 단계 300 에서 320으로 진행되는데, 해당하는 물리적 어드레스가존재하는 비보안 디스크립터로부터 발생되었는 지를 검사하기 위해서이다. 만약 그러하다면, 프로세스 분기는 바로 단계 336을 향하게 되고, 이 곳에서 억세스 권한 로직 202를 통해 억세스 권한이 검사를 받게 된다. 이것은 중요하게 지적 되는 부분으로, 만약 해당하는 물리적 어드레스 부분이 마이크로 TLB상에 있다면, 이것은 마이크로 TLB상에 저장되기 전에 기존의 정보가 이미 비보안 정보라는 것을 의미한다. 단계 336 에서 338로 진행 될때, 메모리에 대한 어떤 위배가 없다면 이는 338로의 진행을 의미한다. 이는 다른 메모리 단계로 진행 되었을 때의 이야기이며, 이는 이후에 설명하기로 한다.
마이크로 TLB 에 320상에 발생하는 내용이 없는 경우에, 마이크로 TLB 208상에 비보안 디스크립터가 존재하는가를 단계 320에서 검사하게 된다. 그렇지 않은 경우에는, 단계 324에서 해석 테이블 수행 로직 210상으로 마이크로 TLB 208에 필요한 비보안 디스크립터가 비보안 페이지 테이블에서 로드 되었는지를 검사하게 된다. 프로세스는 단계 326으로 진행하게 되고, 혹은 바로 단계322에서 326으로 진행 되는데, 이는 마이크로 TLB 208에서 322에 대한 호출이 있는 경우에 해당한다. 단계 326에서는 주 TLB가 올바르게 매겨진 비보안 디스크립터를 가상 어드레스에서 받아 왔는지 검사하고, 메모리 억세스 요구으로부터 가상 어드레스를 정상적으로 받아 왔는지 단계 328에서 부분 체커 222를 통해 검사하게 된다.(디스크립터 내부에서 물리적 어드레스가 주어진다).이는 또한 비보안 메모리로 위치하게 된다. 만약 그렇지 않다면, 예를 들어서 물리적 메모리가 보안 메모리에 위치 하게 될 때, 단계 330에서 보안 위반이 있는 지 확인하고 프로세스는 단계 332로 진행 하는데, 이는 보안/비보안 오류가 부분 체커222에 의해 제기되어 취소 프로세스가 동작한다.
부분 체커 로직 222는 보안 오류가 없는지 확인하고, 단계 334로 진행하게 되며, 마이크로 TLB 상의 해당하는 부분의 마이크로 TLB로 로드되어 물리적인어드레스 부분을 포함하고, 단계 336에서 이전에 설명한 방법대로 메모리 억세스를 시도 하게 된다.
도 40에 나온대로 물리 메모리는 억세스 요구를 하게 된다. 기존에 설명한대로, 이와 같은 시나리오에서, MMU 200은 비 활성화 되고, CP 15의 MMU활성화 유닛에 의해서 선택 적으로 재 수행 된다. 이 세팅은 모니터 모드에 의해 수행된다. 그래서, 단계 350에서는 코어 10 이 물리적인 어드레스를 MPU 220을 통해서 패스 236을 지나 만들어 내게 된다. 그러면 단계 352에서 MPU 220는 해당 권한을 검사하여 메모리 억세스 요구가 현재의 운용 형태, 예를 들어서 관리자, 유저, 모드 등등을 확인한다. 그리고, 만약에 운용 모드가 비보안 모드인경우에는, 부분 체커 222는 또한 단계 352로 이동하여 물리적 어드레스가 비보안인 상태로 지정된다. 단계 354에서는 예를 들어서 메모리 관리 권한에서의 오류가 있는지 확인 하게 되고, 비보안 모드에서의 문제가 없는지도 구분하게된다. 만약 이 중의 어느 하나의 위반이 발생하는 경우에는, 단계 356에서 MPU 220쪽으로 위반 경고 메시지를 보내게 된다. 본 수행방법에서는 두 가지의 취소가 발생하는데, 선택적인 시그널이 억세스 권한 금지나 혹은 보안 금지 등이 이에 해당한다.
단계 354에서 다른 보안 오류가 발견되지 않았다면,358로 진행하게 되고, 메모리 억세스를 통해 물리적 어드레스가 발생 하였는지 구분하게 된다.
본 수행 방법에서는 모니터 모드만이 물리적 어드레스를 직접적으로 준비 할 수 있다고 설명하고 있고, 그에 따라 모든 MMU 200이 관련된 경우에는 이전에 설명한대로 가상 메모리 어드레스가 물리적 메모리 어드레스를 통해 가능해 진다는 것을 이미 설명해 놓고 있다.
도 38은 가상 메모리 어드레스가 지정 된 형태에서의 선택 적인 메모리 관리 형태의 모습을 보여 주고 있다. 그리고 이는 물리적 어드레스가 직접적으로 메모리 관리에 관여 하지 않음을 보여준다. 이 시나리오에서, MPU 220은 필요한 부분이 아니며, 대신에 부분 체커 220이 MMU 200과 같이 운용되고 있다. 이는 도 37, 39에서 설명한 것과 같은 내용으로 볼 수 있다.
다른 형태의 작업들도 가능 하다는 것이 주목할 만 하다. 예를 들어서 비보안 모드에서는 두 개의 MMU가 동시에 작업이 가능하며, 하나는 보안 모드에서, 또 하나는 비보안 모드에서도 작동할 수 있게 된다. 예를 들어서 도 37의 MMU 220은 완전히 다른 MMU와 교체 될 수도 있다. 이런 경우에서는 플래그의 사용이 보안 디스크립터와 비보안 디스크립터를 구분할 수 있는 기준으로 사용되며, 주 TLB내에 비보안 데이터와 보안 데이터 저장의 구분을 도와주게 된다. 비보안 도메인이 코어에 저장되도록 시도할 때, 또한 부분 체커가 동작하여 그 내용을 파악한다.
만약에 그 대신에 모든 메모리 억세스가 물리적인 어드레스를 요구하는 경우에는, 두 개의 MPU상에서 그 처리를 받아들여 하나는 보안 모드, 다른 하나는 비보안 모드로 동작하게 된다. 비보안 모드는 부분 체커를 이용한 작업에 들어가게 되며, 보안 모드는 비보안 모드 데이터가 들어 갈 수 없도록 처리된다.
도 37에서 이미 제공한 기능에 관련해서, 부분 체커 222는 해석 테이블 작업 로직 210에 대한 활성화 정책을 검사하게 된다. 특별히, 코어가 현재 비보안 도메인 상에서 작업되고 있는 중이라면, 부분 체커 222는 로직 210이 데이터를 검색하고 있는 동안에 비보안 페이지 보다는 보안 페이지 상에서 동작 하는지를 검사하게 된다. 로직 210이 일반적으로 가상 어드레스의 특정 비트를 검사하여 두 개의 모드를 전부 검색하기 때문에, 예를 들어서 부분 체크가 활성화된 상태에서는 보안 페이지 테이블에서의 베이스 어드레스 보다는 비보안 페이지 베이스 어드레스에 로직 210의 검사가 수행 된다.
도 41은 부분 체커 222가 비보안 모드상에서 동작하는 것을 보여 주고 있다. 일반적은 동작 모드에서 비보안 페이지 테이블은 비보안 메모리 상에서만 매핑되는 것을 볼 수 있다. 그러나 소프트웨어공격의 경우에는 디스크립터는 표현된대로 비보안과 보안 메모리 상에서 간섭을 받게 된다. 그러므로, 도 41에서 고려되는 것 처럼, 단계 370, 372, 374 등에서 혹은 보안 영역인 376, 378,380 등에서의 페이지를 보안 할 수 있도록 비보안 디스크립터가 동작한다. 만약 가상 어드레스가 메모리 접속 요구의 일부분이라고 한다면, 물리적 어드레스는 보안 메모리 영역에 물리적 어드레스로 응답이 되고, 예를 들어서 메모리 영역 376이 도 41에 표시된 경우처럼, 부분 체커 222는 금지된 억세스를 취소할 수 있도록 생성된다. 반대로, 만약 물리적 어드레스가 디스크립터에서 추출되어 비보안 메모리 영역으로 포함된다면, 영역 374의 예 처럼(도 41) 억세스 관리 정보가 마이크로 TLB 206으로 로드되어 순수하게 보안 영역 374로 넘어가게 된다. 그러므로, 비보안 메모리 영역 374는 보안 영역 376, 378, 380이 발생할 수 있으나, 억세스는 불가하게 된다. 고로, 이것은 주 TLB 208이 비보안 페이지 테이블이 간섭 받거나 할 때 나타나며, 마이크로 TLB는 단지 물리적인 어드레스로 비보안 메모리 영역에서 억세스가 가능하도록 물리적 메모리 부분을 포함할 뿐이다.
기존에 설명 된대로, 본 실시예에서 보안 메모리와 비보안 메모리는 가상 어드레스를 지정할 수 있으며, 보안 페이지와 비보안 메모리 사이 혹은 그 반대의 경우에 선택적으로 모드를바 꿀 수 있도록 하고 있다. 비보안 모드상태에서, 비보안 페이지는 해석 테이블 로직 210의 영향을 받으며, 도 42는 이 부분에 대한 예를 도1에 나와 있는 외부 메모리 56의 예와 같이 들고 있다. 이는 비보안 페이지 테이블 395에서 CP15의 레지스터 34를 참고로 베이스 어드레스 397로 인식되고 있는 것이다. 비슷한 경우로, 보안 메모리 400의 경우에는, 도 1의 외부 메모리 56내부의 것처럼, 보안 페이지 테이블 405는 복제된 CP 15의 레지스터 34 내부에서 제동되면 이는 베이스 어드레스 407에 근간을 두고 있다. 각각의 디스크립터는 비보안 페이지 테이블 395 내부에서 비보안 페이지 메모리 390으로, 그 반면에 보안 페이지 테이블 405 내부에서 각각의 디스크립터는 정의를 내릴 수 있게 된다. 게다가 이후에 설명한 부분이나, 공유 메모리 영역 410내의 특정 메모리 영역은 비보안, 보안 메모리 모드 양쪽에서 억세스가 가능하다.
도 43은 마이크로 TLB 208이 도메인 플래그 425를 이용해 본 실시예에 대한 실행을 하는 것을 설명하고 있다. 디스크립터 435 는 보안 페이지 혹은 비보안 페 이지 테이블에서 구분이 된다. 이 는 검색 프로세스가 수행 되었을 때, 코어 10에 해당하는 특정 도메인이 검사 되었을 때의 경우이다. 도 43은 코어가 보안 도메인 상에서 동작하는 것에 대한 예를 보여 주고 있고, 보안 모드에 해당한다. 도 43에서 보듯이, TLB 208 검색이 수행 되었을 때, 이는 디스크립터 440이 무시 되었다는 것을 의미하며, 디스크립터 445가 검사 프로세스에 사용되었음을 의미한다.
구한 방법에서 프로세스 아이디 430은 또한 ASID플래그라고 명명되며, 이는 특정 페이지 테이블에서 추출된 디스크립터를 의미한다. 모드에 따라 프로세스 p1, p2,p3, 은 각자의 메모리 상의 페이지 테이블에서 추출되며, 이후에 비보안 모드와 보안 모드 양 쪽에서 전체적으로 분류되어 p1, p2, p3는 보안 및 비보안 도메인 상에서 작동한다. 도 43에서 볼 수 있듯이, TLB 208이 필요할 시에는 ASID플래그도 같이 동작하는 것을 불 수 있다.
도 43의 예에서 보안 도메인을 볼 수 있듯이, 프로세스 p1이 수행 중에는, 주 TLB 208에서의 450개의 엔트리가 검사 프로세스 내에서 구분이 되며, 메모리 억세스 요구에 따라 가상 메모리의 해당하는 부분에 대한 검사가 종료된 이후에, 실행 혹은 오류가 나타나게 된다. 만약 실행시에는, 해당 억세스 관리 정보가 micro TLB 206 상에서 억세스 권한 로직202로 정보를 보내고, 영역 특성 로직 204로 억세스를 하게 된다. 그 외에 오류가 발생하는 경우에는 해석 테이블 수행 로직210이 주 TLB 208로의 디스크립터를 보안 프로세스 p1으로부터 수행하게 된다. TLB의 내부에는 많은 관리 기술이 포함되어 있으며, 새 디스크립터가 생성된 경우에는 주 TLB 208로 저장이 된다. 만약 TLB가 포화 상태라면, 새 디스크립터에 대해 기존에 억세스 한 방법으로 재사용 하거나 혹은, 일부 디스크립터를 제외하여 공간을 확보 할 수 있도록 한다.
보안 커널은 보안 모드의 동작시 사용되며, 전체적으로 비보안 운용 체제에서 개발되기도 한다. 그러나, 특정한 경우에서 보안 커널은 비보안 운영 체제에서 비보안 디스크립터를 사용하기 위해 개발되기도 한다. 확실히, 이는 보안 어플리케이션을 비보안 데이터로 억세스 할 수 있도록 하며, 단지 가상 어드레스를 아는 것만으로도 가능하다. 이 경우에는 보안 가상 매핑과 비보안 가상 매핑이 특정한 ASID상에서 제외 되는 것을기존에 가정하고 있다. 이런 시나리오에서는, 도메인 플래그 등의 태그가 보안 / 비보안 디스크립터를 구분 하지는 않는다. TLB의 검색은 대신에 모든 가능한 디스크립터를 찾는데 이용된다.
본 실시예에서 주 TLB의 설정을 선택은 이전에 구성된 분리된 보안 및 비보안 디스크립터에서 CP 15의 관리 레지시트에서 제공된 특정한 비트에 의해 구분이 된다. 본 실시예에서 이 비트는 단지 보안 커널에 의해 정해진다.
보안 어플리 케이션이 직접적으로 비보안 가상 어드레스를 사용할 수 있도록 한 경우에, 비보안 스택 포인터가 보안 도메인 상에서 가능하게 된다. 이는 비보안 레지스터의 값을 복제하여 쓸 수 있도록 한다. 이는 비보안 어플리케이션이 보안 어플리케이션에 의해 이해된 스킴에 따라 파라미터를 저장 할 수 있도록 한다.
기존에 설명 된대로, 메모리는 보안과 비보안으로 구분되며, 이 구분은 CP 15 레지스터의 34의 보안 커널에 의해 결정된다. 이 기본적인 구분 방법은, 영역 억세스 권한 에 의해 mpu 장치와 함께 지정된다. 그에 따라 메모리는 각각의 영역으로 구분되며, 각각의 영역은 선택적으로 각각의 주 어드레스, 사이즈, 메모리 속성과 억세스 권한을 가지게 된다. 게다가 오버랩 영역이 프로그램 된 경우에는, 상위 영역의 속성이 가장 높은 우선권을 가진다. 게다가, 본 발명의 실시예에 의하면, 새 영역 속성은 보안 메모리 비보안 메모리에 해당하는 지정을 할 수 있도록 한다. 이 새 영역 속성은 보안 커널에서 보안 메모리로 보안되는 부분을 지정하여 보안 커널에서 사용할 수 있도록 한다.
부트 단계에서, 처음 부분은 도 44에서 설명한 대로 수행이 된다. 이 초기 부분은 메모리 460에 할당되는 비보안 부분이며, 비보안 운영체계와 비보안 어플리케이션을 위해 쓰인다. 이 양은 전체 부분에서 비보안 영역으로 구분된다. 이 정보는 이후 비보안 운영체계에서 관리 측면으로 사용된다. 나머지 메모리 462, 464 등은 보안 메모리로 운영체계에 의해 결정된다. 비보안 체계의 전체적인 보안을 위해서, 비보안 메모리는 보안 특권 모드 상에서만 수행된다. 고로, 보안 어플리케이션은 이 부트 단계 부분에서 메모리 460이 비보안 운영체계 안에서 사용 가능한지 확인하고 메모리 462는 보안 커널에서 464는 보안 어플리케이션에서 사용 가능할 수 있게 한다.
부트 단계가 수행되면, 비보안 메모리 460의 부트 단계는 비보안 운영 체계에 의해 수행되며, MMU 200을 사용하여 일상적으로 비보안 페이지에서 지정될 수 있는 일련의 작업을 수행하는데, 이는 도 45에 표현되어 있다.
보안 어플리 케이션이 비보안 어플리케이션과의 메모리 공유를 요구하는 경우, 보안 커널은 부분적으로 메모리 를 기 도메인에서 다른 쪽으로 전송 할 수 있게 한다. 따라서, 도 46에 설명 되어 있는 것 처럼, 페이지 변환은 보안 페이지 466처럼 공유 메모리로 사용 될 수 있다.
메모리의 부분이 변경 되는 경우에, 마이크로 TLB 206은 통합 되어야 한다. 이는 이 시나리오에서 비보안 억세스가 발생하는 경우에, 마이크로 TLB 206상에서 에러가 발견이 되면, 새로운 디스크립터가 TLB 208상에서 로드 된다. 이 새로운 디스크립터는 부분 체커 222를 검사하여 MPU 220의 시도를 새로운 마이크로 TLB 206상에서 받을 수 있도록 하고, 새로운 메모리 영역을 지정하게 한다.
본 실시예에 있어서, 캐쉬 38은 가상 인덱스와 물리적인 태그를 소유하게 된다. 그에 따라 캐쉬 38의 억세스가 수행되면, 마이크로 TLB 208상에서 먼저 검사가 수행이 되고, 억세스 권한과 보안, 비보안 권한이 검사된다. 캐쉬 38에서는 보안 데이터는 저장 될 수 없으며, 비보안 어플리케이션에서 이를 수행한다. 캐쉬 38에 대한 억세스는 부분 체커 222에서 수행이 되며, 이는 비보안 모드 상에서 수행 되어 보안 데이터의 억세스를 차단한다.
그러나 한가지 문제가 발생할 수 있는데, 비보안 도메인 상에서의 어플리케이션은 캐쉬를 부적절하거나, 깨끗하거나 혹은 정리 해야 할 경우가 있다. 이는 운영체제에 영향을 주지는 않는다. 예를 들어서 운영 체계가 캐쉬 38을 초기화 하지 않고 사용하는 경우에 오염된 보안 데이터는 외부 메모리로 교체 된다. 선택 적으로 보안 데이터는 캐쉬에 태그 된 상태로 존재하며, 다른 형태로 관리된다.
실시예에서 만약 "어드레스에 의한 적절치 못한 선형" 운용이 비보안 프로그램에 의해 수행된다면, 물리적 어드레스 부분 체커 222에 의해 수행이 되고, 캐쉬 라인이 보안 캐쉬 라인인 경우에는 "청소 및 부합되는" 운용 모드로 수행이 된다. 이는 시스템의 보안을 위함이다. 게다가 본 실시예에서 "인덱스에 의한 부합"운용은 비보안 프로그램에서 수행되어 인덱스에 의한 부합 운용으로 바뀐다. 비슷하게, "모드 비 부합적인" 운용은 비보안 프로그램에서 "깨끗하고 전부 부합되는" 운용으로 바뀐다.
게다가 도 1의 참고 내용에서 TCM36으로의 모든 억세스(DMA32)은 마이크로 TLB 206에 의한다. 고로 DMA32가 모든 가상 어드레스를 물리 어드레스로 변환하는 경우에는, 기존의 플래그가 주 TLB상으로 억세스할 수 있도록 코어 10에서 제기된 억세스 요구에 의해 검사를 수행한다. 그리고 나중에 언급하겠지만, 외부 버스 70에서 복제된 외부 체커가 동작하며, 선택적으로 아비터/ 디코더 블록 54에 위치한 DMA32로의 직접적인 억세스가 가능한 등의 모든 억세스에 대한 검사를 수행한다. 그리고, 특정한 실시예에서 CP 15 레지스터 34가 DMA 32가 비보안 도메인 상에서 쓰일 수 있는 지 검사를 하며, 이 비트는 단지 보안 커널에서 특정 모드로 수행 될 때만 사용이 가능하다.
TCM 36을 고려할 때, 보안 데이터가 TCM 36에 존재하는 경우에는, 이는 조심해서 다루어야 한다. 예로, 비보안 운영체계에서 물리적 어드레스의 범위가 TCM 36메모리인 경우에는 외부 보안메모리 부분도 겹쳐지게 된다. 만약 운영체계가 보안 모드로 전환이 된다면, 보안 커널은 데이터를 중첩되는 부분에 저장하게 되고, 이는 TCM 36 이 높은 우선권을 가지게 되어 다양한 이점의 보안 영역이 매핑되어 비보안 영역의 물리적 메모리에 위치하게 된다. 이것은 비보안 운영 시스템에서 보안 데이터를 접속할 수있게 하며, 부분 체커가 비보안에 대한 취소를 수행 할 수 없게 한다. 고로 정리하자면 만약 TCM이 일반 로컬 램이고 스마트 캐쉬가 아닌 경우에는 비보안 운영체계는 보안 영역의 데이터를 만약 TCM의 물리적 어드레스가 이동할 수 있다면 억세스가 가능하다는 것이다.
이와 같은 시나리오를 방지하기 위해, 관리 비트가 실시예 내의 CP 15 레지스트 34에 대해 단지 특정 모드에서만 억세스가 가능하도록 되어 있다. 이는 두 가지 설정으로 구성되어 있는데, 첫 번째 구성에서는 비트 수를 1로 지정하여, TCM이 단지 콘트롤 레지스터를 CP 15 레지스터 34를 통해서 정의 되어 있지 않은 예외가 허용되는 것을 방지하기 위함이다. 두번 째 설정은 관리 비트를 0으로 설정하여, 비보안 운영 체계에서 TCM이 관리를 할수있도로 하게 한다. TCM을 통해 보안 데이터가 저장 할 수 없도록 막는 것이다. 고로 보안 억세스가 허용되는 경우에, TCM 어드레스 영역에서는 따로 검사가 수행되지는 않는다.
기본적으로 TCM은 비보안 운영 체계에서만 이용되며, 이 시나리오에서는 비보안 운영 체계는 바뀔 필요를 가지지 않는다.
이전에 언급한대로, 부분 체커 222는 이 실시예에서 외부버스 70을 통한 블록을 수행하여, 추가적인 부분 체커가 정책 억세스를 메모리를 통해 다른 장치로 하는 것을 관리하며, DSP50이나 DMA 콘트롤러 52가 외부 버스로 이중 연결된 것등이 이에 해당한다. 확실히 다른 실시예 등에서는, 물론 이후에 언급하겠지만, 메모리 관리 유닛 30등과는 다른 형태의 외부 억세스에 대한 블록 감시에 대한 기능을 갖는다. 이러한 실시예에서는, 파티션 체커가 메모리 관리 유닛 30 부분이며, 이런 경우에 체커는 외부 버스에 이중 연결된 부분 체커로 이후에 동작하게 된다.
기존에 언급한대로, 전체 메모리 시스템은 몇 개의 메모리 유닛으로 구성되어 있으며, 외부 버스 70에도 지정될 수있는데, 그 예로 외부 메모리56, 부트롬 44, 버퍼 레지스터 48, 62,66 등이 이에 해당하고, 외부 연결장비들, 예를 들어서 스크린 드라이버 46, I/O 인터페이스 60, 키 저장 유닛 64, 등이다. 이러한 메모리 시스템 의 다른 부분들은 보안 메모리로 지정 될 수 있으며, 예를 들어 위의 장비들이 모두 보안 유닛으로 지정될 수 있으면, 이러한 경우에는 코어 10을 통한 외부 관리 로직 30이 개입하여 이에 대한 관리를 해야 한다.
도 47은 어떻게 추가적인 부분체커 492가 외부 버스에 이중 연결되어, 외부 장치들에 의해 사용되는 지를 보여 주고 있다. 외부 버스는 장치의 종류에 따라서 메모리의 종류를 지정 받는데, 예를 들어서 470,472 등이며, 이러한 메모리 억세스 요구는 외부 장비에서 지정되는 시그널에 의해 특정 모드나 혹은 다른모드 상에서 사용이 가능하도록 한다. 본 발명의 실시예에 있어서, 도메인 시그널은 선택적으로 하드웨어의 레벨을 설정하여, 그 설정에 맞게 패스490을 통해 외부 버스로 해당하는 작업을 수행한다. 도의 목적은, 패스 490이 분리적으로 패스 488과 다른 형태로 동작하는 것을 표시 해 준다.
이 도메인 시그널에서, 또한 S 유니트로 지정되는 것이 장치의 메모리 억세스를 운영체제 상에서 보안 도메인과 비보안 도메인 상에서 관리 해 준다. 이 정보는 부분 체커492를 통해 외부 버스로 연결된다. 외부 버스 492는 또한 부분 정보 구분을 할 수 있는 메모리 영역의 보안, 비보안 부분에 대한 관리를 할 수 있다. 그리고 이는 한 개의 장치가 다른 메모리의 보안 영역에 억세스하는 데 있어서 S 비트가 보안 메모리 모드로 지정 되어 있는 지 확인하는 기능을 가지고 있다.
기본적으로, S 비트는 기존에 존재하는 비보안 장치들 예를 들어 도 47에 나와있는 외부 장비들에 대한, 것과 같은 것에는 결코 외부 억세스를 허용하지는 않는다. 또한 부분 체커 492는 보안 메모리의 일부분 으로써, 버퍼 482, 486에 등록되어, 스크린 드라이버 480과 I/O 인터페이스 484, 그리고 외부 메모리 474내의 레지스터를 관리한다.
도면 상에서 아비터 블록 476은 마스터 디바이스의 메모리 억세스에 대한 관리를 수행한다. 예를 들어서 장치 470, 472 등이나, 이는 서비스 메모리 요구를 하는 장비이며, 하나의 요소가 다른 요소와 결합 된 상태이기도 하다.
도 48은 다른 실시예에서, 부분 체커 492가 제공 되지 않았을 때, 대신 다른 메모리 영역, 즉, 474, 480 484 등이 정책에 따라 준비되어 예를 들어 스크린 드라이버 480등이 보안 메모리로 지정되는 등의 역할을 하게 된다. 이에 S 비트는 따로 설정 되지 않으며, 메모리 억세스는 허용되지 않는다. 파티션 체커 492가 다른 메모리 억세스 관리에 사용이 되기도 한다.
위의 도 47과 48의 설명에서, S 비트는 운영 체계가 보안 혹은 비보안 도메인 상의 메모리 억세스에 대해서 구분하는 역할을 한다고 설명 했다. 다른 관점에서, S 비트는 메모리 억세스 요구에 속하기도 한다.
본 실시예에 있어서, 도 37과 38을 참고 했을 때, 가상 메모리를 물리적 메모리로 수행 할 때 사용이 된다. 단일 MMU는 단일 페이지 테이블로 구성 되어 있 고, 도 49에 표현 된 대로, 물리적인 공간은 보안과 비보안 영역으로 구분 지어진다. 물리적 어드레스 2100이 0어드레스에서 시작해서 Y어드레스로의 메모리 유닛을 메모리 관리 시스템에서 볼 경우, 외부 메모리 56이 이에 해당한다. 각각의 메모리 유닛을 위해서, 어드레스가 가능한 메모리 항목은 두 개의 부분으로 나뉘는데, 첫번째 2110 부분은 비보안 메모리 유닛으로, 두 번째 2120부분은 보안 유닛으로 나뉜다.
이러한 억세스 방법에서, 물리적인 어드레스는 각각의 도메인으로 억세스가 불가하고 이러한 차이에서 운영 체계가 이들 메모리를 사용하면서 운용된다. 운용 체계가 보안 모드에서 수행되고 있을 때, 비보안 도메인에 대한 정보는 고려 되지 않으며, 대신에 보안 운영 체계가 동작하나 존재하지는 않는다.
다른 이슈로, 비보안 운영체계는 외부 메모리 0에서 X로 도착하는 어드레스 공간을 관리 하게 된다. 그리고 비보안 운영체계에서 보안 커널과 특별한 형태로 나타나는 보안 메모리는 X+1 에서 Y로 까지 발전하게 된다. 반대로 보안 커널에서 어드레스 0에서 시작하는 메모리 체계가 나타나지 않는 경우는, 운영 체계에서 이를 거부하게 된다.
위의 고려를 좀더 완화할 수 있는 방법으로는 보안 메모리 영역을 완벽하게 비보안 운영체계의 시점에서 가리는 방법이 있다. 이는 보안 커널에서 보안 도메인과 비보안 운영 체계를 비보안 도메인에서 보이는 어드레스 공간으로 하여 외부 메모리를 어드레스 0에서 시작하게 하는 것으로 도 51에 표현되어 있다. 여기에 물리적 어드레스 2200 이 페이지 레벨에 맞게 구분되어 보안과 비보안 조직으로 구분된다. 도 51에 나와 있는 예로써, 외부 메모리는 4개의 영역으로 구분되어 있는데, 2210, 2220, 2230, 2240등이나. 두 개의 보안 메모리 영역과 두 개의 비보안 메모리 영역이다.
가상 주소와 물리적 주소의 공간의 전송에 대해서 두 개의 다른 층의 어드레스가 첫 번째 테이블에서 다른 테이블로 준비되며, 그로 인해, 프로세서가 보안 도메인인지 비보안 도메인인지에 대한 내용을 확인 할 수 있다. 좀 더 독특하게, 도 51에 나와 있는 대로, 두 개의 보안 메모리 영역인 2210 과 2230은 물리 어드레스 공간 상에서 단일 영역 2265 쪽으로 메모리 테이블 2250상에서 존재하는 보안 메모리 내의 디스크립터를 통해서 데이터를 보내게 된다. 프로세서에 관해 운영 체계가 고려 될 때, 중간에 물리적인 어드레스가 존재 하며, 이는 MMU 를 가상 어드레스로 변환 하여 중간 어드레스 공간에 배치한다.
비슷하게 중간 어드레스 공간 2270은 비보안 도메인에 포함될 수 있으며, 두 개의 비보안 메모리 영역인 2220과 2240은 물리적 어드레스 공간에서 매핑되어 비보안 메모리 공간인 2275에서 중간 어드레서 공간을 비보안 도메인으로 해당 디스크립터에 의해 페이지 테이블 2250내의 비보안 페이지로 변환한다.
실시예에 있어서 변환된 가상 어드레스를 물리적 어드레스로, 중간 어드레스를 통해서 두 개의 나누어진 MMU로 변환 하는 것은 도 50A에 표현 되어 있다. 각각의 MMU 2150과 2170은 비슷한 도 37의 MMU 200과 비슷한 내용이다. 그러나 도의 자세한 부분은 50A에는 현재 삭제되어 있다.
처음의 MMU 2150의 마이크로 TLB 2155는 주 TLB 2160과 해석 테이블 수행 로 직 2165가 동시에 두 번 째 MMU 2170은 마이크로 TLB 275를 포함하고 있으며, TLB 2180과 해석 테이블 수행 로직 2185 등이 주 요소 이다. 처음 MMU는 비보안 도메인에 의해 수행이 되며, 혹은 보안 커널이 프로세서가 보안 모드일 때도 동작하게 된다. 그러나 이 실시예에서는 MMU는 단지 보안 커널이 모니터 프로그램에 의해서만 수행이 된다.
프로세서 코어 10이 메모리 억세스를 요구하면, 패스 2153을 통해 가상 어드레스를 만들어 낸다. 마이크로 TLB 2155는 몇 개의 가상 주소 부분을 저장하게 되며, 주 TLB 2160에 의해서 페이지 테이블이 받아져 처음 연결된 페이지 테이블로 데이터가 전송된다. 만약 마이크로 TLB 2155에서 데이터가 검출 되는 경우에는 마이크로 TLB 2155는 패스 2157에서 중간 어드레스가 가상 주소로 2153 패스를 통해 진행이 된다. 그리고 만약 해당하는 가상 어드레스 부분이 중간 어드레스 부분에서 마이크로 TLB 2155 중간 어드레스는 패스 2157을 통해 지나가게 된다.
만약 마이크로 TLB 2155 에 다른 억세스가 없다고 한다면, 주 TLB 2160을 포함해서, 그리고 나면 해석 테이블 수행 로직 2165가 이미 지정된 페이지 테이블에서 요구되는 디스크립터를 요구하기 위해 사용이 된다. 이는 MMU 2150에 의해서 수행된다.
일반적으로, 페이지 테이블이 각각의 프로세스에 연관이 되어 있다면, 중간 베이스 어드레스는 해석 테이블 수행 로직 2165에서 억세스를 가능하게 하고, 예를 들어서 적당한 레지스터를 CP 15에서 레지스터 34를 이용하게 된다. 그에 따라서 해석 테이블 수행 로직 2165는 중간 어드레스를 패스 2167을 통해 중간 어드레스를 이슈화 하여 적당한 페이지 테이블에서 디스크립터를 요구하게 된다.
두번째 2170 MMU유닛은 모든 중간 어드레스 결과를 마이크로 TLB 2155를 통해 패스 2157로, 혹은 해석 테이블 수행 로직 2165를 패스 2167을 통해서, 그리고 마이크로 TLB에서 이슈된 물리적 어드레스를 패스 2192 메모리로 야기되는 데이터를 데이터 버스 2190을 통해서 받게된다. 중간 어드레스를 2157패스를 통해 받는 과정에서, 요구되는 데이터를 코어10으로 전송하게 되며, 중간 어드레스는 패스 2167을 통해서, 이는 요구되는 디스크립터를 MMU 2150으로 주 TLB 2160을 통해 전달하게 된다.
마이크로 TLB 2175에서 오류가 나는 경우에는, 주 TLB 2180에서 참고가 되고, 만약에 주 TLB상에서 요구가 있는 경우에는, 요구되는 중간 어드레스부분과 해당하는 물리적 어드레스 부분을 패스 2192를 통해 요구하게 된다. 그러나 마이크로 TLB 2175나 혹은 주 TLB 2180이 없는 경우에는, 해석 테이블 수행 로직 2185가 패스 2194를 통해 결과를 도출하게 되고, 이 차 MMU 2170을 통한 페이지 테이블 결과를 도출한다. 이 두번 째 페이지 테이블의 종류들은 중간 어드레스 부분에서 물리적 어드레스 부분으로 변환하는 것으로, 일반적으로 최소한 한 대 이상의 디스크립터가 작동하여 그 물리적 어드레스를 비보안 도메인에서 페이지 테이블을 보안 도메인에서 하나 이상의 페이지 테이블을 구현하게 된다. 요구가 2194를 통해 전달될 때, 해당하는 디스크립터를 두 번째 페이지 테이블에서 결과를 내어 두번째 MMU 2170에서 주 TLB 2180내의 저장을 하게 된다.
도 50A의 구현 사례에서 보듯이 특별한 예에서 볼 수 있는 부분이 아래와 표 현되어 있다. 그리고 변수 들의표시는 IA표시의 중간 어드레스, 그리고 PA는 물리적 어드레스를 표현한다.
1) 코어가 VA = 3000로 함 (IA=5000, PA=7000)
2) MMU 1의 마이크로 TLB의 미스
3) MMU 1의 주 TLB의 미스
페이지 테이블 1 기저 주소 = 8000 IA [PA=10000]
4) MMU 1의 변환 테이블 워크 로직은 페이지 테이블 검사를 수행한다 IA = 8003으로 함.
5) MMU 2의 마이크로 TLB의 미스
6) MMU 2의 주 TLB의 미스
페이지 테이블 2 기저 주소 = 12000 PA
7) MMU 2 변환 테이블 워크 로직은 페이지 테이블 검사를 수행한다.
IA = 12008으로 함. "8000IA = 10000PA" 페이지 테이블 데이터로 복귀
8) MMU 2의 주 TLB에 저장됨
9) MMU 2의 마이크로 TLB에 저장됨
10) MMU 2의 마이크로 TLB가 히트됨
PA =10003으로 함. "3000VA=5000IA" 페이지 테이블 데이터로 복귀
11) MMU 1의 주 TLB에 저장됨
12) MMU 1의 마이크로 TLB에 저장됨
13) MMU 1의 마이크로 TLB가 히트됨. 데이터 억세스를 수행하기 위하여 IA= 5000로 함.
14) MMU 2의 마이크로 TLB의 미스
15) MMU 2의 주 TLB의 미스
16) MMU 2의 해석 테이블 수행 로직에서 페이지 테이블 검색을 수행. PA = 12005으로 함
17) MMU 2의 주 TLB에 저장됨
18) MMU 2의 마이크로 TLB에 저장됨
19) MMU 2의 마이크로 TLB가 히트됨. 데이터 억세스를 수행하기 위하여 PA = 7000으로 함
20) 물리적 데이터 어드레스 7000이 코어로 복귀
이후 코어는 메모리 억세스 요구를 하게 된다. (VA 3001)
1) 코어가 VA=3001로 함
2) MMU 1의 마이크로 TLB가 히트됨. MMU 2로 IA5001가 요구됨
3) MMU 2의 마이크로 TLB가 히트됨. 메모리로 PA7001이 요구됨
4) PA7001의 데이터가 코어로 복귀.
위의 예는 각각의 마이크로 TLB와 주 TLB의 각각의 MMU에서 예를 가장 "최악의" 시나리오의 예로 볼 수 있다. 일반적으로 그것은 최소한의 마이크로 TLB 혹은 주 TLB에서 데이터를 받는 시간을 제거하는데 사용이 된다.
도 51로 돌아와서, 페이지 테이블 2250의 두 번째 세트에서 특정한 영역의 물리적인 어드레스 공간이 제공이 되며, 구현 방법에 있어서 첫 번째 페이지 테이블은 두 가지로 나뉘는데, 하나는 보안 페이지 테이블과 다른 하나는 비보안 페이지 테이블이다. 바람직하게는 보안 페이지 테이블은 중간 어드레스 공간 2265에서 일관적으로 나타나게 되고, 비보안 테이블은 중간 메모리 공간 2275에서 나타나게 된다. 그러나, 물리적 공간에서 일관되게 나타나지 않는 경우도 있으며, 그 예로 보안 페이지 테이블은 처음의 보안 영역인 2210, 2230에서의 페이지 테이블로 나누어 지는 것을 볼 수 있는데, 비슷하게, 비보안 페이지 테이블은 비보안 메모리 영역인 2220과 2240으로 나뉘게 된다.
이전에 언급한대로, 2가지 레벨의 페이지 테이블 접근 방식은 운영 체계의 보안 도메인과 비보안 도메인의 운영체계를 물리적 어드레스 공간에서 물리적 어드레스가 0부터 시작하는 경우에는, 추가적으로 보안 메모리 영역이 완벽하게 비보안 운영체계의 관점에서 "물리적 어드레스"로 보이게 되는 중간 어드레스의 순서를 일관적으로 할 수 있게 준비할 수 있도록 물리적 어드레스를 보이지 않도록 한다.
추가적으로 비보안 메모리와 보안 메모리 간의 메모리 영역 변경에 대해 이것은 도 52에 나타나 있다. 도 52에서 볼 수 있듯이, 메모리 영역 2300에서 는 메모리의 단일 페이지의 예를 볼 수 있으며, 비보안 메모리 영역 2220과 비슷한 메모리 영역 2310이 또한 보안 영역 2210에 상주 하게 된다. 그러나, 이 두 개의 2300과2310의 메모리 영역은 단순히 해당하는 디스크립터를 변경하는 선에서 바뀔 수 있고, 그러한 영역 2300은 보안 영역에 매핑되어 영역 2305로 중간 어드레스 공간으로써 보안 도메인에 나타나게 되고, 비보안 도메인에 나타나게 된다. 이는 전체 적으로 투명하게 운영 체계에 보안 도메인과 비보안 도메인으로 나타나게 된다. 이는 운영 체계에 물리적 어드레스 공간을 보는 관점이 중간 어드레스 공간의 보안 및 비보안 메모리에 상대적으로 중간 어드레스로 존재한다. 그래서, 접근 방법은 모든 물리적 어드레스의 운영 체계에서의 재 정의를 피하게 된다.
본 발명의 실시예에서 두 개의 MMU는 또한 사용되면, 다른 준비 단계는 도 50A에 나타나는데, 도 50B에 그 다른 준비 단계가 나타나 있다. 도 50B 와 50A상에서 비교되어 나타나 있는 것과 같이, 준비 과정은 동일하며, 단지 구현방법에 있어서 첫번 째 MMU 2150은 가상어드레스를 물리적 어드레스로 변환 하는 것이고, 두 번째 MMU는 중간 어드레스를 통해서 물리적인 어드레스로 변환한다고 볼 수 있다. 그래서, 마이크로 TLB 2155는 첫번째 MMU 2150상에서 MMU 2170의 마이크로 TLB 2175로, 도 50A에 구현되어 있는 것처럼, 마이크로 TLB 2155에 물리적인 주소로 직접 패스 2192로 전달 되고 있다. 이는 도 50B에서 확인 할 수 있다. 도 50B에 구현되어 있는 부분은 아래와 같으며, 자세한 프로세싱에 관련된 부분은 50A에 설명되어 나타나 있는 부분과 같다.
1) 코어가 VA = 3000로 함
2) MMU 1의 마이크로 TLB 및 주 TLB의 미스
페이지 테이블 1 기저 주소 = 8000IA [PA=10000]
3) MMU 내의 해석 테이블 수행 로직은 페이지 테이블 검색을 수행
IA = 8003으로 함.
4) MMU 2의 마이크로 TLB 및 주 TLB에서 IA 8003 미스
페이지 테이블 2 기저주소 = 12000 PA
5) MMU 2 내의 해석 테이블 수행 로직에서 페이지 테이블 검사를 수행
PA =12008으로 함.
"8000IA = 10000PA" 페이지 테이블 데이터로 복귀
6) "8000IA = 10000PA" 매핑이 MMU 2의 주 TLB 및 마이크로 TLB에 저장됨.
7) MMU 2 내의 마이크로 TLB는 단계 3의 요구를 PA10003으로 해석하여 페치함. "3000VA = 5000IA" 페이지 테이블 데이터로 복귀.
주: 이 해석은 MMU 1에 의해 잠시 남아있는 부분이며, 다른 어떤 TLB로도 직접 저장 되지는 않는다.
8) MMU 1의 해석 테이블 수행 로직은 MMU 2로 IA=5000을 요구한다.
9) MMU 2의 주 TLB 및 마이크로 TLB에서 IA5000 미스
10) MMU 2 내의 해석 테이블 수행 로직은 페이지 테이블 검색을 수행. PA=12005으로 함. "5000IA = 7000PA" 페이지 테이블 데이터로 복귀
11) MMU 2는 마이크로 TLB 및 주 TLB에 "5000IA= 7000PA"를 저장. 이 해석은 MMU 1에도 전달된다.
12) MMU 2는 메모리에 억세스하기 위하여 PA = 7000으로 함.
13) PA 7000의 데이터가 코어로 복귀.
다음으로 코어는 메모리 억세스 요구를 한다(VA 3001)
1) 코어는 VA =3001으로 함.
2) MMU 1의 마이크로 TLB가 히트됨. MMU 1은 PA =7001로 하기 위한 요구를 함.
3) PA 7001의 데이터가 코어로 복귀.
위의 예 에서 비교된 바와 같이, 도 50A에서 제공된 내용은, 주로 다른 점이 단계 7에서의 MMU 1이 첫번째 테이블을 디스크립터로 바로 저장하지 않는다는 것이고, 단계 12b에서 (12a 와 12b 는 동시에 발생한다) MMU 1 는 또한 IA->PA로 받는 조합에서 TLB로 조합된 디스크립터를 저장하게 된다.
따라서, 선택적인 구현 방법은 두 세트의 페이지 테이블로 각각의 가상 어드레스를 물리적인 어드레스로 변환하며, 사실은 마이크로 TLB 2155와 주 TLB 2160에서 저장된 직접적인 가상 어드레스가 물리적인 어드레스로 해석되는 부분의 검사를 피할 수 있도록 양 쪽의 MMU가 마이크로 TLB 2155 혹은 주 TLB 2160으로 작업이 발생할 때실행 된다는 것을 알 수 있다. 이 첫 번째 MMU는 직접적으로 두 번째 MMU의 작업이 없이도 코어로부터 요구를 관리 할 수 있게 된다.
두번 째 MMU 2170은 마이크로 TLB 2175 와 주 TLB 2180을 포함하지 않고서, 페이지 테이블 수행 로직 2185 가 모든 요구에서 두번 째 MMU요구에 의해 사용 되도록 한다. 이는 복잡함과 두 번째 MMU의 비용을 절약하여, 두 번째 MMU가 상대적인 사용 빈도를 줄일 수 있도록한다. 그런 관계로, 첫번째 MMU가 모든 요구에 처음 응대하게 되고, 이후에 마이크로 TLB 2155와 주 TLB 2160이 첫 번째 MMU 2150이 첫 번째 MMU의 가동속도를 높이는 역할을 한다.
페이지 테이블 사이즈가 다를 수 있다는 것은 반드시 알고 있어야 하며, 그런 관계로 디스크립터 들은 두 개의 절반으로 각각의 사이즈화 된 페이지를 가지게 된다. 일반적으로 MMU 1페이지는 MMU 2의 페이지보다 작지만 항상 그런 것은 아니다. 예를 들어서.
테이블 1이 0x4003000의 4KB를 0x00081000로 매핑
테이블 2가 0x00000000의 1MB를 0x02000000로 매핑
이때 가장 작은 두 개의 사이즈를 가진 조합을 볼 수 있는데, 조합된 디스크립터는 "4KB at 0x40003000 onto 0x02081000"이다.
그러나, 데이터가 각각에 모드에서 바뀌고 난 경우에는 반대의 경우도 사실이 될 수 있다. 예를 들어서
테이블 1이 0xv0000000의 1MB를 0x00000000로 매핑
테이블 2가 0x00042000의 4KB를 0x02042000로 매핑
이때, 코어에서 어드레스 0xc0042010를 검색하면 다음의 매핑이 주어진다.
"4KB at 0xc0042000 onto ox02042000"
예를 들어서 두 개의 사이즈 중에 작은 것은 언제나 조합용 매핑으로 사용된다.
두번 째 경우는 그 영향이 적은 편인데, 이는 1메가 바이트의 디스크립터 테이블 1이 다른 버려진 4킬로바트 영역에 반복적으로 억세스하게 된다. 그러나, 일반적인 시스템에서 테이블 2의 디스크립터는 대부분의 시간에서 더 큰 편이며, 더 효율적으로 쓰인다.
도 50A 와 50B에서 볼수 있는 두 개의 각각의 MMU의 동작에 대해서, 단일 MMU는 도 53에서 볼 수 있듯이, 주 TLB 2420에서 에러가 나는 경우 그 예외를 생성해서, 소프트웨어가 코어10과 함께 가상 어드레스를 해석하여 두 개의 다른 페이지 테이블을 생성하도록 한다. 좀 더 구체적으로 도 53에 나와 있듯이, 코어 10 MMU 2400과 연결되면, 마이크로 TLB 2410에 주 TLB 2420의 조합이 된다. 코어 10이 메모리 억세스 요구를 하는 경우에는 가상 어드레스는 패스2430을 통해서 마이크로 TLB를 관찰하게 되고, 그리고 나서 해당 물리적 어드레스의 결과를 직접 패스 2440으로 전달하게 되는데 이것이 코어 10으로 데이터를 재 전송하게 하는 결과를 가진다. 그러나, 만약에 2410에서 오류가 발생하는 경우에는 주 TLB인 2420이 개입되어 해당하는 디스크립터를 포함한 가상 어드레스 부분과 물리적인 어드레스 부분은 마이크로 TLB 2410으로 보내고 물리적인 어드레스는 패스 2440을 이용한다. 그러나, 주 TLB가 오류를 생성한다면, 패스 2422를 통한 예외 사항이 발생하게 되어 코어로 전달이 되고, 프로세스는 코어에서 처음 받을 때 그런 예외 사항 이었는지에 대한 프로세스를 진행하게 된다. 이는 도 54에 나타나 있다.
도 54에서 보듯이 TLB가 코어에 의해 에러 검출에 실패하는 경우, 코어는 모니터 모드에 진입하여 기존에 정의된 백터에 의해 단계 2510으로 이동한다. 이는 도 54에서 보듯이 페이지 테이블을 병합하여 수행할 수 있도록 한다.
좀 더 구체적으로, 단계 2520에서 패스 2430을 통한 가상 어드레스는 마이크로 TLB 2410과 주 TLB 2420에서 받아지며, 단계 2530에서 중간 어드레스가 첫 번째 디스크립터에서 요구되며 이는 중간 어드레스의 테이블 세트의 종류에 따라 달라진 다.
고로 단계 2550 에서 1차 디스크립터는 가상 어드레스의 오류에 따라서 결정된다.
그리고 단계 2560에서는, 두 번째 테이블이 다시 두번 째 디스크립터에 주어진 물리적인 어드레스를 중간 어드레스의 가상 어드레스에 대한 오류를 검사하기 위해 쓰여진다. 스탭 2750에서는, 두 번째 디스크립터가 물리적 어드레스의 가상 어드레스의 오류에 대한 내용을 구하기 위해 합쳐진다.
위의 구해진 정보대로, 프로그램은 두번 째 디스크립터에서 필요한 가상 어드레스의 물리적 어드레스로의 변환을 위하여 프로그램을 통합하게 된다. 이는 단계 2580에서 수행된다. 비슷한 방식으로 이전에 묘사한 페이지 테이블 사이즈에 대해 소프트 웨어는 가장 작은 사이즈의 테이블을 선택하게 된다. 단계 2590에서는, 새로운 디스크립터가 저장되어 주 TLB상의 2420에 저장되며, 프로세서는 2595단계의 예외 사항에서 반환되게 된다.
그런 관계로, 코어 10은 가상 주소를 메모리 억세스 요구에 패스 2430을 통해 사용하기 위해 쓰이며, 이는 마이크로 TLB 2410 상의 오류를 야기하게 되는데, 반면에 마이크로 TLB 2410은 물리적 어드레스를 패스 2440을 통해 받게된다. 이로 인해 패스 2450에서 코어 10으로의 필요한 데이터들이 전송된다.
이것은 선택적인 구현 방법에 있어서, 도 50A 와 50B 상에서 볼 수 있는 것인데, 하나, 혹은 둘의 MMU가 구현방법에 있어서 소프트 웨어를 도 53과 54에 있는 내용에 따라 묘사한데로 그 원칙으로 하는 것을 볼 수 있다.
두 개의 MMU가 도 50A, 50B에서 보여진 것처럼 사용되거나 혹은 MMU 단독으로 도 53에서 쓰이는 것과 같은 것은 운영 체제가 보안 모드에서 작동될 때 볼 수 있는 것이고, 이는 페이지 테이블이 안전하다는 것을 의미한다. 그 결과로 프로세서가 비보안 도메인 상에서 단지 비보안 메모리에 대한 내용만을 확인 할 수 있을 때, 중간 어드레스 공간은 비보안 도메인 상에 두 번째 페이지 테이블에 의해 생성이 된다. 그 결과로 메모리 관리 로직 30은 부분 체커를 사용하지 않으며 이는 도1에 나와 있다. 그러나 부분 체커는 외부 버스를 통해 모니터 억세스 모드로 제공되며, 이는 시스템 내의 다른 버스 마스터에 의한다.
도 37과 38에 나타나 있는 구현 방법에 따라, 부분 체커 222는 MMU 200과 연결 되어 그에 따라 억세스가 캐쉬 38내에서 수행 되고, 검색이 마이크로 TLB 206에 의해서 처음 수행 된 후, 억세스 권한 특별히 보안 및 비보안 권한 등이 검사 된다. 또, 그런 구현 방법에서 보안 데이터는 캐쉬 38에 저장 될 수 가 없는데, 이는 비보안 어플리케이션에 의해서 이다. 캐쉬 38로의 억세스는 부분 체커 222의 의해서인데, 비보안 모드상에서 보안 모드의 데이터 저장이 이루어지지 않는다.
그러나, 본 발명의 선택적인 실시예에서는, 시스템 버스 40을 통한 모니터 억세스 모드를 부분 체커 222가 허용하지 않는다. 그 대신에, 외부 버스 70에 연결된 단일 체커가 작동하여 모니터 권한을 외부 버스로 연결 시키는 작업을 한다. 이러한 실시예에 있어서, 이는 프로세서 코어 10이 시스템 버스 40을 통하는 어떤 메모리 유닛이라도 연결이 가능하고, TCM36과 캐쉬 버스 38과 같은 부분에 있어서의 억세스를 허용하고, 그 기술적 구현이 프로세서 코어 10이 비보안 모드의 운영 체계 내에서는 캐쉬 38이나 TCM 36이 없이는 억세스가 불가능 하다는 기술적인 메커니즘을 설명하고 있다.
도 55는 본 발명의 일 실시예에 따른 데이터 처리장치를 도시하고 있으며, 캐쉬 38 및/또는 TCM 36에 대한 억세스를 MMU 200과 관련하여 제공되는 파티션 체커 로직에 대한 필요없이 제어할 수 있도록하는 메카니즘을 제공한다. 도 55에 나타나 있는 것처럼, 시스템 버스 40과 캐쉬 38, TCM 36은 서로 연계되어 있다. 코어 10, 캐쉬 38, 그리고 TCM 36은 외부 버스 인터페이스 42로 외부 버스 70을 통해 연결되어 있으며, 이것은 도 55상의 어드레스 버스 2620, 제어 버스 2630, 데이터 버스 2640으로 구성되어 있다.
코어 10, MMU 200, 캐쉬 38, TCM 36과 외부 버스 42등은 외부 버스 70으로의 단일 장치 연결이 가능하고, 장치 버스와 다른 장치들의 보안 외부 장치 470 이나 혹은 비보안 장치 472등에 대한 보안 기능을 제공한다. 또한 연결된 장치 버스 70에 대해서 하나 혹은더 많은 메모리 유닛에 존재 할 수도 있다. 게다가, 버스 제어 유닛 2650은 장치 버스 70에 연결되며, 아비터 2652와 디코더 2654, 부분 체커 2656 등을 포함한다. 일반적인 장치 버스에 연결된 장비들에 대한 일반적인 토론을 위해서, 도 47에 그 내용이 서술 되어 있다. 도 47에 나타나 있는 실시예는 아비터, 디코더, 그리고 부분 체커에 대한 분리된 블록을 나나태며, 이러한 요소들은 단일 제어 블록 2650에서도 같은 방식으로 보여지게 된다.
도 56의 MMU 200의 경우는 55에 비해 더 자세하게 묘사되어 있다. 도 56과 37의 비교에 있어서는, 차이점이 단지 주 TLB 208과 마이크로 TLB 206만이 있을 뿐이다. 만약 프로세서 코어 10이 메모리 억세스 요구를 특정한 가상 메모리에 하게 되는경우 메모리 억세스 요구가 MMU쪽으로 라우트 되어, 위의 설명 된대로 도 37의 내용을 따라서, 물리적 어드레스가 시스템 버스 40으로 패스 238을 통해 마이크로 TLB 206으로 전달 되는 것을 볼 수 있다. 만약, 그와 반대로 제어 요구가 물리 어드레스로 직접 도달하는 경우에는, 이는 MMU 200을 지나쳐서 대신에 패스 236을 통해 시스템 버스 40으로 바로 연결되게 된다. 이러한 실시예에서는 프로세서는 모니터 모드에서만 동작하게 되며, 메모리 억세스 요구는 직접적으로 물리 메모리를 향하게 된다.
이전의 MMU 200의 설명에 대한 부분을 다시 생각해 보았을 때, 특별히 도 43에 나타나 있는 주 TLB 43에 대해서, 이는 몇 개의 디스크립터 435를 가지고 있는데, 각각의 디스크립터의 도메인 플래그 425는 동일하게 제공되어 해당 디스크립터에보안 페이지 테이블이나 혹은 비보안 페이지 테이블로 전송된다. 디스크립터 435와 연계된 도메인 플래그 425는 도 55의 MMU 200관련 내용에 표기 되어있다.
코어 10이 메모리 억세스 요구를 제기하는 경우에는 이것은 물리적 주소가 메모리 억세스 요구를 시스템 버스 40으로 하는 것을 의미하고, 이는 데이터 아이템이 캐쉬에 저장되는 것을 의미한다. 오류가 발생할 때마다, 데이터 아이템은 외부 메모리 56에서 메모리 억세스 요구를 했다는 것을 의미한다. 특별히 캐쉬가 EBI 42에 대해 선형 linefill 요구를 제어 버스 2630에 한 경우에, 외부 버스 70으로 연결이 되고, 이는 도메인의 시그널이 동작 모드에서 코어로 가는 메모리 억세스가 제기 되었음을 의미한다. 고로, linefill 프로세스는 원래 메모리 억세스 요구를 캐쉬 38에 의해 외부 버스로 보이게 하는 가상의 역할을 한다.
HPROT 시그널은 부분 체커 2656에서 받게 된다. 그리고 그에 따라 부분 체커는 요구하는 장치가 외부 메모리 56이 동작해서 보안 도메인인지 혹은 비보안 도메인인지 하는 부분에 대한 결정을 한다. 부분 체커 2656은 부분 정보 구분을 위해서 메모리의 어느 영역이 보안 혹은 비보안 모드인지, 그리고 장치가 요구하는 데이터 억세스방향으로 억세스 하도록 하는 지를 검사하게 된다. 그러므로, 부분 체커는 메모리의 보안 영역에서 억세스를 허가 하게되며, 만약 도메인 시그널이 HPROT시그널 내부에서 정의 된다면, 데이터는 보안 모드의 운용을 할 수 있도록 시스템에 요구를 하게 된다.
부분 체커는 코어 10이 HPROT시그널이 코어가 비보안 모드에서 동작하는 부분을 감지할 때 데이터의 억세스를 차단 하도록 한다. 그러나 이에 대한linefilll요구는 외부 메모리에서 보안 영역의 메모리에 있는 데이터를 받아 올 수 있도록 검색을 수행하고, 그리고 부분 체커 2656이 EBI42로, 캐쉬 38을 이용해 다시 취소 시그널을 패스 2670을 통해 코어10으로 보내게 되는 역할 을 한다. 그러나, 만약 부분 체커 2656이 억세스를 허가 하도록 하는 경우에는, 결과물 S가 태그 시그널을 구분하여중간에 보안 모드와 비보안 모드를 구분한 상태에서, S 태그 시그널은 패스 2634를 통해 EBI 42를 향하게 되고, 다시 캐쉬 38에서 플래그 2602가 연계된 상태에서 라인필(linefill) 프로세스의 목적인 캐쉬 라인 2600과 함께 연계 되게 된다.
동시에 제어 로직 2650은 외부 메모리 56의 라인필 데이터를 연결하는데 허가를 하게 되고 이 데이터는 다시 EBI42를 거쳐서 캐쉬 38에 라인 2600으로 도달하게 된다. 그런 관계로, 프로세스의 결과에 의해 선택된 캐쉬 라인은 외부 메모리 56에 도달하여 데이터 아이템을 코어 10에 전달하게 된다. 그 데이터 아이템의 목적은 코어에서의 억세스 요구에 대한 것이고 다시 캐쉬 38쪽으로 혹은 직접 EBI 42 쪽으로 코어 10에 패스 2660을 통해 전달 되게 된다.
본 실시예에서, 원래 데이터가 저장되는 라인은 상기 라인필 프로세스에 의하고, 플래그 2602는 부분 체커 2656에 근간한 데이터 값에 의한다. 그리고 플래그는 캐쉬 38에 의해 다시 사용되며, 이는 직접적으로 캐쉬 라인2600에 대한 데이터 입력을 도와주는 역할을 한다. 그러므로, 코어 10은 메모리 억세스 요구를 특정한 캐쉬 라인 2600으로 전달하게 하며, 캐쉬 38은 플래그 2602의 값에 연계되게 된다. 그리고 비교된 값은 CP 15의 상태 레지스터에 기록된다. 캐쉬 38은 단지 데이터 아이템을 보안 모드의 동작 상황에서 운용할 수 있도록 해 준다. 보안 데이터의 코어로의 어떠한 억세스 시도도 캐쉬 38에서 비보안 모드로 동작하는 경우에는 패스 2670을 거쳐서 취소 시그널을 생성하게 된다.
TCM 36은 여러 가지 방법으로 설정 될 수 있다. 일 실시예에 의하면, 이것은 캐쉬 처럼 세팅되기도 해서 다수의 2610 캐쉬라인이 될 수도 있고, 플래그 2612 와 연계된 같은 방법으로 캐쉬 38에 등록 되기도 한다. TCM 36으로의 억세스는 이전에 언급한 캐쉬 38로의 억세스 방법과 동일하며, 어떤 TCM 오류라도 linfill 프로세스가 동작하며, 파티션 체커 2656이 S 태그의 값을 발생시켜서 플래그 2612가 라인 2610과 연계 되도록 한다.
다른 실시예에서는, TCM 36이 외부 메모리 56으로의 확장자 역할을 하기도 하여 프로세서에 의해 자주 메모리를 저장하는 데 쓰이기도 한다. 이는 시스템 버스가 외부 메모리 보다 빠르기 때문이다.
TCM 36은 플래그 2612를 사용하지 않으며, 그 대신에 다른 기술을 사용하여 TCM으로의 억세스 관리를 시도한다. 특별히 이전에 언급된 대로 본 실시예에서는 제어 플래그는 프로세서가 특정화 된관리 모드에서 작동 할 때 제공되며, 혹은 긴밀히 연결된 메모리를 통해 제어가 가능한 프로세서를 통한 수행이 최소한 1회 정도 비보안 모드에서 실행 될 수 있도록 한다. 제어 플래그는 보안 운영체제에서 수행 되며, 효과적으로 TCM이 특정화 된 보안 모드에서 수행 되는지 아닌지에 대한 결정을 하게 된다. 이런 실시예에서는, 비보안 억세스가 TCM제어 레지스터 상에서 입력된 설정 예외를 지정하지 않은 레지스터를 연결 하는 것을 시도 하게 된다.
다른 구성에서는 TCM이 프로세스를 비보안 모드 상에서의 운용되는 운영체계에서 제어 받을수 있도록 한다. 이런 환경에서는 단지 비보안 어플리케이션 만이 실행 될 뿐이다. 다른 보안 데이터는 저장될 수 없거나 혹은 TCM에서 로드가 된다. 따라서, 보안 억세스가 수행 되었을 때, TCM에서 TCM 주소 범위에서 주소를 찾을 수 있게 되어 있다.
도 57은 도 55에서 수행되는 프로세서의 형태를 도식화 하여 표현하고 있는데, 우선 단계 2705에서 검색이 수행되어, 마이크로 TLB 206을 통해 만약 억세스가 발생할 경우, 마이크로 TLB가 단계 2730에 억세스 권한을 검사한다. 도 56을 참고로 할 때, 이 프로세스는 억세스 권한 로직 202에 의해 수행 되는 것으로 보인다.
단계 2705에서 마이크로 TLB 상의 검사가 발생하며, 검사는 주 TLB 208에서 비보안 디스크립터를 그에 저장하면서 검사를 수행한다. 만약 결과가 오류라면, 페이지 테이블 수행 프로세스는 단계 2715에서 수행 되어 2720 단계에서는 주 TLB가 정확한 태그를 지닌 비보안 디스크립터를 결정하게 된다.
그런 관계로, 단계 2725에서는 마이크로 TLB상에서 물리적인 어드레스를 가지고 있는 디스크립터의 부분에 로드 되어 마이크로 TLB는 억세스 권한을 검사한다.
단계 2730에서는, 억세스 권한에 대한 위반이 있는 경우에는 프로세스가 2740으로 수행되며, 취소 시그널이 발생하게 되면, 패스 230을 통해서 프로세스 코어로 전송 하게 된다. 그러나, 위반 이 발견되지 않는 경우에는 단계 2745에서 억세스가 캐쉬데이터 아이템을 가지고 있는 지에 대한 여부를 확인하여 결정한다. 만약 그렇지 않은 경우에는, 외부 억세스가 단계 2790에서 초기화 된상태에서, 보안 부분 위반이 발생한 경우에는, 데이터를 받기 위한 검색이 수행된다. 단계 2795에서는 부분 체커 2656이 보안 부분 위반이 있는지를 검사하며, 만약 프로세서 코어 10이 보안 메모리의 데이터를 저장한다. 그리고 위반이 발견되는 경우에는, 부분 체커 2656이 시그널은 2775 단계을 통해서 생성하게 된다. 그러나, 보안 부분 위반이 없는 경우에는 프로세스를 2785에서 진행 되며, 데이터 억세스가 발생한다.
단계 2745에서는 데이터 요구가 캐쉬가 가능한가에대한 여부를 확인 할 수 있고, 캐쉬가 검사를 해서 단계 2750에서 캐쉬를 사용할 수 있게 하고, 만약 억세스가 감지되는 경우에는 캐쉬가 보안 라인 태그 위반을 단계 2755에서 수행하게 된다. 그리고 이 단계에서, 캐쉬는 플래그 2602의 값을 검사하여 데이터 아이템을 요구하게된다. 만약, 라인 태그가 검색된 경우에는, 캐쉬 38에 의해 오류 취소 시그널이 보안 오류상에서 전송 되어, 단계 2755에서 라인 태그를 통한 처리를 한후, 코어 10에서 패스 2670을 통해 연결된다. 그러나, 비보안 라인 태그 위반은 스탭 2755에 감지 되고 있고, 데이터 억세스는 단계 2785로 수행된다.
만약 캐쉬검색이 단계 2750에서 수행되는 경우, 캐쉬 오류가 발생하는 경우에는 캐쉬 linefill이 단계 2765에서 초기화 된다. 단계 2770에서는, 부분 체커 2656이 보안 위반 오류가 있는 지 확인하고, 만약 그렇다면 취소 시그널을 2755단계으로 보내게 된다. 그러나, 오류가 없는 경우에는, 단계 2780에서 진행되고, 데이터 억세스는 2785에서 완료 된다.
도 57에 나타나 있듯이, 단계은 2705, 2710, 2715, 2720, 2730 과 2735가 MMU내부에서 수행되어 단계 2745, 2750, 2755, 2765, 2780과 2790등이 캐쉬에 의해 수행된다. 그리고 단계 2770 과 단계 2795에서는 부분 체커가 수행 된다.
도 58은 보안 프로그램상에서 아날로그 화 되어 수행되는 가상 어드레스의 코어에 위치하여, 이를 실행한다. 도 57과 58의 비교에서, 단계 2805 에서 2835를 통한 MMU의 아날로그 프로세스는 단계 2810등의 주 TLB가 수행되는 도중에 보안 디스크립터를수행하여 단계 2820에서 주 TLB에 합당한 테그를 보안 디스크립터에 가지게 된다.
캐쉬 내부에서는 캐쉬가 더 이상 어떤 라인 태그 위반을 하지 않는 다는 것을나타내고 있다. 이는 도 58에서 참고할 수 있는 실시예는 보안 프로그램이 보안 데이터와 비보안 데이터를 억세스할 수있게 하는 것이다. 그에 따라서, 만약 단계 2850에서 캐쉬 검사가 있는 경우에는, 프로세스는 바로 단계 2885를 향해 데이터 억세스를 시도한다.
비슷하게도, 각각의 이벤트는 외부 억세스를 할수 있는 메모리 억세스가 요구 되는 경우에 부분 체커와 부분 검사가 수행 되는 상태에서 보안 프로그램이 보안 데이터와 비보안 데이터를 접속할 수 있도록 한다.
단계 2845, 2850, 2860, 2890은 캐쉬에서 아날로그단계으로 수행되고, 2745, 2750, 2765, 2790 등으로 도 57에 묘사된 내용을 볼수 있다.
도 59에서 프로세서상에서 다른 모드와 어플리케이션을 보여주고 있다. 줄이 그어져 있는 선은각각 분리된 다른 어플리케이션과 모드 등을 나타내는데, 다른 모니터링 프로세스가 본 발명의 구현에서 필요한 부분이다.
프로세서가 모니터링을 하는 능력은 오류의 발견 등이 왜 어플리케이션에서 수행 되지 않고유용한 많은 프로세서 상에서 그러한 기능을 할 수 있도록 하게 한다. 이는 다양한 방법으로 디버그 및 트레이스 기능을 수행 하도록 한다.
프로세서가 현재 기술을 디버그 해서 운용되게 하는 몇몇 모드를 포함하여 정지 디버그 모드와 모니터 디버그 모드 등이다. 이 모드들은 정지 되어야 하는 시간에 맞추어 작동하게 된다. 정지 디버그 모드에서는 분기점이나 주시점으로 상태가 구분된다. 코어의 입력이 정지하게 되면, 파이프 라인은 기존에 조합된 설정에 따라 정해진다. PC는 정지 상태에 빠지게 되며, 어떤 인터럽트도 무시되게 된다. 내부 상태에서 코어가 수행이 가능하게 됨에 따라 메모리 시스템에 대한 상태에 위치 하게 된다. 이 상태는 프로그램 수행에 필요로 하며, 현재의 모드를 수정하여 레지스터 내용을 변화 할 수 있게 된다. 디버그가 종료 하게 되면, 코어는 재 시작 설정을 검사한 이후에 디버그 상태를 종료하고 코어는 원래 모드로 돌아오게 된다.
모니터 디버그 상에서 분기점이나주시점에서 코어가 취소 모드에 들어가게 되면, 기능 모드에서 정지 되지않은 상태에서 정지 디버그 에서 준비되도록 하게 된다. 취소 관리자는 디버그 어플리케이션과 통신 하게 되며, 프로세서의 상태를 체크하여 덤프 메모리를 구성하게 된다. 디버그 모니터 프로그램은 하드웨어 / 소프트웨어 디버그 인터페이스 프로그램으로 인식 된다. 만약 11비트의 디버그 상태에서 제어 레지스터를 DSCR에서 설정되며, 인터럽트를 보여주게 된다. 모니터 디버그 모드에서는, 벡터 수집 작업이 비 활성화 되었을 때의 데이터 취소와 수집 취소를 수행 하기위한, 발견 될 수 없는 결과의 내용으로 모니터 디버그 모드 상에서 생성되는 데이터를 볼 수 있다. 이것은 모니터 디버그 모드가 관리자 모드에서 보안 모드와 비보안 모드 상에서의 종류를 선택할 수 있게 된다.
디버그는 상태에 관련한 프로세스의일부 모습을 제공할 수있다. 만약 이것이 여러 개의 레지스터를 동시에 디버그 모드 상에서 요구할 수 있는 데이터를 받는 경우라면, 이 값들은 검사 체인과 그 직렬로 나타나는 결과를 JTAG 콘트롤러에 의해 보게 된다.
선택적인 방법에서의 모니터 모드는 트레이스에 의한다. 트레이스는 기록을 순서적인 상태에서 동작할 수 있도록 설계되어 있다. 트레이스는 ETM상에서 실행되며, 도 1의 22, 26을 참고 할 수 있다. ETM은 트레이스 포트를 정보의 외부로 노출되면, 이는 외부 트레이스 포트 분석기에서 분석되게 된다.
구현 방법 상에서 현재 기술 운영 방법은 두 가지 다른 도메인으로 구분 되는데, 보안과 비보안 모드의 조합에 의해 의한다. 그러나 모니터링 기능에 대한 명확한 기술에 대한 두 개의 도메인 상에서 데이터는 반드시 누출 되지 않아야 한다. 본 발명의 실시예에서는 모니터링 기능이 디버그와 트레이스 상에서 도메인 간의 데이터 누수를 근본적으로 전체적인 시스템 상에서 억세스가 가능한 것으로 설정된다.
보안과 비보안 도메인 상의 보안 데이터는 비보안 상태에서는 불가능 하여야 한다. 게다가, 디버그가 허용된 경우에, 이는 보안 모드와 비보안 모드의 데이터는 강제적으로 숨기게 된다. 도 59에 나타나 있는 내용은 일부의 예가 데이터 억세스를 구분 할 수 있게 되고, 다른 수준의 데이터 성질을 나타낸다. 도 59에서의 예는 블록 500에서의 가장 보안 되어야 하는 모드와 보안 및 비보안 모드 상에서의 전환에 대해 아래의 모니터 모드 500은 비보안 관리 모드 520에서 보안 관리모드 510으로의 전환을 시도 하게 된다. 유저 모드 상에서의 어플리케이션은 522, 524와 보안 유저모드에서의 수행을 한다. 선택적으로, 비보안 도메인과 보안 도메인 상에서의 접속은 가능해야 하는 부분이고, 실시예 상에서는 비보안 부분과 보안 부분에 대해서는 유저 도메인 상에서의 다른 보안 데이터의 누수를 막기 위한 구분으로 볼 수 있다. 코어의 부분에서 이것의 접속은 모니터 기능 중에서 라인 503에서 발생하는 유저 보안 모드 상에서의 기능을 볼 수 있다. 보안 데이터는 다른 어플리케이션 상에서 그 억세스를 모니터 기능을 통해 조절 될 수 있도록 하게 한다.
네 개의 레지스터의 디버그 이벤트가 존재한다. 설정 오류 상태 레지스터, 데이터 오류 상태 레지스터, 그리고 설정 오류 어드레스 레지스터 등이다. 이 레지 스터는 어떤 구현 방법에서 조합 되며, 보안 관점에서 볼 때 데이터를 누수를 막기 위함이다.
PC 샘플 레지스터: 디버그 TAP는 PC를 검사 체인 7에서 억세스 할 수 있도록 한다. 보안 관점에서의 디버그 상태에서는 보안 모드에서 의존한 마스트 값을 디버그 할 때, 비보안 모드 상태에서는 보안 모드에서 실행 되는 코어는 PC의 어떤 값도 유저 어플리케이션이 사용할 수 없도록 하고 있다.
TLB 입력값: CP 15를 이용하여 마이크로 TLB상에서 읽고 쓰는 TLB입력 값을 말한다. 우리는 또한 주 TLB와 마이크로 TLB상의 로딩과 매칭을 조절 할 수 있다. 이런 종류의 운용은 반드시 강제적으로 수행 되어야 하며, 특별히 보안 스레드 상의 디버그가 MMU/ MPU의 보조를 요구하게 된다.
성능 모니터 조절 레지스터: 성능 조절 레지스터는 캐쉬가 오류가 난 경우에 마이크로 TLB가 오류가 난 경우에 외부 메모리 요구를 부분 설정 수행등에 사용한다. 비보안 상태에서는 이 데이터를 디버그 상태로 만들어 지지 않도록 했다. 이 카운터 값은 보안 상태에서 동작할 수 있도록 한다.
캐쉬 시스템 디버그: 디버깅은 비 침투적인 캐쉬 시스템이어야 한다. 이것은 캐쉬와 외부 메모리 상의 유기성을 확보할 수 있도록 한다. 캐쉬는 CP15를 사용하면서, 캐쉬가 모든 영역에서 강제로 쓰기를 할 수 있도록 한다. 모든 경우에, 캐쉬의 수정은 보안 상태의 약점을 디버그 할 수 있도록 제어 될 수 있도록 한다.
엔디언(endianness): 비보안 상태나 보안 유저 어플리케이션 상에서는 엔디언의 변화를 허용하지 않도록 제어를 해야 한다. 엔디언의 변화는 보안 커널을 비 정상적으로 발생하도록 야기시킨다. 엔디언 억세스는 입상에 의하여, 디버그 상에서 금지된다.
모니터 기능의 억세스는 코어가 제어하면서 모니터기능을 수행할 수 있도록 한다. 디버그와 트레이스는 여러 종류로 초기화 된다. 본 발명의 실시예에서 모니터 기능의 억세스는 보안 부분에서 특정한 환경에서의 초기화를 가능하게 하는 코어의 보안 부분이 제공된다.
이러한 기법의 구현 방법에 있어서 모니터링 기능은 다음의 입상에 디버그 상태에 의한다.
디버그 값을 보안 유저 모드 상에서 단지 혹은 모드 보안 상태에서, 디버그 모드를 가능하게 한 상태에서 스레드 ID가 보안 유저 모드 상태에서의 관리를 맡게 된다.
모니터링 기능을 초기화 하기 위해서는, 해당되는 기능이 전부 활성화 되어야 한다. 도 60은 테이블을 도식화 하여 가능한 방법을 초기화하여 모니터링 기능을 활성화 시키고, 모니터링 기능의 종류에 따라서 초기화 설정이 프로그래밍되도록 한다.
일반적으로, 모니터링 설정은 소프트웨어나 혹은 하드웨어 상태에서 입력될 수 있다. 모니터링 기능을 활성화 하기 위해서는, 제어 값이 사용되게 된다. 이러한 조합은 비트 들이 조건적으로 의존하게 되며, 만약 조건이 존재하는 경우에는 모니터링은 단지 비트가 설정 되었을 때시작 할 수 있도록 한다. 이는 ICE530에 위치하고 있는 CP14 보안 레지스터에 저장된다.
본 발명의 실시예에 있어서 디버그 모드에서 관찰 가능한 4개의 비트 들이 존재한다. 이는 보안 디버그 활성화 비트, 보안 트레이스 활성화 비트, 보안 유저 모드활성화 비트와 보안 스레드 인식 활성화 비트 등이다. 이러한 제어 값들은 조절 가능한 입상을 위해 모니터링 기능을 수행하여 데이터 누락을 특정한 도메인 상에서 막기 위해 사용된다. 도 61에는 이와 같은 내용에 대해 어떻게 억세스할 것인가에 대한 내용이 도시되어 있다.
이러한 제어 비트는 보안 도메인 상의 레지스터를 저장하여 3가지 가능성으로 볼 수 있다. 소프트웨어 억세스를 ARM프로세서/ MRC/MCR보조 프로세스를 통해 보안관리자 모드를 이용해서 억세스할 수 있도록 하고 있다. 선택적으로, 소프트웨어억세스는 다른 모드에서 인증코드를 이용해 억세스할 수 있도록 하게 한다. 더 다른 비교 내용은 더 다른 하드웨어 억세스과 이에 관한 설정이 존재해서 입력 포트와 JTAG을 관리 할 수 있도록 한다. 게다가, 모니터링 함수의 사용가능성과 관련한 제어값의 입력 이외에도 입력 포트는 프로세서의 다른 함수들과 관련한 제어값의 입력에 사용될 수도 있다.
스캔체인 및 JTAG에 관한 더욱 구체적인 사항은 다음과 같다.
등록 로직 셀
모든 집적 회로는 두 가지의 로직을 가진다.
조합형 로직 셀 예를 들어서 AND, OR, INV와 같은 게이트를 가진다. 그러한 게이트와 조합들은 단일 혹은 수 차례의 시그널에 의한 부울린 계산 공식에 의해 표현된다.
래치, 플립플롭과 같은 레지스터 로직 셀. 그러한 셀은 시그널 값을 저장하는데 쓰인다. 도 62에 포지티브 엣지 플립플롭이 도시되어 있다.
클럭 시그널 (CK)에 포지티브 엣지 이벤트가 발생하는 경우에 출력(Q)는 입력(D)값을 수신한다; 또는 출력(Q)는 그의 값을 메모리에 유지한다.
스캔 체인 셀
디버그의 목적으로, 등록 로직 셀의 기능적인 부분이 패스되야 하는 경우가 있다. 이런 등록 셀은 스캔 체인 셀로서 통합되며, 도 63에 나타나 있다.
기능 모드에서, SE(검색 가능)은 초기화 되어 등록 셀은 단일 등록 셀로서 운용되며, 테스트나 디버그 모드에서 SE는 설정되고 입력된 데이터가 D 입력 대신에 SI입력으로 대체된다.
스캔 체인
삭제
모든 스캔 체인은 도 64에 나타난 대로 사슬형태로 만들어져 있다.
기능 모드에서 SE가 초기화 되고 모든 등록 셀이 정상적으로 억세스가 가능하고 다른 회로의 로직이 상호 작용을 할수 있게 한다. 테스트나 디버그 모드에서는, SE가 활성화 되고 모든 레지스터는 스캔 체인에 의해 사슬형태로 나열되게 된다. 데이터는 첫번째 스캔 체인에서 전송되며, 각각의 클럭 사이클에 맞게 돌아간다. 데이터는 레지스터의 등록 형태에 따라서 이동 되기도 한다.
탭 콘트롤러
디버그 탭 콘트롤러는 여러 개의 스캔 체인을 관리할 때 사용한다. 탭 콘트롤러는 특정한 스캔 체인을 사용할 수있는데 "scan in", "scan out" 과 같은 시그널을 특성 스캔 체인으로 보내는 역할을 한다. 탭 콘트롤러는 JTAG에 의해 외부에서 통제를 받는다. 도 65에 탭 콘트롤러에 대한 설명이 나와있다.
JTAG의 선택적인 비활성화 스캔 체인 셀
보안상의 이유로, 어떤 레지스터는 스캔 체인에 의해 검색이 안될 수 도 있다. 이러한 경우 테스트나 디버그 모드상에서도 불가하며 새로운 입력 방식인 JADI는 이러한 것을 유동적으로 제거하거나 고정적인 형태에서의 스캔 체인에서부터 전체적인 모든 체인으로, 수정 없이 집적 회로 상에서 제거 할 수 있도록 한다. 도 66A에 B항목에 그 내용이 나와 있다.
만약 JADI가 비 활성화 되는 경우에, 그 상황이 기능 모드거나 혹은 테스트, 디버그 모드 인경우에는, 스캔 체인은 일상적으로 동작한다. 그러나 JADI가 활성화 되어 있는 상태에서는, 디버그 모드 상태에서 스캔 체인 셀이 전체 체인 구조에서 제거 될 수 있다.
스캔 체인 셀의 동일 번호를 유지하기 위해서 JTAG의 JADI가 레지스터를 비활성화 시킨다. SO와 Q는 다른 형태이다.
도 67은 JTAG을 활용하고 있는 프로세싱에 대한 내용을 보여 주고 있다. 일반적인 동작 상태에서는 메모리 550이 코어와 통신을 하게 되고, 그러한 환경에서는 레지스터 CP14 등과 같은 관리 값을 가지게 된다. 이것을 일반적으로 보안 관리자 모드에서만 수행이 가능하다.
디버그 모드가 초기화 되고 입력 값이 TAB 580을 통해 입력될 때, 이것은 코어를 제어 하고 있는것으로 볼 수 있다. 코어는 단계 바이 단계 모드로 동작한다. 디버그 TAP은 CP 14로 코어를 통해 억세스를 하며, 제거 값은 또한 이런 식으로 초기화 된다.
CP 14레지스터를 TAP 580을 통해 관리하는 것은 JSDAEN시그널에 의한다. 이것은 억세스를 위한 목적과, JSDAEN이 높은 속성 권한을 가지게 하는데 있다. 모든 보드 특성에 대한 검사가 완료되면 JSDAEN은 디버그가 활성화 되고 이것은 제어 값에 대한 관리 권한이 보안 모드로 전환되면서 디버그 TAP 580에 대한 활성화가 이루어 진다. 일반적으로 프로세스는 보안 모드에서 동작하고 JSDAEN이 그 근간을 이룬다. 제어 값에 대한 내용은 이와 같고, 지시 메모리 550에 의한 소프트웨어 라우트가 가능해 진다. 이 라우트를 통해서 보안된 관리자 모드와 혹은 다른 인증 코드에 의한 모드가 제공된다.
디폴트 디버그는 단지 비보안 모드 상에서만 이루어진다. 이를 보안모드에서 가능하게 위해서는제어 값의 비트가 활성화 되어야 한다.
디버그 모드에 대한 이점은 항상 유저가 비보안 상태로 들어갈 수 있다는 것이다. 고로, 보안 모드로의 억세스는 일반적으로 유저들이 디버그 모드 일 때는 가능하지 않으며, 많은 경우에서 보안 모드로의 억세스는 힘든 부분이 있으며, 가능해 지기 전에 보드 단계를 확인한다. 보안 관리자는 CP 15에 데이터를 작성하면서 소프트 웨어 라우트를 실행 하게 된다.
도 68은 디버그 초기화에 대한 내용을 나타내고 있다. 이 도면에서 코어 600에 해당하는 부분은 보안 상태 비트 S를 표시하며 시스템이 보안 모드인지 아닌지를 표시한다. 코어 600은 또한 602 레지스터의 협업 비트 S를 표시하거나 프로세스가 운용 중인때에, 예를 들어서 유저 모드와 같은 경우에 레지스터 603에 내용 구분자를 제공하여 현재 코어에서 운용되는 스레드와 어플레케이션의 종류를 확인할 수 있게 해 준다.
분기점에 비교자 601에 도달할 때 분기점에서 레지스터 611은 레지스터 612에 저장된 메모리의 주소를 기억하여 제어 로직 620 쪽으로 신호를 보낸다. 제어 로직 620은 보안 상태 S의 모드를 602 와 그 스레드로 보내게 되며, 이를 레지스터 CP 14에 저장한다. 만약 시스템이 보안 모드에서 동작하지 않는 다면 630에 보안 모드 입력이 표시된다. 그리고 만약에 시스템이 보안 모드에서 동작하는 경우, 보안 로직 620은 모드 602에 나타나며, 만약 유저모드에서 이 모드가 유효한지 확인하는 데는 디버그 모드가 설정이 된다. 만약 디버그 모드가 초기화되고, 스레드가 비트 상에서 인식되는 경우에는 상기 도면은 제어 값에 대한 특성을 보여준다.
모니터 제어의 스레드 인식 부분은 레지스터 CP14에 저장되어 있는 제어값이 보안 관리자 모드에서만 어떻게 변경되어 질 수 있는가가 도 68에 도식적으로 나타내어져 있다(이 실시예에서 프로세서는 생산 단계에 있고, JSDAEN은 그라운드에 의지한다). 보안 유저 모드에서는, 보안 관리자 모드가 인증 코드를 이용하여 제어 값을 CP14에 설정 할 수 있는 부분을 설명하고 있다.
제어 로직 620은 디버그 입력 시그널을 비교자 610에 보내면서 분기점에 도달하여 스레드 비교자 640에 대한 스레드의 디버그가 가능함을 보여 준다. 이 가정은 스레드가 CP 14에 비트 형태로 존재함을 나타낸다. 만약 스레드의 초기화 비트가 분기점에 도달하게 되는 경우에는, 디버그 혹은 트레이스와 같은 모니터 기능이 동작하여 스레드 표시자가 분기점에 도달한 데이터가 옳은 것인지에 대한 판단을 돕게 된다. 분석된 데이터를 추출하여 내용을 구분할 수 있도록 하는 것은 비교자 640에서 스레드가 가능하도록 한다.
이 실시예에서, 입상 내부의 구조도가 존재한다. 그런 결과로 어떤 디버그나 트레이스 상에서는 보안 유저 모드가 실행 되어 보안 스레드가 활성화 되는 비트로 바귀게 된다. 이는 도 69A와 69B에 나타나 있다.
제어 값은 디버그 와 상태 제어 레지스터 (CP14)제거 보안 디버그 입상에 있는 도메인에 따라, 모드와 수행 스레드를 제어한다. 이것이 최상위 보안 관리자 모드이다. 만약 디버그 및 상태 제어 레지스터 CP14 가 구성 되어 있는 경우라면, 이는 보안 관리자 모드가 해당하는 분기점에, 주 시점에 대해 프로그래밍 하는 것이고, 코어는 디버그 상태로 들어가게 된다.
도 69A는 침투 디버그에 관한 보안 디버그 입상의 요약을 도시한다. 리셋의 기본값은 회색으로 표현되어 있다.
디버그 입상에 관한 관찰 디버그의 경우에도 마찬가지이다. 도 69B는 이 경우 보안 디버그 입상의 요약을 도시하는데, 이때 리셋의 기본값이 회색으로 표현되어 있다.
보안 사용자 모드 디버그 가능 비트 및 보안 쓰레드-인지 디버그 가능 비트는 일반적으로 강제적이고 주목할만한 디버그에 활용됨을 주의해야 한다.
쓰레드 인지 초기설정 비트는 레지스터 CP14에 저장되어 있으며, 이는 어플리케이션에 의해 세분성이 요구되는가를 지시한다. 쓰레드 인지 비트가 초기화되면, 차후 제어 로직이 프로그램 식별자 혹은 쓰레드 603가 쓰레드 인지 제어 값에 지시된 것인지 혹은 아닌지를 검증하고, 만약 그렇다면 디버그가 초기화될 것이다. 사용자 모드나 디버그 가능 비트 중에 하나가 설정되지 않거나 쓰레드 인지 비트가 설정되고 어플리케이션 작동이 쓰레드 인지 제어 값에 인지되지 않았을 때에는 중지점은 무시될 것이며, 코어는 수행하던 일을 계속 진행하여서 디버그는 초기화되지 않을 것이다.
모니터링 기능의 제어 초기화에 더하여, 모니터 기능 시의 진단 데이터의 캡쳐도 또한 비슷한 방법으로 제어될 수 있다. 이것을 수행하기 위하여 코어는 레지스터 CP 14에 저장된 가능 비트와 같은 제어 값과 모니터링 기능 작동 시에 연관되는 상태, 두 가지에 지속적으로 주의하여야 한다.
도 70은 모니터링 함수의 실행시의 입상을 개략적으로 도시한다. 이 경우 영역 A는 진단 데이터를 포착할 수 있도록 침투가능한 영역과 관련되며, 영역 B는 CP14에 저장된 그 제어값이 진단 데이터를 포착하는 것이 불가능함을 나타내는 영역과 관련된다.
따라서, 디버그와 프로그램이 영역 A에서 실행되면 진단 데이터는 디버그 중 순차적(step-by-step) 방식으로 출력된다. 동작이 영역 B로 스위칭되면 진단 데이 터의 포착은 허용되지 않으며, 디버그는 더이상 순차적 방식으로 진행되지 않고 아토믹하게 진행되어 어떠한 데이터도 포착되지 않는다. 이는 프로그램의 동작이 영역 A로 복귀할 때 까지 지속되며, 복귀후 진단 데이터의 포착 및 순차적 방식의 디버그가 재개된다.
상기의 실시예에 있어, 만일 보안 도메인이 비활성화되면, SMI 명령어는 항상 아토믹 이벤트로 여겨지며, 진단 데이터의 포착은 억제된다.
나아가, 만일 쓰레드 인식 개시 비트(thread aware initilaisation bit)가 설정되면 어플리케이션에 따른 모니터링 함수의 입상이 또한 발생한다.
관찰 가능한 디버그 또는 트레이스에 대하여, 이는 ETM에 의하여 완료되며 디버그와는 완전히 독립적이다. 트레이스가 활성화되면 ETM은 통상적으로 동작하며 비활성화되면 ETM은 트레이스를 보안계로 숨기거나 선택된 입상에 따라 보안계의 일부분으로 숨긴다. 보안 도메인에서 이것이 활성화되지 않은 경우에 ETM 포착과 진단 데이터의 추적을 피하는 방법의 하나는 S비트가 높은 값일 때 ETM을 지연시키는 것이다. 이것은 S비트와 ETMPWRDOWN 신호를 결합함으로써 수행되며, 코어의 보안계 진입시 ETM 값이 마지막 보유했던 값으로 유지된다. ETM은 따라서 SMI 명령어를 추적하여 코어가 비보안계로 복귀할 때까지 지연된다. 따라서, ETM은 비보안 활동만을 볼 수 있다.
다른 모니터링 함수와 그 입상에 대한 요약은 다음과 같다.
보드 단계(board stage)에서의 침투 디버그
보드 단계에서 JSDAEN 핀이 연결되지 않으면, 부트 세션을 시작하기 전에 어디에서든지 디버그를 활성화할 수 있다. 유사하게, 만일 보안 관리자 모드에서도 유사한 권한을 갖는다.
만일 중지 디버그 모드에서 디버그를 개시하면 모든 레지스터에 억세스 할 수 있으며 (비보안 및 보안 레지스터 뱅크) 디버그 제어를 위한 전용비트를 제외한 모든 메모리가 덤프될 수 있다.
디버그 중지 모드는 어떤 도메인, 어떤 모드에서든지 진입가능하다. 브레이크 포인트와 와치 포인트는 보안 또는 비보안 메모리에 설정될 수 있다.
디버그 상태에서, MCR 명령어를 통해 S비트를 변경하는 것으로써 보안계로 들어가는 것이 가능하다.
보안 예외가 발생할 경우 디버그 모드에 들어갈 수 있으므로, 벡터 트랩 레지스터는 다음과 같은 새로운 비트들로 확장된다.
SMI 벡터 트래핑 가능
보안 데이터 포기 벡터 트래핑 가능
보안 프리패치 포기 벡터 트래핑 가능
보안 미지정 벡터 트래핑 가능
모니터 디버그 모드에서, 심지어는 비보안계에서 SMI가 호출되는 상황에서 우리가 모든 부분을 디버그 할 수 있도록 허가한다면, 단계별 디버그에서 보안계에 진입하는 것이 가능하다. 보안 도메인에서 중지점이 발생하는 경우, 보안 포기 핸들러가 보안 레지스터 뱅크와 보안 메모리의 덤프를 실행할 수 있다.
보안계와 비보안계 안의 두 개의 포기 핸들러는 디버깅 어플리케이션에 그들의 정보를 제공하여, (연관된 디버그 제어 PC의) 디버그 창에 보안계와 비보안계의 레지스터 상태를 표시토록 한다.
도 71A는 코어가 모니터 디버그 모드에서 구성되고 보안계에서 디버그가 가능한 경우에 무엇들이 발생되는지에 관해 보여주고 있다. 도 71B는 코어가 모니터 디버그 모드에서 구성되고 보안계에서 디버그가 불가능한 경우에 무엇들이 발생되는지에 관해 보여주고 있다. 차후의 프로세스는 아래에 기술되어 있다.
제작 단계에서의 강제 디버그
제작 단계에서 JSDAEN이 비보안계에 연관되어 있으며 디버그가 비보안계에만 한정되어 있는 경우에, 보안 감독자가 다른 것들을 정하지 않는다면 발생할 상황들에 대해 도해 71B의 도표에 기록되어 있다. 이러한 경우 SMI는 보안 기능이 항상 디버그 상태에 진입하기 전에 종료되도록 하기 위해 항상 원자 명령어로서 인식되어져야 한다.
디버그 중지 모드로의 진입시 다음과 같은 제약을 받는다.
외부 디버그 요구 또는 내부 디버그 요구는 비보안계에서만 고려된다. 만일 EDBGRQ(외부 디버그 요구)이 보안계에서 설정되면, 코어는 디버그 중지모드로 진입하며, 보안 함수가 종료되면 코어는 비보안계로 복귀한다.
브레이크 포인트 또는 와치 포인트를 보안 메모리 상에 프로그래밍하는 것은 아무런 효력이 없으며 코어는 프로그램된 주소와 일치하더라도 중단되지 않는다.
벡터 트랩 레지스터(이하에서 상세히 설명함)는 비보안 예외만을 고려한다. 모든 확장된 트랩 활성화 비트는 무효화되기 전에 설명된다.
중지 디버그 모드에서는 다음과 같은 제약이 적용된다 :
S비트는 보안 디버그가 활성화 된 경우를 제외하고는 보안계 진입을 위하여 변경될 수 없다.
모드 비트는 보안 관리자 모드에서만 디버그가 허용된 경우 변경될 수 없다.
보안 디버그를 제어하는 전용 비트는 변경될 수 없다.
SMI가 로드되어 실행되면(시스템 속도 억세스로) 코어는 보안 함수가 완전히 실행된 경우에만 디버그 상태로 재진입한다.
모니터 디버그 모드에서는 보안계에서 모니터링이 발생할 수 없으므로, 보안 취소 핸들러가 디버그 모니터 프로그램을 지원할 필요가 없다.
비보안계에서는 "step-by-step"가 가능하지만, SMI가 실행되면 언제나 보안 함수가 완전히 실행되어 "step-in" 및 "step-over"이 다른 모든 명령어에서 가능한 반면, XWSI "step-over"만이 허용된다. XWSI는 따라서 아토믹 명령어로 간주된다.
한번 보안 디버그가 비활성화 되면, 다음과 같은 제약을 받는다.
모니터 모드로 진입전 :
브레이크 포인트와 와치 포인트는 비보안계에서만 고려된다. 만일 S 비트가 설정되면 브레이크 포인트/와치 포인트는 통과된다. 와치 포인트 유니트는 브레이크 포인트/와치 포인트가 보안 메모리에 아무런 영향이 없어 보안상 문제점이 없으므로 MCR/MRC(CP14)로 억세스 가능하다.
BKPT는 브레이크 포인트가 설정된 명령어를 대체하기 위하여 정상적으로 사 용된다. 이는 비보안 모드에서만 가능할 BKPT 명령어에 의하여 메모리 내부의 명령어를 덮어쓰는 것을 지원한다.
벡터 트랩 레지스터는 비보안 예외만을 고려한다. 모든 확장된 트랩 활성화 비트는 무효화되기 이전에 설명된다. 데이터 취소(Data abort) 및 프리펫치(Pre-fetch) 활성화 비트는 프로세서가 복구불능의 상태로 되는 것을 방지하기 위하여 비활성화 되어야 한다.
중단 모드(halt mode)에서도 JTAG를 통해 마찬가지의 제약을 받는다. (S비트는 변경될수 없는 등.)
모니터 모드에서 1회(비보안 취소 모드)
비보안 취소 핸들러는 비보안계로 덤프할 수 있으며 보안 메모리 뿐만 아니라 보안 뱅크 레지스터를 볼 수 없다.
보안 함수를 아토믹 SMI 명령어로 실행하라
S비트는 보안계 진입을 위하여 변경될 수 없다.
모드 비트는 보안 관리자 모드에서 디버그가 활성화되어도 변경될 수 없다.
만일 외부 디버그 요구(EDBGRQ)가 발생하면,
비보안계에서는, 코어가 현재의 명령어를 종료하고 즉시 디버그 상태(중단 모드의)로 진입한다.
보안계에서는 코어가 비보안계로 회귀할 때 현재 함수를 종료하고 디버그 상태로 진입한다.
새로운 디버그 요구사항은 코어 하드웨어의 일부 변형을 의미한다. S비트는 세심하게 제어되어야 하며 보안 비트는 보안상의 이유로 스캔 체인에 삽입되지 말아야 한다.
요약하면, 디버그에서는 보안 관리자 모드에서 디버그가 활성화 된 경우에만 모드 비트가 변경될 수 있다. 보안 도메인에서 디버그에 억세스할 수 있는 자가 시스템을 변경시켜(TBL 진입 등) 보안계 전체에 억세스 하는 것을 방지한다. 이러한 방식으로 각각의 쓰레드는 자신의 코드를 디버그 할 수 있으며, 또한 자신의 코드만을 디버그 할 수 있다. 보안 커널은 안전하게 유지되어야 하며, 따라서 코어가 비보안계에서 동작중일 때 디버그에 진입하는 경우 모드 비트는 그 이전에 변경되어야만 한다.
이러한 기법에 따른 실시예에서는 새로운 벡터 트랩 레지스터를 사용한다. 만일 이 레지스터 내부의 하나의 비트가 높은 값으로 설정되고 대응하는 벡터가 촉발되면 프로세서는 적절한 예외 벡터로부터 명령어 펫치에 브레이크 포인트가 설정된 것처럼 디버그 상태로 진입한다. 이러한 비트들의 움직임은 디버그 제어 레지서트의 "Debug in Secure world Enable"비트의 값에 따라서 달라진다.
새로운 벡터 트랩 레지스터는 다음의 비트로 구성된다 : D_s_abort, P_s_abort, S_undef, SMI, FIQ, IRQ, Unaligned, D_abort, P_abort, SWI, 및 Undef.
- D_s_abort 비트 : 보안계에서 디버그가 활성화된 경우 및 중단 디버그 모드에서 디버그가 조정된 경우에만 설정되어야 한다. 만일 보안계에서 디버그가 비활성화 된 경우 이 비트는 그 값이 무엇이건 상관없이 효력이 없다.
- P_s_abort 비트 : D_s_abort 비트와 동일하다.
- S_undef 비트 : 보안계에서 디버그가 활성화 된 경우에만 설정되어야 한다. 보안계에서 디버그가 비활성화 된 경우 그 값이 무엇이건 상관없이 효력이 없다.
- SMI 비트 : 보안계에서 디버그가 활성화 되었을 경우에만 설정되어야 함. 만일 보안계에서 디버그가 비활성화된 경우, 해당 비트는 그 값이 무엇이건 상관없이 효력이 없다.
- FIQ, IRQ, D_abort, P_abort, SWI, undef 비트 : 비보안 예외에 대응하는 것으로 보안계에서 디버그가 비활성화 되어 있어도 유효하다. D_abort 및 P_abort는 모니터 모드에서 높은 값으로 설정되어야 한다.
- 리셋 비트 : 리셋 발생시 보안계로 진입하는데, 이 비트는 보안계에서 디버그가 활성화 되어 있을 때에만 유효하며 다른 경우 효력이 없다.
비록 본 발명의 구체적인 실시예가 개시되어 있으나, 본 발명이 이에 한정되지 아니함은 명백하며 본 발명의 범위 내에서 많은 변형이나 부가가 가능하다. 예를들어, 이하의 종속항의 구성요소의 다양한 결합은 본 발명의 범위를 벗어나지 않고 독립항의 구성요소에 의하여 도출될 수 있다.

Claims (50)

  1. 보안 도메인과 비보안 도메인을 갖는 데이터 처리장치로서, 상기 데이터 처리 장치의 디바이스들이 상기 보안 도메인에 있어서 비 보안 도메인에서는 억세스할 수 없는 보안 데이터에 억세스하는 상기 데이터 처리 장치에 있어서,
    디바이스 버스와,
    상기 디바이스 버스에 연결되어 상기 보안 도메인 또는 상기 비보안 도메인에 관련된 메모리 억세스 요구를 발행하도록 각각 동작하는 복수의 디바이스로서, 상기 디바이스들 중 적어도 하나는 상기 비 보안 도메인에서의 모드인 적어도 하나의 비 보안 모드와 상기 보안 도메인에서의 모드인 적어도 하나의 보안 모드를 포함하는 복수의 모드에서 동작할 수 있는 복수의 디바이스와,
    상기 디바이스 버스에 연결되어 메모리내의 데이터 항목으로의 억세스가 요구될 경우에 상기 디바이스 버스에 메모리 억세스 요구를 발행하도록 동작하는 상기 디바이스들에 의해 요구된 데이터를 저장하도록 동작하는 메모리로서, 보안 데이터를 저장하는 보안 메모리와 비 보안 데이터를 저장하는 비 보안 메모리를 구비하는 메모리와,
    상기 디바이스 버스에 연결되고, 상기 디바이스들 중 어떤 디바이스에 의해 발행된 상기 메모리 억세스 요구가 상기 비보안 도메인에 관련될 때마다 그 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출가능하도록 동작하고, 검출시에 상기 메모리 억세스 요구에서 특정된 억세스를 방지하는 파티션 검사 로직부를 구비한 것을 특징으로 하는 데이터 처리장치.
  2. 제 1 항에 있어서,
    상기 디바이스들 중 적어도 하나에 대해, 상기 복수의 모드가 상기 보안 도메인 및 상기 비 보안 도메인에서 복제되는 것을 특징으로 하는 데이터 처리장치.
  3. 제 1 항 또는 제 2 항에 있어서,
    상기 파티션 검사 로직부는, 상기 보안 도메인의 소정의 보안 모드에서 동작하고 있을 때 상기 디바이스들 중 하나에 의해 관리되는 것을 특징으로 하는 데이터 처리장치.
  4. 제 1 항 또는 제 2 항에 있어서,
    상기 디바이스들에 의해 발행된 메모리 억세스 요구는, 그 메모리 억세스 요구가 상기 보안 도메인 또는 상기 비보안 도메인에 관련되어 있는지를 식별하는 도메인 신호를 포함하고,
    상기 도메인 신호는 상기 메모리 억세스 요구의 억세스 대상에의 억세스를 수행할 것인가를 결정하기 위하여 상기 파티션 검사 로직부에 의해 사용되는 것을 특징으로 하는 데이터 처리장치.
  5. 제 4 항에 있어서,
    상기 디바이스들은, 상기 디바이스 버스 상에 도메인 신호를 출력하는 소정의 핀을 갖는 것을 특징으로 하는 데이터 처리장치.
  6. 제 1 항 또는 제 2 항에 있어서,
    상기 파티션 검사 로직부는, 상기 디바이스 버스에 연결되어 상기 디바이스 버스 상에서 발행된 메모리 억세스 요구들간의 중재를 행하는 중재기 내에 구비된 것을 특징으로 하는 데이터 처리장치.
  7. 제 1 항 또는 제 2 항에 있어서,
    상기 디바이스들 중 적어도 하나는 상기 비보안 도메인에서 비보안 운영체계의 제어하에 동작가능하고, 상기 디바이스들 중 적어도 하나는 상기 보안 도메인에서 보안 운영체계의 제어하에 동작가능한 것을 특징으로 하는 데이터 처리장치.
  8. 제 1 항에 있어서,
    상기 디바이스들 중 적어도 하나는 프로세서를 내장한 칩으로, 상기 칩은, 상기 프로세서가 메모리 억세스 요구를 발생하는 경우, 1개 이상의 소정의 억세스 제어 기능을 수행하여 상기 디바이스 버스 상에 메모리 억세스 요구를 발행하는 것을 제어가능하도록 동작하는 메모리 관리부를 더 구비한 것을 특징으로 하는 데이터 처리장치.
  9. 제 8 항에 있어서,
    상기 칩은, 시스템 버스를 통해 프로세서에 연결되고, 상기 프로세서에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 추가 메모리와 비보안 데이터 저장용 비보안 추가 메모리를 포함한 추가 메모리와,
    상기 시스템 버스에 연결되고, 상기 비보안 도메인에서의 비보안 모드에서 동작하고 있을 때 상기 프로세서에서 메모리 억세스 요구를 발생할 때마다, 상기 메모리 억세스 요구가 상기 보안 메모리 또는 상기 보안 추가 메모리를 억세스하려고 하고 있는지를 검출가능하도록 동작하여, 그 검출시에 그 메모리 억세스 요구에서 특정한 억세스를 방지하는 추가의 파티션 검사 로직부를 더 구비한 것을 특징으로 하는 데이터 처리장치.
  10. 제 9 항에 있어서,
    상기 프로세서는, 비보안 도메인에서의 모드인 적어도 하나의 비보안 모드와 보안 도메인에서의 모드인 적어도 하나의 보안 모드로 이루어진 다수의 모드에서 동작가능하고, 상기 적어도 하나의 비보안 모드에서 상기 프로세서가 비보안 운영체계의 제어하에서 동작가능하고, 상기 적어도 하나의 보안 모드에서 상기 프로세서가 보안 운영체계의 제어하에서 동작가능하며,
    상기 추가의 파티션 검사 로직부는 보안 운영체계에 의해 관리되는 것을 특 징으로 하는 데이터 처리장치.
  11. 제 10 항에 있어서,
    상기 프로세서가 적어도 하나의 비보안 모드에서 동작하고 있을 때, 메모리 억세스 요구는 가상 어드레스를 특정하고, 상기 메모리 관리부는 비보안 운영체계에 의해 제어되고, 상기 메모리 관리부에 의해 수행된 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 상기 추가의 파티션 검사 로직부는, 메모리 관리부에 의해 생성되는 물리 어드레스가 보안 메모리 내에 있는 경우 그 메모리 억세스 요구에서 특정된 억세스를 방지가능하도록 동작하는 것을 특징으로 하는 데이터 처리장치.
  12. 제 10 항에 있어서,
    상기 프로세서가 적어도 하나의 보안 모드들 중 하나의 모드에서 동작하고 있을 때, 메모리 억세스 요구는 가상 어드레스를 특정하고, 상기 메모리 관리부는 보안 운영체계에 의해 제어되고, 상기 메모리 관리부에 의해 수행된 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 상기 추가의 파티션 검사 로직부는, 적어도 하나의 보안 모드에서 사용되지 않는 것을 특징으로 하는 데이터 처리장치.
  13. 제 12 항에 있어서,
    상기 프로세서의 모든 동작모드에 대해, 메모리 억세스 요구는 가상 어드레스를 특정하고, 추가의 파티션 검사 로직부는 메모리 관리부 내에 설치되고, 프로세서가 상기 적어도 하나의 비보안 모드에서 동작하고 있을 때마다 동작가능한 것을 특징으로 하는 데이터 처리장치.
  14. 제 11 항에 있어서,
    추가의 파티션 검사 로직부가 내부에 설치된 메모리 보호부를 더 구비하고, 상기 메모리 보호부는 보안 운영체계에 의해 관리되고, 프로세서가 특정 보안모드에서 동작하고 있는 경우, 메모리 억세스 요구는 메모리 위치에 대한 물리 어드레스를 특정하고, 메모리 관리부는 사용되지 않고, 그 메모리 보호부는 적어도 메모리 억세스 허가처리를 수행하고 그 물리 어드레스에 의해 특정된 메모리 위치가 상기 특정 보안 모드에서 억세스 가능한지를 검증가능하도록 동작하는 것을 특징으로 하는 데이터 처리장치.
  15. 제 10 항에 있어서,
    상기 메모리는, 다수의 메모리 영역마다 관련 디스크립터를 포함하는 적어도 한개의 테이블을 포함하고, 상기 메모리 관리부는, 디스크립터로부터 얻어지고 메모리 관리부에서 사용된 억세스 제어 정보를 저장하여 메모리 억세스 요구에 대한 소정의 억세스 제어 기능들을 수행하는 내부 저장부를 구비하고, 상기 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리로의 억세스를 허용할 억세스 제어정보를 상기 내부 저장부가 저장하는 것을 방지가능하도록 동작하는 것을 특징으로 하는 데이터 처리장치.
  16. 제 15 항에 있어서,
    상기 메모리 억세스 요구는 가상 어드레스를 특정하고, 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 각 디스크립터는 적어도 가상 어드레스부와 그에 대응한 메모리 영역에 대한 대응 물리 어드레스부를 포함하고, 상기 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 가상 어드레스에 대해 생성되는 물리 어드레스가 보안 메모리 내에 있으면 억세스 제어 정보로서 상기 물리 어드레스부를 상기 내부 저장부가 저장하는 것을 방지가능하도록 동작하는 것을 특징으로 하는 데이터 처리장치.
  17. 제 16 항에 있어서,
    상기 내부 저장부는, 다수의 가상 어드레스부에 대해 상기 적어도 한개의 테이블로부터 검색된 대응한 디스크립터들로부터 얻어진 대응한 물리 어드레스부를 저장가능하도록 동작하는 변환 색인 버퍼(TLB)인 것을 특징으로 하는 데이터 처리장치.
  18. 제 17 항에 있어서,
    상기 TLB는 마이크로 TLB이고, 상기 내부 저장부는 적어도 한개의 테이블로부터 메모리 관리부에서 검색된 디스크립터들을 저장하는 메인 TLB를 더 구비하고, 억세스 제어정보는, 메모리 관리부에서 그 억세스 제어 정보로 사용하고 그 메모리 억세스 요구에 대한 소정의 억세스 제어기능들을 수행하기 전에 메인 TLB로부터 마이크로 TLB로 전송되고, 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리에의 억세스를 허용하는 메인 TLB로부터 마이크로 TLB로의 임의의 억세스 제어정보의 전송을 방지가능하도록 동작하는 것을 특징으로 하는 데이터 처리장치.
  19. 제 16 항에 있어서,
    적어도 한개의 테이블은, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 상기 비보안 운영체계에서 발생된 디스크립터들을 포함하고 있는 경우 사용하도록 비보안 테이블로 이루어지고, 그 경우에, 비보안 테이블 내의 디스크립터는 적어도 부분적으로 상기 보안 메모리의 일부를 포함하는 메모리 영역과 관련되고, 추가의 파티션 검사 로직부는, 프로세서가 비보안 모드에서 동작하고 있을 때, 가상 어드레스에 대해 생성된 물리 어드레스가 보안 메모리 내에 있으면 그 디스크립터에 의해 특정된 물리 어드레스부를 내부 저장부가 억세스 제어정보로서 저장하는 것을 방지가능하도록 동작하는 것을 특징으로 하는 데이터 처리장치.
  20. 제 19 항에 있어서,
    상기 내부 저장부는, 다수의 가상 어드레스부에 대해 상기 적어도 한개의 테이블로부터 검색된 대응한 디스크립터들로부터 얻어진 대응한 물리 어드레스부를 저장가능하도록 동작하는 변환 색인 버퍼(TLB)이고,
    상기 TLB는 마이크로 TLB이고, 상기 내부 저장부는 적어도 한 개의 테이블로부터 메모리 관리부에서 검색된 디스크립터들을 저장하는 메인 TLB를 더 구비하고, 억세스 제어정보는, 메모리 관리부에서 그 억세스 제어 정보로 사용하고 그 메모리 억세스 요구에 대한 소정의 억세스 제어기능들을 수행하기 전에 메인 TLB로부터 마이크로 TLB로 전송되고, 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리에의 억세스를 허용하는 메인 TLB로부터 마이크로 TLB로의 임의의 억세스 제어정보의 전송을 방지가능하도록 동작하며,
    상기 적어도 한 개의 테이블은, 보안 운영체계에서 발생된 디스크립터들을 포함한 보안 메모리 내의 보안 테이블을 더 구비하고, 상기 메인 TLB는, 그 메인 TLB 내에 저장된 각 디스크립터와 관련된 플래그를 갖고서 그 디스크립터가 상기 비보안 테이블로부터의 것인지 상기 보안 테이블로부터의 것인지를 식별하게 하는 것을 특징으로 하는 데이터 처리장치.
  21. 제 20 항에 있어서,
    상기 마이크로 TLB는, 프로세서의 동작모드가 보안모드와 비보안 모드 사이에서 변화할 때마다 플러시되고, 보안 모드에서 억세스 제어정보는 상기 관련 플래그 표시가 보안 테이블로부터 얻어지는 메인 TLB에 있는 디스크립터로부터 마이크로 TLB에 전달되기만하고, 비보안 모드에서 억세스 제어정보는 상기 관련된 플래그 표시가 비보안 테이블로부터 얻어지는 메인 TLB에 있는 디스크립터로부터 마이크로 TLB에 전달되기만 하는 것을 특징으로 하는 데이터 처리장치.
  22. 제 10 항 내지 제 14 항에 있어서,
    상기 메모리는, 다수의 메모리 영역마다 관련 디스크립터를 포함하는 적어도 한개의 테이블을 포함하고, 상기 메모리 관리부는, 디스크립터로부터 얻어지고 메모리 관리부에서 사용된 억세스 제어 정보를 저장하여 메모리 억세스 요구에 대한 소정의 억세스 제어 기능들을 수행하는 내부 저장부를 구비하고, 상기 추가의 파티션 검사 로직부는, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리로의 억세스를 허용할 억세스 제어정보를 상기 내부 저장부가 저장하는 것을 방지가능하도록 동작하고,
    상기 적어도 한개의 테이블은 적어도 한개의 페이지 테이블을 포함하는 것을 특징으로 하는 데이터 처리장치.
  23. 제 10 항에 있어서,
    상기 추가의 메모리는, 시스템 버스에 연결된 밀결합 메모리를 구비하고, 상기 밀결합 메모리에 대한 물리 어드레스 범위는 제어 레지스터내에 정의되고, 제어 플래그는 특권을 가진 보안 모드에서 동작하고 있을 때, 상기 밀결합 메모리가 특권을 가진 보안 모드에서 실행하고 있는 경우만 프로세서에 의해 제어가능하거나 적어도 한개의 비보안 모드에서 실행하고 있는 경우 프로세서에 의해 제어가능한지를 나타내도록 상기 프로세서에 의해 설정가능한 것을 특징으로 하는 데이터 처리장치.
  24. 제 23 항에 있어서,
    상기 밀결합 메모리가 적어도 한개의 비보안 모드에서 실행하고 있을 때 프로세서에 의해 제어가능하면, 보안 데이터가 상기 밀결합 메모리에 저장되는 것을 방지하는 것을 특징으로 하는 데이터 처리장치.
  25. 보안 도메인과 비보안 도메인을 갖는 데이터 처리장치에서의 메모리에의 억세스를 제어하되, 상기 보안 도메인에 있어서 상기 데이터 처리장치의 디바이스들이 상기 비보안 도메인에서 억세스할 수 없는 보안 데이터에 억세스하는 제어방법으로서, 상기 데이터 처리장치가 디바이스 버스와, 상기 디바이스 버스에 연결되어 상기 보안 도메인 또는 상기 비보안 도메인에 관련된 메모리 억세스 요구를 발행하도록 각각 동작하는 복수의 디바이스로서, 상기 디바이스들 중 적어도 하나는 상기 비 보안 도메인에서의 모드인 적어도 하나의 비 보안 모드와 상기 보안 도메인에서의 모드인 적어도 하나의 보안 모드를 포함하는 복수의 모드에서 동작할 수 있는 복수의 디바이스와,
    상기 디바이스 버스에 연결되고, 상기 디바이스들에서 필요로 하는 데이터를 저장가능하도록 동작하는 메모리를 구비하고,
    상기 메모리가 보안 데이터 저장용 보안 메모리와 비 보안 데이터 저장용 비 보안 메모리를 구비한, 상기 데이터 처리 장치에 있어서의 메모리에의 억세스를 제어하는 방법에 있어서,
    (i) 메모리에 있는 데이터 항목으로의 억세스를 필요로 하는 경우 상기 디바이스 버스 상에서 메모리 억세스 요구를 상기 디바이스들 중 어떤 디바이스로부터 발행하는 단계와,
    (ii) 상기 디바이스들 중 어떤 디바이스에서 발행한 것과 같은 상기 메모리 억세스 요구가 상기 비보안 도메인에 관련될 때마다 그 메모리 억세스 요구가 상기 보안 메모리를 억세스하려고 하는지를 검출하기 위해 상기 디바이스 버스에 연결된 파티션 검사 로직부를 사용하는 단계와,
    (iii) 상기 검출시에 상기 메모리 억세스 요구에서 특정된 억세스를 방지하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  26. 제 25 항에 있어서,
    상기 디바이스들 중 적어도 하나에 대해, 상기 복수의 모드가 상기 보안 도메인 및 상기 비 보안 도메인에서 복제되는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  27. 제 25 항 또는 제 26 항에 있어서,
    상기 파티션 검사 로직부는, 상기 보안 도메인의 소정의 보안 모드에서 동작하고 있을 때, 상기 디바이스들 중 하나에 의해 관리되는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  28. 제 25 항 또는 제 26 항에 있어서,
    상기 디바이스들에서 발행된 각각의 메모리 억세스 요구는, 그 메모리 억세스 요구가 상기 보안 도메인 또는 상기 비보안 도메인에 관련되어 있는지를 식별하는 도메인 신호를 포함하고,
    상기 도메인 신호는 상기 메모리 억세스 요구의 억세스 대상에의 억세스를 수행할 것인가를 결정하기 위하여 상기 파티션 검사 로직부에 의해 사용되는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  29. 제 28 항에 있어서,
    상기 디바이스들은, 상기 디바이스 버스 상에 상기 도메인 신호를 출력하는 소정의 핀을 갖는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  30. 제 25 항 또는 제 26 항에 있어서,
    상기 파티션 검사 로직부는, 상기 디바이스 버스에 연결되어 상기 디바이스 버스 상에서 발행된 메모리 억세스 요구들간의 중재를 행하는 중재기 내에 구비된 것을 특징으로 하는 메모리로의 억세스 제어방법.
  31. 제 25 항 또는 제 26 항에 있어서,
    상기 디바이스들 중 적어도 하나는 상기 비보안 도메인에서 비보안 운영체계의 제어하에 동작가능하고, 상기 디바이스들 중 적어도 하나는 상기 보안 도메인에서 보안 운영체계의 제어하에 동작가능한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  32. 제 25 항에 있어서,
    상기 디바이스들 중 적어도 하나는 프로세서를 내장한 칩으로, 상기 칩은, 상기 프로세서가 메모리 억세스 요구를 발생하는 경우, 상기 방법은,
    1개 이상의 소정의 억세스 제어 기능을 수행하여 상기 디바이스 버스 상에 메모리 억세스 요구를 발행하는 것을 제어하는 메모리 관리부를 사용하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  33. 제 32 항에 있어서,
    상기 칩은, 시스템 버스를 통해 프로세서에 연결되고, 상기 프로세서에서 필요로 하는 데이터를 저장가능하도록 동작하고, 보안 데이터 저장용 보안 추가 메모리와 비보안 데이터 저장용 비보안 추가 메모리를 포함한 추가 메모리와, 상기 시스템 버스에 연결된 추가의 파티션 검사 로직부를 더 구비하고, 상기 방법은,
    상기 비보안 도메인에서의 비보안 모드에서 동작하고 있을 때 상기 프로세서에서 메모리 억세스 요구를 발생할 때마다, 상기 메모리 억세스 요구가 상기 보안 메모리 또는 상기 보안 추가 메모리를 억세스하려고 하고 있는지를 검출하기 위해 추가의 파티션 검사 로직부를 사용하는 단계와,
    그 검출시에 그 메모리 억세스 요구에서 특정한 억세스를 방지하는 단계를 더 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  34. 제 33 항에 있어서,
    상기 프로세서는, 비보안 도메인에서의 모드인 적어도 하나의 비보안 모드와 보안 도메인에서의 모드인 적어도 하나의 보안 모드로 이루어진 다수의 모드에서 동작가능하고, 상기 적어도 하나의 비보안 모드에서 상기 프로세서가 비보안 운영체계의 제어하에서 동작가능하고, 상기 적어도 하나의 보안 모드에서 상기 프로세서가 보안 운영체계의 제어하에서 동작가능하며,
    상기 추가의 파티션 검사 로직부는 보안 운영체계에 의해 관리되는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  35. 제 34 항에 있어서,
    상기 프로세서가 적어도 하나의 비보안 모드에서 동작하고 있을 때, 상기 단계(i)에서 발행된 메모리 억세스 요구는 가상 어드레스를 특정하고, 1개 이상의 소정의 억세스 제어 기능을 수행하기 위해 메모리 관리부를 사용하는 상기 단계는 비보안 운영체계에 의해 제어되고, 수행된 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 상기 추가의 파티션 검사 로직부는, 상기 단계(iii)에서 메모리 관리부에 의해 생성되는 물리 어드레스가 보안 메모리 내에 있는 경우 그 메모리 억세스 요구에서 특정된 억세스를 방지하는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  36. 제 34 항에 있어서,
    상기 프로세서가 적어도 하나의 보안 모드들 중 하나의 모드에서 동작하고 있을 때, 상기 단계(i)에서 발행된 메모리 억세스 요구는 가상 어드레스를 특정하고, 1개 이상의 소정의 억세스 제어 기능을 수행하기 위해 상기 메모리 관리부를 사용하는 상기 단계는 보안 운영체계에 의해 제어되고, 수행된 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 상기 추가의 파티션 검사 로직부는, 적어도 하나의 보안 모드에서 사용되지 않는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  37. 제 36 항에 있어서,
    상기 프로세서의 모든 동작모드에 대해, 상기 단계(i)에서 발행한 메모리 억세스 요구는 가상 어드레스를 특정하고, 추가의 파티션 검사 로직부는 메모리 관리부 내에 설치되고, 프로세서가 상기 적어도 하나의 비보안 모드에서 동작하고 있을 때마다 동작가능한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  38. 제 35 항에 있어서,
    상기 데이터 처리장치는, 추가의 파티션 검사 로직부가 내부에 설치된 메모리 보호부를 더 구비하고, 상기 메모리 보호부는 보안 운영체계에 의해 관리되고, 프로세서가 특정 보안모드에서 동작하고 있는 경우, 상기 단계(i)에서 발행한 메모리 억세스 요구는 메모리 위치에 대한 물리 어드레스를 특정하고, 1개 이상의 소정의 억세스 제어 기능을을 수행하기 위해 메모리 관리부를 사용하는 상기 단계는 수행되지 않고, 그 메모리 보호부는 적어도 메모리 억세스 허가처리를 수행하고 그 물리 어드레스에 의해 특정된 메모리 위치가 상기 특정 보안 모드에서 억세스 가능한지를 검증하는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  39. 제 34 항에 있어서,
    메모리는, 다수의 메모리 영역마다 관련 디스크립터를 포함하는 적어도 한개의 테이블을 포함하고, 상기 방법은,
    메모리 관리부 내에, 디스크립터들로부터 얻어지고 메모리 관리부에서 사용된 억세스 제어 정보를 저장하여 메모리 억세스 요구에 대한 소정의 억세스 제어 기능들을 수행하는 내부 저장부를 설치하는 단계와,
    프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리로의 억세스를 허용할 억세스 제어정보를 상기 내부 저장부가 저장하는 것을 방지하기 위한 상기 추가의 파티션 검사 로직부를 사용하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  40. 제 39 항에 있어서,
    상기 단계(i)에서 발행한 메모리 억세스 요구는 가상 어드레스를 특정하고, 메모리 관리부에서 수행된 상기 소정의 억세스 제어 기능들 중 하나는 가상 어드레스의 물리 어드레스로의 변환을 포함하고, 각 디스크립터는 적어도 가상 어드레스부와 그에 대응한 메모리 영역에 대한 대응 물리 어드레스부를 포함하고, 상기 방법은,
    프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 가상 어드레스에 대해 생성되는 물리 어드레스가 보안 메모리 내에 있으면 억세스 제어 정보로서 상기 물리 어드레스부를 상기 내부 저장부가 저장하는 것을 방지하기 위해 상기 추가의 파티션 검사 로직부를 사용하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  41. 제 40 항에 있어서,
    상기 내부 저장부는, 다수의 가상 어드레스부에 대해 상기 적어도 한개의 테이블로부터 검색된 대응한 디스크립터들로부터 얻어진 대응한 물리 어드레스부를 저장가능하도록 동작하는 변환 색인 버퍼(TLB)인 것을 특징으로 하는 메모리로의 억세스 제어방법.
  42. 제 41 항에 있어서,
    상기 TLB는 마이크로 TLB이고, 상기 내부 저장부는 적어도 한개의 테이블로부터 메모리 관리부에서 검색된 디스크립터들을 저장하는 메인 TLB를 더 구비하고, 상기 방법은,
    메모리 관리부에서 그 억세스 제어 정보로 사용하고 그 메모리 억세스 요구에 대한 소정의 억세스 제어기능들을 수행하기 전에 메인 TLB로부터 마이크로 TLB로 억세스 제어정보를 전송하는 단계와,
    프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리에의 억세스를 허용하는 메인 TLB로부터 마이크로 TLB로의 임의의 억세스 제어정보의 전송을 방지하기 위해서 추가의 파티션 검사 로직부를 사용하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  43. 제 40 항에 있어서,
    적어도 한개의 테이블은, 프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 상기 비보안 운영체계에서 발생된 디스크립터들을 포함하고 있는 경우 사용하도록 비보안 테이블로 이루어지고, 그 경우에, 비보안 테이블 내의 디스크립터는 적어도 부분적으로 상기 보안 메모리의 일부를 포함하는 메모리 영역과 관련되고, 상기 방법은,
    프로세서가 비보안 모드에서 동작하고 있을 때, 가상 어드레스에 대해 생성된 물리 어드레스가 보안 메모리 내에 있으면 그 디스크립터에 의해 특정된 물리 어드레스부를 내부 저장부가 억세스 제어정보로서 저장하는 것을 방지하기 위해서 추가의 파티션 검사 로직부를 사용하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  44. 제 43 항에 있어서,
    상기 내부 저장부는, 다수의 가상 어드레스부에 대해 상기 적어도 한개의 테이블로부터 검색된 대응한 디스크립터들로부터 얻어진 대응한 물리 어드레스부를 저장가능하도록 동작하는 변환 색인 버퍼(TLB)이고,
    상기 TLB는 마이크로 TLB이고, 상기 내부 저장부는 적어도 한개의 테이블로부터 메모리 관리부에서 검색된 디스크립터들을 저장하는 메인 TLB를 더 구비하고, 상기 방법은,
    메모리 관리부에서 그 억세스 제어 정보로 사용하고 그 메모리 억세스 요구에 대한 소정의 억세스 제어기능들을 수행하기 전에 메인 TLB로부터 마이크로 TLB로 억세스 제어정보를 전송하는 단계와,
    프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리에의 억세스를 허용하는 메인 TLB로부터 마이크로 TLB로의 임의의 억세스 제어정보의 전송을 방지하기 위해서 추가의 파티션 검사 로직부를 사용하는 단계를 포함하며,
    상기 적어도 한 개의 테이블은, 보안 운영체계에서 발생된 디스크립터들을 포함한 보안 메모리 내의 보안 테이블을 더 구비하고, 상기 메인 TLB는, 그 메인 TLB 내에 저장된 각 디스크립터와 관련된 플래그를 포함하고, 상기 방법은,
    디스크립터가 메인 TLB에 저장되어 있는 경우, 디스크립터가 상기 비보안 테이블로부터의 것인지 상기 보안 테이블로부터의 것인지를 식별하도록 상기 관련된 플래그를 설정하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  45. 제 44 항에 있어서,
    프로세서의 동작모드가 보안모드와 비보안 모드 사이에서 변화할 때마다 마 이크로 TLB를 플러시하는 단계와,
    보안 모드에서, 상기 관련 플래그 표시가 보안 테이블로부터 얻어지는 메인 TLB에 있는 디스크립터로부터 마이크로 TLB에 억세스 제어정보를 전달하기만 하는 단계와,
    비보안 모드에서, 상기 관련된 플래그 표시가 비보안 테이블로부터 얻어지는 메인 TLB에 있는 디스크립터로부터 마이크로 TLB에 억세스 제어정보를 전달하기만 하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  46. 제 34 항 내지 제 38 항에 있어서,
    메모리는, 다수의 메모리 영역마다 관련 디스크립터를 포함하는 적어도 한개의 테이블을 포함하고, 상기 방법은,
    메모리 관리부 내에, 디스크립터들로부터 얻어지고 메모리 관리부에서 사용된 억세스 제어 정보를 저장하여 메모리 억세스 요구에 대한 소정의 억세스 제어 기능들을 수행하는 내부 저장부를 설치하는 단계와,
    프로세서가 상기 적어도 한개의 비보안 모드에서 동작하고 있을 때, 상기 보안 메모리로의 억세스를 허용할 억세스 제어정보를 상기 내부 저장부가 저장하는 것을 방지하기 위한 상기 추가의 파티션 검사 로직부를 사용하는 단계를 포함하고,
    상기 적어도 한개의 테이블은 적어도 한개의 페이지 테이블을 포함하는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  47. 제 34 항에 있어서,
    추가의 메모리는, 시스템 버스에 연결된 밀결합 메모리를 구비하고, 상기 방법은,
    상기 밀결합 메모리에 대한 물리 어드레스 범위를 제어 레지스터내에 정의하는 단계와,
    특권을 가진 보안 모드에서 동작하고 있을 때 프로세서에 의해, 상기 밀결합 메모리가 특권을 가진 보안 모드에서 실행하고 있는 경우만 프로세서에 의해 제어가능하거나 적어도 한개의 비보안 모드에서 실행하고 있는 경우 프로세서에 의해 제어가능한지를 나타내도록 제어 플래그를 설정하는 단계를 포함한 것을 특징으로 하는 메모리로의 억세스 제어방법.
  48. 제 47 항에 있어서,
    상기 밀결합 메모리가 적어도 한개의 비보안 모드에서 실행하고 있을 때 프로세서에 의해 제어가능하면, 보안 데이터가 상기 밀결합 메모리에 저장되는 것을 방지하는 것을 특징으로 하는 메모리로의 억세스 제어방법.
  49. 삭제
  50. 삭제
KR1020057008761A 2002-11-18 2003-10-27 디바이스에 의한 메모리로의 억세스 제어 KR101015456B1 (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
GB0226875.3 2002-11-18
GB0226875A GB0226875D0 (en) 2002-11-18 2002-11-18 Control of access to a memory by a device
GB0226879.5 2002-11-18
GB0226879A GB0226879D0 (en) 2002-11-18 2002-11-18 Apparatus and method for controlling access to a memory
GB0303446.9 2003-02-14
GB0303446A GB0303446D0 (en) 2002-11-18 2003-02-14 Apparatus and method for controlling access to a memory

Publications (2)

Publication Number Publication Date
KR20050085000A KR20050085000A (ko) 2005-08-29
KR101015456B1 true KR101015456B1 (ko) 2011-02-22

Family

ID=32329547

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057008761A KR101015456B1 (ko) 2002-11-18 2003-10-27 디바이스에 의한 메모리로의 억세스 제어

Country Status (7)

Country Link
US (1) US7305534B2 (ko)
EP (1) EP1563388A2 (ko)
JP (1) JP4302641B2 (ko)
KR (1) KR101015456B1 (ko)
AU (1) AU2003278350A1 (ko)
GB (1) GB2411027B (ko)
WO (1) WO2004046934A2 (ko)

Families Citing this family (105)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6986052B1 (en) 2000-06-30 2006-01-10 Intel Corporation Method and apparatus for secure execution using a secure memory partition
EP1331539B1 (en) * 2002-01-16 2016-09-28 Texas Instruments France Secure mode for processors supporting MMU and interrupts
KR100941104B1 (ko) * 2002-11-18 2010-02-10 에이알엠 리미티드 데이터 처리 장치, 데이터 처리 방법 및 컴퓨터 프로그램을 기억한 컴퓨터 판독가능한 기억매체
JP4686193B2 (ja) 2002-11-27 2011-05-18 エヌエックスピー ビー ヴィ チップが集積されている保護手段
US8892878B2 (en) * 2003-05-09 2014-11-18 Oracle America, Inc. Fine-grained privileges in operating system partitions
DE60315047D1 (de) * 2003-12-19 2007-08-30 Sgs Thomson Microelectronics Halbleiterschaltung zur Begrenzung von Datenzugang
FR2864658B1 (fr) * 2003-12-30 2006-02-24 Trusted Logic Controle d'acces aux donnees par verification dynamique des references licites
US7249208B2 (en) * 2004-05-27 2007-07-24 International Business Machines Corporation System and method for extending the cross-memory descriptor to describe another partition's memory
JP4447977B2 (ja) 2004-06-30 2010-04-07 富士通マイクロエレクトロニクス株式会社 セキュアプロセッサ、およびセキュアプロセッサ用プログラム。
JP2006048643A (ja) * 2004-07-08 2006-02-16 Namco Ltd 端末装置、プログラム、情報記憶媒体およびデータ処理方法
DE102004037590B4 (de) * 2004-08-03 2006-06-14 Infineon Technologies Ag Integrierte Schaltung und Verfahren zum Betrieb einer solchen
WO2006057316A1 (ja) * 2004-11-26 2006-06-01 Matsushita Electric Industrial Co., Ltd. プロセッサ、セキュア処理システム
US7457960B2 (en) * 2004-11-30 2008-11-25 Analog Devices, Inc. Programmable processor supporting secure mode
US7673345B2 (en) * 2005-03-31 2010-03-02 Intel Corporation Providing extended memory protection
EP1713000A1 (en) * 2005-04-11 2006-10-18 Jaluna SA Memory protection system
CN101233525A (zh) * 2005-05-26 2008-07-30 松下电器产业株式会社 数据处理装置
JP4850830B2 (ja) * 2005-06-01 2012-01-11 パナソニック株式会社 コンピュータシステム及びプログラム生成装置
EP1742152B1 (en) * 2005-07-07 2012-09-12 Texas Instruments Inc. Method and system for a multi-sharing memory access control
US9158941B2 (en) * 2006-03-16 2015-10-13 Arm Limited Managing access to content in a data processing apparatus
DE602006014801D1 (de) * 2006-04-24 2010-07-22 Ericsson Telefon Ab L M Prüfung der Berechtigung der Installation einer Softwareversion
US8032761B2 (en) * 2006-05-09 2011-10-04 Broadcom Corporation Method and system for memory attack protection to achieve a secure interface
US8285988B2 (en) 2006-05-09 2012-10-09 Broadcom Corporation Method and system for command authentication to achieve a secure interface
US8560829B2 (en) * 2006-05-09 2013-10-15 Broadcom Corporation Method and system for command interface protection to achieve a secure interface
US7836320B2 (en) * 2006-07-07 2010-11-16 Arm Limited Power management in a data processing apparatus having a plurality of domains in which devices of the data processing apparatus can operate
GB0615392D0 (en) * 2006-08-03 2006-09-13 Wivenhoe Technology Ltd Pseudo random number circuitry
US7529916B2 (en) * 2006-08-16 2009-05-05 Arm Limited Data processing apparatus and method for controlling access to registers
GB2440968B (en) * 2006-08-16 2011-02-02 Advanced Risc Mach Ltd Protecting system control registers in a data processing apparatus
WO2008025036A2 (en) * 2006-08-25 2008-02-28 Texas Instruments Incorporated Data processing systems utilizing secure memory
US8959311B2 (en) * 2006-08-25 2015-02-17 Texas Instruments Incorporated Methods and systems involving secure RAM
GB2442023B (en) * 2006-09-13 2011-03-02 Advanced Risc Mach Ltd Memory access security management
JP4756603B2 (ja) * 2006-10-10 2011-08-24 ルネサスエレクトロニクス株式会社 データプロセッサ
KR20080067774A (ko) * 2007-01-17 2008-07-22 삼성전자주식회사 허가되지 않은 메모리 접근으로부터 비밀 영역을 보호하기위한 방법 및 시스템
GB2446658B (en) * 2007-02-19 2011-06-08 Advanced Risc Mach Ltd Hibernating a processing apparatus for processing secure data
US8689288B2 (en) 2007-04-16 2014-04-01 Samsung Electronics Co., Ltd. Apparatus and method for protecting system in virtualized environment
KR101405319B1 (ko) * 2007-04-16 2014-06-10 삼성전자 주식회사 가상화 환경에서의 안전한 시스템 보호 장치 및 방법
JP5049185B2 (ja) * 2007-04-19 2012-10-17 パナソニック株式会社 情報セキュリティ装置、セキュリティシステム及び入力情報漏洩防止方法
GB2448907B (en) 2007-05-02 2011-07-27 Advanced Risc Mach Ltd Reducng information leakage between processes sharing a cache
US8051263B2 (en) * 2007-05-04 2011-11-01 Atmel Corporation Configurable memory protection
US9576156B2 (en) 2007-09-04 2017-02-21 Nintendo Co., Ltd. Download security system
US9176897B2 (en) 2007-09-04 2015-11-03 Nintendo Co., Ltd. Writing area security system
FR2925968B1 (fr) * 2007-12-26 2011-06-03 Ingenico Sa Procede de securisation d'un microprocesseur, programme d'ordinateur et dispositif correspondants
US9418220B1 (en) 2008-01-28 2016-08-16 Hewlett Packard Enterprise Development Lp Controlling access to memory using a controller that performs cryptographic functions
GB2460393B (en) * 2008-02-29 2012-03-28 Advanced Risc Mach Ltd A data processing apparatus and method for controlling access to secure memory by virtual machines executing on processing circuitry
US8826037B2 (en) * 2008-03-13 2014-09-02 Cyberlink Corp. Method for decrypting an encrypted instruction and system thereof
US8127131B2 (en) * 2008-04-10 2012-02-28 Telefonaktiebolaget Lm Ericsson (Publ) System and method for efficient security domain translation and data transfer
WO2009153982A1 (ja) * 2008-06-20 2009-12-23 パナソニック株式会社 複数区分型不揮発性記憶装置およびシステム
US8726364B2 (en) * 2008-06-30 2014-05-13 Intel Corporation Authentication and access protection of computer boot modules in run-time environments
DE102008051578A1 (de) 2008-10-14 2010-04-15 Giesecke & Devrient Gmbh Datenkommunikation mit portablem Endgerät
DE102010004446A1 (de) 2010-01-13 2011-07-14 Giesecke & Devrient GmbH, 81677 Verfahren zum Bereitstellen eines sicheren Zählers auf einem Endgerät
JP5485055B2 (ja) * 2010-07-16 2014-05-07 パナソニック株式会社 共有メモリシステム及びその制御方法
US8539245B2 (en) 2010-08-06 2013-09-17 Intel Corporation Apparatus and method for accessing a secure partition in non-volatile storage by a host system enabled after the system exits a first instance of a secure mode
US20120036308A1 (en) * 2010-08-06 2012-02-09 Swanson Robert C Supporting a secure readable memory region for pre-boot and secure mode operations
JP5541036B2 (ja) * 2010-09-21 2014-07-09 富士通株式会社 メモリアクセス制御プログラム、メモリアクセス制御方法、及び情報処理装置
US9087196B2 (en) * 2010-12-24 2015-07-21 Intel Corporation Secure application attestation using dynamic measurement kernels
JP2012216101A (ja) * 2011-04-01 2012-11-08 Sanyo Electric Co Ltd アクセス制御装置
WO2012160760A1 (ja) 2011-05-25 2012-11-29 パナソニック株式会社 情報処理装置および情報処理方法
US9465755B2 (en) 2011-07-18 2016-10-11 Hewlett Packard Enterprise Development Lp Security parameter zeroization
US9361305B2 (en) * 2011-08-09 2016-06-07 Kyocera Document Solutions Inc. Image forming apparatus having a file system
GB2498571A (en) 2012-01-20 2013-07-24 Intellectual Ventures Holding 81 Llc Base station able to communicate with a second device type on a narrow subset frequency band contained within a first main band
KR101897605B1 (ko) * 2012-02-24 2018-09-12 삼성전자 주식회사 휴대 단말기의 무결성 보호 방법 및 장치
US8984205B2 (en) * 2012-03-22 2015-03-17 Raytheon Company Data filter
FR2989801B1 (fr) 2012-04-18 2014-11-21 Schneider Electric Ind Sas Procede de gestion securisee d'un espace memoire pour microcontroleur
CN104471587B (zh) 2012-05-16 2018-01-23 诺基亚技术有限公司 处理器中的方法,装置和计算机程序产品
US9075751B2 (en) * 2012-08-09 2015-07-07 Intel Corporation Secure data protection with improved read-only memory locking during system pre-boot
US8938796B2 (en) 2012-09-20 2015-01-20 Paul Case, SR. Case secure computer architecture
DE112013006590T5 (de) 2013-02-05 2016-01-21 Arm Limited Handhabung von Speicherzugriffsvorgängen in einer Datenverarbeitungsvorrichtung
JP6106765B2 (ja) * 2013-02-05 2017-04-05 エイアールエム リミテッド メモリ保護ユニットを使用して、仮想化をサポートするゲスト・オペレーティング・システム
US10061940B2 (en) 2013-07-09 2018-08-28 Andes Technology Corporation Secure protection processor and method including comparing an instruction security attribute of an instruction and a security attribute of an operational event
JP5911835B2 (ja) 2013-09-17 2016-04-27 株式会社東芝 情報処理装置
JP6117068B2 (ja) 2013-09-20 2017-04-19 株式会社東芝 情報処理装置、およびプログラム
US9436823B1 (en) * 2013-12-17 2016-09-06 Google Inc. System and method for detecting malicious code
US9535856B2 (en) * 2014-02-21 2017-01-03 International Business Machines Corporation Data access to a storage tier on a client in a multi-tiered storage system
US9413765B2 (en) * 2014-03-25 2016-08-09 Intel Corporation Multinode hubs for trusted computing
US9952887B2 (en) * 2014-06-23 2018-04-24 Vmware, Inc. Device simulation in a secure mode supported by hardware architectures
EP3029574B1 (en) * 2014-12-02 2019-09-18 ARM Limited Memory management
US20160170405A1 (en) * 2014-12-10 2016-06-16 General Electric Company Systems and methods for memory map utilization
DE112015005602T5 (de) * 2014-12-15 2017-09-07 International Business Machines Corporation System und Verfahren zum Unterstützen von sicherer Objekten unter Verwendung einer Überwachungseinrichtung zur Speicherzugriffsteuerung
US20160224098A1 (en) * 2015-01-30 2016-08-04 Alexander Gendler Communicating via a mailbox interface of a processor
US10664179B2 (en) * 2015-09-25 2020-05-26 Intel Corporation Processors, methods and systems to allow secure communications between protected container memory and input/output devices
GB2543096A (en) 2015-10-09 2017-04-12 Secure Thingz Ltd Data Processing Device
US10776294B2 (en) * 2015-11-16 2020-09-15 Atmel Corporation System architecture with secure data exchange
US9824419B2 (en) * 2015-11-20 2017-11-21 International Business Machines Corporation Automatically enabling a read-only cache in a language in which two arrays in two different variables may alias each other
DE102015223757A1 (de) * 2015-11-30 2017-06-01 Robert Bosch Gmbh Verfahren zum Betreiben eines Mikrocontrollers
GB2546742B (en) * 2016-01-26 2019-12-11 Advanced Risc Mach Ltd Memory address translation management
FR3047587B1 (fr) 2016-02-10 2023-01-13 Dolphin Integration Sa Dispositif de traitement muni d'un mode d'acces a des donnees sensibles.
KR20170105353A (ko) * 2016-03-09 2017-09-19 삼성전자주식회사 전자장치 및 그 제어방법
US11379385B2 (en) * 2016-04-16 2022-07-05 Vmware, Inc. Techniques for protecting memory pages of a virtual computing instance
DE102016007690A1 (de) 2016-06-23 2017-12-28 Giesecke+Devrient Mobile Security Gmbh Zustandsloses Sicherheitselement
US10671744B2 (en) * 2016-06-23 2020-06-02 Intel Corporation Lightweight trusted execution for internet-of-things devices
US11442760B2 (en) * 2016-07-01 2022-09-13 Intel Corporation Aperture access processors, methods, systems, and instructions
US11032619B2 (en) 2017-01-17 2021-06-08 Samsung Electronics Co., Ltd. Electronic apparatus and control method thereof
US10796004B1 (en) * 2017-06-16 2020-10-06 Sequitur Labs Inc. Split boot for computing devices with secure and insecure states
US20190042781A1 (en) * 2017-08-04 2019-02-07 Bitdefender IPR Management Ltd. Secure Storage Device
JP6776292B2 (ja) * 2018-03-20 2020-10-28 株式会社東芝 情報処理装置、情報処理方法、およびプログラム
GB2579034B (en) * 2018-11-15 2021-05-05 Trustonic Ltd Software installation method
US11283800B2 (en) 2019-03-08 2022-03-22 International Business Machines Corporation Secure interface control secure storage hardware tagging
US11455398B2 (en) * 2019-03-08 2022-09-27 International Business Machines Corporation Testing storage protection hardware in a secure virtual machine environment
US11176054B2 (en) 2019-03-08 2021-11-16 International Business Machines Corporation Host virtual address space for secure interface control storage
US11068310B2 (en) 2019-03-08 2021-07-20 International Business Machines Corporation Secure storage query and donation
EP3786826A1 (en) * 2019-08-30 2021-03-03 Barclays Execution Services Limited Secure validation pipeline in a third party cloud environment
US11734440B2 (en) * 2019-09-09 2023-08-22 Arm Limited Memory access transaction with security check indication
US11880718B2 (en) * 2020-09-15 2024-01-23 Renesas Electronics Corporation System and method for generating secure partition regions in open and secure processor environments
CN115270100A (zh) * 2021-04-29 2022-11-01 华为技术有限公司 一种安全保护方法、装置及系统
US11809332B2 (en) 2021-12-13 2023-11-07 Micron Technology, Inc. Prefetch data associated with TLB fill requests
EP4276633A1 (en) * 2022-05-13 2023-11-15 Thales Dis France SAS Secured semiconductor device and method

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02239349A (ja) * 1989-03-13 1990-09-21 Nec Corp 仮想計算機の例外検出回路
JP2000076087A (ja) * 1998-08-28 2000-03-14 Hitachi Ltd マルチオペレーティングシステム制御方法
JP2001175486A (ja) * 1999-12-21 2001-06-29 Hitachi Ltd 計算機システム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4521852A (en) 1982-06-30 1985-06-04 Texas Instruments Incorporated Data processing device formed on a single semiconductor substrate having secure memory
US4787031A (en) * 1985-01-04 1988-11-22 Digital Equipment Corporation Computer with virtual machine mode and multiple protection rings
US4779187A (en) 1985-04-10 1988-10-18 Microsoft Corporation Method and operating system for executing programs in a multi-mode microprocessor
GB2176918B (en) 1985-06-13 1989-11-01 Intel Corp Memory management for microprocessor system
GB2260004B (en) 1991-09-30 1995-02-08 Apple Computer Memory management unit for a computer system
US5845129A (en) 1996-03-22 1998-12-01 Philips Electronics North America Corporation Protection domains in a single address space
US6282657B1 (en) 1997-09-16 2001-08-28 Safenet, Inc. Kernel mode protection
US6292874B1 (en) 1999-10-19 2001-09-18 Advanced Technology Materials, Inc. Memory management method and apparatus for partitioning homogeneous memory and restricting access of installed applications to predetermined memory ranges
US6986052B1 (en) 2000-06-30 2006-01-10 Intel Corporation Method and apparatus for secure execution using a secure memory partition
US6820177B2 (en) * 2002-06-12 2004-11-16 Intel Corporation Protected configuration space in a protected environment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02239349A (ja) * 1989-03-13 1990-09-21 Nec Corp 仮想計算機の例外検出回路
JP2000076087A (ja) * 1998-08-28 2000-03-14 Hitachi Ltd マルチオペレーティングシステム制御方法
JP2001175486A (ja) * 1999-12-21 2001-06-29 Hitachi Ltd 計算機システム

Also Published As

Publication number Publication date
KR20050085000A (ko) 2005-08-29
WO2004046934A3 (en) 2005-06-16
US7305534B2 (en) 2007-12-04
EP1563388A2 (en) 2005-08-17
GB2411027A (en) 2005-08-17
WO2004046934A2 (en) 2004-06-03
GB0507886D0 (en) 2005-05-25
GB2411027B (en) 2006-03-15
AU2003278350A8 (en) 2004-06-15
JP4302641B2 (ja) 2009-07-29
AU2003278350A1 (en) 2004-06-15
US20040177261A1 (en) 2004-09-09
JP2006506754A (ja) 2006-02-23

Similar Documents

Publication Publication Date Title
KR101015456B1 (ko) 디바이스에 의한 메모리로의 억세스 제어
KR100941104B1 (ko) 데이터 처리 장치, 데이터 처리 방법 및 컴퓨터 프로그램을 기억한 컴퓨터 판독가능한 기억매체
KR101099463B1 (ko) 보안 도메인과 비보안 도메인을 갖는 시스템 내에서 가상메모리 어드레스의 물리적 메모리 어드레스로의 매핑
KR100955284B1 (ko) 보안 모드와 비보안 모드 사이의 프로세서 전환하는 데이터 처리장치, 데이터 처리방법 및 컴퓨터 판독가능한 기록매체
JP4302492B2 (ja) メモリへのアクセスを管理するための装置および方法
JP4302493B2 (ja) データ処理装置内のメモリへアクセスするための技術
JP4299107B2 (ja) サスペンドされたオペレーティングシステムへデータ処理リクエストを送る方法
JP4302494B2 (ja) データ処理装置内のメモリへアクセスするための技術
JP4424973B2 (ja) マルチドメインプロセッサのためのモニタ制御
US7171539B2 (en) Apparatus and method for controlling access to a memory
WO2004046925A1 (en) Security mode switching via an exception vector
GB2395583A (en) Diagnostic data capture control for multi-domain processors
IL167597A (en) Virtual to physical memory address mapping within a system having a secure domain and a non-secure domain
JP2004171568A (ja) 多数のオペレーティングシステムを使用するデータ処理システムにおける多数の割り込みの取り扱い
IL168336A (en) Control of access to a memory by a device
JP4299108B2 (ja) 多数のオペレーティングシステムの間のタスクの追従
TW200422849A (en) Exception types within a secure processing system

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20140121

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20150119

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20160119

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20170119

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20180118

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20190116

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20200115

Year of fee payment: 10