Method for ensuring heap memory space safety of embedded system, and embedded system using same

Abstract

A method for ensuring heap memory space security of an embedded system, according to some embodiments of the present invention, may comprise the steps of: receiving a source code; generating an instrumentation code for the source code; compiling the instrumentation code and executing a program; setting a plurality of memory protection units for a heap area; and performing memory boundary checking before performing a read / write command included in the program, wherein the step of performing the memory boundary checking can include the steps of: using a base pointer and a pointer for the read / write command, and specifying one of the plurality of memory protection units by using the base pointer; and using the base pointer and the pointer so as to determine whether to exceed the heap size for the specified memory protection unit.

Description

A method for ensuring heap memory space safety in embedded systems and an embedded system utilizing the method.

[0001] The present invention relates to a method for ensuring heap memory space security in an embedded system and an embedded system utilizing the same. More specifically, the present invention relates to a method for ensuring heap memory space security in an embedded system while enhancing security and minimizing performance and resource overhead, and an embedded system utilizing the same.

[0002]

[0003] The content described in this section merely provides background information for the present embodiment and does not constitute prior art.

[0004] This research was supported by the Ministry of Science and ICT of the Republic of Korea, the National IT Industry Promotion Agency, the Information and Communications Technology Planning and Evaluation Institute, the Information Security Core Source Technology Development (R&D), and the Development of a Full-cycle Data Privacy Protection Technology Using Anonymized Confidential Execution (Project ID: 2710008804).

[0005] An embedded system is a special-purpose computing system that integrates computer technology into various devices and systems. Embedded systems are primarily designed to perform specific tasks or functions and are used in a variety of industries. For example, embedded systems can include automotive engine control, medical device monitoring, home appliance control, industrial automation, and smart home systems.

[0006] Most embedded systems have limited computing resources, resulting in small memory, low-power CPUs, and limited storage. Embedded systems utilize limited computing resources not only to reduce costs but also to increase energy efficiency.

[0007] Due to their limited resources, embedded systems struggle to implement high-security policies. Assigning high-security policies to embedded systems sacrifices too much computing resources for security, resulting in performance degradation within the embedded system itself.

[0008] However, embedded systems also require safety and reliability. For example, medical devices and aircraft control systems must ensure reliable operation, and external attacks such as hacking can result in significant damage.

[0009] To fundamentally address these issues, it is necessary to apply Spatial Memory Safety (SMS) technology to embedded systems. Initially, research and development of spatial memory safety technology focused on strengthening security during memory access, using techniques like fat pointers that contain metadata about memory regions. However, maintaining and checking this metadata consumes computing resources, ultimately resulting in performance and memory overhead. Furthermore, direct application of spatial memory safety technology to embedded systems utilizing these resources is challenging.

[0010] Recent advancements in Internet of Things (IoT) technology, the expansion of edge computing, and the development of systems that integrate artificial intelligence (AI) with embedded systems have led to a growing interest in embedded systems. Consequently, research on embedded systems is also actively underway. Embedded systems demand a high level of security in critical sectors such as industrial control, medical devices, and automotive. Therefore, it is crucial to maximize the security environment within limited processor performance and memory capacity, balancing performance and memory overhead with security levels.

[0011] Ultimately, there is an urgent need for research and development on methods to secure memory space security specialized for embedded systems.

[0012] Accordingly, this specification proposes a method for ensuring spatial memory security while minimizing the use of computing resources of an embedded system, and several embodiments of an embedded system using the method.

[0013]

[0014] A method for ensuring heap memory space safety of an embedded system and an embedded system utilizing the method are provided.

[0015] The objectives of the present invention are not limited to those mentioned above. Other objectives and advantages of the present invention not mentioned above can be understood through the following description and will be more clearly understood through the embodiments of the present invention. Furthermore, it will be readily apparent that the objectives and advantages of the present invention can be realized by the means and combinations thereof set forth in the claims.

[0016]

[0017] A method for ensuring heap memory space safety of an embedded system according to some embodiments of the present invention for solving the above problem includes the steps of receiving source code, generating measurement code for the source code, compiling the measurement code and executing a program, setting a plurality of memory protection units for a heap area, and performing a memory boundary check before performing a read / write instruction included in the program, wherein the step of performing the memory boundary check may include the steps of using a base pointer and a pointer for the read / write instruction, specifying one of the plurality of memory protection units using the base pointer, and determining, using the base pointer and the pointer, whether a heap size for the specified memory protection unit is exceeded.

[0018] In some embodiments, the step of generating the instrumentation code may include the step of analyzing the source code to determine the base pointer using the pointer to an object included in at least one of the read / write instructions, and the step of adding an object check function call instruction that takes the pointer and the base pointer as arguments before the read / write instruction.

[0019] In some embodiments, performing the memory bounds check may include calling the object check function.

[0020] In some embodiments, the step of specifying one of the plurality of memory protection units may include the step of using a memory address verification instruction and the base pointer.

[0021] In some embodiments, the memory address verification command may be a hardware-based command.

[0022] In some embodiments, the step of determining whether the heap size for the specified memory protection unit is exceeded may include determining whether a difference between the pointer and the base pointer exceeds the heap size.

[0023] In some embodiments, the method may further include determining a memory boundary error if the heap size for the specified memory protection unit is exceeded, and determining a memory boundary normal if the heap size for the specified memory protection unit is not exceeded.

[0024] In some embodiments, the step of setting up multiple memory protection units for a heap area may include the step of allocating a first memory protection unit for a first heap area and the step of allocating a second memory protection unit, different from the first memory protection unit, for a second heap area different from the first heap area.

[0025] In some embodiments, the first size of the first heap area may be smaller than the second size of the second heap area.

[0026] According to some embodiments of the present invention for solving the above problem, an embedded system includes a processing module and a storage module connected to the processing module, the storage module storing instructions for causing the processing module to execute a program, the instructions including: receiving a source code; generating an instrumentation code for the source code; compiling the instrumentation code and executing the program; setting a plurality of memory protection units for a heap area; and performing a memory boundary check before performing a read / write instruction included in the program, wherein the performing a memory boundary check may include: using a base pointer and a pointer for the read / write instruction, specifying one of the plurality of memory protection units using the base pointer; and determining, using the base pointer and the pointer, whether a heap size for the specified memory protection unit is exceeded.

[0027] In some embodiments, the step of generating the instrumentation code may include the step of analyzing the source code to determine the base pointer using the pointer to an object included in at least one of the read / write instructions, and the step of adding an object check function call instruction that takes the pointer and the base pointer as arguments before the read / write instruction.

[0028] In some embodiments, performing the memory bounds check may include calling the object check function.

[0029] In some embodiments, the step of specifying one of the plurality of memory protection units may include the step of using a memory address verification instruction and the base pointer.

[0030] In some embodiments, the memory address verification command may be a hardware-based command.

[0031] In some embodiments, the step of determining whether the heap size for the specified memory protection unit is exceeded may include determining whether a difference between the pointer and the base pointer exceeds the heap size.

[0032] In some embodiments, the method may further include determining a memory boundary error if the heap size for the specified memory protection unit is exceeded, and determining a memory boundary normal if the heap size for the specified memory protection unit is not exceeded.

[0033] In some embodiments, the step of setting up multiple memory protection units for a heap area may include the step of allocating a first memory protection unit for a first heap area and the step of allocating a second memory protection unit, different from the first memory protection unit, for a second heap area different from the first heap area.

[0034] In some embodiments, the first size of the first heap area may be smaller than the second size of the second heap area.

[0035] According to some embodiments of the present invention for solving the above problem, an embedded system may include a storage module for storing source code, a processing module for executing a program associated with the source code, and a memory management module for executing an object check function requested by the processing module, wherein the object check function may include a step of determining whether a base pointer for a read / write instruction included in the program points to a heap area, a step of determining whether a difference between a pointer for the read / write instruction and the base pointer exceeds an object size of the read / write instruction when the base pointer points to a heap area, and a step of determining whether a difference between the pointer and the base pointer exceeds a size of an area outside the heap area when the base pointer points to an area outside the heap area.

[0036] In some embodiments, the object check function may further include: if the base pointer points to a heap area, determining that a memory boundary error has occurred in the heap area if a difference between the pointer for the read / write instruction and the base pointer exceeds the object size of the read / write instruction; and if the base pointer points to an area outside the heap area, determining that a memory boundary error has occurred in an area outside the heap area if a difference between the pointer and the base pointer exceeds the size of the area outside the heap area.

[0037]

[0038] A method for ensuring heap memory space security of an embedded system according to some embodiments of the present invention and an embedded system using the same have the advantage of increasing security performance while minimizing the use of computing resources.

[0039] In addition to the above-described contents, the specific effects of the present invention are described together with the specific matters for carrying out the invention below.

[0040]

[0041] FIG. 1 is a drawing for explaining the configuration of an embedded system according to some embodiments of the present invention.

[0042] FIG. 2 is a diagram illustrating the configuration of a program stored in memory according to some embodiments of the present invention.

[0043] FIG. 3 is a diagram for functionally explaining the configuration of an embedded system according to some embodiments of the present invention.

[0044] FIG. 4 is a drawing for explaining the structure of a linear memory according to some embodiments of the present invention.

[0045] FIG. 5 and FIG. 6 are drawings for explaining the configuration of a memory protection unit for some embodiments of the present invention.

[0046] FIGS. 7 to 9 are diagrams illustrating a method for ensuring memory space safety for a heap area according to some embodiments of the present invention.

[0047]

[0048] The terms and words used in this specification and claims should not be interpreted based on their general or dictionary meanings. In accordance with the principle that inventors can define the concepts of terms and words to best describe their inventions, they should be interpreted in a way that is consistent with the technical concept of the present invention. Furthermore, the embodiments described in this specification and the configurations depicted in the drawings are merely examples of how the present invention can be realized and do not fully represent the technical concept of the present invention. Therefore, it should be understood that various equivalents, modifications, and applicable examples may exist as of the time of filing.

[0049] The terms first, second, A, B, etc. used in this specification and claims may be used to describe various components, but the components should not be limited by these terms. These terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. The term "and / or" includes any combination of a plurality of related listed items or any item among a plurality of related listed items.

[0050] The terminology used in this specification and claims is for the purpose of describing specific embodiments only and is not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. It should be understood that terms such as "comprise" or "have" in this application do not preclude the presence or addition of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification.

[0051] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs.

[0052] Terms defined in commonly used dictionaries should be interpreted to have a meaning consistent with their meaning in the context of the relevant technology, and will not be interpreted in an idealized or overly formal sense unless expressly defined in this application.

[0053] In addition, each configuration, process, procedure or method included in each embodiment of the present invention may be shared within a scope that is not technically inconsistent with each other.

[0054]

[0055] An embedded system (100) refers to a special-purpose computing system in which computer technology is integrated and operated within various devices and systems. Embedded systems (100) are primarily designed to perform specific tasks or functions and are used in a variety of industrial fields. For example, embedded systems (100) may include automotive engine control, medical device monitoring, home appliance control, industrial automation, smart home systems, and more.

[0056] FIG. 1 is a drawing for explaining the configuration of an embedded system according to some embodiments of the present invention.

[0057] Referring to FIG. 1, an embedded system (100) may include a processor (10), a memory (20), an input device (30), an output device (40), a communication module (50), and an interface (60). Each of the processor (10), the memory (20), the input device (30), the output device (40), the communication module (50), and the interface (60) may interact with each other via a bus or a direct connection. That is, the processor (10), the memory (20), the input device (30), the output device (40), the communication module (50), and the interface (60) may be connected to each other and communicate with each other through various methods.

[0058] The processor (10) may include a main processor (11) and a secondary processor (12). The main processor (11) may include, for example, a central processing unit (CPU) or an application processor (AP). The secondary processor (12) may include, for example, at least one of a graphic processing unit (GPU), an image signal processor (ISP), a sensor hub processor, and a communication processor, which may operate independently of or together with the main processor (11), but the embodiments are not limited thereto. The secondary processor (12) may be configured to operate at lower power than the main processor (11) or to be specialized for a specific function. In some embodiments, the secondary processor (12) may be implemented separately from the main processor (11) or as a part thereof.

[0059] The auxiliary processor (12) may control at least a portion of the functions associated with at least one of the components of the embedded system (100) on behalf of the main processor (11) while the main processor (11) is in an inactive state, or together with the main processor (11) while the main processor (11) is in an inactive state. In some embodiments, the auxiliary processor (12) may be implemented as a part of a component functionally related thereto.

[0060] However, although the present specification describes the processor (10) as including both a main processor (11) and a secondary processor (12), the embodiments are not limited thereto. In other words, depending on the configuration of the system, the processor (10) may be implemented to include only a main processor (11).

[0061] The processor (10) can execute software to control at least one other component of an embedded system (100) connected to the processor (10) and perform various data processing or operations.

[0062] In some embodiments, the processor (10) may be configured with processing units of relatively low performance compared to typical computing systems. This is due to the characteristics of the embedded system (100).

[0063] According to some embodiments, as at least part of data processing or calculation, the processor (10) may load instructions or data received from another component into the memory (20), process instructions or data stored in the memory (20), or store result data in the memory (20). In other words, the processor (10) may execute software in conjunction with the memory (20).

[0064] The memory (20) can store various data used by at least one component of the embedded system (100). The data can include, for example, input data or output data for software and commands related thereto.

[0065] Memory (20) may include non-volatile memory and volatile memory. Non-volatile memory may be memory that retains stored information even when power is not supplied. Non-volatile memory includes, for example, Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Alterable ROM (EAROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM) (e.g., NAND Flash memory, NOR Flash memory), Ultra-Violet Erasable Programmable Read-Only Memory (UVEPROM), Ferroelectric Random Access Memory (FeRAM), Magnetoresistive Random Access Memory (MRAM), Phase-change Random Access Memory (PRAM), Silicon-oxide-nitride-oxide-silicon (SONOS), Resistive Random Access Memory (RRAM), Nanotube Random Access Memory (NRAM), magnetic computer memory (e.g., hard disks, diskette drives, magnetic tapes), optical disk drives, and 3D crosspoint memory (3D XPoint memory), but the present embodiment is not limited thereto.

[0066] Unlike non-volatile memory, volatile memory may be memory that continuously requires power to maintain stored information. Volatile memory may include, for example, at least one of dynamic random access memory (DRAM), static random access memory (SRAM), synchronous dynamic random access memory (SDRAM), and double data rate SDRAM (DDR SDRAM). However, the present embodiment is not limited thereto.

[0067] According to some embodiments, the memory (20) may store instructions for the processor (10) to execute a program (21). In other words, the processor (10) may execute the program (21) according to the instructions stored in the memory (20). For a more specific description of the program (21), reference is made further to FIG. 2.

[0068]

[0069] FIG. 2 is a diagram illustrating the configuration of a program stored in memory according to some embodiments of the present invention.

[0070] Referring to FIG. 2, the program (21) may include an application (APP), middleware (MW), and an operating system (OS).

[0071] An application (APP) is a type of software that is designed to perform a specific task or perform a specific function.

[0072] Middleware (MW) refers to a software layer or service that facilitates communication and interaction between different applications (APPs) or components in an embedded system (100). In other words, middleware (MW) can function as an intermediate layer between applications (APPs) and hardware.

[0073] In some embodiments, the middleware (MW) can manage network communications and establish and maintain connections between the embedded system (100) and other computing systems. Furthermore, the middleware (MW) can perform data conversion or format conversion between different applications (APPs). Furthermore, the middleware (MW) can manage data security and user authentication, ensuring that only authenticated users can access and communicate with the network node (NN).

[0074] An operating system (OS) may be software that provides convenience to users in using the embedded system (100) by efficiently managing the hardware and software resources of the embedded system (100). That is, the operating system (OS) may manage and control one or more system resources of the embedded system (100). The operating system (OS) may include, for example, Unix, Windows, MacOS, and Linux.

[0075]

[0076] Referring back to FIG. 1, the input device (30) can receive commands or data used in components of the embedded system (100) from an external source (e.g., a user) of the embedded system (100). The input device (30) can include a microphone, a mouse, a keyboard, a sensor, etc.

[0077] The output device (40) may be a device that outputs specific information to the outside of the embedded system (100). For example, the output device (40) may include a speaker for multimedia playback, a display for visually expressing information, a holographic device, a haptic device that converts electrical signals into tactile signals, etc.

[0078] The communication module (50) can support the establishment of a direct communication channel or a wireless communication channel between the embedded system (100) and an external electronic device (101) or a server (102), and the performance of communication through the established communication channel. The communication module (50) operates independently from the processor (10) and can include one or more communication processors that support direct communication or wireless communication. According to one embodiment, the communication module (50) can include a wireless communication module or a wired communication module. Among these communication modules, a corresponding communication module can communicate with the external electronic device (101) or the server (102) via a network (200). These various types of communication modules can be integrated into a single component or implemented as multiple separate components.

[0079] The network (200) may include a network based on wired Internet technology, wireless Internet technology, and short-range communication technology. The wired Internet technology may include, for example, at least one of a local area network (LAN) and a wide area network (WAN).

[0080] The wireless Internet technology may include, for example, at least one of Wireless LAN (WLAN), Digital Living Network Alliance (DMNA), Wireless Broadband (Wibro), World Interoperability for Microwave Access (Wimax), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSUPA), IEEE 802.16, Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), Wireless Mobile Broadband Service (WMBS), and 5G NR (New Radio) technologies. However, the present embodiment is not limited thereto.

[0081] Short-range communication technologies may include, for example, at least one of Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra-Wideband (UWB), ZigBee, Near Field Communication (NFC), Ultra Sound Communication (USC), Visible Light Communication (VLC), Wi-Fi, Wi-Fi Direct, and 5G NR (New Radio). However, the present embodiment is not limited thereto.

[0082] An embedded system (100) communicating via a network may comply with technical standards and standard communication methods for mobile communication. For example, the standard communication method may include at least one of GSM (Global System for Mobile communication), CDMA (Code Division Multi Access), CDMA2000 (Code Division Multi Access 2000), EV-DO (Enhanced Voice-Data Optimized or Enhanced Voice-Data Only), WCDMA (Wideband CDMA), HSDPA (High Speed ​​Downlink Packet Access), HSUPA (High Speed ​​Uplink Packet Access), LTE (Long Term Evolution), LTEA (Long Term Evolution-Advanced), and 5G NR (New Radio). However, the present embodiment is not limited thereto.

[0083] The interface (60) may support one or more designated protocols that may be used to directly or wirelessly connect the embedded system (100) to external / internal devices. According to some embodiments, the interface (60) may include a High Definition Multimedia Interface (HDMI), a Universal Serial Bus (USB) interface, an audio interface, etc.

[0084] According to some embodiments, the embedded system (100) may refer to a client terminal utilized by a user and capable of operating an application in a wired or wireless communication environment. The embedded system (100) may include various types of electronic devices, such as a personal computer (PC), a laptop, a tablet, a mobile phone, a smart phone, an IoT device, an embedded system, a wearable device (e.g., a watch-type terminal), etc.

[0085]

[0086] FIG. 3 is a diagram for functionally explaining the configuration of an embedded system according to some embodiments of the present invention.

[0087] Referring to FIG. 3, the embedded system (100) may include a processing module (P_md), a storage module (S_md), and a memory management module (M_md).

[0088] The processing module (P_md) may be a module that implements a function for performing a computational task in an embedded system (100) using a combination of hardware and / or software. The processing module (P_md) includes hardware and / or software resources related to the processor (10) and may perform tasks related to data processing, computation, and execution of application programs.

[0089] According to some embodiments, the processing module (P_md) may include hardware-level instructions (H_instr). In other words, the processing module (P_md) may include a register that stores hardware-level instructions and a processing unit that executes the same. The hardware-level instructions (H_instr) may include, for example, various functions provided at the hardware level, which may be stored in a register in the form of firmware or software. In other words, the hardware-level instructions (H_instr) may include executing a kernel or an operating system (OS) to perform operations that perform specific functions through hardware-level instructions. The hardware-level instructions may include, for example, a TestTarget (TT) instruction provided by ARMv8-M or later.

[0090] Additionally, according to some embodiments, the hardware-level instructions (H_instr) may include instructions for setting up and managing a memory protection unit (MPU). The memory protection unit may be a hardware component used to control and protect memory access in a computer system. The memory protection unit may be primarily used in microcontrollers, microprocessors, embedded systems, and real-time systems.

[0091] In some embodiments, the memory protection unit can set memory address ranges and permissions. In other words, the memory protection unit can be used to individually control read, write, and execute permissions for specific memory regions. This allows the memory protection unit to block attempts to access memory regions for which it has no access rights.

[0092] Additionally, the memory protection unit can isolate memory areas and prevent them from interfering with each other. This can prevent security issues such as memory leaks or overflows in programs (21) or data, and improve memory stability.

[0093] Additionally, the memory protection unit can generate an exception in the processor if it detects an invalid memory access, thereby preventing the program (21) from handling the error or causing the system to halt.

[0094] Additionally, the memory protection unit can allow or restrict code execution in specific memory areas. Through this, the memory protection unit can protect the execution of the program (21) and prevent the execution of malicious code.

[0095]

[0096] A storage module (S_md) may refer to a combination of hardware and / or software that manages and provides data storage. In some embodiments, the storage module (S_md) may store and manage data files, configuration files, and source code (Exe_c).

[0097]

[0098] The memory management module (M_md) may be a module composed of a combination of hardware and / or software for managing a memory area for executing a program (21) and setting up a memory area to prevent errors such as overflow. According to some embodiments of the present invention, the memory management module (M_md) may be controlled to perform a memory boundary check to ensure memory space safety. For example, the memory management module (M_md) may include an instrumentation compiler (Ins_cmp), a memory allocator (Mem_all), and a linear memory (Lin_mem).

[0099] In some embodiments, the instrumentation compiler (Ins_cmp) may analyze the received source code (Exe_c), perform instrumentation operations such as inserting code to perform additional functions, and compile the instrumented code. In some embodiments, the instrumentation compiler (Ins_cmp) may analyze the source code (Exe_c) to track and determine pointers and base pointers for read / write instructions. In this specification, the term "read / write instruction" is used to mean either a read instruction that reads data stored in a specific memory area or a write instruction that writes data to a specific memory area. In other words, the read / write instruction may be either a read instruction or a write instruction.

[0100] According to some embodiments of the present invention, when the embedded system (100) executes a read instruction or a write instruction according to the program (21), a memory boundary check may be performed for security purposes. In other words, since a memory boundary check is performed both when a read instruction is executed and when a write instruction is executed, in this specification, for the convenience of explanation, the term "read / write instruction" is used to refer to either a read instruction or a write instruction.

[0101] In some embodiments, the instrumentation compiler (Ins_cmp) may generate instrumentation source code by analyzing the source code (Exe_c) and adding an object check function call instruction before the read / write instruction if a read / write instruction exists in the source code (Exe_c). In some embodiments, the object check function may be a function that performs a memory boundary check on a memory area for performing the read / write instruction by using a pointer and a base pointer for the read / write instruction analyzed by the instrumentation compiler (Ins_cmp). In other words, the instrumentation compiler (Ins_cmp) may generate instrumentation source code by inserting an object check function call instruction before the read / write instruction so as to perform a memory boundary check before the read / write operation.

[0102] In some embodiments, the instrumentation compiler (Ins_cmp) can compile the instrumentation source code so that it can be executed by the memory management module (M_md), thereby generating binary code. Binary code refers to machine language code consisting of 0s and 1s in a form that a computer can understand and execute.

[0103] Binary code compiled by the instrumentation compiler (Ins_cmp) is provided to the processing module (P_md), and the processing module (P_md) can call the object check function to perform memory boundary check in the memory allocator (Mem_all) according to the binary code.

[0104] The memory allocator (Mem_all) may be a program or module that provides a software library or function used to dynamically allocate and free linear memory (Lin_mem) in a program (21). The memory allocator (Mem_all) manages and allocates the memory space required while the program (21) is running, and frees the memory when it is no longer in use, making it available for reuse.

[0105] In other words, the memory allocator (Mem_all) can find and allocate available memory blocks when a program dynamically requires memory during runtime. The allocated memory blocks can be used in the program (21).

[0106] Additionally, the memory allocator (Mem_all) can free memory when a program no longer needs it, allowing it to be reused for other purposes. Furthermore, the memory allocator (Mem_all) can perform actions to minimize memory fragmentation (the fragmentation of memory space) during memory allocation and deallocation. Memory fragmentation refers to the phenomenon of dividing large blocks of available memory into multiple smaller pieces, which can lead to inefficient memory usage.

[0107] Additionally, the memory allocator (Mem_all) can manage and secure memory access to protect the system from security issues such as incorrect memory access and buffer overflow.

[0108] That is, the memory allocator (Mem_all) according to some embodiments can ensure memory space safety for the operation of a program (21) of an embedded system (100) by managing the memory area for the linear memory (Lin_mem), particularly the heap area of ​​the linear memory (Lin_mem), through memory boundary check.

[0109] Linear memory (Lin_mem) is a virtual memory that may include a user area, which is a unique space for executing a program (21), and the user area may include various memory areas for allocating specific memory structures. For a more specific description of linear memory (Lin_mem), refer to Fig. 4.

[0110]

[0111] FIG. 4 is a drawing for explaining the structure of a linear memory according to some embodiments of the present invention.

[0112] Referring further to FIG. 4, the linear memory (Lin_mem) may include a code area (CR), a global area (GR), a heap area (HR), a stack area (SR), and a peripheral area (PR).

[0113] The code region (CR) can be used to store the instructions and commands of a running application (APP). The program's machine code or executable instructions can be stored in the CR. The CR is generally read-only and may be an area that is not modified while the program is running.

[0114] The global area (GR) can be used to store initialized global and static variables. Variables in the global area (GR) can be preallocated and initialized when the program starts. The global area (GR) is readable and writable and can be maintained throughout the program's lifespan.

[0115] The stack area (SR) can be primarily used to store data related to function calls. When a function is called, the stack area (SR) can store local variables, function parameters, return addresses, and other data. The stack area (SR) stores data in a last-in, first-out (LIFO) structure, and data can be removed from the top of the stack area (SR) when the function returns. The stack area (SR) has a fixed size and is generally suitable for storing small-sized data.

[0116] The peripheral area (PR) may refer to a memory area reserved for data exchange between the embedded system (100) and peripheral devices. The peripheral area (PR) is used when the embedded system (100) communicates with the peripheral devices and may be primarily related to input / output operations. A peripheral device is a device that interacts with the embedded system (100), and may refer to, for example, a hard disk, a network card, a USB device, a graphics card, a sensor, etc. The peripheral area (PR) may be used when exchanging data with such peripheral devices.

[0117] The heap space (HR) can be used to store dynamically allocated data, primarily large data structures such as objects, arrays, and structures. Because the heap space (HR) is dynamically expandable, it can be suitable for storing large amounts of data.

[0118] In other words, the heap area (HR) can be primarily used to dynamically allocate and free memory. However, since memory is dynamically allocated during the execution of the program (21), it is difficult to statically determine the memory boundaries of the heap area (HR) at compile time, making it somewhat difficult to perform memory boundary checks on the heap area (HR).

[0119] In addition, dynamically allocated memory can be freed and reallocated according to the control flow of the program (21). In this case, since the memory boundaries of the heap area (HR) change dynamically, boundary checking needs to be continuously updated. Furthermore, the sizes of objects allocated to the heap area (HR) can vary, and memory boundary checking can become more complex depending on the sizes of the various objects.

[0120] In addition, in an embedded system (100), additional metadata must be maintained for each object in order to perform a memory boundary check for the heap area (HR), but it may be somewhat difficult to store metadata for all objects due to the limited memory resources of the embedded system (100).

[0121] Additionally, the heap (HR) can contain complex data structures, meaning they contain different objects and pointers. This complicates bounds checking for the HR, resulting in performance overhead.

[0122] For this reason, memory boundary checking in the heap region (HR) can be relatively difficult. Therefore, various embodiments of memory boundary checking for the heap region (HR) according to some embodiments of the present invention to address this issue are described below.

[0123]

[0124] FIG. 5 and FIG. 6 are drawings for explaining the configuration of a memory protection unit for some embodiments of the present invention.

[0125] Referring to FIG. 5, the processing module (P_md) may include hardware-level instructions (H_instr) for setting a memory protection unit. In other words, the processing module (P_md) may set and manage a memory protection unit at the hardware level. For example, when using ARMv8-M hardware-based, the processing module (P_md) may manage linear memory (Lin_mem) through eight distinct memory protection units. However, FIG. 5 is merely an exemplary drawing for convenience of explanation, and the embodiments are not to be interpreted as being limited in the number or configuration of the memory protection units. In the following, for convenience of explanation, it is assumed that the processing module (P_md) can set and manage eight distinct memory protection units.

[0126] The processing module (P_md) can perform settings for the first memory protection unit (MPU#0) to the eighth memory protection unit (MPU#7). For example, the processing module (P_md) can set the first memory protection unit (MPU#0) to have the same size as the code area (CR) and allocate the first memory protection unit (MPU#0) to the code area (CR). In addition, the processing module (P_md) can set the second memory protection unit (MPU#1) to have the same size as the global area (GR) and allocate the second memory protection unit (MPU#1) to the global area (GR). In addition, the processing module (P_md) can set the seventh memory protection unit (MPU#6) to have the same size as the stack area (SR) and allocate the seventh memory protection unit (MPU#6) to the stack area (SR). Additionally, the processing module (P_md) can set the 8th memory protection unit (MPU#7) to be the same size as the peripheral area (PR) and allocate the 8th memory protection unit (MPU#7) to the peripheral area (PR).

[0127] In other words, the processing module (P_md) sets memory protection units of the same size as the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR), respectively, and the processing module (P_md) can allocate different memory protection units to the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR).

[0128] Meanwhile, the heap area (HR) may also be allocated a memory protection unit that is distinct from the memory protection units allocated to the code area (CR), global area (GR), stack area (SR), and peripheral area (PR). However, the processing module (P_md) may allocate multiple memory protection units to the heap area (HR). For example, the processing module (P_md) may divide the heap area (HR) into four and allocate distinct memory protection units to each of the divided heap areas. For convenience of explanation, the heap areas (HR) divided by the processing module (P_md) are defined as the first heap area (Heap#0), the second heap area (Heap#1), the third heap area (Heap#2), and the fourth heap area (Heap#3), respectively.

[0129] According to some embodiments, the processing module (P_md) may allocate a third memory protection unit (MPU#2) to the first heap area (Heap#0), a fourth memory protection unit (MPU#3) to the second heap area (Heap#1), a fifth memory protection unit (MPU#4) to the third heap area (Heap#2), and a sixth memory protection unit (MPU#5) to the fourth heap area (Heap#3). For a more specific description of the first heap area (Heap#0) to the fourth heap area (Heap#3), see further FIG. 6.

[0130]

[0131] FIG. 6 is a diagram illustrating a heap area of ​​an embedded system according to some embodiments of the present invention.

[0132] Referring further to FIG. 6, the first heap area (Heap#0) may have a first size (size A). At this time, the first size (size A) of the first heap area (Heap#0) may not mean the size of the first heap area (Heap#0) itself, but may mean the maximum size of an object allocated to the first heap area (Heap#0). In other words, the size of the first object (OBJ#0) allocated to the first heap area (Heap#0) may be smaller than or equal to the first size (size A). In other words, an object larger than the first size (size A) is not allocated to the first heap area (Heap#0). Similarly, the second heap area (Heap#1) may have a second size (size B). In other words, the maximum size of the second object (OBJ#1) allocated to the second heap area (Heap#1) may be the second size (size B). That is, an object whose size is larger than the second size (size B) is not allocated to the second heap area (Heap#1). Similarly, the third heap area (Heap#2) can have a third size (size C). In other words, the maximum size of the third object (OBJ#2) allocated to the third heap area (Heap#2) can be the third size (size C). That is, an object whose size is larger than the third size (size C) is not allocated to the third heap area (Heap#2). Similarly, the fourth heap area (Heap#3) can have a fourth size (size D). In other words, the maximum size of the fourth object (OBJ#3) allocated to the fourth heap area (Heap#3) can be the fourth size (size D). That is, an object whose size is larger than the fourth size (size D) is not allocated to the fourth heap area (Heap#3).

[0133] In some embodiments, the first size (size A) to the fourth size (size D) may have different values. In the following, for convenience of explanation, it is assumed that the first size (size A) is smaller than the second size (size B), the second size (size B) is smaller than the third size (size C), and the third size (size C) is smaller than the fourth size (size D).

[0134] In some embodiments, the memory allocator (Mem_all) may allocate an object in the smallest heap area among the heap areas whose size is less than or equal to the size of the object. For example, the following description assumes that the first size (size A) is 8 bytes, the second size (size B) is 16 bytes, the third size (size C) is 32 bytes, and the fourth size (size D) is 64 bytes.

[0135] For example, if the size of an object is 8 bytes, the first heap area (Heap#0) to the fourth heap area (Heap#3) satisfy the condition that the size of the object is smaller than or equal to the size of the first heap area (Heap#0) to the fourth heap area (Heap#3). Therefore, the memory allocator (Mem_all) can allocate the object to the first heap area (Heap#0) with the smallest size among the first heap areas (Heap#0) to the fourth heap areas (Heap#3). At this time, since the first size (size A) of the first heap area (Heap#0) is 16 bytes, the remainder except for 8 bytes of the object is processed as NULL.

[0136] For another example, if the size of an object is 20 bytes, the size of the object is greater than the first size (size A) of the first heap area (Heap#0), and therefore, it cannot be allocated to the first heap area (Heap#0). Meanwhile, the second heap areas (Heap#1) to the fourth heap areas (Heap#3) each satisfy the condition that the sizes of the objects are less than or equal to the sizes of the second heap areas (Heap#1) to the fourth heap areas (Heap#3). Therefore, the memory allocator (Mem_all) can allocate the object to the second heap area (Heap#1) that has the smallest size among the second heap areas (Heap#1) to the fourth heap areas (Heap#3). To explain a method for ensuring memory space safety for heap areas, reference is made further to FIGS. 7 to 9.

[0137]

[0138] FIGS. 7 to 9 are diagrams illustrating a method for ensuring memory space safety for a heap area according to some embodiments of the present invention.

[0139] Referring further to FIG. 7, the memory management module (M_md) can receive source code (Exe_c) (S100). According to some embodiments of the present invention, the instrumentation compiler (Ins_cmp) of the memory management module (M_md) can receive the source code (Exe_c) stored in the storage module (S_md).

[0140] The memory management module (M_md) can generate instrumentation source code for the source code (Exe_c) and compile it (S200). According to some embodiments of the present invention, the instrumentation compiler (Ins_cmp) can analyze the received source code (Exe_c), add source code that performs a new function or operation, generate instrumentation source code, and compile it to generate binary code. To explain the operation of the instrumentation compiler (Ins_cmp) in more detail, reference is made to FIG. 8.

[0141] According to some embodiments of the present invention, the instrumentation compiler (Ins_cmp) can analyze the received source code (Exe_c) to identify read / write instructions. Subsequently, the instrumentation compiler (Ins_cmp) can determine object pointers and base pointers for the read / write instructions included in the source code (Exe_c) (S210).

[0142] Next, the instrumentation compiler (Ins_cmp) can generate instrumentation source code by adding code to call an object check function using an object pointer and a base pointer before a read / write instruction (S220). That is, the instrumentation compiler (Ins_cmp) can add an object check function call instruction so that the object check function precedes the identified read / write instruction. In other words, due to the instrumentation source code with the object check function call instruction added, the memory allocator (Mem_all) can be called to execute the object check function before the processing module (P_md) executes the read / write instruction.

[0143] The instrumentation compiler (Ins_cmp) can compile the instrumentation source code and generate binary code (S230). The processing module (P_md) can execute specific instructions based on the compiled binary code.

[0144]

[0145] Referring back to FIG. 7, the processing module (P_md) can set a memory protection unit (S300). As described above, the processing module (P_md) can set the size of the memory protection unit according to the size of each of the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR), and can allocate different memory protection units to the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR).

[0146] Meanwhile, the processing module (P_md) can allocate a memory protection unit different from the memory protection units allocated to the code area (CR), global area (GR), stack area (SR), and peripheral area (PR) to the heap area (HR). However, the processing module (P_md) allocates multiple memory protection units to the heap area (HR), and the heap area (HR) can be divided into multiple areas by the multiple memory protection units. In addition, the heap area (HR) divided into multiple areas can have different sizes for each heap area. In this case, the size of the heap area does not mean the size of each distinct heap area, but may mean the maximum size of an object that can be allocated to the corresponding heap area.

[0147] The processing module (P_md) can perform a memory boundary check before executing a read / write instruction (S400). That is, due to the object check function call instruction added by the instrumentation compiler (Ins_cmp), the processing module (P_md) can call the object check function before the read / write instruction, and calling the object check function is interpreted as having the same meaning as performing a memory boundary check. At this time, the operation configuration of the object check function is further described with further reference to FIG. 9.

[0148]

[0149] Referring further to Fig. 9, the processing module (P_md) calls an object check function, and the memory allocator (Mem_all) can be requested to execute the object check function from the processing module (P_md) (S410).

[0150] The memory allocator (Mem_all) can determine which memory protection unit the base pointer of an object points to by using a memory address verification instruction (S420). In other words, the memory allocator (Mem_all) can input the base pointer of an object into the memory address verification instruction to check the memory address indicated by the base pointer of the object, i.e., which memory protection unit it is. The memory address verification instruction is a hardware-based instruction. For example, the memory address verification instruction may refer to the TestTarget (TT) instruction of the ARMv8-M architecture, but the embodiments are not limited thereto. In other words, since the memory address verification instruction that operates based on hardware is executed directly at the hardware level, it can provide a faster response time than an instruction implemented in software, and can reduce the overhead that occurs when processing with software. That is, the memory allocator (Mem_all) can use hardware-based instructions provided by the hardware architecture, rather than software-based instructions, to specify the memory protection unit to which an object is allocated in order to solve the problem of low computing resources of the embedded system (100).

[0151] The memory allocator (Mem_all) can verify whether the memory protection unit determined through the memory address verification command is a heap area (HR) (S430). As described above, the heap area (HR) and the remaining areas, i.e., the code area (CR), global area (GR), stack area (SR), and peripheral area (PR), have different allocation methods for memory protection units. Therefore, the heap area (HR) and the remaining areas may perform memory boundary checks differently.

[0152] If the determined memory protection unit is a heap area (HR) (S430, Y), the memory allocator (Mem_all) can determine the maximum size of an object that can be allocated to a distinct heap area corresponding to the memory protection unit (S440). In other words, the memory allocator (Mem_all) can determine the size of the heap area corresponding to the determined memory protection unit. For example, in Fig. 6, if the memory protection unit determined through the memory address verification command is the fourth memory protection unit (MPU#3), the memory allocator (Mem_all) can determine the maximum size of an object that can be allocated to the second heap area (Heap#1), i.e., the second size (size B) of the second heap area (Heap#1).

[0153] Next, the memory allocator (Mem_all) can determine whether the difference between the pointer of the object and the base pointer exceeds the maximum size of the object that can be allocated in the heap area corresponding to the memory protection unit (S450). As described above, the heap area (HR) is divided into multiple heap areas, and each of the divided heap areas has a different size (the maximum size to which the object can be allocated). At this time, the object can be allocated to the heap area with the smallest size among one or more heap areas that satisfy the condition that the size of the object is less than or equal to the size of the heap area. In other words, the size of the object cannot but be less than or equal to the size of the divided heap area, and the difference between the pointer of the object and the base pointer must satisfy the condition that it is less than or equal to the size of the corresponding heap area.

[0154] Accordingly, the memory allocator (Mem_all) can determine that a memory boundary error has occurred (S460) if the difference between the object pointer and the base pointer exceeds the size of the corresponding distinct heap area, i.e., the maximum size of the object allocable in the corresponding distinct heap area (S450, Y). On the other hand, the memory allocator (Mem_all) can determine that the memory boundary is normal (S480) if the difference between the object pointer and the base pointer does not exceed the size of the corresponding distinct heap area, i.e., the maximum size of the object allocable in the corresponding distinct heap area (S450, N).

[0155] If the determined memory protection unit is not a heap area (HR) (S430, N), that is, if the determined memory protection unit corresponds to any one of a code area (CR), a global area (GR), a stack area (SR), and a peripheral area (PR), the memory allocator (Mem_all) can determine whether the difference between the object pointer and the base pointer exceeds the size of the corresponding memory protection unit (S470).

[0156] As mentioned above, except for the heap area (HR), the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR), all of which can have memory protection units set and allocated that are the same size as the size of each area. Therefore, the size of the objects allocated to the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR) must satisfy the condition that they are less than or equal to the size of the memory protection units corresponding to each of the code area (CR), the global area (GR), the stack area (SR), and the peripheral area (PR).

[0157] Accordingly, the memory allocator (Mem_all) can determine that a memory boundary error has occurred (S460) if the difference between the object pointer and the base pointer exceeds the size of the corresponding memory protection unit (S470, Y). On the other hand, the memory allocator (Mem_all) can determine that the memory boundary is normal (S480) if the difference between the object pointer and the base pointer does not exceed the size of the corresponding memory protection unit (S470, N).

[0158] Referring back to FIG. 7, the processing module (P_md) can determine whether to execute a read / write command based on the memory boundary check result (S500). That is, if a memory boundary error occurs as a result of the memory boundary check, the processing module (P_md) may not execute the read / write command. On the other hand, if the memory boundary check is performed and the memory boundary is normal, the processing module (P_md) can execute the read / write command.

[0159]

[0160] According to some embodiments of the present invention, there is an advantage in that security performance can be increased while minimizing the use of computing resources of an embedded system (100).

[0161]

[0162] The above description is merely an example of the technical idea of ​​the present embodiment, and those skilled in the art will appreciate that various modifications and variations can be made without departing from the essential characteristics of the present embodiment. Therefore, the present embodiments are not intended to limit the technical idea of ​​the present embodiment, but rather to explain it, and the scope of the technical idea of ​​the present embodiment is not limited by these embodiments. The scope of protection of the present embodiment should be interpreted by the claims below, and all technical ideas within a scope equivalent thereto should be interpreted as being included in the scope of rights of the present embodiment.

Claims

1. Step of receiving source code; A step of generating instrumentation code for the above source code; A step of compiling the above measurement code and running the program; A step of setting up multiple memory protection units for the heap area; and A step of performing a memory boundary check before performing a read / write command included in the above program, The step of performing the above memory boundary check uses the base pointer and pointer for the read / write command, A step of specifying one of the plurality of memory protection units using the base pointer; and A step of determining whether the heap size for the specified memory protection unit is exceeded using the base pointer and the pointer, A method for ensuring heap memory space safety in embedded systems.

2. In paragraph 1, The steps for generating the above measurement code are: A step of analyzing the source code and determining the base pointer by using the pointer to the object included in at least one of the read / write instructions; and A step of adding an object check function call instruction that takes the above pointer and the base pointer as arguments before the read / write instruction, A method for ensuring heap memory space safety in embedded systems.

3. In paragraph 2, The step of performing the above memory bounds check includes calling the object check function. A method for ensuring heap memory space safety in embedded systems.

4. In paragraph 1, The step of specifying one of the above plurality of memory protection units is: Comprising a memory address verification command and a step of using the base pointer, A method for ensuring heap memory space safety in embedded systems.

5. In paragraph 4, The above memory address check command is a hardware-based command. A method for ensuring heap memory space safety in embedded systems.

6. In paragraph 1, The step of determining whether the heap size for the above specified memory protection unit is exceeded is: Including determining whether the difference between the above pointer and the base pointer exceeds the heap size. A method for ensuring heap memory space safety in embedded systems.

7. In paragraph 1, Further comprising the step of determining a memory boundary error if the heap size for the specified memory protection unit is exceeded, and determining a memory boundary normal if the heap size for the specified memory protection unit is not exceeded. A method for ensuring heap memory space safety in embedded systems.

8. In paragraph 1, The steps for setting up multiple memory protection units for the heap area are: A step of allocating a first memory protection unit for the first heap area; and A step of allocating a second memory protection unit different from the first heap area and different from the second heap area, A method for ensuring heap memory space safety in embedded systems.

9. In paragraph 8, The first size of the first heap area is smaller than the second size of the second heap area, A method for ensuring heap memory space safety in embedded systems.

10. Processing module; and comprising a storage module connected to the above processing module; The above storage module stores instructions that cause the above processing module to execute a program, The above instructions are, Step of receiving the source code; A step of generating instrumentation code for the above source code; A step of compiling the above measurement code and running the program; A step of setting up multiple memory protection units for the heap area; and A step of performing a memory boundary check before performing a read / write command included in the above program, The step of performing the above memory boundary check uses the base pointer and pointer for the read / write command, A step of specifying one of the plurality of memory protection units using the base pointer; and A step of determining whether the heap size for the specified memory protection unit is exceeded using the base pointer and the pointer, Embedded systems.

11. In clause 10, The steps for generating the above measurement code are: A step of analyzing the source code and determining the base pointer by using the pointer to the object included in at least one of the read / write instructions; and A step of adding an object check function call instruction that takes the above pointer and the base pointer as arguments before the read / write instruction, Embedded systems.

12. In paragraph 11, The step of performing the above memory bounds check includes calling the object check function. Embedded systems.

13. In paragraph 10, The step of specifying one of the above plurality of memory protection units is: Comprising a memory address verification command and a step of using the base pointer, Embedded systems.

14. In paragraph 13, The above memory address check command is a hardware-based command. Embedded systems.

15. In paragraph 10, The step of determining whether the heap size for the above specified memory protection unit is exceeded is: Including determining whether the difference between the above pointer and the base pointer exceeds the heap size. Embedded systems.

16. In paragraph 10, Further comprising the step of determining a memory boundary error if the heap size for the specified memory protection unit is exceeded, and determining a memory boundary normal if the heap size for the specified memory protection unit is not exceeded. Embedded systems.

17. In paragraph 10, The steps for setting up multiple memory protection units for the heap area are: A step of allocating a first memory protection unit for the first heap area; and A step of allocating a second memory protection unit different from the first heap area and different from the second heap area, Embedded systems.

18. In paragraph 17, The first size of the first heap area is smaller than the second size of the second heap area, Embedded systems.

19. Storage module for storing source code; a processing module for executing a program associated with the above source code; and Including a memory management module that executes the object check function requested by the above processing module, The above object check function is, A step of determining whether the base pointer for a read / write instruction included in the above program points to the heap area; If the base pointer points to a heap area, determining whether the difference between the pointer for the read / write instruction and the base pointer exceeds the object size of the read / write instruction; and If the base pointer points to an area outside the heap area, the method comprises the step of determining whether the difference between the pointer and the base pointer exceeds the size of the area outside the heap area. Embedded systems.

20. In paragraph 19, The above object check function is, If the base pointer points to a heap area, a step of determining that a memory boundary error has occurred in the heap area if the difference between the pointer for the read / write instruction and the base pointer exceeds the object size of the read / write instruction; and If the base pointer points to an area outside the heap area, and the difference between the pointer and the base pointer exceeds the size of the area outside the heap area, the method further includes a step of determining that a memory boundary error has occurred in the area outside the heap area. Embedded systems.

Images