Information processing device, information processing method, and program

Abstract

An information processing device, method, and program for realizing high-speed, low-load monitoring processing is provided. [Solution] The information processing device 1 is equipped with a control means for executing processing of an SSD (software) stored at a specific register based on the address written to the specific register, and is equipped with a first loading means 321 for loading a syscall handler 340 capable of monitoring syscall instructions into memory, and an address modification writing means 323 for modifying the address to be written to the specific register to the address of the syscall handler 340 loaded by the first loading means 321 in response to the issuance of a CPU instruction (WRMSR) that commands writing to the specific register, and writing the modified address, and the control means executes processing of the syscall handler 340 loaded at the address written by the address modification writing means 323 instead of processing the SSD (software).

Description

[Technical Field]

[0001] The present invention relates to an information processing device or the like capable of monitoring a predetermined command. [Background technology]

[0002] In modern society, computers connected to the Internet have become an indispensable part of the infrastructure. Because this type of computer is an open infrastructure that anyone can use, there is a constant stream of crimes involving malicious programs, and it is also used in wars between nations. For these reasons, techniques have been proposed that can prevent malicious operations by malicious programs.

[0003] Patent document 1 discloses an information processing device that executes monitoring software loaded into a specified area of ​​memory at a privilege level higher than the privilege level set in the OS kernel, and that includes a monitoring means that monitors, among instructions issued to a processor, at least system call instructions for handing over processing to the OS kernel, and a hook condition setting means that sets hook conditions for monitoring the system call instructions in the monitoring means, wherein the hook condition setting means includes hook condition monitoring means that monitors the issuance of rewrite accesses for the hook conditions to registers in the MSR related to the system call instructions, and hook condition correction means that corrects the hook conditions for the registers when the issuance of the rewrite access is detected.

[0004] Patent Document 2 discloses that a hypervisor runs at a higher privilege level than a virtual machine, and when an interrupt occurs on the virtual machine, the operation of the virtual machine is suspended and control is transferred to the hypervisor. Non-Patent Document 1 discloses a system call hooking method using a virtual machine monitor for malware analysis. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 6370098 [Patent Document 2] U.S. Patent No. 7,996,836 [Non-patent literature]

[0006] [Non-Patent Document 1] Takuya Yoshimura, "System Call Hooking Method Using Virtual Machine Monitor for Malware Analysis," Proceedings of the 72nd (Heisei 22) National Conference on Network Security (3), March 8, 2010, pp. 3-609-3-610 Summary of the Invention [Problem to be solved by the invention]

[0007] However, the conventional techniques described in the above documents each have the following problems. In the invention of Patent Document 1, when an exception (such as a syscall invalid opcode exception or an MSR access exception) occurs, the IDT is referenced and control is passed to an interrupt handler of the monitoring software. Then, under the control of the interrupt handler, the instruction pointer saved on the stack is referenced to determine whether the instruction is a syscall instruction. If it is determined to be a syscall instruction, the contents of the general-purpose registers and stack are inspected to evaluate their validity. For this reason, the invention of Patent Document 1 has the problem that delays are likely to occur because control is passed to the interrupt handler via the long path of #UD → IDT → interrupt handler every time a syscall instruction is issued.

[0008] In particular, the invention disclosed in Patent Document 1 performs processing to demote the kernel to Ring:2. Specifically, syscall commands issued from all processes (application programs) are transferred from Ring:3 to Ring:0 by an interrupt (#UD), and after inspection, they are transferred from Ring:0 to Ring:2, so two permission changes are performed before control is passed to the OS. Also, because the monitoring software operates as the same interrupt handler in Ring:0, the load is concentrated on that handler. For the reasons mentioned above, the invention of Patent Document 1 may cause overhead in the processing of the entire computer. In addition, privileged operations such as memory access, device access, and page table management are generally only permitted in ring 0. Therefore, with the invention of Patent Document 1, it is necessary to customize the OS so that switching between Ring:2 and Ring:0 occurs every time the kernel needs it, and this customization could undermine the versatility and reliability of the OS.

[0009] Incidentally, in an information processing device such as a personal computer, a plurality of application programs can be loaded into memory and run in parallel. Here, the monitoring software according to Patent Document 1 is configured to individually and intensively monitor and evaluate syscall commands issued from each application program. Therefore, when the monitoring software according to Patent Document 1 is installed in the information processing device, the load is concentrated on the monitoring software.

[0010] The invention of Patent Document 1 loads monitoring software into a memory area with a privilege level higher than the kernel level, making it possible to monitor for fraud at the kernel level. However, if the monitoring software itself is tampered with in some way (for example, by accessing an I / O port and communicating directly with the hardware device), it cannot prevent such unauthorized access or tampering. Moreover, the invention of Patent Document 1 monitors only syscall commands, so if fraud is committed using commands other than syscall commands, the fraud cannot be detected.

[0011] Patent Document 2 describes that a security module is executed within a hypervisor. This means that every time a syscall command is issued, the system switches from non-root mode to root mode (switching CPU registers), which increases the load. Similarly, Patent Document 2 describes that system calls are executed using the software interrupt INT2E and the SYSENTER / SYSCALL instructions, and describes setting a breakpoint in the KitFastCallEntry() function to generate an interrupt and switch to the hypervisor. In other words, an interrupt is added to the CPU processing and the mode is changed to the hypervisor, which increases the load even further. Similarly, Patent Document 2 describes identifying the type of system call by referring to the system call in the SSDT. This is inefficient because the type of system call is determined by a specific CPU register specified when the system call instruction is issued. Similarly, Patent Document 2 describes that when the WRMSR and RDMSR instructions are issued, a setting is made in the VT to transfer control to the hypervisor. The purpose of this is to determine whether the instructions were issued by the operating system protection module to access the SSDT and to determine whether SSDT initialization has been completed, and is not to inspect system calls.

[0012] Non-Patent Document 1 describes a method of generating a VM exit at the entrance of a handler that executes a system call in order to analyze the behavior of malware. Specifically, it describes how to use a debug register to cause a VMexit even with a system enter command. More specifically, it describes that when a sysenter instruction is issued, a debug exception occurs, processing transitions to the system call entry point stored in the sysenter_eip_msr register, and that by setting this value in the debug register, a debug exception occurs when a system call is issued, which makes it possible to hook the system call. This will result in a large overhead if there is an application program that makes a lot of system calls. Furthermore, Non-Patent Document 1 describes that a means for identifying the process that issued the syscall command is to compare the information in the CR3 register with the DTB in the bidirectional list managed by Windows. This would require searching through a list of all running processes, which is inefficient.

[0013] In addition, conventional security systems (security software) available on the market are limited in that they are executed after the OS (Operating System) is started, and therefore can only operate in accordance with the OS's functions. Furthermore, many conventional security systems have the problem that they are primarily focused on detecting fraud, but can only detect known fraud.

[0014] The present invention has been made in view of the above circumstances, and has as its object to provide an information processing device, an information processing method, and a program that are capable of realizing high-speed, low-load monitoring processing. [Means for solving the problem]

[0015] In order to achieve the above object, an information processing device according to one embodiment of the present invention is an information processing device having a control means for executing processing of software stored at an address written to a specific register based on the address written to the specific register, and is equipped with a first loading means for loading first software capable of monitoring system call instructions into memory, and an address modification writing means for, in response to the issuance of a CPU instruction instructing a write to the specific register, modifying the address to be written to the specific register to the address of the first software loaded by the first loading means and writing the address to the specific register, wherein the control means executes processing of the first software loaded at the address written by the address modification writing means instead of processing the software.

[0016] In addition, an information processing method according to another aspect of the present invention is provided in a computer having a control means for executing processing of software stored at an address written to a specific register based on the address, the method comprising: a first load step of loading first software capable of monitoring system call instructions into memory; an address change write step of, in response to the issuance of a CPU instruction commanding a write to the specific register, changing the address to be written to the specific register to the address of the first software loaded by the first load means and writing the address to the specific register; and a step of causing the control means to execute processing of the first software loaded at the address written in the address change write step instead of processing the software.

[0017] In addition, a program according to another aspect of the present invention causes a computer having a control means for executing processing of software stored at an address written to a specific register based on the address written to the specific register to function as a first load means for loading first software capable of monitoring system call instructions into memory, and an address change write means for, in response to the issuance of a CPU instruction commanding a write to the specific register, changing the address to be written to the specific register to the address of the first software loaded by the first load means and writing the address to the specific register, and the control means is configured to execute processing of the first software loaded at the address written by the address change write means instead of processing the software. [Effects of the Invention]

[0018] According to the present invention, high-speed monitoring processing with low load can be realized. [Brief explanation of the drawings]

[0019] [Figure 1] 1 is a hardware configuration diagram of an information processing apparatus according to an embodiment of the present invention; [Figure 2] FIG. 2 is a diagram illustrating a main part of a chipset of the information processing device according to the present embodiment. [Figure 3] FIG. 1 is a diagram illustrating a state in which a software package is installed in an information processing apparatus. [Figure 4] FIG. 10 is an explanatory diagram of a specific device. [Figure 5] 1 is a conceptual diagram showing the privilege levels of software loaded into memory and the cooperative relationships of each component. [Figure 6] FIG. 1 is a functional block diagram of an information processing device according to an embodiment of the present invention. [Figure 7] 10 is a flowchart showing the process from power-on to APP startup in a conventional information processing device. [Figure 8] 4 is a flowchart showing the process from power-on to APP startup in the information processing device of the present invention. [Figure 9]10 is a sub-flowchart showing the processing of a specific boot loader of the present invention. [Figure 10] (a) is an illustration of a physical memory map showing that a software area has been reserved for the secure core, and (b) is an illustration of a physical memory map showing that the reserved area for the secure core has been changed to an MMIO area (hardware area) after (a). [Figure 11] 10 is a sub-flowchart showing initial processing related to a secure core. [Figure 12] FIG. 10 is an explanatory diagram of a syscall execution method. [Figure 13] 10 is a flowchart illustrating a method for setting a syscall handler. [Figure 14] 10 is a flowchart illustrating a method for setting an R0 handler. [Figure 15] 10 is a flowchart showing the process from monitoring a CPU instruction to determining whether it is correct or not (invalidation process). [Figure 16] 10 is a flowchart showing the process of monitoring a syscall command and determining whether it is correct or not. [Figure 17] FIG. 1 is a diagram illustrating a process management data structure. [Figure 18] 10 is a flowchart showing the process of monitoring a call command and determining whether it is correct or not. [Figure 19] 10 is a flowchart showing processing after determining whether a syscall command and a call command are correct or not; DETAILED DESCRIPTION OF THE INVENTION

[0020] An embodiment of an information processing device 1 of the present invention will be described. FIG. 1 is a hardware configuration diagram of an information processing device 1 according to an embodiment of the present invention. The information processing device 1 may be any of various information processing devices having a function of communicating via a network, such as a server device with a built-in computer, a general-purpose personal computer, or a portable information processing terminal.

[0021] The information processing device 1 includes a chipset 11 on which a CPU (Central Processing Unit) 10 is mounted as a processor. Hereinafter, the CPU 10 will also be referred to as the processor 10. Note that, as the information processing device 1 of this embodiment, a computer equipped with a CPU 10 manufactured by Intel Corporation and running Windows (registered trademark; the same applies hereinafter) as its OS will be exemplified, but the present invention is not limited to this. For example, it may be a computer equipped with a CPU 10 manufactured by AMD or ARM, and the OS may be UNIX (registered trademark) or MacOS. Furthermore, this embodiment is based on the assumption that the CPU 10 employs Intel's x86-64 architecture, that is, a 64-bit CPU instruction set architecture, but is not limited to this. In addition, in this embodiment, a Syscall (syscall instruction) is used to transition from user mode (ring: 3) to kernel mode (ring: 0), but this may also be a sysenter instruction. The CPU 10 is connected via a bus BA to a flash ROM (Read Only Memory) 20, an HDD (Hard Disc Drive) 90, a memory (RAM: Random Access Memory) 30, an input unit 40, an output unit 50, and a log storage unit 60 that is provided as needed. The CPU 10 executes a program (software) to control each unit of the information processing device 1 and perform processing to realize the functions of the information processing device 1.

[0022] The flash ROM 20 stores a United Extensible Firmware Interface (UEFI) or a Basic Input Output System (BIOS) 21. The "UEFI or BIOS 21" is referred to as "UEFI / BIOS 21." The memory 30 corresponds to a main storage device, and the flash ROM 20 and the HDD 90 correspond to an auxiliary storage device. The auxiliary storage device may be a solid state drive (SSD), a USB flash drive, a secure digital card (SD card), an optical disc (CD, DVD), an external HDD / SSD, or online storage.

[0023] The HDD 90 is a computer-readable recording medium that stores various data and programs used by the processor 10. The HDD 90 stores, for example, an OS 31 (Operating System), various application programs (hereinafter referred to as "APP 34"), and necessary data (information). The software etc. stored in the HDD 90 is loaded into the memory 30 as each component (means) mainly at the time of startup (see FIG. 6).

[0024] When the information processing device 1 is started, the memory 30 is loaded with programs and the like stored in an auxiliary storage device (for example, the flash ROM 20), and also temporarily stores information in the middle of processing. Furthermore, when the information processing device 1 starts up, the memory 30 is loaded with software (such as the secure core 300 and the specific boot loader 93) stored in an auxiliary storage device (for example, the HDD 90). The information processing device 1 performs various known information processing by loading programs stored in the auxiliary storage device into memory 30 and executing them by CPU 10, and the monitoring software (secure core 300, syscall handler 340, APP handler 350, R0 handler 360) stored in the auxiliary storage device into memory 30 and executing them by CPU 10.

[0025] The input unit 40 includes a keyboard, a mouse, a touch panel, etc., and is used to input information and give instructions for processing. The output unit 50 is assumed to be a display unit that displays images. The output unit 50 may also be a printer unit, a communication unit that connects to a network such as the Internet and outputs (transmits) information, or a combination of these. The log storage unit 60 records over time the history (programs) of accesses (CPU commands, syscall commands, call commands, etc.) that are processing requests to resources that occur during operation of the information processing device 1, as well as logs of the processing content (request source, etc.) related to such commands.

[0026] The information processing device 1 of the present invention is realized by processes, means, and functions executed by a computer in accordance with instructions from a program (software). The program sends commands to each component of the computer, causing it to perform predetermined processes, functions, etc. according to the present invention. In other words, each process, means, and function according to the present invention is realized by specific means formed by the program and the computer working together. All or part of the program may be provided on a computer-readable recording medium, such as a magnetic disk, an optical disk, a semiconductor memory, or any other computer-readable recording medium, and the program may be read from the recording medium, installed on a computer, and executed. In other words, the program of the present invention may be recorded on a computer-readable recording medium, read from the recording medium, and executed. The program can also be loaded directly into a computer via a communication line and executed without using a recording medium. Furthermore, the information processing device according to the present invention can be configured as a single information processing device (for example, one computer) or as a plurality of information processing devices (for example, a group of multiple computers).

[0027] FIG. 2 is a diagram showing the main components of the chipset 11. As shown in FIG. The chipset 11 refers to a set of multiple IC chips mounted on a motherboard. A register (also called a CPU register) is a memory circuit implemented within an IC chip. The names of the components and functions listed below include names used in Intel's x86-64 architecture, but these are examples and may be replaced with components or functions with similar functions from other companies or in other architectures. As shown in FIG. 2, there are multiple registers, such as an MSR (Model Specific Register) 101, which is an example of a specific register, a CR 102, which is an example of a control register, a GS 103, which is an example of a segment register, an RIP (Instruction Pointer Register) 104, which is an example of an instruction address register, and a general-purpose register, which are collectively referred to as a register group 100. As shown in FIG. 2, the register group 100 is basically implemented inside the chipset 11, and the memory 30 is implemented outside the chipset 11.

[0028] MSR_IA32_LSTAR is shown as a specific example of MSR 101. MSR_IA32_LSTAR has the role of holding the address of the control transfer destination (jump destination) (the address of the system service dispatcher of the processing transfer destination, managed by the kernel) when a system call instruction (hereinafter also referred to as a "syscall instruction") is executed, and informing the CPU of this address. Hereinafter, the system service dispatcher of the processing transfer destination will also be referred to as the "processing transfer destination SSD."

[0029] CR102 is a register for controlling the control mode and functions of the CPU. For example, in CR0, PE (bit 0) can be set to enable protected mode, and PG (bit 31) can be set to enable paging. The GS 103 is used to reference a specified segment (memory area). For example, by storing the base address of a KPCR (Kernel Processor Control Region) 41, the GS 103 is referenced when the KPCR 41 is accessed. The RIP 104 holds the address (virtual address) of the next instruction that the CPU 10 will execute. General-purpose registers are registers used for various purposes, such as calculations and temporary storage of data, and include RAX and RBX, for example. The RIP 104 is an example when the CPU operation mode is 64-bit mode, and an EIP (Extended Instruction Pointer) is applied in the case of 32-bit mode, and an IP (Instruction Pointer) is applied in the case of 16-bit mode.

[0030] FIG. 3 shows the state of the HDD 90 after a software package 390 including the monitoring software of the present invention (secure core 300, syscall handler 340, APP handler 350, R0 handler 360) and a specific boot loader 93 is installed in the information processing device 1. The software package 390 is usually stored on a removable disk or an external device (a cloud server or a local server), and by executing an installation process on the information processing device 1, the secure core 300 and the specific boot loader 93 are stored in the HDD 90. As shown in FIG. 3, the secure core 300 includes a syscall handler 340, an APP handler 350, and an R0 handler 360 (hereinafter, these may also be referred to as "handlers"). The information processing device 1 stores the UEFI / BIOS 21 in advance in the flash ROM 20 and stores the OS boot loader 91 in the HDD 90. The information processing device 1 is assumed to have one or more APPs 34 stored (installed) in the HDD 90 in advance. These can be loaded into the memory 30 through a predetermined procedure or method.

[0031] FIG. 4 is an explanatory diagram of the identifying device 900. As shown in FIG. The specific device 900 is a virtualization support mechanism. The specific device 900, i.e., the virtualization support mechanism, is a device (hardware) that, when enabled, can create a virtual environment in which the CPU 10 can operate while switching between two virtualization modes: root mode and non-root mode. The specified device 900 may employ, for example, VT-x (Intel Virtualization Technology for x86) of an Intel CPU. It should be noted that the present invention is not limited to VT-x, and other technologies such as AMD-V (AMD Virtualization) for AMD CPUs, TrustZone and VE (Virtualization Extensions) for ARM CPUs, etc. may also be used. Conventional virtualization (virtual environment) is defined as an environment in which one physical machine can be used as multiple virtual machines, and in a virtual environment, control operations are expected to operate multiple virtual machines in non-root mode. In contrast, in the case of the present invention, when a predetermined condition is met during monitoring in non-root mode under a virtual environment, control is switched to root mode and operations such as invalidating CPU instructions are performed as necessary.

[0032] As shown in FIG. 4, the identifying device 900 is disposed between the CPU 10 and the memory 30. That is, by disposing the specific device 900 between the processor 10 and the memory 30, the specific device 900 is configured to relay CPU instructions input and output between the processor 10 and the memory 30. Therefore, when the virtualization support mechanism (specific device 900) is enabled, all CPU instructions input / output between the CPU 10 and the memory 30 can be relayed and detected by the virtualization support mechanism (specific device 900). In other words, when the CPU 10 reads (fetches) CPU instructions from the memory 30, by enabling the virtualization support mechanism, a specific device 900 appears between the CPU 10 and the memory 30, and the specific device 900 can detect (monitor) the CPU instructions before the CPU 10 fetches them from the memory 30.

[0033] The information processing device 1 of the present invention utilizes the features of the specific device 900 and enables the specific device 900 at startup, thereby creating a monitoring environment for CPU instructions based on a virtual environment before the OS 31 starts up. This makes it possible to monitor all CPU instructions that are highly worth monitoring (ie, CPU instructions output from the memory 30 to the CPU 10). In other words, this type of CPU instruction is a fundamental instruction that forms the basis of all processing in the information processing device 1, and no processing can be executed without this CPU instruction, so, for example, it is possible to detect all invalid CPU instructions without omission, leading to thorough countermeasures. As shown in Fig. 4, the virtualization support mechanism is implemented in a chipset 11. This type of implementation is realized in almost all computers.

[0034] FIG. 5 is an image diagram showing the privilege levels of the monitoring software etc. loaded into the memory and the cooperative relationships (connections) of the components. For ease of understanding, FIG. 4 is placed below FIG. 5, with the memories 30 connected by dashed lines. FIG. 5 shows the privilege level (ring) of each component and the virtualization mode (non-root mode and root mode). The CPU 10 has a function of setting a privilege level (authority level) for the memory 30 . The OS (kernel) 31 has ring:0 set as a privilege level in the memory space. The driver (device driver) 36 is also set to the same privilege level as the kernel, "Ring: 0." The APP 34 is set to the lowest privilege level, "Ring: 3."

[0035] The secure core 300 according to the present invention is set to a privilege level higher than that of Ring:0. In other words, generally, memory space consists of kernel space in ring:0 and user space in ring:3, and there is no memory space with a higher privilege level than kernel space, but by enabling the virtualization support mechanism, it is possible to operate secure core 300 at a higher privilege level (root mode) than ring:0. For this reason, the privilege level to which the secure core 300 is set is defined as "Ring:-1" for convenience. The APP handler 350 sets the privilege level to ring:3, and the syscall handler 340 and the R0 handler 360 set the privilege level to ring:0. In this way, by placing the secure core 300 in a memory area with a higher privilege level than other software, the secure core 300 is able to monitor or control all behavior of the OS (kernel) 31 and other monitoring software (syscall handler 340, APP handler 350, R0 handler 360). That is, the CPU 10 has the function of setting a privilege level (authority level) for the memory 30, and this function prohibits access to or execution of the memory space of the OS (kernel) 31, driver 36, and syscall handler 340 from the memory space of the APP 34. Furthermore, by enabling the specific device 900, a higher privilege level is set for the memory space of the secure core 300 than for the memory space of the OS 31 (kernel). This prohibits the OS 31 (kernel) and the driver 36 from accessing or executing the secure core 300 . This prevents the monitoring software from being tampered with or stopped. Furthermore, simply by setting secure core 300 to a higher privilege level than ring:0 on which OS31 operates, it becomes difficult for OS31 to access or recognize secure core 300, thereby preventing fraud such as tampering with secure core 300 itself.

[0036] In addition, in Figure 5, solid arrows indicate the cooperation (connections) between the components. Specifically, the secure core 300 is connected to a syscall handler 340, an APP handler 350, and an R0 handler 360 (a, b, e), allowing the secure core 300 to monitor and control the behavior of each handler. This shows, for example, that the secure core 300 causes the processor 10 to load each handler. The syscall handler 340 is disposed between the APP handler 350 and the OS 31, and is also connected to the secure core 300 (c, d). This indicates that the syscall handler 340 relays a syscall command issued from APP 34 to OS 31. The syscall handler 340 also causes the processor 10 to monitor a syscall command issued from APP 34, and when it detects a syscall command, it hooks control, passes control to the secure core 300, and then returns control to OS 31. The R0 handler 360 is disposed between the driver 36 and the OS 31, and is also connected to the secure core 300 (f, g). This indicates that the R0 handler 360 relays a call command issued from the driver 36 to the OS 31. The R0 handler 360 also causes the processor 10 to monitor a call command issued from the driver 36, and when it detects a call command, it hooks control, passes control to the secure core 300, and then returns control to the OS 31.

[0037] FIG. 6 is a functional block diagram of the information processing device 1 of the present invention. As shown in FIG. 6, the information processing device 1 includes software specific to the present invention, namely, a specific boot loader 93, a secure core 300, a syscall handler 340, an APP handler 350, and an R0 handler 360. The OS boot loader 91 and the OS 31 are software that has existed for some time.

[0038] (specific bootloader 93) The specific boot loader 93 starts up before the OS boot loader 91 , thereby creating an environment such as enabling the specific device 900 before the OS 31 does, and creating an environment that can be monitored by the secure core 300 . Specifically, the specific boot loader 93 includes a load unit 931 , an activation unit 932 , a boot control unit 933 , and an area management unit 934 . The specific boot loader 93 is software (program) according to the present invention that causes the CPU 10 to execute each of these means.

[0039] The load means 931 loads the secure core 300 (predetermined software) into a memory area with a privilege level of ring:-1 (see S23 in FIG. 9). The validation means 932 validates the specific device 900, which is the virtualization support mechanism (see S32 in FIG. 11). Specifically, the validation unit 932 activates the specific device 900 in response to the power-on of the information processing device 1. By enabling the specific device 900, the CPU 10 can operate while switching between two virtualization modes, namely, the non-root mode and the root mode.

[0040] The boot control means 933 controls the execution timing of booting up the OS (OS boot means 91) and loading the secure core 300 (predetermined software) in response to power-on of the information processing device 1. Specifically, when the information processing device 1 is powered on (started up), the start-up control means 933 first loads the secure core 300, and then controls the start-up of the OS 31 (FIGS. 8 and 9). The area management means 934 manages the software area where the secure core 300 (predetermined software) is loaded by registering it as an MMIO area (hardware area) in the physical memory map (see FIGS. 9 and 10).

[0041] By the way, UEFI / BIOS21 provides software (including the operating system) with information in the form of a table called a physical memory map, which describes which ranges of physical addresses are available for software use, which ranges are designated as MMIO, and their attributes. OS31 refers to this physical memory map to recognize the memory layout. In other words, OS31 cannot recognize the MMIO area as an available area. As a result, the OS 31 does not recognize the area (MMIO area) into which the secure core 300 is loaded as an area that can be used by the OS 31, and therefore, unauthorized access to the secure core 300 using the OS 31 can be prevented.

[0042] (OS boot loader 91) The OS boot loader 91 functions as an OS startup means 91 . The OS startup means 91 is a known function, and starts up the OS 31 in response to power-on of the information processing device 1 (see step A2 in FIGS. 7 and 8).

[0043] (OS31) The OS 31 includes an APP loading unit 301 as a known function. The APP loading means 301 loads the APP 34 into the process 35 in the memory 30 by the OS 31 in response to the activation of the APP 34 .

[0044] (Secure Core 300) The secure core 300 is software (program) according to the present invention that functions as a monitoring means (CPU instruction monitoring means) that monitors CPU instructions. The secure core 300 includes a monitoring unit 310 that causes the CPU 10 to monitor and inspect CPU instructions, and a linking unit 320 that causes the CPU 10 to load and link the syscall handler 340 and the APP handler 350.

[0045] Specifically, the monitoring unit 310 includes a CPU instruction detection means 311, a disabling means 312, and an authority setting means 313. That is, the secure core 300 causes the CPU 10 to execute the operation of each means. The CPU instruction detection means 311 detects a CPU instruction via the specific device 900 (virtualization support mechanism). Specifically, the CPU instruction detection means 311 detects CPU instructions input / output between the CPU 10 (processor) and the memory 30 (see FIG. 4, etc.). More specifically, when the information processing device 1 is powered on, the specific device 900 (virtualization support mechanism) is enabled by the specific boot loader 93 (enabling means 932), and therefore the CPU instruction detection means 311 can detect CPU instructions input / output between the CPU 10 and memory 30 via the specific device 900 from the timing of power-on (before the OS 31 is started).

[0046] When a specific CPU instruction is detected by the CPU instruction detection means 311, the invalidation means 312 determines whether the instruction is valid, and invalidates the specific CPU instruction if the instruction is invalid (S64 in FIG. 15). The specific CPU instruction corresponds to, for example, a privileged instruction (an instruction that can only be issued by ring:0) for a specific register (CR0, CR3, CR4, MSR, etc.). In other words, among the instructions issued by the kernel 31, a CPU instruction that can change the function or operation of the CPU 10 can be exemplified as an object of correctness determination. More specifically, when a CPU instruction (MOV instruction) for CR0, CR3, or CR4, or a CPU instruction (WRMSR, RDMSR) for MSR, is detected, the secure core 300 causes the processor 10 to perform a correct / incorrect determination for these specific CPU instructions (privileged instructions). The issuance of privileged instructions cannot be monitored by the program in ring:0, but a specific device 900 (virtualization support mechanism) that can monitor CPU instructions between the CPU 10 and memory 30 is used to monitor and determine (inspect) whether the privileged instructions are correct or not.

[0047] The validity determination is made by determining whether the issuer of a specific CPU instruction is valid, for example. Specifically, if the issuer is the kernel, it is determined to be valid, and if it is not the kernel, it is determined to be invalid. As a criterion for judgment, not only issuance from the kernel but also issuance from a specific group of drivers that operate as functions of OS31 can be permitted as legitimate. If the result of this validity determination is invalid, the invalidation means 312 executes, for example, ignoring the specific CPU instruction. If the result of the validity determination is valid, the secure core 300 executes (continues) the processing related to the specific CPU instruction.

[0048] The authority setting means 313 sets authority information relating to writing to a page table corresponding to an area managed by the secure core 300 (predetermined software) based on the activation of the virtualization support mechanism (specific device 900). This page table is a two-stage page translation table such as an EPT (Extended Page Table) and can be used in a virtual environment. In other words, while a normal page table performs a one-stage page conversion, from linear address (virtual address) to OS31 page table to physical address, EPT performs an extended two-stage page conversion (second-level address conversion) in the virtual environment, from guest linear address to guest OS page table to guest physical address to EPT to host physical address.

[0049] The EPT is a page table that assigns memory addresses starting from address 0 to each OS for the original purpose of running multiple OSs simultaneously in a virtual environment. The EPT has the function of defining (setting) access permissions (write, read, execute) for a specified physical memory area. For example, it is possible to disable write permission (write=0) for the page table corresponding to a specified physical memory area. In this case, if a write is made to a physical memory area for which write permission has been disabled, an EPT violation will occur due to the virtualization support mechanism. The present invention utilizes the function of this EPT to set the page table corresponding to the storage area (MMIO area) of the secure core 300 to disable write permission. By doing so, if a write command is issued to the storage area of ​​the secure core 300, an EPT violation occurs, and this triggers the secure core 300 to hand over control to the processing of the processor 10, and executes processing to ignore (invalidate) the write.

[0050] This not only prevents unauthorized access from the OS 31 by making the storage area of ​​the secure core 300 MMIO, but also prevents any attempt to access and tamper with (write to) the secure core 300 in some way (for example, by hijacking the OS 31). In other words, the secure core 300 can be robustly protected by double defensive measures. EPT is a term that refers to the two-stage page translation table provided by Intel, and two-stage page translation tables from other companies (e.g., AMD's NPT, ARM's Stage-2Translation, etc.) and their associated functions can also be applied.

[0051] The linking unit 320 of the secure core 300 includes a first loading means 321, a second loading means 322, and an address change writing means 323. That is, the secure core 300 causes the CPU 10 to execute the operation of each means. The first loading means 321 causes the processor 10 to load a syscall handler 340 (first software) having a function of monitoring a syscall instruction. Specifically, the first loading means 321 loads the syscall handler 340 included in the secure core 300 into the memory 30 (memory area with privilege level: ring: 0) during initial processing immediately after the OS 31 is started (S43 in FIG. 13).

[0052] The second loading means 322 loads an APP handler 350 (second software) that has a function for determining whether a syscall command is correct or not. Specifically, the APP handler 350 is loaded by the load control means 344 in cooperation with the syscall handler 340. In other words, the loading of the syscall handler 340 by the second load means 322 is controlled by the load control means 344 (see the description of FIGS. 16 and 17). The APP handler 350 is loaded into the memory space of each process 35 corresponding to each APP 34 . In this way, by storing the APP handler 350 in each process, the APP handler 350 present in the process 35 itself essentially determines whether the syscall command issued from the APP 34 (process 35) is correct or not. This allows the load to be distributed more than if success / failure were to be determined centrally in one handler, preventing overload and achieving high-speed processing. The secure core 300 causes the processor 10 to load an R0 handler 360 capable of monitoring call instructions into a memory area at privilege level: ring: 0.

[0053] When a CPU instruction (WRMSR) to write to MSR101 (specific register) is detected (i.e., when a CPU instruction to write the kernel side address of the processing transfer destination to MSR_IA32_LSTAR is detected), the address change writing means 323 changes the address of the processing transfer destination that was to be written to the MSR101 (specific register) to the memory address of the syscall handler 340 (first software) (the address of the syscall handler 340 loaded by the first loading means 321 during the initial processing after OS31 startup, as mentioned above), and writes it to the MSR101 (specific register). That is, the secure core 300 writes the address of the process transfer destination SSD, which was originally intended to be written to MSR_IA32_LSTAR, into MSR_IA32_LSTAR instead of the memory address of the syscall handler 340 . As a result, when a syscall command is issued, the process would normally jump to the address of the SSD to which the processing is to be transferred and the processing would be handed over to the SSD at high speed, but instead it can jump to the address of the syscall handler 340 and the processing can be handed over to the syscall handler 340 at high speed.

[0054] (Syscall Handler 340) The syscall handler 340 is software (program) according to the present invention that is set to an executable state by the setting (FIG. 13) during the initial processing after the OS 31 is started. As a result, the syscall handler 340 is handed over processing in response to the issuance of a syscall instruction, and functions as a linking unit that causes the processor 10 to load and link to the APP handler 350. In other words, when a syscall instruction is issued, the syscall handler 340 is able to immediately execute processing by directly transferring the instruction without hooking it. For example, the syscall handler 340 cooperates with the OS 31 and the secure core 300 to control the loading of the APP handler 350 while the APP 34 is running, and after the loading, monitors the syscall command and passes processing to the APP handler 350 in response to the issuance of the syscall command.

[0055] Specifically, the syscall handler 340 includes a process identification unit 341, a load state information storage unit 342, a load state determination unit 343, and a load control unit 344. That is, the syscall handler 340 causes the CPU 10 to execute the operation of each unit. The process identification means 341 identifies the process currently being executed based on the issued syscall command. Specifically, when APP34 is started, one or more processes 35 corresponding to its execution are generated, and each process 35 is composed of one or more threads, and each thread and process 35 operates simultaneously in parallel (concurrently). Therefore, the process identification means 341 identifies the process 35 that issued the syscall command by tracing the process structure from the KPCR 41. More specifically, the address of the currently executed thread (KTHREAD 43) is constantly updated in the KPCR 41, and by referencing this, the process 35 currently being processed can be identified (see the description of FIG. 16 below). That is, the process identification means 341 identifies the process 35 currently in operation based on the syscall command issued from each process 35 .

[0056] The load status information storage means 342 stores the load status information (identification information that can identify that the APP handler 350 (second software) is not loaded) inside the KPROCESS 44 corresponding to the process 35 that has been identified as being in processing (Figures 16 and 17). That is, the load state information storage means 342 stores identification information indicating the load state of the APP handler 350 (second software) in the process 35 in the management structure (KPROCESS 44) corresponding to the process 35. The load state determination means 343 determines the load state of the APP handler 350 (second software) in the corresponding process 35 based on the load state information stored in the load state information storage means 342. Specifically, it determines whether the APP handler 350 has already been loaded. That is, in response to the issuance of a syscall command, the load state determination means 343 determines, for each process 35, based on the identification information, that the APP handler 350 (second software) has not been loaded.

[0057] The load control means 344 loads an APP handler 350 (second software) into each process 35 corresponding to one or more APPs 34. Specifically, the APP handler 350 (second software) is loaded into the process 35 currently being executed that is identified by the process identification means 341 among the processes 35 corresponding to one or more APPs 34. The load control means 344 controls the loading of the APP handler 350 into the process 35 for which the load state determination means 343 has determined that the APP handler 350 has not been loaded (FIG. 16). In other words, if it is determined that the APP handler 350 is not already loaded, the OS 31 is requested to reserve a memory area for the APP handler 350, and upon the reservation, the memory address obtained from the OS 31 is notified to the secure core 300 to request loading. In response to this, the secure core 300 loads the APP handler 350 into the memory area at the notified memory address. Specifically, the APP handler 350 (second software) is loaded into the process 35 in which the load state determination means 343 has determined that the APP handler 350 (second software) is not already loaded. This allows the APP handler 350 to determine whether the syscall instruction that triggered the loading of the APP handler 350 and any subsequent syscall instructions are correct.

[0058] (APP Handler 350) The APP handler 350 is software (program) according to the present invention that cooperates with the syscall handler 340 to monitor syscall instructions (determine whether they are correct or not). Specifically, the APP handler 350 includes a first identification unit 351, a second identification unit 352, and a correct / incorrect determination unit 353. That is, the APP handler 350 causes the CPU 10 to execute the operation of each unit. The correctness determining means 353 is a process in which the APP handler 350 (second software) loaded into the process 35 causes the processor 10 to determine whether a system call command issued from the process 35 is correct or not. The correctness determining means 353 can also determine correctness based on the program size of the APP 34, for example, and includes a first specifying means 351 and a second specifying means 352 as components for this purpose.

[0059] The first identification means 351 identifies the program size of the APP 34 before it is loaded into the memory 30. The first identification means 351 identifies, for example, the program size of the APP 34 in a state where it is stored in the HDD 90 after it has been installed. The size of the program stored in the HDD 90 can be obtained using a unique file ID (such as NTFS) managed by the OS 31. The second specifying means 352 specifies the program size of the APP 34 after it has been loaded into the memory 30 . The correctness determining means 353 of the APP handler 350 causes the processor 10 to determine whether the syscall command issued from the process 35 is correct or not.

[0060] The correct / incorrect determination means 353 also executes a process of determining whether APP34 is correct or incorrect based on the program size (first size) of APP34 identified by the first identification means 351 and the program size (second size) of APP34 identified by the second identification means 352. Specifically, if the first size and the second size are the same, it is determined to be valid, and if they are different, it is determined to be invalid. In this way, in the present invention, a method of determining whether or not the APP 34 is valid is applied, in which the APP 34 is determined to be invalid if the size of the APP 34 is different before and after processing.

[0061] This is because conventional security systems have searched and determined whether malicious code (such as virus software) has been embedded in the application program itself. In response to this, in recent years, a method has been discovered in which application programs incorporating malicious code are compressed or encrypted to evade searches. Therefore, according to the method of determining whether or not the program is correct, if APP34 is decrypted into memory 30 and malicious code is embedded in the APP34, the program size after decryption (i.e., the program size after loading into memory 30) will inevitably differ from the program size before loading into memory 30, and therefore such maliciousness can be detected.

[0062] (R0 Handler 360) The R0 handler 360 includes a call instruction detection unit 361 and a correct / incorrect determination unit 362 . The call command detection means 361 detects a call command issued by the driver 36 . The correctness determining means 362 determines whether the call command issued by the driver 36 is correct or not.

[0063] An information processing method executed in the information processing device 1 of the present invention will be described. The information processing method described below corresponds to a processing flow executed by a computer in accordance with instructions of the program (software) of the present invention. To make the startup process of the present invention easier to understand, first, a flow from power-on to APP startup in a conventional information processing device will be outlined, and then a flow from power-on to APP startup in the information processing device 1 of the present invention will be outlined.

[0064] FIG. 7 is a flowchart showing the process from power-on to APP startup in a conventional information processing device. As shown in FIG. 7, the power is turned on in a conventional information processing device (S1). When the power is turned on, UEFI / BIOS21 starts up (S2). Specifically, when the power is turned on, the UEFI / BIOS 21 stored in the flash ROM 20 is loaded (mapped) into the memory 30 (physical memory) and executed.

[0065] Next, the OS boot loader 91 is started (step A1). This is because the UEFI / BIOS 21 is designed to execute the OS boot loader 91 (bootmgfw.efi, winload.efi, etc.) that is pre-stored in the EFI system partition (FAT32) of the HDD 90 as standard. In other words, in computers that come with the Windows OS pre-installed or are designed for Windows, the UEFI / BIOS 21 is configured by the hardware manufacturer (computer manufacturer) to first execute the OS boot loader 91 stored in the EFI system partition (FAT32). Computers designed for other OSs are often configured in a similar way. Thereafter, the boot loader (OS boot loader 91) starts up the OS 31 (step A2) and the APP 34 (step A3). For this reason, almost all computers are designed to start OS31 first after booting, and it is not expected that other software will start before OS31 starts. The processes of steps A1 to A3 are collectively referred to as "step A."

[0066] In contrast to this, the process from power-on to APP startup in the information processing device 1 of the present invention will be described. FIG. 8 is a flowchart showing the process from power-on to APP startup in the information processing device of the present invention. The secure core 300 and the specific boot loader 93 are installed in advance in the HDD 90 . Specifically, when the software package 390 is installed in the information processing device 1, the secure core 300 and the specific boot loader 93 are stored in the HDD 90 (see FIG. 3). At this time, the specific boot loader 93 is stored in the same folder as the OS boot loader 91 . An OS boot loader 91 is stored in the EFI system partition (FAT32), and during installation, this OS boot loader 91 is backed up (stored) in a predetermined area of ​​a storage medium such as the HDD 90. Specifically, the OS boot loader 91 stores the file in the same location (in the folder) where it was originally stored, with a different extension. This is because it is necessary to start up the OS 31 in the subsequent process (step A1).

[0067] As shown in FIG. 8, the UEFI / BIOS 21 starts up when the information processing device 1 is powered on (S1 to S2). As mentioned above, almost all computers start UEFI / BIOS21 when powered on.

[0068] Next, the specific boot loader 93 is searched for (S3). Specifically, the UEFI / BIOS 21 determines whether or not the specific boot loader 93 exists through a search (S4). If this search determines that the specific boot loader 93 is "present" (S4: present), the specific boot loader 93 is started (S5), and if it determines that the specific boot loader 93 is "not present" (S4: absent), an error is reported and / or processing is stopped (S7). In the information processing device 1 of the present invention, it is determined that the specific boot loader 93 is present, and therefore the specific boot loader 93 is automatically started up. This is because the specific boot loader 93 is stored in the same folder as the OS boot loader 91 (replaced). Then, the specific boot loader 93 starts up and executes a predetermined process (S6). That is, the UEFI / BIOS 21 starts the specific boot loader 93 before the OS boot loader 91 (bootmgfw.efi, winload.efi, etc.) (S5 to S6 to step A1). As a result, the specific boot loader 93 is started before the OS 31 is started, and the following processing is executed.

[0069] FIG. 9 is a sub-flowchart showing the processing of the specific boot loader 93 (S6 in FIG. 8). As shown in FIG. 9, the specific boot loader 93 acquires the physical memory map (S21). Specifically, UEFI / BIOS 21 manages physical memory by dividing it into a hardware area (area usable by hardware) and a software area (area usable by software). Although UEFI / BIOS 21 is software, it is exceptionally managed as a hardware area. The specific boot loader 93 acquires from the UEFI / BIOS 21 a physical memory map indicating the management contents. The hardware area is called "MMIO (Memory Mapped I / O)" and is managed as an area for input and output to and from computer peripherals (hardware devices).

[0070] Next, the specific boot loader 93 reserves a memory area for the secure core 300 (S22). Specifically, the specific boot loader 93 searches for and reserves an area capable of storing the secure core 300, which is software, from the software area of ​​the physical memory map obtained from the UEFI / BIOS 21. That is, the specific boot loader 93 can search the software area of ​​the physical memory map provided by the UEFI / BIOS 21, but cannot search the hardware area. However, since the software area is originally an area for use by the OS 31, there is a risk that the OS boot loader 91 will subsequently use (reserve) the software area as an area for the OS 31. Such an area is allocated by registering it in the physical memory map. Therefore, when the specific boot loader 93 secures a memory area for the secure core 300, it manages the memory area (software area) secured for the secure core 300 by registering (storing) it as an MMIO area (hardware area) in the physical memory map (area management means 934).

[0071] Figure 10 (a) is an image of a physical memory map showing that a software area has been reserved for secure core 300, and (b) is an image of a physical memory map showing that the reserved area for secure core 300 has been changed and registered as an MMIO area (hardware area) after (a). This allows the OS 31 to recognize the memory area of ​​the secure core 300 as an area that cannot be used by the OS 31.

[0072] Next, the specific boot loader 93 loads the secure core 300 (S23). Specifically, the secure core 300 stored in the HDD 90 is loaded into the memory area secured in S22 (loading means 931). As a result, the secure core 300 is stored in an MMIO area that cannot be recognized (searched) by the OS 31 . Therefore, even if someone tries to gain unauthorized access to the secure core 300 by, for example, taking over the OS 31, the OS 31 cannot recognize (search for) the secure core 300 in the first place, and therefore cannot access the secure core 300, thereby preventing tampering. Next, the specific boot loader 93 executes the initial processing of the secure core 300 (S24).

[0073] FIG. 11 is a sub-flowchart showing the initial processing procedure for the secure core 300 (S24 in FIG. 9). As shown in FIG. 11, in the initial processing of the secure core 300, the specific boot loader 93 first executes processing related to the construction of an execution environment for the secure core 300 (S31). This is to perform preparatory processing to run the secure core 300 in the CPU operating environment of ring:-1 (root mode). This is because at the processing stage of the specific boot loader 93, the CPU 10 is operating in ring:0, and ring:-1 (root mode) does not yet exist.

[0074] Here, the specific device 900 realizes virtualization by switching between root mode and non-root mode. Specifically, the CPU registers for each mode (GDT (Global Descriptor Table), IDT (Interrupt Descriptor Table), page table (CR3), control registers (CR0, CR4), EPT (Extended Page Table), etc.) are stored in physical memory. When an instruction to switch to the root mode is issued to the specific device 900, all of the registers for the root mode are loaded from the physical memory into the CPU registers. When an instruction to switch to the non-root mode is issued to the specific device 900, all of the registers for the non-root mode are loaded from the physical memory into the CPU registers, thereby realizing virtualization.

[0075] Therefore, in the initial processing of the secure core 300, the execution state (CPU register group) of the specific boot loader 93 is saved in physical memory as a register group for non-root mode, and the execution state (CPU register group) of the secure core 300 is changed to a register group that operates as ring:-1 (root mode), and then saved in physical memory as a register group for root mode. This allows the specific device 900 to be enabled later and continue running as ring:-1 (root mode).

[0076] In addition, by configuring the specific device 900 so that when a read or write command to a CPU register is issued in ring:0 (non-root mode), an instruction to switch to ring:-1 (root mode) is generated, the CPU register group in ring:0 (non-root mode) can be referenced by OS31 as a pseudo register group. That is, OS31 can continue normal processing using pseudo registers, so that the contents of pseudo registers and the like required for OS31 processing can be maintained while preventing unauthorized tampering with the pseudo registers.

[0077] Next, the specific boot loader 93 enables the virtualization support mechanism (S32). Specifically, the specific boot loader 93 causes the UEFI / BIOS 21 to enable the specific device 900 (for example, VT-x) during the initial processing of the secure core 300 (enabling means 932). In other words, the operation of the CPU 10 is virtualized by the specific device 900 disposed between the CPU 10 and the memory 30 . This enables the CPU 10 to switch between root mode and non-root mode, and allows the secure core 300 to operate at a higher privilege level (ring: -1, root mode) than the OS31 (ring: 0).

[0078] Next, the specific boot loader 93 sets the monitoring conditions for the secure core 300 (S33). For example, a transition condition for transitioning control to the root mode is set. Specifically, when the mode is changed from non-root mode to root mode, control is handed over to the secure core 300, and the conditions for this change are set. As an example of a transition condition, detection of a specific CPU instruction (a privileged instruction that can only be issued by ring:0) for a specific register (CR0, CR3, CR4, MSR, etc.) is given. Examples of specific CPU instructions include a MOV instruction for CR0, CR3, and CR4, and a WRMSR or RDMSR instruction for MSR. If an unauthorized privileged instruction causes unauthorized access to a specific register, control may be transferred to attack code, or the range of memory access may be changed, resulting in the execution of an unauthorized program and causing severe damage to the CPU's functions and operations. For this reason, the present invention monitors and detects these specific CPU instructions to determine whether or not they are illegal. It should be noted that CPU instructions other than those illustrated may also be applied to specific CPU instructions.

[0079] Furthermore, as a secure core monitoring condition, a setting is made to protect the memory area of ​​the secure core 300 secured in S22 of FIG. 9 using the EPT. Specifically, the write bit of the EPT page corresponding to the memory area (MMIO area) of the secure core 300 is set to "0." In other words, a setting is made to disable the write authority for the memory area of ​​the secure core 300 (authority setting means 313).

[0080] In addition, as a secure core monitoring condition, when a write CPU instruction (WRMSR) to MSR101 (MSR_IA32_LSTAR) is detected, instruction information is set (stored) to hold the address of the SSD to which processing is to be transferred, or to write the address to be written to MSR101 to the memory address of the syscall handler 340. At the end of the initial processing of the secure core 300, a command (VMLaunch) for starting up the guest OS is executed. This returns control from root mode to non-root mode. This also ends the processing of the specific boot loader 93 (S6 in FIG. 8), and the secure core 300 is ready for monitoring.

[0081] As described above, in the information processing device 1 of the present invention, a virtual environment is constructed before the OS 31, and an execution environment for the secure core 300 is prepared. That is, when the power is turned on, the OS 31 is originally started by the UEFI / BIOS 21 built into the hardware, which starts up the OS boot loader 91 stored in the HDD 90 first. In contrast, in the present invention, when the secure core 300 is installed, the OS boot loader 91 is replaced with the specific boot loader 93 of the present invention, so that when the power is turned on, the specific boot loader 93 is started first by the UEFI / BIOS 21, rather than the OS boot loader 91. The specific boot loader 93 can create a state in which all software (OS 31 and APP 34) to be started later is executed in a virtual environment by activating the specific device 900 arranged between the CPU 10 and the memory 30. In other words, all of the processes included in step A shown in FIG. 8 can be monitored.

[0082] In addition, the CPU 10 reads (fetches) and processes CPU instructions from the memory 30, and these CPU instructions are monitored and detected without omission using a specific device 900 (virtualization support mechanism) located between the CPU 10 and the memory 30. The specific device 900 is enabled (virtualized) before OS31 is started, thereby maintaining the contents of various registers required for OS31 processing, thereby preventing unauthorized tampering later. In addition, since the APP 34 cannot operate without requesting processing from the OS 31, it is possible to comprehensively monitor the CPU instructions (syscall instructions) that make these requests, since the fetching of instructions (reading from memory) is an operation that governs the basic functions of the CPU 10. The specific device 900 is implemented in most chipsets 11 currently in use, and is therefore highly versatile.

[0083] Next, the OS boot loader (OS startup means) 91 is started (step A1 in FIG. 8). Specifically, the specific boot loader 93 starts the OS boot loader 91 . More specifically, the OS boot loader 91 that was backed up when the software package 390 was installed when the power was turned on is started. As a result, the OS boot loader 91 starts up the OS 31 (step A2) and the APP 34 (step A3). The processing of step A (A1 to A3) can be entirely monitored by secure core 300 since it is the initial processing of the secure core and processing after the execution environment is established. The processing of step A according to the present invention (FIG. 8) is basically the same as the processing of step A in the conventional technology shown in FIG. 7, but the present invention differs from the conventional technology in that the syscall handler 340 and the R0 handler 360 are set (FIGS. 13 and 14) when the OS 31 is started. First, the syscall handler 340 according to the present invention will be described.

[0084] To make the syscall handler 340 easier to understand, first, a normal syscall execution method will be explained, and then the syscall execution method of the present invention will be explained. The left diagram of FIG. 12 is a diagram outlining a normal (conventional) syscall execution method, and the right diagram of FIG. 12 is a diagram outlining a syscall execution method of the present invention. As shown in the left diagram of Figure 12, in the normal syscall execution method, during the initial processing after OS startup, the kernel side address of the processing transfer destination SSD corresponding to the syscall command is written to the specific register MSR_IA32_LSTAR. The "processing transfer destination SSD" is a processing mechanism that allocates and executes the entity of the called service (processing function) after control is transferred to the kernel by a syscall command. As a result, if a syscall command is issued after the initial processing (during normal operation), control is passed to the SSD to which processing is being transferred by jumping to the address written in MSR_IA32_LSTAR. That is, the conventional information processing device 1 includes a control means that causes the processor 10 to execute the processing of the processing transfer destination SSD (software) stored at the address written in the MSR_IA32_LSTAR (specific register) based on the address.

[0085] In contrast, the syscall execution method related to the syscall handler 340 of the present invention performs processing to change the address of the processing destination SSD that was attempted to be written to MSR_IA32_LSTAR in the "normal syscall execution method" to the memory address of the syscall handler 340 during initial processing after OS startup, as shown in the right diagram of Figure 12. As a result, when a syscall command is issued after the initial processing (during normal operation), control is passed to the syscall handler 340 by jumping to the address written in MSR_IA32_LSTAR.

[0086] (How to set up syscall handler 340) A method for setting the syscall handler 340 will now be described in detail. FIG. 13 is a flowchart showing a method for setting the syscall handler 340. As described above, the syscall handler 340 is set during the initial processing after the OS 31 is started. As shown in FIG. 13, first, the secure core 300 detects a page fault (S41). A page fault is an exception interrupt that occurs when physical memory has not yet been allocated to the memory area that a program (APP34) is trying to access, and typically occurs during the algorithm that configures the OS's virtual memory space. In other words, the OS first prepares a virtual memory space (page table), but since physical memory has not been allocated at the time of access, a page fault occurs when a program accesses a virtual address at that time.

[0087] The timing at which a page fault occurs can be determined as the OS boot loader 91 has already created the initial page for the OS kernel itself to run, and the OS has secured and is now able to manage memory space for other programs (drivers, applications, etc.).This is because page faults begin to occur when the memory manager mechanism within the OS is in place and is able to manage physical memory and free space. For this reason, in this embodiment, the syscall handler 340 is loaded into the memory 30 when a page fault is detected (that is, when a page fault begins to occur).

[0088] Next, the secure core 300 reserves a memory area for the syscall handler 340 (S42). Specifically, the secure core 300 instructs the OS 31 to reserve a memory area for the syscall handler. As a result, the OS 31 reserves an area in the free area of ​​the memory 30 that can be used (stored) by the syscall handler 340 . When the OS 31 has completed the allocation of the memory area, it notifies the secure core 300 of the allocated memory address.

[0089] Next, the secure core 300 loads the syscall handler 340 (S43). Specifically, the secure core 300 loads its own syscall handler 340 into the reserved memory area. That is, the first loading means 321 loads into the memory 30 a syscall handler 340 (first software) that can monitor system call instructions.

[0090] Next, the secure core 300 detects a write instruction to the MSR 101 (S44). Specifically, the secure core 300 detects a WRMSR (write CPU instruction) issued by the OS 31 to MSR_IA32_LSTAR. The secure core 300 identifies and stores the address of the SSD to which the processing is to be transferred (S45). This is because in normal processing, when a syscall command is issued, predetermined processing such as determining whether the command is correct or not is executed in cooperation with the syscall handler 340 and the APP handler 350, and if a valid result is obtained in this determination, the processing is returned to the SSD, and the corresponding API is allocated.

[0091] Then, the secure core 300 changes the address of the process transfer destination SSD to be written to the MSR 101 to the memory address of the syscall handler 340 (S46). That is, in the normal syscall execution method, the address of the processing transfer destination SSD that OS31 is attempting (planning) to write to MSR101 (MSR_IA32_LSTAR) is changed to the memory address of the syscall handler 340 and written to the MSR101 (MSR_IA32_LSTAR) (address change writing means 323). That is, in response to the issuance of a CPU instruction (WRMSR) commanding a write to MSR_IA32_LSTAR (specific register), the address change writing means 323 changes the address of the processing transfer destination SSD to be written to the specific register to the address of the syscall handler 340 (first software) loaded by the first loading means 321 and writes it to MSR_IA32_LSTAR (specific register). This completes the setup of the syscall handler 340.

[0092] (How to set up R0 Handler 360) A method for setting the R0 handler 360 will now be described. The R0 handler 360 performs the setting at the same timing as the syscall handler 340 . FIG. 14 is a flowchart showing a method for setting the R0 handler 360. The R0 handler 360 is set during the initial processing after the OS 31 is started. As shown in FIG. 14, first, the R0 handler 360 is loaded at a predetermined timing (when a predetermined condition is met) (S51). Specifically, the secure core 300 causes the OS 31 to reserve an area from the free area of ​​the memory 30 that can be used by the R0 handler 360 . The secure core 300 then loads the R0 handler 360 provided therein into the memory area allocated by the OS 31 .

[0093] Next, a breakpoint is set at the start address of the API (processing function) corresponding to the call instruction (S52). Specifically, the instruction address corresponding to the entry point of the API function managed by the kernel is overwritten with the INT3 instruction, and a breakpoint exception is generated at execution time. Also, in the INT table, the address of the corresponding #BP is rewritten to the memory address of the R0 handler 360 (S53). This completes the setting of the R0 handler 360.

[0094] (Monitoring operation) Once the preparatory processing (S1 to S6 in Figure 8) such as the initial processing of secure core 300 and processing after the execution environment is established is completed, if the transition condition is met during non-root mode, the system will transition to root mode and control will be transferred to secure core 300. In other words, it becomes possible to monitor (detect) CPU instructions. Furthermore, once the setting of the syscall handler 340 (FIG. 13) during the OS initialization process (step A2) is complete, the syscall handler 340 can monitor the issuance of syscall instructions during non-root mode. Furthermore, once the setting of the R0 handler 360 (FIG. 14) during the OS initialization process (step A2) is completed, the R0 handler 360 can monitor the issuance of call instructions during non-route mode.

[0095] (Monitoring CPU instructions by Secure Core 300 - validity determination) FIG. 15 is a flowchart showing the process of monitoring a CPU instruction and determining whether it is correct or not. CPU instruction monitoring can be performed while in non-root mode. Specifically, in the non-root mode after the processing of the specific boot loader 93 (S6 in FIG. 8) is completed, the secure core 300 is in a state where it can monitor CPU instructions and determine whether they are correct or not (CPU instruction monitoring state).

[0096] 15, during CPU instruction monitoring, it is assumed that the secure core 300 detects the issuance of a specific CPU instruction (S61). Specifically, the CPU instruction detection means 311 determines that a specific CPU instruction has been detected. The specific CPU instructions are exemplified by privileged instructions issued from the kernel of ring:0, such as a MOV instruction (copy instruction) for CR0, CR3, and CR4, and a WRMSR (write instruction) and RDMSR (read instruction) for MSR101. In addition to or instead of the specific CPU instructions, other CPU instructions (including syscall instructions) may be applied to the monitoring target. In response to the detection of the specific CPU instruction, the specific CPU instruction is hooked (S62) and the system transitions to root mode (S63). This causes control to be transferred to the secure core 300 .

[0097] Next, a correct / incorrect determination is made (S64). For example, if a specific CPU instruction is issued by the kernel, it is judged to be valid, and if it is issued by something other than the kernel, it is judged to be invalid. If the validity is determined to be valid, control is returned to the kernel, and processing related to the specific CPU instruction is executed. If the result of the validity check is invalid, invalidation processing is executed, that is, invalidation means 312 is executed. Disabling means, for example, ignoring a privileged instruction so that processing related to the privileged instruction is not executed. In this way, privileged instructions issued by the kernel in ring:0 cannot be monitored by programs in ring:0, so the secure core 300 in ring:-1 uses a specific device 900 located between the CPU 10 and memory 30 to monitor and determine whether the instructions are correct or not (invalidating them if necessary).

[0098] This makes it possible to prevent unauthorized operations such as transferring processing to attack code or changing the access range to memory 30. Furthermore, the specific device 900, due to its placement, can detect all CPU instructions that are the basis of all processing without omission, and by enabling it before the OS 31 starts up, it is simultaneously virtualized, allowing the secure core 300 to monitor and determine whether it is correct or not at an early stage in ring:-1 (root mode). This makes it possible to comprehensively and quickly monitor and determine whether any unauthorized behavior is legitimate or not.

[0099] Issuing an EPT violation can also be used to protect the secure core 300 . Specifically, as described above (S33 in Figure 11, etc.), the write permission based on the EPT function is disabled for the memory area of ​​the secure core 300, so an EPT violation is issued if there is a write to the storage area. When an EPT violation is issued, control is transferred to the secure core 300, and the secure core 300 executes processing to invalidate writing, that is, it ignores the write command to the secure core area. This makes it possible to protect the memory area of ​​the secure core 300. When the invalidation process is complete, a VMRESUME command is issued to return to non-root mode.

[0100] (Monitoring Syscall commands - determining whether they are correct or not) FIG. 16 is a flowchart showing the process of monitoring a syscall command and determining whether it is correct or not. Monitoring of syscall instructions can be performed while in non-root mode. Specifically, during non-root mode after the "syscall handler setup" (Figure 13) that is executed during OS initialization (step A2 in Figure 8) is completed, the system is in a state where it is possible to monitor syscall commands and determine whether they are correct or not (syscall command monitoring state).

[0101] As shown in FIG. 16, during syscall command monitoring, in response to the issuance of a syscall command (S71), control is passed to the syscall handler 340 (S72). That is, the address of the processing transfer destination SSD that was to be written to MSR101 (MSR_IA32_LSTAR) is changed in advance to the memory address of the syscall handler 340 (S46 in Figure 13), so that control is quickly handed over to the syscall handler 340 by jumping to the memory address written to MSR_IA32_LSTAR. In this way, control is passed to the syscall handler 340 when a syscall command is issued from the APP 34. At the stage when control is passed, it is already determined that the command is a syscall command, so the handler itself does not have the function of "detecting a syscall command," which also enables high-speed processing. In other words, the control means (the control means in the "normal syscall execution method" shown in the left diagram of Figure 12) causes the processor 10 to execute processing by the syscall handler 340 (first software) loaded at the address written by the address change writing means 323.

[0102] Next, the syscall handler 340 identifies the process that is currently being processed based on the syscall command (S73(1)). Next, the syscall handler 340 stores information (a flag) indicating whether the APP handler 350 has been loaded or not inside the KPROCESS 44 corresponding to the identified process 35 (S73(2)).

[0103] Here, the syscall command is a command issued from the APP 34 to the OS 31 (kernel), and this syscall command is issued between the time the APP 34 is started and the time it becomes executable. When APP34 is launched, the loading (generation) of the executable file of APP34 begins within process 35, and this generation is specifically performed under the leadership of a shared library (NTDLL.DLL354) that resides within process 35 (see Figure 17). Since the generation of this APP34 executable file involves kernel-level processing, a syscall command is issued from each NTDLL.DLL354 contained in each process to request the kernel to perform the processing during the process from the time of generation to completion of process 35 (the process until APP34 becomes executable). For this reason, the syscall handler 340 can identify the process 35 being processed based on the syscall command issued from the NTDLL.DLL 354 .

[0104] FIG. 17 is a diagram showing the process management data structure. Referring to FIG. 17, a method for identifying a KPROCESS 44 based on a syscall instruction and identifying the corresponding process 35 will be described. When a syscall command is issued, control is transferred to the kernel, and at this time, the start address of KPCR 41 is stored in GS 103 as shown in FIG. Furthermore, based on the starting address of KPCR 41, KPRCB 42 can be identified from its offset, and the address of the currently processed thread (KTHREAD 43) can be obtained from that KPRCB 42 and offset, and further, the address of the process (KPROCESS 44) can be obtained from the offset within that KTHREAD 43. Therefore, each time a syscall command is issued from APP34 (NTDLL.DLL354), the syscall handler 340 can identify the process 35 currently being processed by tracing the address of the data structure along the path GS103 → KPCR41 → KPRCB42 → KTHREAD43 → KPROCESS44 based on the syscall command.

[0105] In this way, the syscall handler 340 can identify the process 35 that is currently being processed, thereby managing the load state of the APP handler 350 for each process 35 . Specifically, each process 35 stores information indicating the load status of the APP handler 350 inside KPROCESS44, which is a process management data structure, and the syscall handler 340 refers to that information and can load it into the process being processed if it is not already loaded, or can avoid redundant loading if it is already loaded.

[0106] Furthermore, the syscall handler 340 can identify the process 35 currently being processed, thereby coordinating the parallel management of the processes 35 by the OS 31 with the syscall processing. The OS 31 manages multiple processes 35 using a process management data structure, and the syscall handler 340 can identify the process 35 (KPROCESS 44) that issued the syscall command by tracing the address of the currently processing thread (KTHREAD 43) from KPCR 41 and KPRCB 42. This mechanism makes it possible to accurately determine which process 35 a syscall command issued from multiple processes 35 running simultaneously in parallel originates, and to process the command based on the data and status associated with that process 35.

[0107] The syscall handler 340 determines the load state of the APP handler 350 (S74). Specifically, the syscall handler 340 refers to the information in the KPROCESS 44 corresponding to the process 35 currently being processed, and determines whether the APP handler 350 has already been loaded (S75). If the APP handler 350 has not been loaded (S75: No), the APP handler 350 is loaded into the process 35 (S76). If the APP handler 350 is already loaded (S75: Yes), the syscall handler 340 passes control to the APP handler 350 (S77).

[0108] The APP handler 350 is loaded in the following manner. Specifically, the syscall handler 340 replaces the syscall command issued from the APP 34 (NTDLL.DLL 354) with an API for memory allocation and passes control to the kernel. As a result, the kernel reserves a memory area for the APP handler 350 , notifies the syscall handler 340 of the reserved memory address, and returns control to the syscall handler 340 . The syscall handler 340 notifies the secure core 300 of the memory address allocated from the kernel. The secure core 300 loads the APP handler 350 into the memory address notified by the syscall handler 340 .

[0109] Incidentally, a process 35 in which the APP handler 350 has not been loaded is in the stage of examining the program structure using its internal NTDLL.DLL 354 and creating an environment in which the executable file (.exe) can be executed, so the APP handler 350 can be loaded before the executable file is executed. This allows the syscall handler 340 to immediately transfer control to the APP handler 350 based on the stored memory address the next time a syscall command is issued. The memory address of the APP handler 350 is held in the KPROCESS 44 . As a result, the next time a syscall instruction is issued, the syscall handler 340 can immediately transfer control to the APP handler 350 by jumping to that memory address.

[0110] Then, the APP handler 350 executes a determination as to whether the syscall command is valid or invalid (S78). Specifically, the APP handler 350 refers to an information storage unit (not shown) that stores in advance information on highly invalid candidates among the API codes that constitute the syscall command, and performs a judgment of validity by, for example, comparison. If the validity is determined to be valid, control is transferred to the SSD of the OS 31, which executes normal system call processing. If the command is found to be invalid, the program returns to the next command following this command, or APP34 is terminated. Examples of highly inappropriate candidates include (a) currently unused or undisclosed APIs, (b) reading and writing to files under C:\Windows or C:\ProgramFiles, and (c) control of permissions granted by the kernel (for example, requests to elevate from user privileges to administrator privileges). Including these, for example, if the API code related to the syscall command is an unused or undisclosed API, it is judged to be unauthorized, and otherwise it is judged to be authorized; if the issuer of the API code is authorized (for example, a process for the OS), it is judged to be authorized, and otherwise it is judged to be unauthorized; if the authority is authorized, it is judged to be authorized, and otherwise it is judged to be unauthorized.

[0111] Also, the above-mentioned correctness determination based on the program size of APP34 is executed. That is, the first identification means 351 may identify the program size of APP34 before it is loaded into memory 30, the second identification means 352 may identify the program size of APP34 after it is loaded into memory 30, and the correct / incorrect judgment means 353 may perform a correct / incorrect judgment on APP34 based on the program size identified by the first identification means 351 and the program size identified by the second identification means 352. In this way, the syscall instruction monitoring and the validity determination are performed by the cooperation of the syscall handler 340 and the APP handler 350, and the validity determination is actually performed by the APP handler 350.

[0112] In addition, execution rules can be applied to programs running on OS31. For example, various execution rules can be applied, such as allowing only programs permitted by the user of the information processing device 1 to be executed, or allowing only programs whose permission information has been authenticated to be executed.

[0113] The syscall handler 340 may determine whether the syscall instruction is valid or invalid. However, in this case, since there is only one syscall handler 340, processing becomes concentrated and the load increases. Therefore, in the present invention, an APP handler 350 is provided for each APP 34 (each process 35), and the APP 34 (process 35) itself determines whether a syscall command issued from its own APP 34 (process 35) is correct or not. This distributes the processing, enabling smooth processing with low load.

[0114] (The R0 handler 360 monitors the call instruction and determines whether it is correct or not.) Next, the flow from monitoring a call command to determining whether it is correct or not will be described. FIG. 18 is a flowchart showing the process of monitoring a call command and determining whether it is correct or not. Monitoring of call instructions can be performed by the R0 handler 360 during non-route mode. Specifically, during non-route mode after the completion of "R0 handler setup" (Figure 14) executed during OS initialization processing (step A2 in Figure 8), the system is in a state where call instructions can be monitored and their success or failure can be determined (call instruction monitoring state).

[0115] 18, it is assumed that the issuance of a specific call instruction is detected during call instruction monitoring (S81). That is, it is assumed that the call instruction detection means 361 detects a specific call instruction. "Specific call instructions" does not mean all call instructions, but rather a selected portion of call instructions. However, it is also possible to monitor all call instructions. If a specific call instruction is detected, the call instruction is hooked (S82) and control is passed to the R0 handler 360 (S83). Specifically, the INT3 instruction (breakpoint) is set in advance at the starting address of the kernel-side API (processing function) corresponding to the call instruction, and the address of #BP in the INT table is rewritten to the memory address of the R0 handler 360, so that when a call instruction is issued, control is transferred to the R0 handler 360 by an interrupt (Figure 14).

[0116] Then, the R0 handler 360 executes a determination of the correctness of the specific call instruction using the correctness determination means 362 (S84). Specifically, the R0 handler 360 refers to a reference storage unit (not shown) that pre-stores highly invalid candidates from among the API codes that make up the call command, and performs a validity determination by, for example, matching. In addition to (a) to (c) in determining whether a syscall command is valid, candidates for high invalidity include, for example, when the issuing driver is a file sharing driver (an invalid condition) and when the call command is a write to the registry (an invalid condition). For example, if the API code related to the call command is an unused or undisclosed API, it is judged to be invalid, and if not, it is judged to be valid; if the issuer of the API code is valid, it is judged to be valid, and if not, it is judged to be invalid.

[0117] FIG. 19 is a flowchart showing the process after determining whether a syscall command and a call command are correct or not. As shown in FIG. 19, the process branches based on the result of the determination of whether the syscall command and the call command are correct or not. If it is determined to be valid (S91: Yes), control is transferred to the kernel (S92). If it is determined to be invalid (S91: No), the program returns to the next command following this command, or ends the program (S93).

[0118] In this way, in the information processing device 1 etc. of the present invention, the operation of the CPU 10 is virtualized by a specific device 900 placed between the CPU 10 and the memory 30, and the specific device 900 transfers processing to the secure core 300 before the CPU 10 fetches a CPU instruction from the memory 30. The secure core 300 monitors instructions issued by the OS (kernel) 31, loads the syscall handler 340 into the memory 30, stores the memory address of the syscall handler 340 loaded into the memory 30, and replaces the memory address that the kernel 31 attempts to write to when issuing a write command to a register that holds the processing transfer destination address of the syscall instruction with the memory address of the syscall handler 340. As a result, the processing destination of a syscall command issued from an APP that is executed later will be transferred to the syscall handler 340, and all processing requests from the APP to the kernel 31 can be monitored.

[0119] The secure core 300 manages its own memory area that is not under the control of the OS 31. This differs from conventional security software that operates in accordance with the OS 31, and operates independently of the OS 31. This makes it possible to provide security functions without being affected even if OS31 is compromised. In other words, unlike conventional technologies that can only operate in accordance with existing OSes, this invention essentially stops all operations other than those permitted, making it possible to detect and prevent not only known fraud but also unknown fraud.

[0120] Furthermore, before the APP is loaded into the memory 30 by the OS 31 and becomes executable, the syscall handler 340 loads the APP handler 350 into the memory space of the APP. The APP handler 350 cooperates with the syscall handler 340 to determine the content of the syscall command, and if it is determined to be invalid, it invalidates the syscall command or terminates the APP. If an instruction that changes the operation of the CPU 10 or an instruction that changes a register of the CPU 10 registered by the kernel 31 is issued among the instructions issued by the kernel 31, the operation of the OS 31 is maintained by invalidating this instruction.

[0121] The CPU 10 also has a function for setting an authority level (privilege level) for the memory 30, which prohibits access to or execution of the memory space of the kernel 31, driver, and syscall handler 340 from the memory space of the APP. When the specific device 900 is enabled, a higher authority level is set for the memory space of the secure core 300 than for the memory space of the kernel 31, and access to or execution from the kernel 31 or drivers is not possible. Therefore, the system including the secure core 300 and the monitoring software of the present invention can be prevented from being tampered with or stopped.

[0122] Furthermore, for example, unauthorized rewriting of MSR101 (MSR_IA32_LSTAR) is possible in ring:0 (kernel mode), but even if monitoring software that runs in ring:0 is applied, such unauthorized behavior cannot be continuously detected. According to the present invention, since the monitoring state can be continued in the virtual environment using the virtual support mechanism (that is, the secure core 300 with the authority of ring:-1 is provided), such fraudulent acts can be continuously detected.

[0123] In addition, when determining whether a CPU instruction that has been invalidated by the invalidation means for a specific CPU instruction, or a syscall instruction or call instruction, is valid or invalid, special instructions can be exceptionally deemed valid and processing can be continued. For example, by referring to the history of CPU instructions, syscall instructions, and call instructions (including the processing content related to the instructions (such as the request source)) stored in the log memory unit 60, it is possible to prevent invalidation or negative judgment from being made for specified instructions. Furthermore, if the user determines that the command that has been stopped or invalidated as a result of the validity determination is necessary, it can be permitted later.

[0124] As described above, the information processing device of the present invention includes a control means for executing the processing of the processing transfer destination SSD (software) stored at the address written to MSR_IA32_LSTAR (specific register) based on the address written to the address, and includes a first load means 321 for loading a syscall handler 340 (first software) capable of monitoring system call instructions into memory, and an address modification / write means 323 for modifying the address written to the specific register to the address of the syscall handler 340 (first software) loaded by the first load means 321 and writing the address to the specific register in response to the issuance of a CPU instruction (WRMSR) commanding a write to the specific register, and the control means executes the processing of the syscall handler 340 (first software) loaded at the address written by the address modification / write means 323 instead of the processing of the SSD (software). (1) As a result, when a syscall command is issued, control is immediately passed directly to the syscall handler 340, resulting in a short path and high-speed processing.

[0125] Furthermore, the information processing device 1 of the present invention includes an APP loading means 301 that loads an APP 34 into a process 35 in memory 30 in response to activation of the APP 34, a second loading means 322 that loads an APP handler 350 (second software) different from the first software into memory, a load control means 344 that loads the APP handler 350 (second software) into each process 35 corresponding to one or more APPs 34, and a correct / incorrect determination means 353 that causes the APP handler 350 (second software) loaded into the process 35 to determine whether a system call command issued from the process 35 is correct or incorrect. (2) This allows the APP handler 350 set as the issuer to process the success or failure of each syscall command, thereby distributing the load.

[0126] The information processing device 1 of the present invention also includes a process identification means 341 that identifies a process 35 currently in progress based on a system call command issued from each process 35, and a load control means 344 loads an APP handler 350 (second software) into the process 35 currently in progress identified by the process identification means 341 among the processes 35 corresponding to one or more APPs 34. (3) This allows the APP handler 350 to be loaded before the APP 34 is ready to run. This allows for thorough monitoring and inspection of all syscall commands.

[0127] The information processing device 1 of the present invention also includes a load state information storage means 342 that stores identification information indicating the load state of the APP handler 350 (second software) within a process 35 in a management structure (KPROCESS44) corresponding to the process 35, and a load state determination means 343 that determines, in response to the issuance of a system call command, for each process 35 based on the identification information, whether the APP handler 350 (second software) is already loaded. The load control means 344 loads the APP handler 350 (second software) into a process 35 for which the load state determination means 343 determines that the APP handler 350 (second software) is not already loaded. (4) This makes it possible to efficiently load the APP handler 350 for multiple processes 35 .

[0128] In contrast, conventional technologies had problems such as the path required for control to be passed to the monitoring software's processing being long, making it impossible to achieve high-speed processing, and the load being concentrated because processing was done by a single monitoring software. According to the present invention, these problems can be solved by the above configurations (1) to (4). In contrast to the problems associated with the prior art document mentioned at the beginning, the present invention eliminates the need to customize the OS, and there is no risk of the versatility and reliability of the OS being impaired by customization. Furthermore, the storage area of ​​the secure core 300 is registered (managed) as an MMIO area that is invisible to the OS 31 and writing authority is restricted, so there is little possibility of tampering. Furthermore, the system consisting of the monitoring software is configured independently of OS31 and can operate before OS31 starts up, so that it can detect fraud in addition to operations that comply with the functions of OS31. This makes it possible to detect not only known fraud but also unknown fraud. That is, according to the present invention, the problems associated with the prior art can be solved.

[0129] Although the preferred embodiments of the present invention have been described above, it goes without saying that the present invention is not limited to the above-described embodiments, and various modifications can be made within the scope of the present invention. For example, the security system described above has the functions of command monitoring, detection, validity determination, and invalidation processing, but the present invention is not limited to this. It may also be configured to determine the presence or absence of bugs or performance. In this case, software for finding bugs or software for determining performance can be applied instead of monitoring software. Furthermore, although a virtualization support mechanism is used as the specific device 900, a virtualization support mechanism need not be used. For example, a device or function other than the virtualization support mechanism may be used that is capable of inputting and outputting CPU instructions between the CPU 10 and the memory 30. Furthermore, the CPU instructions input / output from either the CPU 10 or the memory 30 may be replaced with a detectable device or function.

[0130] Moreover, the targets of the correctness determination by the secure core 300 may be all or some of the CPU instructions. The target CPU instruction may be determined by referring to past log information stored in the log storage unit 60. For example, a specific CPU instruction may be selected or determined based on specific conditions such as the total number of invalid judgment results, the rate at which invalid results occur, the total number of combinations of CPU instructions and issuers that result in invalid results, or the rate at which invalid results occur. Also, the APP handler 350 can be provided inside the syscall handler 340 rather than in the secure core 300 . In this case, the syscall handler 340 can load the APP handler 350 without cooperating with the secure core 300 .

[0131] The syscall handler 340 does not detect the syscall command itself, but can determine what type of request the syscall command is, for example, by the API number present on the OS 31 side. For example, the type of specific content that the APP 34 requests the OS 31 to, such as memory allocation, file read / write, or a shutdown request for the OS 31, is identified. In particular, requests related to the operation of the entire OS 31 (for example, shutdown) can be determined on the syscall handler 340 side and the information can be transmitted to the secure core 300 . Other general syscall instructions may be passed to the APP handler 350 for determination within each individual process 35 .

[0132] In addition, in this invention, an example has been described in which a hardware virtualization support mechanism placed between CPU 10 and memory 30 is used to monitor instructions passing between CPU 10 and memory 30, but this mechanism can also be realized by providing a new separate device rather than using an existing one. This makes it possible to apply the present invention to IoT devices and automobiles (devices that do not have a virtualization support mechanism implemented). In other words, by implementing a virtualization support mechanism between the CPU and memory in these devices, it can be made to function effectively as a protective measure against cyber attacks, etc. [Explanation of symbols]

[0133] 1: Information processing device, 10: CPU (processor), 11: Chipset, 20: Flash ROM, 21: UEFI / BIOS, 30: Memory (RAM), 300: Secure core, 31: OS (kernel), 301: APP loading means, 310: Monitoring unit, 311: CPU instruction detection means, 312: Disabling means, 313: Authority setting means, 320: Collaboration unit, 321: First loading means, 322: Second loading means, 323: Address change writing means, 34: APP (application program), 340: Syscall handler, 341: Process identification means, 342: Load status information storage means, 343: Load status determination means, 344: Load control means, 35: Process, 350: APP handler, 351 : First identification means, 352: Second identification means, 353: Correct / incorrect determination means, 354: NTDLL.DLL, 36: Driver, 360: R0 handler, 361: Call instruction detection means, 362: Correct / incorrect determination means, 390: Software package, 40: Input unit, 41: KPCR, 42: KPRCB, 43: KTHREAD, 44: KPROCESS, 50: Output unit, 60: Log storage unit, 90: Hard disk drive (HDD), 91: OS boot loader (OS startup means), 93: Specific boot loader, 931: Load means, 932: Validation means, 933: Startup control means, 934: Area management means, 100: Register group, 101: MSR, 102: CR, 103: GS, 104: RIP, 900: Specific device

Claims

1. 1. An information processing device having a control means for executing a process of software stored in a specific register based on the address written in the specific register, a first loading means for loading a first software program capable of monitoring a system call instruction into a memory; an address modification writing means for modifying the address to be written in the specific register to an address of the first software loaded by the first loading means in response to issuance of a CPU instruction to instruct writing to the specific register, and writing the modified address to the specific register; The control means Instead of the processing of the software, the processing of the first software loaded at the address written by the address change writing means is executed.

1. An information processing device comprising:

2. An information processing apparatus having an APP load means for loading an application program into a process in a memory in response to the start of the application program, second loading means for loading second software different from the first software into memory; a load control means for loading the second software into each process corresponding to one or more application programs; a correctness determination means for determining whether the second software loaded into the process is correct or not for determining whether a system call instruction issued from the process is correct or not.

2. The information processing apparatus according to claim 1, wherein:

3. a process identification means for identifying a process currently being processed based on a system call command issued from each process; The load control means The second software is loaded into a process currently being executed that is identified by the process identification means among the processes corresponding to one or more application programs.

3. The information processing apparatus according to claim 2, wherein:

4. a load status information storage means for storing identification information indicating a load status within a process of the second software in a management structure corresponding to the process; a load status determination means for determining, in response to the issuance of a system call command, whether the second software is already loaded for each process based on the identification information; The load control means The second software is loaded into a process in which it has been determined by the load state determination means that the second software has not been loaded.

4. The information processing apparatus according to claim 2, wherein the information processing apparatus is a computer.

5. a first specifying means for specifying a program size of an application program before it is loaded into memory; a second specifying means for specifying a program size of the application program after it has been loaded into the memory; The correct / incorrect determination means A validity determination is made for the application program based on the program size specified by the first specifying means and the program size specified by the second specifying means.

3. The information processing apparatus according to claim 2, wherein:

6. 1. An information processing method executed by a computer having a control means for executing processing of software stored in a specific register based on the address written in the specific register, comprising: a first loading step of loading first software capable of monitoring a system call instruction into a memory; an address modification write step of modifying the address to be written to the specific register to the address of the first software loaded in the first loading step in response to issuance of a CPU instruction to write to the specific register; and a step of causing the control means to execute processing of the first software loaded at the address written in the address change writing step instead of processing of the software.

1. An information processing method comprising:

7. A computer having a control means for executing the processing of software stored in a specific register based on the address written in the specific register, a first loading means for loading into a memory a first software capable of monitoring a system call instruction; and functioning as an address modification / writing means for modifying the address to be written into the specific register to the address of the first software loaded by the first loading means in response to issuance of a CPU instruction for instructing writing into the specific register, and writing the address into the specific register; The control means Instead of the processing of the software, the processing of the first software loaded at the address written by the address change writing means is executed. A program characterized by:

Images