Patent Description:
A memory system in which different users or different processes dividedly use a memory is used. In the case of such a memory system, when an isolation in the memory separation is not apparent, there is a risk of modulation of data stored in the memory due to a malicious attacker. As a result, research for improving this problem is being conducted.

<CIT> discloses: Systems comprising: a memory; and a hardware processor and configured to: execute a hypervisor having a first portion and a second portion, wherein the first portion of the hypervisor executes at a first exception level that allows the first portion to access data of a virtual machine in the hardware processor and the memory, and wherein the second portion of the hypervisor executes at a second exception level that prevents the second portion from accessing the data of the virtual machine in the hardware processor and the memory. Methods comprising: executing a first portion of a hypervisor at a first exception level that allows the first portion to access data of a virtual machine in a hardware processor and memory; and executing a second portion of a hypervisor at a second exception level that prevents the second portion from accessing the data in the hardware processor and the memory.

<CIT> discloses: Systems and methods allow protecting a host system, such as a computer or smartphone, from malware. An anti-malware application installs a hypervisor, which displaces an operating system executing on the host system to a guest virtual machine (VM). The hypervisor further creates a set of virtual containers (VC), by setting up a memory domain for each VC, isolated from the memory domain of the guest VM. The hypervisor then maps a memory image of a malware scanner to each VC. When a target object is selected for scanning, the anti-malware application launches the malware scanner. Upon intercepting the launch, the hypervisor switches the memory context of the malware scanner to the memory domain of a selected VC, for the duration of the scan. Thus, malware scanning is performed within an isolated environment.

<CIT> discloses: A "Hypervisor Secure Container" (HSC) is a block of memory space that resides inside of a regular process, but is secured from the operating system of the computer it runs on. The HSC is a software container that runs on a hypervisor directly. Data and code within one HSC can only be accessed by the hypervisor itself and the code that belongs to the same HSC. The HSC can run in user mode or kernel mode. Advantageously, even if the operating system or user of the computer the HSC runs on is malicious, the data inside the HSC is still secure. The HSC allows software based isolation of code/data and can be used in various security contexts including securely storing certificates and passwords, performing Digital Rights Management (DRM) for media and games, and confidential computing in a computing cloud.

Provided are a memory management system and a method for managing memory having improved security reliability.

According to an aspect of an example embodiment, a memory management system includes a first virtual machine, a second virtual machine, and a hypervisor configured to manage a region to which the first virtual machine and the second virtual machine access in a memory, control the first virtual machine to access a first region and a shared region in the memory, control the second virtual machine to access the shared region and a second region different from the first region in the memory, and in response to a request of the first virtual machine, store an in-memory data isolation (IMDI) table that indicates an IMDI region that a task of the first virtual machine accesses and a task of the second virtual machine does not access, in the memory.

According to an aspect of an example embodiment, a memory management system includes a virtual machine on which a kernel level task is performed, and an IMDI circuit configured to receive an access request for an IMDI region of a memory from the kernel level task of the virtual machine, and determine whether to permit an access of the kernel level task of the virtual machine to the IMDI region, based on reference to a virtual machine ID and a task ID of an IMDI table that is stored in the memory and indicates the IMDI region.

However, aspects of the present invention are not restricted to the one set forth herein. The above and other aspects of the present invention will become more apparent to one of ordinary skill in the art to which the present invention pertains by referencing the detailed description of the present invention given below.

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. The embodiments described herein are example embodiments, and thus, the disclosure is not limited thereto and may be realized in various other forms.

<FIG> is a block diagram of a memory management system according to an example embodiment.

Referring to <FIG>, the memory management system <NUM> may include virtual machines <NUM> and <NUM>, a hypervisor <NUM>, a processor <NUM>, and an in-memory data isolation (IMDI) circuit <NUM>. Although the drawings show an example in which there are two virtual machines <NUM> and <NUM>, the number of virtual machines <NUM> and <NUM> may be modified as much as possible.

In some embodiments, the memory management system <NUM> may be configured to further include a memory <NUM>.

The memory management system <NUM> may manage the memory <NUM>. For example, the memory management system <NUM> may dividedly manage a region to which the virtual machine <NUM> is accessible and a region to which the virtual machine <NUM> is accessible, in the memory <NUM>.

The virtual machine <NUM> may be driven by a guest operating system (OS) <NUM>. The guest OS <NUM> may process a process requested by a user or a user process connected through the virtual machine <NUM>.

The virtual machine <NUM> may be driven by the guest OS <NUM>. The guest OS <NUM> may process a process requested by a user or a user process connected through the virtual machine <NUM>.

In some embodiments, the guest OS <NUM> and the guest OS <NUM> may be different operating systems from each other. For example, the guest OS <NUM> may be an android operating system, and the guest OS <NUM> may be a Linux operating system. Further, in some embodiments, the guest OS <NUM> and the guest OS <NUM> may be the same operating system to each other.

The hypervisor <NUM> may dividedly manage the region to which the virtual machine <NUM> is accessible and the region to which the virtual machine <NUM> is accessible, in the memory <NUM>.

In some embodiments, the memory <NUM> may include a dynamic random access memory (DRAM). In some embodiments, the memory <NUM> may include a double data rate synchronous DRAM (DDR SDRAM), a high bandwidth memory (HBM), a hybrid memory cube (HMC), a dual in-line memory module (DIMM), an optane DIMM or a non-volatile DIMM (NVMDIMM).

Further, in some embodiments, the memory <NUM> may include a non-volatile memory such as a NAND flash memory, a magnetic RAM (MRAM), a spin-transfer torque MRAM, a conductive bridging RAM (CBRAM), a ferroelectric RAM (FeRAM), a phase RAM (PRAM) and a resistive memory (resistive RAM).

A second level address translation (SLAT) module <NUM> of the hypervisor <NUM> may perform a second levels address translation for dividedly managing the region to which the virtual machine <NUM> is accessible and the region to which the virtual machine <NUM> is accessible, in the memory <NUM>. Here, the guest OSs <NUM> and <NUM> may perform the first level address translation. A more specific explanation thereof will be provided below.

The processor <NUM> may perform the process necessary in the memory management system <NUM>. The processor <NUM> may include a plurality of memory management units (MMU) <NUM> and <NUM>. According to embodiments, the numbers of MMUs <NUM> and <NUM> may be modified differently from those shown.

A MMU <NUM> may be used to perform the first level address translation by the guest OSs <NUM> and <NUM>. The guest OSs <NUM> and <NUM> may translate the virtual address provided to the virtual machines <NUM> and <NUM> into a first physical address, using the MMU <NUM>.

A MMU <NUM> may be used to perform a second level address translation by a SLAT module <NUM>. The SLAT module <NUM> may translate the first physical address provided from the virtual machines <NUM> and <NUM> into the second physical address, using the MMU <NUM>.

In some embodiments, the first physical address and the second physical address may be different physical addresses from each other. Further, in some embodiments, the first physical address and the second physical address may be the same physical address to each other.

An IMDI circuit <NUM> may determine whether to permit an access of the virtual machines <NUM> and <NUM> to the IMDI region defined in the memory <NUM>. For example, the IMDI circuit <NUM> may determine whether to permit an access of each task of the virtual machines <NUM> and <NUM> to the IMDI region defined in the memory <NUM>. A more specific explanation thereof will also be provided below.

Although the drawings show an example in which the MMU <NUM> and the IMDI circuit <NUM> are separately implemented, in some embodiments, the IMDI circuit <NUM> may be implemented to be included in the MMU <NUM>.

In some embodiments, the virtual machines <NUM> and <NUM> and the hypervisor <NUM> are implemented as software, and the processor <NUM> and the IMDI circuit <NUM> may be implemented as hardware. However, the embodiments are not limited thereto, and the embodiment may be changed as needed.

<FIG> is a diagram of a memory management operation of a hypervisor of <FIG>, according to an example embodiment.

Referring to <FIG>, the memory <NUM> may include a first region R1 to which only the virtual machine <NUM> is accessible, a second region R2 to which only the virtual machine <NUM> is accessible, and a shared region SR to which both the virtual machine <NUM> and the virtual machine <NUM> are accessible. Further, the memory <NUM> may include a SLAT table ST stored in a hypervisor region HV, to which the virtual machine <NUM> and the virtual machine <NUM> are inaccessible and to which only the hypervisor <NUM> is accessible.

The SLAT table ST may be a table used to perform a second level address translation by the SLAT module <NUM>.

Referring to <FIG>, in operation S10, the virtual machine <NUM> translates the virtual address into a first physical address using the MMU (<NUM> of <FIG>), and requests the hypervisor <NUM> to access the first region R1.

In response thereto, in operation S11, the SLAT module <NUM> of the hypervisor <NUM> translates the first physical address into the second physical address using the MMU (<NUM> of <FIG>) and the SLAT table ST, and the hypervisor <NUM> checks whether the virtual machine <NUM> has an access right to the first region R1.

In operation S12, when the hypervisor <NUM> permits an access, the virtual machine <NUM> can access the first region R1 to write data or read the stored data.

Next, in operation S20, the virtual machine <NUM> translates the virtual address into the first physical address using the MMU (<NUM> of <FIG>), and requests the hypervisor <NUM> to access the shared region R1.

In response thereto, in operation S21, the SLAT module <NUM> of the hypervisor <NUM> translates the first physical address into the second physical address using the MMU (<NUM> of <FIG>) and the SLAT table ST, and the hypervisor <NUM> checks whether the virtual machine <NUM> has the access right to the shared region SR.

In operation S22, when the hypervisor <NUM> permits an access, the virtual machine <NUM> can access the shared region SR to write data or read the stored data.

Next, in operation S30, the virtual machine <NUM> translates the virtual address into the first physical address using the MMU (<NUM> of <FIG>), and requests the hypervisor <NUM> to access the second region R2.

In response thereto, in operation S31, the SLAT module <NUM> of the hypervisor <NUM> translates the first physical address into the second physical address, using the MMU (<NUM> of <FIG>) and the SLAT table ST, and the hypervisor <NUM> checks whether the virtual machine <NUM> has the access right to the second region R2.

In operation S32, when the hypervisor <NUM> permits an access, the virtual machine <NUM> can access the second region R2 to write data or read the stored data.

On the other hand, although not shown in the drawing in detail, when the virtual machine <NUM> translates the virtual address into the first physical address using the MMU (<NUM> of <FIG>) and requests the hypervisor <NUM> to access the second region R2, the hypervisor <NUM> checks that the virtual machine <NUM> has no access right to the second region R2 using the MMU (<NUM> of <FIG>) and the SLAT table ST, and then may block an access of the virtual machine <NUM> to the second region R2.

Similarly, when the virtual machine <NUM> translates the virtual address into the first physical address using the MMU (<NUM> of <FIG>) and requests the hypervisor <NUM> to access the first region R1, the hypervisor <NUM> checks that the virtual machine <NUM> has no access right to the first region R1 using the MMU (<NUM> of <FIG>) and the SLAT table ST, and then may block the access of the virtual machine <NUM> to the first region R1.

Referring to <FIG>, a plurality of tasks may be performed on the virtual machines <NUM> and <NUM>. Such a plurality of tasks may include user level tasks U1 to U4 and kernel level tasks K1 to K4. The user level tasks U1 to U4 are tasks that exist in a user space of virtual machines <NUM> and <NUM>, and the kernel level tasks K1 to K4 are tasks that exist in the kernel space of the virtual machines <NUM> and <NUM>.

The user level tasks U1 to U4 are controlled by the guest OS and have less right than those of the virtual machines <NUM> and <NUM>. That is, the virtual machine <NUM> has an access right to the first region R1 and the shared region SR of the memory <NUM>, but the user level tasks U1 and U3 are controlled by the guest OS and do not have the same right as the access right of the virtual machine <NUM>. Further, the virtual machine <NUM> has an access right to the second region R2 and the shared region SR of the memory <NUM>, but the user level tasks U2 and U4 are controlled by the guest OS and do not have the same right as the access right of the virtual machine <NUM>.

On the other hand, the kernel level tasks K1 to K4 have the same access right as the access right of the virtual machines <NUM> and <NUM> described above. That is, when the virtual machine <NUM> has the access right to the first region R1 and the shared region SR of the memory <NUM>, the kernel level tasks K1 and K3 also have the same right as the access right of the virtual machine <NUM>. When the virtual machine <NUM> has the access right to the second region R2 and the shared region SR of the memory <NUM>, the kernel level tasks K2 and K4 may also have the same right as the access right of the virtual machine <NUM>.

In a situation in which the kernel level task K1 of the virtual machine <NUM> and the kernel level task K2 of the virtual machine <NUM> perform the shared task in the shared region SR of the memory <NUM>, when the kernel level task K3 of the virtual machine <NUM> is maliciously seized, a malicious attacker may arbitrarily transform the data stored in the shared region SR of the memory <NUM>, using the kernel level task K3.

Accordingly, a configuration for preventing this may be required, and such an attack can be prevented, using the hypervisor <NUM> and the IMDI circuit (<NUM> of <FIG>) of the present embodiment. Hereinafter, this will be described more specifically.

<FIG> is a diagram of an operation in which the hypervisor of <FIG> generates an IMDI table according to an example embodiment. <FIG> is a diagram of the IMDI table of <FIG> according to an example embodiment.

Referring to <FIG>, in operation S100, a kernel level task K1 of the virtual machine <NUM> requests the hypervisor <NUM> to specify an IMDI region IR to which the kernel level task K1 is accessible.

In some embodiments, such a request may be made, using a hypervisor call provided by the hypervisor <NUM>. That is, the hypervisor <NUM> according to the present embodiment may be a para-virtualized hypervisor.

Next, in operation S110, the hypervisor <NUM> stores the IMDI table IT that indicates the IMDI region IR in the hypervisor region HV of the memory <NUM>, in response to the request.

Referring to <FIG> and <FIG>, such an IMDI table IT may include a virtual machine ID (VMID), a task ID (TUID), a starting address of an IMDI region IT, and a size of the IMDI region IT.

<FIG> shows an example of an IMDI table IT in which the kernel level task K1 of the virtual machine <NUM> has an access right and indicates the IMDI region IR of size b from the starting address a. The IMDI region IR corresponding to the memory <NUM> may be defined according to the storage contents of the IMDI table IT.

Such an IMDI region IR may be defined in the hypervisor region HV. That is, in the present embodiment, the SLAT table ST and the IMDI table IT may be stored in the hypervisor region HV of the memory <NUM>, and the IMDI region IR may be defined in the hypervisor region HV.

Next, in operation S120, the hypervisor <NUM> stores the IMDI table IT in the memory <NUM>, and then may transmit information about the generated IMDI region IR to the virtual machine <NUM>.

<FIG> is a diagram of an operation in which a first task of a first virtual machine accesses an IMDI region according to an example embodiment.

Referring to <FIG>, in operation S200, the kernel level task K1 of the virtual machine <NUM> requests the SLAT module <NUM> of the hypervisor <NUM> to access the IMDI region IR.

In response thereto, in operation S210, the SLAT module <NUM> refers to the SLAT table ST of the memory <NUM>.

When the determination is made on the basis of the stored contents of the SLAT table ST, since the region requested to be accessed by the kernel level task K1 of the virtual machine <NUM> is not the first region (R1 of <FIG>) or the shared region (SR of <FIG>) in which the access is permitted to the virtual machine <NUM>, the SLAT module <NUM> will determine that an access of the kernel level task K1 of the virtual machine <NUM> to the IMDI region IR is not possible.

However, in operation S220, the SLAT module <NUM> does not directly respond to the inaccessibility to the virtual machine <NUM>, and checks in the IMDI circuit <NUM> whether the kernel level task K1 of the virtual machine <NUM> can access the IMDI region IR.

In response thereto, in operation S230, the IMDI circuit <NUM> checks the IMDI table IT.

Further, if the region required to be accessed by the kernel level task K1 of the virtual machine <NUM> is determined to be within the region shown in <FIG>, the IMDI circuit <NUM> permits an access. If the region required to be accessed by the kernel level task K1 of the virtual machine <NUM> is determined to be outside the region shown in <FIG>, the IMDI circuit <NUM> may deny the access.

When the IMDI circuit <NUM> permits the access, the kernel level task K1 of the virtual machine <NUM> can access the IMDI region IR to write data or read stored data (S240).

<FIG> is a diagram of the operation in which a task of a second virtual machine access the IMDI region according to an example embodiment.

Referring to <FIG>, in operation S300, the kernel level task K2 of the virtual machine <NUM> requests the SLAT module <NUM> of the hypervisor <NUM> to access the IMDI region IR.

In response thereto, in operation S310, the SLAT module <NUM> refers to the SLAT table ST of the memory <NUM>.

When the determination is made on the basis of the stored contents of the SLAT table ST, the region requested to be accessed by the kernel level task K2 of the virtual machine <NUM> is not the second region (R2 of <FIG>) or the shared region (SR of <FIG>) in which the access is permitted to the virtual machine <NUM>, the SLAT module <NUM> will determine that an access of the kernel level task K2 of the virtual machine <NUM> to the IMDI region IR is not possible.

However, in operation S320, the SLAT module <NUM> does not directly respond to the inaccessibility to the virtual machine <NUM>, and checks in the IMDI circuit <NUM> whether the kernel level task K2 of the virtual machine <NUM> can access the IMDI region IR.

In response thereto, in operation S330, the IMDI circuit <NUM> checks the IMDI table IT.

In the IMDI table IT shown in <FIG>, since the IMDI region IR permitted to the kernel level task K2 of the virtual machine <NUM> does not exist, the IMDI circuit <NUM> does not permit the access. As a result, in operation S340, the kernel level task K2 of the virtual machine <NUM> cannot access the IMDI region IR.

<FIG> is a diagram of an operation in which a second task of the first virtual machine accesses the IMDI region according to an example embodiment.

Referring to <FIG>, in operation S400, the kernel level task K1 of the virtual machine <NUM> requests the SLAT module <NUM> of the hypervisor <NUM> to access the IMDI region IR.

In response thereto, in operation S410, the SLAT module <NUM> refers to the SLAT table ST of the memory <NUM>.

When the determination is made on the basis of the stored contents of the SLAT table ST, the region requested to be accessed by the kernel level task K3 of the virtual machine <NUM> is not the first region (R1 of <FIG>) or the shared region (SR of <FIG>) in which the access is permitted to the virtual machine <NUM>, the SLAT module <NUM> will determine that access of the kernel level task K3 of the virtual machine <NUM> to the IMDI region IR is not possible.

However, in operation S420, the SLAT module <NUM> does not directly respond to the inaccessibility to the virtual machine <NUM>, and checks in the IMDI circuit <NUM> whether the kernel level task K3 of the virtual machine <NUM> can access the IMDI region IR.

In response thereto, in operation S430, the IMDI circuit <NUM> checks the IMDI table IT.

In the IMDI table IT shown in <FIG>, the kernel level task K1 of the virtual machine <NUM> is permitted to access the IMDI region IR, but the kernel level task K3 of the virtual machine <NUM> is not permitted to access the IMDI region IR. Therefore, the IMDI circuit <NUM> does not permit the access. As a result, in operation S440, the kernel level task K3 of the virtual machine <NUM> cannot access the IMDI region IR.

<FIG> is a diagram for explaining the operation of the IMDI circuit of <FIG>.

Referring to <FIG>, an access request including address information GPA of an access target region, a size SIZE of the access target region, an ID VMID of the virtual machine, and the task ID ID is provided from the task of the virtual machine, and, in operation S500, the IMDI circuit <NUM> checks an access permission to the memory region requested to be accessed by the task of the virtual machine through the second level address translation SLAT.

In some embodiments, the address information GPA of the access target region may be, for example, the first physical address described above, but the embodiments are not limited thereto.

Further, in operation S510, the IMDI circuit <NUM> determines whether the memory region requested to be accessed by the task of the virtual machine can be accessed through the second level address translation.

If it is determined that the memory region requested to be accessed by the task of the virtual machine can be accessed through the second level address translation SLAT (operation S510-Y), the access to the region is permitted.

If it is determined that the memory region requested to be accessed by the task of the virtual machine cannot be accessed through the second level address translation (operation S510-N), in operation S520, it is determined whether the memory region requested to be accessed by the task of the virtual machine corresponds to the IMDI region that is set through the IMDI table.

If the memory region requested to be accessed by the task of the virtual machine does not correspond to the IMDI region that is set through the IMDI table (operation S520-N), accessibility is notified to the task of the virtual machine.

If the memory region requested to be accessed by the task of the virtual machine corresponds to the IMDI region that is set through the IMDI table (operation S520-Y), in operation S530, it is determined whether the virtual machine ID of the requested virtual machine is a virtual machine ID that is registered in the IMDI region of the IMDI table.

If the virtual machine ID of the requested virtual machine ID is not the virtual machine ID registered in the IMDI region of the IMDI table (operation S530-N), accessibility is notified to the task of the virtual machine.

If the virtual machine ID of the requested virtual machine is the virtual machine ID registered in the IMDI region of the IMDI table (operation S530-Y), in operation S540, it is determined whether the task ID of the requested virtual machine is the task ID registered in the IMDI region of the IMDI table (S540).

If the task ID of the requested virtual machine ID is not the task ID registered in the IMDI region of the IMDI table (operation S540-N), accessibility is notified to the task of the virtual machine.

If the task ID of the requested virtual machine is the task ID registered in the IMDI region of the IMDI table (operation S540-Y), an access to the region is permitted.

In the present embodiment, the security reliability of the memory management system can be improved, by defining an IMDI region that grants an access right to the memory for each task of the virtual machine and managing the IMDI region using the IMDI table.

<FIG> is a block diagram of the memory management system according to an example embodiment. Hereinafter, differences from the above-described embodiment will be mainly described.

Referring to <FIG>, a memory management system <NUM> may include virtual machines <NUM> and <NUM> and a hypervisor <NUM>. Although not shown in detail, the memory management system <NUM> may include the processor <NUM>, and the IMDI circuit <NUM> shown in <FIG>.

The memory management system <NUM> may be, for example, a memory management system that supports a multi-tenant system. The virtual machine <NUM> may be connected to a first user US1 to perform a request of the first user US1, and the virtual machine <NUM> may be connected to a second user US2 to perform a request of the second user US2.

In some embodiments, the first user US1 and the second user US2 may be different users from each other. Further, in some embodiments, the first user US1 and the second user US2 may be different user processes of one user. Furthermore, in some other embodiments, the first user US1 and the second user US2 may be different user processes of different users.

<FIG> is a diagram of a vehicle equipped with the memory management system according to an example embodiment. <FIG> is a block diagram of the memory management system of <FIG> according to an example embodiment.

A vehicle <NUM> may include a plurality of electronic control units (ECU) <NUM>, a memory management system <NUM>, and a memory <NUM>.

Each electronic control device of the plurality of electronic control devices <NUM> is electrically, mechanically, and communicatively connected to at least one of the plurality of devices provided in the vehicle <NUM>, and may control the operation of at least one device on the basis of any one function execution command.

Here, the plurality of devices may include an acquiring device <NUM> that acquires information required to perform at least one function, and a driving unit <NUM> that performs at least one function.

For example, the acquiring device <NUM> may include various detecting units and image acquiring units. The driving unit <NUM> may include a fan and compressor of an air conditioner, a fan of a ventilation device, an engine and a motor of a power device, a motor of a steering device, a motor and a valve of a brake device, an opening/closing device of a door or a tailgate, and the like.

The plurality of electronic control devices <NUM> may communicate with the acquiring device <NUM> and the driving unit <NUM> using, for example, at least one of an Ethernet, a low voltage differential signaling (LVDS) communication, and a local interconnect network (LIN) communication.

The plurality of electronic control devices <NUM> determine whether there is a need to perform the function on the basis of the information acquired through the acquiring device <NUM>, and when it is determined that there is a need to perform the function, the plurality of electronic control devices <NUM> control the operation of the driving unit <NUM> that performs the function, and may control an amount of operation on the basis of the acquired information. At this time, the plurality of electronic control devices <NUM> may store the acquired information in the memory <NUM>, or may read and use the information stored in the memory <NUM>. The memory management system <NUM> may receive requests of the plurality of electronic control devices <NUM> to store information in the memory <NUM>, or provide the information stored in the memory <NUM> to the plurality of electronic control devices <NUM>.

Referring to <FIG> and <FIG>, the memory management system <NUM> may include virtual machines <NUM> and <NUM> and a hypervisor <NUM>. Although not shown in detail, the memory management system <NUM> may include the processor <NUM>, the IMDI circuit <NUM> shown in <FIG>.

A virtual machine <NUM> may be connected to the first electronic control device 210a to perform a request of the first electronic control device 210a, and the virtual machine <NUM> may be connected to the second electronic control device 210b to perform a request of the second electronic control device 210b.

In some embodiments, the first electronic control device 210a is a device that collects and processes information from the acquiring device <NUM>, and the second electronic control device 210b may be a device that controls the operation of the driving unit <NUM>. In some embodiments, the first electronic control device 210a may be a device that processes infotainment, and the second electronic control device 210b may be a device that processes operating information of the vehicle. However, the embodiments are not limited thereto.

Referring to <FIG>, the plurality of electronic control devices <NUM> is able to control the operation of the driving unit <NUM> that performs the function on the basis of the function execution command that is input through the input unit <NUM>, and is also able to check a setting amount corresponding to the information that is input through the input unit <NUM> and control the operation of the driving unit <NUM> that performs the function on the basis of the checked setting amount.

Each electronic control device <NUM> may control any one function independently, or may control any one function in cooperation with other electronic control devices.

For example, when a distance to an obstacle detected through a distance detection unit is within a reference distance, an electronic control device of a collision prevention device may output a warning sound for a collision with the obstacle through a speaker.

An electronic control device of an autonomous driving control device may receive navigation information, road image information, and distance information to obstacles in cooperation with the electronic control device of the vehicle terminal, the electronic control device of the image acquisition unit, and the electronic control device of the collision prevention device, and control the power device, the brake device, and the steering device using the received information, thereby performing the autonomous driving.

A connectivity control unit (CCU) <NUM> is electrically, mechanically, and communicatively connected to each of the plurality of electronic control devices <NUM>, and communicates with each of the plurality of electronic control devices <NUM>.

That is, the connectivity control unit <NUM> is able to directly communicate with a plurality of electronic control devices <NUM> provided inside the vehicle, is able to communicate with an external server, and is also able to communicate with an external terminal through an interface.

Here, the connectivity control unit <NUM> may communicate with the plurality of electronic control devices <NUM>, and may communicate with a server <NUM>, using an antenna (not shown) and a radio frequency (RF) communication.

Further, the connectivity control unit <NUM> may communicate with the server <NUM> by wireless communication. At this time, the wireless communication between the connectivity control unit <NUM> and the server <NUM> may be performed through various wireless communication methods such as a global system for mobile communication (GSM), a code division multiple access (CDMA), a wideband CMDA (WCDMA), a universal mobile telecommunications system (UMTS), a time division multiple access (TDMA), and a long term evolution (LTE), in addition to a Wifi module and a Wireless broadband module.

Claim 1:
A memory management system (<NUM>, <NUM>, <NUM>) comprising:
a first virtual machine (<NUM>, <NUM>, <NUM>);
a second virtual machine (<NUM>, <NUM>, <NUM>); and
a hypervisor (<NUM>, <NUM>, <NUM>) configured to:
manage a region to which the first virtual machine (<NUM>, <NUM>, <NUM>) and the second virtual machine (<NUM>, <NUM>, <NUM>) access in a memory (<NUM>, <NUM>),
control the first virtual machine (<NUM>, <NUM>, <NUM>) to access a first region (R1) and a shared region (SR) in the memory (<NUM>, <NUM>) and not to access a second region (R2) different from the first region (R1) in the memory (<NUM>, <NUM>),
control the second virtual machine (<NUM>, <NUM>, <NUM>) to access the shared region (SR) and the second region (R2) in the memory (<NUM>, <NUM>) and not to access the first region (R1) in the memory (<NUM>, <NUM>), and
in response to a request of the first virtual machine (<NUM>, <NUM>, <NUM>), store an in-memory data isolation, IMDI, table that indicates an IMDI region (IR) that a task of the first virtual machine (<NUM>, <NUM>, <NUM>) accesses and a task of the second virtual machine (<NUM>, <NUM>, <NUM>) does not access, in the memory (<NUM>, <NUM>).