Multi-core heterogeneous architecture inter-core communication method and system, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a multi-core heterogeneous architecture inter-core communication method and system, electronic equipment and a storage medium, and belongs to the technical field of inter-core communication. According to the scheme, handshake information and communication data of a first core and a second core are obtained, the first core is a data sending end, and the second core is a data receiving end; performing security negotiation processing according to the handshake message, and determining a current security level including a first level, a second level, a third level and a fourth level; based on the current security level, performing hierarchical security processing on the communication data to obtain security data; based on the current security level, performing hierarchical verification processing on the security data to obtain a verification result; and if the verification result is successful, sending the security data to the second core. According to the method, the reliability and the universality of inter-core communication under the multi-core heterogeneous system can be improved, and program redundancy is reduced.

Description

Technical Field

[0001] This application relates to the field of inter-core communication technology, and in particular to an inter-core communication method, system, electronic device and storage medium for multi-core heterogeneous architecture. Background Technology

[0002] In multi-core heterogeneous systems, inter-core communication is a core and fundamental function with wide applications. Many embedded applications rely on the reliability of inter-core communication. However, there are many types of inter-core communication, and each type requires separate reliability design and implementation, increasing software development workload and system redundancy.

[0003] In addition, most mainstream inter-core communication schemes adopt static configuration, which requires strict adherence to pre-agreed protocols for sending and receiving data, lacking flexible configurability. Summary of the Invention

[0004] The main objective of this application is to propose a method, system, electronic device, and storage medium for inter-core communication in a multi-core heterogeneous architecture, aiming to improve the reliability and versatility of inter-core communication in a multi-core heterogeneous system and reduce program redundancy.

[0005] To achieve the above objectives, one aspect of this application proposes a method for inter-core communication in a multi-core heterogeneous architecture, the method comprising: Obtain the handshake message and communication data between the first core and the second core, wherein the first core is the data sender and the second core is the data receiver; Security negotiation is performed based on the handshake message to determine the current security level, which includes level 1, level 2, level 3 and level 4. Based on the current security level, the communication data is subjected to hierarchical security processing to obtain secure data; Based on the current security level, the security data is subjected to hierarchical verification processing to obtain verification results; If the verification result is successful, the security data is sent to the second core.

[0006] In some embodiments, the handshake message includes a priority label for communication data, data processing capability, and a current stage field. The step of performing security negotiation processing based on the handshake message to determine the current security level includes the following steps: Based on a preset first security policy, a first query process is performed according to the priority label and the data processing capability to obtain a first candidate level set for the first core; Based on a preset second security policy, a second query process is performed according to the priority label and the data processing capability to obtain a second candidate level set for the second core; The negotiation principles are determined based on the current stage fields. Based on the aforementioned negotiation principle, the current security level is determined according to the first candidate level set and the second candidate level set.

[0007] In some embodiments, the step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the first level, then the communication data is encrypted to obtain the ciphertext message; The communication data is concatenated with the freshness value to obtain concatenated data; The concatenated data is digested to obtain a first message digest; The message digest is signed to obtain a digital signature; Secure data is obtained based on the ciphertext of the message, the first message digest, and the digital signature; The step of performing hierarchical verification processing on the security data based on the current security level to obtain the verification result includes the following steps: If the current security level is the first level, then the digital signature is verified to obtain the first decryption result; If the first decryption result is successful, the ciphertext of the message is decrypted to obtain the plaintext of the message; A second message digest is obtained by calculating a digest based on the plaintext of the message and the freshness value. Compare the first message digest and the second message digest. If the first message digest is equal to the second message digest, then the verification result is determined to be passed.

[0008] In some embodiments, the step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the second level, then add a frame sequence number to the communication data to obtain communication sequence data; The communication sequence data is subjected to cyclic redundancy check processing to obtain the first check code; Security data is obtained based on the communication sequence data and the first checksum. The step of performing hierarchical verification processing on the security data based on the current security level to obtain the verification result includes the following steps: If the current security level is the second level, then cyclic redundancy check is performed on the communication sequence data to obtain the second check code; Compare the first verification code and the second verification code. If the first verification code is equal to the second verification code, then the verification result is determined to be successful.

[0009] In some embodiments, the step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the third level, then add a frame sequence number to the communication data to obtain communication sequence data; Security data is obtained based on the communication sequence data; The step of performing hierarchical verification processing on the security data based on the current security level to obtain the verification result includes the following steps: If the current security level is the third level, then the security data is subjected to continuity verification to obtain a continuity result; If the continuity result is that the frame sequence numbers are consecutive, then the verification result is determined to be passed.

[0010] In some embodiments, the step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the fourth level, then security data is obtained based on the communication data.

[0011] In some embodiments, the inter-core communication method for multi-core heterogeneous architectures further includes the following steps: If the verification result is unsuccessful, the security data will be discarded, resent, or notified based on the current security level.

[0012] To achieve the above objectives, another aspect of this application proposes a multi-core heterogeneous architecture inter-core communication system, the system comprising: The first module is used to acquire handshake messages and communication data between the first core and the second core, wherein the first core is the data sender and the second core is the data receiver; The second module is used to perform security negotiation processing based on the handshake message and determine the current security level, wherein the security level includes the first level, the second level, the third level and the fourth level; The third module is used to perform hierarchical security processing on the communication data based on the current security level to obtain secure data; The fourth module is used to perform hierarchical verification processing on the security data based on the current security level, and obtain the verification result; The fifth module is used to send the security data to the second core if the verification result is successful.

[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides a method, system, electronic device, and storage medium for inter-core communication in a multi-core heterogeneous architecture. This scheme obtains handshake messages and communication data between a first core and a second core, where the first core is the data sender and the second core is the data receiver; performs security negotiation processing based on the handshake messages to determine the current security level, where the security levels include a first level, a second level, a third level, and a fourth level; performs hierarchical security processing on the communication data based on the current security level to obtain secure data; performs hierarchical verification processing on the secure data based on the current security level to obtain a verification result; if the verification result is successful, the secure data is sent to the second core. This application can improve the reliability and versatility of inter-core communication in multi-core heterogeneous systems and reduce program redundancy. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of a typical end-to-end communication model provided in the embodiments of this application; Figure 2 This is a flowchart of the inter-core communication method for a multi-core heterogeneous architecture provided in the embodiments of this application; Figure 3 This is a schematic diagram of the end-to-end communication model with added reliability hardening components provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the reliability-reinforced component provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the multi-core heterogeneous architecture inter-core communication system provided in the embodiments of this application; Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0021] Before providing a detailed description of the embodiments of this application, some related technologies involved in the embodiments of this application will be described first.

[0022] Reference Figure 1 This application logically abstracts all inter-core communication into a point-to-point communication model. In related technologies, the typical communication process of the end-to-end communication model is as follows: the first core (SOC A) prepares the data to be sent through the sender module, the sender module sends the data through the communication link, and the second core (SOC B) receives the data through the receiver module.

[0023] Currently, many methods exist to provide end-to-end communication protection for inter-core communication. However, the required protection strategies vary significantly depending on the importance, security level, and data volume of different communications. Even for the same type of communication, different stages of software development necessitate different protection strategies, requiring separate reliability designs for each type of communication, thus increasing program redundancy. Furthermore, current inter-core communication methods lack flexible configurability and cannot provide different communication modes for different communication needs.

[0024] In view of this, this application provides a method, system, electronic device, and storage medium for inter-core communication in a multi-core heterogeneous architecture. This scheme obtains handshake messages and communication data between a first core and a second core, where the first core is the data sender and the second core is the data receiver. Based on the handshake messages, security negotiation is performed to determine the current security level, which includes a first level, a second level, a third level, and a fourth level. Based on the current security level, the communication data undergoes hierarchical security processing to obtain secure data. Based on the current security level, the secure data undergoes hierarchical verification processing to obtain a verification result. If the verification result is successful, the secure data is sent to the second core. This application can improve the reliability and versatility of inter-core communication in multi-core heterogeneous systems and reduce program redundancy.

[0025] The multi-core heterogeneous architecture inter-core communication method provided in this application relates to the field of inter-core communication technology. This method can be applied to terminals, servers, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the multi-core heterogeneous architecture inter-core communication method, but is not limited to the above forms.

[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0027] Figure 2 This is an optional flowchart of the inter-core communication method for multi-core heterogeneous architectures provided in the embodiments of this application. Figure 2 The method may include, but is not limited to, steps S101 to S105.

[0028] Step S101: Obtain the handshake message and communication data between the first core and the second core, wherein the first core is the data sender and the second core is the data receiver.

[0029] Step S102: Perform security negotiation processing based on the handshake message to determine the current security level, which includes the first level, the second level, the third level, and the fourth level.

[0030] Step S103: Based on the current security level, perform hierarchical security processing on the communication data to obtain secure data.

[0031] Step S104: Based on the current security level, perform hierarchical verification processing on the security data to obtain the verification result.

[0032] Step S105: If the verification result is successful, the security data is sent to the second core.

[0033] In this embodiment, by Figure 1 In the appropriate place in the communication model, reliability hardening components (RC) are added to both ends, such as... Figure 3As shown in the diagram, after joining the RC, in a typical communication process, the first core SOC A, acting as the data sender, first negotiates security with the second core SOC B, acting as the data receiver, by exchanging specific handshake messages. This negotiation aims to determine a security level from multiple predefined security levels as the current security level that the RC needs to operate at. The security levels include Level 1, Level 2, Level 3, and Level 4. Different security levels correspond to different security processing strengths and verification strategies. The lower the security level, the higher the corresponding security processing strength and the more comprehensive the verification strategy.

[0034] For example, the first level can be set to the highest level, the second level can be set to a high level, the third level can be set to a normal level, and the fourth level can be set to a low level.

[0035] Meanwhile, SOC A prepares the communication data to be sent through the sender module. After determining the current security level that the RC needs to operate at, the sender module sends the communication data to the RC on the SOC A side. The RC then performs corresponding security processing on the communication data according to the current security level. The hierarchical security processing involves cryptographic algorithm calls, checksum generation, or frame data addition. After security processing, the communication data is reconstructed into secure data that conforms to the current security level specification.

[0036] The RC (Regulator) at SOC A sends security data to the RC module at SOC B via a communication link. The RC module at SOC B then performs hierarchical verification on the security data based on the negotiated current security level. This hierarchical verification process performs checks for integrity, immutability, and continuity based on the verification information embedded in the security data and preset verification rules. If the verification result is successful, the data is sent to the Receiver module at SOC B.

[0037] In some embodiments, step S102 may include, but is not limited to, steps S201 to S204.

[0038] Step S201: Based on the preset first security policy, perform the first query processing according to the priority label and data processing capability to obtain the first candidate level set of the first core.

[0039] Step S202: Based on the preset second security policy, perform a second query process according to priority tags and data processing capabilities to obtain the second candidate level set of the second core.

[0040] Step S203: Determine the negotiation principles based on the current stage fields.

[0041] Step S204: Based on the negotiation principle, determine the current security level according to the first candidate level set and the second candidate level set.

[0042] In this embodiment, when the Sender module of SOC A and the Receiver of SOC B establish a connection, they negotiate the behavior of the RC (Security Controller). The strategy adopted by the RC is dynamically determined by both communicating parties. The negotiation principle can be configured as high-level priority (suitable for mass production) or low-level priority (suitable for development). After negotiation, the Sender or Receiver can renegotiate as needed to reselect the security level.

[0043] Specifically, during the connection establishment phase, the two communicating parties exchange communication data priority information through handshake messages. These handshake messages include the priority label of the communication data and the data processing capabilities.

[0044] The Sender module carries a priority label for the data type in the initial handshake message. For example, data involving security is labeled as high-level (HIGH), and data involving audio and video is labeled as low-level (LOW). The Receiver module provides feedback on the priority data processing capabilities it supports through messages.

[0045] Both communicating parties map priority labels to predefined RC security policy templates. SOC A stores a table of the first security policy, and SOC B stores a table of the second security policy; the first and second security policies are identical. The RC of SOC A, based on its local priority labels and the received data processing capabilities of the peer, queries the first security policy to generate a first candidate level set. Simultaneously, the RC of SOC B, based on its received priority labels and its local data processing capabilities, queries the second security policy to generate a second candidate level set.

[0046] For example, dynamic determination can be achieved in the following way: SOC A and SOC B perform a handshake upon power-on. Each time a handshake is initiated, a negotiation is conducted. The validity of the negotiation result is limited to the data communication of that round. In the next handshake, a new negotiation is conducted. That is, SOC A and SOC B conduct a negotiation once every time the device is powered on.

[0047] Optionally, the negotiation timing can be extended to calls based on upper-layer software, that is, when switching software processes to call cross-SOC data communication, a new handshake is performed. In this case, multiple negotiations can be performed during a single boot, so that secure applications use a high security level and ordinary applications use a low security level.

[0048] Assuming SOC B's data processing capability supports processing both the highest and high priority levels, and SOC A sends a priority tag of high priority, then SOC A determines its first candidate level set, which includes both the highest and high priority levels, based on the sent priority tag and the peer's data processing capability. Similarly, SOC B determines its second candidate level set, which includes both the highest and high priority levels, based on the received priority tag and its local data processing capability.

[0049] During the negotiation process, the development phase and the mass production phase are expressed through a specific data field. That is, during the handshake, the transmitted data also includes a current phase field, which describes whether the current phase is the development phase or the mass production phase.

[0050] Optionally, stage state enumeration values ​​can be defined in the code, with different values ​​directly representing the current stage: / / Enumeration of chip lifecycle stages typedef enum { CHIP_STAGE_DEVELOPMENT = 0, / / Development phase (including prototype verification and functional testing); CHIP_STAGE_PRE_PRODUCTION = 1, / / Pre-production stage (small-batch trial production); CHIP_STAGE_MASS_PRODUCTION = 2, / / Mass production stage; CHIP_STAGE_END_OF_LIFE = 3 / / Lifecycle terminated; ChipLifeCycleStage; / / Global variable or register configuration volatile ChipLifeCycleStage g_chipStage = CHIP_STAGE_DEVELOPMENT; During the negotiation phase, the current stage field is obtained by querying the chipStage value. If the current stage field indicates the mass production stage, the negotiation principle is determined to be high-level priority; if the current stage field indicates the development stage, the negotiation principle is determined to be low-level priority.

[0051] For example, when the negotiation principle is "high-level priority", the current security level is determined to be the highest level if SOC B supports both the highest level and the higher level. Conversely, when the negotiation principle is "low-level priority", the current security level is determined to be the higher level.

[0052] It's important to note that the RC module is a connection-oriented component in software. This means that in the system, the Sender, Receiver, and RC can all have multiple instances. For example, if there are two connections in the system, connection 1 can run at the highest priority, while connection 2 can run at a normal priority.

[0053] In some embodiments, step S103 may include, but is not limited to, steps S301 to S305.

[0054] Step S301: If the current security level is Level 1, the communication data is encrypted to obtain the ciphertext message.

[0055] Step S302: The communication data and the freshness value are spliced ​​together to obtain spliced ​​data.

[0056] Step S303: Perform a digest calculation on the spliced ​​data to obtain the first message digest.

[0057] Step S304: Sign the message digest to obtain a digital signature.

[0058] Step S305: Obtain secure data based on the ciphertext of the message, the first message digest, and the digital signature.

[0059] Step S104 may include, but is not limited to, steps S401 to S404.

[0060] Step S401: If the current security level is Level 1, then the digital signature is verified to obtain the first decryption result.

[0061] Step S402: If the first decryption result is successful, the ciphertext of the message is decrypted to obtain the plaintext of the message.

[0062] Step S403: Calculate the digest based on the plaintext message and freshness value to obtain the second message digest.

[0063] Step S404: Compare the first message digest and the second message digest. If the first message digest is equal to the second message digest, then the verification result is determined to be passed.

[0064] In this embodiment, the RC module can operate at different security levels to meet the different reliability requirements of communication.

[0065] Reference Figure 4The RC module includes a data receiving (input) submodule, a management (RC manner) submodule, a packaging (Crypto lib) submodule, and a data sending (output) submodule. The input submodule receives data, saves it to an internal buffer, and waits for processing by the RC manner submodule. The RC manner submodule is responsible for negotiating the runtime level with the peer, selecting the appropriate scheme based on the negotiation result, and calling the Crypto lib submodule to process the communication data, such as freshness verification, generation, and data validation. The Crypto lib submodule encapsulates common security algorithms, such as freshness generation and cyclic redundancy check (CRC32) verification. The output submodule sends the data processed by the RC manner submodule to the user.

[0066] Specifically, when the RC module is running at the first security level, SOC A and SOC B must execute the most stringent secure data processing and verification procedures. SOC A's RC module first saves the communication data to be sent internally through the input submodule. The RC manner submodule then encrypts the original communication data using SM4 according to the first security level to obtain the ciphertext message. Simultaneously, it calls the Crypto lib submodule, using a 16-bit freshness value, which automatically increments by 1 for each data frame sent.

[0067] Understandably, the system supports setting the freshness value to zero after it overflows, in order to accommodate reset scenarios.

[0068] After data splicing is completed, the RC manner submodule uses the SM3 algorithm to calculate the digest of the original communication data and the set of freshness values, and uses the SM2 algorithm to digitally sign the digest, generating secure data which is then sent to the output submodule. The output submodule then sends the data to the RC module of SOC B through the communication link.

[0069] After receiving security data, the input submodule of the RC module in SOC B verifies the data according to the first level of the current operation through the RC manner submodule.

[0070] Specifically, the SM2 algorithm is used for signature verification. After successful verification, the ciphertext is decrypted using the same SM4 algorithm as the sender. The decrypted plaintext should be completely identical to the original communication data from the sender. To verify data integrity, the obtained plaintext is reassembled with a freshness value, and a second message digest is calculated using the same SM3 algorithm as the sender. This second message digest is then compared with the first message digest. The process is considered successful only if the two digests are completely identical, and the output submodule then sends the communication data to the Receiver module of SOC B.

[0071] In this embodiment, by encrypting and decrypting the communication data, calculating a digest from the set of plaintext messages and freshness values, and signing / verifying the digest, the integrity and immutability of the data are guaranteed, and conventional malicious attacks such as replay attacks can be prevented.

[0072] In some other embodiments, step S103 may include, but is not limited to, steps S311 to S313.

[0073] Step S311: If the current security level is Level 2, add a frame sequence number to the communication data to obtain the communication sequence data.

[0074] Step S312: Perform cyclic redundancy check processing on the communication sequence data to obtain the first check code.

[0075] Step S313: Obtain security data based on communication sequence data and the first check code.

[0076] Step S104 may include, but is not limited to, steps S411 to S412.

[0077] Step S411: If the current security level is the second level, perform cyclic redundancy check on the communication sequence data to obtain the second check code.

[0078] Step S412: Compare the first check code and the second check code. If the first check code is equal to the second check code, then the verification result is determined to be successful.

[0079] In this embodiment, when the RC module is operating at the second security level, the RC module in SOC A adds frame sequence numbers to the communication data through the RCmanner submodule. The frame sequence numbers, as metadata, together with the communication data constitute the communication sequence data. After adding the frame sequence numbers, the Crypto lib submodule is called to perform Cyclic Redundancy Check (CRC) on the communication sequence data, generating a fixed-length first checksum based on the communication sequence data. The CRC algorithm is based on polynomial division. In CRC verification, the data is considered a polynomial sequence with coefficients of 0 or 1, and the CRC checksum is obtained by performing a modulo-2 division operation on this data polynomial using a predefined generator polynomial.

[0080] Optionally, the number of bits in the first checksum is determined according to the CRC algorithm used. When using CRC32, the number of bits in the first checksum is 32; when using CRC64, the number of bits in the first checksum is 64; and when using CRC16, the number of bits in the first checksum is 16.

[0081] Preferably, the checksum generated by CRC32 is 32 bits long, providing 2^32 different possible values, which makes CRC32 more suitable for scenarios with high data transmission and high reliability requirements.

[0082] The RC manner module generates security data based on the communication sequence data and the first checksum, and sends it to the output submodule, which then sends it to the RC module of SOC B via the communication link.

[0083] After receiving security data, the input submodule of the RC module in SOC B verifies the data according to the second level of the current operation through the RC manner submodule.

[0084] Specifically, the security data is separated into communication sequence data and a first checksum, and a second checksum is calculated by performing a cyclic redundancy check on the received communication sequence data. It is understood that the CRC algorithm used in step S411 is the same as the CRC algorithm used in step S312, including but not limited to using the same polynomial, initial value, checksum bit length, and other parameters to ensure algorithm consistency.

[0085] The RC manner submodule compares the generated second checksum with the received first checksum bit by bit. If the first checksum equals the second checksum, the verification is considered successful, and the output submodule sends the communication data to the Receiver module of SOC B.

[0086] This embodiment ensures the integrity and continuity of the communication data by adding frame sequence numbers and performing CRC checks on the communication data.

[0087] In some other embodiments, step S103 may include, but is not limited to, steps S321 to S322.

[0088] Step S321: If the current security level is level 3, add a frame sequence number to the communication data to obtain the communication sequence data.

[0089] Step S322: Obtain security data based on communication sequence data.

[0090] Step S104 may include, but is not limited to, steps S421 to S422.

[0091] Step S421: If the current security level is level 3, then perform continuity verification on the security data to obtain a continuity result.

[0092] Step S422: If the continuity result is that the frame sequence numbers are continuous, then the verification result is determined to be passed.

[0093] In this embodiment, when the RC module operates at the third security level, the RC module in SOC A adds frame sequence numbers to the communication data through the RCmanner submodule. The frame sequence numbers, as metadata, together with the communication data constitute the communication sequence data, ensuring data continuity. Unlike the first and second levels, in the third level, the RC manner submodule only adds frame sequence numbers without performing any encryption or checksum calculations. This is suitable for scenarios with high real-time requirements but lower security needs.

[0094] The RC manner module sends the communication sequence data as secure data to the output submodule, which then forwards it to the RC module of SOC B via the communication link. This streamlined secure data reduces the complexity of protocol parsing, making Level 3 suitable for bulk transmission of non-sensitive data.

[0095] After receiving security data, the input submodule of the RC module in SOC B verifies the data according to the current third level of operation through the RC manner submodule.

[0096] Specifically, after acquiring the security data, continuity verification is performed by extracting the frame sequence numbers from the communication sequence data. The most recently successfully received sequence number is recorded. When new data arrives, the newly received sequence number is compared with the most recently received sequence number to see if they are consecutive. If the continuity result shows that the frame sequence numbers are consecutive, the verification result is confirmed to be successful, and the output submodule sends the communication data to the Receiver module of SOC B.

[0097] In other embodiments, step S103 may include, but is not limited to, step S331.

[0098] Step S331: If the current security level is level four, then obtain security data based on the communication data.

[0099] In this embodiment, when the RC module is running at the fourth security level, the RC module in SOC A does not process the communication data and directly recognizes the communication data as secure data for forwarding.

[0100] In some embodiments, the inter-core communication method for multi-core heterogeneous architectures may also include, but is not limited to, step S701.

[0101] In step S701, if the verification result is unsuccessful, the security data is discarded, resent, or notified based on the current security level.

[0102] In this embodiment, if the verification result of step S404, step S412 or step S422 fails, the data will be processed differently according to the policy specified by the current security level of the RC module, such as discarding the data, requesting retransmission or notifying the Receiver module.

[0103] Specifically, when the RC module is running at the first level and the verification result fails, the RC module of SOC B requests the peer to retransmit. If the peer sends erroneous data three times in a row, the connection with the peer will be disconnected.

[0104] When the RC module is running at the second level and the verification result is a failure, the RC module of SOC B only notifies the peer that the verification with the Receiver module failed.

[0105] When the RC module runs at level 3 and the verification result fails, the RC module of SOC B only records locally and does not notify other modules.

[0106] The following is a detailed introduction and explanation of the solutions in the embodiments of the present invention, with reference to specific application examples.

[0107] In multi-core heterogeneous systems, inter-core communication is a core fundamental function with wide applications. Many embedded applications rely on the reliability of inter-core communication. Therefore, improving the reliability of inter-core communication is of great significance for embedded systems, especially multi-core heterogeneous systems. This application aims to address the problem of overall communication failure in multi-core heterogeneous systems, particularly when multiple teams are collaborating on development, due to inconsistent progress among teams. It abstracts the communication process, logically abstracting all inter-core communication into a point-to-point communication model. An RC (Reliable Controller) is added at appropriate points in this model, providing a unified, configurable component that improves the reliability of inter-core communication in multi-core heterogeneous systems. The RC provides a unified, configurable protection mechanism for data communication, allowing dynamic switching between multiple protection mechanisms and configuration of different protection mechanisms according to different business needs, providing different security levels for different communications to meet diverse business requirements.

[0108] For multi-core heterogeneous systems, especially in the case of collaborative development by multiple teams, the auto-negotiation mode can provide a more flexible approach to reduce the coupling between subsystems in multi-core heterogeneous systems in terms of inter-core communication.

[0109] Because it abstracts the communication process, it is applicable to all inter-core communication scenarios in multi-core heterogeneous systems. That is, all inter-core communication can be protected for reliability using only this component, which greatly reduces program redundancy.

[0110] Reference Figure 5 This application also provides a multi-core heterogeneous architecture inter-core communication system that can implement the above-mentioned multi-core heterogeneous architecture inter-core communication method. The system includes: The first module is used to obtain handshake messages and communication data between the first core and the second core, where the first core is the data sender and the second core is the data receiver.

[0111] The second module is used to perform security negotiation processing based on the handshake message and determine the current security level, which includes the first level, the second level, the third level, and the fourth level.

[0112] The third module is used to perform graded security processing on communication data based on the current security level to obtain secure data.

[0113] The fourth module is used to perform graded verification processing on security data based on the current security level and obtain the verification results.

[0114] The fifth module is used to send security data to the second core if the verification result is successful.

[0115] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0116] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described inter-core communication method for multi-core heterogeneous architecture. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0117] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0118] Reference Figure 6 , Figure 6 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0119] The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 using the multi-core heterogeneous architecture inter-core communication method of the embodiments of this application.

[0120] The input / output interface 903 is used to implement information input and output.

[0121] The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0122] Bus 905 transmits information between various components of the device, such as processor 901, memory 902, input / output interface 903, and communication interface 904.

[0123] The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0124] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described inter-core communication method for multi-core heterogeneous architecture.

[0125] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0126] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0127] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0128] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

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

[0130] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0131] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. 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 comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0132] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for inter-core communication in a multi-core heterogeneous architecture, characterized in that, The method includes the following steps: Obtain the handshake message and communication data between the first core and the second core, wherein the first core is the data sender and the second core is the data receiver; Security negotiation is performed based on the handshake message to determine the current security level, which includes level 1, level 2, level 3 and level 4. Based on the current security level, the communication data is subjected to hierarchical security processing to obtain secure data; Based on the current security level, the security data is subjected to hierarchical verification processing to obtain verification results; If the verification result is successful, the security data is sent to the second core.

2. The method according to claim 1, characterized in that, The handshake message includes a priority label for communication data, data processing capability, and a current stage field. The security negotiation process based on the handshake message to determine the current security level includes the following steps: Based on a preset first security policy, a first query process is performed according to the priority label and the data processing capability to obtain a first candidate level set for the first core; Based on a preset second security policy, a second query process is performed according to the priority label and the data processing capability to obtain a second candidate level set for the second core; The negotiation principles are determined based on the current stage fields. Based on the aforementioned negotiation principle, the current security level is determined according to the first candidate level set and the second candidate level set.

3. The method according to claim 1, characterized in that, The step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the first level, then the communication data is encrypted to obtain the ciphertext message; The communication data is concatenated with the freshness value to obtain concatenated data; The concatenated data is digested to obtain a first message digest; The message digest is signed to obtain a digital signature; Secure data is obtained based on the ciphertext of the message, the first message digest, and the digital signature; The step of performing hierarchical verification processing on the security data based on the current security level to obtain the verification result includes the following steps: If the current security level is the first level, then the digital signature is verified to obtain the first decryption result; If the first decryption result is successful, the ciphertext of the message is decrypted to obtain the plaintext of the message; A second message digest is obtained by calculating a digest based on the plaintext of the message and the freshness value. Compare the first message digest and the second message digest. If the first message digest is equal to the second message digest, then the verification result is determined to be passed.

4. The method according to claim 1, characterized in that, The step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the second level, then add a frame sequence number to the communication data to obtain communication sequence data; The communication sequence data is subjected to cyclic redundancy check processing to obtain the first check code; Security data is obtained based on the communication sequence data and the first checksum. The step of performing hierarchical verification processing on the security data based on the current security level to obtain the verification result includes the following steps: If the current security level is the second level, then cyclic redundancy check is performed on the communication sequence data to obtain the second check code; Compare the first verification code and the second verification code. If the first verification code is equal to the second verification code, then the verification result is determined to be successful.

5. The method according to claim 1, characterized in that, The step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the third level, then add a frame sequence number to the communication data to obtain communication sequence data; Security data is obtained based on the communication sequence data; The step of performing hierarchical verification processing on the security data based on the current security level to obtain the verification result includes the following steps: If the current security level is the third level, then the security data is subjected to continuity verification to obtain a continuity result; If the continuity result is that the frame sequence numbers are consecutive, then the verification result is determined to be passed.

6. The method according to claim 1, characterized in that, The step of performing graded security processing on the communication data based on the current security level to obtain secure data includes the following steps: If the current security level is the fourth level, then security data is obtained based on the communication data.

7. The method according to claim 1, characterized in that, The inter-core communication method for multi-core heterogeneous architectures further includes the following steps: If the verification result is unsuccessful, the security data will be discarded, resent, or notified based on the current security level.

8. A multi-core heterogeneous architecture inter-core communication system, characterized in that, The system includes: The first module is used to acquire handshake messages and communication data between the first core and the second core, wherein the first core is the data sender and the second core is the data receiver; The second module is used to perform security negotiation processing based on the handshake message and determine the current security level, wherein the security level includes the first level, the second level, the third level and the fourth level; The third module is used to perform hierarchical security processing on the communication data based on the current security level to obtain secure data; The fourth module is used to perform hierarchical verification processing on the security data based on the current security level, and obtain the verification result; The fifth module is used to send the security data to the second core if the verification result is successful.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images