Inter-process communication attribute encapsulation method and electronic device

Abstract

The application discloses an encapsulation method of inter-process communication attributes and an electronic device, relates to the technical field of encapsulation of inter-process communication attributes, and comprises the following steps: a protected memory area for encapsulating at least one inter-process communication attribute is built, the protected memory area at least comprises a first area for storing attribute metadata and a second area for storing attribute values; the at least one inter-process communication attribute is bound to the protected memory area; the access permission of the protected memory area is set to read-only through a memory management interface of an operating system, so as to encapsulate the attribute metadata; when an access request for a target communication attribute is received, the position of the target communication attribute in the second area is located according to the attribute metadata in the first area; and an access operation corresponding to the access request type is executed through an encapsulation interface. The problems of poor generality and low access efficiency of the inter-process communication attribute encapsulation scheme in the prior art are solved, and reliable encapsulation of inter-process communication attributes is realized.

Description

Technical Field

[0001] This application relates to the field of encapsulation technology for inter-process communication attributes, and more particularly to a method and electronic device for encapsulating inter-process communication attributes. Background Technology

[0002] Inter-process communication is a crucial foundation for software modularization. In embedded systems such as baseboard management controllers, D-Bus (Inter-Process Communication System) is widely used for data exchange between modules, and its attribute mechanism provides a standardized data interface.

[0003] Currently, there are three main methods for encapsulating DBus attributes in related technologies: one is to directly call complex native interfaces; the second is to perform secondary encapsulation based on string key-value pairs; and the third is to encapsulate DBus related functional interfaces based on language-specific features. However, these technologies have significant drawbacks: firstly, DBus attribute metadata (such as service names and paths) is stored in string format, which is easily tampered with due to memory overflow, leading to silent failure of communication links and making debugging difficult; secondly, string management is inefficient and suffers from hash collision problems; and thirdly, existing encapsulations are deeply coupled with specific programming languages, resulting in poor reusability and high development and maintenance costs.

[0004] Therefore, how to provide a secure, efficient, and language-independent method for encapsulating inter-process communication attributes to fundamentally prevent communication anomalies caused by memory out-of-bounds errors and reduce development complexity has become a pressing technical problem in this field. Summary of the Invention

[0005] This application provides a method and electronic device for encapsulating inter-process communication attributes, which at least solves the technical problems in the related art that lead to code complexity, easy tampering of attribute metadata due to memory out-of-bounds errors, and consequent loss of communication signals and difficulty in debugging caused by directly using the native inter-process communication interface.

[0006] This application provides a method for encapsulating inter-process communication attributes, which includes: A protected memory region is created to encapsulate at least one inter-process communication attribute. The protected memory region includes at least a first region for storing attribute metadata and a second region for storing attribute values. At least one inter-process communication attribute is bound to the protected memory region, wherein the attribute metadata includes communication identification information of the bound inter-process communication attribute and a mapping relationship between the storage location of the bound inter-process communication attribute in the second region. The access permission of at least the first region in the protected memory region is set to read-only via the operating system's memory management interface to encapsulate the attribute metadata. In response to receiving an access request for a target communication attribute, the location of the target communication attribute in the second region is located based on the attribute metadata in the first region, and an access operation corresponding to the access request type is executed through the encapsulation interface.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the encapsulation method of inter-process communication attributes in the following embodiments when executing the computer program.

[0008] A protected memory region is created to encapsulate at least one inter-process communication attribute. The protected memory region includes at least a first region for storing attribute metadata and a second region for storing attribute values. At least one inter-process communication attribute is bound to the protected memory region, wherein the attribute metadata includes communication identification information of the bound inter-process communication attribute and a mapping relationship between the storage location of the bound inter-process communication attribute in the second region. The access permission of at least the first region in the protected memory region is set to read-only via the operating system's memory management interface to encapsulate the attribute metadata. In response to receiving an access request for a target communication attribute, the location of the target communication attribute in the second region is located based on the attribute metadata in the first region, and an access operation corresponding to the access request type is executed through the encapsulation interface.

[0009] The method for encapsulating inter-process communication attributes provided in this application involves creating a protected memory area for encapsulating at least one inter-process communication attribute. The protected memory area includes at least a first area for storing attribute metadata and a second area for storing attribute values. At least one inter-process communication attribute is bound to the protected memory area, wherein the attribute metadata includes communication identification information of the bound inter-process communication attribute and a mapping relationship of the storage location of the bound inter-process communication attribute in the second area. The access permission of at least the first area in the protected memory area is set to read-only through the operating system's memory management interface to encapsulate the attribute metadata. In response to receiving an access request for a target communication attribute, the location of the target communication attribute in the second area is located based on the attribute metadata in the first area, and an access operation corresponding to the access request type is executed through the encapsulation interface. In this innovative way, the operating system-level proactive memory protection mechanism is deeply integrated with the attribute management of inter-process communication. By creating a protected memory area containing a first region (storing attribute metadata) and a second region (storing attribute values), physical isolation between data and metadata is achieved, laying the foundation for fine-grained memory protection and secure access. Furthermore, by setting the access permission of this memory area to read-only through the operating system's memory management interface, any illegal writes are proactively prevented at the operating system level, fundamentally eliminating the possibility of accidental tampering of attribute metadata due to memory out-of-bounds errors, thereby ensuring the integrity and reliability of inter-process communication identifiers. On this basis, in response to access requests for target attributes, the location of the attribute in the second region is located based on the metadata of the first region, and the operation is performed. Efficient and direct data location and access are achieved through a pre-defined address mapping relationship, avoiding the performance overhead and collision problems of string-based search. At the same time, this encapsulation mechanism is independent of specific programming languages, greatly improving code reusability, portability, and development efficiency. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a method for encapsulating inter-process communication attributes according to an embodiment of this application; Figure 2 A schematic diagram of the protected memory area inside the encapsulation interface provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for encapsulating inter-process communication attributes according to another embodiment of this application; Figure 4A flowchart illustrating a method for encapsulating inter-process communication attributes according to another embodiment of this application; Figure 5 A flowchart illustrating a method for encapsulating inter-process communication attributes according to another embodiment of this application; Figure 6 A flowchart illustrating a method for encapsulating inter-process communication attributes according to another embodiment of this application is shown. Figure 7 This is an internal structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] As the server's management unit, the Business Configuration Center (BMC) undertakes various critical functions during normal server operation, including heat dissipation, diagnostics, monitoring, and alarms, effectively ensuring the overall healthy and stable operation of the server. The BMC contains various functional modules, such as component monitoring, heat dissipation, upgrade management, and parameter management modules. Frequent data interactions exist between these modules; for example, the heat dissipation module needs to obtain temperature data from the component monitoring module, and the component monitoring module needs to obtain management parameters from the parameter management module. Common methods for data interaction between modules include pipes, shared memory, semaphores (built-in inter-process communication media in Linux systems), and D-Bus, commonly used in OpenBMC and desktop systems.

[0016] Currently, the interaction medium in OpenBMC is Dbus. Dbus provides a robust solution for inter-module interaction and decoupling through its signal, attribute, and method mechanisms. A built-in Dbus daemon facilitates data transfer from one module to another. Dbus is designed as a lightweight implementation, providing interfaces for various languages ​​such as C, C++, and Python. Dbus offers diverse interaction interfaces for different application processes, perfectly implementing Dbus's signal passing, attribute retrieval and updating, and method invocation functionalities.

[0017] Currently, there are three main types of D-bus applications: direct calls to the underlying D-bus interface, encapsulation based on D-bus parameters, and encapsulation based on language features.

[0018] The direct calling method of Dbus interfaces is to directly use the raw interfaces exposed by Dbus. These interfaces perfectly implement the setting and retrieval of Dbus properties, the registration of methods, the implementation of signals, etc. Using these raw interfaces, all the functions of Dbus can be realized, because no matter what form of encapsulation is used, it is all based on these basic library interfaces. The encapsulation based on Dbus parameters involves constructing a tree structure within the encapsulated interface based on the four types of Dbus parameters: ServiceName, Path, Interface, and Property. Memory space is allocated according to the data type of Property to store the values ​​under that Property. A tree-based key-value pair data structure is constructed to manage Dbus data (setting, querying, traversing, and other related operations). Hash algorithms and collision detection methods are used to balance the performance issues caused by string-based key names. Language-based encapsulation involves encapsulating Dbus's functional interfaces based on the language's specific features. For example, using C++'s overloading capabilities, assignment, copy, and other related operators and common object interfaces can be overloaded. Dbus operations can then be added to the overloaded functions, enabling Dbus property updates and signal broadcasts to be triggered when a variable is assigned a value.

[0019] The current development methods based on native interfaces, Dbus parameter-based encapsulation, and language feature-based encapsulation all have certain limitations, as described below: The development method using native interfaces has a long development cycle, poor code maintainability, and produces large binary files after compilation. The Dbus-related logic code developed in one functional module cannot be fully reused in another functional module, resulting in poor reusability. The encapsulation method based on Dbus parameters uses four types of Dbus parameters as key names for management. These four types of parameters are all string types. When performing operations such as traversal, search, and sorting, string management is relatively cumbersome. It also needs to be aware of the possibility of string collisions during hash operations. Therefore, this encapsulation method reduces the efficiency of Dbus and will affect the performance of the system and various functional modules to a certain extent. The encapsulation method based on Dbus parameters has a problem: when a memory overflow occurs in a developed functional module due to careless development, modifying any one of the Dbus4 elements in the key name can lead to an abnormal scenario where the functional module can still run, but the information on Dbus cannot be obtained, and the corresponding data change signal cannot be sent. Especially for this type of memory-related problem, a restart will restore it, but without a restart, there are no certain debugging methods, which leads to the risk of maintenance difficulties and increased maintenance costs. Moreover, this problem does not have a self-recovery mechanism and has poor stability. The D-Bus encapsulation method based on language features has certain limitations. For example, D-Bus encapsulation using C++ overloading features cannot be used in functional modules developed in C. Even if it is applied to functional modules developed in Java, the encapsulated interface needs to be redeveloped and debugged based on Java overloading features, resulting in poor scalability and reusability. The D-Bus encapsulation method based on language features has a relatively high internal encapsulation complexity and maintenance complexity in order to distinguish between ordinary assignment copy operations and assignment copy operations with D-Bus functionality, thus increasing maintenance costs.

[0020] In other words, directly using these system calls during implementation will make the upper-layer application extremely complex, especially when transmitting complex types of data. Directly using Dbus library functions will greatly reduce the portability and reusability of development, and will also significantly extend the module development cycle and affect product delivery time. Therefore, it is particularly important to properly encapsulate the various interfaces provided in the Dbus protocol, ensuring both the functional integrity of the encapsulated interfaces and the high efficiency of their execution.

[0021] To address the aforementioned technical issues, such as Figure 1 As shown, an embodiment of this application provides a method for encapsulating inter-process communication attributes, which specifically includes the following steps: Step 101: Create a protected memory area for encapsulating at least one inter-process communication attribute, the protected memory area including at least a first area for storing attribute metadata and a second area for storing attribute values.

[0022] In response to receiving an initialization call for the inter-process communication attribute to be encapsulated, the system obtains the definition information of the user data structure associated with the inter-process communication attribute to be encapsulated; based on the memory usage indicated by the user data structure definition information, it determines the required size of the second region for storing attribute values; based on the required size of the second region and the preset size of the first region for storing attribute metadata, it calculates the total size of the protected memory area; it configures the protected memory area in memory according to the total size; and it divides the configured memory area into the first region and the second region and initializes them.

[0023] A protected memory region is a memory area created by the operating system's memory management mechanism (such as mprotect) with strictly controlled access permissions, used to securely store data required for inter-process communication.

[0024] The first area (attribute metadata area) is part of the protected memory area, which is specifically used to store the description information of attributes, such as communication identification information such as service name, object path, interface name, attribute name, and the address mapping relationship of attributes in memory.

[0025] The second area (attribute value area) is another part of the protected memory area. It is a read-only mirror area of ​​the user data structure, used to securely store the actual numerical data of each attribute.

[0026] User data structure definition information: This refers to the type information and memory size of the raw data variables defined by the upper-level functional modules and to be encapsulated as inter-process communication attributes. It serves as a blueprint for constructing protected memory areas.

[0027] An initialization call is a request sent by a functional module to the encapsulation framework to establish a protected memory environment when the module starts up; it usually corresponds to a call to the Dbus interface.

[0028] When an initialization call for a set of inter-process communication attributes is received, the encapsulation framework initiates the construction process of the protected memory area. First, the framework obtains the definition information of the user data structure associated with the attribute to be encapsulated from the caller. This information clarifies the organization and memory footprint of the original data. Based on this, the framework calculates the required size of the second region for securely storing attribute values, a size that must perfectly match the memory layout of the user data structure. Simultaneously, the framework determines the size of the first region for storing attribute metadata (i.e., communication identifiers and address mapping information) according to preset rules. Adding these two together yields the total memory requirement for the entire protected memory area. Subsequently, the encapsulation framework requests a contiguous memory space of the appropriate size from the operating system and clearly divides it into two parts: the first region (attribute metadata area) and the second region (attribute value area). After division, these two regions are initialized, for example, by clearing their contents to zero, thus laying the foundation for subsequent attribute binding and secure access.

[0029] Step 102: Bind at least one inter-process communication attribute to a protected memory area, wherein the attribute metadata includes the communication identification information of the bound inter-process communication attribute and the storage location mapping relationship of the bound inter-process communication attribute in the second area.

[0030] Determine the communication identifier information of the inter-process communication attribute to be bound and the original address of the inter-process communication attribute in the user data structure; calculate the mapping address of the inter-process communication attribute to be bound in the second area based on the storage location; construct the memory address mapping relationship corresponding to the inter-process communication attribute to be bound based on the original address and the mapping address; store the communication identifier information and the memory address mapping relationship as attribute metadata of the inter-process communication attribute to be bound in the first area.

[0031] First, the encapsulation process needs to determine two key types of information about the inter-process communication attribute to be bound: one is the communication identification information used for external addressing (for example, in the D-Bus protocol, this is typically a combination of service name, object path, interface name, and attribute name); the other is the original address of the attribute in the user data structure instance, i.e., the specific memory location of the attribute value within its data structure. Then, based on the original address and the overall layout of the protected memory area, the mapping address of the attribute in the second area (i.e., the attribute value storage area) is derived through predetermined calculation rules (typically, mapping the offset of the original address relative to the starting address of the user data structure to the corresponding offset position in the second area). This mapping address is designed as a protected, normally read-only mirror storage location for the attribute value. Next, the original address and the mapping address are associated to construct a memory address mapping relationship specific to the attribute. Finally, the communication identification information is combined with this memory address mapping relationship to form the complete attribute metadata, and this metadata is stored in the reserved storage space in the first area of ​​the protected memory area (i.e., the attribute metadata area). After this step, the attribute is registered within the encapsulation management system. The encapsulation framework not only clearly defines its unique identifier in the inter-process communication network but also precisely determines the path for locating and synchronizing the attribute data within its internal data structure, thus laying a core foundation for subsequent secure and efficient attribute access and automatic data synchronization. This binding process can be repeated as needed to register multiple attributes one by one.

[0032] Step 103: Through the operating system's memory management interface, set the access permissions of at least the first region in the protected memory area to read-only in order to encapsulate attribute metadata.

[0033] In response to completing the binding of at least one inter-process communication attribute, a request is sent to the operating system kernel through the memory protection system call interface; the starting address, length, and target access permissions of at least the first region in the protected memory area are passed as parameters to the system call; wherein the target access permissions are specified to allow only reading, thereby causing the operating system kernel to refuse to perform write operations on at least the first region in the protected memory area.

[0034] The operating system's memory management interface is a set of application programming interfaces (APIs) provided by the operating system kernel to user-space programs for dynamically managing access permissions to virtual memory regions. In Linux systems, a typical example is the mprotect() memory protection system call.

[0035] The memory protection system call interface specifically refers to the low-level system calls used to implement memory access permission control. It acts as a bridge between user-space programs and the kernel memory management subsystem, allowing programs to request the kernel to modify the read, write, and execute permissions of specified memory pages.

[0036] Target access permissions refer to the permission flags set for the target memory region. In this application, this permission is specified to allow only reading, meaning that any write operations are prohibited.

[0037] Once at least one inter-process communication attribute has been successfully bound and its metadata has been stored in the first region, the encapsulation process triggers this protection mechanism. Specifically, it invokes a memory protection system call such as `mprotect()` through the operating system's memory management interface to send a formal permission setting request to the operating system kernel. In this request, the encapsulation process passes the precise range information of at least the first region within the protected memory area, including the region's starting memory address and length, along with explicit target access permissions, as parameters to the kernel. Upon receiving this request, the kernel marks the specified memory page as read-only in its underlying mechanisms, such as page table management. Once this operation takes effect, it is enforced by the operating system hardware mechanism. Any subsequent attempts to write to this read-only region will be detected and blocked by the CPU Memory Management Unit (MMU), typically triggering a segmentation fault signal. In this way, the attribute metadata (including all important communication identifiers and address mappings) stored in the first area is effectively encapsulated, and its integrity and reliability are guaranteed at the operating system level. This fundamentally eliminates the risk of metadata corruption caused by program errors such as memory out-of-bounds errors, thereby ensuring the stability and security of the entire inter-process communication attribute management framework.

[0038] In response to the determination that data needs to be written to the second area which is currently read-only, the access permissions of the protected memory area are temporarily modified to read-write via the memory management interface; in response to the completion of writing data to the second area which is currently read-only, the access permissions of the protected memory area are restored to read-only. The write operation includes an attribute synchronization operation that synchronizes attribute values ​​from the user data structure instance to the second area and / or an attribute update operation that updates attribute values ​​in the second area in response to external requests.

[0039] After initialization, this application sets the access permission of the first region (attribute metadata area) to read-only and maintains it at all times to absolutely protect critical communication identifiers and address mapping information from tampering. The second region (attribute value mirroring area) is read-only by default, but can be temporarily writable as needed. That is, it remains read-only as long as the mirrored original user data has not changed and no external write request has been received; write permissions are only temporarily granted when attribute synchronization or update operations are required. When the encapsulation logic determines that data needs to be written to the read-only second region (e.g., when it detects that the original user data has changed and synchronization is needed, or when a legitimate external attribute setting request is received), the system will not violate memory protection rules by forcibly writing. Instead, it initiates a rigorous temporary permission modification process. First, it calls the operating system's memory management interface again to request the kernel to temporarily modify the access permission of the corresponding part of the second region (usually at the memory page level) where the data to be written is located to read-write. This process must be extremely cautious and is often supplemented by a mutex lock mechanism to prevent data races or security vulnerabilities caused by concurrent access in the temporarily writable state. After the permission switch is successful, the encapsulation logic immediately performs the actual write operation. The write operation can specifically include attribute synchronization and attribute update operations. Attribute synchronization involves copying the latest values ​​of changed attributes from the user data area to the corresponding mapped addresses in the second area to maintain consistency between the mirror and the source data. Attribute update operations, in response to external requests, write the verified new attribute values ​​to the corresponding locations in the second area. Once the write operation is complete, the encapsulation logic immediately requests the kernel to restore the permissions of the relevant areas to read-only, striving to minimize the time window during which memory is writable. Thus, this application, while ensuring the absolute security of metadata in the first area and the constant protection of the numerical mirror in the second area, supports necessary data updates and synchronization, achieving a unified approach of high-strength security protection and business function availability at the system level.

[0040] Step 104: In response to receiving an access request for the target communication attribute, locate the position of the target communication attribute in the second area based on the attribute metadata in the first area, and perform the access operation corresponding to the access request type through the encapsulated interface.

[0041] Get the type of access request; in response to an access request being an attribute retrieval request, determine the mapping address of the target communication attribute in the second region based on the memory address mapping relationship in the attribute metadata; read the value of the target communication attribute from the mapping address of the target communication attribute in the second region and return it.

[0042] In response to an access request that is a property setting request, the system checks whether a custom processing function is pre-defined in the property metadata corresponding to the target communication property. If a custom processing function is pre-defined in the property metadata, the custom processing function is invoked to perform the custom setting operation. If no custom processing function is pre-defined in the property metadata, the system determines the original address of the target communication property in the user data area and its mapped address in the second area based on the storage location mapping relationship in the property metadata. The system temporarily modifies the access permissions of the area corresponding to the mapped address to read and write. The value in the original address is copied to the mapped address. The access permissions of the area corresponding to the mapped address are restored to read-only, and a property change notification is generated.

[0043] A target communication attribute is a specific inter-process communication attribute that is explicitly specified as the object of an operation in a particular access request. For example, in a Dbus call, it is the attribute that is identified by the service name, path, interface name, and attribute name.

[0044] Access request type refers to the fundamental purpose classification of access operations, mainly divided into two categories: attribute retrieval requests (query operations, such as Dbus's Get) and attribute setting requests (modification operations, such as Dbus's Set). The type determines the subsequent processing logic branch.

[0045] The encapsulation interface is a unified application programming interface provided by this encapsulation framework. It hides the complex internal details of memory protection, address mapping, and data synchronization from upper-layer callers, providing concise property access capabilities.

[0046] Defining a processing function refers to a callback function pointer that can be optionally registered by the property provider (user) during the property binding phase. When the property receives a setting request, if this function has been registered, the framework will call the user function instead of executing the standard numerical update process, thereby supporting complex business logic (such as hardware control, linkage operations, etc.).

[0047] Property change notifications are event signals generated and emitted by the encapsulation framework after a property value has been successfully modified (whether through a custom function or a standard procedure). Their purpose is to notify all listeners (subscribers) interested in this property that its value has changed.

[0048] When the encapsulation framework receives an access request for a specific target communication attribute, it first parses and obtains the type of the access request. This is the branching point in the entire processing logic.

[0049] For attribute retrieval requests (queries), based on the attribute metadata stored in the first area, the mapping address of the target attribute in the second area (read-only numeric mirror area) is quickly located. The value is then securely read from that address and returned to the requester. Since the second area is normally read-only, this read operation itself is secure and requires no permission changes.

[0050] For attribute setting requests (modifications), the processing logic is more complex and sophisticated. First, it queries the attribute metadata corresponding to the target attribute to determine if there are any pre-defined custom processing functions.

[0051] If a custom processing function is provided, the framework will call that function to perform the setting operation. This allows the property provider to inject complex business logic (such as driving hardware, updating associated states, logging, etc.), in which the framework acts as a safe and reliable messenger.

[0052] If no custom processing function is provided, the framework will execute the standard built-in value update process. This process includes several strict steps: First, based on the address mapping relationship in the attribute metadata, the original address of the target attribute in the user data area and its mapped address in the second area are determined simultaneously; next, according to established security specifications, the access permissions of the corresponding memory page in the second area are temporarily modified to read and write; then, the current value at the original address is copied to the mapped address to complete data synchronization; finally, the permissions are immediately restored to read-only to ensure that the protection mechanism is reinstated as soon as possible, and an attribute change notification is generated to inform relevant parties that the data has been updated.

[0053] In this way, not only is a secure and efficient universal path provided for attribute access, but also powerful business expansion capabilities are reserved through the custom processing function mechanism, enabling upper-layer applications to flexibly implement diverse business needs on a robust security foundation.

[0054] In one embodiment, in response to receiving a segmentation fault signal triggered by the operating system kernel due to illegal writing to a protected memory area, a preset exception handling procedure is executed; wherein, the exception handling procedure includes restarting a service or process that depends on the protected memory area.

[0055] Unauthorized write refers to any act that fails to comply with the security protocols defined in this encapsulation framework (such as not modifying the process through temporary permissions) and attempts to directly perform a write operation on a protected memory area that has been set to read-only (including the first area or the second area under normal conditions).

[0056] A segmentation fault signal is a specific signal (such as SIGSEGV) that is actively triggered by the kernel and sent to the process that caused the error when the operating system's memory management unit (MMU) detects an illegal memory access (such as writing to read-only memory). It is a notification at the software level of the hardware-level memory protection mechanism.

[0057] The pre-defined exception handling process is a set of systematic response procedures predefined and registered by the encapsulation framework, which are automatically executed when severe exception signals such as segmentation faults are detected. Its core objective is to isolate faults, restore services, and ensure the overall robustness of the system.

[0058] Services or processes that depend on protected memory areas refer to functional entities that use this encapsulation framework to manage their inter-process communication attributes. Their normal operation relies on the integrity and accessibility of data in the protected memory areas.

[0059] When an illegal write operation occurs due to program defects (such as pointer errors or buffer overflows) or malicious attacks, attempting to tamper with a read-only protected memory area, the operating system's hardware memory protection mechanism immediately intervenes, triggering a segmentation fault signal. The encapsulation framework captures this signal through pre-registered signal handling functions. Instead of simply logging or crashing, the framework executes a pre-defined exception handling process. The primary analysis in this process is determining whether the exception truly stems from illegal access to the protected memory area. Once confirmed, the service or process dependent on that protected memory area is restarted. On one hand, by forcibly restarting, unpredictable or unsafe states that might arise from accidental memory tampering are eliminated, ensuring a clean starting point for business logic. On the other hand, the restart process re-executes the complete initialization and binding process, thereby achieving self-healing of the protected memory area data at the service level, restoring it from a defined initial state. This significantly improves the system's fault tolerance and service continuity in the face of memory-related errors, upgrading from passive protection to proactive recovery capabilities.

[0060] In one implementation, in response to determining that the value of a bound attribute in a user data structure instance has changed, the value of the corresponding attribute in the second region is compared with that in the user data structure instance; if there is a difference, the value in the user data structure instance is synchronized to the second region, and an attribute change notification is generated.

[0061] A user data structure instance refers to a specific variable entity (such as the global variable Test) created in memory based on the user data structure definition. It is the original, readable and writable area where upper-layer application logic directly reads and writes business data.

[0062] The bound attributes specifically refer to those attributes that have completed the registration within the encapsulation framework and established complete attribute metadata through the binding process in step 102, enabling inter-process communication.

[0063] Active synchronization refers to a data consistency maintenance process initiated and driven by the encapsulation framework. Its direction is from the user data structure instance (source) to a second region (mirror), which differs from update operations responding to external requests.

[0064] Property change notification is an event message generated and published by the encapsulation framework after data synchronization is complete, used to inform all subscribers that the value of the property has changed.

[0065] To ensure that attribute values ​​exposed through inter-process communication always reflect the latest state of internal data in a timely manner, this application sets up a mechanism where, when a change is detected in the value of a bound attribute in a user data structure instance, the current value of that attribute in the user data structure instance is read and compared with the existing mirror value stored in the second area. Substantive synchronization is only initiated if a difference exists. Specifically, the permissions of the corresponding part in the second area are temporarily modified to writable, the new value is copied from the user data structure instance to the corresponding mapping address in the second area, and then read-only permissions are immediately restored. After synchronization is complete, the framework generates and publishes an attribute change notification. This decouples data updates and communication state maintenance from business logic. Developers only need to focus on modifying business data, while attribute value synchronization and change broadcasting are automatically and reliably handled by the framework, greatly simplifying development and ensuring the consistency, real-time performance, and reliability of external interface data.

[0066] In one implementation, in response to receiving a registration request for an inter-process communication method processing function, the user-provided callback function is associated with and registered with a method identifier; in response to receiving a call to the registered method identifier, the associated callback function is executed.

[0067] Inter-process communication method handling functions are callback functions implemented by the user to execute the specific logic of the action.

[0068] A method identifier is a string or symbol used in inter-process communication protocols to uniquely identify a method that can be called remotely. It is usually composed of elements such as service name, path, interface name, and method name.

[0069] Association registration refers to the process of establishing and recording the binding relationship between method identifiers and user-provided callback functions within the encapsulation framework. After registration, the framework knows which function to forward the call to when it receives a call to that method identifier.

[0070] Triggered execution refers to the process by which the encapsulation framework, upon receiving a call request for a registered method identifier through an inter-process communication mechanism (such as Dbus), locates and invokes the associated user callback function.

[0071] This application allows users to register any user-implemented callback function with a specific method identifier within the framework through a registration request, thus securely storing and managing this relationship.

[0072] Subsequently, when an external entity initiates a call to the method identifier via a standard inter-process communication mechanism (such as sending a Dbus method call message), the request is first received by the encapsulation framework. Instead of directly exposing the user function, the framework acts as a secure proxy and scheduler: based on the method identifier in the request, it quickly looks up the internal registry to find the associated user callback function, and then triggers the execution of that function in a controlled environment.

[0073] In this way, the complex semantics of inter-process communication method calls (such as parameter encoding / decoding, routing, and permission checks) are clearly separated from the implementation of pure business logic. Users only need to focus on implementing the core functionality of the method (callback functions), while all communication-level details, including request reception, parsing, routing, and security management of the execution environment, are transparently handled by the encapsulation framework. This not only significantly reduces the complexity of implementing remote methods but also ensures that all method calls registered through the framework inherit the framework's underlying memory safety protection and unified robustness management, achieving a dual improvement in security and development efficiency.

[0074] This application innovatively integrates operating system-level proactive memory protection mechanisms with the attribute management layer of inter-process communication (such as D-Bus). Specifically, firstly, this application pioneers a design that constructs a dedicated protected memory area for inter-process communication attributes. This area is clearly divided into a first area storing communication identifiers (metadata) and a second area storing attribute values ​​(data). This design is not a simple memory allocation, but rather directly maps the logical structure of communication attributes (identifiers and values) to the protected layout of physical memory, achieving an atomic binding between communication semantics and the memory safety model. This provides a precise target for subsequent implementation of operating system-level proactive protection.

[0075] Secondly, unlike related technologies that only perform logical verification or passive defense at the application layer, the core innovation of this application lies in actively invoking the operating system's memory management interface (such as mprotect) to forcibly set the protected memory area carrying critical communication data to read-only access. This means that any attempt to tamper with inter-process communication attribute metadata (such as D-Bus service name, object path, etc.)—whether it's a memory overflow caused by a program defect or a malicious attack—will be intercepted and prevented in real time at the hardware / operating system level (triggering a segmentation fault), rather than being discovered afterward at the application logic layer. This eliminates the risk of communication identifier corruption at its source, providing a hardware-enforced security guarantee that is unparalleled by related technical solutions.

[0076] Furthermore, based on the aforementioned protected memory layout, this application designs an efficient attribute access mechanism. When an attribute needs to be accessed, the framework does not require time-consuming lookups, hash calculations, and collision handling as traditional solutions based on string keys or complex data structures. Instead, it directly uses the pre-defined, read-only protected "address mapping" in the first area to instantly locate the numerical image of the target attribute in the second area, much like pointer addressing. This "direct access via memory address mapping" mode reduces the overhead of attribute management to near-direct memory access levels. Moreover, because it is based on address calculation rather than string processing, it inherently possesses language independence. Any language capable of pointer operations (such as C, C++, etc.) can seamlessly reuse this efficient and secure encapsulation framework, completely solving the problems of poor portability and high reuse costs caused by reliance on specific language features (such as C++ overloading) in related technologies.

[0077] In one feasible implementation, in response to a system sleep or low-power wake-up event, all attribute metadata stored in the first region is traversed; for each attribute, the current value of the attribute is read from the user data area based on the original address recorded in its storage location mapping relationship; the read current value is synchronized to the corresponding mapping address in the second region to restore the consistency of the attribute value mirror in the protected memory area.

[0078] System hibernation or low-power wake-up events refer to system-level events triggered when a computing device resumes from a low-power, inactive saved state (such as ACPI's S3 sleep or hibernation to disk) to a fully operational state. During this process, the contents of volatile memory (DRAM) may be lost due to power failure or recovered by the system from other storage media.

[0079] When the system wakes up from a low-power state such as hibernation, although the operating system kernel and application processes resume execution, the data state of the protected memory area (especially the second area) maintained by this encapsulation framework in volatile memory (RAM) may face two risks. One is that in the scenario of hibernation to disk, the content of this area is in a completely new initialized state; the other is that after being suspended to memory, although the content of this area is retained, some attribute values ​​in the user data area may have been modified by the driver or hardware before hibernation, causing the mirrored data to lag behind the real source data. To address this, an automated state reconstruction mechanism is set up. It responds to the system wake-up event and actively initiates the recovery process. By traversing all attribute metadata stored in the first area, this is equivalent to obtaining a list of all registered attributes. For each attribute in the list, the framework uses the storage location mapping relationship recorded in its metadata to find the original address of the attribute in the user data area and reads the current authoritative value of the attribute from that address. Subsequently, the framework synchronizes this latest value to the corresponding mapped address in the second area through a secure write process. Through the above operations, after the system wakes up and before external requests arrive, the consistency between the attribute value mirror in the protected memory area and the real data source is proactively and in batches rebuilt. This completely eliminates the risk of outdated or incorrect data on external interfaces due to power state switching, ensuring that all exposed inter-process communication attributes can immediately provide accurate values ​​upon system wake-up. This not only greatly improves the robustness and user experience of the system in power management scenarios but also demonstrates the completeness of this encapsulation framework in terms of full lifecycle state management.

[0080] The aforementioned method for encapsulating inter-process communication attributes can be implemented in practical Dbus-based systems such as OpenBMC as a Dbus attribute encapsulation interface method based on a memory protection mechanism. The design and implementation of this method heavily relies on and cleverly utilizes the following capabilities provided by the underlying operating system: First, through system calls such as `mprotect`, access permissions for specific memory regions can be dynamically set and modified at the application layer (e.g., set to read-only or read-write); second, any write operation that violates permissions (e.g., writing to a read-only region) will be intercepted by the hardware memory management unit (MMU) and trigger the operating system kernel to send signals such as segmentation faults, which can be captured and handled by user-space preset signal handling functions; finally, the core of Dbus communication—the broadcasting of attribute update and change signals—is essentially data-driven and only needs to be executed when the actual value of the attribute changes.

[0081] To transform the above abstract methods into concrete, usable development tools, this solution designs a set of core encapsulation interfaces, aiming to hide all the complex details of D-Bus protocol interaction, memory safety management, and data synchronization from developers of upper-layer functional modules. These interfaces are designed based on the principle of simplicity and ease of use, and mainly include the following four: 1. `dbus_init(p, size)`, also known as the Dbus initialization interface. This interface is the entry point for the framework startup. The parameter `p` is the starting memory address of the data structure instance (usually a global structure variable) defined by the upper-layer functional module, which centrally manages all data variables that need to be exposed; `p` here is a pointer to this structure. The parameter `size` is the memory footprint of this data structure. After calling this interface, the encapsulation framework will internally allocate a contiguous block of memory as a protected memory area based on `size`. This area is clearly divided into an attribute metadata area (corresponding to the first area mentioned above) and an attribute value mirror area (corresponding to the second area mentioned above). The size and layout of the value mirror area are completely consistent with the user data structure pointed to by the passed-in `p`. The framework initializes this protected memory area to all zeros and immediately calls `mprotect` to set the access permissions of its entire area to read-only, thereby completing the construction of the secure container.

[0082] Please refer to the example memory region partitioning. Figure 2 As shown in the figure, the protected memory area created inside the Dbus encapsulation interface is logically divided into two parts: a read-only attribute area and a read-only data area. The read-only attribute area stores the metadata of each registered attribute. Each record contains the four Dbus elements of the attribute (Service name, Path, Interface name, Property name), its original memory address RwAddr in the user data area, its mirror address (memory address in the built-in data area) RoAddr in the read-only data area, and its data type Type. The read-only data area is a read-only mirror of the user data structure, used to securely store the actual values ​​of each attribute.

[0083] Internally, the interface calls native Dbus library functions to connect to the Dbus (inter-process communication system) daemon and start message listening. The internal implementation logic of this interface is as follows: Figure 3The flowchart shown illustrates the process as follows: After the process begins, the passed pointer `p` and size `size` are first verified for validity. `p` must be a non-null pointer, and `size` must be greater than zero. If invalid, an error is returned. If valid, memory space is allocated based on `size` (usually rounded up to an integer multiple of the memory page size). If memory allocation fails, an error is returned. If allocation is successful, the entire allocated memory region (i.e., the future attribute metadata area and value mirror area) is initialized to 0. Subsequently, the `mprotect` (memory protection) system call is invoked to set the access permissions of this newly initialized memory region to read-only. This is a crucial step in establishing the initial security protection state. Finally, the Dbus (inter-process communication system) native interface is called to connect to the Dbus daemon and start listening, ending the process.

[0084] 2. `dbus_proper_bind(service, path, interface, property, p, type, m, default)` is the D-Bus property binding interface. This interface is used to "declare" and "register" a specific business data variable as a property accessible through D-Bus. The parameters `service` (service name), `path` (object path), `interface` (interface name), and `proper` (property name) together constitute the unique communication identifier of this property on the D-Bus bus (i.e., the aforementioned "D-Bus four elements"). The parameter `p` is the memory address of the specific member variable of this property in the user data structure (i.e., the structure passed in `dbus_init`), that is, its "original address," which is a pointer to the specific member variable. The parameter `type` specifies the data type of this property. The parameter `m` is an optional function pointer used to specify the custom processing function that should be called when an external request to set this property is made through D-Bus; if the property is read-only, this parameter can be NULL. The parameter `default` specifies the initial default value of this property.

[0085] The internal implementation logic of this interface follows Figure 4 The flowchart shown below details the specific steps: Step 1 (Parameter Validation and Address Mapping): First, validate the validity of the input parameters. Then, based on the starting address p_start of the user data structure recorded during dbus_init and the address p of the variable being bound, calculate the offset = p - p_start. Next, based on the starting address RoStart of the value mirror area in the protected memory area, calculate the "mapping address" RoAddr = RoStart + offset of the attribute value in the mirror area. Simultaneously, record the user area address RwAddr = p.

[0086] Step Two (Metadata Writing and Protection): Locate a free metadata storage slot in the attribute metadata area. Temporarily call `mprotect` to modify the permissions of the local memory page containing the free slot to read and write. Then, completely fill the metadata slot with the calculated RoAddr, RwAddr, data type, Dbus four-element string, and the custom setting function pointer `m`, forming the complete "attribute metadata". After filling, immediately call `mprotect` again to restore the permissions of the aforementioned memory page to read-only to protect the written metadata.

[0087] Step 3 (Initial Value Synchronization and Bus Registration): Write the default value (default) to the value mirror area pointed to by RoAddr. This operation also follows a strict security procedure: First, temporarily call mprotect to change the permissions of the memory page where RoAddr is located to read and write; then write the default value; immediately after writing, restore the read-only permissions of the page. Finally, call the Dbus native interface to formally register this property to the Dbus daemon and associate two callbacks for this property: one is the framework's built-in general "property retrieval" function, and the other is the user-provided (if existing) custom "property setting" function m.

[0088] In addition, the framework has a built-in generic "property retrieval" callback function, the logic of which is as follows: Figure 5 The flowchart shown illustrates how this function is triggered when an external entity initiates a property query (GET) request via Dbus. The process is as follows: Based on the four Dbus elements (service name, path, interface name, and property name) carried in the request message, the function iterates through the property metadata area and performs string matching. If a match fails, an error is returned. If a match is successful, the mirror address RoAddr and data type type of the property in the read-only data area are extracted from the matched metadata record. Subsequently, since the area containing RoAddr is always in a read-only protected state, data can be safely read directly from it, and the data is encapsulated into a Dbus response message based on the type and returned to the requester. The entire process requires no modification to memory permissions, making it efficient and secure.

[0089] `dbus_method_bind(service, path, interface, property, m)` is the D-Bus method binding interface. This interface is used to register D-Bus methods that can be invoked remotely. The parameters `service`, `path`, `interface`, and `proper` (where `proper` actually represents the method name) collectively identify the method. The parameter `m` is a pointer to the callback function corresponding to the user-implemented method logic. The internal implementation of this interface is as follows... Figure 6The flowchart shown illustrates the process: After the process begins, the incoming parameters are first validated, including verifying that the function pointer `m` is not null and points to a valid function entry point. If the validation fails, an error is returned. If the validation passes, the native Dbus interface is directly called to bind and register the callback function (method) pointed to by the user-provided pointer `m` with the specified method identifier (composed of four elements). After registration, when the Dbus daemon receives a call request for this method, it can correctly route and execute the callback function.

[0090] `dbus_trigger(p)` is the DBus attribute update trigger interface. This interface serves as a bridge between internal business data changes and external DBus communication status updates. When the upper-layer application logic modifies the value of a bound attribute in the user data structure, this interface needs to be called to notify the encapsulation framework. The parameter `p` is a pointer to the address of the specific member variable that has been changed (i.e., `RwAddr`); if `NULL` (null pointer) is passed, the framework will perform consistency checks and synchronization on all bound attributes.

[0091] The internal implementation logic of the Dbus property update trigger interface specifically includes two processing paths: Path 1: The input parameter p is a non-null pointer (for targeted updates of a single attribute). Parameter p is a pointer to the memory address of the original data variable of the attribute already bound in the user functional module within the user data area. Specifically, when the upper-layer application modifies a business variable (e.g., executing the operation Test.PowerStatus=1), it needs to pass the address pointing to that variable (i.e., &Test.PowerStatus) as a parameter to this interface. This address is already recorded in the attribute metadata as RwAddr (read / write address, i.e., the location of the attribute in the user-readable and writable business data area) during attribute binding.

[0092] The specific process is as follows: The framework first traverses the attribute metadata area, searching for a record where the value of the RwAddr field completely matches the passed pointer p. If no matching record is found, it indicates that the passed address p has not been registered as an attribute, and the interface will return an error. If a matching record is found, the current value of the user data area pointed to by RwAddr in the record is compared with the old value stored in the read-only data area (mirror area) pointed to by RoAddr (read-only address, i.e., the read-only mirror address of the value corresponding to RwAddr in the protected memory area). If the two values ​​are the same, it indicates that although the business data has been assigned a value, the new value is consistent with the original mirror value, and no substantial change has occurred. The process ends directly without further operation. If the two values ​​are different, the secure data synchronization process is initiated: First, the mprotect system call is called to temporarily modify the access permissions of the memory page where RoAddr is located to read and write; then, the new attribute value is copied from the user data area pointed to by RwAddr to the corresponding location in the read-only data area pointed to by RoAddr; then, mprotect is called again immediately to restore the permissions of the memory page where RoAddr is located to read-only. Once data synchronization is complete, the framework sends a Properties Changed Signal via the Desktop Bus (Dbus) to notify all client modules that have subscribed to the signal.

[0093] Path 2: Pass in a null pointer as parameter p (batch check and update). When parameter p is NULL (i.e., a special value representing a "null pointer" in C / C++), it is an explicit instruction that requires the framework to check and synchronize all bound properties, rather than specifying a single property.

[0094] The specific process is as follows: The framework sequentially traverses all records in the attribute metadata area. For each attribute record, it performs the same numerical comparison and conditional synchronization operations as in Path 1, i.e., comparing the values ​​pointed to by the attribute RwAddr and RoAddr. Only when a discrepancy is found is a complete "temporary privilege escalation - data copy - privilege restoration" secure write process triggered for that attribute, and the corresponding attribute change signal is sent immediately after synchronization is complete. For attributes with consistent numerical comparisons, all update and signal sending steps are skipped. This mode is suitable for scenarios where a single business operation causes multiple attributes to change simultaneously. After modifying all relevant variables, developers can call dbus_trigger (desktop bus trigger interface) once, and the framework will intelligently complete all change detection, data synchronization, and signal broadcasting, thereby effectively reducing unnecessary function calls and network overhead and improving system efficiency.

[0095] In one specific implementation, the method for encapsulating inter-process communication attributes provided in this application includes the following steps: S0: The functional module starts. Within this module, a global structure variable is defined. All members of this structure variable are a set of D-Bus (an inter-process communication mechanism) attributes; that is, the memory variables corresponding to the D-Bus attributes are a subset of the memory variables of all members in the structure variable. For ease of description, the corresponding structure is set to STRUCT_TEST, and the corresponding structure variable is set to Test, i.e., STRUCT_TESTTest is defined.

[0096] S1: Functional module initialization. The `dbus_init` wrapper interface (i.e., the D-Bus initialization interface) is called, passing in the address of the corresponding `Test` (i.e., pointer `&Test`) and the size of the `STRUCT_TEST` structure. The calling method is to call the `dbus_init` interface, passing in the address of the `Test` structure variable (`&Test`) and the size of the `STRUCT_TEST` structure (`sizeof(STRUCT_TEST)`) as parameters. At this point, a read-only memory region is automatically constructed within the wrapper interface. The read-only attribute area (first area) is empty, and the size and layout of the read-only data area (second area) are completely consistent with the size and layout of the passed-in `Test` memory region. Furthermore, it has connected to the D-Bus daemon and started listening for D-Bus.

[0097] S2: Based on the needs of this functional module, bind the required properties and their corresponding variable addresses to D-Bus. That is, call `dbus_proper_bind` (the D-Bus property binding interface) to bind the four elements of D-Bus for this functional module to the address of a variable in `Test`. For example, `Test` has a member variable named `PowerStatus`, with an integer data type, and its corresponding four D-Bus elements are: ServiceName, ObjectPath, InterfaceName, and PropertyName. This D-Bus property is read-only by other functional modules and cannot be set.

[0098] If the registered attribute corresponding to this functional module needs to be set externally, a callback function needs to be defined inside the functional module. This callback function implements the operation to be performed when other functional modules set the attribute (e.g., sending a command to the hardware CPLD), and passes the function pointer of this function to the last parameter of the dbus_proper_bind encapsulation interface.

[0099] S3: If this functional module has methods that need to be called by other functional modules, define a callback function in the function and call dbus_method_bind (i.e., the D-Bus method binding interface) to bind the callback function pointer to the corresponding D-Bus method identifier. In this way, when other functional modules call the registered method, they can call the callback function to perform the relevant operations.

[0100] S4: Execute other functions of this module. When a member variable (i.e., a bound property) in Test changes, the corresponding Test member is assigned a value, and the encapsulated interface dbus_trigger(p) (i.e., the D-Bus property update trigger interface) is called to trigger the property update on the D-Bus and send the corresponding signal. The parameter p passed in at this time should be the address (pointer) of the member variable that has changed, for example, &Test.PowerStatus.

[0101] S5: When multiple variables in Test change, there are two implementation methods: one is to call dbus_trigger(p) for each member variable (i.e., pass in the address of a specific variable), and call it multiple times to achieve the purpose of updating each attribute and sending a signal; the other method is to directly call dbus_trigger(NULL) (pass in a null pointer) to update the value of all attributes and automatically send the corresponding changed attribute to other functional modules.

[0102] Thus, the Dbus attribute encapsulation based on memory protection can modify the attributes of non-designed memory regions within the encapsulation interface to read-only via the Linux system call `mprotect`, which is normally a read-only region. This ensures that the four elements of Dbus are not affected by memory out-of-bounds issues in other logic, resulting in strong stability, robustness, and high security. Furthermore, when a memory region within the corresponding encapsulation interface experiences memory out-of-bounds overwriting, because it is a read-only region, it will trigger operating system signals such as a segmentation fault. This functional module can restart and recover, ensuring both the reliability of data in memory and the self-recovery capability of the functional module.

[0103] The encapsulation implementation in this application uses system-level calls and native Dbus library interface calls, independent of the specific programming language of the corresponding functional module, thus possessing strong versatility (corresponding to the beneficial effect of language independence). Furthermore, this application uses a reverse derivation method by comparing memory addresses to derive the four elements of Dbus. Compared to existing methods that use tree structures and the four elements of Dbus as string keys for traversal and searching, this approach is more efficient and avoids complex hash algorithms and string collision issues. The solution is simple, efficient, and possesses strong characteristics of lightweight encapsulation.

[0104] The encapsulation interface in this application is relatively simple. It implements a series of Dbus-related functions, such as attribute updating, attribute retrieval, signal broadcasting, method registration, and invocation, using only four encapsulation interfaces. This simplifies the development of related functional modules, shortens the development cycle and product delivery time, and enhances the product's market competitiveness. This solution completely encapsulates the complex native Dbus interface, eliminating the need for upper-level developers to understand the specific details of the encapsulation or the specific logic of Dbus. It has a low barrier to entry, is easy to learn, and can be quickly deployed to the development of various functional modules. Furthermore, this solution improves the reusability and portability of functional modules. Due to the language-independent nature of the encapsulation interface, functional modules using this solution can be easily ported to other systems, resulting in high reusability.

[0105] Embodiments of this application also provide an electronic device, such as... Figure 7 As shown, it includes a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in any of the above-described methods for encapsulating inter-process communication attributes.

[0106] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the encapsulation method for inter-process communication attributes at runtime.

[0107] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), mobile device, magnetic disk, or optical disk.

[0108] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0109] The above provides a detailed description of a method for encapsulating inter-process communication attributes provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for encapsulating inter-process communication attributes, characterized in that, The method includes: Create a protected memory area for encapsulating at least one inter-process communication attribute, the protected memory area including at least a first area for storing attribute metadata and a second area for storing attribute values; At least one inter-process communication attribute is bound to the protected memory area, wherein the attribute metadata includes communication identification information of the bound inter-process communication attribute and the storage location mapping relationship of the bound inter-process communication attribute in the second area. By using the operating system's memory management interface, the access permissions of at least the first region in the protected memory area are set to read-only in order to encapsulate the attribute metadata; In response to determining that data needs to be written to the second area which is currently under read-only access, the access permissions of the protected memory area are temporarily modified to read-write via the memory management interface; In response to completing the writing of data to the second area which is currently in read-only access, the access permission of the protected memory area is restored to read-only; wherein, the writing of data is an attribute synchronization operation that synchronizes attribute values ​​in the user data structure instance to the second area and / or an attribute update operation that updates attribute values ​​in the second area in response to an external request; In response to receiving an access request for a target communication attribute, the location of the target communication attribute in the second region is determined based on the attribute metadata in the first region, and an access operation corresponding to the access request type is executed through the encapsulated interface.

2. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, The creation of the protected memory area for encapsulating at least one inter-process communication attribute includes: In response to receiving an initialization call for the inter-process communication attribute to be encapsulated, the definition information of the user data structure associated with the inter-process communication attribute to be encapsulated is obtained; Based on the memory usage indicated by the user data structure definition information, determine the required size of the second region used to store attribute values; Calculate the total size of the protected memory area based on the required size of the second region and the preset size of the first region used to store attribute metadata. Configure the protected memory area in memory according to the total size; The configured memory area is divided into the first region and the second region and initialized.

3. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, The step of binding at least one inter-process communication attribute to the protected memory area includes: Determine the communication identifier information of the inter-process communication attribute to be bound and the original address of the inter-process communication attribute in the user data structure; Calculate the mapping address of the inter-process communication attribute to be bound in the second region based on the storage location; Based on the original address and the mapped address, construct the memory address mapping relationship corresponding to the inter-process communication attributes to be bound; The communication identification information and memory address mapping relationship are stored as attribute metadata of the inter-process communication attributes to be bound in the first area.

4. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, Setting the access permission of at least a first region in the protected memory area to read-only to encapsulate the attribute metadata includes: In response to completing the binding of at least one inter-process communication attribute, a request is sent to the operating system kernel via the memory protection system call interface; The starting address, length, and target access permissions of at least the first region in the protected memory area are passed as parameters to the system call; The target access permission is specified to allow only reading, thereby causing the operating system kernel to refuse write operations to at least the first region in the protected memory area.

5. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, The step of responding to a received access request for a target communication attribute, locating the target communication attribute in the second region based on the attribute metadata in the first region, and performing an access operation corresponding to the access request type through an encapsulated interface includes: Get the type of access request; In response to the access request being an attribute retrieval request, the mapping address of the target communication attribute in the second region is determined based on the memory address mapping relationship in the attribute metadata; Read the value of the target communication attribute from the mapping address of the target communication attribute in the second region and return it; In response to the access request being an attribute setting request, determine whether a custom processing function is preset in the attribute metadata corresponding to the target communication attribute; If a custom processing function is pre-set in the attribute metadata corresponding to the target communication attribute, then the custom processing function is called to perform the custom setting operation; If no custom processing function is preset in the attribute metadata corresponding to the target communication attribute, the original address of the target communication attribute in the user data area and the mapped address in the second area are determined based on the storage location mapping relationship in the attribute metadata. Temporarily change the access permissions of the region corresponding to the mapped address to read and write; Copy the value from the original address to the mapped address; Restore the access permissions of the region corresponding to the mapped address to read-only and generate an attribute change notification.

6. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, The method further includes: In response to receiving a segmentation fault signal triggered by the operating system kernel due to illegal writing to the protected memory area, a preset exception handling procedure is executed; The exception handling process includes restarting services or processes that depend on the protected memory area.

7. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, The method further includes: In response to a change in the value of a bound attribute in a user data structure instance, the second region is compared with the value of the corresponding attribute in the user data structure instance. If discrepancies exist, the values ​​in the user data structure instance are synchronized to the second region, and an attribute change notification is generated.

8. The method for encapsulating inter-process communication attributes according to claim 1, characterized in that, The method further includes: In response to receiving a registration request for an inter-process communication method handling function, the user-provided callback function is associated with and registered with the method identifier; In response to receiving a call to a registered method identifier, the associated callback function is executed.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, used to implement the encapsulation method of inter-process communication attributes as described in any one of claims 1 to 8 when executing the computer program.

Images