WO2021122734A1 - Verfahren und vorrichtung zum betreiben einer recheneinrichtung - Google Patents

Verfahren und vorrichtung zum betreiben einer recheneinrichtung Download PDF

Info

Publication number
WO2021122734A1
WO2021122734A1 PCT/EP2020/086404 EP2020086404W WO2021122734A1 WO 2021122734 A1 WO2021122734 A1 WO 2021122734A1 EP 2020086404 W EP2020086404 W EP 2020086404W WO 2021122734 A1 WO2021122734 A1 WO 2021122734A1
Authority
WO
WIPO (PCT)
Prior art keywords
zone
computing
preferred embodiments
program
further preferred
Prior art date
Application number
PCT/EP2020/086404
Other languages
English (en)
French (fr)
Inventor
Manuel Jauss
Razvan Florin AGURIDAN
Mustafa Kartal
Roland Steffen
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP20833782.4A priority Critical patent/EP4078415A1/de
Priority to JP2022537899A priority patent/JP7392157B2/ja
Priority to US17/785,163 priority patent/US20230021594A1/en
Priority to CN202080087688.5A priority patent/CN114787806A/zh
Publication of WO2021122734A1 publication Critical patent/WO2021122734A1/de

Links

Classifications

    • 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/53—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 executing in a restricted environment, e.g. sandbox or secure virtual machine
    • 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/1483—Protection against unauthorised use of memory or access to memory by checking the subject access rights using an access-table, e.g. matrix or list
    • 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • 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
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2105—Dual mode as a secondary aspect
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control

Definitions

  • the disclosure relates to a method for operating a computing device having at least one computing core.
  • the disclosure also relates to an apparatus for carrying out such a method.
  • a reduction in the attack possibilities is achieved in particular by providing different zones, namely at least one trustworthy and at least one untrustworthy zone, to which respective programs are assigned.
  • Data exchange between the different zones is improved by providing different buffer memory areas with different authorizations (reading, writing, but not: executing).
  • a transition of data from the untrusted zone to the Trusted zone does not take place until the data is validated, but still in the untrusted zone.
  • This allows further manipulation possibilities to be restricted.
  • cases of abuse due to incorrect programming for example incorrect return addresses, impermissible overwriting in the event of buffer overflow / underflow, etc., can be minimized in particular by using a memory protection device that controls the access rights to certain buffer memory areas for data exchange.
  • the zone separation can also be applied to interfaces, memories or runtimes, which further reduces the possibility of misuse. In addition, this concept further reduces the impact of a corrupted zone.
  • the concept can already be implemented with a single multi-core solution. The concept can be easily scaled, ie additional zones can be added particularly easily depending on the security architecture.
  • an exchange of data between different zones has the following steps: copying the data in the first buffer memory area assigned to the first zone, checking or validating the copied data and, depending on the checking or validation, copying the data from the first Zone assigned first buffer storage area in the second buffer storage area assigned to the second zone.
  • the validation of the incoming data can further increase security.
  • the speed of the data exchange can be increased due to the chosen concept with the buffer memories with high security against manipulation.
  • the concept also allows the untrustworthy zone to be monitored by using monitoring mechanisms for monitoring the trusted zone.
  • the data in the exchange buffer memory area are particularly expediently checked in connection with a read access, in particular by the additional program, and if the data is checked successfully, the data is copied from the exchange buffer memory area into the second buffer memory area. This allows for a clear separation of zones, so that no corrupted data gets into the trusted zone.
  • Security is further increased by preventing executive access to data in each of the buffer memory areas or in the exchange buffer memory area. This means that the data can only be used after verification. This further increases security.
  • a method for operating a computing device having at least one computation kernel, in particular for an embedded system and / or a control device, in particular for a vehicle, in particular a motor vehicle is provided, the method having the following steps: Assignment of one or more by the Computing device executable programs, in particular application programs or subprograms, for one of at least two zones, the zones characterizing resources of the computing device that can be used for executing a relevant application program, optionally executing at least one of the programs, in particular application programs or subprograms, depending on it assigned zone, the method further comprising: using a supervisor to assign computing time resources for different programs, in particular application programs and / or instances of application programs, where de The supervisor and / or a functionality corresponding to the supervisor is at least partially implemented by means of a supervisor instance that is independent of the at least two zones.
  • FIG. 1 schematically shows a simplified block diagram of a computing device according to preferred embodiments
  • FIG. 2A schematically shows a simplified flow diagram of a method according to further preferred embodiments
  • FIG. 3 schematically shows a simplified block diagram of a computing device according to further preferred embodiments
  • Fig. 15 to 19 each schematically a simplified block diagram of aspects according to further preferred embodiments.
  • FIG. 23 schematically shows a simplified block diagram of configuration data in accordance with further preferred embodiments.
  • 25 shows a simplified block diagram of the integration of the device in a motor vehicle.
  • FIG. 1 schematically shows a simplified block diagram of a computing device 100 according to preferred embodiments.
  • the computing device 100 has at least one computing core, in the present example four computing cores 102a, 102b, 102c, 102n, and can in particular be used, for example, for an embedded system and / or a control device, in particular for a vehicle, in particular a motor vehicle.
  • Preferred embodiments relate to a method for operating the computing device 100, which has the following steps, cf. the flowchart in FIG. 2A: Allocation 200 of one or more programs executable by the computing device 100 (FIG. 1), in particular application programs AP1, AP2 and / or subroutines and / or proxies and / or instances for one of at least two zones Z1, Z2, zones Z1, Z2 characterizing resources of the computing device 100 which are required for executing a relevant program, in particular application program AP1, AP2 and / or Subroutines and / or proxies and / or instances of an application program AP1, AP2 can be used, optionally executing 210 at least one of the programs, in particular application programs AP1, AP2 and / or subroutines and / or proxies and / or instances, depending on the zone Z1, Z2 assigned to it.
  • the method optionally further comprises: using 212 a supervisor SV to assign computing time resources for different programs, in particular application programs and / or instances of application programs, the supervisor SV and / or a functionality corresponding to the supervisor SV at least partially by means of a supervisor instance SVI (Fig. 1) is realized, which is independent of the at least two zones Z1, Z2.
  • a supervisor instance SVI Fig. 1
  • trust boundaries can thereby be defined, e.g. between trustworthy and untrustworthy entities / units / domains.
  • first programs in particular application programs and / or sub-programs and / or proxies and / or instances, for the computing device of an untrustworthy first zone (English: non-trustworthy zone, NTZ) and second programs, in particular application programs and / or Subroutines and / or proxies and / or instances for the computing device are assigned to a trustworthy second zone (English: trustworthy zone, TZ).
  • the computing device 100 has several (for example, four as shown by way of example in FIG. 1) computing cores 102a, 102b, 102c, 102n, the method further having, cf. FIG. 2B: a) assigning 220 at least one computing core to exactly one zone, and / or b) assigning 222 at least one computing core to more than one zone, in particular to two zones, c) using 224 at least one computing core as a supervisor instance SVI, in particular using the at least a computing core as a dedicated supervisor instance SVI, d) using 225 at least one hardware security module HSM and / or trusted platform module, TPM, as a supervisor instance SVI.
  • HSM hardware security module
  • TPM trusted platform module
  • the first computing core 102a is assigned to a first zone Z1 which, for example, can represent an untrustworthy zone
  • the second computing core 102b is assigned to a second zone Z2 which, for example, can represent a trustworthy zone.
  • the third computing core 102c is assigned to both the first zone Z1 and the second zone Z2, see FIG. 1. The same can also apply to the fourth computing core 102n of the computing device 100 in further preferred embodiments.
  • the computing device 100 according to FIG. 1 can also have further components not listed in detail in FIG. 1, such as one or more storage devices and / or peripheral components, which are shown together in FIG. 1 for the sake of clarity by means of the dashed rectangle 103 are indicated.
  • Reference numeral 104 symbolizes one or more data interfaces.
  • the untrustworthy zone Z1 comprises components / control devices in a motor vehicle in a connectivity zone 400, cf. Wired interface 412 (easily accessible with physical connectivity) such as a diagnostic interface (OBD) with associated interface port 426.
  • Wired interface 412 embedded with physical connectivity
  • OBD diagnostic interface
  • Possible components in connectivity zone 400 are, for example, a so-called connectivity control unit or a device for external vehicle networking 420, an infotainment 422, a multimedia unit 424, etc. are provided.
  • Such functions of the motor vehicle are located in this connectivity zone 400, which are characterized on the one hand by data exchange with devices outside the vehicle, but on the other hand do not include any safety-relevant functions that are absolutely necessary for driving the motor vehicle.
  • these are components with a low safety classification, for example ASIL classification QM or ASIL-A according to ISO 26262, an ISO standard for safety-relevant systems in motor vehicles.
  • Such safety-relevant functions which are absolutely necessary for driving the motor vehicle, are located in the safety zone 440.
  • This functional safety zone 440 serves in particular to protect occupants and the environment.
  • the safety zone 440 includes all components / control devices with high requirements in terms of functional safety (engine control, steering, brakes, ). All data coming from the trustworthy zone Z2 are preferably evaluated directly as trustworthy without further input validation.
  • the components of the safety zone 440 can be the motor control 442,
  • Acting brake system 444, steering 446 etc. There are increased security requirements for the components of the security zone 440. These are safety requirements - as classified in the ISO standard IS026262 - from ASIL-B to ASIL-D in the safety classification according to IS026262.
  • a control zone 430 is provided as a link, in particular for data exchange between the security zone 440 and the connectivity zone 400.
  • the control zone 430 is implemented by a gateway 432 in which the functions described are implemented.
  • the control zone 430 is distinguished by targeted monitoring of the communication between the connectivity zone 400 and the security zone 440.
  • the zone separation between the trustworthy zone Z2 and the untrustworthy zone Z1 with the associated data exchange and monitoring mechanisms, in particular by the memory protection device SSE or the supervisor SV, is located. The corresponding interaction takes place between connectivity zone 400 and functional safety zone 440.
  • the division of interfaces 410, 412, resources, runtime and privileges according to zones is particularly preferred.
  • the interfaces 410, 412 can be physically separate bus systems or logical diagnostic interfaces.
  • the resources include memory 1030, 1030a, program memory, data memory and data buffer or buffer memory.
  • the runtime comprises separate tasks or the provision of separate communication proxies or instances (subroutines, for example, in connection with the splitting the protocols according to zones Z1, Z2; these proxies or subroutines are only used for the communication process).
  • separate application proxies or instances sub-programs that change the data or access this data to run application programs, for example for connected services, remote door unlocking, remote parking
  • programs for example for connected services, remote door unlocking, remote parking
  • the privileges include, for example, privileged operating modes.
  • a special mode can be provided for the first zone Z1, as can be implemented, for example, via the configuration data for the memory protection device SSE.
  • a special mode can be provided for the second zone Z2, as can also be implemented, for example, via the configuration data for the memory protection device SSE.
  • a supervisor or supervisor instance SVI again represented by the configuration data for the memory protection device SSE, can be provided for changing between the above-mentioned modes for the two zones Z1, Z2. A one-time static and authentic configuration of the memory protection device SSE takes place here.
  • the supervisor instance SVI can be formed, for example, by a (dedicated) computing core and / or a hardware security module HSM and / or a trusted platform module TPM, or the functionality of the supervisor instance SVI can be implemented by means of at least one of these elements can be realized.
  • FIG. 3 schematically shows a simplified block diagram of a computing device 100a according to further preferred embodiments, which - comparable to the computing device 100 according to FIG. 1 - has four computing cores 102a, 102b, 102c, 102n. Also shown in Fig. 3 is a working memory (RAM) 1030, a non-volatile memory 1032 (e.g. flash memory, especially Flash EEPROM), and optionally available special function registers 1034 of the computing device 100a, such as can be used, for example, to control the operation of peripheral components thereof are.
  • the components 102a, 102b,..., 1034 are connected to one another via a bus system 101.
  • the method for operating the computing device 100 FIG.
  • 100a (FIG. 3) further comprises, see FIG. 2C: control 230, in particular limiting, of at least one of the following elements: a ) Read rights on the memory 1030, 1032 assigned to the computing device 100, 100a, b) Write rights on the memory 1030, 1032 assigned to the computing device, c) Execution rights (“execution rights”) on the memory 1030, 1032 assigned to the computing device, depending on at least one zone Z1, Z2. This advantageously ensures that only such programs, in particular
  • Application programs AP1, AP2 (FIG. 1), subroutines, etc., get access to the mentioned memory or memories 1030, 1032, which are assigned to a corresponding zone Z1, Z2.
  • a program, in particular application program, subprogram, proxy of an untrustworthy zone accesses the memory (s) 1030, 1032 (in particular, for example, access to the memory area 1030, 1032 assigned to the trustworthy zone the untrustworthy zone), which may represent a risk of possible manipulation of the memory content by the program in the untrustworthy zone.
  • the method further comprises, see FIG. 2C: at least temporary use 232 of at least one memory protection device M1, M2, M3, M4, M5_1, M5_2,
  • M5_3, M5_4, M5_5, M5_6, M5_7, M5_8 (Fig. 3) for controlling the reading rights and / or the writing rights and / or the execution rights.
  • the method further comprises, see FIG. 2D: Providing 231 at least one dedicated memory protection device M1 for at least one computing core 102a, in particular one for several, preferably all, computing cores 102a, 102b, 102c, 102n dedicated memory protection device M1, M2, M3, M4 is provided.
  • the respective (dedicated) memory protection device M1, M2, M3, M4 can then be used, see step 232 'from FIG Read and / or write rights and / or execute rights.
  • the use 232 '(FIG. 2D) can be preceded by an optional configuration 231a of the memory protection device (s).
  • At least one computation core 102a at least temporarily adopts a first operating mode, see step 240, wherein in particular the at least one computing core 102a in the first operating mode configuration data 1036 (FIG. 3), which control, prescribe and / or write 242 an operation of at least one memory protection device M1, M2, .., M5_8, wherein in particular the at least one computing core 102a at least temporarily assumes a second operating mode 243 in which it stores the configuration data for the at least one memory protection device M1, M2, .., M5_8 cannot write and / or change.
  • a first operating mode see step 240, wherein in particular the at least one computing core 102a in the first operating mode configuration data 1036 (FIG. 3), which control, prescribe and / or write 242 an operation of at least one memory protection device M1, M2, .., M5_8, wherein in particular the at least one computing core 102a at least temporarily assumes a second operating mode 243 in which it stores the configuration data for the at least one memory
  • the first operating mode can also be referred to as “supervisor mode” or monitoring mode.
  • the “supervisor mode” or monitoring mode can thus preferably represent a privileged state in which the relevant computing core 102a can configure the at least one memory protection device M1, M2,..., M5_8.
  • SFR special function registers
  • special function registers in particular configuration register 1036, can be provided for the configuration data of the at least one memory protection device M1, M2,..., M5_8.
  • SFR special function registers
  • the at least one computing core 102a assumes 240 the first operating mode in an event-controlled manner, in particular as a function of at least one interrupt request.
  • the method further comprises, see FIG. 2F: Providing 250 multiple sets of configuration data KD for the at least one memory protection device M1, M2, .., M5_8, in particular at least one first set of the multiple sets of Configuration data KD is assigned to a first zone Z1 of the at least two zones and at least one second set of the multiple sets of configuration data KD is assigned to a second zone Z2 of the at least two zones, see step 252.
  • At least one arithmetic core 102a within the framework of dedicated system states, for example during a start cycle, and / or for certain events, for example when entering an interrupt service routine (ISR), a certain Operating mode such as supervisor mode, which can be done under hardware control, for example.
  • ISR interrupt service routine
  • At least one further, non-privileged operating mode is provided for one or more, preferably all, computing cores ("non-privileged mode"), which in further preferred embodiments can also be referred to as "user mode" .
  • non-privileged mode the configuration data KD, 1036 for the at least one memory protection device M1, M2,..., M5_8 are preferably not writable.
  • a computing kernel that is currently in user mode cannot write or change the configuration data KD, 1036 for the at least one memory protection device M1, M2,..., M5_8, whereas a computing kernel that is is currently in the supervisor mode, the configuration data KD, 1036 for the at least one memory protection device M1, M2, .., M5_8 can write or change.
  • the application programs AP1, AP2 are executed or executed in a non-privileged mode, for example the user mode.
  • three operating modes or operating states or modes can also be provided, for example: firstly a supervisor mode, secondly a "user mode 1", in particular for untrustworthy zone (s), thirdly a "user mode 2" , especially for trusted zone (s).
  • the static configuration data KD2 can be active in user mode 1, for example, and a first application program AP1 is running, for example.
  • the static configuration data KD3 can be active in user mode 2, for example, and a second application program AP2 is running, for example.
  • the static configuration data KD1 are active in the supervisor mode, the supervisor mode e.g. (optionally only) serving to switch between the static configuration data KD2 and the static configuration data KD3.
  • the user modes 1 and 2 cannot switch between the static configuration data KD1, KD2, KD3, KD4.
  • supervisor mode can also be provided, for example.
  • supervisor mode can be assigned to the trustworthy zone and, for example, switch between the configuration data KD1 and the configuration data KD2 and, if necessary, execute the second application program AP2, for example.
  • different operating modes or operating states eg privileged and non-privileged Mode or supervisor mode, user mode
  • different operating mode specific read and / or write and / or execution rights execution rights
  • execution rights for example assigned to the memory or memories 1030, 1032, which in further preferred embodiments, for example, by the Provision of different sets of configuration data KD ("configuration data sets")
  • configuration data sets can be implemented.
  • operating mode-specific and / or application-specific read and / or write and / or execution rights are assigned for different combinations of operating mode (s) with respective application programs, which in further preferred embodiments, for example, also by providing different sets of configuration data KD ("Configuration data sets") is realizable.
  • configuration data sets For example, read and / or write and / or execution rights can be assigned to the application program AP1, AP2 in question, for example for the user mode for different application programs AP1, AP2 (FIG. 1).
  • one or more, preferably all of the memory protection devices M1, M2,..., M5_8 mentioned by way of example have several configuration data sets which, in further preferred embodiments, can preferably be efficiently assigned to different modes and application programs AP1, AP2.
  • the computing device 100, 100a has the configuration options mentioned below by way of example: a) a, in particular static (non-changeable), configuration data set for at least one central one Memory protection device or at least one memory protection device M5_1, M5_8, b) assigned to the bus system 101 (FIG. 3), four, in particular static, configuration data sets for the dedicated memory protection devices M1, M2, M3, M4, these four configuration data sets each for the dedicated memory protection devices have further preferred embodiments, for example, a static configuration data set for the supervisor mode and, for example, three static configuration data sets for application programs AP1, AP2, that is to say for example for the user mode.
  • FIG. 23 shows schematically exemplary configuration data KD 'with a total of four configuration data sets KD1, KD2, KD3, KD4.
  • the configuration data define, for example, which memory addresses a component of the computing device, for example a computing core, is allowed to read and / or write and / or execute.
  • the memory protection device can be designed to compare accesses (read and / or write and / or execute) currently being carried out by the relevant computing kernel with the content of the configuration data and, for example, to allow or prohibit the relevant accesses if they match or the other way around.
  • the mentioned, preferably static, configuration data sets for the dedicated memory protection devices M1, M2, M3, M4, e.g. for user mode can correlate with the zones Z1, Z2 according to the embodiments.
  • application programs for two zones Z1, Z2, each with a different confidence level are executed on a specific computing kernel 102c (FIG. 1).
  • Two different static configuration data sets are preferably used here for the programs or application programs of the first zone Z1 and the programs or application programs of the second zone Z2, in particular for the user mode, and preferably a further static configuration data set for a further operating mode, for example the Supervisor mode.
  • the computing core 102c is designed to switch between the two static configuration data sets for the two zones Z1, Z2 in the operating mode of the supervisor mode.
  • the computing core 102c can thus activate a configuration data set suitable for the first zone Z1 in its dedicated memory protection device in the supervisor mode if, for example, a program assigned to the first zone Z1, in particular application program AP1 or subroutine or instance, is to be executed, and For example, activate a configuration data set suitable for the second zone Z2 in its dedicated memory protection device if, for example, a program assigned to the second zone Z2, in particular an application program AP2 or subroutine or instance, is to be executed.
  • any remaining, previously unused configuration data sets for programs, especially in user mode can be configured in further preferred embodiments, for example, in such a way that they have general read, write and execution access to the Prevent complete memory 1030, 1032, which further increases security.
  • the method further comprises: providing 260 a first instance AP1 11 (or subprogram, proxy) of the application program AP1 and a second instance AP1J2 (or subprogram, proxy) of the application program AP1, assigning 262 the first instance AP1J1 of the application program AP1 to a first zone Z1 of the at least two zones, assigning 263 the second instance AP1J2 of the application program AP1 to a second zone Z2 of the at least two zones.
  • use cases can advantageously be covered in which an application or an application program AP1 “extends” over several zones Z1, Z2.
  • one instance AP1J1, AP1J2 can exist per zone for this application program AP1, wherein such an instance can also be referred to as a proxy in further preferred embodiments.
  • programs can be understood as proxy, instances, subroutines, etc., such as application programs that require data or generate data, as well as communication programs that are used for data handling.
  • such a proxy AP1J2 can cover (partial) functionalities that are relevant for the further zone Z2 in question.
  • a proxy can optionally also comprise several sub-components.
  • the computing device 100, 100a can execute the following scenario, for example: If a first program, in particular application program AP1, subprogram, is to receive data from, for example, an untrustworthy first zone Z1 - for example remote service requests der Ferne ") from the Internet - and process or forward this data accordingly within the trustworthy zone Z2 - for example to carry out the corresponding service (" remote service ") - this takes place within the first zone Z1 through the Z1 proxy AP1J1 of the application program AP1 receiving the data, the corresponding Z2 proxy AP1J2 executing the following steps, for example: a data verification of the data classified as untrustworthy by the Z2 proxy AP1J2, in particular by default, and - in the case of a successful data verification - the processing or Forwarding of the now (after data verification) classified as trustworthy Data within the second zone Z2.
  • the method further comprises, see FIG. 2H: Separation 270 of areas of a memory 1030, 1032 assigned to the computing device 100, 100a as a function of the at least two zones Z1, Z2, where the area of the computing device 100, 100a assigned memory has at least one of the following elements: a) buffer memory, in particular in the form of main memory, b) stack memory, c) data memory, d) program memory, e) register memory, with at least one memory protection device being used for the separation 270, cf. optional step 272.
  • the method further comprises, see FIG. 2I: exchange 280 of first data between different zones via a buffer memory, in particular a working memory, wherein in particular the exchange of the first data between the first zone Z1 and the second zone Z2 has the following steps: copying 282 the first data into a first buffer memory area TB1b, B3 assigned to the first zone, checking 283 the copied first data, and, in particular depending on the check, copying 283 the first data from the first data assigned to the first zone Z1 Buffer storage area TB1b, B3 into a second buffer storage area TB2a, B1_2 assigned to the second zone Z2.
  • the data exchange takes place particularly preferably via an exchange buffer memory area TB1A (for data exchange from zone 1 Z1 to zone 2Z2) or via an exchange buffer area TB2b (for data exchange from zone 2 Z2 to zone 1 Z1).
  • FIG. 4 schematically shows a simplified block diagram of aspects of the computing device 100, 100a according to further preferred embodiments.
  • the two computation cores 102a, 102b which, as already described above, are assigned to the respective zones Z1, Z2, are shown.
  • An area 1030a of the main memory 1030 (FIG.
  • buffer memory or like the buffer memory areas described below (first buffer memory area TB1b, B3; second buffer memory area TB2a, B1_2; exchange buffer memory area TB1a, TB2b, B3 ")) or" shared working memory ", in particular for data exchange between different zones Z1, Z2 or the relevant computing cores 102a, 102b or executable thereon (Instances of) application programs can be used, a first sub-area TB1 being assigned to the first zone Z1 or the second computing core 102b and a second sub-area TB2 being assigned to the second zone Z2 or the first computing core 102a.
  • proxies PXY are also shown in FIG. 4, with, for example, a first number of proxies Z1-Proxy 1, Z1-Proxy 2,..., Z1-Proxy n being assigned to the first zone Z1, that is to say in the present case to the computing core 102b, and wherein, for example, a second number of proxies Z2 proxy 1, Z2 proxy 2,..., Z2 proxy n is assigned to the second zone Z2, that is to say in the present case to the computing core 102a.
  • the reference symbol SSE denotes several memory protection devices SSE or functional components thereof, which symbolically indicate in FIG. 4 a corresponding separation of the subregions TB1, TB2 or the zones Z1, Z2 from one another or from one another according to the principle according to preferred embodiments.
  • first buffer memory area TB1b, B3 second buffer storage area TB2a, B1_2; Exchange buffer storage area TB1a, TB2b, B3 ”.
  • a first buffer storage area TB1b, B3 ' is provided for the first or transmitting zone Z1.
  • the sending or first zone Z1 or the first program assigned to the untrustworthy zone Z1, in particular application program AP 1, subroutine, etc. has the following access rights, implemented via the memory protection device SSE: read, write, not: execute.
  • the receiving or second zone Z2 or the second program assigned to the trustworthy zone Z2, in particular application program AP2, subroutine, etc. has no access rights to the first buffer memory area TB1b, B3 ', implemented via the memory protection device SSE, i.e. neither reading, writing nor To run.
  • a second buffer storage area TB2a, B1_2 is provided for the second or receiving zone Z2.
  • the receiving or second zone Z2 or the second program assigned to the trustworthy zone Z2, in particular application program AP2, subroutine, etc. has the following access rights, implemented via the memory protection device SSE: read, write, not: execute.
  • the sending or first zone Z1 or the associated first program has no access rights, implemented via the memory protection device SSE, that is, neither reading, writing nor executing.
  • An exchange buffer memory area TB1a, TB2b, B3 ′′ is provided for the exchange of data from the transmitting zone Z1, the first zone Z1 to the receiving zone, or the second zone Z2.
  • the sending or first zone Z1 or first program has the following access rights for the exchange buffer memory area TB1a, TB2b, B3 “, implemented via the memory protection device SSE: Write.
  • the receiving or second zone Z2 or second program has the following access rights for the exchange buffer memory area TB1a, TB2b, B3 “, implemented via the memory protection device SSE: Read.
  • the following procedure results for the exchange of data between the sending zone Z1 and the receiving zone Z2 and use or forwarding in the receiving zone Z2.
  • the data from the first buffer memory area TB1b, B3 ‘from the sending zone Z1 are written into the exchange buffer memory area TB1a, TB2b, B3 ′′.
  • the data from the receiving zone Z2 are then validated by read access to the exchange buffer memory area “TB1a, TB2b, B3” (validity check). If the data are valid, they are evaluated as trustworthy by the receiving zone Z2 and copied into the second buffer memory area TB2a, B1_2 for the receiving zone Z2.
  • the further use and forwarding of trustworthy data takes place starting from the second buffer memory area TB2a, B1_2 for the receiving zone Z2 in the receiving zone Z2.
  • the method described must be used for the exchange of data from the untrustworthy zone Z1 into the trustworthy zone Z2.
  • this procedure is optional.
  • an optional further exchange buffer memory TB2b, B1_1 is also provided, to which a program in the trusted zone Z2 only has write access and the receiving zone Z1 only has read access. Otherwise, the exchange process proceeds as described.
  • the access rights management (with regard to read rights, write rights, execution rights) to the buffer memories (first buffer memory area TB1b, B3; second buffer memory area TB2a, B1_2; exchange buffer memory area TB1a, TB2b, B3 ”) is carried out by the memory protection device SSE.
  • the execution rights for each zone Z1, Z2 are to be prevented.
  • the configuration of the memory protection device SSE and thus the access rights to the respective buffer types and the assignment of zones Z1, Z2 takes place statically and authentically for the boot process. This means that the configuration cannot be changed during runtime or after the initial configuration after booting.
  • any access to one of the buffers (first buffer memory area TB1b, B3 ‘; second buffer memory area TB2a, B1_2; exchange buffer memory area TB1a, TB2b, B3”) always takes place via the memory protection device SSE.
  • the method further comprises: Separation 290 of computing time resources for different application programs AP1, AP2 and / or instances of application programs, in particular allocation of computing time resources for different application programs and / or instances of application programs , depending on the at least two zones Z1, Z2.
  • the method further comprises: using 292 an operating system BS for embedded systems, in particular a lightweight embedded operating system BS, to allocate computing time resources for different application programs AP1, AP2 and / or instances AP1J1, AP2J2 of application programs, In particular, an operating system BS is assigned to each computing core of the computing device 100, 100a, see FIG. 4.
  • the method further comprises: Use 294 of a supervisor SV for embedded systems, see FIG. 5, in particular a lightweight embedded supervisor SV, for assigning computing time resources for different application programs and / or instances of application programs, with a supervisor SV being assigned in particular to each computing core 102c (FIG. 5) of the computing device.
  • a supervisor SV for embedded systems, see FIG. 5, in particular a lightweight embedded supervisor SV, for assigning computing time resources for different application programs and / or instances of application programs, with a supervisor SV being assigned in particular to each computing core 102c (FIG. 5) of the computing device.
  • the operating system BS and / or the supervisor SV an allocation of computing time resources, preferably only, for predefined tasks (application programs and / or instances of application programs and / or parts thereof), in particular using a static (not changeable) task list, executes or executes.
  • predefined tasks application programs and / or instances of application programs and / or parts thereof
  • static (not changeable) task list executes or executes.
  • only predefined tasks can be scheduled, which further increases security.
  • the operating system BS (Fig. 4) and / or the supervisor SV (Fig. 5) an allocation of computing time resources depending on a) repeated, in particular periodically repeated, interrupt requests (interrupt requests, e.g. from timer -Interrupts) and / or b) executes event-driven interrupt requests, in particular tasks being activated from at least one interrupt service routine (ISR, a computer program that is executed when an interrupt request occurs).
  • ISR interrupt service routine
  • ISR interrupt service routine
  • configuration data for at least one memory protection device M1, M2, SSE are changed, in particular in a hardware-controlled manner.
  • the Lightweight Embedded OS BS (Fig. 4) or the Lightweight Embedded Supervisor SV (Fig. 5), for example, can coordinate and / or orchestrate ("Scheduling") (proxy) functionalities (tasks) to be executed cyclically or on an event basis. ).
  • the Lightweight Embedded OS BS and the Lightweight Embedded Supervisor in particular have at least one of the following properties: a) Minimization of the attack surface by reducing complexity (code size, functionality, flexibility, etc.) to the minimum b) Scheduling of only predefined tasks (static task list, no dynamic task list possible), scheduling is based e.g. on ISR with e.g. cyclic interrupt requests (IRQ), e.g. timer IRQ and / or event-based IRQs - e.g.
  • IRQ cyclic interrupt requests
  • a hardware-controlled switch to supervisor mode is preferred: e.g. switch to static configuration data set for the supervisor Mode, preferably switching between static configuration data sets (eg for user modes) is only possible in supervisor mode, i ) more preferably, before activating a task, there is a switchover from supervisor mode to user mode, with tasks (e.g. parts of (instances of) application programs) being carried out in user mode, with in particular no switchover between (static) Configuration data sets in the user mode or in tasks is possible.
  • tasks e.g. parts of (instances of) application programs
  • the method further comprises, see FIG. 2K: Monitoring 300, in particular by means of the operating system BS (FIG. 4) and / or the supervisor SV (FIG. 5), at least one of the following elements, in particular for a potential compromise: a) first zone Z1, b) an application program AP1 assigned to the first zone Z1, c) an instance AP1J1 of an application program AP1 assigned to the first zone Z1, the monitoring 300 in particular comprising: evaluation 302 (FIG.
  • a stack memory (“stack”) and / or evaluation 304 of a program counter ("program counter", PC), preferably evaluating 302 of the stack memory and / or evaluating 304 the program counter before activation of the application program and / or the instance of the Application program takes place.
  • program counter program counter
  • the method further comprises, see FIG. 2L: monitoring 300, see above for FIG. 2K, and initiation 305 of an error reaction, in particular if the monitoring 300 suggests a potential compromise.
  • the error reaction or the initiation 305 of the error reaction has at least one of the following elements, see FIG. 2M: a) Relocation of the first zone Z1 and / or the computing core 102b assigned to the first zone Z1 (FIG . 1) into a safe state, in particular by deactivating 305a of the computing core 102b assigned to the first zone Z1 and / or resetting 305b of the computing core 102b assigned to the first zone Z1 and / or placing 305c in an error mode, b) generating 305d of an error entry FE and / or c) Forwarding 305e of a fault entry or the fault entry to an attack detection system, in particular an intrusion detection system.
  • the IDS can, for example, be arranged internally and / or externally with respect to the computing device 100, 100a.
  • the IDS can also have a distributed implementation, for example first partial functionalities (such as IDS sensors and possibly an IDS master) being implemented or being executed on one or the computing device or at least one computing core of the computing device, and where in particular other parts or further partial functionality (s) are optionally implemented in another device, for example a backend.
  • the backend can, for example, also be designed to implement at least one of the following aspects: a) in-depth expert analysis, b) artificial intelligence (Kl), c) machine learning (ML), etc ..
  • the computing device 100, 100a at least temporarily carries out a cold start 310, with data and / or program code being loaded from a non-volatile memory 1032 (FIG. 3) in particular during the cold start 310 , and the computing device 100, 100a at least intermittently executes a warm start 312 (FIG. 2N), with data and / or program code being loaded from an at least intermittently energized, volatile memory 1030 (FIG. 3), in particular during the warm start 312, with in particular During the cold start 310 (FIG. 2N) at least one memory protection device or the at least one memory protection device is configured, cf. step 311 from FIG. 2N, and / or where in particular (also) the at least one memory protection device is configured during the warm start 312, cf. Step 313 of Figure 2N.
  • the method further comprises, see FIG. 20 (number "2", letter “O"): Allocation 212a of computing time resources for different application programs and / or allocation 212b of computing time resources for instances of application programs, wherein the supervisor SV and / or a dem Supervisor SV functionality is implemented at least partially by means of the supervisor instance SVI (FIG. 1).
  • the method further comprises, see FIG. 2P: Checking 320 an integrity and / or authenticity of configuration data KD that control the operation of at least one memory protection device, in particular by means of at least one of the following elements: a) Verification 322 a program code that can be used for the configuration of the at least one memory protection device, b) verification 324 of the configuration data, c) persistence 326 of a program code that can be used for the configuration of the at least one memory protection device, d) persistence 328 of the configuration data.
  • the persistence 326, 328 can include, for example, providing the program code that can be used for the configuration of the at least one memory protection device or the configuration data in a read-only memory, e.g. a ROM or an OTP (one time programmable memory).
  • a read-only memory e.g. a ROM or an OTP (one time programmable memory).
  • the method further comprises, see FIG. 2Q: at least temporarily executing 330 a secure boot method and / or at least temporarily executing 332 a method for tamper detection during runtime (RTMD, runtime manipulation detection) , in particular by at least one computing core of the computing device 100, 100a.
  • the methods 330, 332 can include, for example, the comparison of an actually existing memory content of at least part of the memory 1030, 1032 with a predeterminable reference memory content, the comparison also including, for example, a hash value formation and / or use of CMAC (cipher-based message authentication code) method and / or use of signatures or signed hash values.
  • CMAC cipher-based message authentication code
  • the method further comprises, see FIG. 2R: controlling 340 an access of a program or application program AP1, AP2 to at least one of the following elements as a function of at least one zone Z1, Z2: a) internal Interface, in particular software interface, of the computing device, b) internal and / or external hardware interface of the computing device, c) hardware security module and / or cryptography module for executing cryptographic functions, d) peripheral devices of the computing device, in particular special function register of at least one peripheral device, e) internal Interfaces of a target system for the computing device, in particular a control device, f) external interfaces of a target system for the computing device, in particular a control device, g) addressing elements for communication protocols, in particular on at least one layer of the ISO / OSI layer model.
  • the optional step 342 according to FIG. 2R indicates, by way of example, a (further) execution of the relevant application program in the zone assigned to it.
  • the method further has at least one of the following elements, see FIG. 2S: a) introduction 350 of at least one additional, in particular not already existing, zone, b) shifting 352 of functionalities from a first computation core 102a to at least one further computing core 102b of computing device 100, 100a, c) executing 354 a communication between at least two zones using a main memory, in particular integrated into the computing device, d) defining 360, see FIG. 2T, at least one trustworthy zone and , optionally, monitoring 362 at least one further, in particular untrustworthy, zone by at least one application program assigned to the trusted zone.
  • FIGS. 6 to 21 which - according to further preferred embodiments - can be combined individually or in combination with at least one of the embodiments described above.
  • FIG. 6 schematically shows aspects of an interrupt routine ISR1 according to further preferred embodiments, as they are, for example, at least temporarily performed by at least one computing core 102a, 102b, ... of computing device 100, 100a are executable.
  • the lightning bolt IRQ in Fig. 6 symbolizes an occurring interrupt request, as it can be generated, for example, cyclically (for example, predeterminable by timer module (timer)) and / or event-controlled (for example arrival of a message at a communication interface).
  • the interrupt routine ISR1 is then executed, which has at least one of the following elements: e1) at least temporarily storing a context of the task or program interrupted by the interrupt request IRQ, e.g.
  • the stack memory can e.g. in a predeterminable area of the RAM 1030, e2) identifying a task to be executed subsequently, e3) switching from a current operating mode, e.g. supervisor mode, to another operating mode, e.g. user mode, e4) restoring the task for the identified zone.
  • a current operating mode e.g. supervisor mode
  • another operating mode e.g. user mode
  • interrupt routine ISR1 can be used, for example, by the operating system BS (FIG. 4), in particular in the case of an inter-core zone separation.
  • FIG. 7 schematically shows aspects of an interrupt routine ISR2 according to further preferred embodiments, such as can be executed, for example, at least temporarily by at least one computing core 102a, 102b, ... of computing device 100, 100a.
  • the lightning symbol IRQ 'in Fig. 7 symbolizes an interrupt request that occurs, as it can be generated, for example, cyclically (e.g. predeterminable by timer module (timer)) and / or event-driven (e.g. arrival of a message at a communication interface).
  • the interrupt routine ISR2 is then executed, which has at least one of the following elements: eT) at least temporarily storing a context of the task or program interrupted by the interrupt request IRQ ', for example on the stack, optionally: e5) executing an evaluation e.g. the stack memory (cf. e.g. step 302 from FIG. 2K) and / or the program counter (cf. e.g. step 304 from FIG.
  • the switchover can also take place, for example, address-based, e.g. using CAN ID, VLAN ID, MAC address, etc.), e8) Switchover from a current operating mode, e.g. supervisor mode, to another operating mode , e.g. User Mode, e9) Restoring a context for the subsequent task.
  • a current operating mode e.g. supervisor mode
  • another operating mode e.g. User Mode
  • the interruption routine ISR2 according to FIG. 7 can be used, for example, by the supervisor SV (FIG. 5), in particular in the case of an intra-core zone separation.
  • FIG. 8 schematically shows a flowchart according to further preferred embodiments, wherein the reference numeral 310 ′ denotes exemplary aspects of a cold start of the computing device 100, 100a, and wherein the reference numeral 312 ′ denotes exemplary aspects of a warm start of the computing device 100, 100a.
  • a test pattern for verification of the contents of RAM 1030 (Fig. 3) is not available.
  • warm start 312 ' for example, a test pattern is available for verification of the contents of RAM 1030 (Fig. 3).
  • a test pattern or pattern can be written into the volatile memory, which is supplied in particular in a power-down mode, as part of a cold start to be run through at least once. Because of the supply mentioned, the test pattern or pattern mentioned is thus retained in the inherently volatile memory.
  • this (RAM) pattern is checked in at least one, in particular every, start cycle by a system state machine (state machine that can be used in further preferred embodiments, for example, to control system states), and in particular, depending on the existence of the Test pattern a cold start (e.g. if (RAM) pattern is not available) or a warm start (e.g. if the (RAM) pattern is available).
  • the integrity and authenticity of the volatile memories supplied in the power-down mode or their data and functionalities contained or located therein e.g. computing core 102c and / or configuration data of the memory protection device, in particular for the first and / or second Zone and / or a program code
  • the integrity and authenticity of the volatile memories supplied in the power-down mode or their data and functionalities contained or located therein e.g. computing core 102c and / or configuration data of the memory protection device, in particular for the first and / or second Zone and / or a program code
  • Previous cold starts secure boot and / or starting from OTP memory - see above
  • invalid manipulation of the data and functionalities in the supplied volatile memory in power-down mode, as well as the RAM pattern implies an at least temporary supply interruption and thus a deletion of the volatile memory (RAM pattern, etc.) supplied in power-down mode .).
  • the system state machine would accordingly initiate a cold start (secure boot and / or starting from OTP - see above) as part of the start cycle due to the missing RAM pattern, with which the integrity and authenticity of the power-down Mode supplied volatile memory or its data and functionalities is guaranteed before their use or execution.
  • test pattern exists, e.g. in the context of a warm start
  • selected time-critical software instances are not checked before they are executed (e.g. in particular no secure boot), but rather only at runtime / after they have been executed.
  • This advantageously accelerates a startup time for time-critical software instances during a warm start.
  • the integrity and authenticity during the warm start is thus advantageously ensured implicitly in further preferred embodiments even without an explicit check during the warm start by the availability of the test pattern (and thus the check during the previous cold start).
  • non-time-critical components can also be checked explicitly during the warm start prior to their execution (e.g. by means of a secure boot process).
  • Block 102a_1 symbolizes, for example, the first computing core 102a of the computing device (FIG. 3) as "root of trust", that is, comparable to a hardware security reference analogous to a TPM (trusted platform module) or a hardware security module (HSM), represented by block 102a_2 a boot manager (system program that controls the loading and / or execution of further system and / or application programs) associated with the computing core 102a.
  • Block 102a_3 represents execution of program code associated with zone Z2 and computation kernel 102a.
  • Block 110 represents a hardware security module.
  • Block 111 represents one Boot manager associated with computing kernel 102c.
  • Block 112 represents an execution of program code associated with zones Z1, Z2 and computing core 102c (which is assigned to both zones Z1, Z2 by way of example and as already described several times above).
  • Block 113 represents a boot manager associated with the computing kernel 102b.
  • Block 114 represents execution of program code associated with zone Z1 and with computation kernel 102b.
  • Block 115 represents a boot manager associated with the computing kernel 102n.
  • Block 116 represents execution of program code associated with zones Z1, Z2 and computation kernel 102n.
  • Arrow a1 symbolizes a boot process (start-up of the computing device 100a, e.g. from a completely deactivated state).
  • Arrow a2 symbolizes a configuration of at least one memory protection device, in particular a central memory protection device M5_1, M5_2,..., M5_8 assigned to the bus system 101 (FIG. 3).
  • Arrow a3 symbolizes a start of the boot manager for the computing core 102c, see also block 111.
  • Arrow a4 symbolizes a configuration of at least one dedicated memory protection device M3 (FIG. 3) for the computing core 102c.
  • Arrow a5 symbolizes the start of an execution 112 of program code by the computing kernel 102c.
  • Arrow a6 symbolizes an optional verification of the computing core 102c, e.g. in the form of an RTMD.
  • the optional verification of the configuration data of the memory protection device M3 can be carried out in particular by means of cryptographic methods, e.g. based on CMACs and / or signed hash values.
  • Arrow a7 likewise symbolizes an optional verification of the computing core 102c, in the context of a cold start 310 '.
  • the optional verification a7 can be carried out by means of cryptographic methods, for example based on CMACs and / or signed hash values.
  • Arrow a8 symbolizes a start of the boot manager for computing kernel 102c, similar to arrow a3, see also block 111.
  • Arrow a9 symbolizes, in particular similar to arrow a4, the configuration of the at least one dedicated memory protection device M3 (FIG. 3) for computing kernel 102c .
  • Arrow a10 symbolizes the start of execution 112 of program code by the computation kernel 102c, similar to arrow a5.
  • Arrow a11 symbolizes an optional verification of several, preferably all, computing cores 102a, 102b, 102n.
  • Arrow a12 symbolizes a start of the
  • Boot manager for the computing core 102n see also block 115.
  • Arrow a13 symbolizes the configuration of at least one dedicated memory protection device for the computing core 102n.
  • Arrow a14 symbolizes the start of an execution 116 of program code by the computing kernel 102n.
  • Arrow a15 symbolizes a start of the boot manager for the computing kernel 102b.
  • Arrow a16 symbolizes the configuration of at least one dedicated memory protection device for the computing core 102b.
  • Arrow a17 symbolizes the start of an execution 114 of program code by the computing kernel 102b.
  • Arrow a18 symbolizes a start of the boot manager for the computing core 102a.
  • Arrow a19 symbolizes the configuration of at least one dedicated memory protection device for the computing core 102a.
  • Arrow a20 symbolizes the start of execution 102a_3 of program code by computing core 102a.
  • FIG. 9 schematically shows aspects of an interrupt routine ISR3 in accordance with further preferred embodiments, such as can be executed, for example, at least temporarily by at least one computing core 102a, 102b, ... of computing device 100, 100a.
  • the lightning bolt IRQ ′′ in FIG. 9 symbolizes an interrupt request that occurs, as can be generated, for example, cyclically (for example, predeterminable by a timer) and / or software-based (for example called up by an application program).
  • the interrupt routine ISR3 is executed, which has at least one of the following elements: eT) at least temporarily storing a context of the task or program interrupted by the interrupt request IRQ ", optionally: e5 ') executing an evaluation, e.g.
  • e10 switching the context to a next task (e.g. depending on a preferably static task list), e11) switching from a current operating mode, e.g. Supervisor Mode, to another operating mode, e.g. User Mode, e12) Restoring the task for the identified zone.
  • a current operating mode e.g. Supervisor Mode
  • another operating mode e.g. User Mode
  • FIG. 10 schematically shows a computing core 102a according to further preferred embodiments, which is an operating system BS and / or supervisor SV (similar to FIG. 5, not shown in FIG. 10) and to which two zones Z1, Z2 are assigned.
  • the computing core 102a can be used, for example, for a network switch, for example to send and / or receive Ethernet data packets.
  • Corresponding instances of application programs are identified by the reference symbols AP3J1 (receiving Ethernet packets, execution in zone Z1), AP3J2 (receiving Ethernet packets, execution in zone Z2), AP4J1 (sending Ethernet packets, execution in zone Z1), AP4J2 (sending of Ethernet packages, version in zone Z2).
  • a RAM 1030 is assigned to the computing core 102a, which in further preferred embodiments can be divided, for example, in a manner comparable to FIG. 5.
  • a switching engine eg coupling network
  • TCAM ternary content-addressable memory
  • FIG. 11 schematically shows two computing cores 102a, 102b according to further preferred embodiments, the first computing core 102a being assigned to a first zone Z1 and the second computing core 102b being assigned to a second zone Z2.
  • An operating system BS is assigned to each of the two computing cores 102a, 102b.
  • the various application programs have, for example, at least one of the following elements: a) programs for carrying out an examination of data packets, in particular for deep packet inspection, DPI, b) programs for diagnosis, c) programs for carrying out updates, in particular by means of FOTA (firmware over the air) techniques (for example by means of the data interface 1008, FIG. 22), d) programs for attack detection and attack defense (intrusion detection and prevention).
  • corresponding second instances I2 of the application programs described above in relation to the first zone Z1 are assigned to the second computation core 102b and the second zone Z2.
  • the memory protection device SSE can be used for controlling the reading rights and / or writing rights and / or execution rights of corresponding application programs or instances of the various zones.
  • the configuration described above by way of example with reference to FIG. 11 can efficiently provide a particularly secure system for examining data packets or for attack detection and attack defense, for example for electronic control devices and / or embedded systems and / or loT systems and the like, with the assignment of the instances 11, I2 of the application programs to the zones Z1, Z2 particularly advantageously, for example, contexts for the execution can be provided with different levels of trust.
  • FIG. 12A schematically shows aspects of an interrupt routine ISR4 according to further preferred embodiments, such as can be executed, for example, at least temporarily by at least one computing core 102a, 102b,... Of computing device 100, 100a.
  • the lightning bolt Rx in FIG. 12A symbolizes an interrupt request that occurs, such as can be generated in an event-controlled manner, in the present example, when a message is received, for example a CAN (Controller Area Network) message.
  • CAN Controller Area Network
  • the interrupt routine ISR4 is then executed, which has at least one of the following elements: e20) at least temporarily storing a context of the task interrupted by the interrupt request Rx, in particular a send task ("Tx task"), for example for sending messages, or program, optionally: e21) Execution of an evaluation, for example of the stack memory (see, for example, step 302 from FIG. 2K) and / or the program counter (see, for example, step 304 of FIG. 2K), e22) determination of a zone with which a received data frame (e.g. the said received CAN message) is associated, e23) switching the context to the zone determined in step e22, e24) switching from a current operating mode, e.g.
  • supervisor mode to another operating mode, e.g. user mode, e25 ) Calling a handling routine for receiving messages ("Receive (Rx) handler"), for example an application program or a part one Application program that processes the received message, e26) Restoring the task (e.g. send task) for the identified zone.
  • Received (Rx) handler for example an application program or a part one Application program that processes the received message
  • transmission tasks that is to say tasks or application programs or parts of application programs for transmitting messages, are planned (“scheduling”).
  • interrupt requests that characterize the receipt of a message are processed with a higher priority than other interrupt requests that are generally triggered, for example, by timers and / or application programs or software become.
  • incoming messages are received simultaneously or within a predeterminable first time range
  • Prioritized interrupt requests for example depending on the source of the interrupt request (incoming message, timer, software) and / or depending on one or more other or further criteria.
  • prioritization can be carried out, for example, by a control device for interrupt requests (English: Interrupt Controller).
  • the context switching compare for example step e23 of FIG. 12A, can take place exclusively in a predeterminable operating mode, in particular in the supervisor mode.
  • FIG. 12B schematically shows aspects of an interrupt routine ISR5 according to further preferred embodiments, such as can be executed, for example, at least temporarily by at least one computing core 102a, 102b,... Of computing device 100, 100a.
  • the lightning bolt TIM_SW in FIG. 12B symbolizes an interrupt request that occurs, as it is, for example, by a timer or an application program or software in general can be generated.
  • the interrupt routine ISR5 is then executed, which has at least one of the following elements: e30) at least temporarily storing a context of the task interrupted by the interrupt request Rx, in particular a send task ("Tx task"), for example for sending messages, or program, optionally: e31) Execution of an evaluation, eg of the stack memory (cf. eg step 302 from FIG. 2K) and / or the program counter (cf. eg step 304 from FIG. 2K), e32) switching the context to a next one Send task (e.g. according to a static task list in particular), e33) Switching from a current operating mode, e.g. supervisor mode, to another operating mode, e.g. user mode, e34) Restoring the task (e.g. sending tasks) for the identified zone.
  • a send task e.g step 302 from FIG. 2K
  • the program counter cf. eg step 304 from FIG. 2K
  • e32 switching the context
  • FIG. 13 schematically shows a simplified block diagram of aspects of a computing device 100b according to further preferred embodiments.
  • the computing device 100b has, by way of example, four computing cores K1, K2, K3, K4, of which the first computing core K1 is designed to process communication messages, in particular CAN messages. Therefore, in further preferred embodiments, the first computing core K1 according to FIG. 13 can also be referred to as “CAN core”.
  • the further computing cores K2, K3 are provided for executing (possibly different instances of) application programs and in further preferred embodiments can therefore also be referred to as “application cores” K2, K3.
  • the fourth computation core K4 according to FIG.
  • Ethernet core or ETH core or “ETH core” K4 is designed to process Ethernet communication messages and can therefore, in further preferred embodiments, also be referred to as the Ethernet core or ETH core or “ETH core” K4.
  • a first supervisor SV1 in particular a CAN lightweight supervisor, is assigned to the first computing core K1
  • a second supervisor SV2, in particular an ETH (Ethernet) lightweight supervisor is assigned to the fourth computing core K4.
  • the first computing core K1 is assigned to two zones Z1, Z2.
  • the fourth computing core K4 is also assigned to two zones Z1, Z2.
  • an application program for sending and / or receiving CAN messages is assigned to the first computation core K1, the reference numeral 11 in FIG. 13 denoting a first instance (or a program or subroutine or proxy) of this application program, which first instance 11 is assigned to the first zone Z1 and is designed to receive CAN messages.
  • the reference symbol I2 denotes a second instance (or a program or subroutine or proxy) of this application program, which is assigned to the second zone Z2 and is designed to receive CAN messages.
  • the reference symbols I3, I4 denote corresponding entities (or a program or subroutine or proxy) for sending or receiving CAN messages, which are each also assigned to one of the two zones Z1, Z2.
  • the interrupt requests Rx, TIM_SW described above by way of example with reference to FIGS. 12A, 12B can be processed by the first computing core K1, for example by executing a corresponding interrupt routine ISR4 (FIG. 12A) or ISR5 (FIG. 12B).
  • the fourth computing core K4 is assigned an application program for sending and / or receiving Ethernet messages
  • the reference symbol 11 'in FIG. 13 denoting a first instance (or a program or subroutine or proxy) of this application program, which first instance 11 'is assigned to the first zone Z1 and is designed to receive Ethernet messages.
  • the reference symbols I3 ', I4' denote corresponding entities (or a program or subroutine or proxy) for sending or receiving Ethernet messages, which are each also assigned to one of the two zones Z1, Z2.
  • the two zones Z1, Z2 are separated within the computing cores K1, K4 using at least one memory protection device SSE1, SSE4.
  • the two application cores K2, K3 are designed to execute application programs which or their individual instances (or a program or subroutine or proxy) are indicated in FIG. 13 as rectangles within the relevant application cores K2, K3 For the sake of clarity, however, are not specified.
  • the second computing core K2 is assigned to the second zone Z2
  • the third computing core K3 is assigned to the first zone Z1.
  • the computing device 100b has a volatile memory, in particular a working memory (RAM) 1030b, which is divided into different areas, in particular different buffer memory areas, for example in a manner comparable to the illustration according to FIG. K3, K4 or their zones Z1, Z2 are assigned.
  • RAM working memory
  • a first area B1 of the main memory 1030b of the computing device 100b according to FIG. 13 is assigned to the first computing core K1, a first subarea B1_1 being assigned to the first zone Z1 and a second subarea B1_2 to the second zone Z2.
  • a comparable division into corresponding areas or sub-areas B4, B4_1, B4_2 is also possible for the fourth computation kernel K4 in further preferred embodiments.
  • further areas B2, B3 of the main memory 1030b can be assigned to the application cores K2, K3, for example.
  • the area B2 can be further divided into a trustworthy area B2 'and a non-trustworthy area B2 ".
  • the same can also apply to the third application core K3, compare the reference symbols B3', B3".
  • one or more further memory protection devices which are collectively designated by the reference symbol SSE 'in FIG. 13, can be provided in order to achieve a respective separation in accordance with to implement preferred embodiments with regard to, for example, read rights and / or write rights and / or execution rights.
  • the computing device 100b according to FIG. 13 can, for example, provide the functionality of a gateway 432, that is to say a network coupling element which, for example, connects a CAN bus (cf. CAN Core K1) to an Ethernet network (cf. ETH Core K4 ) can pair.
  • the first computing core K1 can assume the function of a so-called high-speed routing engine for CAN messages, and / or the fourth computing core K4 the function of a so-called high-speed engine for Ethernet messages.
  • FIG. 14 schematically shows a flowchart according to further preferred embodiments, which exemplarily illustrates the processing of interrupt requests, for example when messages, in particular CAN messages, are received.
  • the block ISR6 represents an example of an interrupt routine that is used, for example, in at least one of the following
  • Interrupt requests can be executed: a) receiving a message (“Rx"), b) signaling a timer ("timer”), c) software-generated interrupt request (“SW”).
  • the block T_RX_Z1 exemplarily represents a task (eg part or instance of an application program) which is assigned to the zone Z1 and is executed when a message is received ("Rx"), comparable to the instance 11 of the first computing core K1 of the computing device 100b according to FIG 13.
  • the block T_RX_Z2 represents, for example, a task that is assigned to the zone Z2 and is executed when a message is received, comparable to the instance I2 of the first computing core K1 of the computing device 100b according to FIG Zone Z1 is assigned and is executed when a message is sent, comparable to the instance I3 of the first computing core K1 of the computing device 100b according to FIG. 13.
  • the block T_TX_Z2 represents, for example, a task that is assigned to zone Z2 and is executed when a message is sent, comparable to the instance I4 of the first computing core K1 of the computing device 100b according to FIG 13th
  • the arrow a30 represents an interrupt request, triggered by the receipt of a (CAN) message, which in particular interrupts the processing of a currently running task, compare the send task T_TX_Z2, compare arrow a30 '.
  • the receiver task T_RX_Z1 is called by the interrupt routine ISR6, compare arrow a31.
  • the receiver task T_RX_Z1 After the execution of the receiver task T_RX_Z1, it branches, preferably by means of a software interrupt request (software interrupt) a32, again to the interrupt routine ISR6, which then continues the previously interrupted send task T_TX_Z2, compare arrow a33.
  • a software interrupt request software interrupt
  • the interrupt routine ISR6 calls the send task T_TX_Z1, see arrow a35, which leads to an interruption a34 'of the previously running send task T_TX_Z2.
  • FIG. 14 and the preceding descriptions clearly show how different program parts (tasks) which can be executed by a computing device according to the embodiments and which, according to the principle according to the embodiments, different zones Z1, Z2, ... (more than two zones are also possible according to further preferred embodiments) can be assigned, can be executed or how their execution can be controlled, for example, by an interrupt routine ISR6, which can for example be part of an operating system BS and / or supervisor SV.
  • ISR6 interrupt routine
  • FIG. 15 schematically shows a simplified block diagram of aspects according to further preferred embodiments, the present example depicting an application that relates to an example zone transition ZT, that is, the transfer of data from a first zone according to preferred embodiments to a second zone according to preferred embodiments Has.
  • the first computing core K1 according to FIG. 15 corresponds to the CAN core K1 already described above with reference to FIG. 13, and the further computing cores K2, K3 from FIG. 15 correspond to the application kernels K2, K3 according to FIG the areas B1, B2, B3 of the main memory 1030b or their sub-areas.
  • the arrow A1 represents the receipt of a CAN message which triggers processing by the instance 11 (or a program or subroutine or proxy) of a corresponding application program of the first processor core K1.
  • Instance 11 which is assigned to the first zone Z1, transmits data of the received CAN message or data derived therefrom via the main memory (in particular via the further exchange buffer memory area B3 ”), compare the arrow A2, to an instance I5 (or A program or sub-program or proxy) of an application program for processing such data, which is assigned to the first zone Z1 and can be executed by the third computing core K3, compare the arrow A3.
  • Reference symbol I6 from FIG. 15 denotes an instance of an application program for examining data packets, in particular deep packet inspection, DPI, which examines the received data (which are in the exchange buffer memory area B3 ") more closely and then writes them to sub-area B3" of the main memory 1030b, compare arrow A5. Then the further instance I6 'of the DPI application program, which is executed on the second computing kernel K2 and which is assigned to the second zone Z2, reads the data from the sub-area B3 ", which corresponds to the zone transition ZT already mentioned above, compare arrow A6.
  • DPI deep packet inspection
  • a particularly in-depth (in the sense of a DPI) payload analysis is carried out, for example, by the instance I6 '("Z2-DPI-Proxy", that is to say the proxy assigned to the second zone Z2 for executing DPI methods), where instance I6 (“Z1-DPI proxy”, ie proxy assigned to the first zone Z1 for executing DPI processes) is preferably responsible for copying the data in B3 “.
  • CAN 15 can be used for at least one of the following applications: a) diagnosis using CAN messages, b) DPI applied to CAN messages, c) formation of a proxy, eg a proxy for a Communication and / or diagnostic protocol or the like, d) Routing from e.g. a first CAN bus to e.g. a second CAN bus, in particular with the inclusion of application programs (this enables, for example, processing of the CAN messages to be routed, in particular an analysis and / or modification).
  • FIG. 16 schematically shows a simplified block diagram of aspects according to further preferred embodiments, based on the representations of FIG. 13 and FIG first zone Z1 according to preferred embodiments into a second zone Z2 according to preferred embodiments.
  • the zone transition ZT 'in the scenario according to FIG. 16 takes place starting from the Ethernet core K4 to the CAN core K1, according to the arrows A11 to A20.
  • FIG. 17 shows an example of a configuration comparable to FIG.
  • FIG. 18 schematically shows a simplified block diagram of aspects according to further preferred embodiments, based on the representations of FIGS. 13 and 15, an application case in which a hardware security module HSM is used is shown here as an example.
  • the hardware security module HSM is integrated into the computing device (not denoted in FIG. 18, see e.g. reference numeral 100 from FIG. 1), which among other things also has the second computing core K2 ', and is designed to carry out cryptographic functions.
  • the cryptographic functions can include, for example, the storage of (secret) keys and / or the formation of hash values and / or signatures and the like.
  • the hardware security module HSM represents an independent (“on-chip") module which is preferably arranged on the same semiconductor substrate or die (chip) as the computing device.
  • the hardware security module HSM preferably has its own computing core (not shown) and possibly its own memory, etc.
  • a crypto stack KS is provided which can be used for communication between the computing cores of the computing device and the hardware security module HSM.
  • this crypto stack KS is only implemented on the computation kernel K2 ', since the computation kernel K2' represents, for example, the only computation kernel of the computing device that is exclusively assigned to the trustworthy zone Z2.
  • the computing kernel K2 ' can thus be viewed as the “most secure core”, that is to say as the most secure computing kernel.
  • the arrows A31, A32, A33, A34, A35, A36 represent, for example, the following steps: receiving (A31) an Ethernet message, storing (A32) the received message in the first buffer memory area B3 ', loading (A33) this message by a Application program of the third processor core K3, processing (A34) the loaded message by the third processor core K3, writing (A35) the data obtained during processing in the exchange buffer memory area B3 ′′, loading (A36) the written data from the exchange buffer memory area B3 "by a program or application program that can be executed on the second computing kernel K2.
  • the second computing core K2 processes the loaded data, in particular also using the hardware security module HSM, see arrow A37.
  • the processing A37 can include, for example, an encryption of data.
  • the processed data A38 is written in the second buffer memory area B1_2 (A38).
  • the data is then loaded by the instance of the CAN core K1 from the second buffer memory area B1_2 (A39) and sent to the CAN bus.
  • FIG. 19 schematically shows a simplified block diagram of aspects according to further preferred embodiments, based on the illustration of FIG. 18, an application case being shown here as an example in which, for example, a firmware update, in particular from FOTA (firmware over the air) - Type that is executable.
  • data can be received via an Ethernet connection, for example by means of the fourth computing core K4, compare arrow A41.
  • An instance IT of a receiving program writes the received data into the first buffer memory area B3 ', see arrow A42.
  • Instances of application programs on the application computing kernel K3 load the data from the first buffer memory area B3 '(A43) and process them (A44).
  • Another instance I7 which is, for example, a first FOTA proxy I7, extracts the data required for the FOTA process from the processed data and writes (A45) the extracted data to the, for example (in particular from the perspective of the second Zone Z2) as untrustworthy exchange buffer memory area B3 ".
  • An instance I8 of an application program which is, for example, a second FOTA proxy and which can be executed on the computing kernel K2" loads the data (arrow A46) from the exchange buffer memory area B3 “.
  • a cryptographic method can then be used by the computation core K2 ′′ are executed on the loaded data, for example a CMAC formation, which advantageously uses the hardware security module HSM, compare the arrow A47.
  • optionally processed data or CMAC values can be stored in an external memory, see arrow A48. Such storage is controlled by the FOTA proxy 18 in further preferred embodiments.
  • the second zone Z2 only has read rights, but in particular no write rights and / or execution rights, to the exchange buffer memory area B3 ′′.
  • the configurations described in 4, 5 apply.
  • ECU image 1033a for at least one computing core or the entire computing device and / or a corresponding control device can also be temporarily stored in the external memory 1033, for example.
  • an application program that can be executed by the second computing core K2 ′′ or a corresponding instance thereof can, for example, check or validate the content of data stored in the external memory 1033.
  • a corresponding memory image 1033a can be distributed to one or more external devices (not shown), compare arrows A49, A50, A51, A52, among others a, for example, block-wise copying of the memory image 1033a from the external memory 1033a into the second buffer memory area B1_2 of the main memory 1030b (A50) and from there to the instance I4 (eg CAN send task).
  • the validation can preferably be carried out based on digital signatures and / or signed hash values.
  • a signed hash value can exist for each ECU image.
  • a signature verification can preferably be carried out via the hardware security module HSM.
  • a CMAC value and / or another value that enables the integrity and / or authenticity of the relevant blocks to be checked can also be carried out during the distribution or copying of the memory image 1033a, preferably again in blocks, for example controlled by corresponding instances of application programs, which run for example on the second computing core K2 ", optionally supported by the hardware security module HSM.
  • the formation and verification of, for example, CMAC values can function in particular as a supplementary integrity and authenticity protection, e.g. for signature verification.
  • a single or every single data packet from the exchange buffer memory area B3 ′′ can be provided with a CMAC value or a truncated CMAC value.
  • FIGS. 20, 21 schematically show flowcharts according to further preferred embodiments, which illustrate by way of example the processing of interrupt requests, for example when messages, in particular CAN messages, are received.
  • the block ISR7 represents an example of an interrupt routine that can be executed, for example, in the event of interrupt requests which signal the receipt of a message ("Rx") ("Rx ISR").
  • the block ISR8 represents an example of an interrupt routine that is used, for example, in at least one of the following
  • Interrupt requests can be executed: a) signaling of a timer ("timer”), b) software-generated interrupt request ("SW ISR").
  • the block RX_H_Z1 represents, for example, a receive handler (eg part or instance of an application program that controls the receipt of a message) that is assigned to zone Z1 and is executed when a message is received ("Rx"), comparable to instance 11 of the first Computing core K1 of computing device 100b according to FIG. 13.
  • the block RX_H_Z2 represents an example of a receive handler (eg part or instance of an application program that controls the receipt of a message) that is assigned to zone Z2 and is executed when a message is received ("Rx"), comparable to instance I2 of the first Computing core K1 of computing device 100b according to FIG. 13.
  • Rx a message is received
  • the block T_TX_ZT represents, for example, a task that is assigned to the zone Z1 and is executed when a message is sent, comparable to the instance I3 of the first computing core K1 of the computing device 100b according to FIG Z2 is assigned and is executed when a message is sent, comparable to the instance I4 of the first computing core K1 of the computing device 100b according to FIG. 13.
  • the arrow a40 represents an interrupt request, triggered by the receipt of a (CAN) message, which in particular interrupts the processing of a currently running task, compare the send task T_TX_Z2 ', compare arrow a40'.
  • the receive handler RX_H_Z1 is called by the interrupt routine ISR7, compare arrow a41. After the execution of the receive handler RX_H_Z1, it returns to the interruption routine ISR7 (e.g. preferably by means of an interrupt request generated by means of software), arrow a42.
  • the send task T_TX_Z1 ' is then carried out, compare arrow a43.
  • this can have the particular advantage that the static configuration (eg corresponding configuration data set) of the memory protection device is already active for the first zone Z1 through the task RX_H_Z1, which preferably also applies to the send task T_TX_Z1 '.
  • This enables the relevant static to be switched over, particularly from a performance point of view Configuration of the memory protection device before the execution of the send task T_TX_Z1 'can be saved.
  • the interrupt routine ISR7 calls the send task T_TX_Z2 ', see arrow a45, which leads to interruption a44' of the previously running send task T_TX_ZT.
  • the static configuration e.g. corresponding configuration data set
  • the sequence then returns to the interrupt routine ISR7, e.g. by means of a software interrupt a46, whereupon the send task T_TX_ZT is continued, see arrow a47.
  • the interruption routine ISR7 according to FIGS. 20, 21 can, for example, have a configuration which is comparable or identical to the configuration ISR4 according to FIG. 12A.
  • a limitation of the access rights to memory 1030a can be used, which enables a zone-wise memory separation, e.g. using mechanisms of known memory protection devices .
  • a zone-wise memory separation can take place in the memory forms mentioned below by way of example: Buffer, for example in the form of a trustworthy buffer memory (e.g. in a shared RAM 1030) and / or in the form of an untrustworthy one Buffer memory (non-trusted buffer (e.g. in the shared RAM 1030), stack (stack memory), data memory (e.g.
  • an exchange of data between different zones (“intra- and / or inter-zone data exchange”) can be implemented, for example, via buffers located in a shared RAM (divided work memory, cf. reference numeral 1030a from FIG. 4).
  • At least one trusted and non-trusted buffer (depending on the application) or buffer areas can be provided per instance 11, I2, I3 (“proxy”) of an application program and per zone, see for example the subregions TB1a, TB1b from FIG. 4.
  • data exchange takes place within a zone or intra-zone communication, in particular exclusively, via trusted buffer or second buffer storage area TB2a (FIG. 4) of this zone.
  • data exchange between zones or inter-zone communication takes place preferably via non-trusted buffers or exchange buffer memory area TB1a located in shared RAM 1030a. If, for example, in further preferred embodiments, data are to be transferred from zone Z1 to zone Z2, they are preferably first copied from a Z1 proxy into the associated Z1 non-trusted buffer or exchange buffer memory area TB1a, TB2b, B ”, from The associated Z2 proxy is verified with regard to its validity and, in the event of valid or trustworthy data with correct content, copied from the Z2 proxy into the Z2 trusted buffer or second buffer memory area TB2a, B1_2.
  • the copying process after successful data verification from Z1 non-trusted buffer or exchange buffer memory area TB1a, TB2b, B3 ”to Z2 trusted buffer or second buffer memory area TB2a, B1_2 is referred to as a zone transition in further preferred embodiments.
  • the verified, trustworthy data located in the Z2 trusted buffer can be processed or forwarded accordingly in further preferred embodiments within Z2, ie the data verification takes place in further preferred embodiments before the zone transition and, if necessary, data usage.
  • a further measure for limiting the attack surface of the computing device according to the embodiments is the limitation of the access rights to runtime according to further preferred embodiments, which in further preferred embodiments can take place, for example, under the control of a corresponding operating system BS or supervisor SV.
  • an AUTomotive Open System ARchitecture (AUTOSAR) BS can function as a basis for the lightweight embedded operating system BS described above by way of example, for example according to FIG. 4, which is reduced to a minimum in terms of its complexity in further preferred embodiments (e.g. via Configuration etc.).
  • an ISR interrupt routine running in the supervisor mode can only switch between the static configuration data sets for the dedicated memory protection device for the relevant computing core.
  • identical static configuration data sets for supervisor mode and user mode of the computing core only allow access to memory and / or runtime that are assigned to a relevant zone, for example the first zone Z1.
  • an ISR running in the supervisor mode cannot perform dynamic reconfiguration of the memory protection device (s); this can in particular be achieved implicitly through a static, integrity and authentic configuration of the Memory protection device (s) during a start cycle, for example during a cold start and / or during a warm start.
  • a task running in user mode which is assigned to the first zone Z1, for example, cannot switch between static configuration data sets of the memory protection device dedicated to a specific computing core, because in further preferred embodiments this switch is only possible in supervisor mode.
  • a task running in user mode which is assigned to the first zone Z1, for example, cannot dynamically reconfigure the memory protection device (s), which in turn can advantageously be achieved implicitly by a static, honest and authentic one provided in further preferred embodiments Configuration of the memory protection device (s) during the start cycle, for example during a cold start and / or during a warm start.
  • a supervisor SV in particular a lightweight embedded supervisor
  • tasks PXY of two zones Z1 and Z2 with different levels of trust are executed on a dedicated computing core 102c, with two different static configuration data sets for Z1 tasks (the first zone Z1 assigned tasks or instances) and Z2 tasks can be used in user mode, as well as, if necessary, another static configuration data set for the supervisor mode, which, for example, controls switching between the two static configuration data sets for the Z1 tasks and the Z2 tasks.
  • any remaining, unused static configuration data set for tasks in user mode can be configured (for example during a cold start and / or warm start) in such a way that it prevents general read, write and execution access to the entire memory, for example the security is further increased.
  • the supervisor mode in particular in the context of an intra-core zone separation, controls a monitoring of an untrustworthy zone Z1, see, for example, the sequence according to FIG. 2M.
  • 3 or more zones Z1, Z2, Z3 can be provided, the first zone Z1 being, for example, a highly trustworthy / confidential zone, the second zone Z2 being e.g. a trustworthy zone, and wherein the third zone Z3 is, for example, an untrustworthy zone.
  • the computing device can, for example, have a microcontroller or be formed by a microcontroller with a corresponding number of computing cores.
  • FIG. 22 Further preferred embodiments relate to an apparatus 1000 for executing the method according to the embodiments, cf. the schematic block diagram according to FIG. 22.
  • the apparatus 1000 has a computing device 1002 with at least one computing core 1002a, the computing core 1002a optionally having at least one memory protection device 1002a 'can be assigned.
  • the device 1000 further has a memory device 1004, which preferably has a volatile memory 1004a, for example a working memory (RAM), and / or a non-volatile memory 1004b, for example a flash EEPROM and / or a ROM and / or an OTP -Storage.
  • a computer program PRG is preferably stored in the ROM 1004b which has commands which, when the program PRG is executed by a computer 1002, cause the computer 1002 to execute the method according to the embodiments.
  • configuration data CFG for the operation of the device 1000 are also stored in the ROM 1004b.
  • These configuration data CFG can, for example, also have one or more configuration data (sets) KD, KD ', KD1, KD2, KD3, KD4 for (the) at least one memory protection device 1002a'.
  • the device 1000 has at least one data bus 1006, which enables data to be exchanged between the computing device 1002 and the storage device 1004.
  • a computer-readable storage medium SM comprising instructions, in particular in the form of a computer program PRG, which, when executed by a computer 1002, cause the computer 1002 to carry out the method according to the embodiments.
  • the device 1000 can preferably have a, preferably bidirectional, data interface 1008 for receiving the data carrier signal DS.
  • the computing device 1002 can also have a configuration in accordance with the computing device 100, 100a, as described above by way of example with reference to, inter alia, FIGS. 1, 3.
  • the or a computing core 1002a of the device 1000 according to FIG. 22 it is also possible for the or a computing core 1002a of the device 1000 according to FIG. 22 to at least temporarily carry out at least some steps of the method according to the embodiments.
  • the device 1000 can also be understood, for example, as a possible target system for the computing device 100, 100a according to the embodiments.
  • the device 1000 also has a hardware security module HSM 'or cryptography module HSM', e.g. for performing cryptographic functions.
  • the hardware security module HSM ' can be used as a supervisor instance SVI.
  • the device 1000 is designed as a microcontroller (English: microcontroller or microcontroller unit (MCU)), in particular as a single microcontroller (single MCU) or as a one-chip system (SoC, system-on-chip), in particular as a single SoC (single SoC).
  • MCU microcontroller or microcontroller unit
  • SoC system-on-chip
  • the device 1000 has a, in particular common, semiconductor substrate 1001, at least one of the following elements being arranged on the, in particular common, semiconductor substrate 1001: a) the computing device having at least one computation core 1002, b) the memory device 1004, c) the data bus 1006, d) the at least one memory protection device 1002a, d) the (optional) hardware security module HSM '.
  • the principle according to preferred embodiments thus advantageously enables the provision of a single MCU system 1 or single SoC system 1, with simultaneous separation in two or more zones Z1, Z2.
  • an exchange of data between the different zones can be carried out, for example, via buffers (buffer memory areas) located in a shared RAM (divided work memory, cf. reference numeral 1030a from FIG. 4) , Exchange buffer memory areas), the shared RAM is advantageously also arranged on the same common semiconductor substrate 1001 as the computing device 1002 or its computing core (s) 1002a and preferably the further components 1006, HSM ', 1002a of the single -SoC systems 1.
  • preferred embodiments enable the "arrangement" of different zones Z1, Z2, for example trustworthy (TZ) and untrustworthy (NTZ) zones, and / or data processing with regard to the data of the different zones Z1, Z2 on the same, preferably single, MCU or SoC system 1.
  • the method and / or the device 100, 100a, 1000 according to the embodiments can be used in a control device, e.g. a control device for a motor vehicle, in particular a control device for an internal combustion engine of a motor vehicle, e.g.
  • a) controlling an operating or operating state transition of the control unit b) enabling or not enabling one or more functions of the control unit and / or another component and / or e.g. the motor vehicle, c) switching to a failure mode and / or emergency operation, d) Making a fault memory entry, e) signaling an operating state to an external unit and / or a user, f) activating an actuator.
  • Further preferred embodiments relate to a use of the method according to the embodiments and / or the device 100, 100a, 1000 according to the embodiments and / or the computer program PRG according to the embodiments for checking at least a partial area of the memory device 1030, 1032, 1004 for changes or changes .
  • Manipulations in particular before, during or after a change of the memory device and / or a computing device 100, 100a, 1002 accessing the memory device from a first operating state to a second operating state, and for controlling an operation, e.g. of a control unit of an internal combustion engine of a motor vehicle as a function the review.
  • FIG. 2U relate to a use of the method according to the embodiments and / or the device according to the embodiments and / or the computer program according to the embodiments for at least one of the following elements: a) Providing 370 confidence limits ( "Trust boundaries") in the computing device 100, 100a (FIG. 1), in particular also within a computing core 102c of the computing device, b) reduction 371 (FIG. 2U) of an attack surface for attacks on the computing device and / or one of its components, c ) Limitation 372 of access rights to memory 1030, 1032, d) Limitation 373 of access rights to peripherals 1034 (Fig. 3), e) Limitation 374 (Fig.
  • 2U of access rights to computing resources (e.g. characterizable by computing time, specification of a computing core), e) Minimization 375 of a Influence of a corrupted component, f) operating 376 a control device, in particular for a vehicle, in particular a motor vehicle, g) operating 377 an embedded system, in particular an Internet-of-Things, loT system, h) operating 378 an application-specific integrated circuit, ASIC.
  • computing resources e.g. characterizable by computing time, specification of a computing core
  • Minimization 375 of a Influence of a corrupted component e.g., a control device, in particular for a vehicle, in particular a motor vehicle, g) operating 377 an embedded system, in particular an Internet-of-Things, loT system, h) operating 378 an application-specific integrated circuit, ASIC.
  • computing resources e.g. characterizable by computing time, specification of a computing core
  • the method further comprises: a) providing 380 a primary supervisor proxy SVI-pri by means of the supervisor instance SVI, b) providing 382 at least one secondary supervisor proxy SVI-sec- 1, SVI-sec-2, where in particular the at least one secondary supervisor proxy SVI-sec-1, SVI-sec-2 has at least one computation kernel 102a, 102b, 102c, ..., 102n; K1, K2, K3, K4 and / or the at least one zone Z1, Z2 is assigned (for example details see below for Fig. 24).
  • the primary supervisor proxy SVI-pri can be realized and / or implemented by means of the on-chip trust anchor (TA).
  • TA on-chip trust anchor
  • the method further comprises: a) providing 385 a first number of functionalities FUN-1 for the supervisor SV, b) assigning 386, in particular dynamically, at least one supervisor functionality SF-1 the first number of functionalities FUN- 1 to the primary supervisor proxy SVI-pri and / or the at least one secondary supervisor proxy SVI-sek-1, in particular the assignment 386 being carried out as a function of at least one of the following elements: A) Operating variable of computing device 100; 100a; 100b, B) operating mode of computing device 100; 100a; 100b, C) application of the computing device 100; 100a; 100b.
  • FIG. 24 schematically shows a simplified block diagram of a computing device 100c in accordance with further preferred embodiments.
  • the computing device 100c has one or more computing cores, which in the present case are collectively designated with the reference symbol KX.
  • Two zones Z1, Z2 are assigned to the computing cores KX, to which, as already described several times by way of example, one or more proxies Z1 -Proxy 1, .., Z1 -Proxy n, Z2-Proxy 1, .., Z2-Proxy n are assigned at least at times could be.
  • a supervisor instance SVI is provided which is independent of the at least two zones Z1, Z2.
  • one or more (“own”) zones Z3, Z4 can also be assigned to the supervisor instance SVI, the zones Z3, Z4 likewise preferably being independent of the at least two zones Z1, Z2.
  • One or more proxies Z3-Proxy 1, .., Z3-Proxy n, Z4-Proxy 1, .., Z4-Proxy n are assigned to the two zones Z3, Z4, for example, at least at times, with the number of proxies according to further preferred embodiments per zone Z3, Z4 (optionally also Z1, Z2) can also be different.
  • At least one (dedicated) computing core of the computing device 100c can preferably be used as a supervisor instance SVI.
  • at least one hardware security module HSM and / or one trusted platform module TPM can be used as a supervisor instance SVI.
  • a data exchange DE between the supervisor instance SVI and the computing cores KX can take place in further preferred embodiments, for example using one or more memory areas, in particular using register memories such as one or more register memories for special functions )).
  • a first register memory or a first group SFR1 of register memories is provided in order to transfer data from the supervisor instance SVI to the cores KX (“host cores”).
  • a second register memory or a second group SFR2 of register memories is provided in order to transfer data from the cores KX to the supervisor instance SVI.
  • a main memory SR (“shared RAM”) is provided for shared access by the primary supervisor proxy SVI-pri and the secondary supervisor proxy SVI-sek-1.
  • the register memory (s) SFR2 are preferably readable and / or writable on the host side (that is to say by at least one of the computing cores KX), but preferably only readable from the perspective of the supervisor entity SVI.
  • writing of the SFR2 on the host side ie writing of the register memory or registers SFR2 by at least one of the computing cores KX) results, for example, in an interrupt request IRQ on the side of the supervisor instance SVI.
  • the register memory (s) SFR1 are preferably readable and / or writable on the supervisor instance side, but can only be read from the perspective of the computing cores KX. More preferably, a supervisor instance-side writing of the register memory SFR1 results in an interrupt request IRQ on the host side KX.
  • the register memory (s) SFR1 can optionally also be polled, in particular interrogated cyclically, on the host side, in order to generate an interrupt request IRQ on the host side KX.
  • bidirectional, readable and writable shared RAM SR can, if required, according to further preferred embodiments, the supplementary data or parameter exchange between the two supervisor proxies SVI-pri, SVI-sek-1 serve.
  • the shared RAM SR can also be subdivided into areas ("sub-areas") which: a) can be read and written bidirectionally, and / or b) (in particular only) can be written by the trust anchor TA and by the Host KX can be read, and / or c) (in particular only) can be written by the host KX and read by the gate anchor TA.
  • sub-areas areas which: a) can be read and written bidirectionally, and / or b) (in particular only) can be written by the trust anchor TA and by the Host KX can be read, and / or c) (in particular only) can be written by the host KX and read by the gate anchor TA.
  • the shared RAM SR can optionally be divided into one main area per computing core (according to further preferred embodiments, at least for some of a plurality of computing cores).
  • this main area or in these main areas for example, at least one, preferably several or all three of the aforementioned three sub-areas a), b), c) can be provided.
  • the main area (s) are also separated from one another by means of a respective memory protection device (MPU) so that, for example, a first computing core is not in the exchange area of a second computing core (e.g. for data exchange between the second computing core with the Trust Anchor TA , SVI).
  • MPU memory protection device
  • data can be transmitted between the cores KX and the supervisor instance SVI, e.g. program-controlled and / or event-controlled (e.g. by means of interrupt requests IRQ).
  • the supervisor instance SVI e.g. program-controlled and / or event-controlled (e.g. by means of interrupt requests IRQ).
  • the supervisor entity SVI characterizes or represents or forms an, in particular particularly, trustworthy entity of the computing device 100c, preferably a so-called on-chip trust anchor (TA).
  • the TA represents the instance of the computing device 100c with the maximum trust level, which according to further preferred embodiments can be used, for example, as the "root of trust" of a trust model.
  • a dedicated computing core or preferably, if available, a dedicated security / cryptography module for example hardware security module (HSM), trusted platform module (TPM), etc., can function as the TA.
  • HSM hardware security module
  • TPM trusted platform module
  • TA Threat Anchor
  • the TA SVI has, preferably unrestricted, access to volatile memory 1004a (FIG. 22) such as RAM, non-volatile memory 1004b such as read only memory (ROM) or flash, one-time programmable (OTP) - Memory and special function registers SFR1, SFR2 (FIG. 25), in particular also to any special function registers of the computing device 100c that may be present.
  • volatile memory 1004a such as RAM
  • non-volatile memory 1004b such as read only memory (ROM) or flash
  • OTP one-time programmable
  • the principle according to preferred embodiments can be used, for example, for the configuration and / or monitoring of, in particular untrustworthy and trustworthy, (host) zones Z1 and Z2 for both the intra- and inter-core zones already described above - Use separation.
  • the supervisor functionalities mentioned below by way of example, in particular depending on the application, further in particular arbitrarily, can be shifted between the "host proxy" SVI-sek-1 and the primary supervisor proxy SVI-pri, with an increase in particular the supervisor functionalities implemented on the side of the primary supervisor proxy SVI-pri result in an, in particular significant, improvement in security:
  • Monitoring of zone Z1 (and optionally zone Z2) for potential compromises and / or detection of potential compromises of zone Z1 (and / or zone Z2) - can preferably be done, for example, by monitoring the stack (stack memory) and / or program counter (program counter ) of the zone Z1- (and / or the zone Z2), in particular before a task activation of a task assigned to the respective zone Z1, Z2, detection of compromise before code execution; the monitoring can, according to further preferred embodiments, optionally via cryptographic integrity and / or Authenticity verifications, for example hash, message authentication code (MAC) etc., for example of the stack and / or program counter of host Z1 (and host Z2) take place.
  • MAC message authentication code
  • At least one substitute response or error response is initiated. This can be done, for example, by o setting zone Z1 (and / or zone Z2) to a safe, in particular integral state (e.g. via power-off / on-reset) or to an error mode, o generating a log (or log file or Error memory) entry.
  • a secure and / or encrypted storage of log entries takes place at least temporarily, in particular in an optional dedicated and exclusive memory SL, preferably of the supervisor instance SVI (see FIG. 24).
  • At least one of the following elements is provided: a) Establishing an authentic and / or encrypted communication channel for forwarding e.g. log entries to at least one external entity (not shown), e.g. an intrusion detection system (IDS), b) Coordination and / or orchestration (e.g. having a scheduling (resource planning)) in particular tasks to be executed cyclically or event-based in zones Z1, Z2, c) secure storage and / or processing of a preferably static host task list in the dedicated and exclusive TA memory SL (Fig. 24), d) Switching between static configuration data sets ("MPU sets"), for example in host MPU SFRs for zone Z1 and / or zone Z2 tasks.
  • IDS intrusion detection system
  • Coordination and / or orchestration e.g. having a scheduling (resource planning)
  • a scheduling resource planning
  • the supervisor functionality can be shifted completely to the TA SVI (FIG. 24), with the privileged mode (supervisor mode) in particular being able to be wholly or at least partially withdrawn from the computing cores (which do not implement the supervisor functionality).
  • Preferred embodiments enable at least temporarily and / or partially at least some of the following effects:
  • the TA SVI has a, in particular, dedicated, memory protection unit (MPU)
  • additional confidence limits or zones Z3, Z4 can be introduced on the TA SVI according to further preferred embodiments.
  • the TA-side zones Z3, Z4 can preferably correlate with correspondingly higher confidence levels than the host-side zones Z1, Z2.
  • the exemplary trust model visualized in Fig. 24 is based on the following zone architecture in descending trust levels: o TA-side: Zone Z4 (e.g. maximum trust level) o TA-side: Zone Z3 o Host-side: Zone Z2 o Host-side: Zone Z1 (e.g. minimum trust level)
  • an integral and / or authentic host MPU configuration e.g. as part of a secure boot mechanism, can also be carried out or at least temporarily controlled by the TA SVI.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren zum Betreiben einer wenigstens einen Rechenkern (102a, 102b, 102c,..., 102n; K1, K2, K3, K4; KX) aufweisenden Recheneinrichtung für ein Steuergerät eines Kraftfahrzeugs, wobei die Recheneinrichtung (100; 100a; 100b; 100c) dazu eingerichtet ist, einen Datenaustausch zwischen einer Konnektivitätszone (400) und einer Sicherheitszone (440) zu steuern, wobei die Sicherheitszone (440) zumindest eine Komponente (442, 444, 446) des Fahrzeugs umfasst wie beispielsweise eine Motorsteuerung (442), ein Bremssystem (444) oder eine Lenkung (446), die zum Fahren des Fahrzeugs erforderlich ist und eine erhöhte Sicherheitsrelevanz besitzt, wobei die Konnektivitätszone (400) zumindest eine Komponente (420, 422, 424, 426) des Fahrzeugs umfasst, deren Betrieb eine Kommunkation außerhalb des Fahrzeugs erfordert, jedoch nicht zum Fahren des Fahrzeugs erforderlich ist und keine erhöhte Sicherheitsrelevanz besitzt, wobei zumindest ein von der Recheneinrichtung (100; 100a; 100b; 100c) ausführbares erstes Programm, insbesondere Anwendungsprogramm (AP1), zu einer nicht-vertrauenswürdigen Zone (Z1), und zumindest ein weiteres Programm, insbesondere Anwendungsprogramm (AP2), einer vertrauenswürdigen Zone (Z2) zugeordnet wird, wobei die Komponente (420, 422, 424, 426) der Konnektivitätszone (400) der nicht-vertrauenswürdigen Zone (Z1) zugeordnet wird, und die Komponente (442, 444, 446) der Sicherheitszone (440) der vertrauenswürdigen Zone (Z2) zugeordnet wird, wobei die Recheneinrichtung (100; 100a; 100b; 100c) zumindest einen Speicher (1030, 1032) umfasst mit zumindest einen ersten Pufferspeicherbereich (TB1b, B3'), auf den ausschließlich das der nicht-vertrauenswürdigen Zone (Z1) zugeordnete Programm (AP1) nur lesenden und/oder nur schreibenden Zugriff besitzt, mit zumindest einem zweiten Pufferspeicherbereich (TB2a, B1_2), auf den ausschließlich das der vertrauenswürdigen Zone (Z2) zugeordnete weitere Programm (AP2) nur lesenden und/oder nur schreibenden Zugriff besitzt, und mit zumindest einem Austausch-Pufferspeicherbereich (TB1a, TB2b, B3''), der dem ersten Programm (AP1) der nicht-vertrauenswürdigen Zone (Z1) nur schreibenden Zugriff und dem zweiten Programm (AP2) der vertrauenswürdigen Zone (Z2) nur lesenden Zugriff ermöglicht.

Description

Beschreibung
Verfahren und Vorrichtung zum Betreiben einer Recheneinrichtung
Stand der Technik
Die Offenbarung betrifft ein Verfahren zum Betreiben einer wenigstens einen Rechenkern aufweisenden Recheneinrichtung.
Die Offenbarung betrifft ferner eine Vorrichtung zur Ausführung eines derartigen Verfahrens.
Offenbarung der Erfindung
Im Kontext hochvernetzter, moderner Fahrzeuge erhöht sich insbesondere aufgrund der mannigfaltigen externen Schnittstellen massiv die Angriffsoberfläche auf Recheneinrichtungen z.B. von Steuergeräten und/oder eingebetteten Systemen. Speziell das Risiko eines sogenannten Remote- Angriffes, d.h. eine Kompromittierung bspw. via Internet ohne physikalischen Zugriff auf das Fahrzeug bzw. die Recheneinrichtung, ist gegeben. Das Prinzip gemäß den bevorzugten Ausführungsformen kann vorteilhaft zur effizienten Verhinderung derartiger Remote-Angriffe und/oder anderer Angriffe auf eine Recheneinrichtung verwendet werden.
Eine Reduzierung der Angriffsmöglichkeiten wird erfindungsgemäß insbesondere dadurch erreicht, dass unterschiedliche Zonen, nämlich zumindest eine vertrauenswürdige und zumindest eine nicht-vertrauenswürdige Zonen vorgesehen werden, denen jeweilige Programme zugeordnet werden. Ein Datenaustausch zwischen den unterschiedlichen Zonen wird dadurch verbessert, dass unterschiedliche Pufferspeicherbereiche mit unterschiedlichen Berechtigungen (lesend, schreibend, nicht jedoch: ausführend) vorgesehen werden. Ein Übergang von Daten von der nicht-vertrauenswürdigen Zone in die vertrauenswürdige Zone erfolgt erst, wenn eine Validierung der Daten erfolgt, jedoch noch in der nicht-vertrauenswürdigen Zone. Dadurch lassen sich weiter Manipulationsmöglichkeiten einschränken. Insbesondere Missbrauchsfälle aufgrund fehlerhafter Programmierung beispielsweise bei fehlerhaften Rücksprungsadressen, unzulässiges Überschreiben bei Buffer- Overflow/Underflow etc. lassen sich insbesondere durch die Verwendung einer Speicherschutzeinrichtung minimieren, die die Zugriffsrechte auf bestimmte Pufferspeicherbereiche zum Datenaustausch steuert. Die Zonentrennung lässt sich auch auf Schnittstellen, Speicher bzw. Laufzeiten anwenden, wodurch sich die Missbrauchsmöglichkeiten weiter reduzieren. Außerdem wird der Einfluss einer korrumpierten Zone durch dieses Konzept weiter reduziert. Das Konzept lässt sich bereits bei einer einzigen Multi-Kern-Lösung realisieren. Das Konzept kann leicht skaliert werden, d.h. es können noch weitere Zonen je nach Sicherheitsarchitektur besonders einfach hinzugefügt werden.
In einer zweckmäßigen Weiterbildung weist ein Austauschen von Daten zwischen verschiedenen Zonen folgende Schritte auf: Kopieren der Daten in den der ersten Zone zugeordneten ersten Pufferspeicherbereich, Überprüfen bzw. Validierung der kopierten Daten und in Abhängigkeit der Überprüfung bzw. Validierung Kopieren der Daten aus dem der ersten Zone zugeordneten ersten Pufferspeicherbereich in den der zweiten Zone zugeordneten zweiten Pufferspeicherbereich.
Insbesondere durch die Validierung der eingehenden Daten kann die Sicherheit weiterhin erhöht werden. Die Geschwindigkeit des Datenaustausches kann aufgrund des gewählten Konzepts mit den Pufferspeichern bei hoher Manipulationssicheheit erhöht werden. Außerdem erlaubt das Konzept auch eine Überwachung der nicht-vertrauenswürdigen Zone, indem hierzu auf Überwachungsmechanismen zur Überwachung der vertrauenswürdigen Zone zurückgegriffen wird. Besonders bevorzugt werden Daten von dem ersten Pufferspeicherbereich in den Austausch-Pufferspeicherbereich geschrieben. Besonders zweckmäßig werden die in dem Austausch-Pufferspeicherbereich befindlichen Daten in Verbindung mit einem lesenden Zugriff insbesondere durch das weitere Programm überprüft und bei einem erfolgreichen Überprüfen der Daten die Daten vom Austausch-Pufferspeicherbereich in den zweiten Pufferspeicherbereich kopiert. Damit kann eine klare Zonentrennung erfolgen, sodass keine korrumpierten Daten in die vertrauenswürdige Zone gelangen. Die Sicherheit wird weiterhin erhöht, indem ein ausführender Zugriff auf Daten in jedem der Pufferspeicherbereich bzw. in dem Austausch-Pufferspeicherbereich unterbunden wird. Somit kann eine Verwendung der Daten erst nach Verifikation überhaupt erfolgen. Dadurch erhöht sich die Sicherheit weiter.
Besonders zweckmäßig ist ein Verfahren zum Betreiben einer wenigstens einen Rechenkern aufweisenden Recheneinrichtung, insbesondere für ein eingebettetes System und/oder ein Steuergerät, insbesondere für ein Fahrzeug, insbesondere Kraftfahrzeug, vorgesehen, wobei das Verfahren die folgenden Schritte aufweist: Zuordnen von einem oder mehreren durch die Recheneinrichtung ausführbaren Programmen, insbesondere Anwendungsprogramme oder Unterprogramme, zu einer von wenigstens zwei Zonen, wobei die Zonen Ressourcen der Recheneinrichtung charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms nutzbar sind, optional Ausführen wenigstens eines der Programme, insbesondere Anwendungsprogramme oder Unterprogramme, in Abhängigkeit der ihm zugeordneten Zone, wobei das Verfahren weiter aufweist: Verwenden eines Supervisors zum Zuweisen von Rechenzeitressourcen für unterschiedliche Programme, insbesondere Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei der Supervisor und/oder eine dem Supervisor entsprechende Funktionalität zumindest teilweise mittels einer Supervisor- Instanz realisiert ist, die von den wenigstens zwei Zonen unabhängig ist.
Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in den Figuren der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Ansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung bzw. Darstellung in der Beschreibung bzw. in der Zeichnung.
In der Zeichnung zeigt: Fig. 1 schematisch ein vereinfachtes Blockdiagramm einer Recheneinrichtung gemäß bevorzugten Ausführungsformen,
Fig. 2A schematisch ein vereinfachtes Flussdiagramm eines Verfahrens gemäß weiteren bevorzugten Ausführungsformen,
Fig. 2B bis 2W jeweils schematisch ein vereinfachtes Flussdiagramm eines Verfahrens gemäß weiteren bevorzugten Ausführungsformen,
Fig. 3 schematisch ein vereinfachtes Blockdiagramm einer Recheneinrichtung gemäß weiteren bevorzugten Ausführungsformen,
Fig. 4,
5 jeweils schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen,
Fig. 6, 7 jeweils schematisch Aspekte von Unterbrechungsroutinen gemäß weiteren bevorzugten Ausführungsformen,
Fig. 8 schematisch ein Ablaufdiagramm gemäß weiteren bevorzugten Ausführungsformen,
Fig. 9 Aspekte einer Unterbrechungsroutine gemäß weiteren bevorzugten Ausführungsformen,
Fig. 10,
11 jeweils schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen,
Fig. 12A,
12B jeweils schematisch Aspekte von Unterbrechungsroutinen gemäß weiteren bevorzugten Ausführungsformen,
Fig. 13 schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen,
Fig. 14 schematisch ein Ablaufdiagramm gemäß weiteren bevorzugten Ausführungsformen,
Fig. 15 bis 19 jeweils schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen,
Fig. 20,
21 jeweils schematisch ein Ablaufdiagramm gemäß weiteren bevorzugten Ausführungsformen,
Fig. 22 schematisch ein vereinfachtes Blockdiagramm einer Vorrichtung gemäß weiteren bevorzugten Ausführungsformen,
Fig. 23 schematisch ein vereinfachtes Blockdiagramm von Konfigurationsdaten gemäß weiteren bevorzugten Ausführungsformen, und
Fig. 24 schematisch ein vereinfachtes Blockdiagramm gemäß weiteren bevorzugten Ausführungsformen und
Fig. 25 ein vereinfachtes Blockdiagramm der Einbindung der Vorrichtung in einem Kraftfahrzeug.
Figur 1 zeigt schematisch ein vereinfachtes Blockdiagramm einer Recheneinrichtung 100 gemäß bevorzugten Ausführungsformen. Die Recheneinrichtung 100 weist wenigstens einen Rechenkern, vorliegend beispielhaft vier Rechenkerne 102a, 102b, 102c, 102n, auf, und kann insbesondere z.B. für ein eingebettetes System und/oder ein Steuergerät, insbesondere für ein Fahrzeug, insbesondere Kraftfahrzeug, verwendet werden.
Bevorzugte Ausführungsformen beziehen sich auf ein Verfahren zum Betreiben der Recheneinrichtung 100, das die folgenden Schritte aufweist, vgl. das Flussdiagramm der Figur 2A: Zuordnen 200 von einem oder mehreren durch die Recheneinrichtung 100 (Fig. 1) ausführbaren Programmen, insbesondere Anwendungsprogrammen AP1, AP2 und/oder Unterprogrammen und/oder Proxies und/oder Instanzen, zu einer von wenigstens zwei Zonen Z1 , Z2 wobei die Zonen Z1, Z2 Ressourcen der Recheneinrichtung 100 charakterisieren, die für eine Ausführung eines betreffenden Programms, insbesondere Anwendungsprogramm AP1, AP2 und/oder Unterprogramm und/oder Proxies und/oder Instanzen eines Anwendungsprogramms AP1, AP2, nutzbar sind, optional Ausführen 210 wenigstens eines der Programme, insbesondere Anwendungsprogramme AP1, AP2 und/oder Unterprogramme und/oder Proxies und/oder Instanzen, in Abhängigkeit der ihm zugeordneten Zone Z1 , Z2. Das Verfahren weist optional weiter auf: Verwenden 212 eines Supervisors SV zum Zuweisen von Rechenzeitressourcen für unterschiedliche Programme, insbesondere Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei der Supervisor SV und/oder eine dem Supervisor SV entsprechende Funktionalität zumindest teilweise mittels einer Supervisor-Instanz SVI (Fig. 1) realisiert ist, die von den wenigstens zwei Zonen Z1 , Z2 unabhängig ist. Dies ermöglicht vorteilhaft eine Steigerung der Sicherheit des Betriebs der Recheneinrichtung 100, ohne die betriebliche Flexibilität bei der Ausführung von Programmen, insbesondere Anwendungsprogrammen AP1,
AP2, Unterprogrammen, Proxies, Instanzen etc., zu beeinträchtigen.
Bei weiteren bevorzugten Ausführungsformen können dadurch z.B. Vertrauensgrenzen (englisch: Trust Boundaries) definiert werden, z.B. zwischen vertrauenswürdigen und nicht-vertrauenswürdigen Instanzen/ Einheiten/Domänen. Auf diese Weise können beispielsweise erste Programme, insbesondere Anwendungsprogramme und/oder Unterprogramme und/oder Proxies und/oder Instanzen, für die Recheneinrichtung einer nicht vertrauenswürdigen ersten Zone (englisch: non-trustworthy zone, NTZ) und zweite Programme, insbesondere Anwendungsprogramme und/oder Unterprogramme und/oder Proxies und/oder Instanzen, für die Recheneinrichtung einer vertrauenswürdigen zweiten Zone (englisch: trustworthy zone, TZ) zugeordnet werden.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Recheneinrichtung 100 (Fig. 1) mehrere (z.B. wie beispielhaft in Fig. 1 abgebildet vier) Rechenkerne 102a, 102b, 102c, 102n aufweist, wobei das Verfahren weiter aufweist, vgl. Fig. 2B: a) Zuordnen 220 mindestens eines Rechenkerns zu genau einer Zone, und/oder b) Zuordnen 222 mindestens eines Rechenkerns zu mehr als einer Zone, insbesondere zu zwei Zonen, c) Verwenden 224 wenigstens eines Rechenkerns als Supervisor-Instanz SVI, insbesondere Verwenden des wenigstens einen Rechenkerns als dedizierte Supervisor-Instanz SVI, d) Verwenden 225 wenigstens eines Hardware-Sicherheitsmoduls HSM und/oder Trusted-Platform-Moduls, TPM, als Supervisor-Instanz SVI. Bei weiteren bevorzugten Ausführungsformen wird beispielsweise der erste Rechenkern 102a einer ersten Zone Z1 zugeordnet, die z.B. eine nicht vertrauenswürdige Zone darstellen kann, und der zweite Rechenkern 102b wird einer zweiten Zone Z2 zugeordnet, die z.B. eine vertrauenswürdige Zone darstellen kann.
Bei weiteren bevorzugten Ausführungsformen wird beispielsweise der dritte Rechenkern 102c sowohl der ersten Zone Z1 als auch der zweiten Zone Z2 zugeordnet, s. Fig. 1. Vergleichbares kann bei weiteren bevorzugten Ausführungsformen auch für den vierten Rechenkern 102n der Recheneinrichtung 100 gelten.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung 100 gemäß Fig. 1 auch über weitere, in Fig. 1 nicht im Einzelnen aufgeführte Komponenten wie z.B. ein oder mehrere Speichereinrichtungen und/oder Peripheriekomponenten verfügen, die in Fig. 1 der Übersichtlichkeit halber zusammen mittels des gestrichelten Rechtecks 103 angedeutet sind. Bezugszeichen 104 symbolisiert ein oder mehrere Datenschnittstellen.
Die nicht-vertrauenswürdige Zone Z1 umfasst Komponenten/Steuergeräte in einem Kraftfahrzeug in einer Konnektivitätszone 400, vgl. Fig. 25. Hierbei können Daten ausgetauscht werden beispielsweise über eine drahtlose Schnittstelle 410 (beispielsweise mittels Mobilfunk, WLAN, Bluetooth etc.) oder eine oder eine drahtgebundene Schnittstelle 412 (leicht zugänglich mit physikalischer Konnektivität) wie beispielsweise eine Diagnoseschnittstelle (OBD) mit zugehörigem Schnittstellen-Port 426. In der Konnektivitätszone 400 sind als mögliche Komponenten beispielsweise eine sog. Connectivity Control Unit bzw. eine Einrichtung zur fahrzeugexternen Vernetzung 420, ein Infotainment 422, eine Multimediaeinheit 424 etc. vorgesehen. In dieser Konnektivitätszone 400 sind solche Funktionen des Kraftfahrzeugs angesiedelt, die sich zum einen durch Datenaustausch mit Einrichtungen außerhalb des Fahrzeugs auszeichnen, zum anderen jedoch keine sicherheitsrelevanten Funktionen, die zum Fahren des Kraftfahrzeugs zwingend notwendig sind, umfassen. Es handelt sich insbesondere um Komponenten mit einer geringen Sicherheitsklassifikation, beispielsweise ASIL-Klassifikation QM oder ASIL-A gemäß ISO 26262, eine ISO- Norm für sicherheitsrelevante Systeme in Kraftfahzeugen. Solche sicherheitsrelevanten Funktionen, die zum Fahren des Kraftfahrzeugs zwingend notwendig sind, sind in der Sicherheitszone 440 angesiedelt. Diese funktionale Sicherheitszone 440 dient insbesondere zum Schutz von Insassen und Umwelt. Die Sicherheitszone 440 umfasst sämtliche Komponenten/ Steuergeräte mit hohen Anforderungen bezüglich funktionaler Sicherheit (Motorsteuerung, Lenkung, Bremse, ....). Sämtliche aus der vertrauenswürdigen Zone Z2 kommenden Daten werden bevorzugt direkt als vertrauenswürdig gewertet ohne weitere Input-Validierung. Beispielhaft kann es sich bei den Komponenten der Sicherheitszone 440 um die Motorsteuerung 442,
Bremssystem 444, Lenkung 446 etc. handeln. Für die Komponenten der Sicherheitszone 440 bestehen erhöhte Sicherheitsanforderungen. Hierbei handelt es sich um Sicherheitsanforderungen - wie in der ISO-Norm IS026262 klassifiziert - ab ASIL-B bis ASIL-D in der Sicherheitsklassifizierung gemäß IS026262.
Als Bindeglied insbesondere zum Datenaustausch zwischen der Sicherheitszone 440 und der Konnektivitätszone 400 ist eine Steuerzone 430 vorgesehen. Die Steuerzone 430 wird realisiert durch ein Gateway 432, in dem die beschriebenen Funktionen realisiert sind. Die Steuerzone 430 zeichnet sich durch gezielte Überwachung der Kommunikation zwischen der Konnektivitätszone 400 und der Sicherheitszone 440 aus. Dort ist insbesondere die Zonenseparation zwischen der vertrauenswürdigen Zone Z2 und der nicht-vertrauenswürdigen Zone Z1 mit zugehörigem Datenaustausch und Überwachungsmechanismen insbesondere durch die Speicherschutzeinrichtung SSE oder den Supervisor SV angesiedelt. Es erfolgt die entsprechende Interaktion zwischen Konnektivitätszone 400 und funktionaler Sicherheitszone 440.
Besonders bevorzugt erfolgt die Aufteilung von Schnittstellen 410, 412, Ressourcen, Laufzeit und Privilegien nach Zonen (sicherheitsrelevante Zone Z2, nicht-sicherheitsrelevante Zone Z1). Bei den Schnittstellen 410, 412 kann es sich um physikalisch getrennte Bussysteme oder um logische Diagnose-Schnittstellen handeln. Zu den Ressourcen zählen Speicher 1030, 1030a, Programmspeicher, Datenspeicher und Daten-Puffer bzw. Pufferspeicher. Die Laufzeit umfasst separate Tasks oder aber das Vorsehen separater Kommunikations-Proxies bzw. Instanzen (Unterprogramme beispielsweise in Verbindung mit der Aufsplittung der Protokolle nach Zonen Z1, Z2; diese Proxies bzw. Unterprogramme dienen lediglich dem Kommunikationsablauf). Außerdem können als Programme separate Applikations-Proxies bzw. Instanzen (Unterprogramme, die die Daten verändern bzw. zur Durchführung von Anwendungsprogrammen auf diese Daten zugreifen, beispielsweise für Connected Services, Fernentriegelung Tür (Remote Door Unlock), Parken über Fernbedienung (Remote Parking)) vorgesehen sein. Zu den Privilegien zählen beispielsweise privilegierte Betriebsmodi. So kann beispielsweise ein spezieller Modus für die erste Zone Z1 vorgesehen werden, wie dies beispielsweise über die Konfigurationsdaten für die Speicherschutzeinrichtung SSE realisiert werden kann. Außerdem kann ein spezieller Modus für die zweite Zone Z2 vorgesehen werden, wie dies ebenfalls beispielsweise über die Konfigurationsdaten für die Speicherschutzeinrichtung SSE realisiert werden kann. Weiterhin kann ein Supervisor bzw. Supervisor- Instanz SVI , wiederum repräsentiert über die Konfigurationsdaten für die Speicherschutzeinrichtung SSE, für den Wechsel zwischen den genannten Modi für die beiden Zonen Z1, Z2 vorgesehen sein. Hierbei erfolgt eine einmalige statische und authentische Konfiguration der Speicherschutzeinrichtung SSE.
Das grundsätzliche Vorgehen hierzu wird nachfolgend näher beschrieben.
Bei weiteren bevorzugten Ausführungsformen kann die Supervisor-Instanz SVI z.B. durch einen (dedizierten) Rechenkern und/oder ein Hardware- Sicherheitsmodul HSM und/oder ein Trusted-Platform-Modul TPM gebildet sein bzw. kann die Funktionalität der Supervisor-Instanz SVI mittels wenigstens einem dieser Elemente realisiert werden.
Figur 3 zeigt schematisch ein vereinfachtes Blockdiagramm einer Recheneinrichtung 100a gemäß weiteren bevorzugten Ausführungsformen, die - vergleichbar zu der Recheneinrichtung 100 gemäß Fig. 1 - vier Rechenkerne 102a, 102b, 102c, 102n aufweist. Ebenfalls in Fig. 3 gezeigt ist ein Arbeitsspeicher (RAM) 1030, ein nichtflüchtiger Speicher 1032 (z.B. Flash- Speicher, insbesondere Flash-EEPROM), sowie optional vorhandene Spezialfunktionsregister 1034 der Recheneinrichtung 100a, wie sie z.B. zur Steuerung eines Betriebs von Peripheriekomponenten hiervon nutzbar sind. Die Komponenten 102a, 102b, .., 1034 sind untereinander über ein Bussystem 101 miteinander verbunden. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren zum Betreiben der Recheneinrichtung 100 (Fig. 1), 100a (Fig. 3) weiter aufweist, vgl. Fig. 2C: Steuern 230, insbesondere Begrenzen, von wenigstens einem der folgenden Elemente: a) Leserechte auf der Recheneinrichtung 100, 100a zugeordneten Speicher 1030, 1032, b) Schreibrechte auf der Recheneinrichtung zugeordneten Speicher 1030, 1032, c) Ausführungsrechte ("Exekutionsrechte") auf der Recheneinrichtung zugeordneten Speicher 1030, 1032, in Abhängigkeit wenigstens einer Zone Z1, Z2. Dadurch ist vorteilhaft sichergestellt, dass nur solche Programme, insbesonder
Anwendungsprogramme AP1, AP2 (Fig. 1), Unterprogramme etc., Zugriff auf den bzw. die genannten Speicher 1030, 1032 erhalten, die einer entsprechenden Zone Z1, Z2 zugeordnet sind. Beispielsweise kann damit bei weiteren bevorzugten Ausführungsformen verhindert werden, dass ein Programm, insbesondere Anwendungsprogramm, Unterprogramm, Proxy, einer nicht vertrauenswürdigen Zone auf den bzw. die Speicher 1030, 1032 zugreift (insbesondere z.B. Zugriff auf den der vertrauenswürdigen Zone zugeordneten Speicherbereich 1030, 1032 durch die nicht- vertrauenswürdigen Zone), was ggf. ein Risiko bezüglich einer möglichen Manipulation des Speicherinhalts durch Programm der nicht vertrauenswürdigen Zone darstellt.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2C: zumindest zeitweises Verwenden 232 wenigstens einer Speicherschutzeinrichtung M1, M2, M3, M4, M5_1, M5_2,
M5_3, M5_4, M5_5, M5_6, M5_7, M5_8 (Fig. 3) zum Steuern der Leserechte und/oder der Schreibrechte und/oder der Ausführungsrechte.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2D: Bereitstellen 231 wenigstens einer dedizierten Speicherschutzeinrichtung M1 für wenigstens einen Rechenkern 102a, wobei insbesondere für mehrere, vorzugsweise alle, Rechenkerne 102a, 102b, 102c, 102n jeweils eine dedizierte Speicherschutzeinrichtung M1, M2, M3, M4 bereitgestellt wird. Bei weiteren bevorzugten Ausführungsformen kann sodann die jeweilige (dedizierte) Speicherschutzeinrichtung M1, M2, M3, M4 verwendet werden, vgl. Schritt 232' aus Fig. 2D, um das genannte Steuern 230, insbesondere Begrenzen, der genannten Zugriffsrechte, insbesondere Leserechte und/oder Schreibrechte und/oder der Ausführungsrechte, auszuführen.
Bei weiteren bevorzugten Ausführungsformen kann der Verwendung 232' (Fig. 2D) eine optionale Konfiguration 231a der Speicherschutzeinrichtung(en) vorangehen.
Bei weiteren bevorzugten Ausführungsformen, vgl. Fig. 2E, ist vorgesehen, dass wenigstens ein Rechenkern 102a zumindest zeitweise eine erste Betriebsart einnimmt, vgl. Schritt 240, wobei insbesondere der wenigstens eine Rechenkern 102a in der ersten Betriebsart Konfigurationsdaten 1036 (Fig. 3), die einen Betrieb wenigstens einer Speicherschutzeinrichtung M1, M2, .., M5_8 steuern, vorgibt und/oder schreibt 242, wobei insbesondere der wenigstens eine Rechenkern 102a zumindest zeitweise eine zweite Betriebsart einnimmt 243, in der er die Konfigurationsdaten für die wenigstens eine Speicherschutzeinrichtung M1, M2, .., M5_8 nicht schreiben und/oder ändern kann.
Bei weiteren bevorzugten Ausführungsformen kann die erste Betriebsart auch als "Supervisor Mode" bzw. Überwachungsmodus bezeichnet werden. Bevorzugt kann der "Supervisor Mode" bzw. Überwachungsmodus somit einen privilegierten Zustand darstellen, in dem der betreffende Rechenkern 102a eine Konfiguration der wenigstens einen Speicherschutzeinrichtung M1, M2, .., M5_8 vornehmen kann.
Bei weiteren bevorzugten Ausführungsformen können die Konfigurationsdaten für die wenigstens eine Speicherschutzeinrichtung M1 , M2, .., M5_8 z.B. in Form von Spezialfunktionsregistern (englisch: special function register, SFR), insbesondere Konfigurationsregistern 1036 vorgesehen sein, die ggf. ebenfalls zumindest zeitweise, vorzugsweise unter Steuerung einer entsprechenden Speicherschutzeinrichtung M5_6, über das Bussystem 101 zugänglich sind.
Mit anderen Worten können bei weiteren bevorzugten Ausführungsformen für die Konfigurationsdaten der wenigstens einen Speicherschutzeinrichtung M1, M2, .., M5_8 z.B. Spezialfunktionsregister (SFR), insbesondere Konfigurationsregister 1036, vorgesehen sein. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, vgl. Fig. 2E, dass der wenigstens eine Rechenkern 102a die erste Betriebsart ereignisgesteuert, insbesondere in Abhängigkeit wenigstens einer Unterbrechungsanforderung (englisch: Interrupt request), einnimmt 240.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2F: Bereitstellen 250 mehrerer Sätze von Konfigurationsdaten KD für die wenigstens eine Speicherschutzeinrichtung M1, M2, .., M5_8, wobei insbesondere wenigstens ein erster Satz der mehreren Sätze von Konfigurationsdaten KD einer ersten Zone Z1 der wenigstens zwei Zonen und wenigstens ein zweiter Satz der mehreren Sätze von Konfigurationsdaten KD einer zweiten Zone Z2 der wenigstens zwei Zonen zugeordnet wird, vgl. Schritt 252.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass wenigstens ein Rechenkern 102a im Rahmen dedizierter Systemzustände, bspw. bei einem Startzyklus, und/oder bei bestimmten Ereignissen, bspw. bei dem Eintreten in eine Unterbrechungsroutine (englisch: Interrupt Service Routine, ISR), eine bestimmte Betriebsart wie z.B. den Supervisor Mode, einnimmt, was beispielsweise hardwaregesteuert erfolgen kann.
Bei weiteren bevorzugten Ausführungsformen ist wenigstens eine weitere, nicht privilegierte Betriebsart für einen oder mehrere, vorzugsweise alle, Rechenkerne vorgesehen ("nicht-privilegierter Modus"), die bei weiteren bevorzugten Ausführungsformen auch als "User Mode" ("Benutzermodus") bezeichnet werden kann. In dem User Mode sind die Konfigurationsdaten KD, 1036 für die wenigstens eine Speicherschutzeinrichtung M1, M2, .., M5_8 vorzugsweise nicht beschreibbar. Mit anderen Worten kann bei weiteren bevorzugten Ausführungsformen ein Rechenkern, der sich gerade in dem User Mode befindet, nicht die Konfigurationsdaten KD, 1036 für die wenigstens eine Speicherschutzeinrichtung M1, M2, .., M5_8 schreiben bzw. ändern, wohingegen ein Rechenkern, der sich gerade in dem Supervisor Mode befindet, die Konfigurationsdaten KD, 1036 für die wenigstens eine Speicherschutzeinrichtung M1, M2, .., M5_8 schreiben bzw. ändern kann. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Anwendungsprogramme AP1, AP2 in einem nicht-privilegierten Modus, z.B. dem User Mode, ausgeführt bzw. exekutiert werden.
Bei weiteren bevorzugten Ausführungsformen können z.B. auch drei Betriebsarten bzw. Betriebszustände bzw. Modi vorgesehen werden, z.B.: erstens ein Supervisor Mode, zweitens ein "User Mode 1", insbesondere für nicht-vertrauenswürdige Zone(n), drittens ein "User Mode 2", insbesondere für vertrauenswürdige Zone(n).
Bei weiteren bevorzugten Ausführungsformen können z.B. in dem User Mode 1 die statischen Konfigurationsdaten KD2 aktiv sein, und es läuft z.B. ein erstes Anwendungsprogramm AP1.
Bei weiteren bevorzugten Ausführungsformen können z.B. in dem User Mode 2 die statischen Konfigurationsdaten KD3 aktiv sein, und es läuft z.B. ein zweites Anwendungsprogramm AP2.
Bei weiteren bevorzugten Ausführungsformen sind in dem Supervisor Mode z.B. die statischen Konfigurationsdaten KD1 aktiv, wobei der Supervisor Mode z.B. (optional lediglich) zum Umschalten zwischen den statischen Konfigurationsdaten KD2 und den statischen Konfigurationsdaten KD3 dient.
Bei weiteren bevorzugten Ausführungsformen können die User Modes 1 und 2 nicht zwischen den statischen Konfigurationsdaten KD1, KD2, KD3, KD4 umschalten.
Bei weiteren bevorzugten Ausführungsformen können z.B. auch (lediglich) zwei Modes (z.B. Supervisor Mode und User Mode) vorgesehen sein. Bei weiteren bevorzugten Ausführungsformen kann demnach z.B. der Supervisor Mode der vertrauenswürdigen Zone zugeordnet sein und z.B. die Umschaltung zwischen den Konfigurationsdaten KD1 und den Konfigurationsdaten KD2 vornehmen sowie ggf. z.B. das zweite Anwendungsprogramm AP2 ausführen.
Bei weiteren bevorzugten Ausführungsformen werden für unterschiedliche Betriebsarten bzw. Betriebszustände (z.B. privilegierter und nicht-privilegierter Modus bzw. Supervisor Mode, User Mode) für die jeweilige Betriebsart spezifische Lese-, und/oder Schreib- und/oder Exekutionsrechte (Ausführungsrechte), z.B. auf den bzw. die Speicher 1030, 1032 vergeben, was bei weiteren bevorzugten Ausführungsformen z.B. durch die Vorsehung unterschiedlicher Sets von Konfigurationsdaten KD ("Konfigurationsdatensets") realisierbar ist.
Bei weiteren bevorzugten Ausführungsformen werden für unterschiedliche Kombinationen von Betriebsart(en) mit jeweiligen Anwendungsprogrammen betriebsartspezifische und/oder anwendungsspezifische Lese-, und/oder Schreib- und/oder Exekutionsrechte vergeben, was bei weiteren bevorzugten Ausführungsformen z.B. ebenfalls durch die Vorsehung unterschiedlicher Sets von Konfigurationsdaten KD ("Konfigurationsdatensets") realisierbar ist. Beispielsweise können somit z.B. für den User Mode für unterschiedliche Anwendungsprogramme AP1, AP2 (Fig. 1) jeweils an das betreffende Anwendungsprogramm AP1, AP2 angepasste Lese-, und/oder Schreib- und/oder Exekutionsrechte vergeben werden.
Bei weiteren bevorzugten Ausführungsformen weisen eine oder mehrere, vorzugsweise alle der beispielhaft genannten, Speicherschutzeinrichtungen M1, M2, .., M5_8 mehrere Konfigurationsdatensets auf, welche bei weiteren bevorzugten Ausführungsformen bevorzugt effizient unterschiedlichen Modi und Anwendungsprogrammen AP1, AP2 zugewiesen werden können.
Bei weiteren bevorzugten Ausführungsformen kann, z.B. bei einem Wechsel zwischen privilegierten oder nicht-privilegierten Modi (z.B. Wechsel von Supervisor Mode zu User Mode oder umgekehrt) oder zwischen Anwendungsprogrammen, insbesondere in einem nicht-privilegierten Modus, effizient, insbesondere hardwaregesteuert, zwischen den Konfigurationsdatensets für die betreffenden Modi bzw. Betriebsarten umgeschaltet werden.
Bei weiteren bevorzugten Ausführungsformen weist die Recheneinrichtung 100, 100a (Fig. 3) exemplarisch die nachfolgend beispielhaft genannten Konfigurationsmöglichkeiten auf: a) ein, insbesondere statisches (nicht veränderbares), Konfigurationsdatenset für wenigstens eine zentrale Speicherschutzeinrichtung bzw. wenigstens eine dem Bussystem 101 (Fig. 3) zugeordnete Speicherschutzeinrichtung M5_1, M5_8, b) jeweils vier, insbesondere statische, Konfigurationsdatensets für die dedizierten Speicherschutzeinrichtungen M1, M2, M3, M4, wobei diese jeweils vier Konfigurationsdatensets für die dedizierten Speicherschutzeinrichtungen bei weiteren bevorzugten Ausführungsformen z.B. ein statisches Konfigurationsdatenset für den Supervisor Mode und z.B. drei statische Konfigurationsdatensets für Anwendungsprogramme AP1, AP2, also z.B. für den User Mode aufweisen. Figur 23 zeigt schematisch beispielhafte Konfigurationsdaten KD' mit insgesamt vier Konfigurationsdatensets KD1, KD2, KD3, KD4.
Bei weiteren bevorzugten Ausführungsformen definieren die Konfigurationsdaten z.B. auf welche Speicheradressen eine Komponente der Recheneinrichtung, z.B. ein Rechenkern, lesend und/oder schreibend und/oder ausführend zugreifen darf. Die Speicherschutzeinrichtung kann bei weiteren bevorzugten Ausführungsformen dazu ausgebildet sein, aktuell von dem betreffenden Rechenkern ausgeführte Zugriffe (Lesen und/oder Schreiben und/oder Ausführen) mit dem Inhalt der Konfigurationsdaten zu vergleichen, und beispielsweise bei Übereinstimmung die betreffenden Zugriffe zu erlauben bzw. zu verbieten oder umgekehrt.
Bei weiteren bevorzugten Ausführungsformen können die genannten, bevorzugt statischen, Konfigurationsdatensets für die dedizierten Speicherschutzeinrichtungen M1, M2, M3, M4 z.B. für den User Mode mit den Zonen Z1, Z2 gemäß den Ausführungsformen korrelieren.
Bei weiteren bevorzugten Ausführungsformen, insbesondere im Falle einer sog. "Inter-Core-Zonen-Separation", werden auf einem bestimmten Rechenkern 102a (Fig. 1) ausschließlich Anwendungsprogramme einer bestimmten Zone Z2 (z.B. mit der gleichen Vertrauensstufe) ausgeführt. Bei weiteren bevorzugten Ausführungsformen werden, insbesondere im Falle einer dedizierten Speicherschutzeinrichtung M1 (Fig. 3) für einen solchen Rechenkern 102a, z.B. nur zwei, insbesondere statische, Konfigurationsdatensets verwendet, z.B. eines für den Supervisor Mode, und eines für Anwendungsprogramme im User Mode. Ggf. verbleibende, bislang ungenutzte Konfigurationsdatensets für Anwendungsprogramme insbesondere im User Mode können bei weiteren bevorzugten Ausführungsformen z.B. so konfiguriert werden, dass diese einen generellen Lese-, Schreib- und Exekutionszugriff auf den kompletten Speicher 1030, 1032 unterbinden, wodurch die Sicherheit weiter gesteigert wird.
Bei weiteren bevorzugten Ausführungsformen, insbesondere im Falle einer sog. "Intra-Core-Zonen-Separation" werden auf einem bestimmten Rechenkern 102c (Fig. 1) Anwendungsprogramme zweier Zonen Z1 , Z2, mit z.B. jeweils unterschiedlicher Vertrauensstufe, ausgeführt. Bevorzugt kommen hier zwei unterschiedliche statische Konfigurationsdatensets für die Programme bzw. Anwendungsprogramme der ersten Zone Z1 und die Programme bzw. Anwendungsprogramme der zweiten Zone Z2, insbesondere für den User Mode, zum Einsatz, sowie bevorzugt ein weiteres statisches Konfigurationsdatenset für eine weitere Betriebsart, z.B. den Supervisor Mode. Bei weiteren bevorzugten Ausführungsformen ist der Rechenkern 102c dazu ausgebildet, in der Betriebsart des Supervisor Mode eine Umschaltung zwischen den beiden statischen Konfigurationsdatensets für die beiden Zonen Z1, Z2 zu übernehmen. Bei weiteren bevorzugten Ausführungsformen kann der Rechenkern 102c somit in dem Supervisor Mode ein für die erste Zone Z1 passendes Konfigurationsdatenset in seiner dedizierten Speicherschutzeinrichtung aktivieren, wenn z.B. ein der ersten Zone Z1 zugeordnetes Programm, insbesondere Anwendungsprogramm AP1 oder Unterprogramm oder Instanz, ausgeführt werden soll, und z.B. ein für die zweite Zone Z2 passendes Konfigurationsdatenset in seiner dedizierten Speicherschutzeinrichtung aktivieren, wenn z.B. ein der zweiten Zone Z2 zugeordnetes Programm, insbesondere Anwendungsprogramm AP2 oder Unterprogramm oder Instanz, ausgeführt werden soll. Ggf. verbleibende, bislang ungenutzte Konfigurationsdatensets für Programme insbesondere im User Mode (vorliegend ein Konfigurationsdatenset, bei der beispielhaft genannten Gesamtzahl von 4 Stück) können bei weiteren bevorzugten Ausführungsformen z.B. so konfiguriert werden, dass diese einen generellen Lese-, Schreib- und Exekutionszugriff auf den kompletten Speicher 1030, 1032 unterbinden, wodurch die Sicherheit weiter gesteigert wird.
Bei weiteren bevorzugten Ausführungsformen, vgl. Fig. 2G, ist vorgesehen, dass das Verfahren weiter aufweist: Bereitstellen 260 einer ersten Instanz AP1 11 (bzw. Unterprogramm, Proxy) des Anwendungsprogramms AP1 und einer zweiten Instanz AP1J2 (bzw. Unterprogramm, Proxy) des Anwendungsprogramms AP1, Zuordnen 262 der ersten Instanz AP1J1 des Anwendungsprogramms AP1 zu einer ersten Zone Z1 der wenigstens zwei Zonen, Zuordnen 263 der zweiten Instanz AP1J2 des Anwendungsprogramms AP1 zu einer zweiten Zone Z2 der wenigstens zwei Zonen. Dadurch können vorteilhaft Anwendungsfälle abgedeckt werden, bei denen sich eine Anwendung bzw. ein Anwendungsprogramm AP1 über mehrere Zonen Z1, Z2 "erstreckt". Somit kann bei weiteren bevorzugten Ausführungsformen für dieses Anwendungsprogramm AP1 pro Zone jeweils eine Instanz AP1J1, AP1J2 existieren, wobei eine derartige Instanz bei weiteren bevorzugten Ausführungsformen auch als Proxy bezeichnet werden kann. Als Proxy, Instanzen, Unterprogramme etc. können generell Programme verstanden werden wie beispielsweise Anwendungsprogramme, die Daten benötigen bzw. Daten erzeugen, sowie Kommunikationsprogramme, die dem Datenhandling dienen.
Bei weiteren bevorzugten Ausführungsformen kann ein derartiger Proxy AP1J2 für die betreffende weitere Zone Z2 relevante (Teil-)Funktionalitäten abdecken. Bei weiteren bevorzugten Ausführungsformen kann ein Proxy auch ggf. mehrere Sub-Komponenten umfassen.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung 100, 100a z.B. das folgende Szenario ausführen: Soll ein erstes Programm, insbesondere Anwendungsprogramm AP1, Unterprogramm, Daten aus einer, z.B. nicht-vertrauenswürdigen ersten, Zone Z1 empfangen - bspw. Remote Service Requests ("Dienstanfragen aus der Ferne") aus dem Internet - und diese Daten entsprechend innerhalb der vertrauenswürdigen Zone Z2 prozessieren oder weiterleiten - bspw. zur Ausführung des entsprechenden Diensts ("Remote Service") - so erfolgt innerhalb der ersten Zone Z1 durch den Z1 -Proxy AP1J1 des Anwendungsprogramms AP1 das Empfangen der Daten, wobei der korrespondierende Z2-Proxy AP1J2 z.B. folgende Schritte ausführt: eine Daten- Verifikation der von dem Z2-Proxy AP1J2, insbesondere defaultmäßig, nicht vertrauenswürdig eingestuften Daten sowie - im Falle einer erfolgreichen Daten- Verifikation - die Prozessierung oder Weiterleitung der nun (nach Daten- Verifikation) als vertrauenswürdig eingestuften Daten innerhalb der zweiten Zone Z2. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2H: Trennen 270 von Bereichen eines der Recheneinrichtung 100, 100a zugeordneten Speichers 1030, 1032 in Abhängigkeit der wenigstens zwei Zonen Z1 , Z2, wobei der der Recheneinrichtung 100, 100a zugeordnete Speicher wenigstens eines der folgenden Elemente aufweist: a) Pufferspeicher, insbesondere in Form von Arbeitsspeicher, b) Stapelspeicher, c) Datenspeicher, d) Programmspeicher, e) Registerspeicher, wobei für das Trennen 270 wenigstens eine Speicherschutzeinrichtung verwendet wird, vgl. den optionalen Schritt 272.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2I: Austauschen 280 von ersten Daten zwischen verschiedenen Zonen über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone Z1 und der zweiten Zone Z2 folgende Schritte aufweist: Kopieren 282 der ersten Daten in einen der ersten Zone zugeordneten ersten Pufferspeicherbereich TB1b, B3, Überprüfen 283 der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, Kopieren 283 der ersten Daten aus dem der ersten Zone Z1 zugeordneten ersten Pufferspeicherbereich TB1b, B3 in einen der zweiten Zone Z2 zugeordneten zweiten Pufferspeicherbereich TB2a, B1_2. Besonders bevorzugt erfolgt der Datenaustausch über einen Austausch-Pufferspeicherbereich TB1A (für den Datenaustausch von Zone 1 Z1 nach Zone 2Z2) bzw. über einen Austausch- Pufferbereich TB2b (für den Datenaustausch von Zone 2 Z2 nach Zone 1 Z1).
Figur 4 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten der Recheneinrichtung 100, 100a gemäß weiteren bevorzugten Ausführungsformen. Abgebildet sind die beiden Rechenkerne 102a, 102b, die wie vorstehend bereits beschrieben den jeweiligen Zonen Z1, Z2 zugeordnet sind. Ein Bereich 1030a des Arbeitsspeichers 1030 (Fig. 3) ist vorliegend als Pufferspeicher (bzw. wie die nachfolgend beschriebenen Pufferspeicherbereiche (erster Pufferspeicherbereich TB1b, B3; zweiter Pufferspeicherbereich TB2a, B1_2; Austausch- Pufferspeicherbereich TB1a, TB2b, B3“)) bzw. "geteilter Arbeitsspeicher", insbesondere zum Datenaustausch zwischen verschiedenen Zonen Z1, Z2 bzw. den betreffenden Rechenkernen 102a, 102b bzw. darauf ausführbaren (Instanzen von) Anwendungsprogrammen nutzbar, wobei ein erster Teilbereich TB1 der ersten Zone Z1 bzw. dem zweiten Rechenkern 102b und ein zweiter Teilbereich TB2 der zweiten Zone Z2 bzw. dem ersten Rechenkern 102a zugeordnet ist.
Ebenfalls abgebildet in Fig. 4 sind mehrere Proxies PXY, wobei z.B. eine erste Anzahl von Proxies Z1-Proxy 1, Z1-Proxy 2, .., Z1-Proxy n der ersten Zone Z1, vorliegend also dem Rechenkern 102b, zugeordnet ist, und wobei z.B. eine zweite Anzahl von Proxies Z2-Proxy 1 , Z2-Proxy 2, .., Z2-Proxy n der zweiten Zone Z2, vorliegend also dem Rechenkern 102a, zugeordnet ist. Mit dem Bezugszeichen SSE sind vorliegend mehrere Speicherschutzeinrichtungen SSE bzw. funktionale Komponenten hiervon bezeichnet, die in Fig. 4 symbolisch eine entsprechende Trennung der Teilbereiche TB1, TB2 bzw. der Zonen Z1, Z2 voneinander bzw. untereinander entsprechend dem Prinzip gemäß bevorzugten Ausführungsformen andeuten.
Zum Datenaustausch werden unterschiedliche Pufferspeicherbereiche eingesetzt, je nach Figur mit unterschiedlichen Bezugszeichen versehen: erster Pufferspeicherbereich TB1b, B3; zweiter Pufferspeicherbereich TB2a, B1_2; Austausch-Pufferspeicherbereich TB1a, TB2b, B3“.
Um beispielsweise Daten von der ersten Zone Z1 (sendende Zone) in die vertrauenswürdige zweite Zone Z2 (empfangende Zone) in einer sicheren Art und Weise zu überführen, sind unterschiedliche Pufferspeicherbereiche des Speichers 1030,1032 vorgesehen.
So ist ein erster Pufferspeicherbereich TB1b, B3‘ für die erste bzw. sendenden Zone Z1 vorgesehen. Die sendende bzw. erste Zone Z1 bzw. das erste der nicht vertrauenswürdigen Zone Z1 zugeordnete Programm, insbesondere Anwendungsprogramm AP 1, Unterprogramm etc., besitzt folgende Zugriffsrechte, realisiert über die Speicherschutzeinrichtung SSE: Lesen, Schreiben, nicht: Ausführen. Die empfangende bzw. zweite Zone Z2 bzw. das zweite der vertrauenswürdigen Zone Z2 zugeordnete Programm, insbesondere Anwendungsprogramm AP2, Unterprogramm etc., besitzt keine Zugriffsrechte auf den ersten Pufferspeicherbereich TB1b, B3‘, realisiert über die Speicherschutzeinrichtung SSE, also weder Lesen, Schreiben noch Ausführen. Es ist ein zweiter Pufferspeicherbereich TB2a, B1_2 für die zweite bzw. empfangende Zone Z2 vorgesehen. Die empfangende bzw. zweite Zone Z2 bzw. das zweite der vertrauenswürdigen Zone Z2 zugeordnete Programm, insbesondere Anwendungsprogramm AP2, Unterprogramm etc., besitzt folgende Zugriffsrechte, realisiert über die Speicherschutzeinrichtung SSE: Lesen, Schreiben, nicht: Ausführen. Die sendende bzw. erste Zone Z1 bzw. zugehöriges erstes Programm besitzt keine Zugriffsrechte, realisiert über die Speicherschutzeinrichtung SSE, also weder Lesen, Schreiben noch Ausführen.
Zum Datenaustausch von sendender bzw. erster Zone Z1 zu empfangender bzw. zweiter Zone Z2 ist ein Austausch-Pufferspeicherbereich TB1a, TB2b, B3“ vorgesehen. Die sendendende bzw. erste Zone Z1 bzw. erstes Programm besitzt für den Austausch-Pufferspeicherbereich TB1a, TB2b, B3“ folgende Zugriffsrechte, realisiert über die Speicherschutzeinrichtung SSE: Schreiben. Die empfangende bzw. zweite Zone Z2 bzw. zweites Programm besitzt für den Austausch-Pufferspeicherbereich TB1a, TB2b, B3“ folgende Zugriffsrechte, realisiert über die Speicherschutzeinrichtung SSE: Lesen.
Für den Datenaustausch zwischen sendender Zone Z1 und empfangender Zone Z2 und Nutzung oder Weiterleitung in der empfangenden Zone Z2 ergibt sich folgende Prozedur. Zunächst werden die Daten aus dem ersten Pufferspeicherbereich TB1b, B3‘ von der sendenden Zone Z1 in den Austausch- Pufferspeicherbereich TB1a, TB2b, B3“ geschrieben. Anschließend werden die Daten von der empfangenden Zone Z2 per Lesezugriff auf den Austausch- Pufferspeicherbereich TB1a, TB2b, B3“ validiert (Prüfung der Gültigkeit). Falls die Daten gültig sind, werden diese von der empfangenden Zone Z2 als vertrauenswürdig gewertet und in den zweiten Pufferspeicherbereich TB2a, B1_2 für die empfangende Zone Z2 kopiert. Die weitere Nutzung und Weiterleitung von vertrauenswürdigen Daten erfolgt ausgehend vom zweiten Pufferspeicherbereich TB2a, B1_2 für die empfangende Zone Z2 in der empfangenden Zone Z2.
Das beschriebene Verfahren ist zwingend für den Daten-Austausch von der nicht-vertrauenswürdigen Zone Z1 in die vertrauenswürdige Zone Z2 anzuwenden. In der anderen Richtung (Datenaustausch von der vertrauenswürdigen Zone Z2 in die nicht-vertrauenswürdige Zone Z1) ist dieses Vorgehen optional. Für den Datenaustausch von der vertrauenswürdigen Zone Z2 in die nicht vertrauenswürdige Zone Z1 nach dem beschriebenen sicheren Verfahren ist darüber hinaus ein optionaler weiterer Austausch-Pufferspeicher TB2b, B1_1 vorgesehen, auf den ein Programm der vertrauenswürdigen Zone Z2 nur schreibenden Zugriff, die empfangende Zone Z1 nur lesenden Zugriff besitzt. Ansonsten läuft das Austauschverfahren sinngemäß ab wie beschrieben.
Wie bereits beschrieben erfolgt die Zugriffsrechte-Verwaltung (bezüglich Leserechte, Schreibrechte, Ausführungsrechte) auf die Pufferspeicher (erster Pufferspeicherbereich TB1b, B3; zweiter Pufferspeicherbereich TB2a, B1_2; Austausch-Pufferspeicherbereich TB1a, TB2b, B3“) durch die Speicherschutzeinrichtung SSE. Für sämtliche drei Pufferarten (erster Pufferspeicherbereich TB1b, B3‘; zweiter Pufferspeicherbereich TB2a, B1_2; Austausch-Pufferspeicherbereich TB1a, TB2b, B3“) sollen die Ausführungsrechte für jede Zone Z1, Z2 unterbunden werden. Die Konfiguration der Speicherschutzeinrichtung SSE und damit die Zugriffsrechte auf die jeweiligen Puffertypen und Zuordnung von Zonen Z1, Z2 erfolgt statisch und authentisch zum Boot-Vorgang. Dies bedeutet, dass keine Änderung der Konfiguration zur Laufzeit bzw. nach erstmaliger Konfiguration nach dem Booten möglich ist.
Jeglicher Zugriff auf einen der Puffer (erster Pufferspeicherbereich TB1b, B3‘; zweiter Pufferspeicherbereich TB2a, B1_2; Austausch-Pufferspeicherbereich TB1a, TB2b, B3“) erfolgt immer über die Speicherschutzeinrichtung SSE. Dies bedeutet, dass jegliche invalide Zugriffsanforderung durch eine Zone Z1, Z2 durch die Speicherschutzeinrichtung SSE unterbunden wird (beispielsweise ein Schreibzugriff durch die erste Zone Z1 auf den zweiten Pufferspeicherbereich TB2a, B1_2 der zweiten Zone T2 beispielsweise bei einem Puffer-Überlauf (sog. buffer-overflow).
Bei weiteren bevorzugten Ausführungsformen, vgl. Fig. 2J, ist vorgesehen, dass das Verfahren weiter aufweist: Trennen 290 von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme AP1, AP2 und/oder Instanzen von Anwendungsprogrammen, insbesondere Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, in Abhängigkeit der wenigstens zwei Zonen Z1, Z2. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist: Verwenden 292 eines Betriebssystems BS für eingebettete Systeme, insbesondere eines Lightweight Embedded Operating System BS, zum Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme AP1, AP2 und/oder Instanzen AP1J1, AP2J2 von Anwendungsprogrammen, wobei insbesondere jeweils einem Rechenkern der Recheneinrichtung 100, 100a ein Betriebssystem BS zugeordnet ist, s. Fig. 4.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren alternativ oder ergänzend zu dem Schritt 292 gemäß Fig. 2J weiter aufweist: Verwenden 294 eines Supervisors SV für eingebettete Systeme, vgl. Fig. 5, insbesondere eines Lightweight Embedded Supervisor SV, zum Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei insbesondere jeweils einem Rechenkern 102c (Fig. 5) der Recheneinrichtung ein Supervisor SV zugeordnet ist.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Betriebssystem BS und/oder der Supervisor SV eine Zuweisung von Rechenzeitressourcen, vorzugsweise nur, für vordefinierte Tasks (Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen und/oder Teile hiervon), insbesondere unter Verwendung einer statischen (nicht veränderbaren) Taskliste, ausführt bzw. ausführen. Mit anderen Worten ist bei weiteren bevorzugten Ausführungsformen ausschließlich ein Scheduling von vordefinierten Tasks möglich, was die Sicherheit weiter steigert.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Betriebssystem BS (Fig. 4) und/oder der Supervisor SV (Fig. 5) eine Zuweisung von Rechenzeitressourcen in Abhängigkeit von a) wiederholten, insbesondere periodisch wiederholten, Unterbrechungsanforderungen (Interrupt requests, z.B. von Zeitgeber-Interrupts) und/oder b) ereignisgesteuerten Unterbrechungsanforderungen ausführt, wobei insbesondere Tasks von wenigstens einer Unterbrechungsroutine (Interrupt Service routine, ISR, ein Computerprogramm, das bei dem Auftreten einer Unterbrechungsanforderung ausgeführt wird) aus aktiviert werden. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass bei dem Eintreten in eine Unterbrechungsroutine Konfigurationsdaten für wenigstens eine Speicherschutzeinrichtung M1, M2, SSE, insbesondere hardwaregesteuert, verändert werden.
Bei weiteren bevorzugten Ausführungsformen kann das Lightweight Embedded OS BS (Fig. 4) respektive der Lightweight Embedded Supervisor SV (Fig. 5) z.B. zyklisch oder Ereignis-basiert auszuführende (Proxy-)Funktionalitäten (Tasks) koordinieren und/oder orchestrieren ("Scheduling").
Bei weiteren bevorzugten Ausführungsformen weist das Lightweight Embedded OS BS sowie der Lightweight Embedded Supervisor insbesondere wenigstens eine der nachstehenden Eigenschaften auf: a) Minimierung von Angriffsoberfläche durch Reduktion von Komplexität (Code- Umfang, Funktionalität, Flexibilität etc.) auf notwendiges Minium b) Scheduling von ausschließlich vordefinierten Tasks (statische Task-Liste, keine dynamische Taskliste möglich), Scheduling basiert z.B. auf ISR mit z.B. zyklischen Interrupt Requests (IRQ), bspw. timer IRQ und/oder event (Ereignis)-basierte IRQs - bspw. Rx (Empfangs-) IRQ, Tx (Sende-) IRQ, SW (Software-) IRQ etc., Tasks werden von ISR aus aktiviert, c) Bei Eintreten in ISR erfolgt bevorzugt eine hardwaregesteuerte Umschaltung in den Supervisor Mode: z.B. Umschaltung auf statisches Konfigurationsdatenset für den Supervisor Mode, bevorzugt ist eine Umschaltung zwischen statischen Konfigurationsdatensets (z.B. für User Modes) ausschließlich in Supervisor Mode möglich, d) weiter bevorzugt erfolgt vor der Aktivierung eines Tasks eine Umschaltung von dem Supervisor Mode zu dem User Mode, wobei insbesondere eine Ausführung von Tasks (z.B. Teile von (Instanzen von) Anwendungsprogrammen) im User Mode erfolgt, wobei weiter insbesondere keine Umschaltung zwischen (statischen) Konfigurationsdatensets in dem User Mode bzw. in Tasks möglich ist. e) Vorteilhaft ist bei weiteren bevorzugten Ausführungsformen bereits implizit durch eine statische (und ggf. insbesondere auch integre und authentische) Konfiguration der Speicherschutzeinrichtung(en), z.B. während eines Startzyklus, ermöglicht, dass keine dynamische Rekonfiguration von Speicherschutzeinrichtungen mittels einer für den Supervisor Mode vorgesehenen Unterbrechungsroutine (ISR) erfolgen kann (z.B. von Lightweight Embedded OS BS / Supervisor SV).
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2K: Überwachen 300, insbesondere mittels des Betriebssystems BS (Fig. 4) und/oder des Supervisors SV (Fig. 5), wenigstens eines der folgenden Elemente, insbesondere auf eine potentielle Kompromittierung: a) erste Zone Z1, b) ein der ersten Zone Z1 zugeordnetes Anwendungsprogramm AP1, c) eine der ersten Zone Z1 zugeordnete Instanz AP1J1 eines Anwendungsprogramms AP1, wobei insbesondere das Überwachen 300 umfasst: Auswerten 302 (Fig. 2K) eines Stapelspeichers ("stack") und/oder Auswerten 304 eines Programmzählers ("program counter", PC), wobei vorzugsweise das Auswerten 302 des Stapelspeichers und/oder das Auswerten 304 des Programmzählers vor einer Aktivierung des Anwendungsprogramms und/oder der Instanz des Anwendungsprogramms erfolgt.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2L: Überwachen 300, s.o. zu Fig. 2K, und Einleiten 305 einer Fehlerreaktion, insbesondere dann, wenn das Überwachen 300 auf eine potentielle Kompromittierung schließen lässt.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Fehlerreaktion bzw. das Einleiten 305 der Fehlerreaktion wenigstens eines der folgenden Elemente aufweist, vgl. Fig. 2M: a) Versetzen der ersten Zone Z1 und/oder des der ersten Zone Z1 zugeordneten Rechenkerns 102b (Fig. 1) in einen sicheren Zustand, insbesondere mittels Deaktivieren 305a des der ersten Zone Z1 zugeordneten Rechenkerns 102b und/oder Resetieren 305b des der ersten Zone Z1 zugeordneten Rechenkerns 102b und/oder Versetzen 305c in einen Fehlermodus, b) Erzeugen 305d eines Fehlereintrags FE und/oder c) Weiterleiten 305e eines bzw. des Fehlereintrags an ein Angriffserkennungssystem, insbesondere Intrusion Detection System. Bei weiteren bevorzugten Ausführungsformen kann das IDS z.B. intern und/oder extern bezüglich der Recheneinrichtung 100, 100a angeordnet sein. Bei weiteren bevorzugten Ausführungsformen kann das IDS z.B. auch eine verteilte Implementierung aufweisen, wobei z.B. erste Teilfunktionalitäten (wie z.B. IDS Sensoren und ggf. ein IDS Master) auf einer bzw. der Recheneinrichtung bzw. wenigstens einem Rechenkern der Recheneinrichtung implementiert sind bzw. ausgeführt werden, und wobei insbesondere andere Teile bzw. weitere Teilfunktionalität(en) optional in einer anderen Vorrichtung, z.B. einem Backend, implementiert sind. Bei weiteren bevorzugten Ausführungsformen kann das Backend z.B. auch dazu ausgebildet sein, wenigstens einen der folgenden Aspekte zu implementieren: a) tiefgehende Experten-Analyse, b) künstliche Intelligenz (Kl), c) Machine Learning (ML), etc..
Bei weiteren bevorzugten Ausführungsformen, vgl. Fig. 2N, ist vorgesehen, dass die Recheneinrichtung 100, 100a zumindest zeitweise einen Kaltstart 310 ausführt, wobei insbesondere während des Kaltstarts 310 Daten und/oder Programmcode aus einem nichtflüchtigen Speicher 1032 (Fig. 3) geladen werden, und wobei die Recheneinrichtung 100, 100a zumindest zeitweise einen Warmstart 312 (Fig. 2N) ausführt, wobei insbesondere während des Warmstarts 312 Daten und/oder Programmcode aus einem zumindest zeitweise bestromten, flüchtigen Speicher 1030 (Fig. 3) geladen werden, wobei insbesondere während des Kaltstarts 310 (Fig. 2N) wenigstens eine Speicherschutzeinrichtung bzw. die wenigstens eine Speicherschutzeinrichtung konfiguriert wird, vgl. Schritt 311 aus Fig. 2N, und/oder wobei insbesondere (auch) während des Warmstarts 312 die wenigstens eine Speicherschutzeinrichtung konfiguriert wird, vgl. Schritt 313 aus Fig. 2N.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass ausschließlich derjenige Rechenkern 102a, 102b, 102c, 102n, dem eine dedizierte Speicherschutzeinrichtung M1, M2, M3, M4 bereitgestellt worden ist (vgl. Schritt 231 aus Fig. 2D), diese dedizierte Speicherschutzeinrichtung M1,
M2, M3, M4 konfiguriert (Schritt 231a aus Fig. 2D).
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 20 (Ziffer "2", Buchstabe "O"): Zuweisen 212a von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Zuweisen 212b von Rechenzeitressourcen für Instanzen von Anwendungsprogrammen, wobei der Supervisor SV und/oder eine dem Supervisor SV entsprechende Funktionalität zumindest teilweise mittels der Supervisor-Instanz SVI (Fig. 1) realisiert ist.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2P: Prüfen 320 einer Integrität und/oder Authentizität von Konfigurationsdaten KD, die einen Betrieb wenigstens einer Speicherschutzeinrichtung steuern, insbesondere mittels wenigstens einem der folgenden Elemente: a) Verifizieren 322 eines für die Konfiguration der wenigstens einer Speicherschutzeinrichtung verwendbaren Programmcodes, b) Verifizieren 324 der Konfigurationsdaten, c) Persistieren 326 eines bzw. des für die Konfiguration der wenigstens einen Speicherschutzeinrichtung verwendbaren Programmcodes, d) Persistieren 328 der Konfigurationsdaten.
Bei weiteren bevorzugten Ausführungsformen kann das Persistieren 326, 328 z.B. ein Vorsehen des für die Konfiguration der wenigstens einen Speicherschutzeinrichtung verwendbaren Programmcodes bzw. der Konfigurationsdaten in einem Festwertspeicher, z.B. einem ROM oder einem OTP (one time programmable, einmalig programmierbarer Speicher), aufweisen.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2Q: zumindest zeitweises Ausführen 330 eines Secure-Boot-Verfahrens und/oder zumindest zeitweises Ausführen 332 eines Verfahrens zur Manipulationserkennung während der Laufzeit (RTMD, runtime manipulation detection), insbesondere durch wenigstens einen Rechenkern der Recheneinrichtung 100, 100a. Die Verfahren 330, 332 können beispielsweise das Vergleichen eines tatsächlich vorhandenen Speicherinhalts wenigstens eines Teils des Speichers 1030, 1032 mit einem vorgebbaren Referenz-Speicherinhalt aufweisen, wobei das Vergleichen beispielsweise auch eine Hashwert-Bildung und/oder Nutzung von CMAC (cipher-based message authentication code)-Verfahren und/oder Nutzung von Signaturen bzw. signierten Hashwerten aufweisen kann.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweist, vgl. Fig. 2R: Steuern 340 eines Zugriffs eines Programms bzw. Anwendungsprogramms AP1, AP2 auf wenigstens eines der folgenden Elemente in Abhängigkeit wenigstens einer Zone Z1, Z2: a) interne Schnittstelle, insbesondere Software-Schnittstelle, der Recheneinrichtung, b) interne und/oder externe Hardwareschnittstelle der Recheneinrichtung, c) Hardware-Sicherheitsmodul und/oder Kryptografiemodul zur Ausführung kryptografischer Funktionen, d) Peripheriegeräte der Recheneinrichtung, insbesondere Spezialfunktionsregister wenigstens eines Peripheriegeräts, e) interne Schnittstellen eines Zielsystems für die Recheneinrichtung, insbesondere eines Steuergeräts, f) externe Schnittstellen eines Zielsystems für die Recheneinrichtung, insbesondere eines Steuergeräts, g) Adressierungselemente für Kommunikationsprotokolle, insbesondere auf wenigstens einer Schicht des ISO/OSI-Schichtenmodells. Der optionale Schritt 342 gemäß Fig. 2R deutet beispielhaft eine (weitere) Ausführung des betreffenden Anwendungsprogramms in der ihm zugeordneten Zone an.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter wenigstens eines der folgenden Elemente aufweist, vgl. Fig. 2S: a) Einführen 350 wenigstens eines zusätzlichen, insbesondere nicht bereits existierenden, Zone, b) Verschieben 352 von Funktionalitäten von einem ersten Rechenkern 102a zu wenigstens einem weiteren Rechenkern 102b der Recheneinrichtung 100, 100a, c) Ausführen 354 einer Kommunikation zwischen wenigstens zwei Zonen unter Verwendung eines, insbesondere in die Recheneinrichtung integrierten, Arbeitsspeichers, d) Definieren 360, vgl. Fig. 2T, wenigstens einer vertrauenswürdigen Zone und, optional, Überwachen 362 wenigstens einerweiteren, insbesondere nicht vertrauenswürdigen, Zone, durch wenigstens ein der vertrauenswürdigen Zone zugeordnetes Anwendungsprogramm.
Nachfolgend sind unter Bezugnahme auf die Figuren 6 bis 21 weitere bevorzugte Ausführungsformen, Aspekte und Vorteile des Prinzips gemäß den Ausführungsformen beschrieben, die - gemäß weiteren bevorzugten Ausführungsformen - jeweils einzeln für sich oder in Kombination miteinander mit wenigstens einer der vorstehend beschriebenen Ausführungsformen kombinierbar sind.
Figur 6 zeigt schematisch Aspekte einer Unterbrechungsroutine ISR1 gemäß weiteren bevorzugten Ausführungsformen, wie sie z.B. zumindest zeitweise durch wenigstens einen Rechenkern 102a, 102b, .. der Recheneinrichtung 100, 100a ausführbar sind. Das Blitzsymbol IRQ in Fig. 6 symbolisiert eine auftretende Unterbrechungsanforderung (Interrupt request), wie sie z.B. zyklisch (z.B. vorgebbar durch Zeitgeberbaustein (Timer)) und/oder ereignisgesteuert (z.B. Eintreffen einer Nachricht an einer Kommunikationsschnittstelle) erzeugt werden kann. Bei weiteren bevorzugten Ausführungsformen wird daraufhin die Unterbrechungsroutine ISR1 ausgeführt, die wenigstens eines der folgenden Elemente aufweist: e1) zumindest zeitweises Speichern eines Kontexts des durch die Unterbrechungsanforderung IRQ unterbrochenen Tasks bzw. Programms, z.B. auf dem Stapelspeicher (kann z.B. in einem vorgebbaren Bereich des RAM 1030 definiert sein), e2) Identifizieren eines nachfolgend auszuführenden Tasks, e3) Umschalten von einer aktuellen Betriebsart, z.B. Supervisor Mode, zu einer anderen Betriebsart, z.B. User Mode, e4) Wiederherstellen des Tasks für die identifizierte Zone.
Bei weiteren bevorzugten Ausführungsformen kann die Unterbrechungsroutine ISR1 gemäß Fig. 6 beispielhaft durch das Betriebssystem BS (Fig. 4), insbesondere bei einer Inter-Core-Zonen-Separation, verwendet werden.
Figur 7 zeigt schematisch Aspekte einer Unterbrechungsroutine ISR2 gemäß weiteren bevorzugten Ausführungsformen, wie sie z.B. zumindest zeitweise durch wenigstens einen Rechenkern 102a, 102b, .. der Recheneinrichtung 100, 100a ausführbar sind.
Das Blitzsymbol IRQ' in Fig. 7 symbolisiert eine auftretende Unterbrechungsanforderung (Interrupt request), wie sie z.B. zyklisch (z.B. vorgebbar durch Zeitgeberbaustein (Timer)) und/oder ereignisgesteuert (z.B. Eintreffen einer Nachricht an einer Kommunikationsschnittstelle) erzeugt werden kann. Bei weiteren bevorzugten Ausführungsformen wird daraufhin die Unterbrechungsroutine ISR2 ausgeführt, die wenigstens eines der folgenden Elemente aufweist: eT) zumindest zeitweises Speichern eines Kontexts des durch die Unterbrechungsanforderung IRQ' unterbrochenen Tasks bzw. Programms, z.B. auf dem Stapelspeicher, optional: e5) Ausführen einer Auswertung z.B. des Stapelspeichers (vgl. z.B. Schritt 302 aus Fig. 2K) und/oder des Programmzählers (vgl. z.B. Schritt 304 aus Fig. 2K), e6) Identifizieren eines nachfolgend auszuführenden Tasks, e7) Umschalten des Kontexts zu einer identifizierten Zone (z.B. aus dem vorangehenden Schritt e6), wobei die identifizierte Zone mit dem identifizierten nachfolgend auszuführenden Task assoziiert ist) (alternativ kann die Umschaltung bei weiteren bevorzugten Ausführungsformen z.B. auch adressbasiert erfolgen, z.B. mittels CAN ID, VLAN ID, MAC-Adresse o.Ä.), e8) Umschalten von einer aktuellen Betriebsart, z.B. Supervisor Mode, zu einer anderen Betriebsart, z.B. User Mode, e9) Wiederherstellen eines Kontexts für den nachfolgenden Task.
Bei weiteren bevorzugten Ausführungsformen kann die Unterbrechungsroutine ISR2 gemäß Fig. 7 beispielhaft durch den Supervisor SV (Fig. 5), insbesondere bei einer Intra-Core-Zonen-Separation, verwendet werden.
Figur 8 zeigt schematisch ein Ablaufdiagramm gemäß weiteren bevorzugten Ausführungsformen, wobei das Bezugszeichen 310' beispielhaft Aspekte eines Kaltstarts der Recheneinrichtung 100, 100a bezeichnet, und wobei das Bezugszeichen 312' beispielhaft Aspekte eines Warmstarts der Recheneinrichtung 100, 100a bezeichnet. Bei dem Kaltstart 310' ist z.B. ein Prüfmuster für eine Verifizierung des Inhalts des RAM 1030 (Fig. 3) nicht verfügbar. Bei dem Warmstart 312' ist z.B. ein Prüfmuster für eine Verifizierung des Inhalts des RAM 1030 (Fig. 3) verfügbar.
Bei weiteren bevorzugten Ausführungsformen kann im Rahmen eines mindestens einmalig zu durchlaufenden Kaltstarts ein Prüfmuster respektive Pattern in den insbesondere in einem Power-Down-Mode versorgten flüchtigen Speicher geschrieben werden. Aufgrund der genannten Versorgung wird somit das genannten Prüfmuster bzw. Pattern in dem an sich flüchtigen Speicher erhalten. Dieses (RAM) Pattern wird bei weiteren bevorzugten Ausführungsformen bei wenigstens einem, insbesondere jedem, Startzyklus von einer System State Machine (Zustandsautomat, der bei weiteren bevorzugten Ausführungsformen z.B. zur Steuerung von Systemzuständen nutzbar ist) geprüft, und insbesondere kann in Abhängigkeit von der Existenz des Prüfmusters ein Kaltstart (z.B. wenn (RAM) Pattern nicht vorhanden ist) oder ein Warmstart (z.B. wenn das (RAM) Pattern vorhanden ist) durchgeführt werden.
Bei weiteren bevorzugten Ausführungsformen wird somit eine Integrität und Authentizität der im Power-Down-Mode versorgten flüchtigen Speicher bzw. ihrer darin enthaltenen bzw. liegenden Daten und Funktionalitäten (z.B. Rechenkern 102c und/oder Konfigurationsdaten der Speicherschutzeinrichtung, insbesondere für die erste und/oder zweite Zone und/oder ein Programmcode) im Rahmen des mindestens einmalig zwingend zu durchlaufenden, vorhergehenden Kaltstarts (Secure Boot und/ oder Starten aus OTP-Speicher- s.o.) sichergestellt.
Bei weiteren bevorzugten Ausführungsformen impliziert somit eine invalide Manipulation der im Power-Down-Mode im versorgten flüchtigen Speicher liegenden Daten und Funktionalitäten sowie des RAM Patterns eine zumindest zeitweise Versorgungsunterbrechung und damit eine Löschung des im Power- Down-Mode versorgten flüchtigen Speichers (RAM Pattern etc.). Bei weiteren bevorzugten Ausführungsformen würde die System State Machine demgemäß im Rahmen des Startzyklus aufgrund des fehlenden RAM Patterns, insbesondere automatisch, einen Kaltstart (Secure Boot und/ oder Starten aus OTP - s.o.) anstoßen, womit die Integrität und Authentizität der im Power-Down-Mode versorgten flüchtigen Speicher bzw. ihrer Daten und Funktionalitäten vor deren Nutzung oder Ausführung gewährleistet ist.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass bei der Existenz des Prüfmusters z.B. im Rahmen eines Warmstarts ausgewählte zeitkritische SW-lnstanzen nicht vor deren Ausführung geprüft werden (also z.B. insbesondere kein Secure Boot), sondern ggf. erst zur Laufzeit/ nach deren Ausführung. Hierdurch wird vorteilhaft eine Startup Zeit für zeitkritische SW- lnstanzen beim Warmstart beschleunigt. Die Integrität und Authentizität während des Warmstarts wird somit bei weiteren bevorzugten Ausführungsformen vorteilhaft auch ohne explizite Prüfung während des Warmstarts implizit durch die Verfügbarkeit des Prüfmusters (und damit Prüfung während des vorherigen Kaltstarts) sichergestellt. Zeitunkritische Komponenten können bei weiteren bevorzugten Ausführungsformen auch während des Warmstarts explizit vor deren Exekution (z.B. mittels eines Secure Boot-Prozesses) geprüft werden.
Block 102a_1 symbolisiert beispielhaft den ersten Rechenkern 102a der Recheneinrichtung (Fig. 3) als "root of trust", also vergleichbar zu einer Hardware-Sicherheitsreferenz analog zu einem TPM (trusted platform module) oder einem Hardware-Sicherheitsmodul (HSM), Block 102a_2 repräsentiert einen Boot-Manager (Systemprogramm, das ein Laden und/oder Ausführen von weiteren System- und oder Anwendungsprogrammen steuert) assoziiert mit dem Rechenkern 102a. Block 102a_3 repräsentiert eine Ausführung von Programmcode assoziiert mit Zone Z2 und Rechenkern 102a. Block 110 repräsentiert ein Hardware-Sicherheitsmodul. Block 111 repräsentiert einen Boot-Manager assoziiert mit dem Rechenkern 102c. Block 112 repräsentiert eine Ausführung von Programmcode assoziiert mit den Zonen Z1, Z2 und Rechenkern 102c (der beispielhaft und wie vorstehend bereits mehrfach beschrieben beiden Zonen Z1, Z2 zugeordnet ist). Block 113 repräsentiert einen Boot-Manager assoziiert mit dem Rechenkern 102b. Block 114 repräsentiert eine Ausführung von Programmcode assoziiert mit der Zone Z1 und mit dem Rechenkern 102b. Block 115 repräsentiert einen Boot-Manager assoziiert mit dem Rechenkern 102n. Block 116 repräsentiert eine Ausführung von Programmcode assoziiert mit den Zonen Z1, Z2 und Rechenkern 102n.
Pfeil a1 symbolisiert einen Bootvorgang (Hochfahren der Recheneinrichtung 100a z.B. aus einem vollständig deaktivierten Zustand). Pfeil a2 symbolisiert eine Konfiguration wenigstens einer Speicherschutzeinrichtung, insbesondere einer zentralen bzw. dem Bussystem 101 (Fig. 3) zugeordneten Speicherschutzeinrichtung M5_1, M5_2, .., M5_8. Pfeil a3 symbolisiert einen Start des Bootmanagers für den Rechenkern 102c, vgl. auch Block 111.
Pfeil a4 symbolisiert eine Konfiguration wenigstens einer dedizierten Speicherschutzeinrichtung M3 (Fig. 3) für den Rechenkern 102c. Pfeil a5 symbolisiert den Start einer Ausführung 112 von Programmcode durch den Rechenkern 102c. Pfeil a6 symbolisiert eine optionale Verifikation des Rechenkerns 102c, z.B. in Form einer RTMD. Bei weiteren bevorzugten Ausführungsformen kann die optionale Verifikation der Konfigurationsdaten der Speicherschutzeinrichtung M3 insbesondere mittels kryptographischer Verfahren, z.B. basierend auf CMACs und/oder signierten Hashwerten, ausgeführt werden.
Pfeil a7 symbolisiert ebenfalls eine optionale Verifikation des Rechenkerns 102c, im Kontext eines Kaltstarts 310'. Bei weiteren bevorzugten Ausführungsformen kann die optionale Verifikation a7 mittels kryptographischer Verfahren, z.B. basierend auf CMACs und/oder signierten Hashwerten, ausgeführt werden. Pfeil a8 symbolisiert einen Start des Bootmanagers für den Rechenkern 102c, ähnlich zu Pfeil a3, vgl. auch Block 111. Pfeil a9 symbolisiert, insbesondere ähnlich zu Pfeil a4, die Konfiguration der wenigstens einen dedizierten Speicherschutzeinrichtung M3 (Fig. 3) für den Rechenkern 102c. Pfeil a10 symbolisiert den Start einer Ausführung 112 von Programmcode durch den Rechenkern 102c, ähnlich zu Pfeil a5. Pfeil a11 symbolisiert eine optionale Verifikation mehrerer, vorzugsweise aller, Rechenkerne 102a, 102b, 102n. Pfeil a12 symbolisiert einen Start des
Bootmanagers für den Rechenkern 102n, vgl. auch Block 115. Pfeil a13 symbolisiert die Konfiguration wenigstens einer dedizierten Speicherschutzeinrichtung für den Rechenkern 102n. Pfeil a14 symbolisiert den Start einer Ausführung 116 von Programmcode durch den Rechenkern 102n.
Pfeil a15 symbolisiert einen Start des Bootmanagers für den Rechenkern 102b. Pfeil a16 symbolisiert die Konfiguration wenigstens einer dedizierten Speicherschutzeinrichtung für den Rechenkern 102b. Pfeil a17 symbolisiert den Start einer Ausführung 114 von Programmcode durch den Rechenkern 102b.
Pfeil a18 symbolisiert einen Start des Bootmanagers für den Rechenkern 102a. Pfeil a19 symbolisiert die Konfiguration wenigstens einer dedizierten Speicherschutzeinrichtung für den Rechenkern 102a. Pfeil a20 symbolisiert den Start einer Ausführung 102a_3 von Programmcode durch den Rechenkern 102a.
Figur 9 zeigt schematisch Aspekte einer Unterbrechungsroutine ISR3 gemäß weiteren bevorzugten Ausführungsformen, wie sie z.B. zumindest zeitweise durch wenigstens einen Rechenkern 102a, 102b, .. der Recheneinrichtung 100, 100a ausführbar sind. Das Blitzsymbol IRQ" in Fig. 9 symbolisiert eine auftretende Unterbrechungsanforderung (Interrupt request), wie sie z.B. zyklisch (z.B. vorgebbar durch Zeitgeberbaustein (Timer)) und/oder softwarebasiert (z.B. aufgerufen durch ein Anwendungsprogramm) erzeugt werden kann. Bei weiteren bevorzugten Ausführungsformen wird daraufhin die Unterbrechungsroutine ISR3 ausgeführt, die wenigstens eines der folgenden Elemente aufweist: eT) zumindest zeitweises Speichern eines Kontexts des durch die Unterbrechungsanforderung IRQ" unterbrochenen Tasks bzw. Programms, optional: e5') Ausführen einer Auswertung z.B. des Stapelspeichers (vgl. z.B. Schritt 302 aus Fig. 2K) und/oder des Programmzählers (vgl. z.B. Schritt 304 aus Fig. 2K), e10) Umschalten des Kontexts zu einem nächsten Task (z.B. in Abhängigkeit einer vorzugsweise statischen Taskliste), e11) Umschalten von einer aktuellen Betriebsart, z.B. Supervisor Mode, zu einer anderen Betriebsart, z.B. User Mode, e12) Wiederherstellen des Tasks für die identifizierte Zone.
Figur 10 zeigt schematisch einen Rechenkern 102a gemäß weiteren bevorzugten Ausführungsformen, dem ein Betriebssystem BS und/oder Supervisor SV (ähnlich Fig. 5, nicht in Fig. 10 gezeigt) zugeordnet ist, und der selbst zwei Zonen Z1, Z2 zugeordnet ist. Der Rechenkern 102a kann z.B. für einen Netzwerkswitch verwendet werden, z.B. um Ethernet-Datenpakete zu senden und/oder zu empfangen. Entsprechende Instanzen von Anwendungsprogrammen sind mit den Bezugszeichen AP3J1 (Empfangen von Ethernetpaketen, Ausführung in der Zone Z1), AP3J2 (Empfangen von Ethernetpaketen, Ausführung in der Zone Z2), AP4J1 (Senden von Ethernetpaketen, Ausführung in der Zone Z1), AP4J2 (Senden von Ethernetpaketen, Ausführung in der Zone Z2) gekennzeichnet. Ein weiteres Anwendungsprogramm, das z.B. Managementaufgaben für den Netzwerkswitch ausführt, läuft nur in der als vertrauenswürdig definierten zweiten Zone Z2, nicht jedoch in der als nicht vertrauenswürdig definierten ersten Zone Z1. Dem Rechenkern 102a ist ein RAM 1030 zugeordnet, das bei weiteren bevorzugten Ausführungsformen z.B. vergleichbar zu Fig. 5 aufgeteilt sein kann. Optional ist eine Switching-Engine (z.B. Koppelnetz) vorgesehen und/oder ein TCAM (ternary content-adressable memory)-Modul.
Figur 11 zeigt schematisch zwei Rechenkerne 102a, 102b gemäß weiteren bevorzugten Ausführungsformen, wobei der erste Rechenkern 102a einer ersten Zone Z1 und wobei der zweite Rechenkern 102b einer zweiten Zone Z2 zugeordnet ist. Beiden Rechenkernen 102a, 102b ist jeweils ein Betriebssystem BS zugeordnet.
Erste Instanzen von verschiedenen Anwendungsprogrammen, die in Figur 11 der Übersichtlichkeit halber zusammen mit dem Bezugszeichen 11 bezeichnet sind, sind der ersten Zone Z1 und damit dem ersten Rechenkern 102a zugeordnet. Bei weiteren bevorzugten Ausführungsformen weisen die verschiedenen Anwendungsprogramme beispielsweise wenigstens eines der folgenden Elemente auf: a) Programme zur Ausführung einer Untersuchung von Datenpaketen, insbesondere zur deep packet inspection, DPI, b) Programme zur Diagnose, c) Programme zur Ausführung von Updates, insbesondere mittels FOTA (firmware over the air)-Techniken (beispielsweise mittels der Datenschnittstelle 1008, Fig. 22), d) Programme zur Angriffserkennung und Angriffsabwehr (Intrusion Detection and Prevention). Bei weiteren bevorzugten Ausführungsformen sind dem zweiten Rechenkern 102b und der zweiten Zone Z2 entsprechende zweite Instanzen I2 der vorstehend in Bezug auf die erste Zone Z1 beschriebenen Anwendungsprogramme zugeordnet. Wenigstens eine Speicherschutzeinrichtung SSE ist gemäß weiteren bevorzugten Ausführungsformen verwendbar zum Steuern der Leserechte und/oder Schreibrechte und/oder Ausführungsrechte entsprechender Anwendungsprogramme bzw. Instanzen der verschiedenen Zonen. Durch die vorstehend beispielhaft unter Bezugnahme auf Figur 11 beschriebene Konfiguration kann effizient ein besonders sicheres System zur Untersuchung von Datenpaketen bzw. zur Angriffserkennung und Angriffsabwehr, beispielsweise für elektronische Steuergeräte und/oder eingebettete Systeme und/oder loT- Systeme und dergleichen bereitgestellt werden, wobei durch die Zuordnung von den Instanzen 11, I2 der Anwendungsprogramme zu den Zonen Z1 , Z2 besonders vorteilhaft beispielsweise jeweils Kontexte für die Ausführung (Exekution) mit unterschiedlichen Vertrauensstufen bereitgestellt werden können.
Figur 12A zeigt schematisch Aspekte einer Unterbrechungsroutine ISR4 gemäß weiteren bevorzugten Ausführungsformen, wie sie z.B. zumindest zeitweise durch wenigstens einen Rechenkern 102a, 102b, .. der Recheneinrichtung 100, 100a ausführbar sind. Das Blitzsymbol Rx in Fig. 12A symbolisiert eine auftretende Unterbrechungsanforderung (Interrupt request), wie sie z.B. ereignisgesteuert, vorliegend beispielhaft bei dem Empfang einer Nachricht, z.B. einer CAN (Controller Area Network)-Nachricht, erzeugt werden kann. Bei weiteren bevorzugten Ausführungsformen wird daraufhin die Unterbrechungsroutine ISR4 ausgeführt, die wenigstens eines der folgenden Elemente aufweist: e20) zumindest zeitweises Speichern eines Kontexts des durch die Unterbrechungsanforderung Rx unterbrochenen Tasks, insbesondere eines Sendetasks ("Tx task"), beispielsweise zum Aussenden von Nachrichten, bzw. Programms, optional: e21) Ausführen einer Auswertung z.B. des Stapelspeichers (vgl. z.B. Schritt 302 aus Fig. 2K) und/oder des Programmzählers (vgl. z.B. Schritt 304 aus Fig. 2K), e22) Ermitteln einer Zone, mit der ein empfangener Datenrahmen (z.B. der genannten empfangenen CAN- Nachricht) assoziiert ist, e23) Umschalten des Kontexts zu der in Schritt e22 ermittelten Zone, e24) Umschalten von einer aktuellen Betriebsart, z.B. Supervisor Mode, zu einer anderen Betriebsart, z.B. User Mode, e25) Aufrufen einer Behandlungsroutine für den Nachrichtenempfang ("Receive (Rx) handler"), also beispielsweise eines Anwendungsprogramms bzw. eines Teils eines Anwendungsprogramms, dass die empfangene Nachricht verarbeitet, e26) Wiederherstellen des Tasks (z.B. Sendetasks) für die identifizierte Zone.
Bei weiteren bevorzugten Ausführungsformen werden Sendetasks, also Aufgaben bzw. Anwendungsprogramme bzw. Teile von Anwendungsprogrammen zum Aussenden von Nachrichten, geplant ("scheduling").
Bei weiteren bevorzugten Ausführungsformen werden Unterbrechungsanforderungen, die den Empfang einer Nachricht charakterisieren, ("Rx IRQ", receive Interrupt request), mit einer höheren Priorität bearbeitet als andere Unterbrechungsanforderungen, die beispielsweise von Zeitgebern (Timer) und/oder Anwendungsprogrammen bzw. Software allgemein ausgelöst werden.
Bei weiteren bevorzugten Ausführungsformen werden gleichzeitig oder innerhalb eines vorgebbaren ersten Zeitbereichs eingehende
Unterbrechungsanforderungen priorisiert, beispielsweise in Abhängigkeit der Quelle der Unterbrechungsanforderung (eingehende Nachricht, Zeitgeber, Software) und/oder in Abhängigkeit von einem oder mehreren anderen bzw. weiteren Kriterien. Bei weiteren bevorzugten Ausführungsformen kann eine derartige Priorisierung beispielsweise durch eine Steuereinrichtung für Unterbrechungsanforderungen (englisch: Interrupt Controller) ausgeführt werden.
Bei weiteren bevorzugten Ausführungsformen kann das Umschalten des Kontexts, vergleiche beispielsweise Schritt e23 von Fig. 12A, ausschließlich in einer vorgebbaren Betriebsart, insbesondere in dem Supervisor Mode, erfolgen.
Die vorstehend beispielhaft unter Bezugnahme auf Figur 12A beschriebenen Aspekte können bei weiteren bevorzugten Ausführungsformen beispielsweise dazu genutzt werden, die Verarbeitung von eingehenden Nachrichten für einen lightweight Supervisor, insbesondere einen CAN lightweight Supervisor, zumindest zeitweise zu steuern.
Figur 12B zeigt schematisch Aspekte einer Unterbrechungsroutine ISR5 gemäß weiteren bevorzugten Ausführungsformen, wie sie z.B. zumindest zeitweise durch wenigstens einen Rechenkern 102a, 102b, .. der Recheneinrichtung 100, 100a ausführbar sind. Das Blitzsymbol TIM_SW in Fig. 12B symbolisiert eine auftretende Unterbrechungsanforderung (Interrupt request), wie sie z.B. durch einen Zeitgeber oder ein Anwendungsprogramm bzw. allgemein Software, erzeugt werden kann. Bei weiteren bevorzugten Ausführungsformen wird daraufhin die Unterbrechungsroutine ISR5 ausgeführt, die wenigstens eines der folgenden Elemente aufweist: e30) zumindest zeitweises Speichern eines Kontexts des durch die Unterbrechungsanforderung Rx unterbrochenen Tasks, insbesondere eines Sendetasks ("Tx task"), beispielsweise zum Aussenden von Nachrichten, bzw. Programms, optional: e31) Ausführen einer Auswertung z.B. des Stapelspeichers (vgl. z.B. Schritt 302 aus Fig. 2K) und/oder des Programmzählers (vgl. z.B. Schritt 304 aus Fig. 2K), e32) Umschalten des Kontexts zu einem nächsten Sendetask (z.B. gemäß einer insbesondere statischen Taskliste), e33) Umschalten von einer aktuellen Betriebsart, z.B. Supervisor Mode, zu einer anderen Betriebsart, z.B. User Mode, e34) Wiederherstellen des Tasks (z.B. Sendetasks) für die identifizierte Zone.
Die vorstehend beispielhaft unter Bezugnahme auf Figur 12A beschriebenen weiteren Aspekte gelten bei weiteren bevorzugten Ausführungsformen für die Unterbrechungsroutine ISR5 gemäß Figur 12B in entsprechender weise.
Figur 13 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten einer Recheneinrichtung 100b gemäß weiteren bevorzugten Ausführungsformen. Die Recheneinrichtung 100b weist vorliegend beispielhaft vier Rechenkerne K1, K2, K3, K4 auf, von denen der erste Rechenkern K1 zur Verarbeitung von Kommunikationsnachrichten, insbesondere CAN-Nachrichten, ausgebildet ist. Daher kann bei weiteren bevorzugten Ausführungsformen der erste Rechenkern K1 gemäß Figur 13 auch als "CAN-Core" bezeichnet werden. Die weiteren Rechenkerne K2, K3 sind zur Ausführung von (gegebenenfalls unterschiedlichen Instanzen von) Anwendungsprogrammen vorgesehen und können bei weiteren bevorzugten Ausführungsformen daher auch als "Anwendungskerne" bzw. englisch "Application Cores" K2, K3 bezeichnet werden. Der vierte Rechenkern K4 gemäß Figur 13 ist zur Verarbeitung von Ethernet- Kommunikationsnachrichten ausgebildet und kann daher bei weiteren bevorzugten Ausführungsformen auch als Ethernet-Kern bzw. ETH-Kern bzw. englisch als "ETH Core" K4 bezeichnet werden. Dem ersten Rechenkern K1 ist ein erster Supervisor SV1, insbesondere ein CAN lightweight Supervisor, zugeordnet, und den vierten Rechenkern K4 ist ein zweiter Supervisor SV2, insbesondere ein ETH (Ethernet) lightweight Supervisor, zugeordnet. Bei weiteren bevorzugten Ausführungsformen ist der erste Rechenkern K1 zwei Zonen Z1 , Z2 zugeordnet. Bei weiteren bevorzugten Ausführungsformen ist auch der vierte Rechenkern K4 zwei Zonen Z1 , Z2 zugeordnet.
Bei weiteren bevorzugten Ausführungsformen ist dem ersten Rechenkern K1 ein Anwendungsprogramm zum Senden und/oder Empfangen von CAN-Nachrichten zugeordnet, wobei das Bezugszeichen 11 in Figur 13 eine erste Instanz (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) dieses Anwendungsprogramms bezeichnet, welche erste Instanz 11 der ersten Zone Z1 zugeordnet und zum Empfangen von CAN-Nachrichten ausgebildet ist. Das Bezugszeichen I2 bezeichnet demgegenüber eine zweite Instanz (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) dieses Anwendungsprogramms, welche der zweiten Zone Z2 zugeordnet und zum Empfangen von CAN-Nachrichten ausgebildet ist. Die Bezugszeichen I3, I4 bezeichnen entsprechende Instanzen (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) zum Senden bzw. Empfangen von CAN-Nachrichten, die jeweils ebenfalls einer der beiden Zonen Z1, Z2 zugeordnet sind.
Bei weiteren bevorzugten Ausführungsformen können die vorstehend beispielhaft unter Bezugnahme auf die Figuren 12A, 12B beschriebenen Unterbrechungsanforderungen Rx, TIM_SW durch den ersten Rechenkern K1 bearbeitet werden, beispielsweise durch Ausführen einer entsprechenden Unterbrechungsroutine ISR4 (Fig. 12A) bzw. ISR5 (Fig. 12B).
Bei weiteren bevorzugten Ausführungsformen ist dem vierten Rechenkern K4 ein Anwendungsprogramm zum Senden und/oder Empfangen von Ethernet- Nachrichten zugeordnet, wobei das Bezugszeichen 11' in Figur 13 eine erste Instanz (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) dieses Anwendungsprogramms bezeichnet, welche erste Instanz 11' der ersten Zone Z1 zugeordnet und zum Empfangen von Ethernet-Nachrichten ausgebildet ist. Das Bezugszeichen I2' bezeichnet demgegenüber eine zweite Instanz (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) dieses Anwendungsprogramms, welche der zweiten Zone Z2 zugeordnet und zum Empfangen von Ethernet- Nachrichten ausgebildet ist. Die Bezugszeichen I3', I4' bezeichnen entsprechende Instanzen (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) zum Senden bzw. Empfangen von Ethernet-Nachrichten, die jeweils ebenfalls einer der beiden Zonen Z1 , Z2 zugeordnet sind. Bei weiteren bevorzugten Ausführungsformen wird eine Trennung der beiden Zonen Z1, Z2 innerhalb der Rechenkerne K1, K4 jeweils unter Verwendung mindestens einer Speicherschutzeinrichtung SSE1, SSE4 bewerkstelligt.
Wie vorstehend bereits erwähnt sind die beiden Anwendungskerne K2, K3 zur Ausführung von Anwendungsprogrammen ausgebildet, die bzw. deren einzelne Instanzen (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) in Figur 13 als Rechtecke innerhalb der betreffenden Anwendungskerne K2, K3 angedeutet, aus Gründen der Übersichtlichkeit jedoch nicht näher bezeichnet sind. Bei weiteren bevorzugten Ausführungsformen ist der zweite Rechenkern K2 der zweiten Zone Z2 zugeordnet, und der dritte Rechenkern K3 ist der ersten Zone Z1 zugeordnet.
Bei weiteren bevorzugten Ausführungsformen weist die Recheneinrichtung 100b einen flüchtigen Speicher, insbesondere einen Arbeitsspeicher (RAM) 1030b auf, der beispielsweise vergleichbar zu der Darstellung gemäß Figur 4, in unterschiedliche Bereiche, insbesondere unterschiedliche Pufferspeicherbereiche, aufgeteilt ist, welche jeweils unterschiedlichen Rechenkernen K1, K2, K3, K4 bzw. deren Zonen Z1, Z2 zugeordnet sind.
Beispielsweise ist ein erster Bereich B1 des Arbeitsspeichers 1030b der Recheneinrichtung 100b gemäß Figur 13 dem ersten Rechenkern K1 zugeordnet, wobei ein erster Teilbereich B1_1 der ersten Zone Z1 und ein zweiter Teilbereich B1_2 der zweiten Zone Z2 zugeordnet ist. Eine vergleichbare Aufteilung in entsprechende Bereiche bzw. Teilbereiche B4, B4_1, B4_2 ist bei weiteren bevorzugten Ausführungsformen auch für den vierten Rechenkern K4 möglich.
Weitere Bereiche B2, B3 des Arbeitsspeichers 1030b sind bei weiteren bevorzugten Ausführungsformen beispielsweise den Anwendungskernen K2, K3 zuordenbar. Bei weiteren bevorzugten Ausführungsformen ist beispielsweise der Bereich B2 weiter aufteilbar in einen vertrauenswürdigen Bereich B2' und in einen nicht-vertrauenswürdigen Bereich B2". Vergleichbares kann bei weiteren bevorzugten Ausführungsformen auch für den dritten Anwendungskern K3 gelten, vergleiche die Bezugszeichen B3', B3".
Bei weiteren bevorzugten Ausführungsformen können ein oder mehrere weitere Speicherschutzeinrichtungen, die in Figur 13 kollektiv mit dem Bezugszeichen SSE' bezeichnet sind, vorgesehen sein, um eine jeweilige Trennung gemäß bevorzugten Ausführungsformen hinsichtlich beispielsweise Leserechten und/oder Schreibrechte und/oder Ausführungsrechte zu realisieren.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung 100b gemäß Figur 13 beispielsweise die Funktionalität eines Gateway 432 bereitstellen, also eines Netz Kopplungselements, das beispielsweise einen CAN-Bus (vgl. den CAN Core K1) mit einem Ethernet-Netzwerk (vgl. den ETH Core K4) koppeln kann. Bei weiteren bevorzugten Ausführungsformen kann beispielsweise der erste Rechenkern K1 die Funktion einer sogenannten highspeed routing engine für CAN-Nachrichten übernehmen, und/oder der vierte Rechenkern K4 die Funktion einer sogenannten highspeed engine für Ethernet- Nachrichten.
Figur 14 zeigt schematisch ein Ablaufdiagramm gemäß weiteren bevorzugten Ausführungsformen, das beispielhaft die Verarbeitung von Unterbrechungsanforderungen, zum Beispiel bei einem Empfang von Nachrichten, insbesondere CAN- Nachrichten, veranschaulicht.
Der Block ISR6 repräsentiert beispielhaft eine Unterbrechungsroutine, die beispielsweise bei wenigstens einer der folgenden
Unterbrechungsanforderungen ausführbar ist: a) Empfang einer Nachricht ("Rx"), b) Signalisierung eines Zeitgebers ("Timer"), c) mittels Software erzeugte Unterbrechungsanforderung ("SW"). Der Block T_RX_Z1 repräsentiert beispielhaft einen Task (z.B. Teil bzw. Instanz eines Anwendungsprogramms), der der Zone Z1 zugeordnet ist und bei Empfang ("Rx") einer Nachricht ausgeführt wird, vergleichbar zu der Instanz 11 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13. Der Block T_RX_Z2 repräsentiert beispielhaft einen Task, der der Zone Z2 zugeordnet ist und bei Empfang einer Nachricht ausgeführt wird, vergleichbar zu der Instanz I2 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13. Der Block T_TX_Z1 repräsentiert beispielhaft einen Task, der der Zone Z1 zugeordnet ist und beim Senden einer Nachricht ausgeführt wird, vergleichbar zu der Instanz I3 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13. Der Block T_TX_Z2 repräsentiert beispielhaft einen Task, der der Zone Z2 zugeordnet ist und beim Senden einer Nachricht ausgeführt wird, vergleichbar zu der Instanz I4 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13. Der Pfeil a30 repräsentiert eine Unterbrechungsanforderung, ausgelöst durch den Empfang einer (CAN-)Nachricht, die insbesondere die Abarbeitung einer momentan laufenden Aufgabe, vergleiche den Sendetask T_TX_Z2, unterbricht, vergleiche Pfeil a30'. Infolgedessen wird bei weiteren bevorzugten Ausführungsformen durch die Unterbrechungsroutine ISR6 der Empfängertask T_RX_Z1 aufgerufen, vergleiche Pfeil a31. Nach der Ausführung des Empfängertasks T_RX_Z1 verzweigt diese, bevorzugt mittels einer Software- Unterbrechungsanforderung (Software-Interrupt) a32, wiederum zu der Unterbrechungsroutine ISR6, die sodann den zuvor unterbrochenen Sendetask T_TX_Z2 fortsetzt, vergleiche Pfeil a33. Bei dem Auftreten a34 einer durch einen Zeitgeber erzeugten Unterbrechungsanforderung (Timer IRQ) ruft die Unterbrechungsroutine ISR6 den Sendetask T_TX_Z1 auf, vgl. Pfeil a35, was zur Unterbrechung a34' des zuvor ablaufenden Sendetasks T_TX_Z2 führt.
Aus dem Diagramm gemäß Figur 14 sowie den vorangehenden Beschreibungen ist deutlich ersichtlich, wie unterschiedliche, durch eine Recheneinrichtung gemäß den Ausführungsformen ausführbare, Programmteile (Tasks), die gemäß dem Prinzip gemäß den Ausführungsformen unterschiedlichen Zonen Z1, Z2, .. (mehr als zwei Zonen sind gemäß weiteren bevorzugten Ausführungsformen ebenfalls möglich) zugeordnet werden können, ausgeführt werden können bzw. wie deren Ausführung beispielsweise durch eine Unterbrechungsroutine ISR6, die beispielsweise Bestandteil eines Betriebssystems BS und/oder Supervisors SV sein kann, steuerbar ist.
Figur 15 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen, wobei vorliegend beispielhaft ein Anwendungsfall abgebildet ist, der einen beispielhaften Zonenübergang ZT, also das Übertragen von Daten aus einer ersten Zone gemäß bevorzugten Ausführungsformen in eine zweite Zone gemäß bevorzugten Ausführungsformen, zum Gegenstand hat.
Der erste Rechenkern K1 gemäß Fig. 15 entspricht dabei dem vorstehend unter Bezugnahme auf Fig. 13 bereits beschriebenen CAN-Core K1, und die weiteren Rechenkerne K2, K3 aus Fig. 15 entsprechen den Anwendungskernen K2, K3 gemäß Figur 13. Vergleichbares gilt auch für die Bereiche B1, B2, B3 des Arbeitsspeichers 1030b bzw. ihre Teilbereiche. Der Pfeil A1 repräsentiert den Empfang einer CAN-Nachricht, der eine Bearbeitung durch die Instanz 11 (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) eines entsprechenden Anwendungsprogramms des ersten Rechenkerns K1 auslöst. Die Instanz 11, die der ersten Zone Z1 zugeordnet ist, überträgt Daten der empfangenen CAN-Nachricht bzw. daraus abgeleitete Daten über den Arbeitsspeicher (insbesondere über den weiteren Austausch- Pufferspeicherbereich B3“), vergleiche den Pfeil A2, an eine Instanz I5 (bzw. ein Programm bzw. Unterprogramm bzw. Proxy) eines Anwendungsprogramms zur Verarbeitung solcher Daten, die der ersten Zone Z1 zugeordnet ist und durch den dritten Rechenkern K3 ausführbar ist, vergleiche den Pfeil A3.
Bezugszeichen I6 aus Figur 15 bezeichnet eine Instanz eines Anwendungsprogramms zur Untersuchung von Datenpaketen, insbesondere deep packet inspection, DPI, die die empfangenen Daten (die im Austausch- Pufferspeicherbereich B3“ liegen) näher untersucht und sodann in den Teilbereich B3" des Arbeitsspeichers 1030b schreibt, vergleiche Pfeil A5. Sodann liest die weitere Instanz I6' des DPI- Anwendungsprogramms, die auf dem zweiten Rechenkern K2 ausgeführt wird und die der zweiten Zone Z2 zugeordnet ist, die Daten aus dem Teilbereich B3", was dem vorstehend bereits erwähnten Zonenübergang ZT entspricht, vergleiche Pfeil A6.
Bei weiteren bevorzugten Ausführungsformen wird eine, insbesondere tiefgehende (im Sinne einer DPI), Payload-Analyse z.B. durch die Instanz I6‘ ("Z2-DPI-Proxy", also der zweiten Zone Z2 zugeordneter Proxy zur Ausführung von DPI-Verfahren) ausgeführt, wobei die Instanz I6 ("Z1 -DPI-Proxy", also der ersten Zone Z1 zugeordneter Proxy zur Ausführung von DPI-Verfahren) bevorzugt für das Kopieren der Daten in B3“ zuständig ist.
Nach einer optionalen weiteren Verarbeitung der Daten durch den zweiten Rechenkern K2, vergleiche den Pfeil A7, werden die Daten bzw. daraus abgeleitete Daten von einer Instanz I5' in den Speicherbereich B1_2 (zweiter Pufferspeicherbereich) des Arbeitsspeichers 1030b geschrieben, vergleiche Pfeil A8, aus dem die Instanz I4, die beispielsweise zum Senden von CAN- Nachrichten ausgebildet und der zweiten Zone Z2 zugeordnet ist, und die von dem CAN-Core K1 ausführbar ist, die Daten entnimmt und beispielsweise wieder auf den CAN-Bus aussendet, vergleiche den Pfeil A10. Das vorstehend beispielhaft unter Bezugnahme auf Figur 15 beschriebene Szenario kann für wenigstens einen der folgenden Anwendungsfälle verwendet werden: a) Diagnose unter Verwendung von CAN-Nachrichten, b) DPI angewandt auf CAN-Nachrichten, c) Bildung eines Proxy, z.B. eines Proxy für ein Kommunikations- und/oder Diagnoseprotokoll oder dergleichen, d) Routing von z.B. einem ersten CAN-Bus zu z.B. einem zweiten CAN-Bus, insbesondere unter Einbeziehung von Anwendungsprogrammen (dies ermöglicht beispielhaft eine Verarbeitung der zu routenden CAN-Nachrichten, insbesondere einer Analyse und/oder Modifikation).
Figur 16 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen, in Anlehnung an die Darstellungen von Fig. 13 und Fig. 15, wobei vorliegend beispielhaft ein Anwendungsfall abgebildet ist, der einen beispielhaften Zonenübergang ZT', also das Übertragen von Daten aus einer ersten Zone Z1 gemäß bevorzugten Ausführungsformen in eine zweite Zone Z2 gemäß bevorzugten Ausführungsformen, zum Gegenstand hat. Im Unterschied zu dem Szenario gemäß Figur 15 erfolgt der Zonenübergang ZT' bei dem Szenario gemäß Figur 16 ausgehend von dem Ethernet-Kern K4 zu dem CAN-Kern K1, gemäß den Pfeilen A11 bis A20.
Aus Figur 16 ist zu erkennen, dass nach dem Empfang A11 der Ethernet- Nachricht entsprechende Daten in dem Speicherbereich bzw. ersten Pufferspeicherbereich B3' gespeichert werden (Pfeil A12), von wo sie durch den der ersten Zone Z1 zugeordneten Anwendungskern K3 eingelesen werden (Pfeil A13), verarbeitet werden (Pfeil A14) und die entsprechend verarbeiteten Daten sodann in den weiteren Speicherbereich bzw. Austausch-Pufferspeicherbereich B3" geschrieben werden (Pfeil A15).
Sodann werden diese Daten durch den der zweiten Zone Z2 zugeordneten Anwendungskern K2 eingelesen, vergleiche Pfeil A16, verarbeitet, vergleiche Pfeil A17, und in den weiteren Speicherbereich bzw. zweiter Pufferspeicherbereich B1_2 geschrieben, vergleiche Pfeil A18. Sodann werden die Daten von dem CAN-Core K1 aus dem zweiten Pufferspeicherbereich B1_2 eingelesen (Pfeil A19), durch die Instanz I4 (Teil eines Anwendungsprogramms zum Aussenden von CAN-Nachrichten) verarbeitet und auf dem CAN-Bus (nicht gezeigt) ausgesendet, vergleiche Pfeil A20. Figur 17 zeigt beispielhaft eine zu Figur 16 vergleichbare Konfiguration, bei der eine eingehende Ethernet-Nachricht durch den Rechenkern K4 empfangen (A21), in dem Arbeitsspeicher 1030b zwischengespeichert (A22) und mittels einer Instanz I3 des ersten Rechenkerns K1 gelesen (A23) und auf einen CAN- Bus gesendet (A24) wird.
Figur 18 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen, in Anlehnung an die Darstellungen von Fig. 13 und Fig. 15, wobei vorliegend beispielhaft ein Anwendungsfall abgebildet ist, bei dem ein Hardware-Sicherheitsmodul HSM verwendet wird. Das Hardware-Sicherheitsmodul HSM ist vorliegend beispielhaft in die Recheneinrichtung (nicht in Fig. 18 bezeichnet, vgl. z.B. Bezugszeichen 100 aus Fig. 1) integriert, die u.a. auch den zweiten Rechenkern K2' aufweist, und zur Ausführung von kryptografischen Funktionen ausgebildet. Bei weiteren bevorzugten Ausführungsformen können die kryptografischen Funktionen beispielsweise das Speichern von (geheimen) Schlüsseln und/oder das Bilden von Hashwerten und/oder Signaturen und dergleichen aufweisen.
Bei weiteren bevorzugten Ausführungsformen stellt das Hardware- Sicherheitsmodul HSM ein eigenständiges ("on-chip"-) Modul dar, das bevorzugt auf demselben Halbleitersubstrat bzw. Die (Chip) wie die Recheneinrichtung angeordnet ist. Bevorzugt weise das Hardware-Sicherheitsmodul HSM einen eigenen Rechenkern (nicht gezeigt) sowie ggf. einen eigenen Speicher usw. auf.
Bei weiteren bevorzugten Ausführungsformen ist ein Krypto-Stack KS vorgesehen, der zur Kommunikation zwischen den Rechenkernen der Recheneinrichtung und dem Hardware-Sicherheitsmodul HSM nutzbar ist. Dieser Krypto-Stack KS ist, bei weiteren bevorzugten Ausführungsformen, insbesondere aus Security-Gründen, lediglich auf dem Rechenkern K2‘ realisiert, da der Rechenkern K2‘ vorliegend beispielhaft den einzigen Rechenkern der Recheneinrichtung darstellt, der ausschließlich der vertrauenswürdigen Zone Z2 zugeordnet ist. Damit kann der Rechenkern K2‘ bei weiteren bevorzugten Ausführungsformen als "most secure core", also als sicherster Rechenkern, angesehen werden. Die Pfeile A31, A32, A33, A34, A35, A36 repräsentieren beispielhaft die folgenden Schritte: Empfangen (A31) einer Ethernet-Nachricht, Speichern (A32) der empfangenen Nachricht in dem ersten Pufferspeicherbereich B3', Laden (A33) dieser Nachricht durch ein Anwendungsprogramm des dritten Rechenkerns K3, Verarbeiten (A34) der geladenen Nachricht durch den dritten Rechenkern K3, Schreiben (A35) der bei der Verarbeitung erhaltenen Daten in den Austausch-Pufferspeicherbereich B3", Laden (A36) der geschriebenen Daten aus dem Austausch- Pufferspeicherbereich B3" durch ein Programm bzw. Anwendungsprogramm, das auf dem zweiten Rechenkern K2 ausführbar ist.
Bei weiteren bevorzugten Ausführungsformen verarbeitet der zweite Rechenkern K2 die geladenen Daten, insbesondere auch unter Verwendung des Hardware- Sicherheitsmodul HSM, vgl. den Pfeil A37. Die Verarbeitung A37 kann beispielsweise eine Verschlüsselung von Daten umfassen. Sodann werden die verarbeiteten Daten A38 in dem zweiten Pufferspeicherbereich B1_2 geschrieben (A38). Danach werden die Daten durch die Instanz des CAN-Cores K1 aus dem zweiten Pufferspeicherbereich B1_2 geladen (A39) und auf den CAN-Bus gesendet.
Figur 19 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß weiteren bevorzugten Ausführungsformen, in Anlehnung an die Darstellung von Fig. 18, wobei vorliegend beispielhaft ein Anwendungsfall abgebildet ist, bei dem z.B. ein Firmware-Update, insbesondere vom FOTA (firmware over the air)-Typ, ausführbar ist. Beispielhaft kann bei bevorzugten Ausführungsformen ein Empfangen von Daten über eine Ethernet-Verbindung erfolgen, beispielsweise mittels des vierten Rechenkerns K4, vergleiche Pfeil A41. Eine Instanz IT eines Empfangsprogramms schreibt die empfangenen Daten in den ersten Pufferspeicherbereich B3‘, vgl. Pfeil A42. Instanzen von Anwendungsprogrammen auf dem Anwendungs-Rechenkern K3 Laden die Daten aus dem ersten Pufferspeicherbereich B3‘ (A43) und verarbeiten diese (A44). Eine weitere Instanz I7, bei der es sich beispielsweise um einen ersten FOTA-Proxy I7 handelt, extrahiert die für den FOTA-Prozess erforderlichen Daten aus dem verarbeiteten Daten und schreibt (A45) die extrahierten Daten in den beispielsweise (insbesondere aus der Perspektive der zweiten Zone Z2) als nicht-vertrauenswürdig angesehenen Austausch-Pufferspeicherbereich B3". Eine Instanz I8 eines Anwendungsprogramms, bei der es sich beispielsweise um einen zweiten FOTA-Proxy handelt, und die auf dem Rechenkern K2" ausführbar ist, lädt (Pfeil A46) die Daten aus dem Austausch-Pufferspeicherbereich B3“. Optional kann dann durch den Rechenkern K2" ein kryptografisches Verfahren auf den geladenen Daten ausgeführt werden, beispielsweise eine CMAC- Bildung, die vorteilhaft das Hardware-Sicherheitsmodul HSM nutzt, vergleiche den Pfeil A47. Bei weiteren bevorzugten Ausführungsformen können optional verarbeitete Daten bzw. CMAC-Werte in einem externen Speicher gespeichert werden, vgl. Pfeil A48. Eine derartige Speicherung wird bei weiteren bevorzugten Ausführungsformen durch den FOTA-Proxy I8 gesteuert.
Bei weiteren bevorzugten Ausführungsformen weist die zweite Zone Z2 nur Leserechte, aber insbesondere keine Schreibrechte und/oder Exekutionsrechte, auf den Austausch-Pufferspeicherbereich B3" auf. Dies kann bei weiteren bevorzugten Ausführungsformen in entsprechender Weise z.B. auch bei den vorstehend beispielhaft unter Bezugnahme auf Fig. 4, 5 beschriebenen Konfigurationen gelten.
Bei weiteren bevorzugten Ausführungsformen können in dem externen Speicher 1033 beispielsweise auch komplette Speicherabbilder ("ECU image") 1033a für wenigstens einen Rechenkern bzw. die gesamte Recheneinrichtung und/oder ein entsprechendes Steuergerät zeitweise abgelegt werden.
Bei weiteren bevorzugten Ausführungsformen kann ein durch den zweiten Rechenkern K2" ausführbares Anwendungsprogramm bzw. eine entsprechende Instanz hiervon beispielsweise den Inhalt von in dem externen Speicher 1033 gespeicherten Daten prüfen bzw. validieren werden.
Bei weiteren bevorzugten Ausführungsformen kann, beispielsweise nach erfolgreicher Validierung der in dem externen Speicher 1033 enthaltene Daten, ein entsprechendes Speicherabbild 1033a an ein oder mehrere externe Geräte (nicht gezeigt) verteilt werden, vergleiche die Pfeile A49, A50, A51, A52, die unter anderem ein, beispielsweise blockweises, Kopieren des Speicherabbilds 1033a aus dem externen Speicher 1033a in den zweiten Pufferspeicherbereich B1_2 des Arbeitsspeichers 1030b (A50) und von dort zu der Instanz I4 (z.B. CAN-Sendetask) zum Gegenstand haben.
Bei weiteren bevorzugten Ausführungsformen kann die Validierung bevorzugt basierend auf digitalen Signaturen und/oder signierten Hashwerten ausgeführt werden. Z.B. kann bei weiteren bevorzugten Ausführungsformen zu jedem ECU- image ein signierter Hashwert existieren. Bei weiteren bevorzugten Ausführungsformen kann eine Signaturverifikation bevorzugt über das Hardware- Sicherheitsmodul HSM ausgeführt werden.
Bei weiteren bevorzugten Ausführungsformen kann beispielsweise auch während des Verteilens bzw. Kopierens des Speicherabbilds 1033a ein, vorzugsweise wiederum blockweises, Überprüfen eines CMAC-Werts und/oder eines anderen Werts, der eine Überprüfung der Integrität und/oder Authentizität der betreffenden Blöcke ermöglicht, erfolgen, beispielsweise gesteuert durch entsprechende Instanzen von Anwendungsprogrammen, die zum Beispiel auf dem zweiten Rechenkern K2" ablaufen, optional unterstützt durch das Hardware- Sicherheitsmodul HSM.
Bei weiteren bevorzugten Ausführungsformen kann eine Bildung und Verifikation von z.B. CMAC-Werten insbesondere als ergänzender Integritäts- und Authentizitätsschutz, z.B. zur Signaturverifikation fungieren. Bei weiteren bevorzugten Ausführungsformen kann z.B. ein einzelnes bzw. jedes einzelne Datenpaket aus dem Austausch-Pufferspeicherbereich B3“ mit einem CMAC- Wert oder einem trunkierten ("truncated") CMAC-Wert versehen werden.
Diese(s) wird bzw. werden bei weiteren bevorzugten Ausführungsformen z.B. vor einer Übertragung in den zweiten Pufferspeicherbereich B1_2 verifiziert, wodurch insbesondere sichergestellt wird, dass ausschließlich Datenpakete in den zweiten Pufferspeicherbereich B1_2 gelangen, die integer und authentisch sind. Bei weiteren bevorzugten Ausführungsformen ist eine Buffer-weise CMAC- Generierung und -Verifikation optional. Die Figuren 20, 21 zeigen schematisch Ablaufdiagramme gemäß weiteren bevorzugten Ausführungsformen, die beispielhaft die Verarbeitung von Unterbrechungsanforderungen, zum Beispiel bei einem Empfang von Nachrichten, insbesondere CAN- Nachrichten, veranschaulichen.
Der Block ISR7 repräsentiert beispielhaft eine Unterbrechungsroutine, die beispielsweise bei Unterbrechungsanforderungen ausführbar ist, die den Empfang einer Nachricht ("Rx") signalisieren ("Rx ISR").
Der Block ISR8 repräsentiert beispielhaft eine Unterbrechungsroutine, die beispielsweise bei wenigstens einer der folgenden
Unterbrechungsanforderungen ausführbar ist: a) Signalisierung eines Zeitgebers ("Timer"), b) mittels Software erzeugte Unterbrechungsanforderung ("SW ISR"). Der Block RX_H_Z1 repräsentiert beispielhaft einen Empfangshandler (z.B. Teil bzw. Instanz eines Anwendungsprogramms, das den Empfang einer Nachricht steuert), der der Zone Z1 zugeordnet ist und bei Empfang ("Rx") einer Nachricht ausgeführt wird, vergleichbar zu der Instanz 11 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13.
Der Block RX_H_Z2 repräsentiert beispielhaft einen Empfangshandler (z.B. Teil bzw. Instanz eines Anwendungsprogramms, das den Empfang einer Nachricht steuert), der der Zone Z2 zugeordnet ist und bei Empfang ("Rx") einer Nachricht ausgeführt wird, vergleichbar zu der Instanz I2 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13.
Der Block T_TX_ZT repräsentiert beispielhaft einen Task, der der Zone Z1 zugeordnet ist und beim Senden einer Nachricht ausgeführt wird, vergleichbar zu der Instanz I3 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13. Der Block T_TX_Z2' repräsentiert beispielhaft einen Task, der der Zone Z2 zugeordnet ist und beim Senden einer Nachricht ausgeführt wird, vergleichbar zu der Instanz I4 des ersten Rechenkerns K1 der Recheneinrichtung 100b gemäß Figur 13.
Der Pfeil a40 repräsentiert eine Unterbrechungsanforderung, ausgelöst durch den Empfang einer (CAN-)Nachricht, die insbesondere die Abarbeitung einer momentan laufenden Aufgabe, vergleiche den Sendetask T_TX_Z2', unterbricht, vergleiche Pfeil a40'. Infolgedessen wird bei weiteren bevorzugten Ausführungsformen durch die Unterbrechungsroutine ISR7 der Empfangshandler RX_H_Z1 aufgerufen, vergleiche Pfeil a41. Nach der Ausführung des Empfangshandlers RX_H_Z1 kehrt dieser zu der Unterbrechungsroutine ISR7 zurück (z.B. bevorzugt durch eine mittels Software erzeugte Unterbrechungsanforderung), Pfeil a42.
Gemäß dem Beispiel nach Fig. 20 wird sodann der Sendetask T_TX_Z1‘ ausgeführt, vergleiche Pfeil a43. Dies kann bei weiteren bevorzugten Ausführungsformen den besonderen Vorteil aufweisen, dass durch den Task RX_H_Z1 ohnehin bereits die statische Konfiguration (z.B. entsprechendes Konfigurationsdatenset) der Speicherschutzeinrichtung für die erste Zone Z1 aktiv ist, die bevorzugt auch für den Sendetask T_TX_Z1‘ gilt. Hierdurch kann insbesondere aus Performance-Sicht ein Umschalten der betreffenden statischen Konfiguration der Speicherschutzeinrichtung vor der Ausführung der Sendetask T_TX_Z1 ‘ gespart werden.
Bei dem Auftreten a44 einer durch einen Zeitgeber erzeugten Unterbrechungsanforderung (Timer IRQ) ruft die Unterbrechungsroutine ISR7 den Sendetask T_TX_Z2' auf, vgl. Pfeil a45, was zur Unterbrechung a44' des zuvor ablaufenden Sendetasks T_TX_ZT führt. Bevorzugt erfolgt vor der Ausführung des Sendetasks T_TX_Z2' ein Umschalten auf die statische Konfiguration (z.B. entsprechendes Konfigurationsdatenset) der Zone Z2. Danach kehrt der Ablauf, z.B. mittels eines Software- Interrupts a46, zu der Unterbrechungsroutine ISR7 zurück, woraufhin der Sendetask T_TX_ZT fortgesetzt wird, vgl. Pfeil a47.
Bei weiteren bevorzugten Ausführungsformen kann die Unterbrechungsroutine ISR7 gemäß Fig. 20, 21 z.B. eine zu der Konfiguration ISR4 gemäß Fig. 12A vergleichbare bzw. identische Konfiguration aufweisen.
Nachfolgend sind weitere bevorzugte Ausführungsformen, Aspekte und Vorteile des Prinzips gemäß den Ausführungsformen beschrieben, die - gemäß weiteren bevorzugten Ausführungsformen - jeweils einzeln für sich oder in Kombination miteinander mit wenigstens einer der vorstehend beschriebenen Ausführungsformen kombinierbar sind.
Bei weiteren bevorzugten Ausführungsformen kann als eine Maßnahme zur Limitierung einer Angriffsoberfläche auf die Recheneinrichtung eine Limitierung der Zugriffsrechte auf Speicher 1030a z.B. gemäß Fig. 4, 5 genutzt werden, wodurch eine zonenweise Speicher-Separation, z.B. unter Nutzung von Mechanismen an sich bekannter Speicherschutzeinrichtungen ermöglicht ist. Besonders bevorzugt kann bei weiteren Ausführungsformen eine zonenweise Speicher-Separation bei den nachstehend beispielhaft genannten Speicherformen erfolgen: Buffer (Pufferspeicher), zum Beispiel in Form eines vertrauenswürdigen Pufferspeichers (Trusted Buffer (z.B. in einem Shared RAM 1030) und/oder in Form eines nicht vertrauenswürdigen Pufferspeichers (Non- Trusted Buffer (z.B. in dem Shared RAM 1030), Stack (Stapelspeicher), Daten speicher (bspw. Daten-Flash, EEPROM etc.), Programm-Speicher (bspw. Programm-Flash, ROM etc.), SFRs (Spezialfunktionsregister). Bei weiteren bevorzugten Ausführungsformen kann ein Austausch von Daten zwischen verschiedenen Zonen ("Intra- und/oder Inter-Zonen-Datenaustausch") beispielsweise über in einem Shared RAM (geteilten Arbeitsspeicher, vgl. Bezugszeichen 1030a aus Fig. 4) liegende Buffer realisiert werden.
Bei weiteren bevorzugten Ausführungsformen kann pro Instanz 11, I2, I3 ("Proxy") eines Anwendungsprogramms und pro Zone beispielsweise mindestens jeweils ein Trusted- und Non-Trusted Buffer (abhängig vom Anwendungsfall können ggf. Buffer entfallen) bzw. Pufferspeicherbereiche vorgesehen sein, vergleiche beispielsweise die Teilbereiche TB1a, TB1b aus Fig. 4.
Bei weiteren bevorzugten Ausführungsformen erfolgt ein Datenaustausch innerhalb einer Zone respektive die Intra-Zonen-Kommunikation, insbesondere ausschließlich, via Trusted Buffer bzw. zweiter Pufferspeicherbereich TB2a (Fig. 4) dieser Zone.
Bei weiteren bevorzugten Ausführungsformen erfolgt ein Datenaustausch zwischen Zonen respektive die Inter-Zonen-Kommunikation bevorzugt über im Shared RAM 1030a liegende Non-Trusted Buffer bzw. Austausch- Pufferspeicherbereich TB1a. Sollen bspw. bei weiteren bevorzugten Ausführungsformen Daten von Zone Z1 nach Zone Z2 transferiert werden, so werden diese bevorzugt zunächst von einem Z1 -Proxy in den zugehörigen Z1- Non-Trusted Buffer bzw. Austausch-Pufferspeicherbereich TB1a, TB2b, B“ kopiert, vom zugehörigen Z2-Proxy inhaltlich bzgl. deren Gültigkeit verifiziert und für den Fall valider respektive inhaltlich korrekter, vertrauenswürdiger Daten, vom Z2-Proxy in den Z2-Trusted Buffer bzw. zweiter Pufferspeicherbereich TB2a, B1_2 kopiert. Der Kopiervorgang nach erfolgreicher Daten-Verifikation von Z1- Non-Trusted-Buffer bzw. Austausch-Pufferspeicherbereich TB1a, TB2b, B3“ nach Z2-Trusted-Buffer bzw. zweiter Pufferspeicherbereich TB2a, B1_2 wird bei weiteren bevorzugten Ausführungsformen als Zonen-Transition bezeichnet. Die verifizierten, vertrauenswürdigen und im Z2-Trusted-Buffer befindlichen Daten können bei weiteren bevorzugten Ausführungsformen innerhalb von Z2 entsprechend prozessiert oder weitergeleitet werden, d.h. die Daten-Verifikation erfolgt bei weiteren bevorzugten Ausführungsformen vor der Zonen-Transition und ggf. Daten-Nutzung. Eine weitere Maßnahme zur Limitierung der Angriffsoberfläche der Recheneinrichtung gemäß den Ausführungsformen ist die Limitierung der Zugriffsrechte auf Laufzeit gemäß weiteren bevorzugten Ausführungsformen, die bei weiteren bevorzugten Ausführungsformen z.B. unter Steuerung eines entsprechenden Betriebssystems BS bzw. Supervisors SV erfolgen kann.
Bei weiteren bevorzugten Ausführungsformen kann für das vorstehend beispielhaft beschriebene Lightweight Embedded Betriebssystem BS z.B. gemäß Fig. 4 als Basis z.B. ein AUTomotive Open System ARchitecture (AUTOSAR) BS fungieren, welches bei weiteren bevorzugten Ausführungsformen bezüglich seiner Komplexität auf ein Minimum reduziert wird (bspw. via Konfiguration etc.).
Bei weiteren bevorzugten Ausführungsformen kann selbst im Falle einer von einem kompromittierten Rechenkern 102a (Fig. 3) ausgehenden Eskalation von Privilegien - bspw. Missbrauch von Supervisor Mode in dem Lightweight Embedded OS ISR - keine invalide Zonen-Transition bzw. invalider Zugriff von Z1 auf Z2-Speicher oder -Laufzeit erfolgen - Begründung: Statische und stark reduzierte Funktionalität des Lightweight Embedded BS, bei weiteren bevorzugten Ausführungsformen speziell Teilfunktionalitäten im Supervisor Mode, ermöglichen somit keinen Missbrauch von Privilegien im Supervisor Mode.
Bei weiteren bevorzugten Ausführungsformen kann eine in dem Supervisor Mode laufende ISR (Unterbrechungsroutine) lediglich zwischen den statischen Konfigurationsdatensets für die dedizierte Speicherschutzeinrichtung für den betreffenden Rechenkern umschalten
Figure imgf000052_0001
identische statische Konfigurationsdatensets für Supervisor Mode und User Mode des Rechenkerns erlauben bei weiteren bevorzugten Ausführungsformen lediglich Zugriff auf Speicher und/oder Laufzeit, die einer betreffenden Zone, zum Beispiel der ersten Zone Z1 , zugeordnet sind.
Bei weiteren bevorzugten Ausführungsformen kann eine in dem Supervisor Mode laufende ISR keine dynamische Rekonfiguration der Speicherschutzeinrichtung(en) vornehmen, dies ist insbesondere implizit erreichbar durch eine statische, integre und authentische Konfiguration der Speicherschutzeinrichtung(en) während eines Startzyklus, beispielsweise während eines Kaltstarts und/oder während eines Warmstarts.
Bei weiteren bevorzugten Ausführungsformen kann eine in dem User Mode laufende Task, die beispielsweise der ersten Zone Z1 zugeordnet ist, nicht zwischen statischen Konfigurationsdatensets der für einen bestimmten Rechenkern dedizierten Speicherschutzeinrichtung umschalten, denn bei weiteren bevorzugten Ausführungsformen ist diese Umschaltung ausschließlich in dem Supervisor Mode möglich.
Bei weiteren bevorzugten Ausführungsformen kann eine in dem User Mode laufende Task, die beispielsweise der ersten Zone Z1 zugeordnet ist, keine dynamische Rekonfiguration der Speicherschutzeinrichtung(en) vornehmen, was vorteilhaft wiederum implizit erreichbar ist durch eine bei weiteren bevorzugten Ausführungsformen vorgesehene statische, integre und authentische Konfiguration der Speicherschutzeinrichtung(en) während des Startzyklus, also beispielsweise während eines Kaltstarts und/oder während eines Warmstarts.
Bei weiteren bevorzugten Ausführungsformen kann ein Supervisor SV, insbesondere Lightweight Embedded Supervisor, gegenüber dem Betriebssystem BS, insbesondere dem Lightweight Embedded Betriebssystem, über ergänzende Überwachungsfunktionalitäten verfügen. Bevorzugt werden im Falle einer Intra-Core-Zonen-Separation (Fig. 5) auf einem dedizierten Rechenkern 102c Tasks PXY zweier Zonen Z1 und Z2 mit unterschiedlicher Vertrauensstufen ausgeführt, wobei hier bevorzugt zwei unterschiedliche statische Konfigurationsdatensets für Z1 -Tasks (der ersten Zone Z1 zugeordnete Tasks bzw. Instanzen) und Z2-Tasks im User Mode verwendet werden, sowie ggf. ein weiteres statisches Konfigurationsdatenset für den Supervisor Mode, welcher z.B. die Umschaltung zwischen den beiden statischen Konfigurationsdatensets für die Z1 -Tasks und die Z2-Tasks steuert. Bei weiteren bevorzugten Ausführungsformen kann ein gegebenenfalls verbleibendes, ungenutztes statisches Konfigurationsdatenset für Tasks im User Mode so konfiguriert werden (beispielsweise während eines Kaltstarts und/oder Warmstarts), dass dieses z.B. einen generellen Lese-, Schreib- und Exekutionszugriff auf den kompletten Speicher unterbindet, wodurch die Sicherheit weiter gesteigert wird. Bei weiteren bevorzugten Ausführungsformen kann vorgesehen sein, dass der Supervisor Mode, insbesondere im Kontext einer Intra-Core-Zonen-Separation, eine Überwachung einer nicht-vertrauenswürdigen Zone Z1 steuert, vgl. z.B. den Ablauf gemäß Fig. 2M.
Bei weiteren bevorzugten Ausführungsformen können z.B. 3 oder mehr Zonen Z1, Z2, Z3 (nicht gezeigt) vorgesehen sein, wobei die erste Zone Z1 z.B. eine - hoch-vertrauenswürdige/ -vertrauliche Zone ist, wobei die zweite Zone Z2 z.B. eine vertrauenswürdige Zone ist, und wobei die dritte Zone Z3 z.B. eine nicht vertrauenswürdige Zone ist.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung z.B. einen Mikrocontroller aufweisen bzw. durch einen Mikrocontroller mit einen entsprechenden Anzahl von Rechenkernen gebildet sein.
Weitere bevorzugten Ausführungsformen beziehen sich auf eine Vorrichtung 1000 zur Ausführung des Verfahrens gemäß den Ausführungsformen, vgl. das schematische Blockdiagramm gemäß Fig. 22. Die Vorrichtung 1000 weist eine Recheneinrichtung 1002 mit wenigstens einem Rechenkern 1002a auf, wobei dem Rechenkern 1002a optional wenigstens eine Speicherschutzeinrichtung 1002a' zugeordnet werden kann.
Die Vorrichtung 1000 weist weiter eine Speichereinrichtung 1004 auf, die bevorzugt über einen flüchtigen Speicher 1004a, z.B. Arbeitsspeicher (RAM), verfügt, und/oder über einen nichtflüchtigen Speicher 1004b, z.B. ein Flash- EEPROM und/oder ein ROM und/oder einen OTP-Speicher. Bevorzugt ist in dem ROM 1004b ein Computerprogramm PRG abgelegt, das Befehle aufweist, die bei der Ausführung des Programms PRG durch einen Computer 1002 diesen veranlassen, das Verfahren gemäß den Ausführungsformen auszuführen.
Bei weiteren bevorzugten Ausführungsformen sind auch Konfigurationsdaten CFG für den Betrieb der Vorrichtung 1000 in dem ROM 1004b abgelegt. Diese Konfigurationsdaten CFG können z.B. auch ein oder mehrere Konfigurationsdaten(sets) KD, KD', KD1, KD2, KD3, KD4 für (die) wenigstens eine Speicherschutzeinrichtung 1002a' aufweisen. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Vorrichtung 1000 wenigstens einen Datenbus 1006 aufweist, der einen Datenaustausch zwischen der Recheneinrichtung 1002 und der Speichereinrichtung 1004 ermöglicht.
Weitere bevorzugte Ausführungsformen beziehen sich auf ein computerlesbares Speichermedium SM, umfassend Befehle, insbesondere in Form eines Computerprogramms PRG, die bei der Ausführung durch einen Computer 1002 diesen veranlassen, das Verfahren gemäß den Ausführungsformen auszuführen.
Weitere bevorzugte Ausführungsformen beziehen sich auf ein Datenträgersignal DS, das das Computerprogramm PRG gemäß den Ausführungsformen überträgt. Bevorzugt kann die Vorrichtung 1000 eine, vorzugsweise bidirektionale, Datenschnittstelle 1008 aufweisen zum Empfang des Datenträgersignals DS.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung 1002 auch eine Konfiguration gemäß der Recheneinrichtung 100, 100a, wie vorstehend beispielhaft unter Bezugnahme u.a. auf Fig. 1, 3 beschrieben, aufweisen. Insbesondere ist es bei weiteren bevorzugten Ausführungsformen auch möglich, dass der bzw. ein Rechenkern 1002a der Vorrichtung 1000 nach Fig. 22 zumindest zeitweise zumindest manche Schritte des Verfahrens gemäß den Ausführungsformen ausführt. Insoweit kann die Vorrichtung 1000 beispielhaft auch als mögliches Zielsystem für die Recheneinrichtung 100, 100a gemäß den Ausführungsformen aufgefasst werden.
Bei weiteren bevorzugten Ausführungsformen weist die Vorrichtung 1000 auch ein Hardware-Sicherheitsmodul HSM' bzw. Kryptografiemodul HSM', z.B. zur Ausführung kryptografischer Funktionen, auf. Bei weiteren bevorzugten Ausführungsformen kann das Hardware-Sicherheitsmodul HSM' als Supervisor- Instanz SVI verwendet werden.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Vorrichtung 1000 ausgebildet ist als ein Mikrocontroller (englisch: Microcontroller bzw. Microcontroller Unit (MCU)), insbesondere als ein einziger Mikrocontroller (single MCU) bzw. als ein Ein-Chip-System (englisch: SoC, system-on-chip), insbesondere als ein einziges SoC (single-SoC).
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Vorrichtung 1000 ein, insbesondere gemeinsames, Halbleitersubstrat 1001 (englisch: die) aufweist, wobei wenigstens eines der folgenden Elemente auf dem, insbesondere gemeinsamen, Halbleitersubstrat 1001 angeordnet ist: a) die wenigstens einen Rechenkern aufweisende Recheneinrichtung 1002, b) die Speichereinrichtung 1004, c) der Datenbus 1006, d) die wenigstens eine Speicherschutzeinrichtung 1002a, d) das (optionale) Hardware-Sicherheitsmodul HSM'.
Das Prinzip gemäß bevorzugten Ausführungsformen ermöglicht somit vorteilhaft die Bereitstellung eines single-MCU Systems 1 bzw. single-SoC Systems 1, bei gleichzeitiger Separation in zwei oder mehr Zonen Z1, Z2.
Bei weiteren bevorzugten Ausführungsformen kann ein Austausch von Daten zwischen den verschiedenen Zonen ("Intra- und/oder Inter-Zonen- Datenaustausch") beispielsweise über in einem Shared RAM (geteilten Arbeitsspeicher, vgl. Bezugszeichen 1030a aus Fig. 4) liegende Buffer (Pufferspeicherbereiche, Austausch-Pufferspeicherbereiche) realisiert werden, wobei das Shared RAM vorteilhaft ebenfalls auf demselben gemeinsamen Halbleitersubtrat 1001 angeordnet ist, wie die Recheneinrichtung 1002 bzw. ihr(e) Rechenkern(e) 1002a und bevorzugt die weiteren Komponenten 1006, HSM', 1002a des single-SoC Systems 1. Hierdurch ist vorteilhaft ein hochperformanter (da MCU-intern bzw. SoC-intern) und sicherer (da MCU-intern bzw. SoC-intern) Kommunikationskanal zwischen den verschiedenen Zonen Z1, Z2 gegeben, der gemäß weiteren bevorzugten Ausführungsformen auch effizient skalierbar ist (z.B. mehrere Buffer bei ggf. weiteren (zusätzlichen) Zonen).
Vorteilhaft ermöglichen bevorzugte Ausführungsformen die "Anordnung" unterschiedlicher Zonen Z1, Z2, z.B. vertrauenswürdiger (TZ) und nicht vertrauenswürdiger (NTZ) Zonen, und/oder eine Datenverarbeitung bezüglich der Daten der unterschiedlichen Zonen Z1, Z2 auf demselben, bevorzugt single-, MCU- bzw. SoC-System 1. Bei weiteren bevorzugten Ausführungsformen kann das Verfahren und/oder die Vorrichtung 100, 100a, 1000 gemäß den Ausführungsformen in einem Steuergerät, z.B. einem Steuergerät für ein Kraftfahrzeug, insbesondere einem Steuergerät für eine Brennkraftmaschine eines Kraftfahrzeugs, verwendet werden, z.B. für wenigstens einen der folgenden Anwendungsfälle: a) Steuern eines Betriebs bzw. Betriebszustandsübergangs des Steuergeräts, b) Freigeben bzw. Nichtfreigeben einer oder mehrerer Funktionen des Steuergeräts und/oder einer anderen Komponente und/oder z.B. des Kraftfahrzeugs, c) Wechseln in einen Fehlermodus und/oder Notlauf, d) Vornehmen eines Fehlerspeichereintrags, e) Signalisierung eines Betriebszustands an eine externe Einheit und/oder einen Benutzer, f) Ansteuern eines Stellglieds.
Weitere bevorzugte Ausführungsformen beziehen sich auf eine Verwendung des Verfahrens gemäß den Ausführungsformen und/oder der Vorrichtung 100, 100a, 1000 gemäß den Ausführungsformen und/oder des Computerprogramms PRG gemäß den Ausführungsformen zur Überprüfung wenigstens eines Teilbereichs der Speichereinrichtung 1030, 1032, 1004 auf Änderungen bzw. Manipulationen, insbesondere vor oder während oder nach einem Wechsel der Speichereinrichtung und/oder einer auf die Speichereinrichtung zugreifenden Recheneinrichtung 100, 100a, 1002 von einem ersten Betriebszustand in einen zweiten Betriebszustand, und zur Steuerung eines Betriebs z.B. eines Steuergeräts einer Brennkraftmaschine eines Kraftfahrzeugs in Abhängigkeit der Überprüfung.
Weitere bevorzugte Ausführungsformen, vgl. Fig. 2U, beziehen sich auf eine Verwendung des Verfahrens gemäß den Ausführungsformen und/oder der Vorrichtung gemäß den Ausführungsformen und/oder des Computerprogramms gemäß den Ausführungsformen für wenigstens eines der folgenden Elemente: a) Bereitstellen 370 von Vertrauensgrenzen ("Trust Boundaries") in der Recheneinrichtung 100, 100a (Fig. 1), insbesondere auch innerhalb eines Rechenkerns 102c der Recheneinrichtung, b) Verringerung 371 (Fig. 2U) einer Angriffsoberfläche für Angriffe auf die Recheneinrichtung und/oder eine ihrer Komponenten, c) Limitierung 372 von Zugriffsrechten auf Speicher 1030, 1032, d) Limitierung 373 von Zugriffsrechten auf Peripherie 1034 (Fig. 3), e) Limitierung 374 (Fig. 2U) von Zugriffsrechten auf Rechenressourcen (z.B. charakterisierbar durch Rechenzeit, Angabe eines Rechenkerns), e) Minimierung 375 eines Einflusses einer korrumpierten Komponente, f) Betreiben 376 eines Steuergeräts, insbesondere für ein Fahrzeug, insbesondere Kraftfahrzeug, g) Betreiben 377 eines eingebetteten Systems, insbesondere eines lnternet-of- Things, loT, -Systems, h) Betreiben 378 eines anwendungsspezifischen integrierten Schaltkreises, ASIC.
Bei weiteren bevorzugten Ausführungsformen, vgl. Fig. 2V, weist das Verfahren weiter auf: a) Bereitstellen 380 eines primären Supervisor-Proxy SVI-pri mittels der Supervisor-Instanz SVI, b) Bereitstellen 382 wenigstens eines sekundären Supervisor-Proxy SVI-sek-1, SVI-sek-2, wobei insbesondere der wenigstens eine sekundäre Supervisor-Proxy SVI-sek-1, SVI-sek-2 wenigstens einem Rechenkern 102a, 102b, 102c, ... , 102n; K1, K2, K3, K4 und/oder der wenigstens einen Zone Z1, Z2 zugeordnet ist (beispielhafte Details s.u. zu Fig. 24).
Weiter bevorzugt kann der primäre Supervisor-Proxy SVI-pri mittels des on-chip Trust Anchor (TA) realisiert und/oder implementiert werden.
Bei weiteren bevorzugten Ausführungsformen, vgl. Fig. 2W, weist das Verfahren weiter auf: a) Bereitstellen 385 einer ersten Anzahl von Funktionalitäten FUN-1 für den Supervisor SV, b) Zuordnen 386, insbesondere dynamisch, wenigstens einer Supervisor-Funktionalität SF-1 der ersten Anzahl von Funktionalitäten FUN- 1 zu dem primären Supervisor-Proxy SVI-pri und/oder dem wenigstens einen sekundären Supervisor-Proxy SVI-sek-1, wobei insbesondere das Zuordnen 386 in Abhängigkeit wenigstens eines der folgenden Elemente ausgeführt wird: A) Betriebsgröße der Recheneinrichtung 100; 100a; 100b, B) Betriebsart der Recheneinrichtung 100; 100a; 100b, C) Anwendungsfall der Recheneinrichtung 100; 100a; 100b.
Figur 24 zeigt schematisch ein vereinfachtes Blockdiagramm einer Recheneinrichtung 100c gemäß weiteren bevorzugten Ausführungsformen. Die Recheneinrichtung 100c weist ein oder mehrere Rechenkerne auf, die vorliegend kollektiv mit dem Bezugszeichen KX bezeichnet sind. Den Rechenkernen KX sind zwei Zonen Z1 , Z2 zugeordnet, denen wie vorstehend bereits mehrfach beispielhaft beschrieben zumindest zeitweise ein oder mehrere Proxies Z1 -Proxy 1, .., Z1 -Proxy n, Z2-Proxy 1, .., Z2-Proxy n zugeordnet sein können. Bei der Recheneinrichtung 100c ist gemäß weiteren bevorzugten Ausführungsformen eine Supervisor-Instanz SVI vorgesehen, die von den wenigstens zwei Zonen Z1, Z2 unabhängig ist. Optional können der Supervisor- Instanz SVI auch ein oder mehrere ("eigene") Zonen Z3, Z4 zugeordnet sein, wobei die Zonen Z3, Z4 ebenfalls bevorzugt von den wenigstens zwei Zonen Z1, Z2 unabhängig sind. Den zwei Zonen Z3, Z4 sind beispielhaft zumindest zeitweise ein oder mehrere Proxies Z3-Proxy 1, .., Z3-Proxy n, Z4-Proxy 1, .., Z4- Proxy n zugeordnet, wobei gemäß weiteren bevorzugten Ausführungsformen die Anzahl der Proxies je Zone Z3, Z4 (optional auch Z1, Z2) auch unterschiedlich sein kann.
Bevorzugt kann z.B. wenigstens ein (dedizierter) Rechenkern der Recheneinrichtung 100c als Supervisor-Instanz SVI verwendet werden. Alternativ oder ergänzend kann bei weiteren bevorzugten Ausführungsformen wenigstens ein Hardware-Sicherheitsmodul HSM und/oder ein Trusted-Platform-Modul TPM, als Supervisor-Instanz SVI verwendet werden.
Ein Datenaustausch DE zwischen der Supervisor-Instanz SVI und den Rechenkernen KX kann bei weiteren bevorzugten Ausführungsformen z.B. unter Verwendung von einem oder mehreren Speicherbereichen erfolgen, insbesondere unter Verwendung von Registerspeichern wie z.B. einem oder mehreren Registerspeichern für besondere Funktionen (englisch: special function register(s)). Beispielsweise ist bei weiteren bevorzugten Ausführungsformen ein erster Registerspeicher bzw. eine erste Gruppe SFR1 von Registerspeichern vorgesehen, um Daten von der Supervisor-Instanz SVI zu den Kernen KX ("Host- Kerne") zu übertragen. Beispielsweise ist bei weiteren bevorzugten Ausführungsformen ein zweiter Registerspeicher bzw. eine zweite Gruppe SFR2 von Registerspeichern vorgesehen, um Daten von den Kernen KX zu der Supervisor-Instanz SVI zu übertragen.
Beispielsweise ist bei weiteren bevorzugten Ausführungsformen ein Arbeitsspeicher SR ("shared RAM") für gemeinsamen Zugriff durch den primären Supervisor-Proxy SVI-pri und den sekundären Supervisor-Proxy SVI-sek-1 vorgesehen. Der bzw. die Registerspeicher SFR2 sind bevorzugt Host-seitig (also durch wenigstens einen der Rechenkerne KX) les- und/oder schreibbar, jedoch bevorzugt aus Perspektive der Supervisor-Instanz SVI lediglich lesbar. Bei weiteren bevorzugten Ausführungsformen resultiert ein Host-seitiges Schreiben des SFR2 (also Beschreiben des bzw. der Registerspeicher SFR2 durch wenigstens einen der Rechenkerne KX) z.B. in einer Unterbrechungsanforderung IRQ auf der Seite der Supervisor-Instanz SVI.
Der bzw. die Registerspeicher SFR1 sind bevorzugt Supervisor-Instanz-seitig les- und/oder schreibbar, aus Perspektive der Rechenkerne KX jedoch lediglich lesbar. Weiter bevorzugt resultiert ein Supervisor-Instanz-seitiges Schreiben des Registerspeichers SFR1 in einer Unterbrechungsanforderung IRQ auf der Host- Seite KX.
Bei weiteren bevorzugten Ausführungsformen kann bzw. können optional zur Generierung einer Unterbrechungsanforderung IRQ auf Host-Seite KX Host- seitig auch der bzw. die Registerspeicher SFR1 gepollt, insbesondere zyklisch abgefragt, werden.
Der gemäß weiteren bevorzugten Ausführungsformen für beide Seiten, insbesondere bidirektional, les- und schreibbare Shared RAM SR kann bei Bedarf gemäß weiteren bevorzugten Ausführungsformen dem ergänzenden Daten- bzw. Parameter-Austausch zwischen den beiden Supervisor-Proxies SVI- pri, SVI-sek-1 dienen.
Bei weiteren bevorzugten Ausführungsformen kann das shared RAM SR auch unterteilt werden in Bereiche ("Sub-Bereiche"), die: a) bidirektional les- und schreibbar sind, und/oder b) (insbesondere nur) vom Trust-Anchor TA schreibbar und vom Host KX lesbar sind, und/oder c) (insbesondere nur) vom Host KX schreibbar und vom T rust Anchor TA lesbar sind.
Bei weiteren bevorzugten Ausführungsformen kann das shared RAM SR optional in je einen Hauptbereich pro Rechenkern (gemäß weiteren bevorzugten Ausführungsformen zumindest für manche von mehreren Rechenkernen) aufgeteilt werden. Bei weiteren bevorzugten Ausführungsformen kann in diesem Hauptbereich bzw. in diesen Hauptbereichen dann z.B. wenigstens einer, vorzugsweise mehrere bzw. alle drei, der vorstehenden genannten drei Sub- Bereiche a), b), c) vorgesehen sein. Der bzw. die Hauptbereich(e) sind gemäß weiteren bevorzugten Ausführungsformen ebenfalls mittels einer jeweiligen Speicherschutzeinrichtung (MPU) voneinander separiert, so dass z.B. ein erster Rechenkern nicht in den Austauschbereich eines zweiten Rechenkerns (z.B. zum Datenaustausch zwischen dem zweiten Rechenkern mit dem Trust Anchor TA, SVI) schreiben kann.
Bei weiteren bevorzugten Ausführungsformen können Daten zwischen den Kernen KX und der Supervisor-Instanz SVI z.B. programmgesteuert und/oder ereignisgesteuert (z.B. mittels Unterbrechungsanforderungen IRQ) übertragen werden.
Bei weiteren bevorzugten Ausführungsformen können ein oder mehrere Speicherschutzeinrichtungen MPU' vorgesehen sein, um unterschiedliche Ressourcenbereiche, insbesondere Speicherbereiche, der verschiedenen Komponenten der Recheneinrichtung 100c untereinander zu trennen.
Bei weiteren bevorzugten Ausführungsformen charakterisiert bzw. repräsentiert bzw. bildet die Supervisor-Instanz SVI eine, insbesondere besonders, vertrauenswürdige Instanz der Recheneinrichtung 100c, bevorzugt einen sog. on-chip Trust- Anchor (TA). Der TA repräsentiert gemäß weiteren bevorzugten Ausführungsformen die Instanz der Recheneinrichtung 100c mit der maximalen Vertrauensstufe, welche gemäß weiteren bevorzugten Ausführungsformen z.B. als "Vertrauenswurzel" (Root-of-Trust) eines Vertrauensmodells nutzbar ist.
Als TA kann gemäß weiteren bevorzugten Ausführungsformen wie schon erwähnt ein dedizierter Rechenkern oder bevorzugt, sofern verfügbar, ein dediziertes Security-/ Kryptographie-Modul, bspw. Hardware Security Module (HSM), Trusted Platform Module (TPM) etc., fungieren.
Gemäß weiteren bevorzugten Ausführungsformen kann damit ein sog. "Trust- Anchor (TA)-enforced secure Zone Supervision"-Ansatz realisiert werden, wobei gemäß Fig. 24 beispielhaft jeweils ein sekundärer Supervisor-Proxy SVI-sek-1 auf dem bzw. den zu überwachenden Rechenkernen KX und ein primärer Supervisor-Proxy SVI-pri auf dem überwachenden TA SVI, im dargestellten Beispiel in Form eines HSM, vorgesehen ist.
Gemäß weiteren bevorzugten Ausführungsformen verfügt der TA SVI über, bevorzugt uneingeschränkten, Zugriff auf flüchtigen Speicher 1004a (Fig. 22) wie RAM, nichtflüchtigen Speicher 1004b wie Read Only Memory (ROM) oder Flash, One-Time-Pro-grammable(OTP)-Speicher und Special Function Register SFR1, SFR2 (Fig. 25), insbesondere auch auf ggf. vorhandene Special Function Register der Recheneinrichtung 100c.
Das Prinzip gemäß bevorzugten Ausführungsformen lässt sich gemäß weiteren bevorzugten Ausführungsformen z.B. zur Konfiguration und/oder Überwachung von, insbesondere nicht-vertrauenswürdigen und vertrauenswürdigen, (Host- )Zonen Z1 und Z2 sowohl für die vorstehend bereits beschriebene Intra- als auch Inter-Core-Zonen-Separation verwenden.
Gemäß weiteren bevorzugten Ausführungsformen können z.B. die nachstehend beispielhaft genannten Supervisor-Funktionalitäten, insbesondere je nach Anwendungsfall, weiter insbesondere beliebig, zwischen dem "Host-Proxy" SVI- sek-1 dem primären Supervisor-Proxy SVI-pri verschoben werden, wobei insbesondere eine Erhöhung der auf der Seite des primären Supervisor-Proxy SVI-pri realisierten Supervisor-Funktionalitäten in einer, insbesondere signifikanten, Verbesserung der Sicherheit resultiert:
1. Überwachung von Zone Z1 (und optional Zone Z2) auf potenzielle Kompromittierungen und/oder Detektion potenzieller Kompromittierungen von Zone Z1 (und/oder Zone Z2) - kann bevorzugt z.B. erfolgen durch Überwachung von Stack (Stapelspeicher) und/oder Program Counter (Programmzähler) der Zone Z1- (und/oder der Zone Z2), insbesondere vor einer Taskaktivierung eines der jeweiligen Zone Z1, Z2 zugeordneten Tasks, Erkennung von Kompromittierung vor Code-Exekution, die Überwachung kann gemäß weiteren bevorzugten Ausführungsformen optional via kryptographischer Integritäts und/oder Authentizitätsverifikationen, bspw. Hash, Message Authentication Code (MAC) etc., z.B. von Stack und/oder Program Counter von Host-Z1- (und Host- Z2) erfolgen. 2. Im Falle einer detektierten Kompromittierung erfolgt gemäß weiteren bevorzugten Ausführungsformen eine Einleitung von wenigstens einer Ersatzreaktion bzw. Fehlerreaktion. Dies kann z.B. erfolgen durch o Versetzung der Zone Z1 (und/oder Zone Z2) in einen sicheren, insbesondere integren Zustand (z.B. via Power-off/on-Reset) oder in einen Fehlermodus, o Generierung eines Log (bzw. Logfile bzw. Fehlerspeicher)-Eintrages. Bei weiteren bevorzugten Ausführungsformen erfolgt zumindest zeitweise eine sichere und/oder verschlüsselte Ablage von Log-Einträgen, insbesondere in einem optionalen dedizierten und exklusiven Speicher SL bevorzugt der Supervisor-Instanz SVI (vgl. Fig. 24)
Bei weiteren bevorzugten Ausführungsformen ist wenigstens eines der folgenden Elemente vorgesehen: a) Aufbau von authentischem und/oder verschlüsseltem Kommunikationskanal zur Weiterleitung z.B. von Log-Einträgen an wenigstens eine externe Instanz (nicht gezeigt), z.B. ein Intrusion Detection System (IDS), b) Koordination und/oder Orchestrierung (z.B. aufweisend ein Scheduling (Ressourcenplanung)) insbesondere zyklisch oder ereignisbasiert auszuführender Tasks der Zonen Z1 , Z2, c) sichere Ablage und/oder Prozessierung einer vorzugsweise statischen Host-Task-Liste in dem dediziertem und exklusiven TA-Speicher SL (Fig. 24), d) Umschaltung zwischen statischen Konfigurationsdatensätzen ("MPU-Sets"), z.B. in Host-MPU-SFRs für Zone Z1 und/oder Zone Z2 Tasks.
Bei weiteren bevorzugten Ausführungsformen kann die Supervisor-Funktionalität vollständig auf den TA SVI (Fig. 24) verlagert werden, wobei insbesondere der privilegierte Modus (Supervisor Mode) den (nicht die Supervisor-Funktionalität realisierenden) Rechenkernen ganz oder zumindest teilweise entzogen werden kann.
Bevorzugte Ausführungsformen ermöglichen zumindest zeitweise und/oder teilweise wenigstens manche der nachfolgenden Effekte:
1. Minimierung der Host-seitigen Supervisor-Funktionalitäten, Reduktion der Angriffsoberfläche (bspw. ausgehend von eine korrumpierten (Host-) Zone Z1),
2. Auslagerung von Supervision von (Host-) Zone(n) Z1 und/oder (optional) Z2 auf eine insbesondere diesen Zonen Z1, Z2 gegenüber autarke (unabhängige) TA-Instanz SVI, Entkopplung von (Host-)Zonen von deren Überwachung, 3. Simple, sichere und performante kryptographische Erweiterung der Supervision, da z.B. Supervision und kryptographische Primitiven auf gleicher Instanz (TA SVI bzw. HSM) realisiert, kryptographische Integritäts- und/oder Authentizitätsverifikationen von Stack und Program Counter (z.B. der Zonen Z1, Z2), verschlüsselte Ablage von Log-Einträgen in sicherem dedizierten und exklusiven TA-Speicher SL, Aufbau von authentischem und/oder verschlüsseltem Kommunikationskanal z.B. zur Weiterleitung von Log-Einträgen an eine externe Instanz, bspw. ein IDS, 4. Sichere Ablage der statischen Host- Task-Liste in TA-Speicher SL (Integritäts- und/oder Authentizitätsschutz), 5. Zentralisierung von Funktionalität zur Umschaltung von statischen MPU-Sets in Host-MPU-SFRs in TA-seitigem Supervisor-Proxy, Entzug von Funktionalität zur Umschaltung auf Host-Seite, Selbst bei invalider Host-seitiger Eskalation von Privilegien keine Umschaltung möglich.
Sofern gemäß weiteren bevorzugten Ausführungsformen der TA SVI eine, insbesondere dedizierte, Memory Protection Unit (MPU) aufweist kann gemäß weiteren bevorzugten Ausführungsformen eine Einführung ergänzender Vertrauensgrenzen respektive Zonen Z3, Z4 auf dem TA SVI erfolgen. Die TA- seitigen Zonen Z3, Z4 können bevorzugt mit entsprechend höheren Vertrauensstufen als die Host-seitigen Zonen Z1, Z2 korrelieren. Das beispielhaft in Fig. 24 visualisierte exemplarische Vertrauensmodell basiert auf nachstehender Zonen-Architektur in absteigenden Vertrauensstufen: o TA-seitig: Zone Z4 (z.B. maximale Vertrauensstufe) o TA-seitig: Zone Z3 o Host-seitig: Zone Z2 o Host-seitig: Zone Z1 (z.B. minimale Vertrauensstufe)
Bei weiteren bevorzugten Ausführungsformen kann eine integre und/oder authentische Host-MPU-Konfiguration z.B. im Rahmen eines Secure-Boot Mechanismus ebenfalls durch den TA SVI ausgeführt bzw. zumindest zeitweise gesteuert werden.

Claims

Ansprüche
1. Verfahren zum Betreiben einer wenigstens einen Rechenkern (102a, 102b, 102c, ... , 102n; K1, K2, K3, K4; KX) aufweisenden Recheneinrichtung für ein Steuergerät eines Kraftfahrzeugs, wobei die Recheneinrichtung (100; 100a;
100b; 100c) dazu eingerichtet ist, einen Datenaustausch zwischen einer Konnektivitätszone (400) und einer Sicherheitszone (440) zu steuern, wobei die Sicherheitszone (440) zumindest eine Komponente (442, 444, 446) des Fahrzeugs umfasst wie beispielsweise eine Motorsteuerung (442), ein Bremssystem (444) oder eine Lenkung (446), die zum Fahren des Fahrzeugs erforderlich ist und eine erhöhte Sicherheitsrelevanz besitzt, wobei die Konnektivitätszone (400) zumindest eine Komponente (420, 422, 424, 426) des Fahrzeugs umfasst, deren Betrieb eine Kommunkation außerhalb des Fahrzeugs erfordert, jedoch nicht zum Fahren des Fahrzeugs erforderlich ist und keine erhöhte Sicherheitsrelevanz besitzt, wobei zumindest ein von der Recheneinrichtung (100; 100a; 100b; 100c) ausführbares erstes Programm, insbesondere Anwendungsprogramm (AP1) oder Unterprogramm, zu einer nicht vertrauenswürdigen Zone (Z1), und zumindest ein weiteres Programm, insbesondere Anwendungsprogramm (AP2) oder Unterprogramm, einer vertrauenswürdigen Zone (Z2) zugeordnet wird, wobei die Komponente (420,
422, 424, 426) der Konnektivitätszone (400) der nicht-vertrauenswürdigen Zone (Z1) zugeordnet wird, und die Komponente (442, 444, 446) der Sicherheitszone (440) der vertrauenswürdigen Zone (Z2) zugeordnet wird, wobei die Recheneinrichtung (100; 100a; 100b; 100c) zumindest einen Speicher (1030, 1032) umfasst mit zumindest einem ersten Pufferspeicherbereich (TB1b, B3‘), auf den ausschließlich das der nicht-vertrauenswürdigen Zone (Z1) zugeordnete Programm (AP1) nur lesenden und/oder nur schreibenden Zugriff besitzt, mit zumindest einem zweiten Pufferspeicherbereich (TB2a, B1_2), auf den ausschließlich das der vertrauenswürdigen Zone (Z2) zugeordnete weitere Programm (AP2) nur lesenden und/oder nur schreibenden Zugriff besitzt, und mit zumindest einem Austausch-Pufferspeicherbereich (TB1a, TB2b, B3“), der dem ersten Programm (AP1) der nicht-vertrauenswürdigen Zone (Z1) nur schreibenden Zugriff und dem zweiten Programm (AP2) der vertrauenswürdigen Zone (Z2) nur lesenden Zugriff ermöglicht.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Austauschen (280) von Daten zwischen verschiedenen Zonen (Z1, Z2) folgende Schritte aufweist: Kopieren (282) der Daten in den der ersten Zone (Z1) zugeordneten ersten Pufferspeicherbereich (TB1b, B3‘), Überprüfen (283) der kopierten Daten, und in Abhängigkeit der Überprüfung (283) Kopieren (284) der Daten aus dem der ersten Zone (Z1) zugeordneten ersten Pufferspeicherbereich (TB1b, B3‘) in den der zweiten Zone (Z2) zugeordneten zweiten Pufferspeicherbereich (TB2a, B1_2).
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Daten von dem ersten Pufferspeicherbereich (TB1b, B3‘) in den Austausch-Pufferspeicherbereich (TB1a, TB2b, B3“) geschrieben werden.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die in dem Austausch-Pufferspeicherbereich (TB1a, TB2b, B3“) befindlichen Daten in Verbindung mit einem lesenden Zugriff insbesondere durch das weitere Programm (AP2) überprüft werden und bei einem erfolgreichen Überprüfen (283) der Daten die Daten vom Austausch- Pufferspeicherbereich (TB1a, TB2b, B3“) in den zweiten Pufferspeicherbereich (TB2a, B1_2) kopiert werden.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein ausführender Zugriff auf die Daten im ersten und/oder zweiten Pufferspeicherbereich (TB1b, B3‘) und/oder im Austausch- Pufferspeicherbereich (TB1a, TB2b, B3“) unterbunden wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Nutzung und Weiterleitung der Daten ausgehend von dem zweiten Pufferspeicherbereich (TB2a, B1_2) erfolgt.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Zugriffsrechte, insbesondere lesender, schreibender oder ausführender Zugriff, auf den Speicher (1030, 1032) und/oder auf den ersten Pufferspeicherbereich (TB1b, B3‘) und/oder auf den zweiten Pufferspeicherbereich (TB2a, B1_2) und/oder auf den Austausch- Pufferspeicherbereich (TB1a, TB2b, B3“) durch eine Speicherschutzeinrichtung (M1 , M2, M3, M4, M5_1, M5_2, M5_3, M5_4, M5_5, M5_6, M5_7, M5_8) erfolgt.
7. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend: Steuern (230), insbesondere Begrenzen, von wenigstens einem der folgenden Elemente: a) Leserechte auf der Recheneinrichtung (100; 100a; 100b) zugeordneten Speicher (1030, 1032), b) Schreibrechte auf der Recheneinrichtung (100; 100a; 100b) zugeordneten Speicher (1030, 1032), c) Ausführungsrechte auf der Recheneinrichtung (100; 100a; 100b) zugeordneten Speicher (1030, 1032), in Abhängigkeit wenigstens einer Zone (Z1, Z2), insbesondere durch zumindest zeitweises Verwenden (232; 232') wenigstens einer Speicherschutzeinrichtung (M1, M2, M3, M4, M5_1, M5_2, M5_3, M5_4, M5_5, M5_6, M5_7, M5_8) zum Steuern der Leserechte und/oder der Schreibrechte und/oder der Ausführungsrechte.
8. Verfahren nach wenigstens einem der vorstehenden Ansprüche, wobei wenigstens ein Rechenkern (102a) zumindest zeitweise eine erste Betriebsart einnimmt (240), wobei insbesondere der wenigstens eine Rechenkern (102a) in der ersten Betriebsart Konfigurationsdaten (1036), die einen Betrieb wenigstens einer Speicherschutzeinrichtung steuern, vorgibt und/oder schreibt (242), wobei insbesondere der wenigstens eine Rechenkern (102a) zumindest zeitweise eine zweite Betriebsart einnimmt (243), in der er die Konfigurationsdaten (1036) für die wenigstens eine Speicherschutzeinrichtung nicht schreiben und/oder ändern kann.
9. Verfahren nach einem der vorhergehenden Ansprüche, weiter aufweisend: Bereitstellen (250) mehrerer Sätze von Konfigurationsdaten (KD) für die wenigstens eine Speicherschutzeinrichtung (M1, M2, M3, M4, M5_1, M5_2, M5_3, M5_4, M5_5, M5_6, M5_7, M5_8), wobei insbesondere wenigstens ein erster Satz der mehreren Sätze von Konfigurationsdaten (KD) einer ersten Zone (Z1) der wenigstens zwei Zonen (Z1, Z2) und wenigstens ein zweiter Satz der mehreren Sätze von Konfigurationsdaten (KD) einer zweiten Zone (Z2) der wenigstens zwei Zonen (Z1, Z2) zugeordnet (252) wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Konfigurationsdaten (KD) der Speicherschutzeinrichtung (M1 , M2, M3, M4, M5_1, M5_2, M5_3, M5_4, M5_5, M5_6, M5_7, M5_8) statisch und/oder authentisch, insbesondere nach einer Validierung, konfiguriert werden, sodass keine Änderung der Konfigurationsdaten (KD) im laufenden Betrieb, sondern allenfalls nach einem Neustart der Recheneinrichtung (100; 100a; 100b) möglich ist.
11. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend das als erstes Programm eine erste Instanz (AP1J1) und als zweites Programm eine zweite Instanz (AP1J2) verwendet wird, insbesondere weiter aufweisend: Bereitstellen (260) der ersten Instanz (AP1J1) des Anwendungsprogramms (AP1) und der zweiten Instanz (AP1J2) des Programms bzw. Anwendungsprogramms (AP1), Zuordnen (262) der ersten Instanz (AP1J1) des ersten Programms bzw. Anwendungsprogramms (AP1) zu einer ersten Zone (Z1) der wenigstens zwei Zonen, Zuordnen (263) der zweiten Instanz (AP1J2) des Anwendungsprogramms (AP1) zu einer zweiten Zone (Z2) der wenigstens zwei Zonen.
12. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend: Trennen (290) von Rechenzeitressourcen für unterschiedliche Programme bzw. Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, insbesondere Zuweisen von Rechenzeitressourcen für unterschiedliche Programm bzw. Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, in Abhängigkeit der wenigstens zwei Zonen (Z1, Z2).
13. Verfahren nach Anspruch 12, weiter aufweisend: a) Verwenden (292) eines Betriebssystems (BS) für eingebettete Systeme, insbesondere eines Lightweight Embedded Operating System, zum Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei insbesondere jeweils einem Rechenkern (102a, 102b) der Recheneinrichtung (100) ein Betriebssystem (BS) zugeordnet ist, und/oder b) Verwenden (294) eines Supervisors (SV) für eingebettete Systeme, insbesondere eines Lightweight Embedded Supervisor, zum Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei insbesondere jeweils einem Rechenkern (102a, 102b) der Recheneinrichtung (100) ein Supervisor (SV) zugeordnet ist.
14. Verfahren nach wenigstens einem der vorstehenden Ansprüche, wobei die Recheneinrichtung (100) zumindest zeitweise einen Kaltstart (310) ausführt, wobei insbesondere während des Kaltstarts (310) Daten und/oder Programmcode aus einem nichtflüchtigen Speicher (1032) geladen werden, und wobei die Recheneinrichtung (100) zumindest zeitweise einen Warmstart (312) ausführt, wobei insbesondere während des Warmstarts (312) Daten und/oder Programmcode aus einem zumindest zeitweise bestromten, flüchtigen Speicher (1030) geladen werden, wobei insbesondere während des Kaltstarts (310) wenigstens eine Speicherschutzeinrichtung (M1, M2, M3, M4, M5_1, M5_2,
M5_3, M5_4, M5_5, M5_6, M5_7, M5_8) bzw. die wenigstens eine Speicherschutzeinrichtung (M1, M2, M3, M4, M5_1, M5_2, M5_3, M5_4, M5_5, M5_6, M5_7, M5_8) konfiguriert (311) wird, und/oder wobei insbesondere während des Warmstarts (312) die wenigstens eine Speicherschutzeinrichtung (M1 , M2, M3, M4, M5_1, M5_2, M5_3, M5_4, M5_5, M5_6, M5_7, M5_8) konfiguriert (313) wird.
15. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend wenigstens eines der folgenden Elemente: a) Einführen (350) wenigstens einer zusätzlichen, insbesondere nicht bereits existierenden, Zone, b) Verschieben (352) von Funktionalitäten von einem ersten Rechenkern (102a) zu wenigstens einem weiteren Rechenkern (102b) der Recheneinrichtung, c) Ausführen (354) einer Kommunikation zwischen wenigstens zwei Zonen (Z1, Z2) unter Verwendung eines, insbesondere in die Recheneinrichtung (100) integrierten, Arbeitsspeichers (1030), d) Definieren (360) wenigstens einer vertrauenswürdigen Zone (Z2) und, optional, Überwachen (362) wenigstens einer weiteren, insbesondere nicht vertrauenswürdigen, Zone (Z1), durch wenigstens ein der vertrauenswürdigen Zone (Z2) zugeordnetes Anwendungsprogramm.
16. Verfahren nach einem der vorhergehenden Ansprüche, weiteraufweisend: Verwenden (212; 294) eines Supervisors (SV) zum Zuweisen (212a) von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei der Supervisor (SV) und/oder eine dem Supervisor (SV) entsprechende Funktionalität zumindest teilweise mittels einer Supervisor-Instanz (SVI) realisiert ist, die von den wenigstens zwei Zonen (Z1, Z2) unabhängig ist.
17. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Recheneinrichtung (100; 100a; 100b; 100c) mehrere Rechenkerne (102a, 102b, 102c, ... , 102n; K1, K2, K3, K4) aufweist, wobei das Verfahren weiter aufweist: a) Zuordnen (220) mindestens eines Rechenkerns (102a, 102b) zu genau einer Zone, und/oder b) Zuordnen (222) mindestens eines Rechenkerns (102a, 102b) zu mehr als einer Zone, insbesondere zu zwei Zonen (Z1, Z2), c) Verwenden (224) wenigstens eines Rechenkerns als Supervisor- Instanz (SVI), insbesondere Verwenden des wenigstens einen Rechenkerns als dedizierte Supervisor-Instanz (SVI), d) Verwenden (225) wenigstens eines Hardware-Sicherheitsmoduls (HSM) und/oder Trusted-Platform-Moduls, TPM, als Supervisor-Instanz (SVI).
18. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend: a) Bereitstellen (380) eines primären Supervisor-Proxy (SVI-pri) mittels der Supervisor-Instanz (SVI), b) Bereitstellen (382) wenigstens eines sekundären Supervisor-Proxy (SVI-sek-1, SVI-sek-2), wobei insbesondere der wenigstens eine sekundäre Supervisor-Proxy (SVI-sek-1, SVI-sek-2) wenigstens einem Rechenkern (102a, 102b, 102c, ... , 102n; K1, K2, K3, K4) und/oder der wenigstens einen Zone (Z1, Z2) zugeordnet ist.
19. Verfahren nach einem der vorhergehenden Ansprüche, weiter aufweisend: a) Bereitstellen (385) einer ersten Anzahl von Funktionalitäten (FUN-1) für den Supervisor (SV), b) Zuordnen (386), insbesondere dynamisch, wenigstens einer Supervisor-Funktionalität (SF-1) der ersten Anzahl von Funktionalitäten (FUN-1) zu dem primären Supervisor-Proxy (SVI-pri) und/oder dem wenigstens einen sekundären Supervisor-Proxy (SVI-sek-1), wobei insbesondere das Zuordnen (386) in Abhängigkeit wenigstens eines der folgenden Elemente ausgeführt wird: A) Betriebsgröße der Recheneinrichtung (100; 100a; 100b; 100c), B) Betriebsart der Recheneinrichtung (100; 100a; 100b; 100c), C) Anwendungsfall der Recheneinrichtung (100; 100a; 100b; 100c).
20. Verfahren nach einem der vorhergehenden Ansprüche, wobei die erste Anzahl von Funktionalitäten (FUN-1) und/oder die wenigstens eine Supervisor- Funktionalität (SF-1) wenigstens eines der folgenden Elemente aufweist: a) Überwachung wenigstens einer Zone (Z1, Z2), insbesondere auf eine potentielle Kompromittierung, b) Detektion einer Kompromittierung wenigstens einer Zone (Z1 , Z2), c) Überwachung wenigstens eines mit wenigstens einer Zone (Z1 , Z2) assoziierten Stapelspeichers, d) Überwachung wenigstens eines mit wenigstens einer Zone (Z1 , Z2) assoziierten Programmzählers, wobei die Überwachung insbesondere vor einer Aktivierung eines Tasks der betreffenden Zone (Z1 , Z2) ausgeführt wird, e) Erkennung einer Kompromittierung, insbesondere vor eine Ausführung von ausführbarem Programmcode, f) Verwendung wenigstens eines, insbesondere kryptographischen, Verfahrens, insbesondere zur Authentizitätsverifikation und/oder Integritätsverifikation, insbesondere für eine bzw. die Überwachung eines bzw. des Stapelspeichers und/oder eine bzw. die Überwachung eines bzw. des Programmzählers, wobei das kryptographische Verfahren wenigstens eines der folgenden Elemente aufweist: f1) Hashwertbildung, f2) Bildung eines Message Authentication Code, MAC.
21. Vorrichtung (100; 100a; 100b; 1000) zur Ausführung des Verfahrens nach wenigstens einem der vorstehenden Ansprüche, wobei die Vorrichtung (100; 100a; 100b; 1000) insbesondere ausgebildet ist als ein, insbesondere als ein einziger bzw. einziges, Mikrocontroller bzw. Ein-Chip-System (1) und/oder insbesondere die Vorrichtung (100; 100a; 100b; 1000) ein, insbesondere gemeinsames, Halbleitersubstrat (1001) aufweist, wobei insbesondere wenigstens eines der folgenden Elemente auf dem, insbesondere gemeinsamen, Halbleitersubstrat (1001) angeordnet ist: a) die wenigstens einen Rechenkern (1002a) aufweisende Recheneinrichtung (1002), b) die Speichereinrichtung (1004), c) der Datenbus (1006), d) die Speicherschutzeinrichtung (1002a1), d) das Hardware-Sicherheitsmodul (HSM; HSM').
PCT/EP2020/086404 2019-12-20 2020-12-16 Verfahren und vorrichtung zum betreiben einer recheneinrichtung WO2021122734A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP20833782.4A EP4078415A1 (de) 2019-12-20 2020-12-16 Verfahren und vorrichtung zum betreiben einer recheneinrichtung
JP2022537899A JP7392157B2 (ja) 2019-12-20 2020-12-16 コンピューティングデバイスの動作方法及び動作装置
US17/785,163 US20230021594A1 (en) 2019-12-20 2020-12-16 Method and device for operating a computing device
CN202080087688.5A CN114787806A (zh) 2019-12-20 2020-12-16 用于运行计算装置的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019220461.9 2019-12-20
DE102019220461.9A DE102019220461A1 (de) 2019-12-20 2019-12-20 Verfahren und Vorrichtung zum Betreiben einer Recheneinrichtung

Publications (1)

Publication Number Publication Date
WO2021122734A1 true WO2021122734A1 (de) 2021-06-24

Family

ID=74106017

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/086404 WO2021122734A1 (de) 2019-12-20 2020-12-16 Verfahren und vorrichtung zum betreiben einer recheneinrichtung

Country Status (6)

Country Link
US (1) US20230021594A1 (de)
EP (1) EP4078415A1 (de)
JP (1) JP7392157B2 (de)
CN (1) CN114787806A (de)
DE (1) DE102019220461A1 (de)
WO (1) WO2021122734A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021104153A1 (de) 2021-02-22 2022-08-25 Bayerische Motoren Werke Aktiengesellschaft Steuervorrichtung, telematiksteuergerät und verfahren
DE102022207910A1 (de) * 2022-08-01 2024-02-01 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Verarbeiten von mit einem Hardware-Sicherheitsmodul assoziierten Daten
DE102022213911A1 (de) 2022-12-19 2024-06-20 Zf Friedrichshafen Ag Fahrzeugsteuergerät und Verfahren zum Betreiben desselben

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030084196A1 (en) * 2001-11-01 2003-05-01 Chang Cheng Tsung Message passing method for computer system
DE102014201682A1 (de) * 2014-01-30 2015-07-30 Robert Bosch Gmbh Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
EP3357761A1 (de) * 2015-09-30 2018-08-08 Hitachi Automotive Systems, Ltd. Steuerungsvorrichtung in einem fahrzeug

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015067107A (ja) 2013-09-30 2015-04-13 日立オートモティブシステムズ株式会社 車両用制御装置
JP6761793B2 (ja) 2017-10-13 2020-09-30 日立オートモティブシステムズ株式会社 車両用制御装置
JP6973120B2 (ja) 2018-01-26 2021-11-24 住友電気工業株式会社 なりすまし検出装置、検出方法、およびコンピュータプログラム
DE102022204716A1 (de) * 2022-05-13 2023-11-16 Robert Bosch Gesellschaft mit beschränkter Haftung Rechnersystem zur bereitstellung einer mehrzahl von funktionen für eine vorrichtung, insbesondere für ein fahrzeug, mittels separation einer mehrzahl von zonen

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030084196A1 (en) * 2001-11-01 2003-05-01 Chang Cheng Tsung Message passing method for computer system
DE102014201682A1 (de) * 2014-01-30 2015-07-30 Robert Bosch Gmbh Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
EP3357761A1 (de) * 2015-09-30 2018-08-08 Hitachi Automotive Systems, Ltd. Steuerungsvorrichtung in einem fahrzeug

Also Published As

Publication number Publication date
DE102019220461A1 (de) 2021-06-24
EP4078415A1 (de) 2022-10-26
JP7392157B2 (ja) 2023-12-05
US20230021594A1 (en) 2023-01-26
JP2023508913A (ja) 2023-03-06
CN114787806A (zh) 2022-07-22

Similar Documents

Publication Publication Date Title
EP4049136A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
WO2021122734A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
EP3437012B1 (de) Verfahren, prozessor und gerät zur integritätsprüfung von nutzerdaten
DE112020005949T5 (de) Informationsverarbeitungsvorrichtung, Anomalieerfassungsverfahren und Computerprogramm
DE102018132970A1 (de) Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten
DE112020003881T5 (de) System und verfahren zur durchführung von trusted computing mit fernbescheinigung und informationsisolierung auf heterogenen prozessoren über eine offene verbindung
EP3655876B1 (de) Ein-chip-system, verfahren zum betrieb eines ein-chip-systems und kraftfahrzeug
EP4154139B1 (de) Erweiterte integritätsüberwachung eines containerabbildes
EP3095065B1 (de) Vorrichtung und verfahren zum detektieren einer manipulation an einem programmcode
WO2024056443A1 (de) Verfahren zum überprüfen von daten in einer recheneinheit
DE602004002241T2 (de) Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor
EP4364015A1 (de) Ausführen von privilegierten operationen in einem container
EP3819804A1 (de) Integritätsüberprüfung eines registerinhalts
DE102021123370A1 (de) Informationsverarbeitungsvorrichtung, informationsverarbeitungsverfahren, und programm
DE102022204716A1 (de) Rechnersystem zur bereitstellung einer mehrzahl von funktionen für eine vorrichtung, insbesondere für ein fahrzeug, mittels separation einer mehrzahl von zonen
EP4290397A1 (de) Verfahren und system zur bereitstellung von steuerungsanwendungen
WO2023156175A1 (de) Containerlaufzeitumgebung mit verteilten überwachungsaufgaben und minimalen privilegien
EP3690690B1 (de) Verfahren zum prüfen einer validität von daten und computerimplementierte vorrichtung zum verarbeiten von daten
EP4170490A1 (de) Priorisieren eines zugriffs von einer containerinstanz auf eine datei in einer dateisystemressource
DE102020103314A1 (de) Verfahren zum Aktualisieren von Software und Knoten eines Netzwerkes
EP4187418A1 (de) Verfahren und vorrichtung zur autorisierung einer einen zugang anfragenden applikation
EP3786790A1 (de) Ausführungsumgebung und verfahren für einen prozess
EP4312137A1 (de) Berechtigung zu einem installieren und/oder einem starten eines zweiten anwendungsprogramms
WO2024088790A1 (de) Verfahren und system zur umgebungs-abhängigen sicherheitsbezogenen anomalieerkennung für eine containerinstanz
WO2024160420A1 (de) Verfahren und system zur behandlung von mindestens einem unbefugten zugriff auf mindestens eine gemeinsame ressource durch mindestens eine containerinstanz

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20833782

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022537899

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020833782

Country of ref document: EP

Effective date: 20220720