System and method for enhancing security of system-on-chip

Abstract

To provide a method for enhancing the security of a system-on-chip.SOLUTION: Example embodiments of the present disclosure provide enhancement on the security of a system-on-chip (SoC). According to embodiments, the method for enhancing the security of the SoC is provided. The method is performed by at least one microcontroller unit (MCU) implemented in the SoC and includes: accessing a storage component that stores a plurality of configuration files; selecting at least one configuration file from among the plurality of configuration files; moving at least one configuration file into a portion of a memory component; and marking the portion of the memory component as non-accessible by other components.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] FIELD Exemplary embodiments of the present disclosure relate to systems on chips (SoCs), and more particularly to enhancing the security of one or more configuration files associated with one or more components within an SoC. [Background technology]

[0002] A system-on-chip (SoC) is an integrated circuit that integrates multiple system components onto a single chip. An SoC typically includes the hardware and software necessary to control the operation and functionality of the hardware. The hardware of an SoC may include a processing system (consisting of a microcontroller unit (MCU) and multiple processor cores, such as a real-time core (R-core) and an application core (A-core)) and a storage system. The software of an SoC, on the other hand, may include one or more operating systems (OS) stored in the storage system and loaded by the processing system during operation.

[0003] Generally, when an SoC is powered on or reset, some of the components of the SoC may boot before the SoC is fully functional. For example, the MCU and R-core may boot simultaneously, followed by the A-core. An exemplary boot process for an SoC is as follows: the MCU and R-core (or their associated operating systems) may boot simultaneously, followed by loading a trusted execution environment (TEE) on the A-core, loading a hypervisor associated with the A-core, and loading an operating system associated with the A-core. In this regard, the TEE may host and control configuration files or parameters associated with the A-core in a secure manner. For example, the operating system of the A-core may load off one or more specific configurations and store them in the TEE. In this way, the configuration files or parameters associated with the A-core may be guaranteed to be tamper-proof by an attacker at runtime because they are not present in normal memory at runtime.

[0004] Meanwhile, the configuration of the MCU and R-core is loaded from one or more configuration files that are pre-stored in a storage system during boot of the MCU and R-core, and stored in a memory component (e.g., flash memory) at runtime. The one or more configuration files can define various system settings closely related to the security of the SoC, such as firewall settings for the SoC. For example, assuming the SoC is implemented in a vehicle, the one or more configuration files can define where Controller Area Network (CAN) messages can be sent within the vehicle and to which entities they can be sent.

[0005] Therefore, in view of the above, the SoC includes various safety-related components (e.g., MCU, R-core, etc.) that need to be booted before loading the TEE. Nevertheless, as will be explained below, the SoC in the related art is at risk of being attacked due to the lack of a mechanism for protecting the configuration files of the safety-related components during runtime. Furthermore, the SoC in the related art also lacks a mechanism for verifying or detecting changes to the configuration files, as well as for efficiently restoring or recovering the configuration files when necessary.

[0006] Specifically, because safety-related components (e.g., MCU, R-core, etc.) boot before the A-core loads, the A-core is not yet loaded and the TEE is not yet loaded into the A-core, so the TEE is not available to source or store associated configuration files. Furthermore, because the configuration files are typically stored in unprotected memory components during runtime, the configuration files may be vulnerable to attackers. Specifically, because there is a time difference between the boot time of the safety-related components (e.g., MCU, R-core, etc.) and the boot time of the A-core, the time difference (even a few seconds) between the boot times may allow an attacker to access and modify associated configuration files before the A-core boots and the TEE loads. Similarly, an attacker may also modify configuration files during runtime (e.g., when the MCU and / or R-core are functioning).

[0007] Furthermore, prior art SoCs are unable to detect or verify changes to configuration files of safety-related components (e.g., MCUs, R-cores, etc.). As a result, prior art SoCs are unable to quickly identify modifications to configuration files and are unable to detect or respond to attacks in a timely manner. Related art SoCs also lack a mechanism for automatically restoring configuration files when necessary. Summary of the Invention

[0008] Exemplary embodiments consistent with this disclosure effectively and efficiently provide enhanced security for an SoC.

[0009] According to an example embodiment, a method for enhancing security of an SoC is provided, the method being executable by at least one microcontroller unit (MCU) implemented within the SoC and including accessing a storage component that stores a plurality of configuration files, selecting at least one configuration file from the plurality of configuration files, moving the at least one configuration file to a portion of a memory component, and marking the portion of the memory component as inaccessible by other components.

[0010] According to an example embodiment, an SoC is provided. The SoC may include a memory component that stores computer-readable instructions and an MCU communicatively coupled to the memory component. The MCU may be configured to execute instructions to access a storage component that stores a plurality of configuration files, select at least one configuration file from the plurality of configuration files, move the at least one configuration file to a portion of the memory component, and mark the portion of the memory component as inaccessible by other components.

[0011] According to an embodiment, a non-transitory computer-readable recording medium may have stored thereon instructions executable by at least one MCU implemented in a SoC to cause the MCU to perform a method for enhancing security of the SoC, the method including accessing a storage component that stores a plurality of configuration files, selecting at least one configuration file from the plurality of configuration files, moving the at least one configuration file to a portion of a memory component, and marking the portion of the memory component as inaccessible by other components.

[0012] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be realized by practice of the presented embodiments of the present disclosure.

[0013] The features, advantages, and significance of exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals indicate like elements. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates a block diagram of exemplary components of a system-on-chip (SoC) in accordance with one or more exemplary embodiments. [Figure 2] FIG. 2 illustrates a block diagram of an example communications arrangement for enhancing security of an MCU's configuration files, according to one or more example embodiments. [Figure 3] FIG. 3 illustrates a flow diagram of an example method for enhancing security of a configuration file of an MCU, according to one or more example embodiments. [Figure 4] FIG. 4 illustrates a block diagram of an example communication configuration for enhancing security of R Core's configuration files, according to one or more example embodiments. [Figure 5]FIG. 5 illustrates a block diagram of an exemplary communications arrangement for managing configuration files, according to one or more exemplary embodiments. [Figure 6] FIG. 6 illustrates a flow diagram of an example method for managing configuration files, according to one or more example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] The following detailed description of exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Moreover, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and operational descriptions provided below, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed concurrently (at least in part), and the order of one or more operations may be switched.

[0016] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible embodiments includes each dependent claim in combination with every other claim in the claim set.

[0017] No element, act, or instruction used herein should be construed as critical or required unless explicitly stated as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified. Furthermore, phrases such as "[A] and / or [B]," "at least one of [A] and [B]," or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0018] Throughout this specification, references to "one embodiment," "an embodiment," "a non-limiting exemplary embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Thus, throughout this specification, "in one embodiment," "in an embodiment," "in a non-limiting exemplary embodiment," and similar language may, but do not necessarily, all refer to the same embodiment.

[0019] Furthermore, the described characteristics, advantages, and properties of the present disclosure can be combined in any suitable manner in one or more exemplary embodiments. In light of the description herein, those skilled in the art will recognize that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0020] Furthermore, the term "vehicle" as used herein refers to any suitable type of vehicle in which exemplary embodiments of the present disclosure may be implemented. For example, a "vehicle" may refer to a motorized vehicle, such as a car, truck, bus, motorcycle, or any other suitable type of motor vehicle powered by an engine, motor, or other mechanical means. Alternatively, or additionally, a "vehicle" as used herein may refer to a bicycle, skateboard, and any other suitable type of non-motorized vehicle without departing from the scope of the present disclosure.

[0021] Exemplary embodiments of the present disclosure provide methods, systems, and devices for enhancing the security of a system-on-chip (SoC). Specifically, the exemplary embodiments of the present disclosure securely manage configuration files of one or more safety-related components, such as microcontroller units (MCUs) and real-time cores (R-cores), across different stages or processes of the SoC, thereby reducing the risk of the configuration files being leaked or tampered with. Furthermore, the exemplary embodiments of the present disclosure detect and verify changes to the configuration files and restore the configuration files in a timely manner, as needed. Ultimately, the exemplary embodiments of the present disclosure effectively and efficiently enhance the security of the components of the SoC.

[0022] It is contemplated that the features, advantages, and significance of the exemplary embodiments described herein are only a portion of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configurations, operations, and implementations of the exemplary embodiments of the present disclosure are provided below.

[0023] FIG. 1 illustrates a block diagram of exemplary components of a system-on-chip (SoC) 100 in accordance with one or more exemplary embodiments. As illustrated in FIG. 1, the SoC 100 may include at least one bus 111, at least one processing system 112, multiple memory components 113, at least one input / output memory management unit (IOMMU) 114, at least one storage component 115, and multiple peripherals 116. One or more of the components 111-116 may be implemented in hardware, firmware, or a combination of hardware and software. The components of the SoC 100 are simplified for illustrative purposes, and it is contemplated that the SoC 100 may include additional components and / or be configured differently depending on the implementation without departing from the scope of the present disclosure. For example, in some implementations, the storage component 115 may be implemented as part of the memory system 113, the processing system 112 may include multiple R cores and multiple A cores, etc.

[0024] At least one bus 111 may be configured to facilitate or enable communication between components of SoC 100. Specifically, bus 111 may communicatively couple the components to one another and provide a means for data transfer and the flow of control signals between the components. Bus 111 may include various types of communication buses, such as an address bus, a data bus, a control bus, a memory bus, a peripheral bus, and any other suitable type of bus implemented within SoC 100 that can enable communication and cooperation between components within SoC 100. Furthermore, bus 111 may include a parallel bus that facilitates parallel communication or data access between components of SoC 100, a serial bus that facilitates serial communication or data access between components of SoC 100, or a combination thereof. Furthermore, bus width of bus 111 may be 8 bits, 16 bits, 32 bits, 128 bits, or a higher bus width.

[0025] The processing system 112 may be programmed or configurable to perform one or more operations described herein. As shown in FIG. 1 , the processing system 112 may include at least one real-time core (R core) 112-1, at least one application core (A core) 112-2, at least one secure processing unit (SPU) 112-3, and at least one microcontroller unit (MCU) 112-4. It is contemplated that the processing system 112 may include more or fewer components and / or be configured differently without departing from the scope of the present disclosure. For example, the SPU 112-3 and the MCU 112-4 may be implemented separately from the processing system 112, which may further include a microprocessor, a digital signal processor (DSP), etc.

[0026] According to an exemplary embodiment, the R-core 112-1 and the A-core 112-2 may comprise a central processing unit (CPU). The R-core 112-1 may be configured to perform real-time operations and manage tasks with real-time requirements, such as monitoring and controlling safety-related functions and performing automotive-related operations. Conversely, the A-core 112-2 may be configured to perform performance-intensive and non-real-time operations (i.e., operations that do not have strict timing requirements) and manage a wide range of application software for various tasks, such as general-purpose computing, multimedia processing, networking, and operation system support. The R-core 112-1 and the A-core 112-2 may be configured to interoperate with each other to achieve a balance between real-time responsiveness and application flexibility.

[0027] SPU 112-3 may include one or more processing units dedicated to processing or executing security-related operations within SoC 100. According to example embodiments, SPU 112-3 may be configured to provide hardware-based security functions such as cryptographic operations, provide secure storage, secure memory creation, secure communications, secure processing, etc. As described further below, in some example embodiments, SPU 112-3 may be communicatively coupled to a safety island (SAIL) on R-core 112-1 (via bus 111), and control of SPU 112-3 may be mapped to or provided by the SAIL of R-core 112-1.

[0028] MCU 112-4 may include one or more processing units dedicated to processing or executing low power operations, such as controlling electronic control components (ECUs) within a vehicle system, embedded control components such as sensor monitoring, etc. According to an example embodiment, MCU 112-4 may include one or more integrated circuits including its own CPU, memory components, peripherals, etc.

[0029] Memory component 113 may include one or more media for storing temporary data, runtime variables, a boot loader, computer-readable or program instructions, caches, and buffers necessary for operation of SoC 100. As shown in FIG. 1, memory component 113 may include at least one non-volatile memory 113-1 and at least one volatile memory 113-2.

[0030] Non-volatile memory 113-1 refers to a memory storage medium that maintains the contents stored therein when power is lost. Non-volatile memory 113-1 may be configured to store boot code or computer-readable instructions for booting components of SoC 100 (e.g., R-core 112-1, A-core 112-2, MCU 112-4, etc.). In some embodiments, non-volatile memory 113-1 may be configured to store configuration files associated with SoC 100. According to an example embodiment, non-volatile memory 113-1 may include one or more of flash memory, read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electric EPROM (EEPROM), ferroelectric RAM (FRAM), magnetoresistive RAM (MRAM), phase-change RAM (PRAM), resistive RAM (ReRAM), ferroelectric field-effect transistor memory (FeFET), and any other suitable type of non-volatile memory.

[0031] Volatile memory 113-2 refers to a memory storage medium that resets or erases the contents stored therein when power is lost. Volatile memory may be configured to store temporary data or information. According to an embodiment, volatile memory 113-2 may include one or more of static random access memory (RAM), synchronous RAM (SSRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate RAM (DDR RAM), synchronous dual data rate SDRAM (DDR SDRAM), graphical DDR SDRAM (GDDR SDRAM), low power DDR SDRAM (LDDR SDRAM), quad data rate SDRAM (QDR SDRAM), and any other suitable type of volatile memory.

[0032] IOMMU 114 may include one or more components configured to manage memory access between components of SoC 100 (e.g., processing system 112, etc.) and memory component 113. According to an example embodiment, IOMMU 114 may be configured to receive virtual / logical addresses from processing system 112 and then convert or translate the virtual / logical addresses to physical addresses (e.g., by utilizing an internal address table) for use by other components of SoC 100. Additionally, IOMMU 114 may be configured to provide virtual memory, for example, by delivering more logical address space than physically available memory space.

[0033] According to an example embodiment, IOMMU 114 may be configured to provide protection for different memory regions, for example, by marking particular portions of memory component 113 as accessible / inaccessible by particular components. As described further below, IOMMU 114 may be communicatively coupled to MCU 112-4 (via bus 111) and may receive instructions from MCU 112-4 to mark particular portions of memory component 113 as inaccessible and / or accessible by other components of SoC 100 and other external components.

[0034] Storage component 115 may include one or more storage media configured to store non-volatile data, such as an operating system (OS), firmware, configuration settings, calibration data, information, and / or software related to the operation and use of SoC 100. According to an example embodiment, storage component 115 may include one or more storage media embedded in SoC 100, such as embedded flash memory, embedded multimedia card (eMMC), etc. Additionally or alternatively, storage component 115 may include one or more external storage media communicatively coupled to SoC 100, such as a removable Secure Digital (SD) card, a removable MMC, etc. It is contemplated that storage component 115 may include any other suitable type of non-transitory computer-readable medium without departing from the scope of the present disclosure.

[0035] According to an exemplary embodiment, storage component 115 may be configured to store computer-readable or computer-executable instructions for implementing one or more operations described herein, one or more configuration files associated with one or more components of SoC100, historical information of one or more operations performed by SoC100 (or one or more components thereof), and the like.

[0036] Peripherals 116 may include one or more components that interoperate with other components of SoC 100 to increase the efficiency and effectiveness of SoC 100. According to an example embodiment, peripherals 116 may include one or more communication interfaces, such as transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter), that enable SoC 100 (or components thereof) to communicate with one or more external components, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, the peripherals 116 may include one or more of a Universal Asynchronous Receiver / Transmitter (UART), a Controller Area Network (CAN) bus interface, an Ethernet interface, a Serial Peripheral Interface (SPI), an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a High-Definition Multimedia Interface (HDMI), a Wi-Fi interface, a cellular network interface, one or more application programming interfaces (APIs), and the like.

[0037] According to an exemplary embodiment, peripherals 116 may include pulse width modulators (PWMs), analog-to-digital converters (ADCs), digital-to-analog converters (DACs), timers / counters, inter-integrated circuits (I2Cs), general-purpose input / outputs (GIPOs), fixed analog components, programmable analog components, fixed digital components, programmable digital components, and the like.

[0038] Safety-related components of SoC 100 (e.g., MCU 112-4, R-core 112-1, etc.) may be configured to interoperate with other components of SoC 100 (e.g., SPU 112-3, A-core 112-2, IOMMU 114, etc.), thereby enhancing the security of SoC 100. Example embodiments relating thereto are further described below with reference to FIGS.

[0039] 2 is a block diagram of an example communication configuration for enhancing security of an MCU's configuration file, according to one or more example embodiments. In this example, MCUs 112-4, memory component 113, IOMMU 114, and storage component 115 in SoC 100 of FIG. 1 are involved, and communication therebetween may be performed via bus 111 of SoC 100. It may be understood that more or fewer components of SoC 100 may be involved without departing from the scope of the present disclosure.

[0040] 2, storage component 115 may be configured to store one or more configuration files 210 and one or more operating system (OS) files 220. One or more configuration files 210 may include configuration information (e.g., OS configuration, firewall configuration, peripheral configuration, power management configuration, system configuration, communication protocol configuration, etc.) associated with one or more components of SoC 100, such as configuration files associated with MCU 112-4, R-core 112-1, A-core 112-2, etc.

[0041] Additionally, the one or more OS files 220 may include programming code or image files of one or more OSs associated with one or more components of SoC 100, such as an OS associated with MCU 112-4, an OS associated with R-core 112-1, an OS associated with A-core 112-2, etc. According to an example embodiment, the OSs associated with MCU 112-4 and R-core 112-1 may include one or more real-time OSs (RTOSs), and the OS associated with A-core 112-2 may include one or more rich OSs and / or one or more general-purpose OSs.

[0042] For purposes of explanation only, it may be assumed that the OS file in Figure 2 is associated with the OS of MCU 112-4 and the configuration file in Figure 2 is associated with the OS of MCU 112-4. In this regard, the configuration file may include information associated with the OS configuration, such as OS kernel settings, initial RAM disk (initrd) settings, device tree blob (DTB) settings, boot loader settings, etc.

[0043] 2, memory component 113 may include a first portion 230 and a second portion 240. Note that a "portion" may refer to non-volatile memory 113-1 or volatile memory 113-2, or to a partition of non-volatile memory 113-1 or a partition of volatile memory 113-2. Furthermore, it is contemplated that memory component 113 may include more than two portions without departing from the scope of the present disclosure.

[0044] The following describes example operations that MCU 112-4 can perform in the example configuration of Figure 2. Figure 3 illustrates a flow diagram of an example method 300 for enhancing security of an MCU's configuration files, according to one or more example embodiments. One or more operations of method 300 may be performed by MCU 112-4 during the boot process of MCU 112-4. For example, one or more operations may be performed by a boot loader of MCU 112-4 when executing boot firmware stored in boot ROM (in memory component 113).

[0045] 3, at operation S310, MCU 112-4 may be configured to access a storage component that stores multiple configuration files. For example, in the example of FIG. 2, MCU 112-4 may access (via bus 111) storage component 115 that stores multiple configuration files 210.

[0046] Subsequently, in operation S320, the MCU 112-4 may be configured to select at least one configuration file from among the plurality of configuration files, for example, the MCU 112-4 may determine configuration files associated with the MCU 112-4 and select from among the configuration files a configuration file associated with the OS of the MCU 112-4.

[0047] Next, in operation S330, MCU 112-4 may be configured to move the selected configuration file from the storage component to a portion of the memory component. For example, in the example of FIG. 2, MCU 112-4 may move configuration file 210 to first portion 230 (or second portion 240) of memory component 113.

[0048] Thus, in operation S340, MCU 112-4 may be configured to mark a portion of the memory component (where the configuration file is temporarily stored) as inaccessible by other components of the SoC and / or one or more external components. For example, the marked portion of the memory component cannot be accessed by a component running the OS, an unauthorized component outside the SoC, or an unauthorized component. In some implementations, instead of marking a portion of the memory component as inaccessible, MCU 112-4 may mark a portion of the memory component as unwritable.

[0049] According to an exemplary embodiment, MCU 112-4 may employ memory protection mechanisms, such as assigning specific memory attributes and access permissions to portions of memory components, managing or enforcing access control policies, managing or enforcing access control lists (ACLs) or access permission tables, etc., to mark portions of memory components as accessible or inaccessible.

[0050] According to an example embodiment, MCU 112-4 may be configured to interact with IOMMU 114 to mark portions of memory component 113 as inaccessible. In this case, in operation S340, MCU 112-4 may generate instructions to mark portions of the memory component as inaccessible and provide the instructions to IOMMU 114. Accordingly, IOMMU 114 may be configured to mark portions of the memory component as inaccessible.

[0051] Upon marking the memory as inaccessible, the MCU 112-4 may be configured to prepare and launch one or more OSs. For example, the MCU 112-4 may access the marked portion of the memory component to read at least one configuration file and then initialize an environment (e.g., a software environment, a hardware environment, etc.) for loading the OS associated with the at least one configuration file. Thus, the MCU 112-4 may load the OS in the initialized environment and then launch the OS therein. The OS may include an RTOS, a rich OS, and any other suitable type of OS.

[0052] Furthermore, after marking a portion of memory as inaccessible, the MCU 112-4 may initiate loading of a trusted execution environment (TEE) into an A core (e.g., A core 112-2). For example, the MCU 112-4 may send at least one signal or message to the A core, thereby triggering the A core to load the TEE into the A core. As another example, the MCU 112-4 may write a status flag or variable to the memory component 113 and / or the storage component 115, thereby allowing the A core to periodically (or continuously) check the memory component 113 and / or the storage component 115 to determine the status of the MCU 112-4 and load the TEE based thereon. Furthermore, the MCU 112-4 may send at least one signal or message to a power management unit (PMU), such that the PMU can subsequently provide power to wake up the A core.

[0053] Additionally, the MCU 112-4 may remove or retrieve configuration files from portions of the memory component during a shutdown process of the SoC. Specifically, upon marking a portion of the memory component as inaccessible (or unwriteable), the MCU 112-4 may continuously (or periodically) determine whether the SoC is undergoing a shutdown process. In this regard, based on determining that the SoC is undergoing a shutdown process, the MCU 112-4 may remove at least one configuration file from a portion of the memory component and then mark the portion of the memory component as accessible by other components of the SoC in a manner similar to how the MCU 112-4 marked the portion as inaccessible. For example, the MCU 112-4 may generate instructions to mark a portion of a memory component as accessible and then provide the instructions to the IOMMU 114 so that the IOMMU 114 can be configured to mark the portion of the memory component as accessible.

[0054] In view of the above, exemplary embodiments of the present disclosure provide a system and mechanism for reserving and marking a portion of a memory component as inaccessible / unwritable after boot. In this manner, configuration files can be stored in the secured memory portion during runtime of the MCU 112-4 and retrieved from the memory portion during shutdown processing. This effectively and efficiently prevents runtime leakage and tampering of configuration files.

[0055] Next, exemplary embodiments related to the R-core will be described. FIG. 4 illustrates a block diagram of an exemplary communication configuration for enhancing security of an R-core configuration file, according to one or more exemplary embodiments. In this example, the R-core 112-1, SPU 112-3, memory component 113, IOMMU 114, and storage component 115 in the SoC 100 of FIG. 1 are involved, and communication therebetween may be performed via the bus 111 of the SoC 100. It may be understood that more or fewer components of the SoC 100 may be involved without departing from the scope of the present disclosure.

[0056] Some of the configuration in Figure 4 may be similar to the configuration in Figure 2. For example, storage component 115 may store therein one or more configuration files 210 and one or more OS files 220, memory component 113 may include first portion 230 and second portion 240, etc. The configuration differs in that operations involving configuration files are performed by SPU 112-3 instead of R-core 112-1, whereas operations involving configuration files are performed by MCU 112-4 in Figure 2.

[0057] Specifically, the operation of SPU 112-3 may be controlled or mapped by a safety island on R-core 112-1 (SAIL) 410, and configuration files associated with R-core 112-1 may be managed by SPU 112-3 under the control of SAIL 410. For example, during the boot process of R-core 112-1, SAIL 410 may generate and provide signals or messages instructing SPU 112-3 to access storage component 115, select at least one configuration file from storage component 115, move the selected configuration file to a portion of memory component 113, mark the portion of memory component 113 as inaccessible and accessible, and begin loading the TEE of the A-core, in a manner similar to that described above with reference to FIGS.

[0058] In view of the above, any operation or action that needs to be performed involving the configuration file of R-core 112-1 is performed only on SPU 112-3, and the configuration file is not exposed (e.g., in plain text) on R-core 112-1. Thus, the risk of the configuration file being leaked or tampered with can be further reduced.

[0059] Exemplary embodiments relating to configuration file verification and detection, and configuration file recovery will now be described with reference to FIGS.

[0060] 5 illustrates a block diagram of an exemplary communication configuration for managing configuration files according to one or more exemplary embodiments. This example involves the R-core 112-1, A-core 112-2, SPU 112-3, and MCU 112-4 of the SoC 100 of FIG. 1, with communication therebetween occurring via the bus 111 of the SoC 100. It may be understood that more or fewer components of the SoC 100 may be involved without departing from the scope of the present disclosure.

[0061] 5. In addition to the components of SoC 100, at least one cloud server 520 may also be included in the example of FIG. 5. Cloud server 520 may be associated with a service center responsible for handling error codes provided by the components of the SoC. Communication between cloud server 520 and the components of SoC 100 (e.g., A-core 112-2, SPU 112-3, MCU 112-4, etc.) may be performed via peripherals 116 of SoC 100.

[0062] As shown in FIG. 5, the A-core 112-2 may include or implement a trusted execution environment (TEE) 510. The TEE 510 may include a secure, isolated execution environment capable of securely performing one or more specific operations, such as secure data processing, configuration file management, and booting a trusted OS. According to an example embodiment, the TEE 510 may be implemented as a hardware-isolated execution environment within the A-core 112-2 that provides access control between content or runtime within the TEE 510 and components external to the TEE 510.

[0063] Loading of the TEE 510 may be initiated automatically when the A core 112-2 is initially powered up (i.e., when the A core 112-2 is powered up by a PMU or the like), or the A core 112-2 may load the TEE 510 upon receiving a signal or message from the R core 112-1 and / or the MCU 112-4 indicating completion of booting of the R core 112-1 and / or the MCU 112-4. Additionally, the A core 112-2 may periodically (or continuously) check one or more storage media (e.g., part of the memory component 113, the storage component 115, etc.) for information related to the status (e.g., status flags, etc.) of the R core 112-1 and / or the MCU 112-4, and then load the TEE 510 upon determining completion of booting of the R core 112-1 and / or the MCU 112-4.

[0064] According to an example embodiment, the TEE 510 may be configured to store multiple hashes, each associated with a corresponding configuration file. In this regard, a hash may include a fixed-size string of bytes (e.g., hexadecimal digits, a unique string of characters, etc.) generated based on the contents of the associated configuration file. Any change to a configuration file results in a change to the associated hash whenever a component of the SoC 100 (e.g., MCU 112-4, R-Core 112-1, etc.) updates or changes the associated configuration file, and therefore the associated hash in the TEE 510 is also updated. Accordingly, the hashes of the configuration files may be utilized to manage (e.g., verify and restore) the configuration files of the components of the SoC (e.g., R-Core 112-1, MCU 112-4, etc.). Example operations related thereto are described below with reference to FIG. 6.

[0065] 6 illustrates a flow diagram of an example method 600 for managing configuration files, according to one or more example embodiments. One or more operations of method 600 may be performed or implemented by a TEE of an A-core. According to an example embodiment, method 600 may be initiated by the TEE during the boot process of an OS (e.g., a secure OS, a rich OS, etc.) within the TEE.

[0066] 6, at operation S610, the TEE may be configured to obtain at least one hash from a component of the SoC. For example, in the example of FIG. 5, the TEE 510 may obtain hashes from the R-core 112-1 and the MCU 112-4. In this regard, the TEE 510 may communicate with the MCU 112-4 via the bus 111 of the SoC 100 and establish a secure connection to the MCU 112-4 to obtain the hash therefrom. Meanwhile, the TEE 510 may communicate with the SAIL 410 of the R-core 112-1 (via the SPU 112-3) and request the SAIL 410 to provide the hash (e.g., via a certificate), and the SPU 112-3 may accordingly return the requested hash to the TEE 510.

[0067] Upon obtaining the hash, method 600 proceeds to operation S620, where the TEE 510 may be configured to compare the obtained hash with associated hashes stored within the TEE 510. Accordingly, at operation S630, the TEE 510 may determine whether there is a mismatch between the hashes. In this regard, based on a determination that there is a mismatch between the hashes, method 600 proceeds to operation S640, where the TEE 510 may be configured to perform one or more operations to manage associated configuration files. If not, method 600 may be stopped or terminated, or may return to operation S610 such that the TEE 510 may perform method 600 repeatedly over at least some period of time.

[0068] According to an example embodiment, in operation S640, the TEE 510 may limit the functionality available to the component associated with the hash and then provide a message to the component notifying it that it is operating in an error state. Accordingly, the TEE 510 may perform one or more operations to recover the associated configuration file. An example use case related thereto is described below with reference to FIG. 5.

[0069] In the example of FIG. 5, the TEE 510 can detect a mismatch between the hashes of the R-core 112-1 and the MCU 112-4 and then limit the functionality available to the R-core 112-1 and the MCU 112-4 while notifying them that they are operating in an error state.

[0070] Upon receiving notification from the TEE 510, the R core 112-1 and the MCU 112-4 may perform one or more actions to self-diagnose and restart, if applicable. In this regard, the TEE 510 does not automatically reset the configuration file. Rather, the R core 112-1 and the MCU 112-4 request a copy of an uncorrupted configuration file, if applicable. Specifically, upon performing the self-diagnosis, the R core 112-1 and the MCU 112-4 may provide the TEE 510 with an error code and a request for an uncorrupted configuration file, thereby notifying the TEE 510 that the R core 112-1 and the MCU 112-4 have self-detected that they are in a vulnerable state and have requested an uncorrupted configuration file.

[0071] Accordingly, the TEE 510 may transmit the error code to the cloud server 520, for example, via a data communications module (DCM). The DCM may be integrated into the SoC or may be an external, off-chip component communicatively coupled to the SoC. The cloud server 520 may then provide a response (e.g., an acknowledgement message, etc.) to the TEE 510, notifying the TEE 510 that the error code was securely received. In this regard, if the TEE 510 receives a response from the cloud server 520, the TEE 510 may provide a complete, uncorrupted configuration file to the R-core 112-1 and the MCU 112-4. Alternatively, if the TEE 510 does not receive a response from the cloud server 520, the TEE 510 may provide a constrained secure configuration file with limited options (e.g., a bare minimum configuration, etc.) such that only the minimum or essential functionality required for the SoC to operate in a secure manner is provided to the R-core 112-1 and the MCU 112-4.

[0072] Considering the above, the TEE 510 only provides an uncorrupted configuration during verification, thereby preventing an attacker or other erroneous configuration from obtaining an uncorrupted file, and effectively reducing the impact of its actions on related components (e.g., MCU 112-4, R-core 112-1, etc.).

[0073] To this end, exemplary embodiments of the present disclosure effectively and efficiently improve the security of an SoC. Specifically, compared to prior art SoCs that simply load and store a component's configuration file in unprotected memory during runtime, exemplary embodiments of the present disclosure move the configuration file to a portion of memory during the boot process and then mark that portion as inaccessible or addressable (e.g., by the running OS, by unauthorized components, etc.) to protect the configuration file during runtime. Furthermore, exemplary embodiments of the present disclosure also detect and verify the integrity of the configuration file, collect error codes before restoring the affected configuration file, and appropriately restore the configuration file based on the error code (e.g., restore the complete configuration file, restore the minimum required attributes of the configuration file, etc.).

[0074] The features, advantages, and significance of the above exemplary embodiments are intended to be only a part of the present disclosure and are not intended to be exhaustive or to limit the technical scope of the present disclosure. Further descriptions of the features, components, configurations, operations, and implementations of the exemplary embodiments of the present disclosure, as well as related technical advantages and significance, are provided below.

[0075] It should be understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of a sample approach. Based on design preferences, it should be understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Additionally, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order and are not limited to the specific order or hierarchy presented.

[0076] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, as described above, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium having computer-readable program instructions for causing a processor to perform operations.

[0077] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or structures in grooves having instructions recorded thereon, and any suitable combination of the above. Computer-readable storage medium, as used herein, should not be construed as being a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0078] The computer-readable program instructions described herein can be downloaded to each computing / processing device from a computer-readable storage medium or to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0079] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++®, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.

[0080] These computer-readable program instructions may be provided to a processor of an SoC, a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement aspects of the function / acts specified in the flowchart and / or block diagram block or blocks.

[0081] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process that executes on the computer, other programmable data processing apparatus, or other device a series of operational steps that are performed on the computer, other programmable data processing apparatus, or other device such that the instructions, executing on the computer, other programmable data processing apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0082] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various aspects. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or arranged differently from that shown in the figures. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or acts or executes a combination of special-purpose hardware and computer instructions.

[0083] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual particular control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operations and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method performed by at least one microcontroller unit (MCU) implemented in a system-on-chip (SoC) for enhancing security of the system-on-chip, comprising: accessing a storage component that stores a plurality of configuration files; selecting at least one configuration file from the plurality of configuration files; moving the at least one configuration file to a portion of a memory component; marking the portion of the memory component as inaccessible by other components; A method comprising:

2. Marking the portion of the memory component as inaccessible comprises: generating instructions to mark the portion of the memory component as inaccessible; providing said instructions to an input / output memory management unit (IOMMU); Including, The method of claim 1 , wherein the input / output memory management unit is configured to mark the portion of the memory component as inaccessible.

3. determining whether the system-on-chip is in a shutdown process; removing the at least one configuration file from the portion of the memory component based on determining that the system-on-chip is undergoing a shutdown process; marking the portion of the memory component as accessible by other components; The method of claim 1 further comprising:

4. Marking the portion of the memory component as accessible comprises: generating instructions to mark the portion of the memory component as accessible; providing said instructions to an input / output memory management unit; Including, The method of claim 3 , wherein the input / output memory management unit is configured to mark the portion of the memory component as accessible.

5. accessing the portion of the memory component to read the at least one configuration file; initializing, based on the at least one configuration file, an environment for loading an operating system (OS) associated with the at least one configuration file; loading the operating system into the initialized environment; The method of claim 1 further comprising:

6. 2. The method of claim 1, further comprising: after marking the portion of the memory component as inaccessible, initiating loading of a trusted execution environment (TEE) within an application core (A-Core).

7. The method according to any one of claims 1 to 6, wherein the method is performed by a boot loader of the at least one microcontroller unit when executing boot firmware stored in a boot read-only memory (ROM).

8. a memory component that stores computer-readable instructions; a microcontroller unit (MCU) communicatively coupled to the memory component; and The microcontroller unit accessing a storage component that stores a plurality of configuration files; selecting at least one configuration file from the plurality of configuration files; moving the at least one configuration file to a portion of the memory component; marking the portion of the memory component as inaccessible by other components; A system on a chip (SoC) configured to execute instructions.

9. The microcontroller unit generating instructions to mark the portion of the memory component as inaccessible; providing said instructions to an input / output memory management unit (IOMMU); configured to mark the portion of the memory component as inaccessible by The system-on-chip of claim 8 , wherein the input / output memory management unit is configured to mark the portion of the memory component as inaccessible.

10. The microcontroller unit determining whether the system-on-chip is in a shutdown process; removing the at least one configuration file from the portion of the memory component based on determining that the system-on-chip is undergoing a shutdown process; marking the portion of the memory component as accessible by other components; The system-on-chip of claim 8 further configured to execute instructions.

11. The microcontroller unit generating instructions to mark the portion of the memory component as accessible; providing said instructions to an input / output memory management unit; configured to mark the portion of the memory component as accessible by The system-on-chip of claim 10 , wherein the input / output memory management unit is configured to mark the portion of the memory component as accessible.

12. The microcontroller unit accessing said portion of said memory component to read said at least one configuration file; initializing an environment for loading an operating system (OS) associated with the at least one configuration file based on the at least one configuration file; loading the operating system into the initialized environment; The system-on-chip of claim 8 further configured to execute instructions.

13. The microcontroller unit and initiating loading of a trusted execution environment (TEE) into an application core (A-Core) after marking the portion of the memory component as inaccessible. The system-on-chip of claim 8 further configured to execute instructions.

14. 14. The system-on-chip of claim 8, wherein the memory component comprises a boot read-only memory (ROM), and the computer-readable instructions include instructions for executing boot firmware stored in the boot read-only memory.

15. 1. A computer program product having instructions executable by at least one microcontroller unit (MCU) implemented in a system-on-chip (SoC) to cause the at least one MCU to perform a method for enhancing security of the system-on-chip, the computer program product comprising: The method comprises: accessing a storage component that stores a plurality of configuration files; selecting at least one configuration file from the plurality of configuration files; moving the at least one configuration file to a portion of a memory component; marking the portion of the memory component as inaccessible by other components; a computer program comprising:

16. Marking the portion of the memory component as inaccessible comprises: generating instructions to mark the portion of the memory component as inaccessible; providing said instructions to an input / output memory management unit (IOMMU); Including, 16. The computer program product of claim 15, wherein the input / output memory management unit is configured to mark the portion of the memory component as inaccessible.

17. The method comprises: determining whether the system-on-chip is in a shutdown process; removing the at least one configuration file from the portion of the memory component based on determining that the system-on-chip is undergoing a shutdown process; marking the portion of the memory component as accessible by other components; The computer program of claim 15 , further comprising:

18. Marking the portion of the memory component as accessible comprises: generating instructions to mark the portion of the memory component as accessible; providing said instructions to an input / output memory management unit; Including, 20. The computer program product of claim 17, wherein the input / output memory management unit is configured to mark the portion of the memory component as accessible.

19. The method comprises: accessing the portion of the memory component to read the at least one configuration file; initializing, based on the at least one configuration file, an environment for loading an operating system (OS) associated with the at least one configuration file; loading the operating system into the initialized environment; 16. The computer program of claim 15, further comprising:

20. The method comprises: Initiating loading of a trusted execution environment (TEE) into an application core (A-Core) after marking the portion of the memory component as inaccessible; 20. The computer program of claim 15, further comprising:

Images