DE102020127800A1 - Ein-chip-system und verfahren zu dessen betrieb - Google Patents

Ein-chip-system und verfahren zu dessen betrieb Download PDF

Info

Publication number
DE102020127800A1
DE102020127800A1 DE102020127800.4A DE102020127800A DE102020127800A1 DE 102020127800 A1 DE102020127800 A1 DE 102020127800A1 DE 102020127800 A DE102020127800 A DE 102020127800A DE 102020127800 A1 DE102020127800 A1 DE 102020127800A1
Authority
DE
Germany
Prior art keywords
firmware
main processor
target firmware
hypervisor
memory
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
DE102020127800.4A
Other languages
English (en)
Inventor
Siheung Kim
Keunyoung PARK
Dongjin PARK
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of DE102020127800A1 publication Critical patent/DE102020127800A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7807—System on chip, i.e. computer system on a single chip; System in package, i.e. computer system on one or more chips in a single package
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G06F12/0638—Combination of memories, e.g. ROM and RAM such as to permit replacement or supplementing of words in one module by words in another module
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7839—Architectures of general purpose stored program computers comprising a single central processing unit with memory
    • G06F15/7864—Architectures of general purpose stored program computers comprising a single central processing unit with memory on more than one IC chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/34—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/35—Indirect addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/152—Virtualized environment, e.g. logically partitioned system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

Ein Ein-Chip-System enthält einen Speicher, einen Hauptprozessor, auf dem ein Betriebssystem läuft, und erste Intellectual Properties (IPs), die entsprechende Verarbeitungsvorgänge durchführen. Der Hauptprozessor arbeitet, um unter Verwendung eines Firmware-Laders Ziel-Firmware in den Speicher zu kopieren, unter Verwendung eines Hypervisors den Zugriff des Hauptprozessors und der ersten IPs auf die Ziel-Firmware vor der Verifikation der Ziel-Firmware zu blockieren und nach der Verifikation der Ziel-Firmware unter Verwendung des Hypervisors den Zugriff auf die Ziel-Firmware durch eine Ziel-IP unter den ersten IPs, die der Ziel-Firmware entspricht, zu gewähren.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNG
  • Diese Anmeldung beansprucht die Priorität der koreanischen Patentanmeldung Nr. 10-2020-0028586 , die am 6. März 2020 beim koreanischen Amt für Geistiges Eigentum eingereicht wurde und deren Offenbarung durch Verweis hierauf in vollem Umfang hierin aufgenommen wurde.
  • HINTERGRUND
  • Bereich
  • Die vorliegende Offenbarung bezieht sich auf ein Ein-Chip-System und insbesondere auf ein Ein-Chip-System zum sicheren Laden von Firmware und ein Verfahren zum Betrieb derselben.
  • Beschreibung des Standes der Technik
  • Mit der Entwicklung der Mobilfunktechnologie und dem Bedarf an verschiedenen Funktionen nehmen die Funktionen zu, die von einem Ein-Chip-System verarbeitet werden müssen und dementsprechend wird, um die Leistung mobiler Vorrichtungen zu verbessern und optimierte Funktionen durchzuführen, neben dem Hauptprozessor auch Intellectual Property (IP), wie z. B. ein digitaler Signalprozessor (DSP) mit verschiedenen Funktionen, entwickelt. Beispielsweise wurden neuere Ein-Chip-Systeme (SoCs) mit einer neuronalen Verarbeitungseinheit (NPU) und einer Tensorverarbeitungseinheit (TPU) ausgestattet, die für parallele Berechnungen im Zusammenhang mit künstlicher Intelligenz optimiert sind und den Hauptprozessor ersetzen könnten, und selbst Kamerafunktionen, die komplexe Berechnungen erfordern, verteilen Berechnungen auf DSPs, um die Verarbeitung zu beschleunigen.
  • Darüber hinaus kann der DSP ähnliche Operationen wie der Hauptprozessor mit einer Vielzahl von Kernen durchführen. Das heißt, der DSP kann Softwarecode in einem Speicher lesen, um eine vorbestimmte Operation durchzuführen, und während er die Operation durchführt, kann er von Zeit zu Zeit auf den Speicher zugreifen, um Algorithmen oder Softwaredaten zu lesen oder um Berechnungsergebnisse zu schreiben.
  • Darüber hinaus werden DSPs zunehmend in einem sicheren Bereich (z. B. einer Bereich einer sicheren Ausführungsumgebung (TEE, TEE=Trusted Execution Environment) zur sicheren Datenverarbeitung eingesetzt. Beispielsweise kann eine Verarbeitungsoperation mit künstlicher Intelligenz, die Gesichtserkennung oder eine andere sichere Verarbeitung erfordert, im DSP anstelle des Hauptprozessors durchgeführt werden. Um den DSP in einem sicheren Bereich zu steuern, müssen die Firmware, Algorithmen und Daten, die den DSP steuern, alle im geschützten Speicher arbeiten, und die Verifikation von Firmware und dergleichen sollte ebenfalls zuerst durchgeführt werden. Während der Verifikationsoperation für die Firmware und dergleichen werden die Daten jedoch in den Speicherbereich kopiert, der dem sicheren Bereich entspricht, und wenn der DSP die Verifikation unter Verwendung der kopierten Daten durchführt, besteht das Problem, dass die Datenbewegung mehrfach erfolgt und sich dementsprechend die Rechenzeit erhöht.
  • ZUSAMMENFASSUNG
  • Ein Aspekt besteht darin, ein Ein-Chip-System zum effizienten Bewegen und Schützen von Daten und ein Verfahren zum Betrieb desselben vorzusehen, wenn eine vorbestimmte IP anstelle des Hauptprozessors im gesicherten Bereich eine vorbestimmte Datenverarbeitungsoperation durchführt oder wenn der Hauptprozessor direkt eine vorbestimmte Datenverarbeitungsoperation durchführt.
  • Nach einem Aspekt einer oder mehrerer exemplarischer Ausführungsformen wird ein Betriebsverfahren eines Ein-Chip-Systems mit einem Hauptprozessor und einer Vielzahl erster Intellectual Properties (IPs) vorgesehen, wobei das Betriebsverfahren das Kopieren der ersten Ziel-Firmware durch den Hauptprozessor unter Verwendung eines Firmware-Laders in einen Speicher; Blockieren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor unter Verwendung eines Hypervisors und der Vielzahl der ersten IPs; Verifizieren der ersten Ziel-Firmware durch den Hauptprozessor unter Verwendung eines Firmware-Verifizierers; und Gewähren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor, der den Hypervisor verwendet, durch eine Ziel-IP aus der Vielzahl der ersten IPs auf der Grundlage des Verifikationsergebnisses umfasst.
  • Nach einem anderen Aspekt einer oder mehrerer exemplarischer Ausführungsformen wird ein Ein-Chip-System (SoC) vorgesehen, das einen Speicher und einen Hauptprozessor umfasst, der für das Ausführen eines Betriebssystems eingerichtet ist; und eine Vielzahl erster Intellectual Properties (IPs), die eingerichtet sind, um eine jeweilige Verarbeitungsoperation durchzuführen, wobei der Hauptprozessor eingerichtet ist, um unter Verwendung eines Firmware-Laders Ziel-Firmware in den Speicher zu kopieren, unter Verwendung eines Hypervisors, den Zugriff des Hauptprozessors und der Vielzahl erster IPs auf die Ziel-Firmware vor dem Verifizieren der Ziel-Firmware zu blockieren und unter Verwendung des Hypervisors den Zugriff auf die Ziel-Firmware durch eine Ziel-IP unter der Vielzahl erster IPs, die der Ziel-Firmware nach dem Verifizieren der Ziel-Firmware entspricht, zu gewähren.
  • Nach einem anderen Aspekt einer oder mehrerer exemplarischer Ausführungsformen wird ein Betriebsverfahren eines Ein-Chip-Systems mit einem Hauptprozessor, einer Vielzahl von Intellectual Properties (IPs) und einem Sicherheitssystem vorgesehen, wobei das Verfahren das Anfordern einer Verwaltung zum Laden von Ziel-Firmware durch einen vom Hauptprozessor ausgeführten Kernel an einen vom Hauptprozessor ausgeführten Hypervisor; Ändern der Zugriffsberechtigung für zumindest eines von dem Hauptprozessor und der Vielzahl von IPs auf einen Speicherbereich, in den die Ziel-Firmware geladen werden soll, durch den Hypervisor; Laden der Ziel-Firmware in den Speicherbereich durch den Kernel; Anfordern einer Verifikation der geladenen Ziel-Firmware durch den Kernel an den Hypervisor; Ändern der Zugriffsberechtigung für zumindest eines von dem Hauptprozessor und der Vielzahl von IPs auf den Speicherbereich durch den Hypervisor; Anfordern der Verifikation der geladenen Ziel-Firmware durch den Hypervisor an das Sicherheitssystem; Durchführen der Verifikation der geladenen Ziel-Firmware durch das Sicherheitssystem; Bereitstellen eines Verifikationsergebnisses der Verifikation durch das Sicherheitssystem an den Hypervisor; Ändern der Zugriffsberechtigung für zumindest eines von dem Hauptprozessor und der Vielzahl von IPs auf den Speicherbereich durch den Hypervisor auf der Grundlage des Verifikationsergebnisses; und Ausführen der geladenen Ziel-Firmware durch den Kernel umfasst.
  • Figurenliste
  • Verschiedene Ausführungsformen werden in der folgenden detaillierten Beschreibung, die in Verbindung mit den beigefügten Zeichnungen erstellt wurde, besser verstanden:
    • 1 ist ein Blockdiagramm, das eine mobile Vorrichtung nach einer beispielhaften Ausführungsform schematisch darstellt;
    • 2 ist ein Blockdiagramm, das eine Software-Architektur für ein Verfahren veranschaulicht, das in einer normalen und einer Sicherheitsumgebung nach einer beispielhaften Ausführungsform funktioniert;
    • 3 ist ein Blockdiagramm, das den Betrieb einer mobilen Vorrichtung nach einer beispielhaften Ausführungsform veranschaulicht;
    • 4A und 4B sind Diagramme zur Erläuterung des Betriebs eines Hypervisors zur Steuerung des Zugriffs eines Hauptprozessors der mobilen Vorrichtung von 3 auf die Ziel-Firmware, nach einer beispielhaften Ausführungsform;
    • 5A und 5B sind Diagramme zur Erläuterung des Betriebs eines Hypervisors zur Steuerung des Zugriffs eines ersten DSPs auf die Ziel-Firmware eines Hauptprozessors der mobilen Vorrichtung aus 3, nach einer beispielhaften Ausführungsform;
    • 6 ist ein Diagramm zur Erläuterung des Betriebs eines Hypervisors, bis die Ziel-Firmware von 3 in den Speicher geladen und verifiziert ist, nach einer beispielhaften Ausführungsform;
    • 7 ist ein Ablaufdiagramm, das ein Verfahren zum Betrieb eines Ein-Chip-Systems nach einer beispielhaften Ausführungsform zeigt;
    • 8 bis 10 sind Ablaufdiagramme, die ein Verfahren zum Betrieb eines Ein-Chip-Systems nach einer beispielhaften Ausführungsform zeigen;
    • 11 ist ein Blockdiagramm, das die Struktur einer Software-Architektur, die in einem Speicher oder einer Speichervorrichtung von 1 gespeichert ist, nach einer beispielhaften Ausführungsform veranschaulicht;
    • 12 ist ein Blockdiagramm, das eine elektronische Vorrichtung mit einem Ein-Chip-System nach einer beispielhaften Ausführungsform darstellt;
    • 13 ist ein Blockdiagramm, das eine elektronische Vorrichtung, die ein Ein-Chip-System nach einer beispielhaften Ausführungsform enthält, veranschaulicht; und
    • 14 ist ein Diagramm, das ein Smart Home veranschaulicht, das durch den Anschluss einer Vielzahl von Internet of Things (IoT)-Vorrichtungen an einen Server nach einer beispielhaften Ausführungsform implementiert wurde.
  • DETAILLIERTE BESCHREIBUNG
  • Im Folgenden werden verschiedene beispielhafte Ausführungsformen bezugnehmend auf die beigefügten Zeichnungen ausführlich beschrieben.
  • 1 ist ein Blockdiagramm, das eine mobile Vorrichtung nach einer beispielhaften Ausführungsform schematisch darstellt. Es versteht sich von selbst, dass die in 1 dargestellte und nachstehend beschriebene Konfiguration und der Betrieb einer mobilen Vorrichtung 100 auf andere elektronische Vorrichtungen angewandt werden kann.
  • Unter Bezugnahme auf 1 kann die mobile Vorrichtung 100 ein Ein-Chip-System (SoC), einen Speicher (z. B. einen Arbeitsspeicher) 130 und eine Speichervorrichtung 170 enthalten. Obwohl in 1 nicht dargestellt, kann die mobile Vorrichtung 100 darüber hinaus eine Flüssigkristallanzeige, ein Berührungsfeld und eine Audiovorrichtung enthalten. Das SoC kann einen Hauptprozessor (z. B. einen Mehrkernprozessor) 110, einen Speicher-Controller 120, eine neuronale Verarbeitungseinheit (NPU) 140, einen digitalen Signalprozessor (DSP) 150, eine Speicherschnittstelle 160, ein Sicherheitssystem 180 und einen Beschleuniger 190 enthalten. In einigen Ausführungsformen kann der Hauptprozessor ein Mehrkernprozessor sein. Nachfolgend können der Hauptprozessor 110, der NPU 140 und der DSP 150 jeweils als Intellectual Property (IP) bezeichnet werden, und obwohl sie nicht im SoC von 1 dargestellt sind, können IPs (z. B. ein Bildsignalprozessor (ISP), eine Tensorverarbeitungseinheit (TPU) und ähnliches), die Datenverarbeitung zur Bereitstellung verschiedener Dienste für einen Benutzer durchführen, ferner einbezogen werden. Wie in dieser Spezifikation verwendet, bezieht sich der Begriff „Intellectual Property“ auf einen Intellectual Property-Core, IP-Core oder IP-Block, der eine wiederverwendbare Einheit eines Logik-, Zellen- oder integrierten Schaltungslayouts (d. h. eines Chips) darstellt, das Intellectual Property einer Partei ist. Verschiedene IP-Cores oder IP-Blöcke werden verwendet, um eine integrierte Halbleitervorrichtung aufzubauen.
  • Der Hauptprozessor 110 kann den Gesamtbetrieb der mobilen Vorrichtung 100 steuern. Zu diesem Zeitpunkt kann der Hauptprozessor 110 eine Operation als eine von einer Normalumgebung (normal world) und einer Sicherheitsumgebung (secure world) durchführen.
  • Die Sicherheitsumgebung kann eine sichere Datenverarbeitungsarchitektur bedeuten, und die Normalumgebung kann eine allgemeine Datenverarbeitungsarchitektur bedeuten, die nicht sicher ist. Als beispielhafte Ausführungsform kann der Hauptprozessor 110 auf der Grundlage der „ARM Trustzone Architektur“ arbeiten. Diese Architektur kann zwei Laufzeitumgebungen enthalten, und eine davon, eine unsichere Laufzeitumgebung (z. B. eine Rich Execution Environment (REE)), kann als Normal Zone oder Normal World bezeichnet werden und kann von einem normalen Betriebssystem gesteuert werden. Eine andere Laufzeitumgebung, eine sichere Laufzeitumgebung (z. B. eine Trusted Execution Environment, TEE)), kann als Trustzone oder Trusted World oder Secure World bezeichnet werden, und die sichere Laufzeitumgebung kann von einem Sicherheitsbetriebssystem gesteuert werden.
  • Das normale Betriebssystem kann z.B. ein typisches Betriebssystem wie Android, Windows Phone, iPhone OS (iOS) und ähnliches sein, und das Sicherheitsbetriebssystem kann ein Betriebssystem sein, bei dem ein Sicherheitskernel, in den Sicherheitsfunktionen integriert sind, in ein bestehendes Betriebssystem eingebettet ist. Gemäß der vorstehend erwähnten ARM-Trustzone können die vorstehend beschriebene unsichere Laufzeitumgebung und die sichere Laufzeitumgebung zusammen als eine virtuelle Ausführungsumgebung definiert werden.
  • Der Hauptprozessor 110 kann Software (z. B. Anwendungsprogramme, Betriebssysteme, Gerätetreiber und dergleichen) ausführen, die auf der mobilen Vorrichtung 100 ausgeführt werden soll. Der Hauptprozessor 110 kann ein Betriebssystem ausführen, das in den Speicher 130 geladen ist. Der Hauptprozessor 110 kann verschiedene Anwendungsprogramme ausführen, die auf der Grundlage des Betriebssystems ausgeführt werden sollen.
  • Nachfolgend wird ein Fall beschrieben, in dem der DSP 150 anstelle des Hauptprozessors 110 auf Basis der Firmware im TEE arbeiten soll. Als beispielhafte Ausführungsform soll die Firmware in der Sicherheitsumgebung ausgeführt werden und kann z. B. ein Programm zum Durchführen von Gesichtserkennung, Fingerabdruckerkennung, Iriserkennung, eine KI-Verarbeitungsoperation, die Sicherheit erfordert, eine mobile Transaktionsoperation und ähnliches enthalten. Darüber hinaus wird es für einen Fachmann klar sein, dass die technischen Prinzipien der vorliegenden Offenbarung auf Fälle angewandt werden können, in denen andere IPs, wie z. B. die NPU 140 und/oder der Beschleuniger 190 außer dem DSP 150 auf der Grundlage der Firmware anstelle des Hauptprozessors 110 ausgeführt werden müssen.
  • Als beispielhafte Ausführungsform kann der Hauptprozessor 110 die in der Speichervorrichtung 170 gespeicherte sichere Speicherverwaltungssoftware (Secure MM S/W) 172 ausführen, ein in der Speichervorrichtung 170 gespeichertes Firmware (FW)-Image 174 in den Speicher 130 kopieren, damit der DSP 150 die in den Speicher 130 im TEE geladene Firmware (d. h. die Kopie des Firmware (FW)-Images 174) stabil ausführen kann, und die Verifikation der Firmware (d. h. die Kopie des in den Speicher 130 geladenen Firmware (FW)-Images 174) unter Verwendung des Sicherheitssystems 180 durchführen. Bei dem in der Speichervorrichtung 170 gespeicherten Firmware-(FW)-Image 174 kann es sich um Firmware verschiedener IPs handeln, wie z. B. des Hauptprozessors 110, des NPU 140, des DSP 150, des Sicherheitssystems 180 und/oder des Beschleunigers 190.
  • Konkret kann der Hauptprozessor 110 das Firmware-Image 174 von der Speichervorrichtung 170 über einen Firmware-Lader im Kernel des Betriebssystems in den Speicher 130 kopieren. Im Folgenden wird die Kopie des Firmware-Images 174, das in den Speicher 130 geladen wurde, als Ziel-Firmware (FW) 134 bezeichnet.
  • Der Hauptprozessor 110 kann den Zugriff auf die Ziel-Firmware 134 unter Verwendung eines Hypervisors steuern.
  • Ein Hypervisor ist eine logische Plattform für die gleichzeitige Ausführung mehrerer Betriebssysteme und kann als Monitor für virtuelle Maschinen oder Manager für virtuelle Maschinen bezeichnet werden. Je nach Typ kann der Hypervisor direkt auf dem Hauptprozessor 110 oder über das Host-Betriebssystem des Hauptprozessors 110 ausgeführt werden. Selbst wenn ein Hackerangriff vor dem Verifizieren der Ziel-Firmware 134 erfolgt, kann der Hypervisor den unsicheren Zugriff auf die Ziel-Firmware 134 von IPs blockieren, um eine Änderung oder Beschädigung der Ziel-Firmware 134 zu verhindern. In einer beispielhaften Ausführungsform kann der Hypervisor die Lese- oder Schreibberechtigung für einen Bereich des Speichers 130, in dem die Ziel-Firmware 134 gespeichert ist, anpassen, um den unsicheren Zugriff auf die Firmware der IPs zu blockieren. Der Kernel und der Hypervisor des Hauptprozessors 110 können in einer REE arbeiten.
  • Der Hauptprozessor 110 kann die Ziel-Firmware 134 unter Verwendung eines Firmware-Verifizierers verifizieren. Der Firmware-Verifizierer kann im TEE arbeiten und die Integrität der Ziel-Firmware 134 verifizieren. In einer beispielhaften Ausführungsform kann der Firmware-Verifizierer das Sicherheitssystem 180 steuern, um die Integrität der Ziel-Firmware 134 zu verifizieren. Das Sicherheitssystem 180 kann eine sichere IP enthalten, die in der Lage ist, Integritätsüberprüfungsoperationen durchzuführen, und die sichere IP kann eine digitale Signatur für die Ziel-Firmware 134 durch Anwendung verschiedener Arten von Verschlüsselungsalgorithmen erzeugen und die digitale Signatur unter Verwendung eines öffentlichen Schlüssels entschlüsseln. Die sichere IP kann die Integrität der Ziel-Firmware 134 verifizieren, indem sie unter Verwendung einer digitalen Signatur und eines öffentlichen Schlüssels prüft, ob die Ziel-Firmware 134 geändert wurde.
  • Wenn die Integritätsverifikation der Ziel-Firmware 134 abgeschlossen ist und die Integrität der Ziel-Firmware 134 die Verifikation bestanden hat, kann der Hauptprozessor 110 dem DSP 150 den Zugriff auf die Ziel-Firmware 134 erlauben, so dass der DSP 150 die Ziel-Firmware 134 im TEE ausführen kann. In einer beispielhaften Ausführungsform kann der Hypervisor die Lese- oder Schreibberechtigung für einen Bereich, in dem die Ziel-Firmware 134 des Speichers 130 gespeichert ist, anpassen, damit der DSP 150 auf die Ziel-Firmware 134 zugreifen kann. Infolgedessen kann der DSP 150 anstelle des Hauptprozessors 110 die Ziel-Firmware 134 ausführen, um Operationen auf der Basis der Ziel-Firmware 134 durchzuführen. In einigen Ausführungsformen kann die Ziel-Firmware 134 die Firmware des Hauptprozessors 110 sein, und der Hypervisor kann den Zugriff des Hauptprozessors 110 auf die Ziel-Firmware 134 steuern, und der Hauptprozessor 110 kann die Ziel-Firmware 134 ausführen, um eine auf der Ziel-Firmware 134 basierende Operation durchzuführen.
  • Der Speicher-Controller 120 kann eine Schnittstelle zwischen dem Speicher 130 und dem SoC vorsehen. Der Speicher-Controller 120 kann als Antwort auf die Anforderung des Hauptprozessors 110 oder einer anderen IP (z. B. NPU 140, DSP 150, Sicherheitssystems 180 und/oder Beschleunigers 190) auf den Speicher 130 zugreifen. Zum Beispiel kann der Speicher-Controller 120 als Antwort auf die Schreibanforderung des Hauptprozessors 110 Daten in den Speicher 130 schreiben, und als Antwort auf die Leseanforderung des Hauptprozessors 110 kann der Speicher-Controller 120 Daten aus dem Speicher 130 lesen und die gelesenen Daten über einen Systemzusammenschalter 192 an den Hauptprozessor 110 oder die Speicherschnittstelle 160 übertragen.
  • Das Betriebssystem oder die Anwendungsprogramme können in den Speicher 130 geladen werden, wenn die mobile Vorrichtung 100 gebootet wird. Verschiedene Ein-/Ausgabeoperationen der mobilen Vorrichtung 100 können vom Betriebssystem unterstützt werden. Außerdem kann eine Vielzahl von Firmware-Stücken (oder Anwendungsprogrammen) in den Speicher 130 geladen werden, um vom Benutzer ausgewählt zu werden oder um grundlegende Dienste bereitzustellen. Zusätzlich zu dieser Verwendung kann der Speicher 130 als Pufferspeicher für die Speicherung von Bilddaten verwendet werden, die von einem Bildsensor wie z. B. einer Kamera zugeführt werden. Der Speicher 130 kann ein flüchtiger Speicher, wie z. B. ein statischer Speicher mit wahlfreiem Zugriff (SRAM), ein dynamischer Speicher mit wahlfreiem Zugriff (DRAM) und dergleichen, oder ein nichtflüchtiger Speicher, wie z. B. ein Phasen-RAM (PRAM), ein magnetischer RAM (MRAM), ein resistiver RAM (ReRAM), ein ferroelektrischer RAM (FRAM), ein Flash-Speicher und dergleichen, sein.
  • Die Speicherschnittstelle 160 kann auf Anforderung des Hauptprozessors 110 oder einer anderen IP (z. B. NPU 140, DSP 150, Sicherheitssystems 180 und Beschleunigers 190) auf die Speichervorrichtung 170 zugreifen. Das heißt, die Speicherschnittstelle 160 kann eine Schnittstelle zwischen dem SoC und der Speichervorrichtung 170 bilden. Beispielsweise können Daten, die vom Hauptprozessor 110 verarbeitet werden, über die Speicherschnittstelle 160 in der Speichervorrichtung 170 gespeichert werden, und die in der Speichervorrichtung 170 gespeicherten Daten können über die Speicherschnittstelle 160 dem Hauptprozessor 110 zugeführt werden.
  • Die Speichervorrichtung 170 kann als Speichermedium der mobilen Vorrichtung 100 vorgesehen werden. Die Speichervorrichtung 170 kann die Sicherheitsspeicherverwaltungssoftware (sichere MM-S/W) 172 und das Firmware (FW)-Image 174 speichern, und darüber hinaus kann die Speichervorrichtung 170 eine Vielzahl von Anwendungsprogrammen, ein Betriebssystem-Image und verschiedene Daten speichern. Die Speichervorrichtung 170 kann als Speicherkarte (z. B. eine Multi-Media-Karte (MMC), eine Embedded MMC (eMMC)-Speicherkarte, eine Secure Digital (SD)-Speicherkarte, eine Micro SD-Speicherkarte und dergleichen) vorgesehen werden. Die Speichervorrichtung 170 kann einen Flash-Speicher mit einer großen Speicherkapazität enthalten. Alternativ kann die Speichervorrichtung 170 einen nichtflüchtigen Speicher der nächsten Generation, wie z. B. PRAM, MRAM, ReRAM und FRAM, enthalten. In einigen Ausführungsformen kann die Speichervorrichtung 170 ein im SoC vorgesehener interner Speicher sein.
  • Die NPU 140, der DSP 150 und der Beschleuniger 190 können den Hauptprozessor 110 unterstützen oder in einigen Fällen die Funktionalität des Hauptprozessors 110 ersetzen, so dass die NPU 140, der DSP 150 und der Beschleuniger 190 als separate IP für die Durchführung von Verarbeitungsoperationen von Sicherheits- oder Multimediadaten vorgesehen werden können. Zum Beispiel kann der Beschleuniger 190 als IP für die Verbesserung der Verarbeitungsleistung von Text, Audio, Standbildern, Animationen, Video, zweidimensionalen Daten oder dreidimensionalen Daten vorgesehen werden.
  • Wenn andere IPs als der Hauptprozessor 110 oder der DSP 150, die Hauptprozessoren des SoCs sind, Firmware im TEE ausführen, kann die mobile Vorrichtung 100 nach einer beispielhaften Ausführungsform unnötigen Datenaustausch zwischen dem TEE-Bereich und dem REE-Bereich im Speicher 130 auslassen, um das Firmware (FW)-Image 174 effizient und sicher in den Speicher 130 zu laden und das Firmware (FW)-Image 174 zu verifizieren.
  • 2 ist ein Blockdiagramm, das eine Software-Architektur für ein Verfahren veranschaulicht, das in einer normalen und einer Sicherheitsumgebung nach einer beispielhaften Ausführungsform funktioniert. Nach einigen beispielhaften Ausführungsformen kann die Softwarearchitektur eine Trustzone-Architektur sein.
  • Unter Bezugnahme auf 2 kann die Trustzone-Architektur zwei Laufzeitumgebungen vorsehen, wie z. B. eine Normalumgebung 210 und eine Sicherheitsumgebung 220. Die Normalumgebung 210 kann einen Normalumgebung-Benutzermodus 212 und einen Normalumgebung-Kernelmodus 214 enthalten, und die Sicherheitsumgebung 220 kann einen Sicherheitsumgebung-Benutzermodus 222, einen Sicherheitsumgebung-Kernelmodus 224 und einen Monitormodus 230 enthalten. Jede von der normalen und Sicherheitsumgebung 210 und 220 kann durch die virtuelle Trennung von Hardwareressourcen, wie z. B. Cache, Translation Lookaside Buffer (TLB), Memory Management Unit (MMU) und Register, verwaltet werden.
  • Wie vorstehend beschrieben, kann, da die Normalumgebung 210 und die Sicherheitsumgebung 220 selektiv betrieben werden können, die Trustzone-Architektur den Monitormodus 230 vorsehen, um Änderungen von der Normalumgebung 210 zur Sicherheitsumgebung 220 und umgekehrt zu verwalten. Nach einigen beispielhaften Ausführungsformen kann die Software im Monitormodus 230 in der Sicherheitsumgebung 220 betrieben werden.
  • Da die Normalumgebung 210 und die Sicherheitsumgebung 220 durch den Monitormodus 230 gesteuert werden, können außerdem verschiedene Anweisungen oder Interrupts, die vom Hauptprozessor 110 (siehe 1) erzeugt werden, über den Monitormodus 230 für jede von der normalen und Sicherheitsumgebung 210 und 220 vorgesehen werden. Zum Beispiel kann der Normalumgebung-Kernelmodus 214 oder der Sicherheitsumgebung-Kernelmodus 224 über einen sicheren Monitor-Aufrufbefehl (SMC) verbunden werden. Das heißt, der Hauptprozessor 110 (siehe 1) kann den gegenwärtig ausgeführten Modus (z. B. den Normalumgebung-Kernelmodus 214 oder den Sicherheitsumgebung-Kernelmodus 224) unter Verwendung des SMC in den Monitormodus 230 ändern. Zusätzlich zur Verwendung des SMC kann jedoch der Hauptprozessor 110 (siehe 1) den gegenwärtig ausgeführten Modus unter Verwendung einer Interrupt-Anforderung (IRQ) oder einer schnellen Interrupt-Anforderung (FIQ) in den Monitormodus 230 ändern. Nach einigen beispielhaften Ausführungsformen kann der IRQ als Interrupt der Normalumgebung 210 und der FIQ als Interrupt der Sicherheitsumgebung 220 verwendet werden.
  • Wie vorstehend beschrieben, kann der Betrieb in der Normalumgebung 210 dem Betrieb in dem REE und der Betrieb in der Sicherheitsumgebung 220 dem Betrieb in dem TEE entsprechen.
  • Der Hauptprozessor 110 (siehe 1) kann nach einer beispielhaften Ausführungsform durch Umschalten vom Normalumgebung-Kernelmodus 214 in den Sicherheitsumgebung-Kernelmodus 224 betrieben werden, und er kann durch Umschalten vom Sicherheitsumgebung-Kernelmodus 224 in den Normalumgebung-Kernelmodus 214 betrieben werden, so dass die Ziel-Firmware 134 (siehe 1) in den Speicher 130 geladen und verifiziert werden kann, um in Zukunft das Ausführen durch den Hauptprozessor 110 zu ermöglichen (siehe 1), oder damit die Ziel-Firmware 134 (siehe 1) in den Speicher 130 geladen und verifiziert werden kann, um in Zukunft das Ausführen durch eine andere IP (z. B, die NPU 140, den DSP 150, das Sicherheitssystem 180 und/oder den Beschleuniger 190 (siehe 1)) zu ermöglichen.
  • 3 ist ein Blockdiagramm, das den Betrieb einer mobilen Vorrichtung nach einer beispielhaften Ausführungsform veranschaulicht.
  • Unter Bezugnahme auf die 3, kann eine mobile Vorrichtung 300 als Hardware HW einen Hauptprozessor 352, eine erste MMU (1. MMU) 354, eine zweite MMU (2. MMU) 356, einen ersten DSP (1. DSP) 362, eine erste System-MMU (SysMMU) 364, eine erste Speicherschutzeinheit (1. MPU) 366, einen zweiten DSP (2. DSP) 382, eine zweite System-MMU (2. SysMMU) 384, eine zweite MPU 386, eine IP 372, eine System-MMU (SysMMU) 374, eine MPU 376 und einen Speicher 390 enthalten. Darüber hinaus sind die beispielhaften Ausführungsformen nicht auf das in 3 dargestellte Beispiel beschränkt, und die Hardware HW kann darüber hinaus Speicherverwaltungseinheiten enthalten, die jeweils mit mehr und verschiedenen IPs verbunden sind.
  • Der Hauptprozessor 352 kann direkt an die erste MMU 354 angeschlossen werden und kann über die erste MMU 354 an die zweite MMU 356 angeschlossen werden, und der Hauptprozessor 352 kann unter Verwendung der ersten MMU 354 und der zweiten MMU 356 stufenweise auf den Speicher 390 zugreifen. Das heißt, die erste MMU 354 kann in einer ersten Stufe und die zweite MMU 356 in einer zweiten Stufe ausgeführt werden. Der erste DSP 362 kann direkt an das erste System MMU 364 und über das erste System MMU 364 an die erste MPU 366 angeschlossen werden, und der erste DSP 362 kann stufenweise unter Verwendung der ersten System-MMU 364 und der ersten MPU 366 auf den Speicher 390 zugreifen. Der zweite DSP 382 kann direkt mit dem zweiten System MMU 384 verbunden werden und kann über das zweite System MMU 384 mit der zweiten MPU 386 verbunden werden, und der zweite DSP 382 kann unter Verwendung des zweiten Systems MMU 384 und der zweiten MPU 386 stufenweise auf den Speicher 390 zugreifen. Die IP 372 kann über das System MMU 374 und die MPU 376 angeschlossen werden, und die IP 372 kann unter Verwendung des Systems MMU 374 und der zweiten MPU 386 stufenweise auf den Speicher 390 zugreifen.
  • Die erste MMU 354 verwaltet eine L2L-Zuordnungstabelle (L2L = Logical To Logical), in der der Hauptprozessor 352 eine erste logische Adresse in eine zweite logische Adresse für den Zugriff auf den Speicher 390 umwandelt, und die zweite MMU 356 kann eine P2P-Zuordnungstabelle (P2P = Physical To Physical) verwalten, die die zweite logische Adresse in eine physische Adresse umwandelt. Die physische Adresse kann der tatsächlichen Adresse des Speichers 390 entsprechen.
  • Die MPUs, d. h. die erste MPU 366, die MPU 376 und die zweite MPU 386, können einige Bereiche des Speichers 390 vor dem unsicheren Zugriff der IPs, d. h. der ersten DSP 362, der IP 372 und der zweiten DSP 382, schützen. Konkret können die MPUs, d. h. die erste MPU 366, die MPU 376 und die zweite MPU 386, einen Bereich des Speichers 390 in eine Vielzahl von Fensterbereichen unterteilen und die Vielzahl von Fensterbereichen vor unsicherem Zugriff der IPs, d. h. des ersten DSP 362, der IP 372 und des zweiten DSP 382, schützen. Die MPUs, d. h. die erste MPU 366, die MPU 376 und die erste MPU 386, können eine Seitentabelle mit (einer) Adressinformation(en) des Speichers 390 und (einer) Attributinformation(en), die den einzelnen Adressinformation(en) entsprechen, verwalten.
  • Darüber hinaus kann man davon ausgehen, dass ein Kernel 310, ein Firmware (FW)-Verifizierer 320 und ein Hypervisor 330 Programme sein können, die vom Hauptprozessor 352 ausgeführt werden.
  • In einer beispielhaften Ausführungsform können der Kernel 310 und der Firmware-Verifizierer 320 auf der ersten Schicht L1, der Hypervisor 330 auf der zweiten Schicht L2 und die vertrauenswürdige Firmware (FW) 340 auf der dritten Schicht L3 arbeiten. Die vertrauenswürdige Firmware 340 entspricht einer Firmware mit bekannter Sicherheit (d. h. die Sicherheit der vertrauenswürdigen Firmware 340 wurde im Voraus bestätigt), so dass die vertrauenswürdige Firmware 340 sicher für die Übertragung und den Empfang von Signalen zwischen dem Hypervisor 330 in der REE und dem Firmware-Verifizierer 320 in der TEE verwendet werden kann. Darüber hinaus kann in einigen beispielhaften Ausführungsformen der Firmware-Verifizierer 320 im TEE auf der zweiten und dritten Schicht L2 und L3 arbeiten und so implementiert werden, dass er in der vertrauenswürdigen Firmware 340 enthalten ist.
  • In einer beispielhaften Ausführungsform kann der Kernel 310 Komponenten steuern, die in einem ersten Steuerbereich CSR1 enthalten sind, und der Hypervisor 330 kann Komponenten steuern, die in einem zweiten Steuerbereich CSR2 enthalten sind. Der Kernel 310 kann nicht auf die Komponenten zugreifen, die im zweiten Steuerbereich CSR2 enthalten sind, und kann daher nicht die Komponenten steuern, die im zweiten Steuerbereich CSR2 enthalten sind. Der erste Steuerbereich CSR1 kann den Hauptprozessor 352, die erste MMU 354, den ersten DSP 362, die erste System-MMU 364, den zweiten DSP 382, die zweite System-MMU 384, die IP 372 und die System-MMU 374 enthalten. Der zweite Steuerbereich CSR2 kann die zweite MMU 356, die erste MPU 366, die zweite MPU 386 und die MPU 376 enthalten.
  • Der Firmware (FW)-Lader 312 des Kernels 310 kann die Ziel-Firmware (FW) 392 in einen Bereich des Speichers 390 kopieren (oder laden). Beispielsweise kann die Ziel-Firmware 392 die Firmware des ersten DSP 362 sein. Nach dem Laden kann der Hypervisor 330 den Zugriff des Hauptprozessors 352, des ersten DSP 362, der IP 372 und des zweiten DSP 382 auf den Speicher 390 blockieren, indem er den zweiten Steuerbereich CSR2 steuert, um ein Hacken der Ziel-Firmware 392 zu verhindern, bevor eine Verifikation der Ziel-Firmware 392 durchgeführt wird. Beispielsweise kann der Hypervisor 330 den Zugriff des Hauptprozessors 352 auf die Ziel-Firmware 392 blockieren, indem er die Adressinformation(en) der Ziel-Firmware 392 in der L2P-Zuordnungstabelle der zweiten MMU 356 ändert. Danach kann die Änderung der Adressinformation(en) die Änderung eines Zugriffsattributs eines vorbestimmten Speicherbereichs, der der Adresse entspricht, oder das Löschen der Adressinformation(en) umfassen. Darüber hinaus kann der Hypervisor 330 den Zugriff des ersten DSP 362 auf die Ziel-Firmware 392 blockieren, indem er die Attributinformation(en) der Adresse, die der Ziel-Firmware 392 entspricht/entsprechen, in der Seitentabelle der ersten MPU 366 ändert. Ein solches Verfahren kann auch auf die IP 372 und den zweiten DSP 382 angewandt werden.
  • Der Hypervisor 330 kann den Firmware Verifizierer 320 auffordern, die Ziel-Firmware 392 durch die vertrauenswürdige Firmware 340 zu verifizieren, und der Firmware Verifizierer 320 kann den zweiten DSP 382 steuern, um die Verifikation der Ziel-Firmware 392 als Antwort auf die Anforderung durchzuführen. Der zweite DSP 382 kann im Voraus eingestellt werden, um die Ziel-Firmware 392 zu verifizieren, und kann dem Sicherheitssystem 180 von 1 entsprechen. Der Hypervisor 330 kann die Seitentabelle der zweiten MPU 386 so ändern, dass der zweite DSP 382 auf die Ziel-Firmware 392 zugreifen kann.
  • Der zweite DSP 382 kann die Integritätsverifikation der Ziel-Firmware 392 durchführen, und nach Abschluss der Integritätsverifikation kann der Firmware-Verifizierer 320 die Ergebnisse der Integritätsverifikation über die vertrauenswürdige Firmware 340 dem Hypervisor 330 zuführen.
  • Wenn das Integritätsverifikationsergebnis für die Ziel-Firmware 392 vorliegt, kann der Hypervisor 330 die Seitentabelle der ersten MPU 366 so ändern, dass der erste DSP 362 auf die Ziel-Firmware 392 in einem TEE zugreifen und die Ziel-Firmware 392 ausführen kann. Mit anderen Worten, der Hypervisor 330 kann den Zugriff aller Komponenten des ersten Steuerbereichs CSR1 während der Verifikation blockieren und nach der Verifikation den Zugriff auf die Komponente des ersten Steuerbereichs CSR1, die der verifizierten Firmware entspricht, selektiv zulassen.
  • Somit steuert der Hypervisor 330 in der mobilen Vorrichtung 300 nach einer beispielhaften Ausführungsform, um eine Umgebung für den ersten DSP 362 zur Ausführung der Ziel-Firmware 392 anstelle des Hauptprozessors 352 im TEE vorzusehen, effektiv nur die Konfiguration des zweiten Steuerbereichs CSR2, um den unsicheren Zugriff effektiv zu blockieren und die Datenbewegung im Speicher 390 zu minimieren.
  • Die in 3 gezeigte Konfiguration ist jedoch nur ein Beispiel, und beispielhafte Ausführungsformen sind nicht darauf beschränkt. Darüber hinaus wurde vorstehend beschrieben, wie der zweite DSP 382 eine Umgebung für das Ausführen der Ziel-Firmware 392 im TEE vorbereitet. Die technischen Grundsätze der vorliegenden Offenbarung können jedoch auf alle Fälle anwendbar sein, in denen mindestens eine andere IP als der Hauptprozessor 352 eine Umgebung für das Ausführen der Ziel-Firmware 392 im TEE vorbereitet.
  • 4A und 4B sind Diagramme zur Erläuterung des Betriebs des Hypervisors 330 zur Steuerung des Zugriffs des Hauptprozessors 352 auf die Ziel-Firmware 392 von 3.
  • Unter Bezugnahme auf 3 und 4A kann die erste MMU 354 die L2L-Zuordnungstabelle L2L_TB verwalten. Die L2L-Zuordnungstabelle L2L_TB kann Informationen über die erste logische Adresse L_ADDa und die dieser zugeordnete zweite logische Adresse L_ADDb enthalten. Wenn z. B. der Hauptprozessor 352 die Adresse ‚L_ADD1a‘ der ersten MMU 354 mit einer Anforderung für eine vorbestimmte Operation zuführt, kann die erste MMU 354 ‚L_ADD1a‘ in ‚L_ADD1b‘ auf der Grundlage der L2L-Zuordnungstabelle L2L_TB umwandeln und die Umwandlungsergebnisadresse der zweiten MMU 356 zuführen.
  • Die zweite MMU 356 kann die L2P-Zuordnungstabelle L2P_TB verwalten. Die L2P-Zuordnungstabelle L2P_TB kann Information(en) über die zweite logische Adresse L_ADDb und die dieser zugeordnete physische Adresse P_ADD enthalten. Die physische Adresse P_ADD kann einer tatsächlichen Adresse des Speichers 390 entsprechen. Beispielsweise kann die zweite MMU 356 die empfangene ‚L_ADD1b‘ in ‚P_ADD1‘ auf der Grundlage der L2P-Zuordnungstabelle L2P_TB umwandeln und mit ‚P_ADD1‘ auf die entsprechende Adresse des Speichers 390 zugreifen.
  • Im Folgenden wird angenommen, dass die physischen Adressen des Speichers 390, in dem die Ziel-Firmware 392 gespeichert ist, ‚P_ADD1‘ und ‚P_ADD2‘ sind. Um einen unsicheren Zugriff des Hauptprozessors 352 auf die Ziel-Firmware 392 zu verhindern, kann der Hypervisor 330 eine Operation durchführen, bei der er in der L2P-Zuordnungstabelle L2P_TB eine physische Adresse P_ADD entsprechend der Ziel-Firmware 392 oder eine zweiten logischen Adresse LADDb, die darauf abgebildet ist, ändert.
  • Unter Bezugnahme auf 4B kann der Hypervisor 330 außerdem ‚P_ADD1‘ und ‚PADD2‘, die die physischen Adressen P_ADD sind, die auf die Ziel-Firmware 392 zeigen, aus der L2P-Zuordnungstabelle L2P_TB löschen. In einigen Ausführungsformen löscht der Hypervisor 330 möglicherweise ‚L_ADD1b‘ und ‚L_ADD2b‘, die ‚P_ADD1‘ und ‚P_ADD2‘ zugeordnet sind, welche physische Adressen P_ADD sind, die auf die Ziel-Firmware 392 zeigen, aus der L2P-Zuordnungstabelle L2P_TB. Weiterhin kann der Hypervisor 330 ‚P_ADD1‘ und ‚P_ADD2‘, die physische Adressen P_ADD sind, die auf die Ziel-Firmware 392 zeigen, und ‚L_ADD1b‘ und ‚L_ADD2b‘, die jeweils ‚P_ADD1‘ und ‚P_ADD2‘ zugeordnet sind, aus der L2P-Zuordnungstabelle L2P_TB löschen.
  • Darüber hinaus kann der Hypervisor 330 die aus der L2P-Zuordnungstabelle L2P_TB gelöschten Adressinformation(en) (z. B. P_ADD1 und/oder L_ADD1b) in einem beliebigen Bereich des Speichers 390 sichern, um den ungesicherten Zugriff des Hauptprozessors 352 zu blockieren, und in Zukunft kann/können die gesicherte(n) Adressinformation(en) aus dem beliebigen Bereich des Speichers 390 in der L2P-Zuordnungstabelle L2P_TB wiederhergestellt werden, damit der Hauptprozessor 352 auf die Adressinformation(en) zugreifen kann.
  • In einigen Ausführungsformen kann die zweite MMU 356 darüber hinaus (eine) Information(en) verwalten, die die Lese- oder Schreibberechtigung für einen Bereich des Speichers 390 angibt/angeben, der der physischen Adresse P_ADD der L2P-Zuordnungstabelle L2P_TB entspricht, und der Hypervisor 330 kann den Zugriff des Hauptprozessors 352 auf den Speicher 390 steuern, indem er die Information(en), die die Lese- oder Schreibberechtigung angibt/angeben, ändert.
  • 5A und 5B sind Diagramme zur Erläuterung des Betriebs des Hypervisors 330 zur Steuerung des Zugriffs des ersten DSP 362 auf die Ziel-Firmware 392 des Hauptprozessors 352 von 3. Im Folgenden wird deutlich, dass das beschriebene technische Prinzip auch für die Zugriffskontrolle des IP 372 und des zweiten DSP 382 auf die Ziel-Firmware 392 des Hauptprozessors 352 anwendbar ist.
  • Unter Bezugnahme auf 3 und 5A, kann das erste System MMU 364 die L2P-Zuordnungstabelle L2P_TB verwalten. Die L2P-Zuordnungstabelle L2P_TB kann (eine) Information(en) über die logische Adresse L_ADD und die darauf abgebildete physische Adresse P ADD enthalten. Wenn z. B. der erste DSP 362 die Adresse ‚L_ADD1‘ der ersten System-MMU 364 mit einer Anforderung für eine vorbestimmte Operation zuführt, kann die erste System-MMU 364 ‚L_ADD1‘ auf der Grundlage der L2P-Zuordnungstabelle L2P_TB in ‚P_ADD1‘ umwandeln und die Adresse des Umwandlungsergebnisses der ersten MPU 366 zuführen.
  • Die erste MPU 366 kann die Seitentabelle P_TB verwalten. Die Seitentabelle P_TB kann eine physische Adresse P_ADD des Speichers 390 und (eine) Property-Information(en) PI über die Adresse enthalten. In einer beispielhaften Ausführungsform kann/können die Property-Information(en) PI ein Leseberechtigungskennzeichen RPF und ein Schreibberechtigungskennzeichen WF enthalten. Beispielsweise kann/können das Leseberechtigungskennzeichen RPF (eine) Information(en) sein, die angibt/angeben, ob Daten, die in der entsprechenden physischen Adresse P_ADD gespeichert sind, gelesen werden dürfen, und das Schreibberechtigungskennzeichen WPF kann/können (eine) Information(en) sein, die angibt, ob Daten in die entsprechende physische Adresse P_ADD geschrieben werden dürfen.
  • Um einen unsicheren Zugriff des ersten DSP 362 auf die Ziel-Firmware 392 zu verhindern, kann der Hypervisor 330 die Property-Information(en) PI ändern, die der physischen Adresse P_ADD des Speichers 390 entspricht/entsprechen, in dem die Ziel-Firmware 392 gespeichert ist. Zum Beispiel können, wie vorstehend in 4A beschrieben, die physischen Adressen des Speichers 390, in dem die Ziel-Firmware 392 gespeichert ist, ‚P_ADD1‘ und ‚P_ADD2‘ sein, und somit kann der Hypervisor 330 mindestens eine von ‚F1a‘, ‚F1b‘, ‚F2a‘ und ‚F2b‘ entsprechend ‚P_ADD1‘ und ‚P_ADD2‘ ändern, um den Zugriff der Ziel-Firmware 392 durch den ersten DSP 362 zu steuern.
  • Unter Bezugnahme auf 5B kann die Seitentabelle P_TB im Vergleich zu 5A zusätzlich einen sicheren Merker SF enthalten, der der physischen Adresse P_ADD des Speichers 390 entspricht. Das Sicherheitskennzeichen SF kann/können (eine) Information(en) sein, die angibt/angeben, ob ein unsicherer Zugriff oder ein sicherer Zugriff auf die entsprechende physische Adresse P_ADD möglich ist. Der Hypervisor 330 kann den unsicheren Zugriff und den sicheren Zugriff durch den ersten DSP 362 steuern, indem er das Sicherheitskennzeichen SF ändert. Beispielsweise kann der Hypervisor 330 mindestens eines von ‚F1a‘, ‚F1b‘, ‚F1c‘ entsprechend ‚P_ADD1‘ und mindestens eines von ‚F2a‘, ‚F2b‘ und ‚F2c‘ entsprechend ‚P_ADD2‘ ändern, um den Zugriff der Ziel-Firmware 392 durch den ersten DSP 362 zu steuern.
  • 6 ist ein Diagramm zur Erläuterung des Betriebs des Hypervisors 330, bis die Ziel-Firmware 392 von 3 in den Speicher 390 geladen und verifiziert ist.
  • Unter Bezugnahme auf 3 und 6, in (a) von 6, kann der Speicherbereich MA_FW, in dem die Ziel-Firmware 392 des Speichers 390 gespeichert ist, mit „Nur Lesen“-Berechtigung so eingestellt werden, dass die Ziel-Firmware 392 nur vom Hauptprozessor 352, dem ersten DSP 362, der IP 372 und dem zweiten DSP 382 gelesen werden kann. In (b) von 6 kann der Hypervisor 330 dem Hauptprozessor 352 die Erlaubnis geben, in den Speicherbereich MA_FW zu schreiben, damit der Firmware-Lader 312 die Ziel-Firmware 392 in den Speicherbereich MA_FW laden kann. Dann, in (c) von 6, kann der Hypervisor 330, bevor die Verifikationsoperation für die Ziel-Firmware 392 durchgeführt wird, dem Hauptprozessor 352 die „Nur Lesen“-Berechtigung für den Speicherbereich MA_FW erteilen. Obwohl in der Zeichnung nicht dargestellt, kann der Hypervisor 330 dem zweiten DSP 382 fernerhin eine Schreibberechtigung für den Speicherbereich MA_FW erteilen, so dass der zweite DSP 382 eine Verifikationsoperation für die Ziel-Firmware 392 durchführen kann. Wenn die Verifikation der Ziel-Firmware 392 abgeschlossen ist, kann der Hypervisor 330 in (d) von 6 dem ersten DSP 362 ferner die „Code ausführbar“-Berechtigung für den Bereich, in dem der Code der Ziel-Firmware 392 gespeichert ist, und die „mit Daten beschreibbar“-Berechtigung für den Bereich, in dem die Daten der Ziel-Firmware 392 gespeichert sind, erteilen. Durch dieses Verfahren kann der erste DSP 362 die Ziel-Firmware 392 ausführen und Daten der Ziel-Firmware 392 in den Speicher 390 schreiben.
  • Die in 6 dargestellte inhaltliche Beschreibung ist jedoch nur eine beispielhafte Ausführungsform, und beispielhafte Ausführungsformen sind nicht darauf beschränkt. Um ein Hacken der Ziel-Firmware 392 zu verhindern, steuert der Hypervisor 330 dynamisch den zweiten Steuerbereich CSR2, so dass verschiedene Ausführungsformen angewandt werden können, um den Hauptprozessor 352, den ersten DSP 362, die IP 372 und den zweiten DSP 382 zu blockieren oder den Zugriff auf die Ziel-Firmware 392 zu gewähren.
  • 7 ist ein Ablaufdiagramm, das ein Verfahren zum Betrieb eines SoCs nach einer beispielhaften Ausführungsform zeigt.
  • Unter Bezugnahme auf 7 kann das SoC, in der Operation S100, die Ziel-Firmware in den Speicher kopieren. Beispielsweise kann das SoC die Ziel-Firmware über den Firmware-Hochlader des Kernels in den Speicher kopieren (oder laden). Die Ziel-Firmware dient zur Handhabung sicherheitsbezogener Operationen, die vor Hacken geschützt werden müssen und auf einem Hauptprozessor oder einem anderen DSP (oder IP) als dem Hauptprozessor ausgeführt werden können. In der Operation S110 kann das SoC die Verifikation der Ziel-Firmware anfordern. Beispielsweise kann das SoC den Firmware-Verifizierer auffordern, die Ziel-Firmware über den Hypervisor zu verifizieren. In der Operation S120 kann das SoC die Zugriffsberechtigung auf die Ziel-Firmware steuern. Um beispielsweise ein Hacken der Ziel-Firmware zu verhindern, kann das SoC vor Beginn der Verifikation der Ziel-Firmware die Zugriffsberechtigung von anderen Komponenten (z. B. einem Hauptprozessor, einem anderen DSP und dergleichen) als dem sicheren DSP (oder der sicheren IP) auf die Ziel-Firmware, die Gegenstand der Verifikation ist, durch den Hypervisor einschränken. In der Operation S130 kann das SoC die Ziel-Firmware unter Verwendung eines sicheren DSPs verifizieren. Zum Beispiel kann das SoC die Ziel-Firmware unter Verwendung eines Sicherheits-DSPs durch einen Firmware-Verifizierer verifizieren. In einigen Ausführungsformen kann das SoC die Ziel-Firmware unter Verwendung des Hauptprozessors im TEE anstelle des Sicherheits-DSP verifizieren, und in einigen Ausführungsformen kann das SoC, wenn der Hauptprozessor TEEbezogenen Code ausführt, die Ziel-Firmware unter Verwendung eines Hypervisors verifizieren. In der Operation S140 kann das SoC die Zugriffsberechtigung auf die Ziel-Firmware auf der Grundlage des Verifikationsergebnisses steuern. Beispielsweise kann das SoC auf der Grundlage des Verifikationsergebnisses dem Subjekt, das die Ziel-Firmware über den Hypervisor ausführt, die Zugriffsberechtigung auf die Ziel-Firmware gewähren. Wenn es sich bei dem Subjekt, das die Ziel-Firmware ausführt, beispielsweise um einen DSP handelt, kann das SoC beispielsweise einen Zugriff auf den DSP gewähren, um dem DSP das Ausführen der Ziel-Firmware durch den Hypervisor zu ermöglichen. In der Operation S150 kann das SoC die Ziel-Firmware ausführen. Beispielsweise kann das SoC die Ziel-Firmware über den DSP ausführen.
  • 8 ist ein Ablaufdiagramm, das ein Verfahren zum Betrieb eines SoCs nach einer beispielhaften Ausführungsform zeigt.
  • Unter Bezugnahme auf 8 kann das SoC, wenn das Ausführen einer neuen Ziel-Firmware erforderlich ist, in der Operation S200 die neue Ziel-Firmware in einen Speicher kopieren (oder laden). Wenn zum Beispiel das Ausführen einer neuen Ziel-Firmware erforderlich ist, kann das SoC die neue Ziel-Firmware über den Firmware-Hochlader des Kernels in einen Speicher kopieren (oder laden). Die neue Ziel-Firmware kann in einen anderen Bereich des Speichers kopiert werden als die in 7 beschriebene Ziel-Firmware. Die neue Ziel-Firmware dient zur Handhabung sicherheitsbezogener Operationen, die vor Hacken geschützt werden müssen und kann auf einem Hauptprozessor oder einem anderen DSP (oder einer IP) als dem Hauptprozessor ausgeführt werden. In der Operation S210 kann das SoC die Verifikation der neuen Ziel-Firmware anfordern. Beispielsweise kann das SoC den Firmware-Verifizierer auffordern, die neue Ziel-Firmware über den Hypervisor zu verifizieren. In der Operation S220 kann das SoC die Zugriffsberechtigung auf die neue Ziel-Firmware steuern. Um beispielsweise ein Hacken der neuen Ziel-Firmware zu verhindern, kann das SoC vor Beginn der Verifikation der neuen Ziel-Firmware die Zugriffsberechtigung von anderen Komponenten (z. B. einem Hauptprozessor, einem anderen DSP und dergleichen) als dem sicheren DSP (oder der sicheren IP) auf die Ziel-Firmware, die Gegenstand der Verifikation ist, durch den Hypervisor einschränken. In der Operation S230 kann das SoC die neue Ziel-Firmware unter Verwendung eines sicheren DSPs verifizieren. Zum Beispiel kann das SoC die neue Ziel-Firmware unter Verwendung eines Sicherheits-DSP durch einen Firmware-Verifizierer verifizieren. In der Operation S240 kann das SoC die Zugriffsberechtigung auf die neue Ziel-Firmware auf der Grundlage des Verifikationsergebnisses steuern. Auf der Grundlage des Verifikationsergebnisses kann das SoC beispielsweise dem Subjekt, das die neue Ziel-Firmware über den Hypervisor ausführt, die Zugriffsberechtigung auf die Ziel-Firmware gewähren. In verschiedenen Ausführungsformen können das Subjekt, das die Ziel-Firmware von 7 ausführt, und das Subjekt, das die neue Ziel-Firmware ausführt, identisch oder voneinander verschieden sein. In der Operation S250 kann das SoC die neue Ziel-Firmware ausführen und die vorherige Ziel-Firmware verwalten. Beispielsweise kann das SoC die neue Ziel-Firmware über den DSP ausführen und den Zugriff des Hauptprozessors auf die Ziel-Firmware über den Hypervisor verwalten, damit der Firmware-Hochlader bei Bedarf auf die frühere Ziel-Firmware zugreifen kann.
  • 9 ist ein Ablaufdiagramm, das ein Verfahren zum Betrieb eines SoCs nach einer beispielhaften Ausführungsform zeigt.
  • Bezugnehmend auf 9 kann das SoC in der Operation S300, wenn der Betrieb der Ziel-Firmware abgeschlossen ist und die Ziel-Firmware nicht mehr ausgeführt werden soll, die Freigabe der Ziel-Firmware anfordern. Zum Beispiel kann der DSP des SoC den Hypervisor auffordern, die Ziel-Firmware freizugeben. In der Operation S310 kann das SoC die Zugriffsberechtigung auf die Ziel-Firmware steuern. Beispielsweise kann das SoC dem Hauptprozessor über den Hypervisor die Zugriffsberechtigung auf die Ziel-Firmware erteilen. In der Operation S320 kann das SoC die Zugriffsberechtigung des DSP steuern. Beispielsweise kann das SoC die Seitentabelle der MPU, die dem DSP entspricht, über einen Hypervisor ändern, um die Zugriffsberechtigung des DSP auf die Ziel-Firmware zu blockieren. In der Operation S330 kann das SoC die Ziel-Firmware freigeben. Beispielsweise kann das SoC die Ziel-Firmware vom DSP freigeben.
  • 10 ist ein Ablaufdiagramm eines Verfahrens zum Betrieb eines SoC nach einer beispielhaften Ausführungsform. Danach enthält das SoC einen Hauptprozessor, eine Vielzahl von IPs und ein Sicherheitssystem, und der Kernel und der Hypervisor können vom Hauptprozessor gesteuert werden.
  • Unter Bezugnahme auf 10 kann der Kernel in der Operation S400 den Hypervisor für die Verwaltung zum Laden der Firmware anfordern. In der Operation S402 kann der Hypervisor die Zugriffsberechtigung auf den Firmware-Speicherbereich des Speichers ändern, so dass der Kernel die in der vorbestimmten Speichervorrichtung gespeicherte Firmware in den Speicher laden kann. Insbesondere kann der Hypervisor die L2P-Zuordnungstabelle oder (eine) vorbestimmte Information(en) der zweiten MMU 356 aus 3 ändern, damit der Kernel auf den Firmware-Speicherbereich zugreifen und die Firmware in den Firmware-Speicherbereich kopieren kann. In der Operation S404 kann der Hypervisor den Kernel darüber benachrichtigen, dass die Änderung der Zugriffsberechtigung auf den Firmware-Speicherbereich abgeschlossen ist. In der Operation S406 kann der Kernel die Firmware in den Speicher laden. In der Operation S408 kann der Kernel den Hypervisor auffordern, die geladene Firmware zu verifizieren. In der Operation S410 kann der Hypervisor die Zugriffsberechtigung auf den Firmware-Speicherbereich ändern, bevor er mit dem Verifizieren der Firmware beginnt. Insbesondere kann der Hypervisor dem Sicherheitssystem, das die Firmware-Verifikation durchführt, die Erlaubnis zum Zugriff auf den Firmware-Speicherbereich erteilen und den Zugriff auf den Firmware-Speicherbereich durch den Hauptprozessor und die Vielzahl von IPs blockieren. In der Operation S412 kann der Hypervisor die Verifikation der Firmware durch das Sicherheitssystem anfordern. In der Operation S414 kann das Sicherheitssystem als Reaktion auf die Anforderung des Hypervisors eine Verifikation der geladenen Firmware durchführen. Beispielsweise kann das Sicherheitssystem eine Signatur-Verifikationsoperation an der geladenen Firmware auf der Grundlage verschiedener Verfahren und Algorithmen durchführen. In der Operation S416 kann das Sicherheitssystem dem Hypervisor das Verifikationsergebnis der Firmware zuführen. In der Operation S418 kann der Hypervisor die Zugriffsberechtigung auf den Speicherbereich der Firmware auf der Grundlage des Verifikationsergebnisses ändern. Insbesondere kann der Hypervisor einer Vielzahl von IPs oder einem Hauptprozessor, der zur Ausführung der Firmware ausgewählt wurde, die Zugriffsberechtigung auf den Firmware-Speicherbereich erteilen. Wenn beispielsweise der Hauptprozessor für das Ausführen der Firmware ausgewählt wird, kann die Zugriffsberechtigung auf den Firmware-Speicherbereich für eine Vielzahl von IPs und ein Sicherheitssystem blockiert sein. In der Operation S404 kann der Hypervisor den Kernel darüber benachrichtigen, dass die Änderung der Zugriffsberechtigung auf den Firmware-Speicherbereich abgeschlossen ist. In der Operation S422 kann der Kernel auf den Firmware-Speicherbereich zugreifen und die Firmware ausführen.
  • 11 ist ein Blockdiagramm, das eine im Speicher 130 und/oder der Speichervorrichtung 170 von 1 gespeicherte Software-Architekturstruktur nach einer beispielhaften Ausführungsform veranschaulicht.
  • Unter Bezugnahme auf 11 kann der Speicher 130 (siehe 1) oder die Speichervorrichtung 170 (siehe 1) ein Betriebssystem (OS) 1010, einen Kernel 1020, eine Middleware 1030 und Anwendungen 1040 enthalten.
  • Das Betriebssystem 1010 steuert und verwaltet den Gesamtbetrieb der Hardware. Das Betriebssystem 1010 ist eine Schicht, die für grundlegende Funktionen wie Hardwareverwaltung, Speicher und Sicherheit verantwortlich ist.
  • Der Kernel 1020 kann als Pfad für die Übertragung verschiedener Signale dienen, einschließlich eines Berührungssignals, das über eine Eingabevorrichtung an die Middleware 1030 eingegeben wird.
  • Die Middleware 1030 kann verschiedene Softwaremodule enthalten, die den Betrieb der mobilen oder elektronischen Vorrichtung steuern. Die Middleware 1030 kann ein Sicherheitsmodul 1031, ein Haupt-Framework 1033, ein Sub-Framework 1034, einen Window-Manager 1035, einen System-Manager 1036, ein Multimedia-Framework 1037, einen APP-Manager 1038 und einen Verbindungsmanager 1039 enthalten.
  • Das Sicherheitsmodul 1031 ist ein Modul, das Hardware-Zertifizierung, sichere Speicherung und ähnliches unterstützt und ein Firmware-Lademodul 1032 nach verschiedenen Beispielausführungsformen der vorliegenden Offenbarung enthalten kann. Das Firmware-Lademodul 1032 kann der sicheren Speicherverwaltungssoftware 130 von 1 entsprechen. Ein Hypervisor nach den Beispielausführungsformen der vorliegenden Offenbarung kann auf der Grundlage des Firmware-Lademoduls 1032 arbeiten. Das heißt, in einer Reihe von Operationen des Ladens der Firmware in einen vorbestimmten Speicher durch den Firmware-Lader des Kernels 1020, der Durchführung der Verifikation für die Firmware und der Ausführung der Firmware kann der Hypervisor schnell und einfach die Zugriffsberechtigung auf die Firmware der IP ändern, die Gegenstand jeder Operation ist. Zum Beispiel ist es bei der Steuerung des Zugriffs auf die Firmware des Hauptprozessors möglich, die Information(en) der mit dem Hauptprozessor verbundenen MMU zu ändern, und bei der Steuerung der Zugriffsberechtigung der vorgegebenen IP-Firmware ist es möglich, die Information(en) der mit der IP verbundenen MPU zu ändern.
  • Das Haupt-Framework 1033 ist ein Modul zur Bereitstellung verschiedener Benutzerschnittstellen, die auf einer Hauptfläche der Anzeige angezeigt werden. Das Sub-Framework 1034 ist ein Modul zur Bereitstellung verschiedener Benutzerschnittstellen, die in einem Sub-Bereich der Anzeige angezeigt werden sollen.
  • Der Window-Manager 1035 kann ein Berührungsereignis oder ein anderes Eingabeereignis mit dem Körper des Benutzers oder Stift erfassen. Wenn ein solches Ereignis erfasst wird, sendet der Window-Manager 1035 ein Ereignissignal an das Haupt-Framework 1033 oder das Sub-Framework 1034, um eine dem Ereignis entsprechende Operation durchzuführen.
  • Der Systemmanager 1036 überwacht den Zustand jeder Komponente in der mobilen Vorrichtung oder in der elektronischen Vorrichtung und führt das Überwachungsergebnis anderen Modulen zu. Wenn z. B. der Batteriestand niedrig ist, ein Fehler auftritt, der Status der Kommunikationsverbindung verloren geht und ähnliches, kann der Systemmanager 1036 das Überwachungsergebnis dem Haupt-Framework 1033 oder dem Sub-Framework 1034 zuführen, um eine Benachrichtigung oder einen Benachrichtigungston auszugeben.
  • Das Multimedia-Framework 1037 ist ein Modul zur Wiedergabe von Multimedia-Inhalten, die in einer mobilen oder elektronischen Vorrichtung gespeichert sind oder von einer externen Quelle zugeführt werden. Der APP-Manager 1038 ist ein Modul, das die Ausführungszustände von verschiedenen im Speicher installierten Anwendungen 1040 verwaltet. Der Verbindungsmanager 1039 ist ein Modul zur Unterstützung von drahtgebundenen oder Drahtlos- Netzwerkverbindungen.
  • Die in 11 dargestellte Struktur ist jedoch nur ein Beispiel, und beispielhafte Ausführungsformen sind nicht darauf beschränkt. Dementsprechend ist es klar, dass je nach Art oder Zweck der mobilen oder elektronischen Vorrichtung einige Komponenten weggelassen, modifiziert oder hinzugefügt werden können.
  • 12 ist ein Blockdiagramm, das eine elektronische Vorrichtung 1100 einschließlich eines SoC 1150 nach einer beispielhaften Ausführungsform darstellt. Danach kann die elektronische Vorrichtung 1100 als eine Drahtlos-Kommunikationsvorrichtung, wie z. B. ein Mobiltelefon, ein Smartphone und ein Tablet-PC, implementiert werden.
  • Unter Bezugnahme auf 12 kann die elektronische Vorrichtung 1100 einen Funk-Sender-Empfänger 1120, eine Eingabevorrichtung 1130, eine Anzeigevorrichtung 1140, ein SoC 1150 und eine Speichervorrichtung 1160 enthalten.
  • Der Funk-Sender-Empfänger 1120 kann ein Drahtlos-Signal über eine Antenne 1122 senden und empfangen und kann das Drahtlos-Signal in ein Signal ändern, das vom SoC 1150 verarbeitet werden kann.
  • Das SoC 1150 verarbeitet ein vom Funk-Sender-Empfänger 1120 ausgegebenes Signal und kann das verarbeitete Signal an die Speichervorrichtung 1160 oder die Anzeigevorrichtung 1140 übertragen. Darüber hinaus kann das SoC 1150 ein Firmware-Lademodul 1152 nach verschiedenen beispielhaften Ausführungsformen enthalten und auf der Grundlage des Firmware-Lademoduls 1152 arbeiten, so dass ein effizientes und sicheres Laden der Firmware in die Speichervorrichtung 1160, die Firmware-Verifikation und die Firmware-Ausführung durchgeführt werden können.
  • Die Eingabevorrichtung 1130 ist eine Vorrichtung, die ein Steuersignal zur Steuerung des Betriebs des SoC 1150 oder der vom SoC 1150 zu verarbeitenden Daten eingeben kann und das mit einer Zeigevorrichtung, wie z. B. einem Berührungsfeld und einer Computermaus, einem Tastenfeld oder einer Tastatur, implementiert werden kann.
  • Das SoC 1150 kann den Betrieb der Anzeigevorrichtung 1140 so steuern, dass Daten, die von der Speichervorrichtung 1160 ausgegeben werden, auf der Anzeigevorrichtung 1140 angezeigt werden können.
  • 13 ist ein Blockdiagramm, das eine elektronische Vorrichtung 1200 einschließlich eines SoC 1220 nach einer beispielhaften Ausführungsform zeigt. Danach kann die elektronische Vorrichtung 1200 als Bildverarbeitungsvorrichtung, z. B. als Digitalkamera, als Mobiltelefon mit Digitalkamera, als Smartphone mit Digitalkamera oder als Tablet-PC mit Digitalkamera, implementiert werden.
  • Unter Bezugnahme auf 13 kann die elektronische Vorrichtung 1200 einen Bildsensor 1210, ein SoC 1220, eine Speichervorrichtung 1230 und eine Anzeigevorrichtung 1240 enthalten.
  • Der Bildsensor 1210 kann das optische Bild in ein digitales Bild umwandeln, und das Umwandlungsergebnis kann an das SoC 1220 oder die Speichervorrichtung 1230 übertragen werden. Das aus der Umwandlung unter der Steuerung des SoC 1220 resultierende digitale Bild kann auf der Anzeigevorrichtung 1240 angezeigt oder in der Speichervorrichtung 1230 gespeichert werden. In der Speichervorrichtung 1230 gespeicherte Daten können unter der Steuerung des SoC 1220 auf der Anzeigevorrichtung 1240 angezeigt werden.
  • Das SoC 1220 kann ein Firmware-Lademodul 1152 nach verschiedenen beispielhaften Ausführungsformen enthalten und kann auf der Grundlage des Firmware-Lademoduls 1222 arbeiten, so dass ein effizientes und sicheres Laden der Firmware in die Speichervorrichtung 1230, die Verifikation der Firmware und das Ausführen der Firmware durchgeführt werden kann.
  • 14 ist ein Diagramm, das ein Smart Home 2000 veranschaulicht, das durch den Anschluss einer Vielzahl von Internet of Things (IoT)-Vorrichtungen an einen Server nach einer beispielhaften Ausführungsform implementiert wurde.
  • Unter Bezugnahme auf 14 kann das Smart Home 2000 eine Vielzahl von IoT-Vorrichtungen 2010, einen Hub 2020, einen Server 2030 und eine elektronische Vorrichtung 2040 enthalten.
  • Die Vielzahl der IoT-Vorrichtungen 2010 kann einen Fernseher 2011, einen Kühlschrank 2012, einen Tablet-PC 2013, einen Laptop 2014 und/oder eine Klimaanlage 2015 enthalten. Dies ist jedoch eine beispielhafte Ausführungsform, und die Vielzahl der IoT-Vorrichtungen 2010 ist nicht auf die in 14 dargestellten beschränkt.
  • Die Vielzahl der IoT-Vorrichtungen 2010 kann über den Hub 2020 an den Server 2030 angeschlossen werden. Eine Vielzahl von Vorrichtungs-Identifikationsinformationen über jede der Vielzahl von IoT-Vorrichtungen 2010 kann über die elektronische Vorrichtung 2040 an den Server 2030 übertragen werden. Jede der Vielzahl von IoT-Vorrichtungen 2010 kann mit dem Hub 2020 gepaart und an diesen angeschlossen werden, der der/den im Server 2030 registrierten Hub-Identifikationsinformation(en) entspricht. Die Vielzahl der IoT-Vorrichtungen 2010 kann mit dem Server 2030 über eine Verbindung mit dem Hub 2020 kommunizieren.
  • Der Hub 2020 kann eine Verbindung zwischen der Vielzahl von IoT-Vorrichtungen 2010 und dem Server 2030 weiterleiten. Nach verschiedenen Ausführungsformen kann der Hub 2020 die Funktion eines Routers, einer Bridge oder eines Access Points (AP) übernehmen. Der Server 2030 kann einen Prozessor und eine Drahtlos-Kommunikationsschaltung enthalten. Der Prozessor kann den Gesamtbetrieb des Servers 2030 steuern. Der Server 2030 kann unter Verwendung der Drahtlos-Kommunikationsschaltung mit dem Hub 2020 kommunizieren oder über den Hub 2020 mit der Vielzahl von IoT-Vorrichtungen 2010 kommunizieren.
  • Die elektronische Vorrichtung 2040 kann einen Prozessor und eine Drahtlos-Kommunikationsschaltung enthalten. Der Prozessor kann den Gesamtbetrieb der elektronischen Vorrichtung 2040 steuern. Die elektronische Vorrichtung 2040 kann über die Drahtlos-Kommunikationsschaltung mit dem Server 2030 kommunizieren. Nach verschiedenen Ausführungsformen kann die elektronische Vorrichtung 2040 ferner eine Anzeige, eine Kamera oder ein Ein-/Ausgabemodul enthalten.
  • Wenn die Kommunikation mit der Vielzahl von IoT-Vorrichtungen 2010 beginnt, kann die elektronische Vorrichtung 2040 Firmware ausführen, die sich auf Sicherheit oder Authentifizierung bezieht, und zu diesem Zeitpunkt kann die elektronische Vorrichtung 2040 auf der Grundlage eines Firmware-Lademoduls nach verschiedenen beispielhaften Ausführungsformen arbeiten. Zum Beispiel kann die elektronische Vorrichtung 2040 die elektronische Vorrichtung 1100 von 12 oder die elektronische Vorrichtung 1200 von 13 sein.
  • Während verschiedene beispielhafte Ausführungsformen vorstehend besonders gezeigt und beschrieben wurden, wird davon ausgegangen, dass darin verschiedene Änderungen in Form und Details vorgenommen werden können, ohne vom Geist und Umfang der folgenden Ansprüche abzuweichen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • KR 1020200028586 [0001]

Claims (20)

  1. Betriebsverfahren eines Ein-Chip-Systems mit einem Hauptprozessor und einer Vielzahl von ersten Intellectual Properties (IPs), wobei das Verfahren umfasst: Kopieren der ersten Ziel-Firmware durch den Hauptprozessor unter Verwendung eines Firmware-Laders in einen Speicher; Blockieren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor unter Verwendung eines Hypervisors und der Vielzahl der ersten IPs; Verifizieren der ersten Ziel-Firmware durch den Hauptprozessor unter Verwendung eines Firmware-Verifizierers; und Gewähren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor, der den Hypervisor verwendet, durch eine Ziel-IP aus der Vielzahl der ersten IPs auf der Grundlage des Verifikationsergebnisses.
  2. Verfahren nach Anspruch 1, wobei der Firmware-Lader und der Hypervisor in einer Rich Execution Environment (REE) arbeiten und der Firmware-Verifizierer in einer Trusted Execution Environment (TEE) arbeitet.
  3. Verfahren nach Anspruch 1, wobei die Vielzahl der ersten IPs mindestens einen digitalen Signalprozessor (DSP), eine neuronale Verarbeitungseinheit (NPU), eine Tensorverarbeitungseinheit (TPU) oder einen Bildsignalprozessor (ISP) umfassen.
  4. Verfahren nach Anspruch 1, wobei der blockierende Zugriff das Ändern einer/von Information(en) über den Speicher in einer Speicherverwaltungseinheit (MMU), die mit dem Hauptprozessor verbunden ist, und in Speicherschutzeinheiten (MPUs), die jeweils mit der Vielzahl der ersten IPs verbunden sind, durch den Hauptprozessor unter Verwendung des Hypervisors umfasst.
  5. Verfahren nach Anspruch 4, wobei das Ändern der Information(en) das Ändern einer logischen zu physischen (L2P)-Zuordnungstabelle der MMU durch den Hauptprozessor unter Verwendung des Hypervisors umfasst, um den Zugriff des Hauptprozessors auf die erste Ziel-Firmware zu blockieren.
  6. Verfahren nach Anspruch 4, wobei das Ändern der Information(en) das Ändern einer Seitentabelle der MPUs durch den Hauptprozessor unter Verwendung des Hypervisors umfasst, um den Zugriff der Vielzahl der ersten IPs auf die erste Ziel-Firmware zu blockieren.
  7. Verfahren nach Anspruch 6, wobei die Seitentabelle (eine) Adressinformation(en) des Speichers, in den die erste Ziel-Firmware kopiert wird, und (eine) der/den Adressinformation(en) entsprechende Property-Information(en) umfasst.
  8. Verfahren nach Anspruch 1, wobei das Ein-Chip-System ferner eine zweite IP zur Sicherheit umfasst, wobei das Verifizieren das Steuern der zweiten IP durch den Hauptprozessor unter Verwendung des Firmware-Verifizierers, um eine Signatur-Verifikationsoperation der ersten Ziel-Firmware durchzuführen, umfasst.
  9. Verfahren nach Anspruch 1, wobei das Gewähren umfasst, dass, wenn das Verifikationsergebnis ein Bestanden ist, Ändern durch den Hauptprozessor unter Verwendung des Hypervisors einer/von Information(en) über den Speicher in einer Speicherschutzeinheit (MPU), die mit der Ziel-IP verbunden ist.
  10. Verfahren von Anspruch 1, ferner umfassend: wenn das Ausführen für die erste Ziel-Firmware der Ziel-IP abgeschlossen ist, Gewähren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor unter Verwendung des Hypervisors, um den Zugriff auf die erste Ziel-Firmware durch das Firmware-Ladeprogramm zu ermöglichen; und Blockieren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor unter Verwendung des Hypervisors durch die Ziel-IP.
  11. Verfahren von Anspruch 1, ferner umfassend: wenn das Ausführen einer zweiten Ziel-Firmware von einer der Vielzahl von ersten IPs angefordert wird, Kopieren der zweiten Ziel-Firmware durch den Hauptprozessor unter Verwendung des Firmware-Laders in den Speicher; Blockieren des Zugriffs auf die zweite Ziel-Firmware durch den Hauptprozessor unter Verwendung des Hypervisors und der Vielzahl der ersten IPs; Verifizieren der zweiten Ziel-Firmware durch den Hauptprozessor unter Verwendung des Firmware-Verifizierers; Gewähren des Zugriffs auf die zweite Ziel-Firmware durch den Hauptprozessor, der den Hypervisor verwendet, durch die eine aus der Vielzahl der ersten IPs, die das Ausführen der zweiten Ziel-Firmware angefordert hat, auf der Grundlage des Verifikationsergebnisses der zweiten Ziel-Firmware; und Gewähren des Zugriffs auf die erste Ziel-Firmware durch den Hauptprozessor unter Verwendung des Hypervisors, um den Zugriff auf die erste Ziel-Firmware durch den Firmware-Lader zu ermöglichen.
  12. Ein-Chip-System (SoC) umfassend: einen Speicher; einen Hauptprozessor, der für das Ausführen eines Betriebssystems eingerichtet ist; und eine Vielzahl von ersten Intellectual Properties (IPs), die eingerichtet sind, um eine entsprechende Verarbeitungsoperation durchzuführen, wobei der Hauptprozessor eingerichtet ist, um: die Ziel-Firmware in den Speicher unter Verwendung eines Firmware-Laders zu kopieren, unter Verwendung eines Hypervisors den Zugriff des Hauptprozessors und der Vielzahl der ersten IPs auf die Ziel-Firmware vor der Verifikation der Ziel-Firmware zu blockieren, und nach der Verifikation der Ziel-Firmware unter Verwendung des Hypervisors den Zugriff auf die Ziel-Firmware durch eine Ziel-IP aus der Vielzahl der ersten IPs, die der Ziel-Firmware entspricht, zu gewähren.
  13. SoC nach Anspruch 12, wobei der Hauptprozessor mit einer ersten Speicherverwaltungseinheit (MMU) verbunden ist, die eine L2L-Zuordnungstabelle verwaltet, und einer zweiten MMU, die eine L2P-Zuordnungstabelle verwaltet, um stufenweise auf den Speicher zuzugreifen, wobei die Vielzahl der ersten IPs jeweils mit System-MMUs, die eine L2P-Zuordnungstabelle verwalten, und mit Speicherschutzeinheiten (MPUs) verbunden sind, die eine Seitentabelle verwalten, um stufenweise auf den Speicher zuzugreifen.
  14. SoC nach Anspruch 13, wobei der Hauptprozessor einen Zugriff auf die Ziel-Firmware gewährt, indem er unter Verwendung des Hypervisors (eine) Information(en) über den Speicher in der zweiten MMU und in den MPUs ändert.
  15. SoC nach Anspruch 14, wobei die Information(en) über den Speicher die L2P-Zuordnungstabelle der MMU, die die physische(n) Adressinformation(en) des Speichers, auf den die Ziel-Firmware kopiert wird, und die dieser/diesen zugeordnete(n) logische(n) Adressinformation(en) enthält, und die Seitentabelle der MPUs, die die physische(n) Adressinformation(en) und die ihr entsprechende(n) Property-Information(en) enthält, umfasst.
  16. SoC aus Anspruch 13, wobei der Hauptprozessor eingerichtet ist, um die erste MMU und die System-MMUs unter Verwendung eines Kernels zu steuern.
  17. SoC nach Anspruch 12, wobei die Vielzahl der ersten IPs mindestens einen digitalen Signalprozessor (DSP), eine neuronale Verarbeitungseinheit (NPU), eine Tensorverarbeitungseinheit (TPU) oder einen Bildsignalprozessor (ISP) umfassen.
  18. SoC aus Anspruch 12, das ferner eine zweite IP zum Durchführen der Verifikation der Ziel-Firmware umfasst, wobei der Hauptprozessor unter Verwendung eines Firmware-Verifizierers die zweite IP steuert, um eine Signatur-Verifikationsoperation der Ziel-Firmware durchzuführen.
  19. SoC nach Anspruch 18, die ferner eine Speichervorrichtung umfasst, in der die Ziel-Firmware, der Firmware-Lader, der Hypervisor und der Firmware-Verifizierer in einer Form von Code gespeichert sind, der vom Hauptprozessor ausgeführt werden kann.
  20. Betriebsverfahren eines Ein-Chip-Systems mit einem Hauptprozessor, einer Vielzahl von Intellectual Properties (IPs) und einem Sicherheitssystem, wobei das Betriebsverfahren umfasst: Anfordern durch einen vom Hauptprozessor ausgeführten Kernel an einen vom Hauptprozessor ausgeführten Hypervisor der Verwaltung zum Laden der Ziel-Firmware; Ändern durch den Hypervisor der Zugriffsberechtigung auf einen Speicherbereich, in den die Ziel-Firmware geladen werden soll, für mindestens einen von dem Hauptprozess und der Vielzahl der IPs; Laden der Ziel-Firmware durch den Kernel in den Speicherbereich; Anfordern der Verifikation der geladenen Ziel-Firmware durch den Kernel an den Hypervisor; Ändern der Zugriffsberechtigung auf den Speicherbereich durch den Hypervisor für mindestens eines von dem Hauptprozessor und der Vielzahl der IPs; Anfordern durch den Hypervisor von dem Sicherheitssystem einer Verifikation der geladenen Ziel-Firmware; Durchführen einer Verifikation durch das Sicherheitssystem an der geladenen Ziel-Firmware; Bereitstellen an den Hypervisor eines Verifikationsergebnisses der Verifikation durch das Sicherheitssystem; Ändern der Zugriffsberechtigung für mindestens eines von dem Hauptprozessor und der Vielzahl der IPs auf den Speicherbereich durch den Hypervisor auf der Grundlage des Verifikationsergebnisses; und Ausführen der geladenen Ziel-Firmware durch den Kernel.
DE102020127800.4A 2020-03-06 2020-10-22 Ein-chip-system und verfahren zu dessen betrieb Pending DE102020127800A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020200028586A KR20210112923A (ko) 2020-03-06 2020-03-06 시스템 온 칩 및 이의 동작 방법
KR10-2020-0028586 2020-03-06

Publications (1)

Publication Number Publication Date
DE102020127800A1 true DE102020127800A1 (de) 2021-09-09

Family

ID=77388751

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020127800.4A Pending DE102020127800A1 (de) 2020-03-06 2020-10-22 Ein-chip-system und verfahren zu dessen betrieb

Country Status (5)

Country Link
US (1) US11847225B2 (de)
KR (1) KR20210112923A (de)
CN (1) CN113434453A (de)
DE (1) DE102020127800A1 (de)
TW (1) TWI844763B (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102126931B1 (ko) * 2018-11-07 2020-06-25 시큐리티플랫폼 주식회사 시큐어 부팅 장치 및 방법
US20230035610A1 (en) * 2021-07-29 2023-02-02 Saratoga Milkyway Inc. Hybrid system fabric for enabling host operating system and real-time operating system within chiplet system-on-chip
CN114218153B (zh) * 2021-12-06 2023-11-14 海飞科(南京)信息技术有限公司 用于存储管理的方法、介质、程序产品、系统和装置
CN114647453B (zh) * 2022-03-01 2023-06-09 芯原微电子（成都）有限公司 多处理器的可信动态启动方法、系统、存储介质及终端
CN114880251B (zh) * 2022-07-12 2023-08-29 荣耀终端有限公司 存储单元的访问方法、访问装置和终端设备
CN117521054A (zh) * 2022-07-30 2024-02-06 华为技术有限公司 电子装置和安全访问软件的方法
TWI830443B (zh) * 2022-10-18 2024-01-21 新唐科技股份有限公司 針對攻擊進行處置的安全處理裝置、方法與電子設備
CN117453318B (zh) * 2023-12-25 2024-03-15 上海励驰半导体有限公司 基于iommu的dsp固件使用方法、系统芯片及车机

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200028586A (ko) 2018-09-07 2020-03-17 두산중공업 주식회사 고농도 유기물, 질소 및 인을 제거하는 수처리 장치 및 이를 이용하는 수처리 방법

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7103529B2 (en) 2001-09-27 2006-09-05 Intel Corporation Method for providing system integrity and legacy environment emulation
US20060294355A1 (en) 2005-06-24 2006-12-28 Zimmer Vincent J Secure variable/image storage and access
US8554686B2 (en) 2005-06-30 2013-10-08 Advanced Micro Devices, Inc. Anti-hack protection to restrict installation of operating systems and other software
CN100580638C (zh) * 2007-07-26 2010-01-13 北京神州龙芯集成电路设计有限公司 一种实现硬件级验证的方法及装置
US8201161B2 (en) * 2008-01-07 2012-06-12 Lenovo (Singapore) Pte. Ltd. System and method to update device driver or firmware using a hypervisor environment without system shutdown
IN2012DN02458A (de) 2009-11-13 2015-08-21 Irdeto Canada Corp
KR20120014673A (ko) 2010-08-10 2012-02-20 주식회사 잉카인터넷 위장 동적연결라이브러리 삽입에 의한 프로세스 변조 검출방법
KR101064164B1 (ko) 2011-03-02 2011-09-15 (주)아이넷캅 리눅스 커널 기반 스마트 플랫폼 내에서의 커널 무결성 검사 및 변조된 커널 데이터 복구 방법
JP5655677B2 (ja) 2011-04-04 2015-01-21 富士通株式会社 ハイパーバイザ置き換え方法および情報処理装置
CN102411535B (zh) * 2011-08-02 2014-04-16 上海交通大学 导航SoC芯片仿真、验证和调试平台
US8775784B2 (en) * 2011-11-11 2014-07-08 International Business Machines Corporation Secure boot up of a computer based on a hardware based root of trust
US9141802B2 (en) 2012-09-25 2015-09-22 Intel Corporation Computing device boot software authentication
US10063380B2 (en) 2013-01-22 2018-08-28 Amazon Technologies, Inc. Secure interface for invoking privileged operations
US20140250290A1 (en) 2013-03-01 2014-09-04 St-Ericsson Sa Method for Software Anti-Rollback Recovery
JP2016534479A (ja) 2013-09-12 2016-11-04 ヴァーセック・システムズ・インコーポレーテッドＶｉｒｓｅｃ Ｓｙｓｔｅｍｓ，Ｉｎｃ． マルウェアのランタイム中の自動検出
JP6895666B2 (ja) 2015-04-07 2021-06-30 ランセーフ セキュリティー，インク． バイナリ及びメモリ多様性による難読化システム及び方法関連出願の相互参照
KR20170089352A (ko) 2016-01-26 2017-08-03 한국전자통신연구원 가상화 시스템에서 수행하는 무결성 검증 방법
US10057069B2 (en) 2016-02-29 2018-08-21 Red Hat Israel, Ltd. Securing code loading by a guest in a virtual environment
US20170255775A1 (en) 2016-03-02 2017-09-07 Apple Inc Software verification systems with multiple verification paths
EP3220262B1 (de) 2016-03-15 2018-06-13 Axis AB Vorrichtung, die während der firmware-aktualisierung betätigbar ist
US10110624B2 (en) 2016-04-19 2018-10-23 Red Hat Israel, Ltd. Discovering and provisioning computing devices in a security enhanced environment
US10097563B2 (en) * 2016-05-04 2018-10-09 Gbs Laboratories, Llc Reliable and secure firmware update with a dynamic validation for internet of things (IoT) devices
US10482257B2 (en) 2017-03-16 2019-11-19 Dell Products, L.P. System and method to enforce the secure boot policy of a platform on a virtual machine
US10747883B2 (en) * 2017-05-11 2020-08-18 Qualcomm Incorporated Collated multi-image check in system-on-chips
US10409585B2 (en) * 2018-02-14 2019-09-10 Micron Technology, Inc. Over-the-air (OTA) update for firmware of a vehicle component
US10802875B2 (en) * 2018-04-30 2020-10-13 Qualcomm Incorporated Multithread framework for use in pre-boot environment of a system-on-chip

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200028586A (ko) 2018-09-07 2020-03-17 두산중공업 주식회사 고농도 유기물, 질소 및 인을 제거하는 수처리 장치 및 이를 이용하는 수처리 방법

Also Published As

Publication number Publication date
KR20210112923A (ko) 2021-09-15
CN113434453A (zh) 2021-09-24
TW202203012A (zh) 2022-01-16
US11847225B2 (en) 2023-12-19
TWI844763B (zh) 2024-06-11
US20210279334A1 (en) 2021-09-09
US20240045969A1 (en) 2024-02-08

Similar Documents

Publication Publication Date Title
DE102020127800A1 (de) Ein-chip-system und verfahren zu dessen betrieb
US20230128711A1 (en) Technologies for trusted i/o with a channel identifier filter and processor-based cryptographic engine
DE112018002031B4 (de) Sichern einer betriebssystemkonfiguration unter verwendung von hardware
CN105431858B (zh) 安全特权等级执行和访问保护
DE112017004017T5 (de) Sichere öffentliche cloud
DE112016004330T5 (de) Prozessoren, Verfahren, Systeme und Befehle zum Zulassen sicherer Kommunikationen zwischen einem geschützten Containerspeicher und Eingabe-/Ausgabegeräten
CN107667350A (zh) 基于虚拟化的平台保护技术
CN107408096B (zh) 对硬件块的适应性存取控制
US9916205B2 (en) Secure live virtual machine guest based snapshot recovery
DE102011082184A1 (de) Sicherheitsschutz für Speicherinhalt von Prozessorhauptspeicher
KR20160075499A (ko) 가상 머신 관리자에 의해 촉진되는 선택적 코드 무결성 강화 기법
DE102019108266A1 (de) Techniken zum bereitstellen von isolation auf funktionsebene mit auf fähigkeit basierender sicherheit
DE112016004476T5 (de) Technologien für einen nur-ausführungs-transaktionsarbeitsspeicher
DE102018115683A1 (de) Domänenübergreifende sicherheit in kryptographisch partionierter cloud
DE112007001321T5 (de) Ausführung eines Sichere-Umgebungs-Initialisierungsbefehls in einem Punkt-zu-Punkt-Verbindungssystem
DE102023202297A1 (de) Wahrung der vertraulichkeit von mandanten in einer cloud-umgebung beim einsatz von sicherheitsdiensten
DE112016004297T5 (de) Technologien für mehrstufige virtualisierung
US20180150311A1 (en) Virtual processor state switching virtual machine functions
WO2021055290A1 (en) Controlled access to data stored in a secure partition
EP3722952A1 (de) Konzept für den zugriff auf einen computerspeicher eines speicherpools
CN105009134A (zh) 提供安全操作的方法、装置、系统和计算机可读介质
DE102022108625A1 (de) Mehrere physische anforderungsschnittstellen für sicherheitsprozessoren
US20150278512A1 (en) Virtualization based intra-block workload isolation
CN112784283B (zh) 能力的管理方法和计算机设备
KR20170112855A (ko) 스토리지 디바이스에서 논리 블록 어드레싱 액세스 퍼미션을 정의하는 방법 및 시스템

Legal Events

Date Code Title Description
R012 Request for examination validly filed