Method and apparatus for operating a computing device

Abstract

A method for operating a computing device having at least one computing core, wherein the method comprises the following steps: allocating one or more applications executable by the computing device to one of at least two areas, wherein the area represents resources of the computing device, which resources can be used to execute the relevant applications; and executing at least one of the applications according to the area allocated to the at least one application.

Description

Technical Field

[0001] The present disclosure relates to a method for operating a computing device having at least one computing core.

[0002] Furthermore, the present disclosure relates to an apparatus for performing such a method. Summary of the invention

[0003] A preferred embodiment relates to a method for operating a computing device having at least one computing core, the computing device being a computing device, in particular for a vehicle, in particular a motor vehicle, in particular for an embedded system and / or a control device, wherein the method comprises the following steps: assigning one or more applications executable by the computing device to one of at least two areas, wherein the areas characterize resources of the computing device that can be used to execute the relevant applications; and executing at least one of the applications according to the area assigned to the at least one application. Advantageously, this makes it possible to increase the operational safety of the computing device without impairing operational flexibility when executing the applications.

[0004] Particularly preferably, the method according to this embodiment is designed as a computer-implemented method.

[0005] In other preferred embodiments, two regions may be provided, or more than two regions may be provided.

[0006] In further preferred embodiments, the resource of the computing device that can be characterized by an area can include at least one of the following elements: a) a memory, b) execution time or computing time, wherein in particular the resource includes the memory.

[0007] In other preferred embodiments, it is provided that the computing device has a plurality of computing cores, wherein the method further comprises: a) assigning at least one computing core to exactly one area and / or b) assigning at least one computing core to more than one area, in particular to two areas.

[0008] In other preferred embodiments, the method further comprises: controlling, in particular limiting, at least one of the following elements based on at least one area: a) read access to the memory assigned to the computing device, b) write access to the memory assigned to the computing device, c) execution access to the memory assigned to the computing device.

[0009] In other preferred embodiments, it is provided that the method further comprises at least temporarily using at least one memory protection device to control read authorization and / or write authorization and / or execute authorization.

[0010] In other preferred embodiments, it is provided that the method further comprises providing at least one dedicated memory protection device for at least one computing core, wherein in particular a dedicated memory protection device is respectively provided for a plurality of computing cores, preferably for all computing cores.

[0011] In other preferred embodiments, it is provided that the method further comprises providing a memory protection device, in particular a common memory protection device, for a plurality of computer cores.

[0012] In other preferred embodiments, it is provided that at least one computing core at least temporarily occupies a first operating mode, wherein in particular the at least one computing core in the first operating mode predetermines and / or writes configuration data for controlling the operation of at least one memory protection device, wherein in particular the at least one computing core at least temporarily occupies a second operating mode, in which the at least one computing core cannot write and / or change configuration data for the at least one memory protection device.

[0013] In other preferred embodiments, it is provided that at least one computing core assumes the first operating mode in an event-controlled manner, in particular as a function of at least one interrupt request.

[0014] In other preferred embodiments, the method further comprises: providing multiple groups of configuration data for at least one memory protection device, wherein in particular at least one first group of the multiple groups of configuration data is assigned to a first area of ​​the at least two areas, and at least one second group of the multiple groups of configuration data is assigned to a second area of ​​the at least two areas.

[0015] In other preferred embodiments, the method further comprises: providing a first instance of the application and a second instance of the application, assigning the first instance of the application to a first area of ​​at least two areas, and assigning the second instance of the application to a second area of ​​the at least two areas.

[0016] In other preferred embodiments, it is provided that the method further comprises: dividing the area of ​​the memory assigned to the computing device according to at least two areas, wherein the memory assigned to the computing device has at least one of the following elements: a) a buffer memory, in particular a buffer memory in the form of a working memory, b) a stack memory, c) a data memory, d) a program memory, e) a register memory, f) an OTP (one time programmable) memory, wherein at least one memory protection device is used for the division.

[0017] In other preferred embodiments, the method further comprises: exchanging first data between different areas via a buffer memory, in particular a working memory, wherein in particular exchanging the first data between the first area and the second area comprises the following steps: copying the first data to a first buffer memory area assigned to the first area, checking the copied first data, and in particular copying the first data from the first buffer memory area assigned to the first area to a second buffer memory area assigned to the second area based on the check.

[0018] In other preferred embodiments, it is provided that the method further comprises dividing computing time resources for different applications and / or instances of applications according to at least two areas, in particular allocating computing time resources for different applications and / or instances of applications.

[0019] In other preferred embodiments, the method further comprises: a) using an operating system of an embedded system, in particular a lightweight embedded operating system (Lightweight Embedded Operating System), to allocate computing time resources for different applications and / or application instances, wherein in particular the operating system is respectively assigned to computing cores of the computing device, and / or b) using a supervisor of the embedded system, in particular a lightweight embedded supervisor, to allocate computing time resources for different applications and / or application instances, in particular when (instances of) applications are assigned to different areas, wherein in particular the supervisor is respectively assigned to computing cores of the computing device.

[0020] In further preferred embodiments, it is provided that, in particular when using a static task list, the operating system and / or the supervisor performs an allocation of computing time resources to predefined tasks, preferably only to predefined tasks.

[0021] In other preferred embodiments, it is provided that the operating system and / or the supervisor performs an allocation of computing time resources based on a) repeated, in particular cyclically repeated, interrupt requests and / or b) event-controlled interrupt requests, wherein in particular tasks are activated based on at least one interrupt routine.

[0022] In other preferred embodiments, it is provided that, when entering the interrupt routine, configuration data for at least one memory protection device or the at least one memory protection device are changed, in particular in a hardware-controlled manner. In other preferred embodiments, it is provided that the method further comprises: monitoring at least one of the following elements, in particular monitoring potential damage (compromittierung) of at least one of the following elements, in particular by means of an operating system and / or a supervisor: a) a first area, b) an application assigned to the first area, c) an instance of the application assigned to the first area, wherein in particular the monitoring comprises: evaluating the stack memory and / or evaluating the program counter, wherein preferably the evaluation of the stack memory and / or evaluating the program counter is performed before activating the application and / or the instance of the application. In other preferred embodiments, the monitoring routine of the supervisor is executed or implemented in a trusted operating mode (e.g. "supervisory mode"), in particular the monitoring routine of the supervisor is executed or implemented by a trusted instance.

[0023] In other preferred embodiments, it is provided that the method further comprises: starting a fault reaction, in particular when the monitoring can infer a potential damage, then starting a fault reaction, wherein the fault reaction has at least one of the following elements: a) placing the first area and / or the computing cores assigned to the first area in a safe state, in particular by deactivating the computing cores assigned to the first area and / or resetting (resetting, resetting) the computing cores assigned to the first area and / or placing them in a fault mode, b) generating a fault entry and / or c) forwarding the fault entry or the fault entry to an attack identification system, in particular an intrusion detection system (IDS). In other preferred embodiments, the IDS can be arranged, for example, internally or externally with respect to the computing device.

[0024] In other preferred embodiments (see Figure 2N ) is provided in which the computing device at least temporarily performs a cold start, wherein in particular data and / or program code are loaded from a non-volatile memory during the cold start; and wherein the computing device at least temporarily performs a hot start, wherein in particular data and / or program code are loaded from a volatile memory that is at least temporarily powered on during the hot start; wherein in particular at least one memory protection device is configured during the cold start, and / or wherein in particular at least one memory protection device is configured during the hot start.

[0025] In other preferred embodiments, it is provided that a dedicated memory protection device is only assigned to that computing core for which the dedicated memory protection device is provided.

[0026] In other preferred embodiments, it is provided that the method further comprises: testing the integrity and / or authenticity of configuration data or testing the configuration data, which control the operation of at least one memory protection device, in particular testing is performed by means of at least one of the following elements: a) verifying a program code that can be used to configure the at least one memory protection device, b) verifying the configuration data, c) persisting the program code that can be used to configure the at least one memory protection device or the program code, d) persisting the configuration data.

[0027] In other preferred embodiments, it is provided that the method further includes at least temporarily executing a secure boot method and / or at least temporarily executing a method for manipulation detection during runtime, in particular by at least one computer core.

[0028] In other preferred embodiments, the method further comprises: controlling the access of the application to at least one of the following elements according to at least one area: a) an internal interface of the computing device, in particular a software interface, b) an internal and / or external hardware interface of the computing device, c) a hardware security module and / or a cryptographic module for performing cryptographic functions, d) peripheral devices of the computing device, in particular special function registers of at least one peripheral device, e) an internal interface of a target system of the computing device, in particular an internal interface of a control device, f) an external interface of a target system of the computing device, in particular an external interface of a control device, g) an addressing element for a communication protocol, in particular an addressing element on at least one layer of the ISO / OSI layer model.

[0029] In other preferred embodiments, it is provided that the method further comprises at least one of the following elements: a) introducing at least one additional, in particular already non-existing area, b) moving functions from the first computing core to at least one other computing core of the computing device, c) performing communication between at least two areas using a working memory, in particular integrated in the computing device, d) defining at least one trusted area by at least one application assigned to the trusted area and optionally monitoring at least one other, in particular untrusted area. In other preferred embodiments, the monitoring of at least one other, in particular untrusted area can be performed, for example, by a program, for example an interrupt routine (ISR, English: interrupt service routine), preferably in a monitoring mode, which can also be referred to as "supervisory mode".

[0030] Further preferred embodiments relate to a device for carrying out the method according to the embodiments described.

[0031] In further preferred embodiments, it is provided that the device has at least one of the following elements: a) a computing device having at least one computing core, b) a memory device, c) a data bus, d) a memory protection device, e) a hardware security module.

[0032] In other preferred embodiments, it is provided that the device is designed as a microcontroller, in particular as a single microcontroller or as a single-chip system (SoC), in particular as a single SoC.

[0033] In other preferred embodiments, it is provided that the device has a (especially common) semiconductor substrate, wherein at least one of the following elements is arranged on the (especially common) semiconductor substrate: a) a computing device having at least one computing core, b) a memory device, c) a data bus, d) a memory protection device, d) a hardware security module.

[0034] Further preferred embodiments relate to a computer-readable storage medium comprising instructions, in particular in the form of a computer program, which, when executed by a computer, cause the computer to carry out the method according to the embodiments.

[0035] Further preferred embodiments relate to a computer program which comprises instructions which, when the program is executed by a computer, cause the computer to carry out the method according to the embodiments.

[0036] Further preferred embodiments relate to a data carrier signal which transmits a computer program according to the embodiments described.

[0037] Other preferred embodiments relate to the use of the method according to the embodiment and / or the device according to the embodiment and / or the computer program according to the embodiment for at least one of the following elements: a) providing a trust boundary in a computing device, in particular also within a computing core of the computing device, b) reducing the attack surface for attacking the computing device and / or one of its components, c) limiting access rights to memory, d) limiting access rights to the periphery, e) limiting access rights to computing resources, e) minimizing the impact of damaged components, f) operating a control device, in particular a control device for a vehicle, in particular a motor vehicle, g) operating an embedded system, in particular an Internet of Things IoT system, h) operating an application-specific integrated circuit ASIC, i) detecting damaged areas, j) initiating a fault reaction, in particular in the event of detected damage.

[0038] In other preferred embodiments, the method and / or device according to the embodiment can be used in a control device, for example a control device for a motor vehicle, in particular a control device for an internal combustion engine of a motor vehicle, for example for at least one of the following application scenarios: a) controlling the operation or operating state transition of the control device, b) enabling or disabling the control device and / or other components and / or one or more functions of the motor vehicle, for example, c) switching to a fault mode and / or emergency operation, d) making a fault memory entry, e) signaling the operating state to an external unit and / or a user, f) controlling an actuator.

[0039] Other preferred embodiments relate to the use of the method according to said embodiment and / or the device according to said embodiment and / or the computer program according to said embodiment for: in particular before, during or after a transition of the storage device and / or a computing device accessing the storage device from a first operating state to a second operating state, checking for changes or manipulation of at least one subarea of ​​the storage device; and controlling the operation of a control device, for example of an internal combustion engine of a motor vehicle, based on said checking. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Further features, possible applications and advantages of the invention are apparent from the following description of an exemplary embodiment of the invention, which is shown in the figures of the accompanying drawings. All described or shown features, either alone or in any combination, form the subject matter of the invention, regardless of their summary in the claims or their reference back thereto, and regardless of their expression in the description or their illustration in the drawings.

[0041] In the attached picture:

[0042] Figure 1 Schematically shows a simplified block diagram of a computing device according to a preferred embodiment,

[0043] Figure 2A A simplified flow chart of a method according to another preferred embodiment is schematically shown.

[0044] Figures 2B to 2U Schematically shows a simplified flow chart of a method according to other preferred embodiments,

[0045] Figure 3 Schematically shows a simplified block diagram of a computing device according to another preferred embodiment,

[0046] Figure 4 , 5 Schematically shows a simplified block diagram of aspects according to other preferred implementation forms, respectively,

[0047] Figure 6 ,7 Schematically show aspects of an interrupt routine according to further preferred embodiments,

[0048] Figure 8 Schematically shows a flow chart according to other preferred implementation forms,

[0049] Fig. 9 shows aspects of an interrupt routine according to a further preferred embodiment,

[0050] Fig.10 , 11 Schematically shows a simplified block diagram of aspects according to other preferred implementation forms, respectively,

[0051] Fig. 12A , 12B Schematically show aspects of an interrupt routine according to further preferred embodiments,

[0052] Fig.13 Schematically shows a simplified block diagram of aspects according to other preferred implementation forms,

[0053] Fig.14 Schematically shows a flow chart according to other preferred implementation forms,

[0054] Figures 15 to 19 Schematically shows a simplified block diagram of aspects according to other preferred implementation forms, respectively,

[0055] Fig. 20 , 21 Schematically show flow charts according to other preferred implementation forms, respectively,

[0056] Fig. 22 schematically shows a simplified block diagram of a device according to other preferred embodiments, and

[0057] Fig.23 A simplified block diagram of configuration data according to a further preferred embodiment is schematically shown. DETAILED DESCRIPTION

[0058] Figure 1 A simplified block diagram of a computing device 100 according to a preferred embodiment is schematically shown. The computing device 100 has at least one computing core, in the present invention, by way of example, four computing cores 102a, 102b, 102c, 102n, and can be used, for example, in particular for embedded systems and / or control devices, in particular for vehicles, in particular motor vehicles.

[0059] A preferred embodiment relates to a method for operating a computing device 100, the method comprising the following steps (see Figure 2A): can be performed by the computing device 100 ( Figure 1 ) to one of at least two zones Z1, Z2, wherein the zones Z1, Z2 represent resources of the computing device 100, which resources can be used to execute the relevant applications AP1, AP2; and executing 210 at least one of the applications AP1, AP2 according to the zones Z1, Z2 assigned to the at least one application. Advantageously, this makes it possible to improve the security of the operation of the computing device 100 without hindering the flexibility in the operation when executing the applications AP1, AP2.

[0060] In other preferred embodiments, trust boundaries can be defined, for example, between trusted and untrustworthy instances / units / domains. In this way, for example, a first application for a computing device can be assigned to a first untrustworthy zone (non-trustworthy zone, NTZ) and a second application for the computing device can be assigned to a second trusted zone (TZ).

[0061] In other preferred embodiments, the computing device 100 ( Figure 1 ) has multiple (e.g. as exemplified in Figure 1 As depicted in FIG. 4 ) computing cores 102a, 102b, 102c, 102n, wherein the method further has (see Figure 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.

[0062] In other preferred embodiments, for example, first computing core 102a is assigned to first zone Z1, which may be an untrustworthy zone, and second computing core 102b is assigned to second zone Z2, which may be a trustworthy zone, for example.

[0063] In other preferred embodiments, for example, the third computing core 102c is assigned to both the first area Z1 and the second area Z2, see Figure 1 In other preferred implementation forms, comparable contents may also be applicable to the fourth computing core 102 n of the computing device 100 .

[0064] In other preferred embodiments, according to Figure 1 The computing device 100 may also have Figure 1Other components not specifically mentioned in the description, such as one or more storage devices and / or peripheral components, are not specifically mentioned in the description for the sake of clarity. Figure 1 1 and 2. The data interfaces 104 are collectively outlined by means of a dashed rectangle 130. Reference numeral 104 symbolically represents one or more data interfaces.

[0065] Figure 3 Schematically shows a simplified block diagram of a computing device 100a according to another preferred embodiment, the computing device 100a (which can be compared to the computing device 100a according to Figure 1 The computing device 100 of FIG. 1 has four computing cores 102a, 102b, 102c, and 102n. Figure 3 1 shows a working memory (RAM) 1030, a non-volatile memory 1032 (e.g., a flash memory, in particular a flash EEPROM) and optionally present special function registers 1034 of the computing device 100a, such as they can be used, for example, to control the operation of its peripheral components. The components 102a, 102b, . . . , 1034 are connected to one another via the bus system 101.

[0066] In other preferred embodiments, a method for operating the computing device 100 ( Figure 1 )、100a( Figure 3 ) method further has (see Figure 2C ): Based on at least one zone Z1, Z2, control 230, in particular restrict at least one of the following elements: a) read access to the memory 1030, 1032 assigned to the computing device 100, 100a, b) write access to the memory 1030, 1032 assigned to the computing device, c) execution access ("execution access") to the memory 1030, 1032 assigned to the computing device. This advantageously ensures that only such applications AP1, AP2 (which are assigned to the corresponding zone Z1, Z2) are available. Figure 1 ) obtain access to the mentioned memory 1030, 1032 or the mentioned memory 1030, 1032. For example, in other preferred embodiments, it can be prevented that an application from the untrustworthy area accesses the memory 1030, 1032 or the memory 1030, 1032 (in particular, for example, accesses by the untrustworthy area to the memory area 1030, 1032 assigned to the trusted area), which may involve a risk of possible manipulation of the memory content by the application from the untrustworthy area.

[0067] In other preferred embodiments, the method further comprises (see Figure 2C): at least temporarily using 232 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 ( Figure 3 ) to control read permissions and / or write permissions and / or execute permissions.

[0068] In other preferred embodiments, the method further comprises (see Figure 2D ): at least one dedicated memory protection device M1 is provided 231 for at least one computing core 102a, wherein in particular dedicated memory protection devices M1, M2, M3, M4 are provided for a plurality of, preferably all, computing cores 102a, 102b, 102c, 102n, respectively. In other preferred embodiments, corresponding (dedicated) memory protection devices M1, M2, M3, M4 can then be used, see Figure 2D Step 232' in order to carry out the mentioned control 230, in particular restriction, of the mentioned access rights, in particular read rights and / or write rights and / or execute rights.

[0069] In other preferred embodiments, 232' ( Figure 2D ) may occur before optional configuration 231a of the memory protection device(s).

[0070] In other preferred embodiments (see Figure 2E ) provides that at least one computing core 102a at least temporarily assumes a first operating mode, see step 240 , wherein in particular at least one computing core 102a predetermines and / or writes 242 configuration data 1036 in the first operating mode ( Figure 3 ), the configuration data 1036 controls the operation of at least one memory protection device M1, M2, ..., M5_8, wherein in particular at least one computing core 102a at least temporarily occupies 243 a second operating mode, in which the at least one computing core 102a cannot write and / or change the configuration data for at least one memory protection device M1, M2, ..., M5_8.

[0071] In other preferred embodiments, the first operating mode may also be referred to as a "supervisory mode" or monitoring mode. Preferably, the "supervisory mode" or monitoring mode may therefore be a privileged state in which the relevant computing core 102a may configure at least one memory protection device M1, M2, ..., M5_8.

[0072] In other preferred embodiments, the configuration data for at least one memory protection device M1, M2, ..., M5_8 can be provided, for example, in the form of a special function register (SFR), in particular in the form of a configuration register 1036, which is also accessible at least temporarily via the bus system 101, preferably when the corresponding memory protection device M5_6 is controlled, via the bus system 101. In other words, in other preferred embodiments, for example, a special function register (SFR), in particular a configuration register 1036, can be provided for the configuration data of at least one memory protection device M1, M2, ..., M5_8.

[0073] In other preferred embodiments (see Figure 2E ) provides that at least one computing core 102 a assumes 240 the first operating mode in an event-controlled manner, in particular in response to at least one interrupt request.

[0074] In other preferred embodiments, the method further comprises (see Figure 2F ): Provide more than 250 groups of configuration data KD for at least one memory protection device M1, M2, ..., M5_8, wherein in particular at least one first group of the multiple groups of configuration data KD is assigned to a first area Z1 of at least two areas, and at least one second group of the multiple groups of configuration data KD is assigned to a second area Z2 of at least two areas, see step 252.

[0075] In other preferred embodiments, it is provided that within the scope of special system states, for example in a boot cycle, and / or in the case of certain events, for example when entering an interrupt routine (English: Interrupt Service Routine, ISR), at least one computing core 102a assumes a certain operating mode, such as, for example, a supervisory mode, which can be carried out, for example, in a hardware-controlled manner.

[0076] In other preferred embodiments, at least one other, non-privileged operating mode ("non-privileged mode") is provided for one or more, preferably all computing cores, and the at least one other, non-privileged operating mode may also be referred to as "user mode" in other preferred embodiments. In user mode, the configuration data KD, 1036 for at least one memory protection device M1, M2, ..., M5_8 is preferably not writable. In other words, in other preferred embodiments, a computing core that is exactly in user mode cannot write or change the configuration data KD, 1036 for at least one memory protection device M1, M2, ..., M5_8, while a computing core that is exactly in supervisor mode can write or change the configuration data KD, 1036 for at least one memory protection device M1, M2, ..., M5_8.

[0077] In other preferred embodiments, it is provided that the applications AP1 , AP2 are implemented or executed in a non-privileged mode (eg user mode).

[0078] In other preferred embodiments, for example, three operating modes or operating states or modes can also be set, for example: first is the supervision mode, second is "user mode 1", especially "user mode 1" for (multiple) untrustworthy areas, and third is "user mode 2", especially "user mode 2" for (multiple) trustworthy areas.

[0079] In other preferred embodiments, for example in user mode 1 , the static configuration data KD2 can be active and, for example, the first application program AP1 can be run.

[0080] In other preferred embodiments, for example in user mode 2 , the static configuration data KD3 can be active and, for example, the second application AP2 can be run.

[0081] In further preferred embodiments, in the supervision mode, for example, the static configuration data KD1 are active, wherein the supervision mode is used, for example (optionally only) to switch between the static configuration data KD2 and the static configuration data KD3 .

[0082] In other preferred embodiments, user modes 1 and 2 cannot be switched between the static configuration data KD1 , KD2 , KD3 , KD4 .

[0083] In other preferred embodiments, for example (only) two modes (for example supervisor mode and user mode) can also be provided. In other preferred embodiments, the supervisor mode can thus be assigned to the trusted area, for example, and a switch can be made between the configuration data KD1 and the configuration data KD2, and if necessary, for example, the second application program AP2 can be executed.

[0084] In other preferred embodiments, for different operating modes or operating states (for example, privileged mode and non-privileged mode or supervisor mode, user mode), the corresponding operating mode is given, for example, specific read permissions and / or write permissions and / or implementation permissions (execution permissions) for the or the memory 1030, 1032. This can be achieved in other preferred embodiments, for example, by setting different sets of configuration data KD ("configuration data sets").

[0085] In other preferred embodiments, operating mode-specific and / or application-specific read and / or write permissions and / or execution permissions are assigned to different combinations of (multiple) operating modes and corresponding applications, which can also be achieved in other preferred embodiments, for example, by providing different sets of configuration data KD ("configuration data sets"). For example, for different applications AP1, AP2 ( Figure 1 ) can grant read permissions and / or write permissions and / or implementation permissions adapted to the relevant applications AP1, AP2 respectively.

[0086] In other preferred embodiments, one or more, preferably all of the memory protection devices M1, M2, . . . , M5_8 mentioned by way of example, have a plurality of configuration data sets, which in other preferred embodiments can preferably be efficiently assigned to different modes and applications AP1, AP2.

[0087] In other preferred embodiments, for example when switching between privileged or non-privileged modes (for example from supervisor mode to user mode or vice versa) or when switching between applications, in particular in non-privileged modes, a switch between configuration data sets for the relevant modes or operating modes can be carried out efficiently, in particular in a hardware-controlled manner.

[0088] In other preferred embodiments, the computing device 100, 100a ( Figure 3 ) has, by way of example, the configuration possibilities mentioned below by way of example: a) for assignment to bus system 101 ( Figure 3) a configuration data set, in particular a static (unchangeable) configuration data set, for at least one memory protection device M5_1, ..., M5_8 or at least one central memory protection device, b) four configuration data sets, in particular static configuration data sets, for dedicated memory protection devices M1, M2, M3, M4, respectively, wherein the four configuration data sets for the dedicated memory protection devices in other preferred embodiments have, for example, a static configuration data set for a supervisory mode and three static configuration data sets, for example, for applications AP1, AP2 (i.e., for example, for a user mode). Fig.23 An exemplary configuration data set KD′ is schematically shown with a total of four configuration data sets KD1 , KD2 , KD3 , KD4 .

[0089] In other preferred embodiments, the configuration data define which memory addresses, for example, are allowed to be accessed by components (e.g., computing cores) of the computing device in the form of read and / or write and / or execute. In other preferred embodiments, the memory protection device can be designed to compare the access (read and / or write and / or execute) currently being performed by the relevant computing core with the content of the configuration data and, for example, in the case of consistency, to allow or prohibit the relevant access, or vice versa.

[0090] In further preferred embodiments, the aforementioned, preferably static, configuration data sets for the dedicated memory protection devices M1 , M2 , M3 , M4 , for example for the user mode, can be assigned to the zones Z1 , Z2 according to the embodiments described.

[0091] In other preferred embodiments, in particular in the case of so-called “inter-core zone separation”, for certain computing cores 102 a ( Figure 1 ) only executes applications of a specific area Z2 (for example with the same trust level). In other preferred embodiments, in particular in a dedicated memory protection device M1 ( Figure 3 ), for example, only two, in particular static, configuration data sets are used for such a computing core 102a, for example, one configuration data set for the supervisor mode and one configuration data set for the application in the user mode. In other preferred embodiments, the configuration data set remaining, which has not been used so far, in particular for the application in the user mode, can be configured, for example, in such a way that it prohibits general read access, write access and execute access to the entire memory 1030, 1032, thereby further increasing security.

[0092] In other preferred embodiments, in particular in the case of so-called “intra-core zone separation”, in certain computing cores 102 c ( Figure 1 ), for example, applications of two zones Z1, Z2, each with different trust levels, are executed on a dedicated memory protection device. Preferably, two different static configuration data sets are used for the applications of the first zone Z1 and the applications of the second zone Z2, in particular for the user mode, and preferably another static configuration data set is used for other operating modes, such as the supervisor mode. In other preferred embodiments, the computing core 102c is configured to take over the switch between the two static configuration data sets for the two zones Z1, Z2 in the supervisor mode operating mode. In other preferred embodiments, in the supervisor mode, when, for example, an application AP1 assigned to the first zone Z1 is to be executed, the computing core 102c can therefore activate a configuration data set suitable for the first zone Z1 in its dedicated memory protection device, and when, for example, an application AP2 assigned to the second zone Z2 is to be executed, the computing core 102c can therefore activate a configuration data set suitable for the second zone Z2 in its dedicated memory protection device. In other preferred embodiments, the configuration data sets that may remain and have not been used so far for applications, in particular in user mode (in the exemplary case of a total of four blocks, in the present invention, configuration data sets) can be configured, for example, such that they prohibit general read access, write access and execution access to the entire memory 1030, 1032, thereby further increasing security.

[0093] In other preferred embodiments (see Figure 2G ) is provided that the method further comprises: providing 260 a first instance AP1_I1 of the application program AP1 and a second instance AP1_I2 of the application program AP1; allocating 262 the first instance AP1_I1 of the application program AP1 to a first zone Z1 of at least two zones, and allocating 263 the second instance AP1_I2 of the application program AP1 to a second zone Z2 of at least two zones. This advantageously covers the following application scenarios: in the application scenarios, the application or application program AP1 "extends" over a plurality of zones Z1, Z2. Therefore, in other preferred embodiments, for the application program AP1, there is an instance AP1_I1, AP1_I2 in each zone, respectively, wherein such instances may also be referred to as proxies in other preferred embodiments.

[0094] In other preferred embodiments, such an agent AP1_I2 can include (part of) the functions associated with the other relevant zone Z2. In other preferred embodiments, the agent can also include a plurality of subcomponents, if necessary.

[0095] In other preferred embodiments, the computing devices 100, 100a can, for example, execute the following scenario: If a first application AP1 is to receive data from, for example, an untrustworthy first area Z1 (e.g., remote service requests (Remote Service Requests) (“business inquiries from afar”) from the Internet) and to process or forward the data accordingly within a trusted area Z2 (e.g., for executing a corresponding business (“Remote Service”), then the data is received within the first area Z1 via the Z1 proxy AP1_I1 of the application AP1, wherein the corresponding Z2 proxy AP1_I2, for example, executes the following steps: verifying data that is classified as untrustworthy by the Z2 proxy AP1_I2, especially by default, and (in the case of successful data verification) processing or forwarding the data that is now (after data verification) classified as trustworthy within the second area Z2.

[0096] In other preferred embodiments, the method further comprises (see Figure 2H ): According to at least two areas Z1, Z2, the memories 1030, 1032 assigned to the computing devices 100, 100a are separated 270, wherein the memories assigned to the computing devices 100, 100a have at least one of the following elements: a) a buffer memory, in particular a buffer memory in the form of a working memory, b) a stack memory, c) a data memory, d) a program memory, e) a register memory, wherein at least one memory protection device is used for the separation 270, see optional step 272.

[0097] In other preferred embodiments, the method further comprises (see Fig.2I ): first data are exchanged 280 between different areas via a buffer memory, in particular a working memory, wherein in particular the exchange of first data between a first area Z1 and a second area Z2 comprises the following steps: copying 282 the first data into a first buffer memory area assigned to the first area; checking 283 the copied first data; and in particular based on the checking, copying 283 the first data from the first buffer memory area assigned to the first area Z1 into a second buffer memory area assigned to the second area Z2.

[0098] Figure 4 A simplified block diagram of aspects of a computing device 100, 100a according to another preferred embodiment is schematically shown. Two computing cores 102a, 102b are depicted, which are assigned to the respective areas Z1, Z2 as already described above. A working memory 1030 ( Figure 3 ) area 1030a can be used as a buffer memory or "shared working memory" in the present invention, in particular for data exchange between different areas Z1, Z2 or relevant computing cores 102a, 102b or (instances of) applications executable thereon, wherein the first sub-area TB1 is assigned to the first area Z1 or the second computing core 102b, and the second sub-area TB2 is assigned to the second area Z2 or the first computing core 102a.

[0099] Also in Figure 4 , a plurality of agents PXY are depicted, wherein, for example, a first number of agents Z1-agent 1, Z1-agent 2, ..., Z1-agent n are assigned to a first area Z1 (i.e., computing core 102b in the present invention), and wherein, for example, a second number of agents Z2-agent 1, Z2-agent 2, ..., Z2-agent n are assigned to a second area Z2 (i.e., computing core 102a in the present invention). The reference symbol SSE is used in the present invention to designate a plurality of memory protection devices or their functional components, which are Figure 4 The division of the subareas TB1 , TB2 or zones Z1 , Z2 from one another or from one another according to the principle according to a preferred embodiment is schematically depicted in FIG.

[0100] In other preferred embodiments, at least one of the sub-areas TB1, TB2 can be divided into different areas TB1a, TB1b or TB2a, TB2b, wherein, for example, area TB1a corresponds to an untrustworthy area of ​​the first sub-area TB1, area TB1b corresponds to a trusted area of ​​the first sub-area TB1, area TB2a corresponds to a trusted area of ​​the second sub-area TB2, and area TB2b corresponds to an untrustworthy area of ​​the second sub-area TB2. In other preferred embodiments, it can be provided to separate the sub-areas TB1, TB2 or the different areas TB1a, TB1b or TB2a, TB2b by means of at least one memory protection device.

[0101] In other preferred embodiments (see Figure 2J ) is provided, the method further comprises: separating 290 computing time resources for different applications AP1, AP2 and / or instances of applications, in particular allocating computing time resources for different applications and / or instances of applications according to at least two areas Z1, Z2.

[0102] In other preferred embodiments, the method further comprises: using 292 an operating system BS for embedded systems, in particular a lightweight embedded operating system BS, for allocating computing time resources for different applications AP1, AP2 and / or application instances AP1_I1, AP2_I2, wherein in particular the computing cores of the computing devices 100, 100a are respectively assigned an operating system BS, see Figure 4 .

[0103] In other preferred embodiments, it is provided that, alternatively or in addition to Figure 2J Step 292, the method further comprises: using 294 a supervisor SV for the embedded system (see Figure 5 ), in particular using 294 lightweight embedded supervisor SV for allocating computing time resources to different applications and / or instances of applications, in particular to the computing cores 102c ( Figure 5 ) is assigned a supervisor SV.

[0104] In other preferred embodiments, it is provided that, in particular when using a static (unchangeable) task list, the operating system BS and / or the supervisor SV performs the allocation of computing time resources for predefined tasks (applications and / or instances of applications and / or parts thereof), preferably only for predefined tasks (applications and / or instances of applications and / or parts thereof). In other words, in other preferred embodiments, it is possible to schedule only predefined tasks, which further increases safety.

[0105] In other preferred embodiments, it is provided that the operating system BS ( Figure 4 ) and / or Supervisor SV ( Figure 5 ) performs an allocation of computing time resources, wherein in particular tasks are activated starting from at least one interrupt routine (interrupt service routine ISR, a computer program which is executed when an interrupt request occurs).

[0106] In further preferred embodiments, it is provided that, when the interrupt routine is entered, configuration data for at least one memory protection device M1 , M2 , . . . , SSE are changed, in particular in a hardware-controlled manner.

[0107] In other preferred implementation forms, the lightweight embedded OS BS ( Figure 4 ) or the lightweight embedded supervisor SV ( Figure 5) can, for example, coordinate and / or orchestrate (“scheduling”) (agent) functions (tasks) to be executed periodically or based on events.

[0108] In other preferred embodiments, the lightweight embedded OS BS and the lightweight embedded supervisor have in particular at least one of the following characteristics:

[0109] a) Minimize the attack surface by reducing complexity (code scope, functionality, flexibility, etc.) to the minimum required;

[0110] b) Scheduling only predefined tasks (static task list, no dynamic task list is possible), scheduling e.g. based on ISRs with e.g. periodic interrupt requests (IRQs) (e.g. timer IRQs) and / or event-based IRQs (e.g. Rx IRQs, Tx IRQs, SW IRQs, etc.), activating tasks from ISRs;

[0111] c) upon entering the ISR, preferably switching to the supervisor mode in a hardware-controlled manner, e.g. switching to a static configuration data set for the supervisor mode, preferably switching between static configuration data sets (e.g. for the user mode) is only possible in the supervisor mode;

[0112] d) further preferably, before activating the task, a switch is made from the supervisor mode to the user mode, wherein in particular the task (eg parts of (an instance of) an application) is executed in the user mode, wherein further in particular a switch between (static) configuration data is not possible in the user mode or in the task;

[0113] (e) Advantageously, in other preferred embodiments, it is already possible implicitly through a static (and, if necessary, in particular also complete and actual) configuration of the memory protection device(s), for example during a boot cycle, that the memory protection devices cannot be dynamically reconfigured with the aid of interrupt routines (ISRs) provided for the supervisory mode (for example, configured by the lightweight embedded OS BS / supervisor SV).

[0114] In other preferred embodiments, the method further comprises (see Figure 2K ): Especially with the help of operating system BS ( Figure 4 ) and / or Supervisor SV ( Figure 5), monitoring 300 at least one of the following elements, in particular monitoring 300 at least one of the following elements for potential damage: a) a first zone, b) an application AP1 assigned to the first zone Z1, c) an instance AP1_I1 of the application AP1 assigned to the first zone Z1, wherein in particular the monitoring 300 comprises: evaluating 302 ( Figure 2K ) a stack memory (“stack”) and / or an evaluation 304 of a program counter (“program counter”, PC), wherein the stack memory is preferably evaluated 302 and / or the program counter is evaluated 304 before activating an application and / or an instance of an application.

[0115] In other preferred embodiments, the method further comprises (see Figure 2L ): (see above for Figure 2K ) monitoring 300 and initiating 305 a fault response, especially when the monitoring 300 can infer potential damage, then initiating 305 a fault response.

[0116] In other preferred embodiments, it is provided that the fault response or the start 305 of the fault response has at least one of the following elements (see Figure 2M ): a) in particular by deactivating 305a a computing core 102b assigned to the first zone Z1 and / or resetting 305b a computing core 102b assigned to the first zone Z1 and / or placing 305c a computing core 102b assigned to the first zone Z1 in a fault mode, Figure 1 ) into a safe state, b) generate 305d a fault entry FE and / or c) forward 305e the fault entry or the fault entry to an attack identification system, in particular an intrusion detection system. In other preferred embodiments, the IDS can be arranged internally and / or externally with respect to the computing device 100, 100a, for example.

[0117] In other preferred embodiments, the IDS may also have a distributed implementation, for example, wherein a first partial function (such as, for example, an IDS sensor and, if applicable, an IDS host) is implemented or executed on a computing device or at least one computing core of the computing device, and wherein, in particular, further parts or other partial functions (multiple) are optionally implemented in other devices (such as a backend). In other preferred embodiments, the backend may also be configured, for example, to implement at least one of the following aspects: a) deep expert analysis, b) artificial intelligence (KI), c) machine learning (ML), etc.

[0118] In other preferred embodiments (see Figure 2N) provides that the computing device 100, 100a at least temporarily performs a cold start 310, wherein in particular during the cold start 310, the non-volatile memory 1032 ( Figure 3 ) to load data and / or program code; and wherein the computing device 100, 100a at least temporarily performs a hot boot 312 ( Figure 2N ), wherein in particular during a warm start 312, from the at least temporarily powered volatile memory 1030 ( Figure 3 ) in which data and / or program code are loaded, in particular during a cold start 310 ( Figure 2N ), at least one memory protection device or the at least one memory protection device is configured, see Figure 2N 311 in step 312, and / or wherein in particular (also) during a warm start 312, the at least one memory protection device is configured, see Figure 2N Step 313 in .

[0119] In other preferred embodiments, it is provided that only the following computing cores 102a, 102b, 102c, 102n are equipped with a dedicated memory protection device M1, M2, M3, M4 ( Figure 2D Step 231a in ): The dedicated memory protection devices M1, M2, M3, M4 (see Figure 2D 231 in step 231).

[0120] In other preferred embodiments, the method further comprises (see Figure 2P ): testing 320 the integrity and / or authenticity of configuration data KD, which controls the operation of at least one memory protection device, in particular testing 320 with the aid of at least one of the following elements: a) verifying 322 a program code that can be used to configure at least one memory protection device, b) verifying 324 the configuration data, c) making the program code that can be used to configure at least one memory protection device or the program code that can be used to configure at least one memory protection device persistent 326, d) making the configuration data persistent 328.

[0121] In other preferred specific embodiments, persistence 326 , 328 may include, for example, providing a program code or configuration data which can be used to configure the at least one memory protection device in a read-only memory, such as a ROM or an OTP (one time programmable memory).

[0122] In other preferred embodiments, the method further comprises (see Figure 2Q): In particular, by at least one computing core of the computing device 100, 100a, at least temporarily executing 330 a secure boot method and / or at least temporarily executing 332 a method for manipulation detection (RTMD) during runtime. For example, the method 330, 332 can include: comparing the actually existing memory content of at least a part of the memory 1030, 1032 with a predeterminable reference memory content, wherein the comparison can also include, for example, hash value formation and / or the use of a CMAC (cipher-based message authentication code) method and / or the use of a signature or a signed hash value.

[0123] In other preferred embodiments, the method further comprises (see Figure 2R ): According to at least one zone Z1, Z2, control 340 the access of the application program AP1, AP2 to at least one of the following elements: a) internal interfaces of the computing device, in particular software interfaces, b) internal and / or external hardware interfaces of the computing device, c) hardware security modules and / or cryptographic modules for performing cryptographic functions, d) peripheral devices of the computing device, in particular special function registers of at least one peripheral device, e) internal interfaces of the target system of the computing device, in particular internal interfaces of the control device, f) external interfaces of the target system of the computing device, in particular external interfaces of the control device, g) addressing elements for communication protocols, in particular addressing elements on at least one layer of the ISO / OSI layer model. According to Figure 2R The optional step 342 exemplarily outlines the (further) execution of the relevant application in the zone assigned to it.

[0124] In other preferred embodiments, the method further comprises at least one of the following elements (see Figure 2S ): a) introducing 350 at least one additional, in particular already non-existing, area, b) moving 352 functions from a first computing core 102a to at least one other computing core 102b of a computing device 100, 100a, c) performing 354 communication between at least two areas using a working memory, in particular integrated in the computing device, d) defining 360 (cf. Figure 2T ) at least one trustworthy area and, optionally, monitoring 362 at least one other, in particular untrustworthy area.

[0125] Then refer to Figures 6 to 21Further preferred embodiments, aspects and advantages according to the principles of these embodiments are described, which (according to further preferred embodiments) can be combined with at least one of the embodiments described above, each individually by themselves or in combination with one another.

[0126] Figure 6 Aspects of an interrupt routine ISR1 according to a further preferred embodiment are schematically shown, as it is executable, for example, at least temporarily by at least one computing core 102a , 102b , . . . of a computing device 100 , 100a . Figure 6 The lightning symbol IRQ in represents symbolically an interrupt request that occurs, such as it can be generated, for example, cyclically (for example, predefined by a timer module) and / or in an event-controlled manner (for example, a message arrives at a communication interface). In other preferred embodiments, an interrupt routine ISR1 is then executed, which has at least one of the following elements: e1) at least temporarily storing the environment of the task or program interrupted by the interrupt request IRQ, for example, in a stack memory (for example, it can be defined in a predefined area of ​​RAM 1030), e2) identifying the task to be executed subsequently, e3) switching the current operating mode (for example, supervisor mode) to another operating mode (for example, user mode), e4) restoring the task for the identified area.

[0127] In other preferred embodiments, the control system BS ( Figure 4 ), especially in the case of internuclear region separation, the Figure 6 The interrupt routine ISR1.

[0128] Figure 7 Aspects of an interrupt routine ISR2 according to a further preferred embodiment are schematically shown, as it is executable, for example, at least temporarily by at least one computing core 102a, 102b, . . . of a computing device 100, 100a.

[0129] Figure 7 The lightning symbol IRQ' in the figure symbolically represents an interrupt request (inturupt request) that occurs, such as it can be generated, for example, cyclically (for example, predefined by a timer module) and / or in an event-controlled manner (for example, a message arrives at a communication interface). In other preferred embodiments, an interrupt routine ISR2 is then executed, which has at least one of the following elements: e1') at least temporarily storing the environment of the task or program interrupted by the interrupt request IRQ', for example in a stack memory; optionally: e5) performing an evaluation of, for example, a stack memory (see, for example Figure 2K 302 in ) and / or evaluation of the program counter (see e.g. Figure 2K 304 in step 304); e6) identifying the task to be performed subsequently; e7) converting the environment to the identified area (e.g. from the previous step e6), wherein the identified area is associated with the identified task to be performed subsequently) (alternatively in other preferred embodiments the conversion can also be performed based on addresses, for example with the aid of CAN ID, VLAN ID, MAC address or the like); e8) switching from the current operating mode (e.g. supervisory mode) to another operating mode (e.g. user mode); e9) restoring the environment for the subsequent task.

[0130] In other preferred embodiments, the monitoring device SV ( Figure 5 ), especially in the case of intranuclear region separation, the Figure 7 The interrupt routine ISR2.

[0131] Figure 8 Schematically shows a flow chart according to another preferred embodiment, wherein reference numeral 310′ exemplarily indicates aspects of a cold start of a computing device 100, 100a, and reference numeral 312′ exemplarily indicates aspects of a warm start of a computing device 100, 100a. For example, in the case of a cold start 310′, the RAM 1030 ( Figure 3 ) is not available. For example, in the case of a hot boot 312 ′, a test pattern (Pruefmuster) for verifying the contents of RAM 1030 ( Figure 3 ) content is available.

[0132] In other preferred embodiments, within the scope of a cold start to be run through at least once, a test diagram or pattern can be written to a volatile memory that is supplied, in particular in power-down mode. Due to the aforementioned supply, the aforementioned test diagram or pattern is obtained in the inherently volatile memory. In other preferred embodiments, the (RAM) pattern is tested by a system state machine (System State Machine) (in other preferred embodiments, for example, a state machine that can be used to control the system state) in at least one, in particular each start cycle, and in particular, depending on the presence of the test diagram, a cold start (for example, when the (RAM) pattern is not present) or a hot start (for example, when the (RAM) pattern is present) can be performed.

[0133] In other preferred embodiments, the integrity and authenticity of the volatile memory supplied in power-off mode or the data and functions contained or located therein (in particular for the first area and / or the second area and / or program code, for example configuration data of the computing core 102c and / or the memory protection device) is thus ensured within the scope of a previous cold start (secure boot and / or startup from OTP memory - see above) that must be traversed at least once.

[0134] In other preferred embodiments, the invalid manipulation of the data and functions in the volatile memory provided in the power-off mode and the RAM pattern implies at least a temporary interruption of the supply and thus the clearing of the volatile memory provided in the power-off mode (RAM pattern, etc.). In other preferred embodiments, the system state machine may accordingly initiate a cold start (secure boot and / or boot from OTP—see above) due to the missing RAM pattern within the scope of the boot cycle, in order to ensure the integrity and authenticity of the volatile memory provided in the power-off mode or its data and functions before using or executing them.

[0135] In other preferred embodiments, it is provided that, when a test diagram is present, for example within the scope of a hot restart, the selected time-critical SW instances are not tested before their execution (i.e., for example, in particular without a secure boot), but are tested only at runtime / after their execution, if necessary. This advantageously speeds up the startup time for time-critical SW instances in the case of a hot restart. Therefore, in other preferred embodiments, in the absence of an explicit test during a hot restart, the integrity and authenticity during the hot restart are advantageously also implicitly ensured by the availability of the test diagram (and thus by testing during a preceding cold restart). In other preferred embodiments, components that are not time-critical can also be tested during a hot restart explicitly before their execution (e.g., by means of a secure boot process).

[0136] Block 102a_1 symbolically represents, by way of example, the first computing core 102a ( Figure 3), and therefore can be compared to a hardware security reference similar to a TPM (trusted platform module) or a hardware security module (HSM); block 102a_2 represents a boot manager associated with the computing core 102a (a system program that controls the loading and / or execution of other systems and / or applications). Block 102a_3 represents the execution of program code associated with the zone Z2 and the computing core 102a. Block 110 represents a hardware security module. Block 111 represents a boot manager associated with the computing core 102c. Block 112 represents the execution of program code associated with the zones Z1, Z2 and the computing core 102c (the computing core 102c is exemplarily and as has been described many times before, assigned to the two zones Z1, Z2). Block 113 represents a boot manager associated with the computing core 102b. Block 114 represents the execution of program code associated with the zone Z1 and with the computing core 102b. Block 115 represents a boot manager associated with the computing core 102n. Block 116 represents the execution of program code associated with zones Z1 , Z2 and compute core 102n.

[0137] Arrow a1 symbolically represents a boot process (eg, starting the computing device 100a from a completely deactivated state). Arrow a2 symbolically represents the configuration of at least one memory protection device, in particular a central one or one assigned to the bus system 101 ( Figure 3 ) of the memory protection devices M5_1, M5_2, . . . , M5_8. Arrow a3 symbolically represents starting the boot manager for the computing core 102c, see also block 111.

[0138] Arrow a4 symbolically represents at least one dedicated memory protection device M3 ( Figure 3 ). Arrow a5 symbolically represents the start of execution 112 of the program code by computing core 102c. Arrow a6 symbolically represents an optional verification of computing core 102c, for example in the form of RTMD.

[0139] Arrow a7 also symbolically represents an optional verification of computing core 102c in the context of cold start 310'. In other preferred embodiments, optional verification a7 can be performed with the aid of cryptographic methods (e.g. based on CMAC and / or signed hash values). Arrow a8 symbolically represents the start of a boot manager for computing core 102c, similar to arrow a3, see also block 111. Arrow a9 symbolically represents the configuration of at least one dedicated memory protection device M3 ( Figure 3 ). Arrow a10 symbolically represents the start of execution 112 of the program code by the computing core 102c, similar to arrow a5.

[0140] Arrow a11 symbolically represents an optional verification of multiple, preferably all computing cores 102a, 102b, ..., 102n. Arrow a12 symbolically represents the start of a boot manager for computing core 102n, see also block 115. Arrow a13 symbolically represents the configuration of at least one dedicated memory protection device for computing core 102n. Arrow a14 symbolically represents the start of the execution 116 of the program code by computing core 102n. Arrow a15 symbolically represents the start of the boot manager for computing core 102b. Arrow a16 symbolically represents the configuration of at least one dedicated memory protection device for computing core 102b. Arrow a17 symbolically represents the start of the execution 114 of the program code by computing core 102b. Arrow a18 symbolically represents the start of the boot manager for computing core 102a. Arrow a19 symbolically represents the configuration of at least one dedicated memory protection device for computing core 102a. Arrow a20 symbolically represents the start of execution 102 a_3 of the program code by computing core 102 a .

[0141] Fig. 9 Aspects of an interrupt routine ISR3 according to a further preferred embodiment are schematically shown, as it is executable, for example, at least temporarily by at least one computing core 102a, 102b, . . . of a computing device 100, 100a. Fig. 9 The lightning symbol IRQ'' in the figure symbolically represents an interrupt request that occurs, such as it can be generated, for example, cyclically (for example, it can be predetermined by a timer module) and / or on the basis of software (for example, it can be called by an application). In other preferred embodiments, an interrupt routine ISR3 is then executed, which has at least one of the following elements: e1') at least temporarily storing the environment of the task or program interrupted by the interrupt request IRQ''; optionally: e5') performing, for example, an evaluation of a stack memory (see, for example Figure 2K 302 in ) and / or evaluation of the program counter (see e.g. Figure 2K 304 in step 10); e10) switching the environment to the next task (for example, according to a preferably static task list); e11) switching the current operating mode (for example, supervisor mode) to another operating mode (for example, user mode); e12) resuming the task for the identified area.

[0142] Fig.10 Schematically shows a computing core 102a according to another preferred embodiment, to which an operating system BS and / or a supervisor SV (similar to Figure 5 , not in Fig.10), and the computing core 102a itself is assigned to two areas Z1, Z2. The computing core 102a can, for example, be used in a network switch, for example to send and / or receive Ethernet data packets. The corresponding instances of the application are characterized by the reference numerals AP3_I1 (receive Ethernet packets, executed in area Z1), AP3_I2 (receive Ethernet packets, executed in area Z2), AP4_I1 (send Ethernet packets, executed in area Z1), AP4_I2 (send Ethernet packets, executed in area Z2). For example, other applications that perform management tasks for a network switch only run in the second area Z2 defined as trustworthy, but not in the first area Z1 defined as untrustworthy. The computing core 102a is assigned a RAM 1030, which in other preferred embodiments can be, for example, analogous to Figure 5 Optionally, a switching engine (Switching-Engine) (eg a coupling network) and / or a TCAM (ternary content-addressable memory) module is provided.

[0143] Fig.11 Two computing cores 102a, 102b are schematically shown according to a further preferred embodiment, wherein the first computing core 102a is assigned to the first zone Z1 and wherein the second computing core 102b is assigned to the second zone Z2. An operating system BS is respectively assigned to the two computing cores 102a, 102b.

[0144] exist Fig.11 The first instances of the different applications, which are collectively labeled with the reference numeral I1 for the sake of clarity, are assigned to the first zone Z1 and thus to the first computing core 102a. In other preferred embodiments, the different applications have, for example, at least one of the following elements: a) a program for performing an investigation of data packets, in particular for deep packet inspection DPI, b) a program for diagnosis, c) a program for performing an update, in particular by means of FOTA (firmware over the air) technology (for example by means of data interface 1008, Fig. 22) to execute the updated program, d) a program for attack identification and attack defense (Intrusion Detection and Prevention). In other preferred embodiments, the second computing core 102b and the second area Z2 are assigned a corresponding second instance I2 of the application described above with respect to the first area Z1. According to other preferred embodiments, at least one memory protection device SSE can be used to control the read permission and / or write permission and / or execution permission of the corresponding application or instance of different areas. By referring to the example above Fig.11 The described configuration, for example for electronic control devices and / or embedded systems and / or IoT systems, etc., can effectively provide a particularly secure system for investigating data packets or for attack identification and attack defense, wherein by assigning instances I1, I2 of the application to zones Z1, Z2, for example, environments for execution (implementation) with different trust levels can be provided respectively, which is particularly advantageous.

[0145] Fig. 12A Aspects of an interrupt routine ISR4 according to a further preferred embodiment are schematically shown, as it is executable, for example, at least temporarily by at least one computing core 102a , 102b , . . . of a computing device 100 , 100a . Fig. 12A The lightning symbol Rx in the figure symbolically represents an interrupt request that occurs, such as can be generated, for example, in an event-controlled manner, as can be generated in the present invention, for example, when receiving a message, such as a CAN (Controller Area Network) message. In other preferred embodiments, an interrupt routine ISR4 is then executed, which has at least one of the following elements: e20) at least temporarily storing the environment of the task interrupted by the interrupt request Rx, in particular the sending task ("Tx task"), for example for sending a message or a program; optionally: e21) performing, for example, an evaluation of a stack memory (see, for example Figure 2K 302 in ) and / or evaluation of the program counter (see e.g. Figure 2K); e22) determining the area to which the received data frame (e.g. the received CAN message mentioned) is associated; e23) switching the environment to the area determined in step e22; e24) switching from the current operating mode (e.g. supervisory mode) to another operating mode (e.g. user mode); e25) calling a processing routine for message reception ("Receive (Rx) handler"), i.e. calling an application or part of an application that processes received messages; e26) resuming the task for the identified area (e.g. send task).

[0146] In further preferred embodiments, a sending task, ie a task for sending a message or an application or a part of an application, is planned (“scheduling”).

[0147] In other preferred embodiments, an interrupt request characterizing the reception of a message (“Rx IRQ”, receive interrupt request) is processed with a higher priority than other interrupt requests which are typically triggered by a timer and / or an application or software, for example.

[0148] In other preferred embodiments, interrupt requests that are incoming simultaneously or within a predefinable first time range are prioritized, for example, depending on the source of the interrupt request (incoming message, timer, software) and / or depending on one or more further or other criteria. In other preferred embodiments, such prioritization can be performed, for example, by a control device for the interrupt requests (interrupt controller).

[0149] In other preferred embodiments, the environment can be switched only in a predeterminable operating mode, in particular in a supervisory mode (see, for example Fig. 12A Step e23).

[0150] In other preferred embodiments, the above exemplary reference Fig. 12A The described aspects can be used, for example, to at least temporarily control the processing of incoming messages for a lightweight supervisor, in particular a CAN lightweight supervisor.

[0151] Fig. 12B Aspects of an interrupt routine ISR5 according to a further preferred embodiment are schematically shown, as it is executable, for example, at least temporarily by at least one computing core 102a , 102b , . . . of a computing device 100 , 100a . Fig. 12BThe lightning symbol TIM_SW in the figure symbolically represents an interrupt request (interrupt request) that occurs, such as can be generated, for example, by a timer or an application program or, in general, by software. In other preferred embodiments, an interrupt routine ISR5 is then executed, which has at least one of the following elements: e30) at least temporarily storing the environment of the task interrupted by the interrupt request Rx, in particular the send task ("Tx task"), for example for sending a message or a program; optionally: e31) performing an evaluation of, for example, a stack memory (see, for example Figure 2K 302 in step 100) and / or a program counter (see e.g. Figure 2K 304 in step 304); e32) switching the environment to the next sending task (for example, based on a particularly static task list); e33) switching from the current operating mode (for example, supervisor mode) to another operating mode (for example, user mode); e34) resuming the task for the identified area (for example, the sending task).

[0152] In other preferred embodiments, the above exemplary reference Fig. 12A The other aspects described apply in a corresponding manner to Fig. 12B The interrupt routine ISR5.

[0153] Fig.13 A simplified block diagram of aspects of a computing device 100b according to a further preferred embodiment is schematically shown. In the present invention, the computing device 100b has, by way of example, four computing cores K1, K2, K3, K4, wherein the first computing core K1 is designed to process communication messages, in particular CAN messages. Thus, in a further preferred embodiment, according to Fig.13 The first computing core K1 can also be referred to as a "CAN core". The other computing cores K2, K3 are provided for executing (if necessary different instances of) application programs and in other preferred embodiments can therefore also be referred to as "application cores" or in English "Application Cores" K2, K3. Fig.13 The fourth computing core K4 is designed to process Ethernet communication messages and can therefore also be referred to as Ethernet core or ETH core K4 or in English as "ETHCore" K4 in other preferred embodiments. A first supervisor SV1, in particular a CAN lightweight supervisor, is assigned to the first computing core K1, and a second supervisor SV2, in particular an ETH (Ethernet) lightweight supervisor, is assigned to the fourth computing core K4.

[0154] In other preferred embodiments, the first computing core K1 is assigned to the two zones Z1 , Z2 . In other preferred embodiments, the fourth computing core K4 is also assigned to the two zones Z1 , Z2 .

[0155] In a further preferred embodiment, an application for sending and / or receiving CAN messages is assigned to the first computing core K1, wherein Fig.13 The reference numeral I1 in the figure denotes a first instance of the application, which is assigned to the first zone Z1 and is designed to receive CAN messages. In contrast, the reference numeral I2 denotes a second instance of the application, which is assigned to the second zone Z2 and is designed to receive CAN messages. The reference numerals I3, I4 denote corresponding instances for sending and receiving CAN messages, which are also assigned to one of the two zones Z1, Z2, respectively.

[0156] In other preferred embodiments, the above exemplary reference Fig. 12A , 12B The interrupt request Rx, TIM_SW described can be processed by the first computing core K1, for example, by executing the corresponding interrupt routine ISR4 ( Fig. 12A ) or ISR5 ( Fig. 12B ) to handle it.

[0157] In a further preferred embodiment, an application for sending and / or receiving Ethernet messages is assigned to the fourth computing core K4, wherein Fig.13 The reference numeral I1' in the figure denotes a first instance of the application, which is assigned to the first zone Z1 and is designed to receive Ethernet messages. In contrast, the reference numeral I2' denotes a second instance of the application, which is assigned to the second zone Z2 and is designed to receive Ethernet messages. The reference numerals I3', I4' denote corresponding instances for sending or receiving Ethernet messages, which are also assigned to one of the two zones Z1, Z2, respectively.

[0158] In further preferred embodiments, the separation of the two areas Z1 , Z2 within the computing cores K1 , K4 is achieved using in each case at least one memory protection device SSE1 , SSE4 .

[0159] As already mentioned above, the two application cores K2, K3 are designed to execute application programs, which or their respective instances are Fig.13 , which are outlined as rectangles within the respective application cores K2, K3, but are not indicated in more detail for reasons of clarity. In other preferred embodiments, the second computing core K2 is assigned to the second area Z2, and the third computing core K3 is assigned to the first area Z1.

[0160] In a further preferred embodiment, the computing device 100b has a volatile memory, in particular a working memory (RAM) 1030b, which can be analogously described in accordance with Figure 4 The diagram is divided into different areas, which are respectively assigned to different computing cores K1, K2, K3, K4 or their areas Z1, Z2.

[0161] For example, according to Fig.13 The first area B1 of the working memory 1030b of the computing device 100b is assigned to the first computing core K1, wherein the first subarea B1_1 is assigned to the first zone Z1, and the second subarea B1_2 is assigned to the second zone Z2. In other preferred embodiments, a similar division into corresponding areas or subareas B4, B4_1, B4_2 is also possible for the fourth computing core K4.

[0162] In other preferred embodiments, other areas B2, B3 of the working memory 1030b can be allocated to, for example, application cores K2, K3. In other preferred embodiments, for example, area B2 can be further divided into a trusted area B2' and an untrusted area B2". In other preferred embodiments, analogous contents can also apply to the third application core K3, see the figure marks B3', B3".

[0163] In other preferred embodiments, one or more further memory protection devices may be provided in order to achieve a corresponding separation in terms of, for example, read permissions and / or write permissions and / or execute permissions according to the preferred embodiment, wherein the further memory protection devices are Fig.13 They are collectively denoted by the reference symbol SSE'.

[0164] In other preferred embodiments, according to Fig.13 The computing device 100b can, for example, provide the function of a gateway, that is, the function of a network coupling element, which can, for example, couple a CAN bus (see CAN core K1) to an Ethernet network (see ETH core K4). In other preferred embodiments, for example, 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 can assume the function of a so-called high-speed engine for Ethernet messages.

[0165] Fig.14 A flow chart according to a further preferred embodiment is schematically shown, which explains by way of example the processing of an interrupt request, for example when receiving a message, in particular a CAN message.

[0166] Block ISR6 exemplarily represents an interrupt routine which is executable, for example, in the case of at least one of the following interrupt requests: a) receiving a message ("Rx"), b) signaling of a timer ("Timer"), c) interrupt request generated by software ("SW"). Block T_RX_Z1 exemplarily represents a task (e.g. part or instance of an application program) which is assigned to area Z1 and is executed when a message is received ("Rx"), analogously to a task according to Fig.13 The block T_RX_Z2 exemplarily represents a task assigned to the zone Z2 and executed when receiving a message, which can be compared to the task assigned to the zone Z2 and executed when receiving a message. Fig.13 The block T_TX_Z1 exemplarily represents a task assigned to the zone Z1 and executed when sending a message, which can be compared to the task assigned to the zone Z1 and executed when sending a message according to Fig.13 The block T_TX_Z2 exemplarily represents a task assigned to the zone Z2 and executed when sending a message, which can be compared to the task assigned to the zone Z2 and executed when sending a message according to Fig.13 Instance I4 of the first computing core K1 of the computing device 100b.

[0167] Arrow a30 represents an interrupt request triggered by receiving a (CAN) message, which in particular interrupts the execution of the currently running task (see the sending task T_TX_Z2), see arrow a30'. Therefore, in other preferred embodiments, the receiver task T_RX_Z1 is called by the interrupt routine ISR6, see arrow a31. After the execution of the receiver task T_RX_Z1, preferably with the help of a software interrupt request (Software-Interrupt (software interrupt)) a32, it branches again to the interrupt routine ISR6, which then continues the previously interrupted sending task T_TX_Z2, see arrow a33. When an interrupt request (timer IRQ) generated by a timer occurs a34, the interrupt routine ISR6 calls the sending task T_TX_Z1, see arrow a35, which leads to the interruption a34' of the previously running sending task T_TX_Z2.

[0168] From the basis Fig.14From the diagram and the preceding description it can be clearly seen how different program parts (tasks) executable by a computing device according to the embodiment can be executed, which program parts (tasks) can be assigned to different areas Z1, Z2, ... according to the principle according to the embodiment (more than two areas are also possible according to other preferred embodiments), or how the execution of the program parts (tasks) can be controlled, for example, by an interrupt routine ISR6, which can, for example, be a component of an operating system BS and / or a supervisor SV.

[0169] Fig.15 A simplified block diagram of aspects according to further preferred embodiments is schematically shown, wherein the present invention depicts an application case by way of example: the application case relates to an exemplary zone transition ZT, i.e. the transfer of data from a first zone according to a preferred embodiment to a second zone according to a preferred embodiment.

[0170] according to Fig.15 The first calculation kernel K1 corresponds to the one previously described with reference to Fig.13 The CAN core K1 already described, and Fig.15 The other calculation kernels K2 and K3 in correspond to Fig.13 Analogous contents also apply to the areas B1, B2, B3 or their subareas of the working memory 1030b.

[0171] Arrow A1 indicates the reception of a CAN message, which triggers processing by the instance I1 of the corresponding application of the first computing core K1. Such data are transferred via the working memory (see arrow A2) from the instance I1 assigned to the first area Z1 to an instance I5 of the application for processing the data of the received CAN message or data derived therefrom, which is assigned to the first area Z1 and is executable by the third computing core K3 (see arrow A3). Fig.15 The reference numeral I6 in the figure indicates an instance of an application for investigating data packets, in particular deep packet inspection DPI, which investigates the received data in more detail and then writes the received data to a sub-area B3" of the working memory 1030b, see arrow A5. Then, a further instance I6' of the DPI application, which is executed on the second computing core K2 and assigned to the second area Z2, reads the data from the sub-area B3", which corresponds to the area transition ZT already mentioned above, see arrow A6.

[0172] In other preferred embodiments, a payload analysis, in particular a deep payload analysis (in the sense of DPI), is performed, for example, by instance I6' ("Z2-DPI agent", i.e. an agent assigned to the second zone Z2 for executing DPI methods), wherein instance I6 ("Z1-DPI agent", i.e. an agent assigned to the first zone Z1 for executing DPI methods) is preferably responsible for copying the data to B3".

[0173] After optional further processing of the data by the second computing core K2 (see arrow A7), the data or data derived therefrom are written by instance I5' to storage area B1_2 of working memory 1030b, see arrow A8, from which the data are retrieved by instance I4, which is constructed, for example, for sending CAN messages and is assigned to the second area Z2 and executable by the CAN core K1, and, for example, sent out again to the CAN bus, see arrow A10.

[0174] In the foregoing exemplary reference Fig.15 The described scenario can be used for at least one of the following application cases: a) diagnostics using CAN messages, b) DPI applied to CAN messages, c) formation of a proxy, for example for communication and / or diagnostic protocols etc., d) routing from, for example, a first CAN bus to, for example, a second CAN bus, in particular with the inclusion of an application (which, for example, enables processing of the CAN messages to be routed, in particular analysis and / or modification).

[0175] Follow Fig.13 and Fig.15 , Fig.16 A simplified block diagram of aspects according to further preferred embodiments is schematically shown, wherein the present invention depicts an application case by way of example: the application case relates to an exemplary zone transition ZT', i.e. the transfer of data from a first zone according to a preferred embodiment to a second zone according to a preferred embodiment. Fig.15 The scenarios are different, according to arrows A11 to A20, in accordance with Fig.16 In the scenario, the zone transition ZT' starts from the Ethernet core K4 to the CAN core K1.

[0176] from Fig.16 As can be seen in FIG. 1 , after receiving the A11 Ethernet message, the corresponding data are stored in the memory area B3' (arrow A12), read from the memory area B3' by the application core K3 assigned to the first zone Z1 (arrow A13), processed (arrow A14), and then the corresponding processed data are written to the other memory area B3" (arrow A15).

[0177] The data are then read in by the application core K2 assigned to the second area Z2 (see arrow A16), processed (see arrow A17), and written to the further memory area B1_2 (see arrow A18). The data are then read in by the CAN core K1 from the further memory area B1_2 (arrow A19), processed by the instance I4 (part of the application for sending CAN messages), and sent on the CAN bus (not shown) (see arrow A20).

[0178] Fig.17 The example shows Fig.16 A comparable configuration is shown in which an incoming Ethernet message is received by computing core K4 ( A21 ), buffered ( A22 ) in working memory 1030 b , read out ( A23 ) by instance I3 of first computing core K1 , and sent to the CAN bus ( A24 ).

[0179] Follow Fig.13 and Fig.15 , Fig.18 A simplified block diagram of aspects according to further preferred embodiments is schematically shown, wherein the present invention exemplarily depicts an application scenario in which a hardware security module HSM is used. In the present invention, the hardware security module HSM is exemplarily integrated into a computing device (not shown). Fig.18 Indicated in, see e.g. Figure 1 In the figure 100 in FIG. 1 ), the computing device also has a second computing core K2 ', and the hardware security module HSM is designed to perform cryptographic functions. In other preferred embodiments, the cryptographic functions can, for example, include storing (secret) keys and / or forming hash values ​​and / or signatures, etc.

[0180] In other preferred embodiments, the hardware security module HSM is an independent ("on-chip") module, which is preferably arranged on the same semiconductor substrate or die (chip) as the computing device. Preferably, the hardware security module HSM has its own computing core (not shown) and, if necessary, its own memory, etc.

[0181] In other preferred embodiments, a cryptographic stack KS is provided, which can be used for communication between a computing core of a computing device and a hardware security module HSM. In other preferred embodiments, the cryptographic stack KS is implemented only on the computing core K2', in particular for security reasons, since the computing core K2' is, in the present invention, exemplarily the only computing core of the computing device, which is only assigned to the trusted zone Z2. Therefore, in other preferred embodiments, the computing core K2' can be regarded as the "most secure core", that is, the most secure computing core. Arrows A31, A32, A33, A34, A35, A36 exemplarily represent the following steps: receiving (A31) an Ethernet message, storing (A32) the received message in area B3', loading (A33) the message by an application of the third computing core K3, processing (A34) the loaded message by the third computing core K3, writing (A35) data obtained during the processing to the storage area B3", and loading (A36) the written data from the storage area B3" by an application executable on the second computing core K2.

[0182] In other preferred embodiments, the second computing core K2 processes the loaded data, in particular also when using a hardware security module HSM, see arrow A37. The processing A37 can, for example, include encryption of the data. The processed data A38 are then written (A38) to the memory area B1_2. Thereafter, the data are loaded (A39) from the memory area B1_2 by the instance of the CAN core K1 and sent to the CAN bus.

[0183] Follow Fig.18 , Fig.19A simplified block diagram according to aspects of other preferred embodiments is schematically shown, wherein the present invention exemplarily depicts the following application scenario: in the application scenario, for example, a firmware update, in particular a firmware update of the FOTA (Firmware Over The Air) type, can be performed. In a preferred embodiment, data can be received, for example, via an Ethernet connection, for example by means of a fourth computing core K4, see arrow A41. An instance I1' of the receiving program writes the received data to a memory area B3", see arrow A42. An instance of the application program on the application computing core K3 loads (A43) the data from the memory area B3" and processes (A44) the data. Other instances I7, for example the first FOTA agent I7, extract the data required for the FOTA process from the processed data and write (A45) the extracted data to a memory area B3", which memory area B3", for example (in particular from the perspective of the second area Z2) is considered untrustworthy. The following instance I8 of the application loads (arrow A46) the data from the memory area B3": the instance I8 is, for example, a second FOTA agent and can be executed on the computing core K2". Optionally, an encryption method can then be performed on the loaded data by the computing core K2", for example a CMAC formation, which advantageously uses a hardware security module HSM, see arrow A47. In other preferred embodiments, the processed data or the CMAC value can optionally be stored in an external memory, see arrow A48. In other preferred embodiments, such storage is controlled by the FOTA agent I8.

[0184] In other preferred embodiments, the second area Z2 has only read access to the storage area B3″, but in particular no write access and / or execution access. In other preferred embodiments, this can be done in a corresponding manner, for example, as also described above by way of example. Figure 4 , 5 The described configuration applies.

[0185] In other preferred specific embodiments, an entire memory image (“ECU image”) 1033 a , for example for at least one computing core or the entire computing device and / or a corresponding control unit, may be temporarily stored in external memory 1033 .

[0186] In other preferred embodiments, the application program or its corresponding instance that can be executed by the second computing core K2″ can, for example, test or verify the content of the data stored in the external memory 1033.

[0187] In other preferred embodiments, for example after successful verification of the data contained in the external memory 1033, the corresponding memory image 1033a can be distributed to one or more external devices (not shown), see arrows A49, A50, A51, A52, which further involve copying the memory image 1033a from the external memory 1033a (e.g. block by block) to the storage area B1_2 of the working memory 1030b (A50) and from there (e.g. block by block) to the instance I4 (e.g. CAN send task).

[0188] In other preferred embodiments, the verification can preferably be performed based on a digital signature and / or a signed hash value. For example, in other preferred embodiments, a signed hash value may exist for each ECU image. In other preferred embodiments, the signature verification can preferably be performed via a hardware security module HSM.

[0189] In other preferred embodiments, for example also during the distribution or copying of the memory image 1033a, the CMAC value and / or another value that allows the integrity and / or authenticity of the relevant blocks to be checked can be checked, preferably again block by block, for example under the control of a corresponding instance of an application running, for example, on the second computing core K2", optionally with the assistance of a hardware security module HSM.

[0190] In other preferred embodiments, for example, the generation and verification of a CMAC value can serve in particular as a supplementary integrity and authenticity protection, for example for signature verification. In other preferred embodiments, for example, a single data packet or each single data packet from buffer B3" can be provided with a CMAC value or a truncated ("truncated") CMAC value. In other preferred embodiments, for example, the (said) data packet is verified before transmission to buffer B1_2, thereby ensuring in particular that only complete and authentic data packets arrive in buffer B1_2. In other preferred embodiments, buffer-based CMAC generation and verification is optional. Fig. 20 , 21 A flow chart according to a further preferred embodiment is schematically shown, which explains by way of example the processing of an interrupt request (for example when receiving a message, in particular a CAN message).

[0191] Block ISR7 represents, by way of example, an interrupt routine which can be executed, for example, in the case of an interrupt request which signals (“Rx ISR”) the receipt of a message (“Rx”).

[0192] Block ISR8 represents, by way of example, an interrupt routine which can be executed, for example, in the case of at least one of the following interrupt requests: a) signaling of a timer (“Timer”), b) an interrupt request generated by means of software (“SW ISR”).

[0193] Block RX_H_Z1 represents, by way of example, a receive handler (eg, a part or instance of an application program that controls the reception of messages): This receive handler is assigned to zone Z1 and is executed when a message is received ("Rx"), similar to the process described in accordance with Fig.13 An instance I1 of the first computing core K1 of the computing device 100b.

[0194] Block RX_H_Z2 exemplarily represents a receive processing program (eg, a portion or instance of an application program that controls the reception of messages): the receive processing program is assigned to zone Z2 and is executed when receiving ("Rx") a message, which can be compared to the receive processing program according to Fig.13 An instance I2 of the first computing core K1 of the computing device 100b.

[0195] Block T_TX_Z1' exemplarily represents a task assigned to zone Z1 and executed when sending a message, which can be compared to Fig.13 The block T_TX_Z2' exemplarily represents a task assigned to the zone Z2 and executed when sending a message, which can be compared to the task assigned to the zone Z2 and executed when sending a message according to Fig.13 Instance I4 of the first computing core K1 of the computing device 100b.

[0196] Arrow a40 represents an interrupt request triggered by receiving a (CAN) message, which interrupt request in particular interrupts the execution of the currently running task (see send task T_TX_Z2'), see arrow a40'. Therefore, in other preferred embodiments, the receive processing program RX_H_Z1 is called by the interrupt routine ISR7, see arrow a41. After the receive processing program RX_H_Z1 is executed, it returns to the interrupt routine ISR7 (for example, preferably by an interrupt request generated by software), arrow a42.

[0197] According to Fig. 20, and then execute the transmission task T_TX_Z1', see arrow a43. In other preferred embodiments, this can have the following particular advantage: by the task RX_H_Z1, the static configuration of the memory protection device for the first area Z1 (for example, the corresponding configuration data set) is already activated, which static configuration is preferably also applicable to the transmission task T_TX_Z1'. As a result, especially from a performance point of view, it is possible to save the conversion of the relevant static configuration of the memory protection device before executing the transmission task T_TX_Z1'.

[0198] When an interrupt request (timer IRQ) generated by a timer occurs a44, the interrupt routine ISR7 calls the transmission task T_TX_Z2', see arrow a45, which leads to the interruption a44' of the previously running transmission task T_TX_Z1'. Preferably, before executing the transmission task T_TX_Z2', a switch is made to the static configuration of the area Z2 (e.g., a corresponding configuration data set). After this, the process returns to the interrupt routine ISR7, for example, by means of a software interrupt a46, and the transmission task T_TX_Z1' is then continued, see arrow a47.

[0199] In other preferred embodiments, according to Fig. 20 , 21 The interrupt routine ISR7 can for example have the same Fig. 12A The configuration of ISR4 can be comparable or identical to the configuration.

[0200] Further preferred embodiments, aspects and advantages according to the principles of these embodiments are described below, which (according to further preferred embodiments) can each be combined individually by themselves or in combination with one another with at least one of the embodiments described above.

[0201] In other preferred embodiments, as a measure for limiting the attack surface of the computing device, it is possible to use, for example, Figure 4 , 5The access rights of the memory 1030a are restricted, thereby enabling, for example, a region-by-region memory separation when using the mechanism of a memory protection device known per se. Particularly preferably, in other embodiments, the region-by-region memory separation can be performed in the case of the following exemplary memory forms: buffer (buffer memory), for example in the form of a trusted buffer memory (TrustedBuffer (for example in the shared RAM 1030)) and / or in the form of an untrusted buffer memory (Non-Trusted Buffer (for example in the shared RAM 1030)), stack (stack memory), data memory (for example data flash, EEPROM, etc.), program memory (for example program flash, ROM, etc.), SFR (special function register).

[0202] In other preferred embodiments, data can be exchanged between different areas ("intra-area and / or inter-area data exchange"), for example, via a shared RAM (shared working memory, see Figure 4 This is achieved by the buffer in the reference numeral 1030a).

[0203] In other preferred embodiments, at least one trusted buffer and one untrusted buffer can be provided for each instance I1, I2, I3 ("proxy") of the application and each area (depending on the application, the buffer can be omitted if necessary), for example, see Figure 4 Sub-areas TB1a and TB1b in.

[0204] In other preferred embodiments, data exchange or intra-region communication within a region is carried out (in particular exclusively) via the trusted buffer TB2a ( Figure 4 )conduct.

[0205] In other preferred embodiments, data exchange or inter-area communication between areas is preferably carried out via an untrusted buffer TB1a in a shared RAM 1030a. For example, if data is to be transferred from area Z1 to area Z2 in other preferred embodiments, the data is first copied by the Z1 agent to the associated Z1 untrusted buffer, verified by the associated Z2 agent regarding its validity in terms of content, and copied by the Z2 agent to the Z2 trusted buffer in the case of valid or content-correct, trustworthy data. In other preferred embodiments, the copying process from the Z1 untrusted buffer to the Z2 trusted buffer after successful data verification is called area transition. In other preferred embodiments, the verified, trustworthy data located in the Z2 trusted buffer can be processed or forwarded accordingly within Z2, that is, in other preferred embodiments, data verification is performed before area transition and, if necessary, data use.

[0206] A further measure for limiting the attack surface of the computing device according to these embodiments is to limit the access rights to the runtime according to further preferred embodiments, in which case the limitation can be carried out, for example, by controlling a corresponding operating system BS or supervisor SV.

[0207] In other preferred embodiments, for example, according to the above exemplary embodiment Figure 4 A lightweight embedded operating system BS, for example the AUTOSAR (AUTomotive Open System ARchitecture) BS, can serve as the basis, which in other preferred embodiments is reduced to a minimum with regard to its complexity (eg via configuration etc.).

[0208] In other preferred embodiments, even if the damaged computing core 102a ( Figure 3 ) (e.g. abuse of the supervisor mode in the lightweight embedded OS ISR), invalid zone transitions or invalid accesses by Z1 to Z2 memory or runtime may not be performed either - the reason being: the static and greatly reduced functionality of the lightweight embedded BS (in other preferred embodiments, in particular partial functionality in the supervisor mode) therefore enables no abuse of privileges in the supervisor mode.

[0209] In a further preferred embodiment, an ISR (interrupt routine) running in supervisory mode can only switch between static configuration data sets for the memory protection device specific to the computing core in question. In other preferred embodiments, the same static configuration data set for the supervisor mode and the user mode of the computing core allows access only to the memory and / or runtime that is assigned to the relevant area (for example, the first area Z1 ).

[0210] In other preferred embodiments, an ISR operating in supervisory mode is not capable of dynamically reconfiguring the memory protection device(s), which can be achieved in particular implicitly by a static, complete and actual configuration of the memory protection device(s) during a boot cycle (e.g. during a cold start and / or during a hot start).

[0211] In other preferred embodiments, tasks running in user mode, for example assigned to the first area Z1, cannot be switched between static configuration data sets of the memory protection device that are specific to a specific computing core, since in other preferred embodiments such a switch is only possible in supervisor mode.

[0212] In other preferred embodiments, a task running in user mode, for example assigned to the first area Z1, cannot dynamically reconfigure the memory protection device(s), which can advantageously and implicitly be achieved by configuring the memory protection device(s) during a startup cycle (i.e., for example during a cold start and / or during a hot start) as follows: the configuration is a static, complete and actual configuration provided in other preferred embodiments.

[0213] In other preferred embodiments, the supervisor SV (especially a lightweight embedded supervisor) may have a supplementary monitoring function relative to the operating system BS (especially a lightweight embedded operating system). Figure 5 ), a task PXY of two zones Z1 and Z2 with different trust levels is executed on a dedicated computing core 102 c, wherein preferably in user mode two different static configuration data sets are used for the Z1 task (task or instance assigned to the first zone Z1) and the Z2 task, and optionally a further static configuration data set is used for a supervisory mode, which controls, for example, the switch between the two static configuration data sets for the Z1 task and the Z2 task. In other preferred embodiments, the possibly remaining, unused static configuration data sets for the tasks can be configured in user mode (e.g. during a cold start and / or hot start) so that, for example, the configuration data sets prohibit general read access, write access and execution access to the entire memory, thereby further increasing security.

[0214] In other preferred embodiments, it can be provided that the supervisory mode controls the monitoring of the untrustworthy zone Z1 (especially in the context of intra-core zone separation), see for example Figure 2M process.

[0215] In other preferred embodiments, for example, three or more areas Z1, Z2, Z3 (not shown) may be provided, wherein the first area Z1 is, for example, a highly trusted / intimate area, wherein the second area Z2 is, for example, a trusted area, and wherein the third area Z3 is, for example, an untrustworthy area.

[0216] In other preferred embodiments, the computing device can have, for example, a microcontroller or can be formed by a microcontroller having a corresponding number of computing cores.

[0217] According to the inventors' investigations, in the context of highly networked modern vehicles, the attack surface for computing devices such as control devices and / or embedded systems is greatly increased, especially due to the wide variety of external interfaces. In particular, the risk of so-called remote attacks is given, that is, damage is carried out, for example via the Internet, without physical access to the vehicle or the computing device. The principle according to the preferred embodiment can be advantageously used to effectively mitigate such remote attacks and / or other attacks on the computing device.

[0218] Further preferred embodiments relate to a device 1000 for carrying out the method according to the embodiments, see Fig. 22 The device 1000 has a computing device 1002 with at least one computing core 1002a, wherein optionally at least one memory protection device 1002a' can be assigned to the computing core 1002a.

[0219] The device 1000 further has a storage device 1004, which preferably has a volatile memory 1004a, such as a working memory (RAM), and / or a non-volatile memory 1004b, such as a flash EEPROM and / or a ROM and / or an OTP memory. Preferably, a computer program PRG is stored in the ROM 1004b, which has the following instructions: when the program PRG is executed by the computer 1002, the computer 1002 is prompted to perform the method according to the embodiment.

[0220] In other preferred embodiments, configuration data CFG for operating device 1000 are also stored in ROM 1004b. Configuration data CFG may also include, for example, one or more configuration data sets KD, KD', KD1, KD2, KD3, KD4 for at least one memory protection device 1002a'.

[0221] In further preferred embodiments, it is provided that the device 1000 has at least one data bus 1006 which enables data to be exchanged between the computing device 1002 and the memory device 1004 .

[0222] Further preferred embodiments relate to a computer-readable storage medium SM which comprises instructions, in particular in the form of a computer program PRG, which, when executed by the computer 1002 , cause the computer 1002 to carry out the method according to the described embodiments.

[0223] Further preferred embodiments relate to a data carrier signal DS which transmits a computer program PRG according to the embodiments described. Preferably, the device 1000 can have a preferably bidirectional data interface 1008 for receiving the data carrier signal DS.

[0224] In other preferred embodiments, the computing device 1002 may also have a configuration according to the computing device 100, 100a, as described above by way of example. Figure 1 , 3 In particular, in other preferred embodiments, it is also possible to Fig. 22 The computing core 1002a of the device 1000 or the computing core 1002a at least temporarily executes at least some steps of the method according to the embodiment. In this regard, the device 1000 can also be understood as a possible target system for the computing device 100, 100a according to the embodiment.

[0225] In other preferred embodiments, the device 1000 also has a hardware security module HSM′ or a cryptographic module HSM′, for example for executing cryptographic functions.

[0226] In other preferred embodiments, it is provided that device 1000 is designed as a microcontroller (English: Microcontroller or Microcontroller Unit (MCU), in particular as a single microcontroller (single MCU) or as a single chip system (English: SoC, system-on-chip), in particular as a single SoC (single SoC).

[0227] In other preferred embodiments, it is provided that the device 1000 has a (especially common) semiconductor substrate 1001 (English: die), wherein at least one of the following elements is arranged on the (especially common) semiconductor substrate 1001: a) a computing device 1002 having at least one computing core, b) a memory device 1004, c) a data bus 1006, d) at least one memory protection device 1002a, d) an (optional) hardware security module HSM'.

[0228] Therefore, in the case of simultaneous separation into two or more areas Z1, Z2, it is possible to advantageously provide a single MCU system 1 or a single SoC system 1 according to the principles of the preferred embodiment.

[0229] In other preferred embodiments, data can be exchanged between different areas ("intra-area and / or inter-area data exchange"), for example, via a shared RAM (shared working memory, see Figure 4 The shared RAM is implemented by a buffer in the reference numeral 1030a in the figure, wherein the shared RAM is advantageously also arranged on the same common semiconductor substrate 1001 as the computing device 1002 or its (multiple) computing cores 1002a and preferably with other components 1006, HSM', 1002a of the single SoC system 1. By this, a high-performance (because inside the MCU or inside the SoC) and secure (because inside the MCU or inside the SoC) communication channel between different areas Z1, Z2 is advantageously provided, and according to other preferred embodiments, the communication channel can also be effectively expanded (for example, if necessary, there are multiple buffers in other (additional) areas).

[0230] Advantageously, the preferred implementation enables different zones Z1, Z2 (e.g., a trusted zone (TZ) and an untrusted zone (NTZ)) to be “arranged” on the same, preferably single MCU or SoC system 1 and / or data processing of data from different zones Z1, Z2 to be performed.

[0231] In other preferred embodiments, the method and / or device 100, 100a, 1000 according to the described embodiments can be used in a control device, for example a control device for a motor vehicle, in particular a control device for an internal combustion engine of a motor vehicle, for example for at least one of the following application scenarios: a) controlling the operation or operating state transition of the control device, b) enabling or disabling the control device and / or other components and / or one or more functions of, for example, a motor vehicle, c) switching to a fault mode and / or emergency operation, d) making a fault memory entry, e) signaling the operating state to an external unit and / or a user, f) controlling an actuator.

[0232] Other preferred embodiments relate to the use of methods according to these embodiments and / or devices 100, 100a, 1000 according to these embodiments and / or computer programs PRG according to these embodiments for: in particular, checking changes or manipulations of at least one sub-area of ​​a storage device 1030, 1032, 1004 before, during or after a transition of the storage device and / or a computing device 100, 100a, 1002 accessing the storage device from a first operating state to a second operating state; and controlling the operation of a control device, for example an internal combustion engine of a motor vehicle, based on the checking.

[0233] Other preferred embodiments (see Figure 2U ) relates to the application of the method according to the embodiment and / or the device according to the embodiment and / or the computer program according to the embodiment for at least one of the following elements: a) in a computing device 100, 100a ( Figure 1 ) in the computing device, in particular also providing 370 trust boundaries (“Trust Boundaries”) within the computing core 102 c of the computing device, b) reducing 371 ( Figure 2U ) an attack surface for attacking a computing device and / or one of its components, c) limiting 372 access to memory 1030, 1032, d) limiting 373 access to peripherals 1034 ( Figure 3 ) access rights, e) restrict 374 ( Figure 2U ) access rights to computing resources (which can be characterized, for example, by computing time, description of computing cores), e) minimizing the impact of damaged components 375, f) operating 376 a control device, in particular a control device for a vehicle, in particular a motor vehicle, g) operating 377 an embedded system, in particular an Internet of Things IoT system, h) operating 378 an application-specific integrated circuit ASIC.

Claims

1. A method for operating a computing device (100; 100a; 100b), the computing device (100; 100a; 100b) having at least one computing core (102a, 102b, 102c, ..., 102n; K1, K2, K3, K4), the computing device (100; 100a; 100b) being a computing device for a motor vehicle, wherein the method comprises the following steps: assigning (200) one or more application programs (AP1, AP2) executable by the computing device (100; 100a; 100b) to at least two zones (Z1, a) one of the zones (Z1, Z2) of the computing device (100; 100a; 100b), wherein the zones (Z1, Z2) represent resources of the computing device (100; 100a; 100b), the resources being usable for executing related applications (AP1, AP2); executing (210) at least one of the applications (AP1, AP2) based on the zones (Z1, Z2) allocated to the at least one application; and controlling (230) at least one of the following elements based on the at least one zone (Z1, Z2): a) controlling a memory (1030, 1032) allocated to the computing device (100; 100a; 100b); a) a read permission for a memory (1030, 1032) assigned to the computing device (100; 100a; 100b); c) an execute permission for a memory (1030, 1032) assigned to the computing device (100; 100a; 100b); at least temporarily using (232; 232') 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) to control the read permission and / or the write permission and / or the execute permission; wherein At least one computing core (102a) at least temporarily occupies (240) a first operating mode, wherein the at least one computing core (102a) predetermines and / or writes (242) configuration data (1036) in the first operating mode, wherein the configuration data (1036) controls the operation of at least one memory protection device, wherein the at least one computing core (102a) at least temporarily occupies (243) a second operating mode, wherein the at least one computing core (102a) cannot write and / or change the configuration data (1036) for the at least one memory protection device in the second operating mode.

2. The method according to claim 1, wherein: The computing device (100; 100a; 100b) has multiple computing cores (102a, 102b, 102c, ..., 102n; K1, K2, K3, K4), wherein the method further comprises: a) allocating (220) at least one computing core (102a, 102b) to exactly one area, and / or b) allocating (222) at least one computing core (102a, 102b) to more than one area (Z1, Z2).

3. The method according to claim 1 further comprises: providing (231) at least one dedicated memory protection device (M1) for at least one computing core (102a), wherein dedicated memory protection devices are respectively provided for multiple computing cores (102a).

4. The method according to claim 1 further comprises: providing (250) multiple sets of configuration data (KD) for the 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), wherein at least one first set of the multiple sets of configuration data (KD) is assigned (252) to a first area (Z1) of the at least two areas (Z1, Z2), and at least one second set of the multiple sets of configuration data (KD) is assigned (252) to a second area (Z2) of the at least two areas (Z1, Z2).

5. The method according to claim 1, wherein: The at least one computing core (102a) assumes (240) the first operating mode in response to at least one interrupt request.

6. The method according to any one of the above claims 1-5 further comprises: providing (260) a first instance (AP1_I1) of the application (AP1) and a second instance (AP1_I2) of the application (AP1); allocating (262) the first instance (AP1_I1) of the application (AP1) to a first area (Z1) among the at least two areas; and allocating (263) the second instance (AP1_I2) of the application (AP1) to a second area (Z2) among the at least two areas.

7. The method according to any one of the above claims 1 to 5 further comprises: separating (270) an area of ​​a memory allocated to the computing device (100) according to the at least two areas (Z1, Z2), wherein the memory allocated to the computing device (100) has at least one of the following elements: a) a buffer memory in the form of a working memory, b) a stack memory, c) a data memory, d) a program memory, e) a register memory, wherein 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) is used (272) for the separation (270).

8. The method according to any one of the above claims 1 to 5 further comprises: exchanging (280) first data between different areas (Z1, Z2) via a buffer memory, wherein exchanging the first data between the first area (Z1) and the second area (Z2) comprises the following steps: copying (282) the first data to a first buffer storage area assigned to the first area (Z1); checking (283) the copied first data; and based on the checking (283), copying (284) the first data from the first buffer storage area assigned to the first area (Z1) to a second buffer storage area assigned to the second area (Z2).

9. The method according to any one of the above claims 1-5 further comprises: allocating computing time resources to different applications and / or instances of applications according to the at least two zones (Z1, Z2).

10. The method according to claim 9 further comprises: a) using (292) an operating system (BS) for an embedded system to allocate computing time resources for different applications and / or instances of applications, wherein the operating system (BS) is respectively assigned to the computing cores (102a, 102b) of the computing device (100); and / or b) using (294) a supervisor (SV) for an embedded system to allocate computing time resources for different applications and / or instances of applications, wherein the supervisor (SV) is respectively assigned to the computing cores (102a, 102b) of the computing device (100).

11. The method according to claim 10, wherein: In case of using a static task list, the operating system (BS) and / or the supervisor (SV) performs allocation of computing time resources for predefined tasks.

12. The method according to claim 10, wherein: Based on a) repeated interrupt requests and / or b) event-controlled interrupt requests, the operating system (BS) and / or the supervisor (SV) performs an allocation of computing time resources, wherein tasks are activated based on at least one interrupt routine.

13. The method according to any one of claims 1 to 5, wherein: Upon entry into the interrupt routine, configuration data of the at least one memory protection device is changed (1036).

14. The method according to claim 10 further comprises: monitoring (300) with the aid of the operating system (BS) and / or the supervisor (SV) for potential damage at least one of the following elements: a) a first zone (Z1), b) an application assigned to the first zone (Z1), c) an instance (AP1_I1) of an application (AP1) assigned to the first zone (Z1), wherein the monitoring (300) comprises: A stack memory is evaluated (302) and / or a program counter is evaluated (304), wherein the stack memory is evaluated (302) and / or the program counter is evaluated (304) before activating the application (AP1) and / or the instance (AP1_I1) of the application (AP1).

15. The method according to claim 14 further comprises: when the monitoring (300) is able to infer potential damage, then starting (305) a fault reaction, wherein the fault reaction (305) has at least one of the following elements: a) by deactivating (305a) the computing cores assigned to the first area (Z1) and / or resetting (305b) the computing cores assigned to the first area (Z1) and / or placing (305c) the computing cores assigned to the first area (Z1) in a safe state, b) generating (305d) a fault entry (FE) and / or c) forwarding (305e) the fault entry or the fault entry to an attack identification system.

16. The method according to any one of claims 1 to 5, wherein: The computing device (100) at least temporarily performs a cold boot (310), wherein during the cold boot (310), data and / or program code are loaded from a non-volatile memory (1032), or wherein the computing device (100) at least temporarily performs a hot boot (312), wherein during the hot boot (312), data and / or program code are loaded from a volatile memory (1030) that is at least temporarily powered on, wherein during the cold boot (310), The 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) is configured (311), or wherein during the warm start (312), the 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) is configured (313).

17. The method according to any one of claims 3 to 5, wherein: A dedicated memory protection device (M1) is only assigned (231a) to that computing core (102a) for which the dedicated memory protection device (M1) is already provided (231).

18. The method according to any one of the preceding claims 1 to 5 further comprises: testing (320) the integrity and / or authenticity of configuration data (1036) or testing (320) the configuration data (1036), the configuration data (1036) controlling the operation of at least one memory protection device, the testing (320) being performed with the aid of at least one of the following elements: a) verifying (322) a program code that can be used to configure the at least one memory protection device, b) verifying (324) the configuration data (1036), c) making the program code that can be used to configure the at least one memory protection device or the program code persistent (326), d) making the configuration data (1036) persistent (328).

19. The method according to any of the preceding claims 1 to 5 further comprises: at least temporarily executing (330) a secure boot method and / or at least temporarily executing (332) a method for manipulation identification during runtime by at least one computing core (102a).

20. The method according to any one of the above claims 1-5 further comprises: controlling (340) the access of the application (AP1) to at least one of the following elements according to at least one zone (Z1): a) an internal interface of the computing device (100), b) an internal and / or external hardware interface of the computing device (100), c) a hardware security module (HSM) and / or a cryptographic module for performing cryptographic functions, d) a peripheral device of the computing device (100) or a special function register of at least one peripheral device, e) an internal interface of a target system of the computing device (100) or an internal interface of a control device, f) an external interface of a target system of the computing device (100) or an external interface of a control device, g) an addressing element on at least one layer of the ISO / OSI layer model.

21. The method according to any one of the above claims 1-5 further comprises at least one of the following elements: a) introducing (350) at least one additional area that no longer exists, b) moving (352) functions from a first computing core (102a) to at least one other computing core (102b) of the computing device, c) performing (354) communication between at least two areas (Z1, Z2) using a working memory (1030) integrated into the computing device (100), d) defining (360) the trusted area (Z2) by at least one application assigned to at least one trusted area (Z2), and optionally monitoring (362) at least one other untrusted area (Z1).

22. A device (100; 100a; 100b; 1000) for performing the method according to any one of the preceding claims 1-21.

23. The device (100; 100a; 100b; 1000) according to claim 22, comprising at least one of the following elements: a) a computing device (1002) having at least one computing core (1002a), b) a storage device (1004), c) a data bus (1006), d) a memory protection device (1002a'), d) a hardware security module (HSM; HSM').

24. The device (100; 100a; 100b; 1000) according to any one of claims 22 to 23, wherein: The device (100; 100a; 100b; 1000) is designed as a microcontroller or a system on a chip (1).

25. The device (100; 100a; 100b; 1000) according to claim 23, wherein The device (100; 100a; 100b; 1000) has a common semiconductor substrate (1001), wherein at least one of the following elements is arranged on the common semiconductor substrate (1001): a) a computing device (1002) having at least one computing core (1002a), b) a storage device (1004), c) a data bus (1006), d) a memory protection device (1002a'), d) a hardware security module (HSM; HSM').

26. A microcontroller system (1) or a single-chip system (1) for executing the method according to any one of claims 1 to 21, wherein: The system (1) comprises a device (1000) according to any one of claims 22 to 25.

27. A computer-readable storage medium (SM) comprising instructions (PRG) which, when executed by a computer (1002a), cause the computer (1002a) to perform the method according to any one of claims 1 to 21.

28. A method according to any one of claims 1 to 21 and / or an apparatus (100; 100a; 100b; 1000) according to any one of claims 22 to 25 and / or a system (1) according to claim 26 and / or a computer-readable storage medium (SM) according to claim 27 for application to at least one of the following elements: a) providing (370) a trust boundary in a computing device (100) or within a computing core (102a) of the computing device (100), b) reducing (371) the number of devices used to attack the computing device (100); c) limiting (372) access rights to memory, d) limiting (373) access rights to peripherals, e) limiting (374) access rights to computing resources, e) minimizing the impact of damaged components (375), f) operating (376) a control device for a motor vehicle, g) operating (377) an embedded system or an Internet of Things (IoT) system, h) operating (378) an application-specific integrated circuit (ASIC), i) detecting a damaged area, and j) initiating a fault response in the event of detected damage.

Images