An rfc security execution method and system based on runtime dynamic proxy

Abstract

This invention discloses a method and system for secure execution of RFCs based on runtime dynamic proxies. The method includes the following steps: acquiring data containing call instructions and parameters to be processed and converting it into a strongly typed data structure; extracting memory usage characteristics and nesting complexity to calculate a safe memory threshold; allocating a virtualized execution stack with physical boundaries in the host process according to the threshold; dynamically generating a temporary proxy object within the stack by invoking a memory reflection mechanism and configuring shared memory access permissions for the execution stack; performing memory offset and pointer boundary checks on the parameters through the temporary proxy object; isolating and running the call instructions within the virtualized execution stack after successful checks; and destroying the proxy object and forcibly reclaiming physical memory space by overwriting it with all zeros in response to execution completion or an exception. This invention achieves function-level sandbox isolation that is destroyed upon use, preventing host process crashes and data leaks caused by malicious RFC calls at the underlying physical memory level.

Description

Technical Field

[0001] This invention belongs to the field of computer information security and electronic digital data technology, and specifically relates to an RFC secure execution method and system based on runtime dynamic agent. Background Technology

[0002] With the popularization of distributed computing and microservice architecture, RFC (Remote Function Call) has become a core mechanism for business collaboration across processes or network nodes. RFC allows a program to request the execution of a function or procedure running in another address space without knowing the underlying network details.

[0003] In traditional server-side architectures, security defenses are often concentrated at the network transport layer. However, once existing RFC calls pass through the network firewall and enter the host machine, they typically undergo deserialization within the application and are executed directly via pointer addressing to the target function. This conventional execution mechanism has serious security vulnerabilities: because the main thread lacks runtime execution context isolation when calling remote functions, if the passed RFC parameters are maliciously crafted, it is extremely easy to cause memory buffer overflows or logical infinite loops during deserialization or execution, leading to the crash of the entire host process, or even the hijacking of control flow by attackers.

[0004] To address the security issues of remote function calls, several hardware-isolated solutions have been proposed in the industry. For example, Chinese invention patent application CN115964103A discloses a method for remote function calls in secure applications based on the TEE specification. This method involves the client application calling TEEC_InvokeCommand, allowing the secure application to back up the entry function context. When a remote function call is required, the application encapsulates the parameters and backs up the interrupt function context, thus enabling the secure application to use functions within the rich execution environment via remote calls.

[0005] However, the aforementioned existing technologies still have the following significant drawbacks in practical industrial applications: The solution heavily relies on the Trusted Execution Environment (TEE, such as ARM TrustZone) provided by the underlying chip. For conventional business systems deployed on ordinary cloud servers or heterogeneous computing platforms, the modification cost is extremely high, and lightweight deployment cannot be achieved through pure computer memory management mechanisms. Fine-grained verification is not performed on the complexity of the input parameters themselves and the characteristics of memory threats. When faced with memory overflows caused by malformed parameters, the traditional fixed-size execution stack still cannot provide effective physical blocking. After the call ends, it typically only returns the call result, without performing low-level full-zero overwriting and forced reclamation of register states and memory-resident data generated during function execution, resulting in a high risk of runtime data residue and theft.

[0006] Therefore, there is an urgent need in the field for a method that does not rely on a specific hardware TEE environment and can shrink the security defense boundary from the network layer to the memory processing and execution logic inside the host. How to completely isolate malicious function calls at the pure electrical digital data processing level by dynamically generating proxy objects, performing strong type and memory boundary checks on parameters, and allocating a virtualized execution stack on demand for each RFC call, thereby completely isolating malicious function calls at the pure electrical digital data processing level, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] This invention provides a method and system for secure execution of RFCs based on runtime dynamic proxies. By dynamically allocating a virtualized execution stack with memory-protected pages based on the complexity of input parameters at the pure software level, and using underlying bytecode enhancement to generate temporary proxy objects to implement fine-grained memory offset verification, and by bypassing the regular stack frame execution register clearing and physical page overwriting when the call terminates, it aims to solve the problems of existing remote function call mechanisms lacking runtime context isolation after penetrating network layer firewalls. These mechanisms are prone to memory buffer overflows and arbitrary address read / write due to maliciously constructed malformed parameters, which can lead to host process crashes, system resource exhaustion, or illegal control flow hijacking.

[0008] To address the aforementioned technical problems, this invention proposes a method for secure execution of RFCs based on runtime dynamic proxies, comprising the following steps: Obtain data containing call instructions and parameters to be processed, convert it into a strongly typed data structure, and extract memory usage characteristics and nesting complexity. Calculate the safe memory threshold based on the memory usage characteristics and nesting complexity, and allocate a virtualized execution stack with physical boundaries in the host process according to the safe memory threshold; The memory reflection mechanism is invoked to generate a temporary proxy object within the virtualized execution stack, and the shared memory access permissions for the execution stack are configured based on the strongly typed data structure. The temporary proxy object performs memory boundary verification on the parameters to be processed. If the verification passes, the calling instruction is executed in isolation within the virtualization execution stack. In response to the end of execution or the interception of an out-of-bounds exception, the temporary proxy object is destroyed and the physical memory space of the virtualized execution stack is forcibly reclaimed.

[0009] Preferably, the method for extracting the memory usage features and nesting complexity is as follows: By recursively scanning the object graph of the strongly typed data structure, it is possible to identify whether there are circular references pointing to visited nodes; In response to the detection of a circular reference, the nesting complexity is corrected by truncating the circular path and recording the reference weight; Based on the ratio of serialized data to the size of unpacked memory objects, a memory expansion factor model is established to correct the memory usage characteristics.

[0010] Preferably, the method for calculating the secure memory threshold is as follows: Parse the object graph of the strongly typed data structure, and statistically analyze the nesting depth and number of nodes of the parameters; If the nesting depth exceeds a preset linear processing threshold, an exponential penalty coefficient is used to weight the nesting complexity. The estimated base memory consumption is multiplied by the weighted nesting complexity, and then the size of the stack overflow buffer reserved by the host system is added to generate the safe memory threshold.

[0011] Preferably, the method for allocating the virtualized execution stack is as follows: Request contiguous memory pages corresponding to the aforementioned safe memory threshold from the operating system's memory manager to serve as the base stack space; In the adjacent virtual memory mapping areas at the highest and lowest addresses of the basic stack space, memory protection pages that prohibit read and write access are configured respectively; When the temporary proxy object triggers a memory addressing beyond the base stack space during runtime, it is intercepted by the memory protection page and a page fault exception is triggered to constitute the physical boundary.

[0012] Preferably, the process of constructing the physical boundary further includes the following steps: The address space layout of the virtualized execution stack is randomized. By modifying the memory descriptor table of the host process, the virtualized execution stack can have an independent logical address translation mechanism during execution, thereby achieving randomized isolation of the instruction-level execution environment.

[0013] Preferably, the method for generating the temporary proxy object is as follows: Based on the extracted strongly typed data structure, a simplified class definition containing only the target method signature and interception hook is constructed in memory in real time using dynamic bytecode enhancement technology. When the temporary proxy object is instantiated, the interception hook is bound to a preset memory monitor to achieve real-time capture of all memory read and write instructions during the target function call process.

[0014] Preferably, the method for configuring the access permissions is as follows: Extract the read / write attribute declarations of each parameter variable in the strongly typed data structure; For host process external reference parameters declared as read-only, their memory address segments are marked as read-only in the local page table of the virtualization execution stack; For host process sensitive memory areas that are prohibited from being accessed by the temporary proxy object, the corresponding virtual memory page table entries are stripped from the context of the virtualized execution stack or their mapping is blocked.

[0015] Preferably, the memory boundary verification method specifically includes: When the temporary proxy object assigns values ​​to the fields of the parameter to be processed, the offset address of each field in the virtualization execution stack is calculated; By comparing the offset address with the base address and length of the virtualization execution stack, it is determined whether the memory boundary of the field has overflowed; If the field involves an external pointer reference, then verify whether the target address of the corresponding pointer is within the shared memory segment that the virtualization execution stack is allowed to access.

[0016] Preferably, the method for responding to the end of execution or intercepting an out-of-bounds exception, destroying the temporary proxy object and forcibly reclaiming the physical memory space of the virtualized execution stack, is as follows: When an out-of-bounds exception or instruction cycle timeout interrupt is caught by the temporary proxy object, the normal function return stack frame of the calling instruction is bypassed. Clear the state of the processor registers bound to the virtualization execution stack; Send a physical page release command to the memory manager, overwrite the memory region containing the contiguous memory pages and memory protection pages with all zeros, and then return it to the host process.

[0017] In another aspect, the present invention also proposes an RFC secure execution system based on runtime dynamic proxies, the system being used to implement the method as described in the first aspect of the present invention, comprising: The data parsing and feature extraction module is used to acquire data containing call instructions and parameters to be processed, convert it into a strongly typed data structure, and extract memory usage features and nesting complexity. The stack space dynamic allocation module is used to calculate the safe memory threshold based on the memory usage characteristics and nesting complexity, and allocate a virtualized execution stack with physical boundaries in the host process according to the safe memory threshold. The proxy generation and permission configuration module is used to call the memory reflection mechanism to generate a temporary proxy object in the virtualization execution stack, and configure the shared memory access permissions for the virtualization execution stack based on the strongly typed data structure. The isolated execution and boundary verification module is used to perform memory boundary verification on the parameters to be processed through the temporary proxy object. If the verification passes, the calling instruction is run in isolation within the virtualized execution stack. The secure destruction and memory reclamation module is used to destroy the temporary proxy object and forcibly reclaim the physical memory space of the virtualized execution stack in response to the end of execution or the interception of an out-of-bounds exception.

[0018] Compared with the prior art, the present invention has the following technical effects: 1. The RFC secure execution method proposed in this invention implements a nanosecond-level, use-and-destroy function-level sandbox isolation mechanism that is independent of specific hardware TEE environments. By shrinking the security defense boundary from the traditional network transport layer and sinking it down to the instruction execution and memory management layer inside a single machine, it completely eliminates host process crashes, control flow hijacking, and core data leakage caused by malicious RFC calls at the underlying physical memory level, greatly improving the runtime security of distributed systems.

[0019] 2. The RFC secure execution method proposed in this invention can dynamically calculate the secure memory threshold based on the nesting complexity and bloat prediction of the input parameters, and allocate basic stack space with memory protection pages in the host process as needed accordingly. By using the operating system's page fault exception as a physical blocking means, it avoids the memory waste caused by static large stack allocation and can achieve hardware-level out-of-bounds interception when facing deeply nested bombs.

[0020] 3. The RFC secure execution method proposed in this invention utilizes dynamic bytecode enhancement technology to generate concise temporary proxy objects in real time, and combines this with local page table control to separate read-only and sensitive memory. What was originally an unrestricted direct function call from the business side is transformed into delegated execution subject to strict memory read / write monitoring, achieving extremely fine-grained shared memory access control.

[0021] 4. The RFC secure execution method proposed in this invention directly calculates the offset address and compares it with the sandbox length when the proxy object assigns values ​​to the parameter fields. At the same time, it strictly restricts the legal range of the target address of the external pointer, effectively preventing traditional buffer overflow attacks and arbitrary address read / write vulnerabilities.

[0022] 5. The RFC secure execution method proposed in this invention, upon completion of execution or an exception, bypasses the conventional function return stack frame, clears the processor registers, and performs a full-zero overwrite on consecutive memory pages before returning them to the memory manager. This mechanism not only eliminates the risk of memory leaks but also dismantles return-oriented programming attack paths, ensuring that no sensitive data remains in memory. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the method described in this invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present application and with reference to the accompanying drawings.

[0025] Example 1 This embodiment describes a secure execution method for RFCs based on runtime dynamic proxies, such as... Figure 1 As shown, it includes the following steps one through five: Step 1: Obtain the data containing the call instructions and parameters to be processed, convert it into a strongly typed data structure, and extract memory usage characteristics and nesting complexity.

[0026] In specific application scenarios, RFC request payloads are typically received through the host process's network listening port or local inter-process communication (IPC) channel. This payload is usually a serialized string or byte stream, such as JSON, XML, or Protobuf format. The system's built-in deserialization engine does not directly execute any function calls; instead, it strictly adheres to a predefined data format, mapping the serialized data word-for-word and converting it into a strongly typed data structure in memory, such as a POJO object in Java, a struct in C++, or an instance of a specific class.

[0027] As an example, suppose the system receives raw RFC serialized data as a JSON-formatted byte stream, and its business intent is to call the ProcessTransaction function, with the following payload: { "method":"ProcessTransaction", "params":{ "transactionId":987654321, "amount":250.50, "isCrossBorder":true, "riskTags":["high_frequency","new_device"], "deviceMeta":{ "deviceId":"MAC-A1-B2-C3", "osVersion":14 } } } In typical deserialization vulnerabilities, parsers often trigger the target class's constructor or setter method directly at the underlying level based on the `@type` or similar fields specified in the JSON, resulting in malicious code being executed during the parsing phase. This embodiment's deserialization engine strictly prohibits such implicit calls. The system pre-defines a strongly typed data contract in memory that strictly corresponds to this RFC interface, using a C++-style struct memory structure as an example: struct DeviceMeta{ char deviceId

[32] ; / / Fixed-length character array to prevent overflow int32_t osVersion; / / 4-byte integer }; struct TransactionParams{ int64_t transactionId; / / 8-byte long integer double amount; / / 8-byte double-precision floating-point number bool isCrossBorder; / / 1-byte boolean value char riskTags[5]

[32] ; / / Two-dimensional fixed-length array, limiting the maximum number of tags and length DeviceMeta deviceMeta; / / Nested strongly typed struct }; The mapping and transformation process is as follows: The deserialization engine first allocates a contiguous memory region in the virtualized execution stack allocated in step two, based on the physical memory size determined by the compiler for the TransactionParams structure (approximately 192 bytes after memory alignment), and performs all-zero initialization. At this point, no constructors for any business objects are called. The engine parses JSON key-value pairs one by one, performing strict type assertions. For example, when parsing "transactionId":987654321, the engine confirms its target type is int64_t, then directly converts it to 8 bytes of two's complement and writes it to the corresponding memory address. When parsing nested deviceMeta objects and dynamic arrays riskTags, the engine does not arbitrarily allocate new objects on the heap, but strictly truncates or reports errors according to the fixed-length boundaries defined in the strong type. If the input JSON contains malformed data exceeding this boundary, the engine will discard it or trigger an exception during the pure data transfer phase.

[0028] During or after the conversion, a feature extractor is simultaneously started to obtain the initial state information of the strongly typed data structure, providing a basis for subsequent sandbox isolation. The methods for extracting memory usage features and nesting complexity are as follows: By recursively scanning the object graph of the strongly typed data structure, the system identifies whether circular references to visited nodes exist. The feature extractor can maintain a hash set or object identifier mapping table as an access logger. When the system recursively traverses the object graph of the strongly typed data structure using a depth-first search or breadth-first search algorithm, its memory address or unique identifier is stored in the access logger for each visited object node. If, in a subsequent scan, a pointer to the child node to be parsed is already found in the access logger, a circular reference is definitively determined. This mechanism aims to prevent malicious object graph bombs, such as malformed data with continuous self-referencing, from exhausting the parsing thread's stack.

[0029] In response to the detection of a circular reference, the nesting complexity is corrected by truncating the circular path and recording the reference weight. To ensure that the parsing process does not fall into an infinite loop and the main process does not crash, when a circular reference is detected, the system forcibly sets the pointer of the child node to null or replaces it with a special weak reference placeholder, thereby truncating the circular path at the physical level. Simultaneously, the system records the depth of the loop and the volume of the target node pointed to by the loop, defining them collectively as the reference weight. Subsequently, the corrected nesting complexity is calculated using the following formula:

[0030] In the formula, The larger the value, the more complex the parameter structure, and the higher the safety level requirement when allocating sandboxes later; N is the total number of non-cyclic nodes in the object graph; Let be the tree level depth of the i-th non-cyclic node in the object graph; M is the total number of identified circular reference paths; The reference weight of the kth circular reference can be determined by the original byte size of the node it points to; The exponential penalty coefficient is set to a constant in this embodiment, such as 1.5 or 2.0, to impose a higher complexity assessment value on payloads that attempt to attack via circular references.

[0031] Based on the ratio of serialized data size to the size of the unpacked memory object, a memory bloat factor model is established to correct the aforementioned memory usage characteristics. During RFC deserialization, when highly compressed serialized data is instantiated as an object in memory, its size can increase due to operating system memory alignment, object header overhead, pointer length, and other factors. Therefore, the system uses a memory bloat factor model to predict actual memory consumption. The specific correction formula is as follows:

[0032] In the formula, This is the corrected memory usage characteristic, which is the estimated number of bytes of physical memory that this parameter will actually consume in the virtualization execution stack; The size in bytes of the received raw serialized data. This is a dynamic memory bloat factor, which is derived by the system through machine learning or statistical regression based on historical parsing logs for different data structure types (such as string arrays and complex nested objects). For example, the bloat factor for plain text conversion may be 1.2, while the bloat factor for a large number of small nested objects may be as high as 5.0. This is a constant representing the fixed overhead ratio of the host system and the underlying virtual machine.

[0033] By implementing step one above, the true degree of danger and physical resource requirements of external parameters can be obtained without actually executing business logic code, thereby providing targeted computational input for the on-demand allocation of virtualized execution stacks with physical boundaries in step two.

[0034] Step 2: Calculate the safe memory threshold based on the aforementioned memory usage characteristics and nesting complexity, and allocate a virtualized execution stack with physical boundaries within the host process according to the safe memory threshold. Conventional RFC processing frameworks typically reuse the global thread pool of the host process, whose thread stack size is statically fixed, for example, 1MB or 2MB by default. This static allocation mechanism is highly susceptible to stack overflow, leading to host process crashes, when faced with extremely complex and malformed parameters. This embodiment isolates this risk by dynamically calculating the memory threshold and constructing an independent stack with physical boundaries.

[0035] The method for calculating the secure memory threshold is as follows: The object graph of the strongly typed data structure is parsed, and the nesting depth of the parameters and the number of nodes are statistically analyzed. The built-in parsing engine traverses the strongly typed data structure in memory, accurately recording the maximum tree-level depth and the total number of instantiated nodes in the object graph. These statistics reflect the expected recursion call depth and local variable table size required by the objective function when processing this parameter.

[0036] If the nesting depth exceeds a preset linear processing threshold, an exponential penalty coefficient is used to weight the nesting complexity. The estimated basic memory consumption is multiplied by the weighted nesting complexity, and the size of the stack overflow buffer reserved by the host system is added to generate the safe memory threshold.

[0037] In practice, the system calculates the final safe memory threshold based on the following formula:

[0038] In the formula, This is the dynamically generated safe memory threshold, which is the total physical stack size that needs to be allocated, in bytes. The exponential penalty coefficient is a constant in this embodiment, for example, 2.0. No penalty is applied when the depth of the input parameter is within the normal range. Once the depth exceeds the limit, the system will exponentially expand the defense space to deal with possible recursive overflow attacks. The parameter nesting depth is obtained through statistics; The preset linear processing threshold is set to 20 layers based on the nesting of service parameters. The size of the stack overflow buffer reserved for the host system.

[0039] The method for allocating the virtualized execution stack is as follows: The system requests contiguous memory pages corresponding to the aforementioned safe memory threshold from the operating system's memory manager to serve as the base stack space. In Unix-like operating systems such as Linux, the system can call the mmap system call function, along with the MAP_ANONYMOUS and MAP_PRIVATE flags, to directly request a size of [amount missing] from the operating system's kernel memory manager. A contiguous set of virtual memory pages serves as the base stack space for this RFC call. Those skilled in the art will understand that the data calculated in this step... Typically, it needs to be rounded up to an integer multiple of the standard memory page, such as a multiple of 4KB.

[0040] In the adjacent virtual memory mapping regions at the highest and lowest addresses of the basic stack space, memory protection pages that prohibit read and write access are configured respectively. To establish absolute physical boundaries, the system allocates an additional memory page at both the top and bottom of the basic stack space when allocating it. Subsequently, the mprotect function is called to forcibly modify the memory access permissions of these two boundary pages to PROT_NONE, prohibiting any form of read, write, or execution operations.

[0041] When the temporary proxy object triggers a memory addressing outside the base stack space during runtime, the memory protection page intercepts and triggers a page fault exception to constitute the physical boundary. If the proxy object experiences a stack overflow while executing a malicious or malformed RFC call, its underlying CPU instruction register will attempt to access an address outside the base stack space. Once a memory protection page configured as PROT_NONE is encountered, the CPU's memory management unit will immediately intercept the operation at the hardware level and throw a severe segmentation fault signal (SIGSEGV) or page fault exception to the host process. The system catches this exception through a pre-registered custom signal handler function, thereby achieving strong physical-level isolation without affecting the execution of other threads in the main process.

[0042] Furthermore, the process of constructing the physical boundary also includes the following steps: The address space layout of the virtualized execution stack is randomized; by modifying the memory descriptor table of the host process, the virtualized execution stack has an independent logical address translation mechanism during execution, so as to achieve randomized isolation of the instruction-level execution environment.

[0043] To prevent advanced memory exploitation techniques such as Return-Oriented Programming (ROP) attacks, this embodiment not only restricts the stack boundaries but also obfuscates the runtime environment within the stack. The system simulates fine-grained Address Space Layout Randomization (ASLR) in user space, making the stack base address allocated for each call highly unpredictable. Simultaneously, by calling specific kernel interfaces or modifying the process environment block, the system forces the execution thread containing the proxy object to use an independent logical-to-physical address mapping translation context. This means that even if an attacker guesses the main process's memory layout through a vulnerability, they cannot successfully hijack instructions in this randomized and isolated micro-sandbox environment, thus achieving a high level of instruction-level isolation.

[0044] Step 3: A temporary proxy object is generated within the virtualized execution stack using memory reflection, and shared memory access permissions are configured for the execution stack based on the strongly typed data structure. In conventional remote procedure calls, the system typically obtains the function pointer of the target function directly and pushes it onto the stack for execution. In this embodiment, to prevent malicious code from exploiting vulnerabilities to escape or tamper with the host process's core memory, the system does not directly execute the original function but instead employs a proxy mechanism and privilege downgrading.

[0045] The method for generating the temporary proxy object is as follows: Based on the extracted strongly typed data structure, a simplified class definition containing only the target method signature and intercept hooks is constructed in memory in real time using dynamic bytecode enhancement technology. In specific implementation, if the host process runs in a Java Virtual Machine or a similar high-level language runtime environment, the system does not use the conventional, expensive, and difficult-to-control native reflection mechanism of java.lang.reflect; instead, it calls the underlying dynamic bytecode manipulation library (such as ASM, ByteBuddy, or CGLIB) to directly assemble binary bytecode instructions in the method area of ​​memory. Through dynamic bytecode enhancement technology, a simplified proxy class that inherits from or implements the target interface is generated. This simplified class strips away all redundant logic unrelated to the current call, retaining only the target method signature that strictly corresponds to the parameters to be processed. More importantly, when generating the machine code or bytecode of this method, the system forcibly weaves intercept hook code statically before and after its critical memory addressing instructions (such as GETFIELD, PUTFIELD, or direct pointer dereference instructions).

[0046] When the temporary proxy object is instantiated, the interception hook is bound to a preset memory monitor to achieve real-time capture of all memory read and write instructions during the target function call process. When this temporary proxy object is formally instantiated in the virtualized execution stack allocated in step two, a memory monitor instance initialized in the host process's safe zone is injected into the proxy object. During the actual execution of business logic by the proxy object, each read and write operation on a variable will trigger the woven interception hook first. The hook function will report the target physical address or relative offset that the current operation attempts to access to the memory monitor in real time for authentication, thereby transforming the application-layer function execution into instruction-level step-by-step review.

[0047] The method for configuring the access permissions is as follows: Extract the read / write attribute declarations of each parameter variable in the strongly typed data structure. After completing the strongly typed data structure conversion in step one, the system will use the type introspection mechanism to parse the metadata on the parameter object. For example, it will scan the annotations attached to the parameter fields (such as @ReadOnly, @Immutable) or language-level modifiers (such as the const keyword in C++, and immutable borrow semantics in Rust) to extract the read / write attributes that the developer has explicitly or implicitly declared for each parameter.

[0048] For external reference parameters of the host process declared as read-only, their memory address segments are marked as read-only in the local page table of the virtualized execution stack. To achieve hardware-level access control, this embodiment utilizes the CPU's memory management unit. Instead of relying on purely software-level judgments, it directly leverages the operating system's page table management. When a temporary proxy object needs to read a shared parameter object already existing in the host process, the system finds the virtual memory address segment containing that parameter object in the local page table bound to the current virtualized execution stack. Then, the system modifies the corresponding page table entry, forcibly setting its read / write control bit to read-only. Thus, if the temporary proxy object is maliciously tampered with during execution, attempting to perform a write operation on the parameter, the CPU hardware will trigger a privileged exception, preventing the possibility of modifying external data via pointers.

[0049] For sensitive memory areas of the host process that are prohibited from access by the temporary proxy object, the corresponding virtual memory page table entries are stripped from the context of the virtualized execution stack or their mapping is blocked. The host process's memory space typically contains extremely sensitive data (such as plaintext passwords for database connection pools, SSL / TLS private key memory segments, and stack spaces of other concurrent threads). When configuring the execution environment for this RFC call, the system maintains a blacklist of sensitive memory areas. Before switching to the virtualized execution stack context, the system reviews the thread's virtual memory mapping table for all sensitive memory pages included in the blacklist, either setting the presence bit of these page table entries to 0 or forcibly redirecting the mapping to a randomly generated garbage data page. This makes this sensitive data invisible to the temporary proxy object at the physical addressing level. Even if an attacker gains control of the proxy object through buffer overflows or other means and attempts to perform a malicious scan of the entire memory segment, they cannot breach the MMU's hardware barrier, thus ensuring the security of the host process's core assets.

[0050] Step 4: Perform memory boundary verification on the parameters to be processed through the temporary proxy object. If the verification passes, the calling instruction is executed in isolation within the virtualization execution stack.

[0051] The memory boundary verification method is specifically as follows: When the temporary proxy object assigns values ​​to the fields of the parameters to be processed, it calculates the offset address of each field in the virtualization execution stack. Specifically, when fields of a strongly typed data structure need to be loaded into the local variable table or specific registers of the current virtualization execution stack, the intercept hooks woven into the temporary proxy object are triggered. The proxy object first dynamically calculates the target absolute address in memory of the field to be assigned, based on the underlying compiler's memory alignment rules and the data type word length of each field. The calculation formula is as follows:

[0052] In the formula, The calculated physical or virtual absolute starting address of memory where the current k-th field will be written; This is the address of the bottom pointer of the current virtualization execution stack, or the starting base address of the current object; The length of the data in the i-th field preceding the current field; This indicates the alignment requirement based on the i-th field. The alignment function that performs the rounding up calculation; Offset is the offset of blank bytes automatically filled by the compiler to meet the overall data structure alignment requirements.

[0053] The offset address is compared with the base address and length of the virtualization execution stack to determine whether the memory boundary of the field has overflowed. After obtaining the target absolute address, the temporary proxy object performs a strict boundary inequality check, which is the core mechanism to prevent buffer overflow attacks. The system adds the starting address of the field to be written to the size of the field itself and compares it with the legal physical boundary of the current virtualization execution stack. The determination formula is as follows:

[0054] In the formula, This is the number of bytes of memory required for the k-th field to be assigned. If it is a variable-length string or array, then the actual length declared in its descriptor is used. This refers to the total available length of the virtualized execution stack allocated according to the safe memory threshold in step two.

[0055] If the above inequality does not hold, it means that the parameter assignment operation will exceed the sandbox boundary allocated by the system. In this case, it is defined as a memory boundary overflow, and the assignment instruction will be blocked directly, throwing a hardware-level or software-level out-of-bounds exception.

[0056] If the field involves an external pointer reference, the target address of the corresponding pointer is verified to be within a shared memory segment accessible by the virtualized execution stack. In RFC calls, parameters often contain not only value types but also a large number of reference types. Attackers frequently exploit malformed pointers to attempt to induce the target function to perform illegal reads or modifications. To address this scenario, when a field is an external pointer reference, the temporary proxy object extracts the memory target address it points to before dereferencing the pointer. Then, the access permission table and local page table configured for this execution stack were consulted to verify the validity of the address range:

[0057] In the formula, m is the total number of legal shared memory segments that are allowed to be accessed; This represents the starting base address of the j-th legal shared memory segment; This represents the length range of the j-th legal shared memory segment. Only when... The pointer dereference operation is allowed only if the pointer falls strictly within the set of legal memory regions mentioned above. Otherwise, it is considered an illegal pointer overreach and the operation is terminated.

[0058] Only after the boundary checks for memory overflow and pointer privilege escalation have successfully passed do the temporary proxy object finally transfer control, and the invocation instructions are executed in isolation within the virtualized execution stack. (Steps) Step 5: In response to the end of execution or interception of an out-of-bounds exception, destroy the temporary proxy object and forcibly reclaim the physical memory space of the virtualized execution stack.

[0059] The response, upon execution completion or interception of an out-of-bounds exception, destroys the temporary proxy object and forcibly reclaims the physical memory space of the virtualized execution stack. The specific method is as follows: When an out-of-bounds exception or instruction cycle timeout is captured by the temporary proxy object, the regular function return stack frame of the called instruction is bypassed. Specifically, if the proxy object triggers an exception during the execution of step four, or its execution time exceeds the preset watchdog timer cycle, the system kernel or exception handler will take over control. Since the stack frame structure within the virtualized execution stack may have been corrupted by malicious parameters when an exception occurs, its stored return address may have been tampered with by the attacker. If the system still performs stack popping and return according to regular assembly instructions, it will directly trigger a return-oriented programming attack, returning control flow to the attacker. Therefore, the currently corrupted stack frame is forcibly discarded through the underlying context jump mechanism, directly shifting the program's execution flow to the host process's preset security recovery routine.

[0060] Clear the processor register state bound to the virtualized execution stack. After the security recovery routine takes over, the first thing to handle is the processor registers. Because the temporary proxy object inevitably stores sensitive plaintext data processed by the target function in the CPU's general-purpose registers, floating-point registers, or vector registers when performing RFC operations, a specific assembly cleanup routine must be called before returning the thread resources to the host process's thread pool. This hard-clears all non-reserved registers bound to the current thread to prevent attackers from attempting to steal sensitive information from the previous session through timing side-channels or register remnants.

[0061] A physical page release instruction is sent to the memory manager, overwriting the memory region containing the contiguous memory pages and memory protection pages with all zeros before returning it to the host process. To ensure that any local variables, object pointers, and temporary data in the execution stack are not read without authorization, the system performs a forced safe erase before releasing the memory. This is done by calling the underlying memory overwrite function to overwrite the previously allocated contiguous block of virtual memory with all zeros.

[0062] The memory range to be overwritten is calculated as follows:

[0063]

[0064] In the formula, The absolute physical / virtual address range for performing an all-zero overwrite; This is the starting address of the memory protection page allocated at the bottom of the stack in step two; This is the starting address of the memory protection page allocated at the top of the stack in step two; This is the fixed size of the standard memory page in the operating system. This represents the total number of bytes that need to be overwritten.

[0065] After confirming that the overwrite operation has physically written to disk, the system sends a physical page release command to the operating system's memory manager. At this point, the temporary proxy object is completely destroyed, and all the contiguous memory pages and memory protection pages it occupied are unbound and returned to the host process's available memory pool.

[0066] Example 2 This embodiment is an RFC secure execution system based on runtime dynamic proxies. The system is used to implement the method described in Embodiment 1, including: The data parsing and feature extraction module is used to acquire data containing call instructions and parameters to be processed, convert it into a strongly typed data structure, and extract memory usage features and nesting complexity. The stack space dynamic allocation module is used to calculate the safe memory threshold based on the memory usage characteristics and nesting complexity, and allocate a virtualized execution stack with physical boundaries in the host process according to the safe memory threshold. The proxy generation and permission configuration module is used to call the memory reflection mechanism to generate a temporary proxy object in the virtualization execution stack, and configure the shared memory access permissions for the virtualization execution stack based on the strongly typed data structure. The isolated execution and boundary verification module is used to perform memory boundary verification on the parameters to be processed through the temporary proxy object. If the verification passes, the calling instruction is run in isolation within the virtualized execution stack. The secure destruction and memory reclamation module is used to destroy the temporary proxy object and forcibly reclaim the physical memory space of the virtualized execution stack in response to the end of execution or the interception of an out-of-bounds exception.

[0067] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the inventive concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A method for secure execution of RFCs based on runtime dynamic proxies, characterized in that, Includes the following steps: Obtain data containing call instructions and parameters to be processed, convert it into a strongly typed data structure, and extract memory usage characteristics and nesting complexity. Calculate the safe memory threshold based on the memory usage characteristics and nesting complexity, and allocate a virtualized execution stack with physical boundaries in the host process according to the safe memory threshold; The memory reflection mechanism is invoked to generate a temporary proxy object within the virtualized execution stack, and the shared memory access permissions for the execution stack are configured based on the strongly typed data structure. The temporary proxy object performs memory boundary verification on the parameters to be processed. If the verification passes, the calling instruction is executed in isolation within the virtualization execution stack. In response to the end of execution or the interception of an out-of-bounds exception, the temporary proxy object is destroyed and the physical memory space of the virtualized execution stack is forcibly reclaimed.

2. The method according to claim 1, characterized in that, The method for extracting the memory usage characteristics and nesting complexity is as follows: By recursively scanning the object graph of the strongly typed data structure, it is possible to identify whether there are circular references pointing to visited nodes; In response to the detection of a circular reference, the nesting complexity is corrected by truncating the circular path and recording the reference weight; Based on the ratio of serialized data to the size of unpacked memory objects, a memory expansion factor model is established to correct the memory usage characteristics.

3. The method according to claim 1, characterized in that, The method for calculating the secure memory threshold is as follows: Parse the object graph of the strongly typed data structure, and statistically analyze the nesting depth and number of nodes of the parameters; If the nesting depth exceeds a preset linear processing threshold, an exponential penalty coefficient is used to weight the nesting complexity. The estimated base memory consumption is multiplied by the weighted nesting complexity, and then the size of the stack overflow buffer reserved by the host system is added to generate the safe memory threshold.

4. The method according to claim 1, characterized in that, The method for allocating the virtualized execution stack is as follows: Request contiguous memory pages corresponding to the aforementioned safe memory threshold from the operating system's memory manager to serve as the base stack space; In the adjacent virtual memory mapping areas at the highest and lowest addresses of the basic stack space, memory protection pages that prohibit read and write access are configured respectively; When the temporary proxy object triggers a memory addressing beyond the base stack space during runtime, it is intercepted by the memory protection page and a page fault exception is triggered to constitute the physical boundary.

5. The method according to claim 4, characterized in that, The process of constructing the physical boundary also includes the following steps: The address space layout of the virtualized execution stack is randomized. By modifying the memory descriptor table of the host process, the virtualized execution stack can have an independent logical address translation mechanism during execution, thereby achieving randomized isolation of the instruction-level execution environment.

6. The method according to claim 1, characterized in that, The method for generating the temporary proxy object is as follows: Based on the extracted strongly typed data structure, a simplified class definition containing only the target method signature and interception hook is constructed in memory in real time using dynamic bytecode enhancement technology. When the temporary proxy object is instantiated, the interception hook is bound to a preset memory monitor to achieve real-time capture of all memory read and write instructions during the target function call process.

7. The method according to claim 1, characterized in that, The method for configuring the access permissions is as follows: Extract the read / write attribute declarations of each parameter variable in the strongly typed data structure; For host process external reference parameters declared as read-only, their memory address segments are marked as read-only in the local page table of the virtualization execution stack; For host process sensitive memory areas that are prohibited from being accessed by the temporary proxy object, the corresponding virtual memory page table entries are stripped from the context of the virtualized execution stack or their mapping is blocked.

8. The method according to claim 1, characterized in that, The memory boundary verification method is specifically as follows: When the temporary proxy object assigns values ​​to the fields of the parameter to be processed, the offset address of each field in the virtualization execution stack is calculated; By comparing the offset address with the base address and length of the virtualization execution stack, it is determined whether the memory boundary of the field has overflowed; If the field involves an external pointer reference, then verify whether the target address of the corresponding pointer is within the shared memory segment that the virtualization execution stack is allowed to access.

9. The method according to claim 4, characterized in that, The response, upon execution completion or interception of an out-of-bounds exception, destroys the temporary proxy object and forcibly reclaims the physical memory space of the virtualized execution stack. The specific method is as follows: When an out-of-bounds exception or instruction cycle timeout interrupt is caught by the temporary proxy object, the normal function return stack frame of the calling instruction is bypassed. Clear the state of the processor registers bound to the virtualization execution stack; Send a physical page release command to the memory manager, overwrite the memory region containing the contiguous memory pages and memory protection pages with all zeros, and then return it to the host process.

10. An RFC secure execution system based on runtime dynamic proxies, characterized in that, The system is used to implement the method as described in any one of claims 1-9, comprising: The data parsing and feature extraction module is used to acquire data containing call instructions and parameters to be processed, convert it into a strongly typed data structure, and extract memory usage features and nesting complexity. The stack space dynamic allocation module is used to calculate the safe memory threshold based on the memory usage characteristics and nesting complexity, and allocate a virtualized execution stack with physical boundaries in the host process according to the safe memory threshold. The proxy generation and permission configuration module is used to call the memory reflection mechanism to generate a temporary proxy object in the virtualization execution stack, and configure the shared memory access permissions for the virtualization execution stack based on the strongly typed data structure. The isolated execution and boundary verification module is used to perform memory boundary verification on the parameters to be processed through the temporary proxy object. If the verification passes, the calling instruction is run in isolation within the virtualized execution stack. The secure destruction and memory reclamation module is used to destroy the temporary proxy object and forcibly reclaim the physical memory space of the virtualized execution stack in response to the end of execution or the interception of an out-of-bounds exception.

Images