Information processing device and information processing method

Abstract

The present invention implements fine-grained control of system calls. This information processing device is provided with: an identification unit for outputting identification results, which are the results of identifying a system call used by a first application and the arguments of the system call, using, as inputs, the first application, file access information, which is information indicating a file accessible by the first application, and a system call list defining system calls to be monitored; and a control unit for controlling whether or not to issue a system call requested by the first application, using the identification results as inputs.

Description

Information processing device and information processing method

[0001] The technology disclosed in this specification relates to information processing technology.

[0002] Malware attacks can have adverse effects on systems while programs are running. If a malware attack targets a car, it could have an impact not only on the system but also on the human body.

[0003] Therefore, it is necessary to minimize the damage caused by malware attacks. To minimize the damage, it is necessary to quickly detect attacks and impose restrictions on programs. One example of a method for quickly detecting attacks is to monitor system calls that act as a bridge between the user space and the OS space in a system (see, for example, Patent Document 1).

[0004] International Publication No. 2019 / 150699

[0005] However, even with the system call monitoring method described in Patent Document 1, it may be difficult to ensure sufficient security against malware attacks, etc. Therefore, finer-grained control of system calls is desired.

[0006] The technology disclosed in this specification has been made in consideration of the problems described above, and is a technology for realizing fine-grained control of system calls.

[0007] An information processing device that is a first aspect of the technology disclosed in the present specification includes an identification unit that receives as input a first application, file access information that is information indicating files that the first application can access, and a system call list that defines system calls to be monitored, and outputs an identification result that is the result of identifying the system calls and arguments of the system calls used in the first application, and a control unit that receives as input the identification result and controls whether or not to issue the system calls requested by the first application.

[0008] According to at least the first aspect of the technology disclosed in the present specification, the system call is identified, including its arguments, and the identification result is used as input to control whether or not the system call can be issued, thereby enabling fine-grained control of system calls.

[0009] Furthermore, objects, features, aspects, and advantages associated with the technology disclosed herein will become more apparent from the detailed description and accompanying drawings set forth below.

[0010] FIG. 17 is a diagram conceptually illustrating an example of the configuration of an autonomous driving system according to an embodiment. FIG. 18 is a diagram conceptually illustrating an example of the configuration of an information processing device according to an embodiment. FIG. 19 is a diagram conceptually illustrating an example of the configuration of a Container Runtime according to an embodiment. FIG. 20 is a diagram conceptually illustrating an example of file access information. FIG. 21 is a diagram conceptually illustrating an example of a system call list. FIG. 22 is a flowchart illustrating an example of a process from when an identification unit creates a Container to when the Container is executed. FIG. 23 is a flowchart illustrating an example of a process from when an identification unit creates a Container to when the Container is executed. FIG. 24 is a diagram conceptually illustrating an example of a process from when an identification unit creates a Container to when the Container is executed. FIG. 3 is a diagram showing an example of a control log which is an output of a control unit. FIG. 4 is a diagram conceptually showing an example of the configuration of an information processing device according to an embodiment. FIG. 5 is a diagram conceptually showing an example of the configuration of a Container Runtime according to an embodiment. FIG. 6 is a diagram schematically illustrating a hardware configuration when the information processing device, an example of which is shown in FIG. 3, is actually operated. FIG. 7 is a diagram schematically illustrating a hardware configuration when the information processing device, an example of which is shown in FIG. 3, is actually operated.

[0011] Hereinafter, embodiments will be described with reference to the accompanying drawings. In the following embodiments, detailed features are shown for the purpose of explaining the technology, but these are merely examples and are not necessarily essential features for enabling the embodiments to be implemented.

[0012] The drawings are schematic, and for the sake of convenience, components may be omitted or simplified as appropriate. The relative sizes and positions of components shown in different drawings are not necessarily accurately depicted and may be changed as appropriate. Hatching may also be used in drawings such as plan views that are not cross-sectional views to facilitate understanding of the embodiments.

[0013] In the following description, the same components are denoted by the same reference numerals, and their names and functions are also the same. Therefore, detailed descriptions of them may be omitted to avoid duplication.

[0014] Furthermore, in the description given in this specification, when a certain component is described as "comprising," "including," or "having," unless otherwise specified, this is not an exclusive expression that excludes the presence of other components.

[0015] Furthermore, in the description of this specification, even if ordinal numbers such as "first" or "second" are used, these terms are used for convenience to make it easier to understand the contents of the embodiments, and the contents of the embodiments are not limited to the order that may result from these ordinal numbers.

[0016] 1 is a diagram conceptually illustrating an example of the configuration of an automated driving system according to this embodiment. The automated driving system 1 described below is mounted on a vehicle such as a passenger car.

[0017] As shown in the example of FIG. 1, the autonomous driving system 1 includes an information processing device 100, various electronic control units (ECUs), such as a human machine interface (HMI)-ECU 2000, a driver monitoring system (DMS)-ECU 3000, advanced driver assistance systems (ADAS)-ECU 4000, a control-ECU 5000, and a camera-ECU 6000, and a communication line 7000 that connects these ECUs and the information processing device 100 so that they can communicate with each other. The information processing device 100 includes a central processing unit (CPU) 101, a memory 102, and an auxiliary storage device 103. It goes without saying that the technology described in this embodiment can be applied to systems other than autonomous driving systems.

[0018] First Embodiment An information processing device and an information processing method according to this embodiment will be described. In the following description, components similar to those described in the above embodiments will be denoted by the same reference numerals, and detailed descriptions thereof will be omitted as appropriate.

[0019] <Configuration of Information Processing Device> Fig. 2 is a diagram conceptually illustrating an example of the configuration of the information processing device 100 according to this embodiment. As illustrated in Fig. 2, the information processing device 100 includes an operating system (OS) Kernel 120, a Container Runtime 110, and N Containers 131, 132, ..., 13N. Note that the N Containers may be 10 or more.

[0020] The kernel 120 has a system call interface 121 that serves as a processing interface from the user space to the OS space.

[0021] The Container Runtime 110 controls the containers. In the Container Runtime 110, N containers, ie, Container 131, Container 132, . . . , Container 13N, are running.

[0022] In this embodiment, the information processing device 100 is assumed to be a network-ECU. Also, App 140, which is an application in Container 131, is assumed to be a target of tracing system call issuance. App 140 is described as an application that monitors the status of communication with the outside.

[0023] Fig. 3 is a diagram conceptually illustrating an example of the configuration of the Container Runtime 110 according to this embodiment. As illustrated in Fig. 3, the Container Runtime 110 includes an identification unit 170 and a control unit 190. Note that Fig. 3 only illustrates some of the functions of the Container Runtime 110, and the Container Runtime 110 may be provided with functional units other than the identification unit 170 and the control unit 190.

[0024] The identification unit 170 takes as input the App 140 to be tracked, file access information 150 which is information about the files accessed by the App 140, and a system call list 160 issued by the App 140, and outputs an identification result 180 which is the result of identifying the system call or the arguments of the system call.

[0025] The control unit 190 receives the identification result 180 as input and controls (controls whether or not to issue) the system call requested by the application 140. The control unit 190 then outputs a control log 200, which is a record of the control of the system call.

[0026] <Identification Unit> <File Access Information> Fig. 4 is a diagram showing an example of the file access information 150. The file access information 150 includes a directory 151, a flag 152, a mode 153, and an access permission 154.

[0027] Directory 151, which is information indicating the location of a file, includes both directories that allow access to App 140 and directories that do not allow access to App 140. Flag 152 indicates access permission information for the file. For example, O_RDONLY indicates read-only, O_RDWR indicates both read and write, and O_CREAT indicates that a new file should be created if the file does not exist.

[0028] The mode 153 indicates the file mode (file ownership) of the file. The mode 153 S_IRWXU illustrated in FIG. 4 indicates that the file owner has read, write, and execute permissions. The access permission 154 is a flag indicating whether or not to permit file access when App 140 accesses the file using the directory 151, flag 152, and mode 153. In the example of FIG. 4, the setting is to deny access to the / lib / modules / directory.

[0029] 5 is a diagram showing an example of the system call list 160. The system call list 160 may be defined (prepared) in advance, or may be created outside the Container Runtime 110.

[0030] The system call list 160 includes a system call 161 and an argument 162 for the system call 161 .

[0031] The system call list 160 shows a list of system calls 161 used by App 140. The example in Fig. 5 shows that the openat2, read, and fstat system calls 161 are used by App 140. The system calls 161 need to be prepared in advance, and in this case, in the case of Linux (registered trademark), strace may be used to trace the system calls 161 to be used.

[0032] The argument 162 indicates which argument of the system call 161 is to be monitored. In the example of FIG. 5 , the first and third arguments of the argument 162 of the system call 161 of openat2 are to be tracked. Furthermore, because the third argument of openat2 is a structure, the first member of the structure, argument 3-1, is also to be monitored. In FIG. 5 , read indicates that only the first argument is to be monitored, and the other arguments are not to be monitored. On the other hand, fstat indicates that all arguments are not to be monitored. The arguments to be monitored may be determined by checking the definition of the system call 161 and comparing it with the requirements of App 140. In this embodiment, in order to monitor access to the directory 151 described in the file access information 150, the system call 161 required for reading and writing files is to be monitored. Furthermore, among these, the argument 162 of the system call 161 that can identify the file to be read or written is to be monitored.

[0033] <Processing Contents of Identification Unit> The processing of the identification unit 170 can be broadly divided into two parts. One is processing in which the identification unit 170 of the Container Runtime 110 creates a Container 131 from predefined file access information 150 and a system call list 160, and then executes the Container 131. The other is processing in which the identification unit 170 monitors the system calls 161 executed by the App 140 in the Container 131.

[0034] FIG. 6 is a flowchart showing an example of processing from when the identification unit 170 creates the Container 131 to when the Container 131 is executed.

[0035] First, in step ST1701, the file access information 150 is read. Next, in step ST1702, the system call list 160 is read. Note that these steps may be reversed.

[0036] Next, in step ST1703, the monitoring items of the system call 161 are set, and a configuration file to be used when creating a container in the Container Runtime 110 is created. The format of the configuration file is preferably the JSON format used by the OCI-compliant Container Runtime 110. The configuration file includes information on the directory 151, flag 152, mode 153, and access permission 154 described in the file access information 150. In addition, information on the system call list 160 is also included.

[0037] Finally, in step ST1704, the Container Runtime 110 creates and executes the Container 131 from the configuration file. The method of monitoring the system call 161 set in step ST1703 when creating the Container 131 may use, for example, an extended Berkeley Packet Filter (eBPF) in Linux (registered trademark).

[0038] FIG. 7 is a flowchart showing an example of a process in which the identification unit 170 monitors the system call 161 executed by the App 140 in the Container 131 .

[0039] First, in step ST1711, the identification unit 170 hooks the system call 161 executed by the App 140 and identifies the system call 161 and the arguments 162 used. In Linux (registered trademark), the values ​​of the CPU's standard registers are stored in the pt_regs structure, which is a structure at the time the system call 161 is issued. Since the number of the system call 161 or the arguments 162 of the system call 161 are stored in register numbers determined by the ABI (Application Binary Interface), the contents of the register to be referenced can be read from the members of the pt_regs structure. For example, in the x86-64 architecture, the number of the system call 161 is stored in the rax register, the first argument is stored in the rdi register, and the second argument is stored in the rsi register. Therefore, the identification unit 170 references each argument, and if the reference destination is a structure, it further tracks it and identifies the values ​​of the structure's members.

[0040] Next, in step ST1712, the identification unit 170 determines whether the system call 161 to be issued matches the system call 161 identified in step ST1711. If they match, the process proceeds to step ST1713. On the other hand, if they do not match, the process proceeds to step ST1715, where the issuance of the system call 161 is permitted.

[0041] In step ST1713, since the system call 161 matches the monitoring target, the identification unit 170 identifies the function that called the system call. The caller function is identified from the return address saved in the stack. Specifically, the return address is obtained from the pt_regs structure used when the system call 161 was issued. By repeating this process for each stack frame, the caller function can be traced back. For example, assume that the return address indicates that the execution function of the CPU instruction (e.g., the syscall instruction for the x86_64 architecture, or the svc instruction for the aarch64 architecture) executed when the read system call is executed is libc, a standard library for the C language. Next, the address executed before libc can be traced from the return address stored in this stack frame. By repeating this operation, the functions called before the system call 161 was issued can be traced back. The caller function is identified based on the results of the traced functions using a predefined pattern. Examples of predefined patterns include a case where only functions within libc are used from the issuance of system call 161 to the calling function, or a case where functions within libc and functions within other libraries are mixed from the issuance of system call 161 to the calling function.

[0042] 8 is a diagram showing an example of the process memory map 210 used to identify the caller function from the return address when executing step ST1713. The caller function is identified using the disassembly result of App140 and the process memory map 210.

[0043] First, the return address is used to identify the relative address from the beginning of the code from the return address and the process memory map 210. For example, if App 140 is in ELF (Executable and Linking Format), it is configured with sections 211, as shown in the example of FIG. 8. Here, since the .text section is a code area, the return address can be compared with the beginning address 212 of the .text section to identify the relative address from the beginning of the .text section. Next, the relative address from the beginning of the .text section can be found in the disassembly results, and the calling function can be identified.

[0044] After identifying the calling function in step ST1713, the identifying section 170 outputs the identification result 180 in step ST1714.

[0045] <Identification Results> Fig. 9 is a diagram showing an example of the identification results 180 output in step ST1714. The identification results 180 include information about the system calls 182, openat2 and read, which are defined as monitoring targets in the system call list 160. Furthermore, the identification results 180 include information about the caller function 181 of the system call 182, and the results of identifying up to the argument 183 used in the system call 182. If a structure is used in the argument 183 of the system call 182, it can be seen that the results of identifying up to the values ​​of the structure members are included, as in the third-1st argument of the system call 182 (openat2) in Fig. 9.

[0046] <Control Unit> FIG. 10 is a flowchart showing an example of processing in which the control unit 190 controls system calls in a fine-grained manner using the input identification result 180.

[0047] First, in step ST1901, the control section 190 reads the identification result 180. Next, in step ST1902, the control section 190 determines whether or not there is a problem with the argument of the system call 182 written in the identification result 180.

[0048] If there is a problem with the argument of the system call 182 described in the identification result 180, the control unit 190 proceeds to step ST1903. Then, the issuance of the system call 182 is rejected, and the processing of the App 140 is interrupted. Then, the control unit 190 proceeds to step ST1904, where it outputs the control log 200.

[0049] On the other hand, if there is no problem with the argument of the system call 182 written in the identification result 180, the control unit 190 proceeds to step ST1905. Then, the issuance of the system call 182 is permitted. In other words, the processing of the App 140 continues.

[0050] Here, in step ST1902, the determination of whether or not there is a problem with the argument of the system call 182 described in the identification result 180 is based on whether or not there is access to a directory that is not accessible in the file access information 150 in the argument 183 of the system call 182 described in the identification result 180 (if there is, it is determined that there is a problem).

[0051] 9, the second argument of system call 182 (openat2) is the monitoring target, and the second argument accesses / lib / modules / *, which is not permitted to access in file access information 150. Therefore, it is determined that there is a problem because App 140 is behaving suspiciously, and processing must be interrupted.

[0052] 11 is a diagram showing an example of a control log 200 that is output by the control unit 190. The control log 200 contains a function name 201 (calling function) included in the identification result 180, a system call 202, an argument 203, and an issuance refusal reason 204 that is information that serves as the basis for determining that there is a problem with the argument of the system call in step ST1902 of FIG.

[0053] Information logs are useful for analyzing malware attacks, making it possible to develop specific countermeasures against malware attacks.

[0054] The information processing device 100 of this embodiment operates as described above. According to the information processing device 100 of this embodiment, even the arguments of system calls executed by applications are monitored, and if there is a problem with the arguments, the issuance of the system call is refused. This makes it possible to minimize the damage caused by malware attacks. Furthermore, by identifying the calling function of a system call, it is possible to save information that is useful for analyzing malware attacks.

[0055] Second Embodiment An information processing device and an information processing method according to this embodiment will be described. In the following description, components similar to those described in the above embodiments will be denoted by the same reference numerals, and detailed descriptions thereof will be omitted as appropriate.

[0056] <Configuration of Information Processing Device> This embodiment describes a technology for identifying the number of source code lines that call a system call when the binary of an application of the information processing device 100 shown in the first embodiment includes debug information.

[0057] The configuration of information processing device 100 according to this embodiment is the same as that shown in Fig. 2. An example of file access information 150 shown in this embodiment is the same as that shown in Fig. 4. An example of system call list 160 shown in this embodiment is the same as that shown in Fig. 5.

[0058] 12 is a diagram conceptually illustrating an example of the configuration of a Container Runtime 110A according to this embodiment. As illustrated in the example of FIG. 12, the Container Runtime 110A includes an identification unit 270 and a control unit 290.

[0059] Unlike the first embodiment, App 240, which is an application in Container 131, includes debug information. For example, the debug information may be in DWARF format.

[0060] The identification unit 270 receives the App 240, the file access information 150, and the system call list 160 as input, identifies the arguments of the system call or the number of lines of the caller source code, and outputs the identification result 280. Unlike the first embodiment, the identification result 280 is characterized in that it also includes the caller source code of the system call.

[0061] The control unit 290 receives the identification result 280 as an input, monitors the arguments of the system call, and outputs a control log 300 if the arguments differ from the expected arguments.

[0062] <Identification Unit> <Processing Contents of Identification Unit> An example of the processing from when the identification unit 270 creates the Container 131 to when the Container 131 is executed is the same as that shown in FIG.

[0063] FIG. 13 is a flowchart showing an example of a process in which the identification unit 270 monitors the system call 161 executed by the App 240 in the Container 131 .

[0064] First, in step ST2711, the identification unit 270 hooks the system call 161 executed by the App 240, and identifies the system call 161 and the argument 162 used.

[0065] Next, in step ST2712, the identification unit 270 determines whether the system call 161 to be issued matches the system call 161 identified in step ST2711. If they match, the process proceeds to step ST2713. On the other hand, if they do not match, the process proceeds to step ST2716, where the issuance of the system call 161 is permitted, and the process proceeds to step ST2715.

[0066] In step ST2713, since the system call 161 matches the monitoring target, the identification unit 270 identifies the function that called the system call. The caller function is identified from the return address saved in the stack. After identifying the caller function in step ST2713, the process proceeds to step ST2714.

[0067] Unlike the first embodiment, in step ST2714, the identification unit 270 identifies the number of lines of source code of the system call source. In step ST2714, the return address stored in the stack used in the process of identifying the caller function in step ST2713 is used. The identification unit 270 identifies the number of lines of source code of the caller from the return address and the binary disassembly result including the debug information of App 240. However, the return address stored in the stack is the address one instruction after the execution of the system call 161. Therefore, the correct address of the caller is the address one instruction before the return address. The identification unit 270 searches for this address in the disassembly result and identifies the number of lines of source code of the system call source. Then, the process proceeds to step ST2715.

[0068] In step ST2715, the identification section 270 outputs the identification result 280.

[0069] 14 is a diagram showing an example of the identification result 280 output in step ST2715. The identification result 280 includes information about the openat2 and read system calls 283 defined as monitoring targets in the system call list 160. Furthermore, the identification result 280 also includes information about the caller function 281 of the system call 283, source code information 282 (number of lines of source code) of the system call caller, and even the results of identifying arguments 284 used in the system call 283.

[0070] <Control Unit> An example of the process in which the control unit 290 controls system calls at a fine granularity using the input identification result 280 is similar to that shown in FIG.

[0071] However, when the control section 290 outputs the control log 300 in step ST1904, the control section 290 outputs the control log 300 including the source code information 282 written in the identification result 280.

[0072] 15 is a diagram showing an example of a control log 300 that is output by the control unit 290. The control log 300 contains a function name 301 included in the identification result 280, source code 302 (number of lines of source code), system call 303, argument 304, and issuance refusal reason 305, which is information that serves as the basis for determining that there is a problem with the system call argument.

[0073] Information logs are useful for analyzing malware attacks, making it possible to develop specific countermeasures against malware attacks.

[0074] The information processing device of this embodiment operates as described above. According to the information processing device of this embodiment, even the arguments of system calls executed by applications are monitored, and if there is a problem with the arguments, the issuance of the system call is refused. This makes it possible to minimize the damage caused by malware attacks. Furthermore, by identifying the number of lines of source code that call the system call, it is possible to save information that is useful for analyzing malware attacks.

[0075] Third Embodiment An information processing device and an information processing method according to this embodiment will be described. In the following description, components similar to those described in the above embodiments will be denoted by the same reference numerals, and detailed descriptions thereof will be omitted as appropriate.

[0076] <Configuration of Information Processing Device> In this embodiment, a technique for changing system call control when a new application is added to the information processing device shown in the first and second embodiments will be described.

[0077] 16 is a diagram conceptually illustrating an example of the configuration of an information processing device 100B according to this embodiment. As illustrated in the example of FIG. 2, the information processing device 100B includes an operating system (OS) Kernel 120, a Container Runtime 310, and N Containers 331, 332, ..., 33N. Note that the N Containers may be 10 or more.

[0078] The kernel 120 has a system call interface 121 that serves as a processing interface from the user space to the OS space.

[0079] The Container Runtime 310 controls the containers. In the Container Runtime 310, N containers, ie, Container 331, Container 332, . . . , Container 33N, are running.

[0080] In this embodiment, the information processing device 100B is assumed to be a network-ECU. Also, App341, which is an application in Container 331, and App342, which is an application in Container 332, are targets of tracing of system call issuance. App341 and App342 are described as applications that monitor the status of communication with the outside.

[0081] The information processing apparatus 100B differs from the first embodiment in that the system calls used by App342, which is a newly added application, are checked within the Container Runtime 310. If there is no problem with the system calls used in App342, App342 is newly added as an application of the Container 331.

[0082] 17 is a diagram conceptually illustrating an example of the configuration of the container runtime 310 according to this embodiment. As illustrated in the example of FIG. 17, the container runtime 310 includes an identification unit 270, a control unit 290, and an inspection unit 330.

[0083] The inspection unit 330 receives as input App 342 (a newly added application) to be inspected, the file access information 150, and the prohibited system call list 320, which is a list of predefined prohibited system calls, and inspects App 342.

[0084] The inspection unit 330 operates the App 342 and monitors the issuance of system calls down to the arguments. If the issued system calls include a system call included in the prohibited system call list 320, the inspection unit 330 does not permit the App 342 to be added to the system. On the other hand, if the issued system calls do not include a system call included in the prohibited system call list 320, the inspection unit 330 permits the App 342 to be added to the Container 331.

[0085] 18 and 19 are diagrams illustrating a schematic example of a hardware configuration when the information processing device exemplified in Fig. 3 is actually operated. This also corresponds to the information processing device 100 in Fig. 1.

[0086] Note that the hardware configurations illustrated in Figures 18 and 19 may not match the configuration illustrated in Figure 3 in terms of numbers, etc., but this is because the configuration illustrated in Figure 3 shows conceptual units.

[0087] Therefore, at least the following cases can be envisaged: a configuration illustrated in FIG. 3 is made up of multiple hardware configurations illustrated in FIGS. 18 and 19; a configuration illustrated in FIG. 3 corresponds to a part of the hardware configuration illustrated in FIGS. 18 and 19; and further, multiple configurations illustrated in FIG. 3 are provided in a single hardware configuration illustrated in FIGS. 18 and 19.

[0088] 18 shows a processing circuit 1102A that performs calculations and a storage device 1103 that can store information as a hardware configuration for realizing the identification unit 170, control unit 190, etc. in Fig. 3. This configuration is similar in all of the above-mentioned embodiments.

[0089] 19 shows a processing circuit 1102B that performs calculations as a hardware configuration for realizing the identification unit 170, the control unit 190, etc. in FIG. 3. This configuration is the same in all of the above-described embodiments.

[0090] The storage device 1103 may be, for example, a memory (recording medium) including a volatile or non-volatile semiconductor memory such as a hard disk drive (HDD), random access memory (RAM), read only memory (ROM), flash memory, erasable programmable read only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM), a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, or a DVD, or any recording medium that will be used in the future.

[0091] The processing circuit 1102A may execute a program stored in the storage device 1103, an external CD-ROM, an external DVD-ROM, an external flash memory, etc. That is, it may be, for example, a central processing unit (CPU), a microprocessor, a microcomputer, or a digital signal processor (DSP).

[0092] When the processing circuit 1102A executes a program stored in the storage device 1103, an external CD-ROM, an external DVD-ROM, or an external flash memory, the identification unit 170 and the control unit 190 are realized by software, firmware, or a combination of software and firmware that causes the processing circuit 1102A to execute the program stored in the storage device 1103. Note that the functions of the identification unit 170 and the control unit 190 may be realized, for example, by a plurality of processing circuits working together.

[0093] The software and firmware may be written as a program and stored in the storage device 1103. In this case, the processing circuit 1102A realizes the above-described functions by reading and executing the program stored in the storage device 1103. In other words, the storage device 1103 may store a program that, when executed by the processing circuit 1102A, results in the above-described functions being realized.

[0094] The processing circuit 1102B may also be dedicated hardware, i.e., for example, a single circuit, multiple circuits, a programmed processor, a parallel programmed processor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination thereof.

[0095] When the processing circuit 1102B is dedicated hardware, the identification unit 170 and the control unit 190 are realized by the operation of the processing circuit 1102B. Note that the functions of the identification unit 170 and the control unit 190 may be realized by separate circuits or by a single circuit.

[0096] In addition, the functions of the identification unit 170 and the control unit 190 may be partially realized in a processing circuit 1102A that executes a program stored in a memory device 1103, and partially realized in a processing circuit 1102B that is dedicated hardware.

[0097] <Regarding the Effects Produced by the Multiple Embodiments Described Above> Next, examples of the effects produced by the multiple embodiments described above will be described. Note that in the following description, the effects will be described based on the specific configurations exemplified in the multiple embodiments described above, but these may be replaced with other specific configurations exemplified in the present specification to the extent that similar effects are produced. In other words, for convenience, only one of the associated specific configurations may be described as a representative below, but the representatively described specific configuration may be replaced with another associated specific configuration.

[0098] Furthermore, the replacement may be made across multiple embodiments, i.e., configurations illustrated in different embodiments may be combined to produce the same effect.

[0099] According to the embodiment described above, the information processing device includes an identification unit 170 (or identification unit 270) and a control unit 190 (or control unit 290). The identification unit 170 receives as input a first application, file access information 150 indicating files accessible by the first application, and a system call list 160 defining a system call 161 to be monitored. The identification unit 170 outputs an identification result 180 (or identification result 280) that identifies the system call 161 and the argument 162 of the system call 161 used by the first application. Here, the first application corresponds to, for example, App140, App240, App341, etc. The control unit 190 receives as input the identification result 180 and controls whether or not to issue the system call 161 requested by App140.

[0100] Furthermore, according to the embodiment described above, the information processing device includes a processing circuit 1102A that executes a program and a storage device 1103 that stores the program to be executed. The processing circuit 1102A executes the program to realize the following operations.

[0101] That is, App 140, file access information 150 indicating files accessible by App 140, and system call list 160 defining system calls 161 to be monitored are input, and identification result 180 is output as a result of identifying system calls 161 and arguments 162 of system calls 161 used by App 140. Then, using identification result 180 as input, whether or not to issue system call 161 requested by App 140 is controlled.

[0102] Furthermore, according to the embodiment described above, the information processing device includes the processing circuit 1102B, which is dedicated hardware. The processing circuit 1102B, which is dedicated hardware, performs the following operations.

[0103] That is, the processing circuit 1102B, which is dedicated hardware, receives as input App 140, file access information 150, which is information indicating files accessible by App 140, and system call list 160, which defines system calls 161 to be monitored, and outputs identification result 180, which is the result of identifying system calls 161 and arguments 162 of system calls 161 used by App 140. Then, using identification result 180 as input, it controls whether or not to issue system calls 161 requested by App 140.

[0104] According to this configuration, the system call 161 is identified, including the argument 162, and the identification result is used as an input to control whether or not the system call 161 can be issued, thereby realizing fine-grained control of the system call 161. As a result, damage caused by malware attacks and the like can be minimized.

[0105] Furthermore, even if other configurations shown as examples in this specification are appropriately added to the above configuration, that is, even if other configurations in this specification that were not mentioned as the above configuration are appropriately added, the same effect can be achieved.

[0106] Furthermore, according to the embodiment described above, file access information 150 includes file directory 151, flag 152 which is information related to access to the file, mode 153 which is information indicating the file mode of the file, and access permission 154 which is information related to whether access to App 140 is permitted. With this configuration, file access information 150 indicates the directory, flag, mode, and access permission, which makes it easy for identification unit 170 to derive control candidates for system call 161 based on file access information 150.

[0107] Furthermore, according to the embodiment described above, the system call list 160 lists the system calls 161 and the arguments 162 of the system calls 161 used by the app 140. If the arguments 162 of the system calls 161 are structures, the system call list 160 lists the members of the structures. This configuration enables fine-grained control of the system calls 161 using information that identifies in detail the members of the structures of the arguments 162 of the system calls 161.

[0108] Furthermore, according to the embodiment described above, the identification unit 170 sets monitoring items for the system call 161 based on the file access information 150 and the system call list 160. With this configuration, when identifying the system call 161, monitoring can be limited to specific monitoring items for the system call 161. This reduces the monitoring overhead.

[0109] Furthermore, according to the embodiment described above, when the system call 161 to be monitored is issued, the identification unit 170 identifies the caller function of the system call 161. With this configuration, by identifying the caller function of the system call 161, it is possible to obtain information that is useful for analyzing malware attacks.

[0110] Furthermore, according to the embodiment described above, when identifying a caller function, the identification unit 170 uses the process memory map 210, which is a process map of App 140. With this configuration, even when it is difficult to identify the execution location using only the address at the time of execution by ASLR, the execution location can be correctly identified by using the process memory map.

[0111] Furthermore, according to the embodiment described above, the identification result 180 includes the results of identifying the caller function, the system call 161, and the arguments 162 of the system call 161. With this configuration, by identifying the caller function of the system call 161 and the arguments of the system call 161, it is possible to perform fine-grained control of the system call 161 while also obtaining information useful for analyzing malware attacks.

[0112] Furthermore, according to the embodiment described above, the control unit 190 outputs the control log 200 (or the control log 300) including the calling function, the system call 161, the argument 162 of the system call 161, and the reason for issuing the system call 161. With this configuration, the reason for issuing the system call (the reason for refusing to issue the system call) is recorded in the control log 200, and therefore, information useful for analyzing a malware attack can be obtained from the control log 200.

[0113] Furthermore, according to the embodiment described above, the identification unit 170 identifies the number of lines of source code of the calling function. With this configuration, by identifying the number of lines of source code of the calling function of the system call 161, it is possible to obtain information that is useful for analyzing malware attacks.

[0114] Furthermore, according to the embodiment described above, the identification result 180 includes the result of identifying the number of lines of source code of the calling function. With this configuration, by identifying the number of lines of source code of the calling function of the system call 161, it is possible to obtain information that is useful for analyzing malware attacks.

[0115] Furthermore, according to the embodiment described above, the control unit 190 outputs the control log 200 (or the control log 300) including the number of lines of source code of the calling function. With this configuration, by identifying the number of lines of source code of the calling function of the system call 161, it is possible to obtain information useful for analyzing malware attacks.

[0116] Furthermore, according to the embodiment described above, the control unit 190 controls whether or not to issue the system call 161 based on the argument 162 of the system call 161 included in the identification result 180. With such a configuration, the system call 161 is identified, including the argument 162, and the identification result is used as an input to control whether or not to issue the system call 161, thereby enabling fine-grained control of the system call 161.

[0117] Furthermore, according to the embodiment described above, the binary of App 140 includes debug information. With this configuration, the debug information is included in the binary, so that even the line number of the source code that calls system call 161 can be identified.

[0118] Furthermore, according to the embodiment described above, the information processing device includes an inspection unit 330 and a prohibited system call list 320. The inspection unit 330 inspects the system call 161 used by a newly added second application. Here, the second application corresponds to, for example, App 342. The prohibited system call list 320 defines the prohibited system call 161. Here, the file access information 150 also indicates files that App 342 can access. Then, when App 342 is run and a prohibited system call 161 defined in the prohibited system call list 320 is issued, the inspection unit 330 does not allow the addition of App 342. With this configuration, malware attacks can be prevented by inspecting applications added over the air (OTA) in a dedicated container.

[0119] According to the embodiment described above, the information processing method takes App 140, file access information 150 indicating files accessible by App 140, and system call list 160 defining system calls 161 to be monitored as inputs, and outputs identification result 180 resulting from identifying system calls 161 and arguments 162 of system calls 161 used by App 140. Then, using identification result 180 as input, it controls whether or not to issue system calls 161 requested by App 140.

[0120] According to this configuration, the system call 161 is identified, including the argument 162, and the identification result is used as an input to control whether or not the system call 161 can be issued, thereby realizing fine-grained control of the system call 161. As a result, damage caused by malware attacks and the like can be minimized.

[0121] Furthermore, even if other configurations shown as examples in this specification are appropriately added to the above configuration, that is, even if other configurations in this specification that were not mentioned as the above configuration are appropriately added, the same effect can be achieved.

[0122] <Regarding Modifications of the Multiple Embodiments Described Above> In the multiple embodiments described above, the dimensions, shapes, relative positional relationships, and implementation conditions of each component may be described, but these are merely examples in all aspects and are not limiting.

[0123] Therefore, countless modifications and equivalents not shown as examples are contemplated within the scope of the technology disclosed in the present specification, including, for example, modifying, adding, or omitting at least one component, and further, extracting at least one component from at least one embodiment and combining it with a component from another embodiment.

[0124] Furthermore, the descriptions in this specification are incorporated by reference for all purposes related to the present technology, and none of them are admitted to be prior art.

[0125] Furthermore, each component described in the above-described embodiments is envisioned as software or firmware, as well as corresponding hardware, and as software it is referred to as, for example, a "unit," and as hardware it is referred to as, for example, a "processing circuit."

[0126] Furthermore, the technology disclosed in this specification may also be in a form in which each component is distributed across multiple devices, that is, in a form such as a system that is a combination of multiple devices.

[0127] 1 Automatic driving system, 100 Information processing device, 100A Information processing device, 100B Information processing device, 101 Central processing unit, 102 Memory, 103 Auxiliary recording device, 110 Container Runtime, 110A Container Runtime, 120 Kernel, 121 System Call Interface, 131 Container, 132 Container, 13N Container, 140 App, 150 File access information, 151 Directory, 152 Flag, 153 Mode, 154 Access permission, 160 System call list, 161 System call, 162 Argument, 170 Identification unit, 180 Identification result, 181 Caller function, 182 System call, 183 Argument, 190 Control section, 200 Control log, 201 Function name, 202 System call, 203 Argument, 204 Reason for issue refusal, 210 Process memory map, 211 Section, 212 Address, 240 App, 270 Identification section, 280 Identification result, 281 Calling function, 282 Source code information, 283 System call, 284 Argument, 290 Control section, 300 Control log, 301 Function name, 302 Source code, 303 System call, 304 Argument, 305 Reason for issue refusal, 310 Container Runtime, 320 Prohibited system call list, 330 Inspection section, 331 Container, 332 Container, 33N Container, 341 App, 342 App, 1102A Processing circuit, 1102B processing circuit, 1103 storage device, 2000 HMI-ECU, 3000 DMS-ECU, 4000 ADAS-ECU, 5000 control-ECU, 6000 camera-ECU, 7000 communication line.

Claims

1. An information processing device comprising: an identification unit that receives as input a first application, file access information that is information indicating files that the first application can access, and a system call list that defines system calls to be monitored, and outputs an identification result that is a result of identifying the system calls and arguments of the system calls used in the first application; and a control unit that receives as input the identification result, and controls whether or not to issue the system call requested by the first application.

2. An information processing device as described in claim 1, wherein the file access information includes a directory of the file, a flag which is information regarding access to the file, a mode which is information indicating the file mode of the file, and an access permission which is information regarding whether or not access to the first application is possible.

3. An information processing device as claimed in claim 1 or 2, wherein the system call list describes the system calls used in the first application and the arguments of the system calls, and when the arguments of the system calls are structures, the system call list describes the members of the structures.

4. An information processing device according to any one of claims 1 to 3, wherein the identification unit sets the monitoring items for the system calls based on the file access information and the system call list.

5. An information processing device according to any one of claims 1 to 4, wherein the identification unit identifies a function that calls the system call when the system call to be monitored is issued.

6. An information processing device according to claim 5, wherein the identification unit uses a process memory map, which is a process map of the first application, when identifying the caller function.

7. An information processing device according to claim 5 or 6, wherein the identification result includes a result of identifying the caller function, the system call, and the arguments of the system call.

8. An information processing device according to any one of claims 5 to 7, wherein the control unit outputs a control log including the calling function, the system call, the arguments of the system call, and a reason for issuing the system call.

9. An information processing device according to any one of claims 5 to 8, wherein the identification unit identifies the number of source code lines of the calling function.

10. An information processing device according to claim 9, wherein the identification result includes a result of identifying the number of source code lines of the calling function.

11. An information processing device according to claim 9 or 10, wherein the control unit outputs a control log including the number of lines of source code of the calling function.

12. An information processing device according to any one of claims 1 to 11, wherein the control unit controls whether or not to issue the system call based on the arguments of the system call included in the identification result.

13. An information processing device according to any one of claims 1 to 12, wherein the binary of the first application includes debug information.

14. An information processing device according to any one of claims 1 to 13, further comprising an inspection unit for inspecting the system calls used in a newly added second application, wherein the file access information also indicates the files that the second application can access, and the inspection unit runs the second application and does not allow the addition of the second application if a prohibited system call defined in a prohibited system call list that defines the prohibited system calls is issued.

15. An information processing method comprising: inputting a first application, file access information indicating files accessible by the first application, and a system call list defining system calls to be monitored; outputting an identification result resulting from identifying the system calls and arguments of the system calls used by the first application; and using the identification result as input to control whether or not to issue the system calls requested by the first application.

Images