Information processing device and information processing method

Abstract

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

Description

[Technical field]

[0001] The technology disclosed in this specification relates to information processing technology. [Background 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. In order 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 (for example, see Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2019 / 150699 Summary of the Invention [Problem to be solved by the invention]

[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 achieving fine-grained control of system calls. [Means for solving the problem]

[0007] An information processing device according to 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 accessible by the first application, 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 by 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. the arguments include a structure, and the system call list describes members of the structure. . Effect of the Invention

[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 set forth below and the accompanying drawings. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram conceptually illustrating an example of the configuration of an autonomous driving system according to an embodiment. [Diagram 2] FIG. 1 is a diagram conceptually illustrating an example of a configuration of an information processing device according to an embodiment. [Diagram 3] FIG. 2 is a diagram conceptually illustrating an example of a configuration of a Container Runtime according to an embodiment. [Figure 4] FIG. 11 is a diagram illustrating an example of file access information. [Diagram 5] FIG. 13 illustrates an example of a system call list. [Figure 6]13 is a flowchart illustrating an example of processing performed by an identification unit from creating a Container to executing the Container. [Figure 7] 13 is a flowchart illustrating an example of a process in which an identification unit monitors system calls executed by an App in a Container. [Figure 8] FIG. 13 is a diagram showing an example of a process memory map used to identify a caller function from a return address when step ST1713 is executed. [Figure 9] FIG. 13 is a diagram showing an example of an identification result output in step ST1714. [Figure 10] 13 is a flowchart showing an example of a process in which a control unit controls system calls in a fine-grained manner using an input identification result. [Figure 11] FIG. 11 is a diagram illustrating an example of a control log that is an output of a control unit. [Figure 12] FIG. 2 is a diagram conceptually illustrating an example of a configuration of a Container Runtime according to an embodiment. [Figure 13] 13 is a flowchart illustrating an example of a process in which an identification unit monitors system calls executed by an App in a Container. [Figure 14] FIG. 13 is a diagram showing an example of an identification result output in step ST2715. [Figure 15] FIG. 11 is a diagram illustrating an example of a control log that is an output of a control unit. [Figure 16] FIG. 1 is a diagram conceptually illustrating an example of a configuration of an information processing device according to an embodiment. [Figure 17] FIG. 2 is a diagram conceptually illustrating an example of a configuration of a Container Runtime according to an embodiment. [Figure 18] 4 is a diagram illustrating a schematic hardware configuration of the information processing device illustrated in FIG. 3 in an actual operation; [Figure 19] 4 is a diagram illustrating a schematic hardware configuration of the information processing device illustrated in FIG. 3 in an actual operation; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, the 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 they 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, configurations may be omitted or simplified as appropriate. The size and positional relationship of the configurations shown in different drawings are not necessarily described accurately, and may be changed as appropriate. Hatching may be used in drawings such as plan views that are not cross-sectional views to facilitate understanding of the contents 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 thereof may be omitted to avoid duplication.

[0014] Furthermore, in the description 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, even if ordinal numbers such as "first" or "second" are used in the description of this specification, these terms are used for convenience to facilitate understanding of the contents of the embodiments, and the contents of the embodiments are not limited to the orders that may result from these ordinal numbers.

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

[0017] As shown in 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, an advanced driver assistance systems (ADAS)-ECU 4000, a control-ECU 5000, and a camera-ECU 6000, and a communication line 7000 that connects the 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 recording device 103. It goes without saying that the technology shown in this embodiment can be applied to systems other than autonomous driving systems.

[0018] <First embodiment> The information processing device and the information processing method according to the present embodiment will be described. In the following description, the same components as those described in the above embodiment are illustrated with the same reference numerals, and detailed description 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 an information processing device 100 according to the present embodiment. As illustrated in the example of Fig. 2, the information processing device 100 includes a Kernel 120 of an operating system (OS), 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 which 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 pieces of Containers 131, 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 the issuance of system calls. App 140 is described as an application that monitors the state 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 the present 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 include 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 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 a system call or an argument of a system call.

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

[0026] <Identification section> <File access information> 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 permit access to App 140 and directories that do not permit 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 is to be created if the file does not exist.

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

[0029] <System Call List> 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 the App 140. The example in Fig. 5 shows that the system calls 161 of openat2, read, and fstat are used by the App 140. The system calls 161 need to be prepared in advance, and in that 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 traced. Furthermore, since the third argument of openat2 is a structure, the argument 3-1, which is the first member of the structure, 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 argument 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 the example of 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 a file is to be monitored. Furthermore, among them, the argument 162 of the system call 161 that can identify the file to be read and written is to be monitored.

[0033] <Processing details of the identification unit> The processing of the identification unit 170 can be roughly divided into two parts. One is a process 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 a part in which the identification unit 170 monitors a system call 161 executed by an App 140 in the Container 131.

[0034] FIG. 6 is a flowchart showing an example of processing performed by the identification unit 170 from creating the Container 131 to executing the Container 131.

[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 in 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 the Container 131 from the configuration file and executes it. The method of monitoring the system call 161 set in step ST1703 when creating the Container 131 may use, for example, eBPF (extended Berkeley Packet Filter) 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 argument 162 used. In the case of Linux (registered trademark), the value of a standard register of the CPU is stored in pt_regs, which is a structure at the time of issuing the system call 161. Since the number of the system call 161 or the argument 162 of the system call 161 is stored in a register number determined by the ABI (Application Binary Interface), the content of the register to be referenced may be read from the member of the pt_regs structure. For example, in the case of 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 refers to each argument, and if the reference destination is a structure, it further tracks it and identifies the value of the member of the structure.

[0040] Next, in step ST1712, the identification unit 170 judges whether the issued system call 161 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 identification of the caller function is performed from the return address saved in the stack. As a detailed procedure, the return address is obtained from the pt_regs structure used when the system call 161 is issued. By repeating this for each stack frame, it is possible to trace back to the caller function. For example, assume that it is found from the return address that the execution function of the CPU instruction (for example, the syscall instruction in the case of the x86_64 architecture, or the svc instruction in the case of the aarch64 architecture) executed when the read system call is executed is libc, which is a standard library of the C language. Next, it is possible to trace the address executed before libc from the return address stored in the stack frame of this part. By repeating this operation, it is possible to trace back the functions that were called before the issuance of the system call 161. The identification of the caller function based on the result of the traced back function is determined by a predefined pattern. Examples of patterns to be defined in advance include a case where only functions in libc are used from the issuance of system call 161 to the caller function, or a case where functions in libc and functions in other libraries are mixed from the issuance of system call 161 to the caller 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 disassembly result of App140 and the process memory map 210 are used to identify the caller function.

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

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

[0045] <Identification results> 9 is a diagram showing an example of the identification result 180 output in step ST1714. The identification result 180 includes information on the openat2 and read system calls 182 defined as monitoring targets in the system call list 160. Furthermore, the identification result 180 includes information on the caller function 181 of the system call 182, and the result 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 result of identifying up to the values ​​of the members of the structure is included, as in the 3-1st argument of the system call 182 (openat2) in FIG. 9.

[0046] <Control Unit> FIG. 10 is a flow chart showing an example of a process in which the control unit 190 uses the input identification result 180 to control system calls in a fine-grained manner.

[0047] First, in step ST1901, the control section 190 reads the identification result 180. Next, in step ST1902, the control section 190 judges 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 as to 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 permitted 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 the system call 182 (openat2) is the object of monitoring, and the second argument accesses / lib / modules / *, which is not permitted to be accessed in the file access information 150. Therefore, it is determined that there is a problem because App 140 is behaving suspiciously, and the process must be interrupted.

[0052] <Control log> Fig. 11 is a diagram showing an example of a control log 200 that is an output of the control unit 190. The control log 200 describes a function name 201 (calling function) included in the identification result 180, a system call 202, an argument 203, and an issue refusal reason 204 that is information on the grounds when it is determined in step ST1902 of Fig. 10 that there is a problem with the argument of the system call.

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

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

[0055] <Second embodiment> The information processing device and the information processing method according to the present embodiment will be described. In the following description, the same components as those described in the above embodiment are illustrated with the same reference numerals, and detailed description thereof will be omitted as appropriate.

[0056] <Configuration of information processing device> In this embodiment, a technique for identifying the number of lines of source code from which a system call is made when the binary of an application of the information processing device 100 shown in the first embodiment includes debug information will be described.

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

[0058] 12 is a diagram conceptually illustrating an example of the configuration of the Container Runtime 110A according to the present embodiment. As illustrated in the example of FIG.

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

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

[0061] A 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 section> <Processing details of the identification unit> An example of the process from when the identification unit 270 creates the Container 131 to when the Container 131 is executed is similar to 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 judges whether the issued system call 161 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 identification of the caller function is performed from the return address saved in the stack. Then, after identifying the caller function in step ST2713, the process proceeds to step ST2714.

[0067] In step ST2714, unlike the first embodiment, 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 call source function in step ST2713 is used. The identification unit 270 identifies the number of lines of source code of the call source from the return address and the disassembly result of the binary including the debug information of App240. 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 call source 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. In addition, the identification result 280 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, or even the result of identifying the 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 in a fine-grained manner 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] <Control log> 15 is a diagram showing an example of a control log 300 that is an output of the control unit 290. The control log 300 contains a function name 301 included in the identification result 280, a source code 302 (the number of lines of source code), a system call 303, an argument 304, and an issue refusal reason 305 that is information on the grounds when it is determined that there is a problem with the argument of the system call.

[0073] Information logs are useful for analyzing malware attacks, making it possible to take specific measures 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 a system call executed by an application 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 a malware attack. Furthermore, by identifying the number of lines of source code that calls the system call, it is possible to store information that is useful for analyzing a malware attack.

[0075] <Third embodiment> The information processing device and the information processing method according to the present embodiment will be described. In the following description, the same components as those described in the above embodiment are illustrated with the same reference numerals, and detailed description 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] Fig. 16 is a diagram conceptually illustrating an example of the configuration of an information processing device 100B according to the present embodiment. As illustrated in Fig. 2, the information processing device 100B includes a Kernel 120 of an operating system (OS), a Container Runtime 310, and N Containers 331, 332, ..., 33N. The N Containers may be 10 or more.

[0078] The kernel 120 has a system call interface 121 which 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 pieces of Containers 331, 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 Container331, and App342, which is an application in Container332, 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 device 100B differs from the first embodiment in that the system calls used in App342, which is a newly added application, are inspected in 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 the App 342.

[0084] The inspection unit 330 runs the App 342 and monitors the issuance of system calls, including 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] <Hardware configuration of information processing device> 18 and 19 are diagrams each illustrating a schematic hardware configuration when the information processing device exemplified in Fig. 3 is actually operated. The same applies 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 numbers, etc., of the configuration illustrated in Figure 3, 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 composed of multiple hardware configurations illustrated in FIG. 18 and FIG. 19; a configuration illustrated in FIG. 3 corresponds to a part of the hardware configuration illustrated in FIG. 18 and FIG. 19; and further, the multiple configurations illustrated in FIG. 3 are provided in a single hardware configuration illustrated in FIG. 18 and FIG. 19.

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

[0089] In Fig. 19, a processing circuit 1102B that performs calculations is shown as a hardware configuration for realizing the identification unit 170, the control unit 190, etc. in Fig. 3. This configuration is similar in all of the above-mentioned embodiments.

[0090] The storage device 1103 may be, for example, a memory (recording medium) including a hard disk drive (i.e., HDD), random access memory (i.e., RAM), read only memory (i.e., ROM), flash memory, volatile or non-volatile semiconductor memory such as 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 to 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, or 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, an external flash memory, or the like, the identification unit 170 and the control unit 190 are realized by software, firmware, or a combination of software and firmware, in which the program stored in the storage device 1103 is executed by the processing circuit 1102A. 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-mentioned 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-mentioned functions being realized.

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

[0095] When the processing circuit 1102B is a 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 may be realized 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] <Effects of the above-described embodiments> Next, examples of effects produced by the above-described embodiments are shown. In the following description, the effects are described based on the specific configurations shown as examples in the above-described embodiments, but may be replaced with other specific configurations shown as examples in this specification as long as the same effects are produced. In other words, for convenience, only one of the corresponding specific configurations may be described as a representative below, but the representatively described specific configuration may be replaced with another corresponding specific configuration.

[0098] Furthermore, the replacement may be made across a number of embodiments, that is, configurations shown as examples 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 an identification unit 270) and a control unit 190 (or a control unit 290). The identification unit 170 receives as input a first application, file access information 150 that is information indicating files accessible by the first application, and a system call list 160 that defines a system call 161 to be monitored, and outputs an identification result 180 (or an identification result 280) that is a result of identifying the system call 161 and the argument 162 of the system call 161 used in 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] 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 which is information indicating files accessible by App 140, and system call list 160 which defines system call 161 to be monitored are input, and identification result 180 which is a result of identifying system call 161 used by App 140 and argument 162 of system call 161 is output. Then, with 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, 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 call 161 to be monitored, and outputs identification result 180 which is a result of identifying system call 161 used by App 140 and argument 162 of system call 161. Then, using identification result 180 as input, it controls whether or not to issue system call 161 requested by App 140.

[0104] According to 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 the system call 161 is issued, thereby realizing fine-grained control of the system call 161. Therefore, damage caused by malware attacks and the like can be minimized.

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

[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 or not access is permitted to App 140. 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, system call list 160 describes system calls 161 and arguments 162 of system calls 161 used by App 140. If argument 162 of system call 161 is a structure, system call list 160 describes members of the structure. With this configuration, fine-grained control of system call 161 can be performed using information that identifies in detail even the members of the structure of argument 162 of system call 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 makes it possible to reduce 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 the App 140. With this configuration, even if it is difficult to identify the execution location only from the address at the time of execution due to 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. According to such a configuration, by identifying the caller function of the system call 161 and the arguments of the system call 161, it is possible to obtain information useful for analyzing malware attacks while controlling the system call 161 in a fine-grained manner.

[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 such a configuration, the reason for issuing the system call (reason for refusal to issue the system call) is recorded in the control log 200, so that information useful for analyzing a malware attack can be obtained from the control log 200.

[0113] 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 a malware attack.

[0114] 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. According to such a 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 a malware attack.

[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 even 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 a malware attack.

[0116] Furthermore, according to the embodiment described above, control unit 190 controls whether or not to issue system call 161 based on argument 162 of system call 161 included in identification result 180. With such a configuration, identification is performed including argument 162 of system call 161, and whether or not to issue system call 161 is controlled using the identification result as an input, so that fine-grained control of system call 161 can be realized.

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

[0118] 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 in a newly added second application. Here, the second application corresponds to, for example, App342. The prohibited system call list 320 defines the prohibited system call 161. Here, the file access information 150 also indicates a file that App342 can access. Then, when App342 is operated and a prohibited system call 161 defined in the prohibited system call list 320 is issued, the inspection unit 330 does not permit the addition of App342. According to such a configuration, an application added by over the air (OTA) is inspected on a dedicated container, thereby making it possible to prevent malware attacks.

[0119] According to the embodiment described above, in the information processing method, App 140, file access information 150 which is information indicating files accessible by App 140, and system call list 160 which defines system call 161 to be monitored are input, and identification result 180 which is a result of identifying system call 161 used by App 140 and argument 162 of system call 161 is output. Then, using identification result 180 as input, whether or not to issue system call 161 requested by App 140 is controlled.

[0120] According to 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 the system call 161 is issued, thereby realizing fine-grained control of the system call 161. Therefore, damage caused by malware attacks and the like can be minimized.

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

[0122] <Modifications of the above-described embodiments> In the 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 assumed 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 in at least one embodiment and combining it with a component in 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 of the components described in the above embodiments is envisioned as either software or firmware, or as corresponding hardware, and as software, is referred to as, for example, a "unit," and as hardware, is referred to as, for example, a "processing circuit" (circuitry).

[0126] Furthermore, the technology disclosed in this specification may also be implemented 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. [Explanation of symbols]

[0127] 1 Autonomous 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 Calling function, 182 System call, 183 Argument, 190 Control unit, 200 Control log, 201 Function name, 202 System call, 203 Argument, 204 Issue refusal reason, 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 rejection of issue, 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 identification unit that takes as input a first application, file access information which is information indicating a file accessible by the first application, and a system call list that defines system calls to be monitored, and outputs an identification result which is a result of identifying the system calls used in the first application and the arguments of the system calls, a control unit that takes the identification result as input and controls whether or not to issue the system calls required by the first application, wherein the argument includes a structure, and the system call list describes members of the structure, an information processing apparatus.

2. The information processing apparatus according to 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 a file mode of the file, and an access permission which is information regarding whether or not access to the first application is permitted, an information processing apparatus.

3. The information processing apparatus according to claim 1 or 2, wherein the identification unit sets monitoring items of the system calls from the file access information and the system call list, an information processing apparatus.

4. The information processing apparatus according to claim 1, wherein when the system call to be monitored is issued, the identification unit identifies a calling function of the system call, an information processing apparatus.

5. The information processing apparatus according to claim 4, wherein when identifying the calling function, the identification unit uses a process memory map which is a process map of the first application, an information processing apparatus.

6. The information processing apparatus according to claim 4 or 5, wherein the identification result includes a result of identifying the calling function, the system call, and the argument of the system call, an information processing apparatus.

7. The information processing apparatus according to claim 4, wherein the control unit outputs a control log including the calling function, the system call, the argument of the system call, and a reason for issuing the system call, an information processing apparatus.

8. The information processing apparatus according to claim 4, wherein the identification unit identifies the number of source code lines of the calling function, an information processing apparatus.

9. The information processing apparatus according to claim 8, The identification result includes the identified result of the number of source code lines of the calling function. An information processing apparatus.

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

11. The information processing apparatus according to claim 1 or 2, wherein the control unit controls whether or not to issue the system call based on the argument of the system call included in the identification result. An information processing apparatus.

12. The information processing apparatus according to claim 1 or 2, wherein the binary of the first application includes debug information. An information processing apparatus.

13. The information processing apparatus according to claim 1 or 2, further comprising an inspection unit for inspecting the system call used in a newly added second application, wherein the file access information also indicates the files accessible by the second application, and the inspection unit does not permit the addition of the second application when the second application is operated and a prohibited system call defined in a prohibited system call list defining the prohibited system call is issued. An information processing apparatus.

14. Inputting a first application, file access information which is information indicating files accessible by the first application, and a system call list defining system calls to be monitored, and outputting an identification result which is a result of identifying the system calls and the arguments of the system calls used in the first application, inputting the identification result and controlling whether or not to issue the system calls required by the first application, wherein the argument includes a structure, and the system call list describes members of the structure. An information processing method.

Images