Processing device and related communication method

Abstract

Embodiments of the present application disclose a processing device and a related communication method. Each processing unit corresponds to a hardware identifier. A communication module includes multiple communication channels. A first processing unit sends a first command to the communication module. The command includes a first hardware identifier of the first processing unit, a first software identifier, and first information to be sent to a second processing unit. The communication module receives the first command, and writes the first hardware identifier, the first software identifier, and the first information into a first storage area, a second storage area, and a third storage area in a target communication channel respectively. The communication module sends a first signal to the second processing unit. The second processing unit receives the first signal, reads the first information from the third storage area, and judges whether the first hardware identifier recorded in the first storage area matches the first software identifier recorded in the second storage area. If the first hardware identifier does not match the first software identifier, the second processing unit discards the first information. The present application can avoid attacks on a communication system and improve communication security.

Description

Technical Field

[0001] This application relates to the field of chips, and more particularly to processing devices and related communication methods. Background Technology

[0002] With the development of System-on-Chip (SoC) technology and the increasing demands of applications, traditional single-core SoC architectures have become increasingly inadequate in terms of performance and power consumption to meet the growing design requirements. To address this challenge, SoC architectures have evolved, promoting the development of homogeneous multi-core and heterogeneous multi-core architectures. Heterogeneous multi-core architecture refers to integrating multiple different types of processor cores within a single chip. This type of SoC system includes multiple processor cores with varying performance and applications, each leveraging its specific computational advantages to optimize resource allocation. Compared to traditional single-core or homogeneous multi-core architectures, heterogeneous multi-core architectures offer significant advantages in improving overall performance and reducing power consumption, thus becoming the mainstream design solution for current SoC architectures.

[0003] In heterogeneous multi-core systems, different processor cores need to work together to complete complex tasks. Processor cores typically exchange information through message passing mechanisms, which effectively support heterogeneity. A common implementation of Inter-Processor Communication (IPC) is as follows: the source processor core sends an interrupt request to the target processor core through the IPC module. Upon receiving the interrupt, the target processor core executes the corresponding interrupt handler and replies with a response interrupt to the source processor core, thus completing the communication.

[0004] However, with increasing chip integration, the number of processor cores in a System-on-a-Chip (SoC) is constantly increasing, and the communication models between processor cores are becoming increasingly complex, bringing increasingly severe security challenges. Because the security capabilities of individual processor cores within an SoC often vary, once an attacker compromises a processor core, they may exploit the inter-core communication mechanism to forge or tamper with inter-core communication messages, thereby launching an attack. For example, if an attacker controls a low-privilege processor core but forges messages sent by a high-privilege processor core, they may achieve privilege escalation, thus threatening the security of the entire system.

[0005] Therefore, how to prevent attackers from attacking the inter-core communication system and improve the security of inter-core communication is an urgent problem to be solved. Summary of the Invention

[0006] This application provides a processing device and related communication methods, which can prevent attackers from attacking the communication system and improve communication security.

[0007] In a first aspect, embodiments of this application provide a processing apparatus, including a communication module, a first processing unit, and a second processing unit; the first processing unit is configured to: send a first command to the communication module, the first command including a first hardware identifier and a first software identifier of the first processing unit, and first information to be sent to the second processing unit; the communication module is configured to: receive the first command and store the first hardware identifier, the first software identifier, and the first information; the second processing unit is configured to: obtain the first hardware identifier and the first software identifier from the communication module, determine whether the first hardware identifier and the software identifier match according to a preset matching relationship; and perform exception handling when the first hardware identifier and the software identifier do not match.

[0008] In this embodiment, the first processing unit is responsible for constructing and sending a first command, which contains crucial security information: firstly, a unique and tamper-proof hardware identifier used to verify the hardware identity of the command source at the receiving end, ensuring the trustworthiness of the command's hardware origin; secondly, a software identifier that can be modified by software, also used to verify the command source at the receiving end and distinguish different processing units, but this software identifier may be modified by software; and thirdly, first information to be sent to the second processing unit, which may contain data or control instructions to be processed. After receiving the first command, the communication module extracts and stores the hardware identifier, software identifier, and first information, serving as a bridge for secure communication between multiple processor cores. The second processing unit obtains these identifiers from the communication module and verifies them according to preset matching rules. If the hardware identifier and software identifier do not match, it is determined to be an abnormal situation, such as the command being spoofed or originating from an unauthorized device. In this case, abnormal handling will be performed, such as refusing to execute the command, avoiding verification of the first processing unit's identity solely through the software identifier, thereby effectively preventing malware attacks and unauthorized access, ensuring that only commands from trusted sources can be executed, thus improving system security.

[0009] In some embodiments, the first processing unit includes a hardware identifier adder, which is not accessible to software; the hardware identifier adder is used to add a first hardware identifier to a first command.

[0010] In this embodiment, the hardware identifier adder is a hardware module that records the unique hardware identifier (i.e., the first hardware identifier) ​​of the first processing unit. This module can be used to add the hardware identifier of the first processing unit to commands sent by the first processing unit to the communication module. The function of the hardware identifier adder is to automatically add the first hardware identifier to the command when the first processing unit sends a command to the communication module. To prevent malicious software from tampering with the hardware identifier, once the first hardware identifier is written to the hardware identifier adder, software (such as an operating system or application) cannot directly read, modify, or control the module. Considering that the command is initially generated by software, to avoid the software potentially modifying or forging the hardware identifier during command generation, the initial first command does not need to include the first hardware identifier. This application innovatively introduces a dedicated hardware module, the hardware identifier adder, to be responsible for adding the first hardware identifier to the command, thereby ensuring the authenticity and integrity of the hardware identifier and preventing the possibility of the first processing unit actively modifying its own hardware identifier. This hardware-level protection mechanism significantly enhances the security of the communication system.

[0011] In some embodiments, before determining whether the first hardware identifier and the software identifier match according to a preset matching relationship, the second processing unit is further configured to obtain the first information from the communication module.

[0012] In this embodiment, before performing security verification (i.e., determining whether the first hardware identifier matches the software identifier), the second processing unit first obtains first information (i.e., the actual data or instructions contained in the command) from the communication module to prevent the first information from being modified during the information verification process. Obtaining the first information first and storing it in the internal buffer of the second processing unit avoids this situation. Even if the first information in the first processing unit or communication module is tampered with during verification, the second processing unit still retains the unmodified first information, thereby improving communication security.

[0013] In some embodiments, the first command further includes a second hardware identifier of the second processing unit. The communication module is further configured to: store the second hardware identifier; send a first interrupt to the second processing unit; receive a first access request sent by the second processing unit, the first access request including a third hardware identifier of the second processing unit; determine whether the third hardware identifier is consistent with the second hardware identifier; when the third hardware identifier is consistent with the second hardware identifier, allow the second processing unit to obtain first information from the communication module; the second processing unit is further configured to: receive the first interrupt; and send a first access request in response to the first interrupt.

[0014] In this embodiment, the command sent by the first processing unit includes not only a first hardware identifier, a first software identifier, and first information, but also a second hardware identifier of the second processing unit. The second hardware identifier can be used to verify whether the recipient of the information is the expected second processing unit. When the communication module receives the first command, it stores the second hardware identifier for subsequent authentication. Upon receiving the first command, the communication module sends an interrupt signal to the second processing unit to notify it that new data needs processing. Upon receiving the interrupt signal, the second processing unit sends an access request to the communication module, requesting to obtain the first information. The access request includes the third hardware identifier of the second processing unit to prove its identity. Upon receiving the access request, the communication module compares the third hardware identifier in the access request with the previously stored second hardware identifier to determine if they match. Only when the third hardware identifier matches the second hardware identifier will the communication module allow the second processing unit to obtain the first information. By storing the hardware identifier of the second processing unit in the communication module and performing authentication when the second processing unit requests access to the first information, unauthorized access is prevented.

[0015] In some embodiments, the apparatus further includes a third processing unit; the communication module is further configured to: receive a second command sent by the first processing unit, the second command including a fourth hardware identifier of the first processing unit and a fifth hardware identifier of the third processing unit; determine whether the fourth hardware identifier is consistent with the first hardware identifier; and update the second hardware identifier to the fifth hardware identifier when the fourth hardware identifier is consistent with the first hardware identifier.

[0016] In this embodiment, the communication module receives not only a first command but also a second command from the first processing unit. The second command includes a fourth hardware identifier of the first processing unit and a fifth hardware identifier of the third processing unit. The communication module needs to verify whether the sender of the second command is indeed the first processing unit. That is, by comparing the fourth hardware identifier in the second command with the previously stored first hardware identifier of the first processing unit, the sender's identity can be confirmed. When the verification is successful and it is confirmed that the second command indeed comes from the first processing unit, the communication module will perform an update operation, that is, update the previously stored second hardware identifier (i.e., the hardware identifier of the second processing unit) to the fifth hardware identifier (i.e., the hardware identifier of the third processing unit). The communication module allows the first processing unit to update the second hardware identifier stored in the communication module under specific conditions, that is, it allows the processor core of the communication destination to be dynamically changed during system operation.

[0017] In some embodiments, the communication module is further configured to: record an abnormal state in the communication module when the fourth hardware identifier is inconsistent with the first hardware identifier; or, record an abnormal state in the communication module when the third hardware identifier is inconsistent with the second hardware identifier.

[0018] In this embodiment, the communication module, in addition to basic communication functions, also has anomaly detection and recording capabilities. The fourth hardware identifier is an identifier included in the second command sent by the first processing unit, used to declare its identity. The first hardware identifier is a pre-stored, real hardware identifier of the first processing unit. If the two are inconsistent, it means an attacker (or malware) is attempting to impersonate the first processing unit to send commands. In this case, the communication module records this anomaly for subsequent analysis and processing. Alternatively, when the third hardware identifier is inconsistent with the second hardware identifier, the communication module records the anomaly, indicating a mechanism for verifying the hardware identifier of the second processing unit. Suppose a command (possibly from the first or other processing units) claims to be sent to the second processing unit, and this command includes the hardware identifier of the second processing unit. If the communication module finds that this third hardware identifier is inconsistent with its stored real hardware identifier of the second processing unit, it also considers an anomaly to have occurred and records it, possibly because the command has been tampered with or the target device has been replaced. In short, the communication module detects potential identity impersonation or tampering by comparing the hardware identifier declared in the command with its stored real hardware identifier. Once an inconsistency is detected, the abnormal state is recorded.

[0019] In some embodiments, the second processing unit is specifically used to: when the first hardware identifier matches the software identifier, determine whether an abnormal state is stored in the communication module; if an abnormal state is stored, perform abnormal handling.

[0020] In this embodiment, after receiving and verifying a command, the second processing unit can determine whether to execute the command based on the abnormal states recorded in the communication module. When the first hardware identifier matches the software identifier, the received command undergoes basic authentication to confirm that the hardware source (first hardware identifier) ​​and software source (software identifier) ​​of the command conform to preset matching rules, thus determining whether the command originates from a trusted source. Even if basic authentication is successful, the second processing unit will still further check whether the communication module records any abnormal states related to the command. These abnormal states may have been detected during previous communication, such as inconsistent hardware identifiers. If the communication module stores abnormal states related to the command, even if the first hardware identifier and software identifier match, the second processing unit will still consider the command to have a potential risk and execute corresponding exception handling.

[0021] In some embodiments, the communication module is further configured to: receive a third command sent by the first processing unit; and in response to the third command, delete the abnormal state recorded in the communication module, wherein the abnormal state stored in the communication module is prohibited from being modified by other processing units besides the first processing unit.

[0022] In this embodiment, the communication module, in addition to communication and exception logging functions, also has the ability to receive and respond to specific commands to clear exception states. When the communication module receives a third command, it executes the operation to clear the exception state, thereby removing previously recorded errors or warnings due to hardware identifier mismatch or other reasons. The exception states stored in the communication module are prohibited from being modified by any processing unit other than the first processing unit. This is a critical security restriction; only the first processing unit has the right to clear these exception states. Other processing units (such as the second and third processing units) or any other unauthorized entity cannot modify or delete these exception state records, ensuring that the clearing operation of exception states can only be initiated by the first processing unit, preventing malicious tampering or misoperation.

[0023] In some embodiments, exception handling includes at least one of discarding the first information and performing alarm handling.

[0024] In this embodiment, the first information is discarded. The first information typically refers to commands or data received from the first processing unit via the communication module. If a mismatch between the hardware identifier and the software identifier is detected, indicating that the message originates from a counterfeit source, the second processing unit can choose to directly discard the information without further processing, thereby preventing potential malicious or erroneous information from affecting the normal operation of the system. Alarm handling refers to taking a series of measures to notify the system administrator or security control system that an abnormal event has occurred, such as sending alarm messages, activating indicator lights, and triggering audible alarms.

[0025] In some embodiments, the communication module is specifically configured to: store a first hardware identifier in a first storage area of ​​the communication module, wherein the first storage area is in a read-only state after storing the first hardware identifier; store a first software identifier in a second storage area of ​​the communication module; and store first information in a third storage area of ​​the communication module.

[0026] In this embodiment, the first storage area of ​​the communication module stores a first hardware identifier. The content stored in this first storage area can only be modified by the first processing unit; other processing units can only read the content but cannot modify it. That is, other modules can read the hardware identifier in the first storage area to verify the source of the command, but no module other than the first processing unit can modify the hardware identifier in the first storage area, including the communication module itself, thereby preventing the hardware identifier from being tampered with. The second storage area of ​​the communication module stores a first software identifier. Unlike the first storage area, the second storage area may not have a "non-writable" restriction because the software identifier may need to be updated or modified. The third storage area of ​​the communication module stores first information (i.e., the actual data or instructions contained in the command). The access permissions for the third storage area may vary depending on the specific application scenario, such as allowing both reading and writing. The communication module includes multiple storage areas. By storing different types of information in different storage areas and setting different access permissions for each storage area, the security of the system is improved.

[0027] In some embodiments, the communication module is further configured to: receive a fourth command sent by the first processing unit, the fourth command including a sixth hardware identifier and second information of the first processing unit; determine whether the sixth hardware identifier is consistent with the first hardware identifier; and when the sixth hardware identifier is consistent with the first hardware identifier, update the first information in the third storage area to the second information.

[0028] In this embodiment, the communication module, in addition to its previous communication, anomaly logging, and clearing functions, also has the ability to receive specific commands to update stored information. When the communication module receives a fourth command from the first processing unit, the fourth command includes a sixth hardware identifier and second information. The sixth hardware identifier is a hardware identifier used by the first processing unit to declare its identity and is used for verification by the communication module. The second information is information that the first processing unit wants to write to the communication module to replace the previously stored first information. The communication module compares the sixth hardware identifier contained in the fourth command with its own stored, real hardware identifier (first hardware identifier) ​​related to the first processing unit, i.e., it performs authentication to confirm that the sender of the fourth command is indeed the first processing unit. Only when authentication is successful (i.e., the sixth hardware identifier matches the first hardware identifier) ​​will the communication module perform an update operation, replacing the first information previously stored in the third storage area with the second information contained in the fourth command. Hardware identifier verification ensures that only authorized processing units (the first processing unit) can update information in the communication module, preventing malicious software or unauthorized devices from tampering with critical data.

[0029] In some embodiments, the first storage region, the second storage region, and the third storage region are registers.

[0030] In this embodiment of the application, the first storage area, the second storage area, and the third storage area are storage areas inside the communication module used to store different types of information, namely, the first hardware identifier, the first software identifier, and the first information, respectively. These can be implemented using registers. Since registers have a very fast access speed, they can improve communication efficiency.

[0031] Secondly, embodiments of this application provide a communication method applied to a multi-core processing device, the multi-core processing device including a communication module, a first processing unit, and a second processing unit; the method includes: sending a first command to the communication module through the first processing unit, the first command including a first hardware identifier and a first software identifier of the first processing unit, and first information to be sent to the second processing unit; receiving the first command through the communication module, and storing the first hardware identifier, the first software identifier, and the first information; obtaining the first hardware identifier and the first software identifier from the communication module through the second processing unit, and determining whether the first hardware identifier and the software identifier match according to a preset matching relationship; when the first hardware identifier and the software identifier do not match, performing exception handling.

[0032] Thirdly, embodiments of this application provide a multi-core processor, including a communication module, a first processing unit, and a second processing unit; the first processing unit is configured to: send a first command to the communication module, the first command including a first hardware identifier and a first software identifier of the first processing unit, and first information to be sent to the second processing unit; the communication module is configured to: receive the first command and store the first hardware identifier, the first software identifier, and the first information; the second processing unit is configured to: obtain the first hardware identifier and the first software identifier from the communication module, determine whether the first hardware identifier and the software identifier match according to a preset matching relationship; and perform exception handling when the first hardware identifier and the software identifier do not match.

[0033] Fourthly, embodiments of this application provide a system-on-a-chip, including a communication module, a first processing unit, and a second processing unit; the first processing unit is configured to: send a first command to the communication module, the first command including a first hardware identifier and a first software identifier of the first processing unit, and first information to be sent to the second processing unit; the communication module is configured to: receive the first command and store the first hardware identifier, the first software identifier, and the first information; the second processing unit is configured to: obtain the first hardware identifier and the first software identifier from the communication module, determine whether the first hardware identifier and the software identifier match according to a preset matching relationship; and perform exception handling when the first hardware identifier and the software identifier do not match.

[0034] Fifthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform the method described in any of the second aspects above. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the structure of a system-on-a-chip provided in an embodiment of this application.

[0036] Figure 2 This is a schematic diagram of an inter-core communication module provided in an embodiment of this application.

[0037] Figure 3 This is a schematic diagram of a multi-core processing device provided in an embodiment of this application.

[0038] Figure 4 This is a schematic diagram of a hardware identifier adder provided in an embodiment of this application.

[0039] Figure 5 This is a schematic diagram of the storage area of ​​an inter-core communication module provided in an embodiment of this application.

[0040] Figure 6 This is a schematic diagram illustrating communication between an inter-core communication module and a second processing core, provided as an embodiment of this application.

[0041] Figure 7 This is a schematic diagram of a third processing core provided in an embodiment of this application.

[0042] Figure 8 This is a schematic diagram of an abnormal state record provided in an embodiment of this application.

[0043] Figure 9 This is a schematic diagram illustrating the deletion of an abnormal state, as provided in an embodiment of this application.

[0044] Figure 10 This is a schematic diagram illustrating a modification of the first information provided in an embodiment of this application.

[0045] Figure 11 This is a schematic diagram illustrating communication between a sending end and a receiving end, provided as an embodiment of this application.

[0046] Figure 12 This application provides a flowchart illustrating an inter-core communication method. Detailed Implementation

[0047] The embodiments of this application will now be described with reference to the accompanying drawings.

[0048] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0049] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0050] This application provides a system-on-a-chip (SoC). Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of a system-on-a-chip provided in an embodiment of this application. The multi-core heterogeneous processor 101 refers to a chip integrating multiple processor cores (also called processor hubs). These processor cores have different functions and structures, are integrated in the same chip in an efficient manner, and applications are allocated to different processor cores for parallel processing in an efficient partitioning manner, thereby improving the performance of the processor system. The multi-core heterogeneous processor 101 can be located in any electronic device, such as a computer, mobile phone, tablet, personal digital assistant, smart wearable device, smart vehicle, or smart home appliance. The multi-core heterogeneous processor 101 may include an inter-core communication module 1011 and multiple processing cores (such as processor core 1012, processor core 1013). Specifically, the multi-core heterogeneous processor 101 can be a chip, a chipset, or a circuit board carrying a chip or chipset. The chip, chipset, or circuit board carrying a chip or chipset can operate under software drive. Specifically,

[0051] Multiple processor cores ( Figure 1Taking F processors as an example (where F is an integer greater than 1), such as processor core 1012, processor core 1013, ..., processor core 101F+1, is short for processor core, also known as a kernel. It is part of the Central Processing Unit (CPU) and is manufactured from single-crystal silicon using a specific production process. All calculations, command reception or storage, and data processing by the CPU are executed by the processor core. Operating systems, file systems (such as the flash file system F2FS), or applications can run on multiple processor cores to control multiple hardware or software components connected to the processor and to process various data and perform operations. Each processor core can load instructions or data stored in a storage device (which can be understood as external storage, such as a disk) into the internal memory 102, and retrieve the instructions or data that need to be processed for computation. After the computation is completed, the processor core temporarily stores the result in the internal memory 102, and stores instructions or data that need to be stored long-term into the storage device (i.e., external storage) through the controller 103. In some embodiments, the memory in the multi-core heterogeneous processor 101 can be a cache. The cache may include one or more of a Level 1 cache, a Level 2 cache, and a Level 3 cache. The cache can store instructions or data that the multi-core heterogeneous processor 101 has recently used or that is used repeatedly. If the multi-core heterogeneous processor 101 needs to use the same instruction or data again, it can retrieve it directly from the cache. This avoids repeated accesses, reduces the waiting time of the processor cores, and thus improves the efficiency of the processor system.

[0052] The processor cores are heterogeneous, meaning that different processor cores (1012, 1013...101F+1) have different structures. For example, processor cores can be categorized into large cores, medium cores, and small cores based on performance. Furthermore, different cores may belong to different security domains and have different access permissions. For instance, a secure core has high privileges and can handle sensitive data and security-related tasks, while a normal core has low privileges and can only access non-sensitive data. A high-privilege processor core can specify a low-privilege processor core to perform a corresponding task, but a low-privilege processor core cannot instruct a high-privilege processor core to perform a corresponding task.

[0053] Multiple processor cores can communicate with each other via the inter-core communication module 1011. See also... Figure 2 , Figure 2This is a schematic diagram of an inter-core communication module provided in an embodiment of this application. The inter-core communication module 1011 typically includes multiple mailbox channels, each of which includes a set of registers for storing control information, status information, and data to be sent or received. If the source processor core is a high-privilege processor core and the destination processor core is a low-privilege processor core, the source processor core needs to request an idle mailbox channel from the inter-core communication module 1011 to send information or tasks to the destination processor core. After successful request, the source processor core configures the mailbox channel by writing the data to be sent into the designated register of the mailbox channel and setting corresponding control registers, such as interrupt control registers and destination registers, to notify the destination processor core that a new message or task has arrived. Further, the inter-core communication module 1011 sends an interrupt to the destination processor core. Upon receiving the interrupt, the destination processor core can read data from the designated register of the mailbox channel, completing one inter-core communication. After the communication ends, the mailbox channel can be released and return to an idle state, making it available for use by other processor cores.

[0054] However, potential security risks exist in scenarios where a high-privilege source processor core sends tasks to a low-privilege destination processor core. Since the mailbox channel is configured by the source processor core, if the attacker is a low-privilege processor core, they could impersonate a high-privilege source processor core to configure the registers in the mailbox channel. For example, an attacker could tamper with the source processor core identifier in the mailbox channel or modify task-related parameters. Because the destination processor core cannot verify whether the information or tasks in the mailbox channel truly originate from the genuine high-privilege source processor core, an attacker could construct malicious tasks to instruct the destination processor core to perform unauthorized operations to escalate privileges. Attackers could also inject malicious code into the mailbox channel; when the destination processor core executes this code, it could lead to system crashes, data breaches, or other malicious actions. Attackers could also send a large number of invalid or malicious tasks, consuming the destination processor core's resources and causing it to malfunction, thus achieving a denial-of-service attack. Furthermore, attackers could tamper with the data in the mailbox channel, causing the destination processor core to receive incorrect information, thereby affecting the normal functioning of the system. Therefore, additional security measures are needed to prevent low-privilege processor cores from impersonating high-privilege processor cores and ensure the security of inter-core communication.

[0055] Current technologies optimize the inter-core communication module 1011 by adding a firewall to prevent low-privilege processor cores from impersonating high-privilege processor cores. Specifically, the firewall is configured to protect the register space of the mailbox channel, ensuring that the register space for inter-core communication can only be accessed by the corresponding processor core. This also protects the shared memory used for inter-core communication, ensuring that it can only be accessed by the source and destination processor cores communicating. If a third-party attacker attempts to impersonate or tamper with messages from the inter-core communication module 1011, the firewall will block the attempt. However, this optimization method requires a firewall administrator to configure the firewall before each inter-core communication session if the firewall configuration of the inter-core communication module 1011 is not fixed. This operation affects the efficiency of inter-core communication and does not meet the design requirements of current high-performance SoCs. Furthermore, the firewall configuration itself is derived from the register configuration, and the firewall configuration itself can be modified by attackers, thus potentially posing a security risk. Furthermore, if the firewall configuration is not updated for each inter-core communication, the number of processor cores that can be accessed for each mailbox channel is fixed, and hardware resources are bound to the actual processor cores. However, since there are a large number of processor cores in the SOC, this method will result in a significant waste of mailbox resources.

[0056] Therefore, in this embodiment of the application, the inter-core communication module 1011 is improved by adding a dedicated register to each mailbox channel. This register is used by the inter-core communication module 1011 to record the unique hardware identifier of the mailbox channel applicant. That is, when a processor core applies for a mailbox channel, if the application is successful, the inter-core communication module 1011 will actively record the unique hardware identifier of the applicant in the dedicated register of that mailbox channel for subsequent identity authentication. This prevents attackers from attacking the inter-core communication system and improves the security of inter-core communication. This will be described in detail later and will not be repeated here.

[0057] Internal memory 102, or simply RAM, can be located outside the multi-core heterogeneous processor 101. It is typically a power-loss volatile memory, losing its stored contents when power is off; it can also be called main memory. In this application, internal memory 102 includes readable and writable runtime memory, used to temporarily store computational data from multiple processor cores and data exchanged with storage devices or other external storage. It can serve as a storage medium for temporary data of the operating system or other running programs. In this application, the task scenario currently running on the processor core can be predicted based on the data access characteristics of the processor core accessing internal memory 102. Internal memory 102 can include one or more of dynamic random access memory (DRAM), static random access memory (SRAM), and synchronous dynamic random access memory (SDRAM). DRAM includes Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), also known as DDR, second-generation Double Data Rate Synchronous Dynamic Random Access Memory (DDR2), third-generation Double Data Rate Synchronous Dynamic Random Access Memory (DDR3), fourth-generation Low Power Double Data Rate Synchronous Dynamic Random Access Memory (LPDDR4), and fifth-generation Low Power Double Data Rate Synchronous Dynamic Random Access Memory (LPDDR5).

[0058] Controller 103, also called a storage controller, is commonly used to manage and control communication between the multi-core heterogeneous processor 101 and external storage devices (such as disks), and to provide a standardized (e.g., Universal Flash Storage (UFS) standard) interface for this communication. It should be noted that... Figure 1 While external storage devices are not shown, the multi-core heterogeneous processor 101 can connect not only to the internal memory 102 but also to external storage devices. Specifically, the controller 103 can transmit commands (e.g., write, read, erase commands) and data to the external storage device based on read / write requests issued by the multi-core heterogeneous processor 101, and can also provide feedback events (such as command completion events, command status events, hardware error events, etc.) to the multi-core heterogeneous processor 101 based on the results of reading / writing data from the storage device. For commands or data issued from the multi-core heterogeneous processor 101, the controller 103 can encapsulate the commands or data into data packets supporting a certain protocol, while for data received by the multi-core heterogeneous processor 101, the controller 103 performs the reverse operation.

[0059] Understandable, Figure 1The structure of the system-on-a-chip described above is only one of the exemplary implementations provided in this application. The structure of the system-on-a-chip in this application includes, but is not limited to, the above implementation methods.

[0060] Next, the processing apparatus provided in this application will be described in detail with reference to the accompanying drawings. The processing apparatus can be a multi-core processing apparatus or other processing apparatus, including but not limited to the previously mentioned multi-core heterogeneous processor. The first processing unit can be a first processing core or a hardware unit with processing capabilities; the second processing unit can be a second processing core or a hardware unit with processing capabilities. The following description uses a multi-core processing apparatus, a first processing unit as a first processing core, and a second processing unit as a second processing core as an example. A detailed description will be given of how to prevent attackers from attacking the inter-core communication system and improve the security of inter-core communication.

[0061] Please see Figure 3 , Figure 3 This is a schematic diagram of a multi-core processing device provided in an embodiment of this application. The multi-core processing device 20 includes multiple processing cores 200 and an inter-core communication module 210. The multiple processing cores 200 include a first processing core 201 and a second processing core 202. The first processing core 201 can be a source processing core, and the second processing core 202 can be a destination processing core. The inter-core communication module 210 is a hardware or software component responsible for transmitting information between different processing cores.

[0062] The first processing core 201 is used to send the first command to the inter-core communication module 210.

[0063] Specifically, the first command includes a first hardware identifier and a first software identifier of the first processing core 201, and first information to be sent to the second processing core 202. The first hardware identifier is the hardware identifier corresponding to the first processing core 201. Each of the multiple processing cores has a unique hardware identifier, and different processing cores have different hardware identifiers. This hardware identifier can be used to identify the processing core sending the command and cannot be modified by software. The first software identifier is a processing core identifier that can be used to distinguish different processing cores, but the software identifier may be modified by software. The first information may include data to be processed or transmitted, and may also include one or more instructions, such as data transmission, task scheduling, status query, etc.

[0064] In some embodiments, see Figure 4 , Figure 4 This is a schematic diagram of a hardware identifier adder provided in an embodiment of this application. The first processing core 201 includes a hardware identifier adder 2011, which cannot be accessed by software. The hardware identifier adder 2011 is used to add a first hardware identifier to a first command.

[0065] Specifically, the hardware identifier adder 2011 is a hardware module that records the unique hardware identifier (i.e., the first hardware identifier) ​​of the first processing core 201. This module can be used to add the hardware identifier of the first processing core 201 to commands sent by the first processing core 201 to the inter-core communication module 210. The function of the hardware identifier adder 2011 is to automatically add the first hardware identifier to the command when the first processing core 201 sends a command to the inter-core communication module 210. To prevent malicious software from tampering with the hardware identifier, once the first hardware identifier is written to the hardware identifier adder 2011, software (such as operating systems, applications, etc.) cannot directly read, modify, or control this module. Considering that the first command is initially generated by software, to avoid the software potentially modifying or forging the hardware identifier during command generation, the initial first command does not need to include the first hardware identifier. This application innovatively introduces a dedicated hardware module, namely the hardware identifier adder 2011, to be responsible for adding the first hardware identifier to the command, thereby ensuring the authenticity and integrity of the hardware identifier and preventing the possibility of the first processing core 201 actively modifying its own hardware identifier. This hardware-level protection mechanism significantly enhances the security of the inter-core communication system.

[0066] In one embodiment, the first hardware identifier is bound to the first processing core 201 and can be embedded in the chip during the chip design stage. That is, the first hardware identifier is encoded in the hardware identifier adder and cannot be modified by software.

[0067] In some embodiments, the first processing core 201 includes a processing module 2012 and a hardware identifier adder 2011. The processing module 2012 generates initial first information and sends the initial first information to the hardware identifier adder 2011. The processing module 2012 may include a logic processing or logic calculation unit, which can be used to run software, or it may be a hardware unit that performs tasks; this embodiment is not limited in this respect.

[0068] In some embodiments, each of the multiple processing cores 200 is provided with a hardware identifier adder. When each processing core sends a command to the inter-core communication module 210, it adds the corresponding hardware identifier to the command through its own hardware identifier adder.

[0069] The inter-core communication module 210 is used to: receive a first command and store a first hardware identifier, a first software identifier, and first information.

[0070] Specifically, the inter-core communication module 210 is responsible for communication between multiple processor cores. It can be a hardware component, a software component, or a combination of both. After receiving the first command sent by the first processing core 201, the inter-core communication module 210 extracts and stores a first hardware identifier, a first software identifier, and first information. The first hardware identifier can be used to verify the source of the command and the device identity; the first software identifier can be used to verify the source of the command and the software identity; the first information may include actual data or instructions, such as data to be transmitted, tasks to be executed, and status to be queried.

[0071] In some embodiments, see Figure 5 , Figure 5 This is a schematic diagram of the storage area of ​​an inter-core communication module provided in an embodiment of this application. The inter-core communication module 210 is specifically used for: storing a first hardware identifier in a first storage area of ​​the inter-core communication module 210, and the first storage area is in a readable but not writable state after storing the first hardware identifier; storing a first software identifier in a second storage area of ​​the inter-core communication module 210; and storing first information in a third storage area of ​​the inter-core communication module 210.

[0072] Specifically, the inter-core communication module 210 may include multiple storage areas, which may include registers or internal processor storage devices, without specific limitations in this application. The first storage area of ​​the inter-core communication module 210 is used to store a first hardware identifier. The content stored in this first storage area can only be modified by the first processing core 201. Other processing cores can only read the content of the first storage area but cannot modify it. That is, other modules can read the hardware identifier in the first storage area to verify the source of the command, but no module other than the first processing core can modify the hardware identifier in the first storage area, including the inter-core communication module 210 itself, thereby preventing the hardware identifier from being tampered with. The second storage area of ​​the inter-core communication module 210 is used to store a first software identifier. Unlike the first storage area, the second storage area may not have a "non-writable" restriction because the software identifier may need to be updated or modified. The third storage area of ​​the inter-core communication module 210 is used to store first information (i.e., the actual data or instructions contained in the command). The access permissions of the third storage area may vary depending on the specific application scenario, such as allowing both reading and writing. The inter-core communication module 210 includes multiple storage areas. By storing different types of information in different storage areas and setting different access permissions for the storage areas, the security of the system is improved.

[0073] In some embodiments, the third storage area can only be accessed and modified by the first processing core 201 and the second processing core 202.

[0074] In some embodiments, the third storage area is connected to the first judgment module, which is a hardware module. The input of the first judgment module is a first hardware identifier, a second hardware identifier, and the hardware identifier of the processing core accessing the third storage area. If the hardware identifier of the processing core accessing the third storage area is consistent with the first hardware identifier or the second hardware identifier, then the processing core is allowed to access the third storage area, for example, the circuit is turned on.

[0075] In some embodiments, the inter-core communication module 210 includes multiple mailbox channels, among which a target mailbox channel is in an idle state. The target mailbox channel includes a first storage area, a second storage area, and a third storage area, such as... Figure 5 Che1 in the middle.

[0076] In some embodiments, the first command includes multiple subcommands, each carrying one or more pieces of information. For example, the first subcommand includes a first hardware identifier and can be used to request an idle target mailbox channel from the inter-core communication module 210; the second subcommand includes a first software identifier and first information and is used to configure the target mailbox channel.

[0077] It should be noted that the first storage area records the hardware identifier of the first processing core of the currently requested email channel when the email channel changes from an idle state to an occupied state. After storing the first hardware identifier, the first storage area is in a readable but not writable state.

[0078] In some embodiments, the first storage region, the second storage region, and the third storage region are registers.

[0079] Specifically, the first storage area, the second storage area, and the third storage area are storage areas inside the inter-core communication module 210 used to store different types of information, namely, the first hardware identifier, the first software identifier, and the first information, respectively. These can be implemented using registers. Since registers have a very fast access speed, the efficiency of inter-core communication can be improved.

[0080] The second processing core 202 is used to: obtain a first hardware identifier and a first software identifier from the inter-core communication module 210, determine whether the first hardware identifier and the software identifier match according to a preset matching relationship, and perform exception handling when the first hardware identifier and the software identifier do not match.

[0081] Specifically, the second processing core 202 is another processor core that communicates with the first processing core 201. The second processing core 202 obtains a first hardware identifier and a first software identifier from the inter-core communication module 210. These identifiers are sent by the first processing core 201 and stored by the inter-core communication module 210. Furthermore, the second processing core 202 has pre-defined matching rules that can be used to determine whether the first hardware identifier and the first software identifier stored in the inter-core communication module 210 match. If the second processing core 202 determines that the first hardware identifier and the first software identifier do not conform to the preset matching relationship, it considers an abnormal situation to have occurred, such as an unknown command source (the hardware identifier may come from an unauthorized device). When an abnormal situation occurs, exception handling is performed, such as refusing to execute the command (discarding the command to prevent malicious code execution). By verifying the matching relationship between the hardware identifier and the software identifier, the second processing core 202 can effectively prevent malicious software attacks and unauthorized access. This security mechanism ensures that only commands from trusted sources can be executed, thereby improving system security.

[0082] For example, suppose the first processing core 201 is responsible for running the application, and the second processing core 202 is responsible for controlling the hardware device. The application (running on the first processing core 201) needs to control the hardware device (controlled by the second processing core 202). The application can generate a command containing control instructions, adding its own hardware and software identifiers to the command, and send the command to the inter-core communication module 210. The inter-core communication module 210 passes the hardware and software identifiers to the second processing core 202, which verifies whether the hardware and software identifiers match according to a preset matching relationship. If the verification is successful, the second processing core 202 executes the control instructions and controls the hardware device. If the verification fails, the second processing core 202 refuses to execute the control instructions and issues a warning. In this way, the second processing core 202 can prevent malicious applications from controlling the hardware device, thereby protecting the system's security.

[0083] In some embodiments, if the first hardware identifier is the same as the first software identifier, then the first hardware identifier and the first software identifier are matched.

[0084] In some embodiments, the first hardware identifier and the first software identifier may not be the same, but if there is a correspondence or conversion between the first hardware identifier and the first software identifier, then the first hardware identifier and the first software identifier match.

[0085] In some embodiments, the second processing core 202 pre-stores the matching relationship between the hardware identifier and the software identifier of each processing core, and determines whether the first hardware identifier and the first software identifier match by using the pre-stored matching relationship.

[0086] In some embodiments, the second processing core 202 is pre-designed with a hardware circuit that matches the hardware identifier with the software identifier, and the hardware circuit is used to determine whether the first hardware identifier matches the first software identifier.

[0087] In some embodiments, before determining whether the first hardware identifier and the software identifier match according to a preset matching relationship, the second processing core 202 is further configured to obtain the first information from the inter-core communication module 210.

[0088] Specifically, before performing security verification (i.e., determining whether the first hardware identifier matches the software identifier), the second processing core 202 first obtains the first information (i.e., the actual data or instructions contained in the command) from the inter-core communication module 210 to prevent the first information from being modified during the information verification process. If the first information is not obtained before security verification, but only after verification is passed, the first information may be maliciously tampered with during the time window between verification and obtaining the first information. For example, malware can modify the instructions in the first information to perform malicious operations. Obtaining the first information first and storing it in the internal buffer of the second processing core 202 can prevent this from happening. Even if the first information in the first processing core 201 or the inter-core communication module 210 is tampered with during verification, the second processing core 202 still retains the first information before it was tampered with, thereby improving the security of inter-core communication.

[0089] For example, the first processing core 201 sends a command containing a hardware identifier, a software identifier, and first information to the inter-core communication module 210, which stores the hardware identifier, software identifier, and first information. Then, the second processing core 202 obtains the first information from the inter-core communication module 210. Further, the second processing core 202 obtains the hardware identifier and software identifier from the inter-core communication module 210. The second processing core 202 determines whether the hardware identifier and software identifier match according to a preset matching relationship. If they match, the second processing core 202 processes the first information (executes the command). If they do not match, the second processing core 202 performs exception handling, including discarding the first information.

[0090] In some embodiments, see Figure 6 , Figure 6This is a schematic diagram of communication between an inter-core communication module and a second processing core provided in an embodiment of this application. The first command further includes a second hardware identifier of the second processing core 202. The inter-core communication module 210 is further configured to: store the second hardware identifier; send a first interrupt to the second processing core 202; receive a first access request sent by the second processing core 202, the first access request including a third hardware identifier of the second processing core 202; determine whether the third hardware identifier is consistent with the second hardware identifier; when the third hardware identifier is consistent with the second hardware identifier, allow the second processing core 202 to obtain first information from the inter-core communication module 210; the second processing core 202 is further configured to: receive the first interrupt; and send a first access request in response to the first interrupt.

[0091] Specifically, the command sent by the first processing core 201 includes not only the first hardware identifier, the first software identifier, and the first information, but also the second hardware identifier of the second processing core 202. The second hardware identifier can be used to verify whether the recipient of the information is the expected second processing core 202. When the inter-core communication module 210 receives the first command, it stores the second hardware identifier for subsequent authentication. After receiving the first command, the inter-core communication module 210 sends an interrupt signal to the second processing core 202 to notify it that new data needs to be processed. Upon receiving the interrupt signal, the second processing core 202 sends an access request to the inter-core communication module 210 to obtain the first information. The access request includes the third hardware identifier of the second processing core 202 to prove its identity. Upon receiving the access request, the inter-core communication module 210 compares the third hardware identifier in the access request with the previously stored second hardware identifier to determine if they match. Only when the third hardware identifier matches the second hardware identifier will the inter-core communication module 210 allow the second processing core 202 to obtain the first information. By storing the hardware identifier of the second processing core 202 in the inter-core communication module 210 and authenticating it when the second processing core 202 requests access to the first information, unauthorized access is prevented.

[0092] In some embodiments, determining whether the third hardware identifier matches the second hardware identifier can be implemented by hardware circuitry. When they match, the circuit activates the inter-core communication module 210, allowing the second processing core to acquire the first information.

[0093] For example, the first processing core 201 sends a first command containing a first hardware identifier, a first software identifier, first information, and a second hardware identifier to the inter-core communication module 210. The inter-core communication module 210 then stores the first hardware identifier, the first software identifier, the first information, and the second hardware identifier. Next, the inter-core communication module 210 sends a first interrupt to the second processing core 202. When the second processing core 202 receives the first interrupt, it responds by sending a first access request containing a third hardware identifier to the inter-core communication module 210. Further, the inter-core communication module 210 determines whether the third hardware identifier matches the second hardware identifier. If they match, the inter-core communication module 210 allows the second processing core 202 to access the first information; if they do not match, the inter-core communication module 210 refuses the second processing core 202's access to the first information and may perform exception handling. By storing the hardware identifier of the second processing core 202 in the inter-core communication module 210 and performing authentication when the second processing core 202 requests access to the first information, unauthorized devices or malicious software can be prevented from impersonating the second processing core 202 to obtain sensitive information.

[0094] In some embodiments, see Figure 7 , Figure 7 This is a schematic diagram of a third processing core provided in an embodiment of this application. The device further includes a third processing core 203; an inter-core communication module 210, which is further configured to: receive a second command sent by a first processing core 201, the second command including a fourth hardware identifier of the first processing core 201 and a fifth hardware identifier of the third processing core 203; determine whether the fourth hardware identifier is consistent with the first hardware identifier; and when the fourth hardware identifier is consistent with the first hardware identifier, update the second hardware identifier to the fifth hardware identifier.

[0095] Specifically, the inter-core communication module 210 receives not only the first command but also a second command from the first processing core 201. The second command includes a fourth hardware identifier of the first processing core 201 and a fifth hardware identifier of the third processing core 203. The inter-core communication module 210 needs to verify whether the sender of the second command is indeed the first processing core 201. This is achieved by comparing the fourth hardware identifier in the second command with the previously stored first hardware identifier of the first processing core 201. Only when the verification is successful, confirming that the second command indeed originates from the first processing core 201, will the inter-core communication module 210 perform an update operation, updating the previously stored second hardware identifier (i.e., the hardware identifier of the second processing core 202) to the fifth hardware identifier (i.e., the hardware identifier of the third processing core 203). The inter-core communication module 210 allows the first processing core 201 to update the second hardware identifier stored in the inter-core communication module 210 under specific conditions, allowing for dynamic replacement of the processor core at the communication destination or reconfiguration of the system's hardware resources during system operation. For example, if the second processing core 202 fails, it can be replaced by the third processing core 203, and the hardware identifier can be updated in the manner described above. The third processing core 203 replaces the second processing core 202, allowing the system to continue to operate normally.

[0096] For example, suppose the first processing core 201 is responsible for managing system resources, the second processing core 202 is responsible for handling database requests, and the third processing core 203 is a spare processor core. Under normal circumstances, the second processing core 202 is responsible for handling database requests, and the second hardware identifier stored in the inter-core communication module 210 is the hardware identifier of the second processing core 202. If the second processing core 202 malfunctions, the first processing core 201 detects the malfunction. The first processing core 201 can send a second command to the inter-core communication module 210, which includes the fourth hardware identifier of the first processing core 201 and the fifth hardware identifier of the third processing core 203. Then, the inter-core communication module 210 verifies that the fourth hardware identifier is consistent with the first hardware identifier, and updates the previously stored second hardware identifier (the hardware identifier of the second processing core 202) to the fifth hardware identifier (the hardware identifier of the third processing core 203). At this time, the third processing core 203 takes over the work of the second processing core 202 and begins to process database requests. In this way, when the second processing core 202 fails, the system can automatically switch to the third processing core 203 and update the hardware identifier, thereby ensuring the continuous availability of the system.

[0097] In some embodiments, see Figure 8 , Figure 8The diagram provided in this application embodiment illustrates an abnormal state recording method. The inter-core communication module 210 is further configured to: record an abnormal state in the inter-core communication module 210 when the fourth hardware identifier is inconsistent with the first hardware identifier; or, record an abnormal state in the inter-core communication module 210 when the third hardware identifier is inconsistent with the second hardware identifier.

[0098] Specifically, in addition to basic communication functions, the inter-core communication module 210 also has anomaly detection and logging capabilities. The fourth hardware identifier is an identifier included in the second command sent by the first processing core 201, used to declare its identity. The first hardware identifier is a pre-stored, real hardware identifier of the first processing core 201 stored by the inter-core communication module 210. If the two are inconsistent, it means an attacker (or malware) is attempting to impersonate the first processing core 201 to send commands. In this case, the inter-core communication module 210 will record this anomaly for subsequent analysis and processing. Alternatively, when the third hardware identifier is inconsistent with the second hardware identifier, the inter-core communication module 210 records the anomaly, indicating a mechanism for verifying the hardware identifier of the second processing core 202. Suppose a command (possibly from the first processing core 201 or another processing core) claims to be sent to the second processing core 202, and this command includes the hardware identifier of the second processing core 202. If the inter-core communication module 210 finds that this third hardware identifier is inconsistent with its stored real hardware identifier of the second processing core 202, it also considers an anomaly to have occurred and records it. This could be due to command tampering or target device replacement. In short, the inter-core communication module 210 detects potential identity impersonation or tampering by comparing the hardware identifier declared in the command with its own stored real hardware identifier. If an inconsistency is found, the abnormal state is recorded.

[0099] In some embodiments, the second processing core 202 is specifically used to: when the first hardware identifier matches the software identifier, determine whether an abnormal state is stored in the inter-core communication module 210; if an abnormal state is stored, perform abnormal handling.

[0100] Specifically, after receiving and verifying a command, the second processing core 202 can determine whether to execute the command based on the abnormal states recorded in the inter-core communication module 210. When the first hardware identifier matches the software identifier, the received command undergoes basic authentication to confirm that the hardware source (first hardware identifier) ​​and software source (software identifier) ​​of the command conform to preset matching rules, indicating that the command comes from a trusted source. Even if the basic authentication is passed, the second processing core 202 will still further check whether the inter-core communication module 210 records any abnormal states related to the command. These abnormal states may have been detected during previous communication, such as inconsistent hardware identifiers. If the inter-core communication module 210 stores abnormal states related to the command, even if the first hardware identifier and software identifier match, the second processing core 202 will still consider the command to have potential risks and execute corresponding exception handling.

[0101] In some embodiments, see Figure 9 , Figure 9 This is a schematic diagram of deleting an abnormal state provided in an embodiment of this application. The inter-core communication module 210 is further configured to: receive a third command sent by the first processing core 201; and in response to the third command, delete the abnormal state recorded in the inter-core communication module 210. The abnormal state stored in the inter-core communication module 210 is prohibited from being modified by other processing units other than the first processing core 201.

[0102] Specifically, in addition to communication and exception logging functions, the inter-core communication module 210 also has the ability to receive and respond to specific commands to clear exception states. When the inter-core communication module 210 receives a third command, it will execute the operation to clear the exception state, thereby removing error or warning information previously recorded due to hardware identifier mismatch or other reasons. The exception states stored in the inter-core communication module 210 are prohibited from being modified by any processing unit other than the first processing core 201. This is a critical security restriction; only the first processing core 201 has the right to clear these exception states. Other processing cores (such as the second processing core 202, the third processing core 203) or any other unauthorized entity cannot modify or delete these exception state records, ensuring that the exception state clearing operation can only be initiated by the first processing core 201, preventing malicious tampering or misoperation.

[0103] In some embodiments, the exception handling mentioned above includes at least one of discarding the first information and performing alarm handling.

[0104] Specifically, the first message is discarded. The first message typically refers to commands or data received from the first processing core 201 via the inter-core communication module 210. If a hardware identifier mismatch is detected with the software identifier, or if the hardware identifier is not equal to the expected hardware identifier value of the first processing core, it indicates that the message originated from a counterfeit source. The second processing core 202 can choose to directly discard the message without any further processing, thus preventing potentially malicious or erroneous information from affecting the normal operation of the system. Alarm handling refers to taking a series of measures to notify the system administrator or security control system that an abnormal event has occurred, such as sending alarm messages, activating indicator lights, and triggering audible alarms.

[0105] In some embodiments, see Figure 10 , Figure 10 This is a schematic diagram of modifying first information provided in an embodiment of this application. The inter-core communication module 210 is further configured to: receive a fourth command sent by the first processing core 201, the fourth command including a sixth hardware identifier and second information of the first processing core 201; determine whether the sixth hardware identifier is consistent with the first hardware identifier; and when the sixth hardware identifier is consistent with the first hardware identifier, update the first information in the third storage area to the second information.

[0106] Specifically, in addition to its previous communication, anomaly logging, and clearing functions, the inter-core communication module 210 also has the ability to receive specific commands to update stored information. When the inter-core communication module 210 receives a fourth command from the first processing core 201, the fourth command includes a sixth hardware identifier and second information. The sixth hardware identifier is the hardware identifier used by the first processing core 201 to declare its identity and is used by the inter-core communication module 210 for verification. The second information is the information that the first processing core 201 wants to write to the inter-core communication module 210 to replace the previously stored first information. The inter-core communication module 210 compares the sixth hardware identifier contained in the fourth command with its own stored true hardware identifier (first hardware identifier) ​​related to the first processing core 201, i.e., it performs authentication to confirm that the fourth command was indeed sent by the first processing core 201. Only when authentication is successful (i.e., the sixth hardware identifier matches the first hardware identifier) ​​will the inter-core communication module 210 perform an update operation, replacing the first information previously stored in the third storage area with the second information contained in the fourth command. Hardware identification verification ensures that only authorized processing cores (first processing core 201) can update information in the inter-core communication module 210, preventing malicious software or unauthorized devices from tampering with critical data.

[0107] It should be noted that for the processing cores (also called Masters) in a heterogeneous multi-core system, each Master is assigned a unique Master ID. This Master ID serves as a unique identifier for each Master and is ensured to be a software-unchangeable marker, i.e., the hardware identifier described above. This hardened Master ID is used to address the issues of preventing impersonation, tampering, and theft during inter-core communication between processors in a heterogeneous multi-core scenario. When processor cores in a heterogeneous multi-core system communicate using the IPC mailbox channel, the message source processor first requests and occupies an idle mailbox channel. While the message source processor occupies the mailbox channel, the IPC module automatically records the message source processor's Master ID, designated as Master ID1. The recorded Master ID1 is sent along with the message to the message receiver, which checks to confirm that the message comes from a legitimate source. Because the recorded Master ID1 is a software-unchangeable unique identifier, this Master ID signal cannot be tampered with by attackers. When an attacker impersonates a high-privilege processor core to send messages, the Master ID1 carried in the message sent to the message receiver is the attacker's Master ID, not the Master ID of the intended message sender. The message receiver can identify the impersonated message by checking this Master ID. Simultaneously, before inter-core communication (IPC) begins, the message sender specifies which destination processor the IPC message will be sent to. The sender also needs to configure the Master ID corresponding to the message receiver processor, called Master ID2. Master ID2 can only be specified by the message sender. During Master ID2 configuration, the IPC mailbox channel checks if the Master ID of the processor configuring Master ID2 is Master ID1. If it is not Master ID1, the IPC module will generate an exception log and intercept the configuration operation. Once the IPC mailbox channel determines the message sender's Master ID (Master ID1) and the message receiver's Master ID (Master ID2), it checks access to the mailbox channel. If access operations occur from a Master that is not the IPC message source or destination, the IPC module will generate an exception log and intercept the configuration operation. If an attacker accesses the IPC mailbox channel, since the attacker's Master ID is neither MasterID1 nor MasterID2, the attacker cannot modify or read the registers and mailbox information inside the IPC channel, effectively preventing the attacker from tampering with or stealing inter-core communication information.The abnormal status information recorded by the IPC module can only be cleared by the Master ID of the message sender; clearing operations by other Masters are ineffective. Compared to traditional software-based message source tagging, this application uses a hardware-generated Master ID identifier, which cannot be modified by software and cannot be denied by attackers. Previously, software tagging methods could be used to spoof inter-core communication messages by modifying software configuration. Compared to configuring a firewall, this application requires no additional configuration, improving the efficiency of inter-core communication and saving hardware resources.

[0108] For example, such as Figure 11 As shown, Figure 11 This illustration shows a communication between a sender and receiver according to an embodiment of this application. When the sender and receiver of an IPC message access the IPC inter-core communication module, they both carry a unique Master ID (i.e., hardware identifier) ​​indicating the Master. The IPC inter-core communication module enhances the security of inter-core communication by checking the Master accessing the mailbox channel. Compared to unprotected communication, the protection provided in this application only requires a small amount of additional configuration and checks, and its impact on the overall efficiency of inter-core communication is negligible. Furthermore, the IPC communication mailbox does not need to be bound to a specific processor, greatly improving resource utilization.

[0109] In summary, in this application, the first processing core 201, as the initiator of communication, is responsible for constructing and sending a first command to the inter-core communication module 210. The key components of this command include: a unique and tamper-proof hardware identifier specific to the first processing core 201, which is unique among multiple processor cores and used to verify the hardware identity of the command source at the receiving end, ensuring the command originates from a trusted hardware source; a first software identifier, used to distinguish messages from different software components or processes initiating communication on the first processing core 201. While the software identifier helps distinguish the message source, it can be modified by malicious software; and first information to be sent to the second processing core 202. This information may contain data to be processed or control instructions, such as data transfer, task scheduling, or status queries. The inter-core communication module 210, acting as a bridge for communication between multiple processor cores, is responsible for receiving the first command sent by the first processing core 201 and extracting and storing the first hardware identifier, the first software identifier, and the first information. This module can be a hardware component, a software component, or a combination of both. The system employs a first hardware identifier to verify the hardware source and device identity of the command, providing hardware-level security. A first software identifier verifies the software source of the command. The first information contains the actual data or instructions. The second processing core 202, acting as the receiver of communication, obtains the first hardware identifier and the first software identifier from the inter-core communication module 210 and verifies them according to a preset matching rule to determine if they match. This matching rule is pre-defined and used to determine whether the received command originates from a trusted source. If the second processing core 202 determines that the first hardware identifier and the first software identifier do not conform to the preset matching relationship, it considers an anomaly to have occurred, such as the command being maliciously tampered with (the software identifier being modified) or the command originating from an unknown source (the hardware identifier originating from an unauthorized device). When an anomaly is detected, the second processing core 202 will perform corresponding anomaly handling, such as refusing to execute the command (discarding the command to prevent malicious code execution), and may issue a warning or log the information. Through the joint verification of the hardware and software identifiers, the system effectively prevents malware attacks and unauthorized access, ensuring that only commands from trusted sources can be executed, thereby significantly improving system security.

[0110] Please see Figure 12 , Figure 12 This application provides a flowchart illustrating an inter-core communication method. The method is applied to a processing device, which includes a communication module, a first processing unit, and a second processing unit. The method includes:

[0111] Step S301: Send a first command to the communication module through the first processing unit.

[0112] Specifically, the first command includes the first hardware identifier and the first software identifier of the first processing unit, and the first information to be sent to the second processing unit.

[0113] Step S302: Receive the first command through the communication module and store the first hardware identifier, the first software identifier, and the first information.

[0114] Step S303: The second processing unit obtains the first hardware identifier and the first software identifier from the communication module, and determines whether the first hardware identifier and the software identifier match according to the preset matching relationship; when the first hardware identifier and the software identifier do not match, exception handling is performed.

[0115] It should be noted that for a detailed description of multi-core processing devices, please refer to the above.

[0116] This application provides a multi-core processor, including an inter-core communication module, a first processing core, and a second processing core. The first processing core is configured to: send a first command to the inter-core communication module, the first command including a first hardware identifier and a first software identifier of the first processing core, and first information to be sent to the second processing core; the inter-core communication module is configured to: receive the first command and store the first hardware identifier, the first software identifier, and the first information; the second processing core is configured to: obtain the first hardware identifier and the first software identifier from the inter-core communication module, and determine whether the first hardware identifier and the software identifier match according to a preset matching relationship; when the first hardware identifier and the software identifier do not match, perform exception handling.

[0117] It should be noted that for a detailed description of multi-core processing devices, please refer to the above.

[0118] This application provides a system-on-a-chip, including an inter-core communication module, a first processing core, and a second processing core. The first processing core is configured to: send a first command to the inter-core communication module, the first command including a first hardware identifier and a first software identifier of the first processing core, and first information to be sent to the second processing core; the inter-core communication module is configured to: receive the first command and store the first hardware identifier, the first software identifier, and the first information; the second processing core is configured to: obtain the first hardware identifier and the first software identifier from the inter-core communication module, and determine whether the first hardware identifier and the software identifier match according to a preset matching relationship; when the first hardware identifier and the software identifier do not match, perform exception handling.

[0119] It should be noted that for a detailed description of multi-core processing devices, please refer to the above.

[0120] This application provides a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform any of the above-described data transmission methods.

[0121] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0122] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0124] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0126] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium may include various media capable of storing program code, such as a USB flash drive, portable hard drive, magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

[0127] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A processing apparatus, characterized in that, It includes a communication module, a first processing unit, and a second processing unit; The first processing unit is configured to: send a first command to the communication module, wherein the first command includes a first hardware identifier and a first software identifier of the first processing unit, and first information to be sent to the second processing unit; The communication module is configured to: receive the first command, and store the first hardware identifier, the first software identifier, and the first information; The second processing unit is configured to: obtain the first hardware identifier and the first software identifier from the communication module; determine whether the first hardware identifier and the software identifier match according to a preset matching relationship; and perform exception handling when the first hardware identifier and the software identifier do not match.

2. The apparatus according to claim 1, characterized in that, The first processing unit includes a hardware identifier adder, which is not accessible by software. The hardware identifier adder is used to add the first hardware identifier to the first command.

3. The apparatus according to claim 1 or 2, characterized in that, Before determining whether the first hardware identifier and the software identifier match according to the preset matching relationship, the second processing unit is also used to obtain the first information from the communication module.

4. The apparatus according to claim 3, characterized in that, The first command also includes a second hardware identifier for the second processing unit, and the communication module is further configured to: Store the second hardware identifier; Send a first interrupt to the second processing unit; Receive a first access request sent by the second processing unit, wherein the first access request includes a third hardware identifier of the second processing unit; Determine whether the third hardware identifier is consistent with the second hardware identifier; When the third hardware identifier matches the second hardware identifier, the second processing unit is allowed to obtain the first information from the communication module; The second processing unit is further configured to: Receive the first interrupt; In response to the first interruption, the first access request is sent.

5. The apparatus according to claim 4, characterized in that, The device also includes a third processing unit; The communication module is also used for: The system receives a second command sent by the first processing unit, the second command including a fourth hardware identifier of the first processing unit and a fifth hardware identifier of the third processing unit. Determine whether the fourth hardware identifier is consistent with the first hardware identifier; When the fourth hardware identifier is the same as the first hardware identifier, the second hardware identifier is updated to the fifth hardware identifier.

6. The apparatus according to claim 5, characterized in that, The communication module is also used for: When the fourth hardware identifier is inconsistent with the first hardware identifier, an abnormal state is recorded in the communication module; or... When the third hardware identifier is inconsistent with the second hardware identifier, the abnormal state is recorded in the communication module.

7. The apparatus according to claim 6, characterized in that, The second processing unit is specifically used for: When the first hardware identifier matches the software identifier, it is determined whether the abnormal state is stored in the communication module; If the aforementioned abnormal state is stored, execute the aforementioned exception handling.

8. The apparatus according to claim 7, characterized in that, The communication module is also used for: Receive the third command sent by the first processing unit; In response to the third command, the abnormal state recorded in the communication module is deleted, and the abnormal state stored in the communication module is prohibited from being modified by any processing unit other than the first processing unit.

9. The apparatus according to any one of claims 1-8, characterized in that, The exception handling includes at least one of the following: discarding the first information and performing alarm processing.

10. The apparatus according to any one of claims 1-9, characterized in that, The communication module is specifically used for: The first hardware identifier is stored in the first storage area of ​​the communication module, and the first storage area is in a read-only state after storing the first hardware identifier; The first software identifier is stored in the second storage area of ​​the communication module; The first information is stored in the third storage area of ​​the communication module.

11. The apparatus according to claim 10, characterized in that, The communication module is also used for: Receive a fourth command sent by the first processing unit, the fourth command including the sixth hardware identifier and second information of the first processing unit; Determine whether the sixth hardware identifier is consistent with the first hardware identifier; When the sixth hardware identifier matches the first hardware identifier, the first information in the third storage area is updated to the second information.

12. The apparatus according to claim 10 or 11, characterized in that, The first storage area, the second storage area, and the third storage area are registers.

13. A communication method, characterized in that, The method is applied to a processing device, which includes a communication module, a first processing unit, and a second processing unit; the processing device includes: The first processing unit sends a first command to the communication module. The first command includes a first hardware identifier and a first software identifier of the first processing unit, and first information to be sent to the second processing unit. The communication module receives the first command and stores the first hardware identifier, the first software identifier, and the first information. The second processing unit obtains the first hardware identifier and the first software identifier from the communication module, and determines whether the first hardware identifier and the software identifier match according to a preset matching relationship; when the first hardware identifier and the software identifier do not match, exception handling is performed.

Images