CN115774651A

CN115774651A - Safety monitoring method, device, equipment and chip based on microkernel operating system

Info

Publication number: CN115774651A
Application number: CN202310093203.9A
Authority: CN
Inventors: 赵东艳; 王慧; 王喆; 曾林; 李德建; 顿中强
Original assignee: Beijing Smartchip Microelectronics Technology Co Ltd
Current assignee: Beijing Smartchip Microelectronics Technology Co Ltd
Priority date: 2023-02-10
Filing date: 2023-02-10
Publication date: 2023-03-10
Anticipated expiration: 2043-02-10
Also published as: CN115774651B; WO2024164630A1

Abstract

The embodiment of the disclosure discloses a security monitoring method, a device, equipment and a chip based on a microkernel operating system, wherein the method comprises the following steps: responding to a calling request of an execution object of a user space to a system calling interface in the microkernel operating system, and matching a system calling event type corresponding to the calling request with pre-configured audit configuration information in the kernel space; when the type of the system calling event is matched with the audit configuration information, recording the entry audit information of the system calling interface when entering the kernel space for operation in the audit context structure of the execution object, and recording the exit audit information of the system calling interface when exiting in the audit context structure of the execution object; and when the system call interface is exited, the entry audit information and the exit audit information in the audit context structure are output to the audit buffer area of the user space from the kernel space. The technical scheme can carry out security monitoring on the operating system on the premise of simplifying the kernel as far as possible.

Description

Safety monitoring method, device, equipment and chip based on microkernel operating system

Technical Field

The present disclosure relates to the field of chip technologies, and in particular, to a security monitoring method, device, equipment, and chip based on a microkernel operating system.

Background

Audit is an analysis technology for confirming that a security rule is violated afterwards, and the security audit provides timely warning information for an administrator when a user violates the security rule, so that functions of tracking, examining, counting, reporting and the like of system information are realized. Currently, some open source operating systems have implemented audit functions.

Linux provides an auditing system for recording system security events, the auditing system comprises a user space auditing system and a kernel space auditing system, the user space auditing system comprises auditing programs of some user spaces, and is used for starting kernel auditing functions, setting auditing rules and auditing system states, receiving auditing messages sent by the kernel auditing system, writing log files, retrieving the auditing messages and generating auditing summary reports. The kernel auditing system is used for generating and filtering various auditing messages of the kernel.

The security audit system of Linux is divided into two parts of syslog and audio. The audio part is mainly used for recording security information including reading and writing of files, modification of authority and the like, and the syslog part is mainly used for recording various information in the system, such as hardware alarms, software logs and the like. The log data mainly comprises three types: kernel and system logs, user logs, program logs.

The syslog belongs to a service of an application layer and is specially used for recording logs, each program can be understood as a subsystem, and the syslog can store the logs in different files according to the categories and the priorities of the logs. In addition, the syslog has two processes, the syslog is specially used for recording logs generated by other settings of the non-kernel, and the klogd is specially used for the logs generated by the kernel, and the information is read out through a system call syslog and is recorded in a log file.

In addition to Linux, there is the SNARE (System intrust and Reporting Environment) auditing System, which is an open source security audit and event logging software. The SNARE system is mainly divided into three modules: kernel dynamic loading module audiomodule.o; an audit monitoring program audiotd running in a user space; configuration of the graphical cross-section and reporting tool snare. The system separates the audit from the kernel to form a module independent of the kernel. The method comprises the steps of rewriting the system call to be audited, realizing the collection of audit information in the new system call, putting the audit record into a buffer pool, and after loading a module, enabling the new system call with the audit function to replace the original system call by pointing a function pointer in a system call table to a new system call function.

In addition, the WINDOWS NT auditing system is able to detect and record any security-related events that create, access or delete system resources, and record users that implement these activities. In the auditing process, the object manager can generate an auditing event according to the auditing strategy, which is a passive process, and can also actively generate the auditing event by using an auditing function in a user program.

The Linux operating system is used as a macro-kernel architecture, main kernel components of the system are all realized in kernels, and partial modules of the security audit system are also realized in the kernels, so that the design concept is different from that of a micro-kernel operating system aimed at by the invention, and the design is not beneficial to modular design.

The SNARE system has fewer audit events and is not comprehensive enough, meanwhile, a mode of separating the audit system by adopting system call is established on the basis of a system call table, and the mode is not feasible when the kernel module can not refer to the system call table any more.

Therefore, for the microkernel operating system, a security audit monitoring system needs to be designed on a user layer, and the security and reliability of the operating system are maintained on the basis of ensuring the isolation.

Disclosure of Invention

The embodiment of the disclosure provides a security monitoring method, a security monitoring device, security monitoring equipment and a security monitoring chip based on a microkernel operating system.

In a first aspect, an embodiment of the present disclosure provides a security monitoring method based on a microkernel operating system, where the method includes:

responding to a calling request of an execution object of a user space to a system calling interface in a microkernel operating system, and matching a system calling event type corresponding to the calling request with pre-configured audit configuration information in a kernel space;

when the system calling event type is matched with the audit configuration information, recording the entry audit information of the system calling interface when entering the kernel space operation in the audit context structure of the execution object, and recording the exit audit information of the system calling interface when exiting in the audit context structure of the execution object;

and when the system calling interface is exited, the entry audit information and the exit audit information in the audit context structure are output to an audit buffer area of a user space from the kernel space.

Further, the method further comprises:

and when the system calling event type corresponding to the calling request is not matched with the audit configuration information, writing first kernel-state log information generated by the system calling interface in the kernel space execution process into a log buffer area of a user space.

Further, the method further comprises:

writing user mode log information generated by a user space into the log buffer area; and/or the presence of a gas in the gas,

writing second kernel-state log information generated by a kernel space into the log buffer; and the second kernel-state log information is log information generated by a non-system call interface in a kernel space.

Further, the method further comprises:

reading the log information in the log buffer area in a user space;

and calling a file system interface to output the log information in the log buffer area to a console or a log file.

Further, the method further comprises:

acquiring user space audit information generated by a user space;

matching the user space audit information with the audit configuration information;

and when the user space audit information is matched with the audit configuration information, writing the user space audit information into the audit buffer area.

Further, the method further comprises:

receiving user configuration information input by a user through a preset interface in a user space;

updating the audit configuration information stored in user space based on the user configuration information.

Further, the method further comprises:

receiving a viewing request of a user for a log file in a user space;

outputting the log file to a user based on the viewing request.

Further, the method further comprises:

reading audit information in the audit buffer area in a user space;

and calling a file system interface to output the audit information in the audit cache region to an audit file.

Further, the method further comprises:

receiving a viewing request of a user for the audit file in a user space;

and outputting an audit report to a user based on the audit information in the audit file.

Further, the method further comprises:

setting an audit buffer linked list in a user space; the audit buffer linked list is used for storing a pointer pointing to the audit buffer;

calling a file system interface to output the audit information in the audit cache area to an audit file, wherein the audit information comprises the following steps:

after the number of pointers in the audit buffer linked list exceeds a preset threshold value, a file system interface is called to output audit information in the audit buffer to the audit file based on the pointers in the audit buffer linked list in a user space;

and deleting the corresponding pointer in the audit buffer linked list.

Further, the method further comprises:

establishing an idle audit buffer area;

storing a pointer pointing to the idle audit buffer area in an idle audit buffer area linked list;

when the system call interface is exited, the entry audit information and the exit audit information in the audit context structure are output to an audit buffer area of a user space from the kernel space, and the audit buffer area comprises:

requesting an idle audit buffer area from the idle audit buffer area linked list;

and writing the audit information in the audit context structure into the idle audit buffer area.

Further, the method further comprises:

when the idle audit buffer chain table does not have an idle audit buffer, the audit buffer is redistributed;

and writing the audit information in the audit context structure into the redistributed audit buffer area.

Further, the method further comprises:

after the content in the audit file exceeds the preset storage capacity, establishing a new audit file;

and deleting one or more audit files established at first according to the time sequence after the number of the audit files exceeds the preset number.

In a second aspect, an embodiment of the present disclosure provides a security monitoring apparatus based on a microkernel operating system, where the security monitoring apparatus includes:

the response module is configured to respond to a call request of an execution object of a user space to a system call interface in the microkernel operating system, and match a system call event type corresponding to the call request with pre-configured audit configuration information in the kernel space;

the recording module is configured to record entry audit information of the system call interface when the system call event type is matched with the audit configuration information in an audit context structure of the execution object when the system call interface enters a kernel space for operation, and record exit audit information of the system call interface when the system call interface exits in the audit context structure of the execution object;

a first output module configured to output entry audit information and exit audit information in the audit context structure from the kernel space to an audit buffer of a user space upon exiting the system call interface.

Further, the apparatus further comprises:

and the first writing module is configured to write first kernel-state log information generated by the system calling interface in a kernel space execution process into a log buffer of a user space when the system calling event type corresponding to the calling request is not matched with the audit configuration information.

Further, the apparatus further comprises:

a second writing module configured to write user-mode log information generated by a user space into the log buffer; and/or the presence of a gas in the gas,

a third writing module configured to write second kernel-state log information generated by a kernel space into the log buffer; and the second kernel-state log information is log information generated by a non-system call interface in a kernel space.

Further, the apparatus further comprises:

a first reading module configured to read the log information in the log buffer in a user space;

the first calling module is configured to call a file system interface to output the log information in the log buffer to a console or a log file.

Further, the apparatus further comprises:

the acquisition module is configured to acquire user space audit information generated by a user space;

a matching module configured to match the user space audit information with the audit configuration information;

a fourth write module configured to write the user space audit information into the audit buffer when the user space audit information matches the audit configuration information.

Further, the apparatus further comprises:

the first receiving module is configured to receive user configuration information input by a user through a preset interface in a user space;

an update module configured to update the audit configuration information stored in user space based on the user configuration information.

Further, the apparatus further comprises:

the second receiving module is configured to receive a viewing request of a user for the log file in the user space;

a second output module configured to output the log file to a user based on the viewing request.

Further, the apparatus further comprises:

a second reading module configured to read audit information in the audit buffer in user space;

and the second calling module is configured to call a file system interface to output the audit information in the audit cache region to an audit file.

Further, the apparatus further comprises:

a third receiving module configured to receive a viewing request of a user for the audit file in a user space;

a third output module configured to output an audit report to a user based on audit information in the audit file.

Further, the apparatus further comprises:

the setting module is configured to set an audit buffer linked list in a user space; the audit buffer linked list is used for storing a pointer pointing to the audit buffer;

the second calling module comprises:

the calling sub-module is configured to call a file system interface to output the audit information in the audit buffer area to the audit file based on the pointer in the audit buffer area linked list in a user space after the number of the pointers in the audit buffer area linked list exceeds a preset threshold value;

and the deleting submodule is configured to delete the corresponding pointer in the audit buffer linked list.

Further, the apparatus further comprises:

a first establishing module configured to establish a free audit buffer;

a storage module configured to store a pointer to the idle audit buffer in an idle audit buffer linked list;

the first output module includes:

a request submodule configured to request an idle audit buffer from the idle audit buffer linked list;

a write-in submodule configured to write audit information in the audit context structure into the idle audit buffer.

Further, the apparatus further comprises:

the allocation module is configured to reallocate the audit buffer when the idle audit buffer list does not have an idle audit buffer;

a fifth writing module configured to write audit information in the audit context structure into the reallocated audit buffer.

Further, the apparatus further comprises:

the second establishing module is configured to establish a new audit file after the content in the audit file exceeds a preset storage capacity;

and the deleting module is configured to delete one or more audit files established firstly according to the time sequence after the number of the audit files exceeds the preset number.

The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

In one possible design, the apparatus includes a memory configured to store one or more computer instructions that enable the apparatus to perform the corresponding method, and a processor configured to execute the computer instructions stored in the memory. The apparatus may also include a communication interface for the apparatus to communicate with other devices or a communication network.

In a third aspect, the disclosed embodiments provide an electronic device, comprising a memory, a processor, and a computer program stored on the memory, wherein the processor executes the computer program to implement the method of any one of the above aspects.

In a fourth aspect, the disclosed embodiments provide a computer-readable storage medium for storing computer instructions for use by any one of the above apparatuses, the computer instructions, when executed by a processor, being configured to implement the method of any one of the above aspects.

In a fifth aspect, the disclosed embodiments provide a computer program product comprising computer instructions that, when executed by a processor, implement the method of any one of the above aspects.

In a sixth aspect, the disclosed embodiments provide a chip for executing instructions to implement the method of any one of the above aspects.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects:

the embodiment of the disclosure designs and realizes a security monitoring scheme based on a microkernel operating system, and guarantees the security of the operating system by recording and analyzing the runtime information of the operating system. In the prior art, few security audit schemes are designed and perfected for microkernel operating systems, but the embodiment of the disclosure designs and realizes a security monitoring scheme based on microkernel operating systems, which meets the security standards of operating systems, and records the running state and information of the operating systems in real time by using the security monitoring scheme. According to the method and the device, the service of the configuration audit rule is provided in the user space, the authority user configures the event, format and the like needing to be audited according to the requirement, the kernel system only conditionally records the relevant event configured by the authority user in the running process, and the operating system is safely monitored on the premise of simplifying the kernel as far as possible.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

Other features, objects, and advantages of the present disclosure will become more apparent from the following detailed description of non-limiting embodiments when taken in conjunction with the accompanying drawings. In the drawings.

FIG. 1 shows a flow diagram of a microkernel operating system based security monitoring method according to an embodiment of the present disclosure.

Fig. 2 is a schematic diagram illustrating implementation effects of a log buffer and/or an audit buffer according to an embodiment of the present disclosure.

Fig. 3 (a) -3 (c) are schematic diagrams illustrating one implementation of a logging system and an auditing system included in a security monitoring system of a microkernel operating system according to an embodiment of the present disclosure.

Fig. 4 is a block diagram illustrating a security monitoring apparatus based on a microkernel operating system according to an embodiment of the present disclosure.

Fig. 5 shows a block diagram of an electronic device according to an embodiment of the present disclosure.

FIG. 6 is a schematic block diagram of a computer system suitable for implementing a microkernel operating system-based security monitoring method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement them. Also, for the sake of clarity, parts not relevant to the description of the exemplary embodiments are omitted in the drawings.

In the present disclosure, it is to be understood that terms such as "including" or "having," etc., are intended to indicate the presence of the disclosed features, numbers, steps, actions, components, parts, or combinations thereof, and do not preclude the possibility that one or more other features, numbers, steps, actions, components, parts, or combinations thereof are present or added.

It should be further noted that the embodiments and features of the embodiments in the present disclosure may be combined with each other without conflict. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

The details of the embodiments of the present disclosure are described in detail below with reference to specific embodiments.

FIG. 1 shows a flow diagram of a microkernel operating system based security monitoring method according to an embodiment of the present disclosure. As shown in fig. 1, the security monitoring method based on the microkernel operating system includes the following steps:

in step S101, in response to a call request from an execution object in a user space to a system call interface in a microkernel operating system, matching, in the kernel space, a system call event type corresponding to the call request with pre-configured audit configuration information;

in step S102, when the system call event type matches the audit configuration information, recording entry audit information when the system call interface enters kernel space to run in the audit context structure of the execution object, and recording exit audit information when the system call interface exits in the audit context structure of the execution object;

in step S103, when exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to an audit buffer area of a user space.

In this embodiment, the kernel part is simplified to the maximum extent for the microkernel operating system. The kernel part only comprises the most basic IPC (inter-process communication) mechanism, address space management and scheduling mechanism and the like for realizing the basic functions of the operating system service, and at the service level, the device driver, the file system, the inter-application program communication and the like are realized by means of a user-mode service program. When a common application program needs related services of an operating system, the common application program needs to initiate inter-process communication to corresponding service programs, the service programs carry out related operations, and the service programs can also be trapped into kernel-mode operation through a system call interface provided by an execution kernel if necessary so as to complete some basic operations, and the results are fed back to the application program through the inter-process communication.

In the embodiment of the disclosure, an application scenario is considered as a microkernel operating system, a security monitoring system is added to a microkernel operating system architecture, a kernel part is simplified as much as possible, and functions of the security monitoring system are implemented as a user space service program.

The security monitoring system in the embodiment of the disclosure at least comprises an auditing system. The auditing system is used for safety tracking, and the design of the auditing system aims to simplify the kernel as far as possible to the maximum extent, and related auditing service is designed in a user space.

The audit event is the minimum unit of the system for auditing the user action, and the collection of the audit event refers to the establishment of the audit event under a certain security level audit standard. From the perspective of a subject, the system needs to record all activities performed by the user, and from the perspective of an object, the system needs to record all access activities of an object.

The auditing event can be mainly divided into a system calling event and a user credible event, and the embodiment of the disclosure is designed aiming at the system calling event as follows:

the main body of the system call type event is a thread. A system call class event may be understood as a call event of an execution object of the user space, such as a thread, to a system call interface provided by the microkernel operating system. Therefore, in the embodiment of the present disclosure, after detecting a system call event, that is, after detecting a call request of an execution object of a user space to a system call interface, the security monitoring system may collect audit information by using the auditing system designed for the system call event according to the embodiment of the present disclosure, and output the audit information to a log file of the user space, so that a subsequent user with a related authority audits the use of the microkernel operating system based on the log file.

The embodiment of the disclosure can provide a management tool for configuring audit configuration information for a related authority user in a user space, the management tool can provide an audit information configuration interface or a command input interface, the related authority user can configure corresponding audit rules through the audit information configuration interface or a command input mode, and can also configure an output format of the audit information. Audit configuration information configured by the related authority user can be stored in a corresponding storage file so as to be read by the security monitoring system subsequently.

In the embodiment of the disclosure, the security monitoring system may be implemented by programming, and after the security monitoring system operates, the system call event may be detected by starting one or more detection threads in the user space. After detecting a system call event, the one or more detection threads in the security monitoring system may match the type of the system call event with a rule set in audit configuration information in a storage file, if the currently detected system call event is an event related to content to be audited and configured in advance by a user with a related authority, that is, when the type of the current system call event is matched with the pre-configured audit configuration information, write entry audit information when the currently called system call interface enters kernel mode operation into an audit context structure corresponding to the execution object, and write exit audit information when the execution of the system call interface is completed and exits into the audit context structure corresponding to the execution object.

The audit context structure can be well written in the source code of an execution object during programming, the execution object is established when being created after the safety monitoring system runs, and when a system calling interface exits, one or more information output threads started after the safety monitoring system runs output the corresponding entry audit information and the corresponding exit audit information in the context structure from the kernel space to the audit buffer area of the user space. The audit context structure may then be cleared.

In some embodiments, the audit context structure may be as follows:

struct audit_context{

the enum audio _ state, the status of audit

unique int serial number// serial number of record

struct timing ctime// time of system call entry

int major// System Call number

Signaled long argv [4 ]/system call parameter

Long return code// System Call Return code

int audio table, flag of whether it has been written into audit buffer area

}。

The entry audit information and the exit audit information can be determined based on an audit context structure, namely, which of the entry audit information and the exit audit information is respectively included in the audit context structure is predefined. As indicated by the audit context structure above, the entry audit information may include, but is not limited to, an audit status, a serial number, a system call entry time, a system call number, a system call parameter, etc. in the audit context structure; exit audit information may include, but is not limited to, system call return code and flags whether the contents of the audit context structure are output to an audit buffer, etc. In some embodiments, an audit buffer of the user space may be created at the time of initialization of the security monitoring system, and read and write operations are performed on the audit buffer by a read and write thread started at the time of initialization of the security monitoring system.

In an optional implementation manner of this embodiment, the method further includes the following steps:

In this optional implementation manner, if the system call event type corresponding to the currently called system call interface is not matched with the audit configuration information preferentially configured by the authorized user, it is indicated that the content related to the current system call is not the audit information concerned by the authorized user, so that the related audit information may not be generated. However, for subsequent viewing needs, the relevant log information may be written to a log buffer in user space. In some embodiments, a log output thread, which may be started by the security monitoring system after running, writes the relevant log information to a log buffer in user space.

That is to say, when the security monitoring system is initialized, an audit buffer and a log buffer may be established in a user space, and for a system call event in the microkernel operating system, if an authorized user does not pre-configure audit information related to the current system call event, the log output thread may also write first kernel-state log information related to the current system call event into the log buffer. It should be noted that, the related first kernel-state log information may include, but is not limited to, a start time and an end time of a system call type event, a modification operation on the microkernel operating system during running, and other related logs. A log output thread can be specially arranged in the microkernel operating system, and the related logs of the programs run by the kernel space can be specially written into a log buffer area of the user space.

writing second kernel-mode log information generated by a kernel space into the log buffer area; and the second kernel-state log information is log information generated by a non-system call interface in a kernel space.

In this optional implementation manner, the log buffer may further record user-mode log information generated by the user space, and the second kernel-mode log information generated by the kernel space may also be written into the log buffer. In this embodiment, in order to distinguish the log information generated by the system call event in the kernel space from the log information generated in other cases, the log information generated by the system call event is referred to as first kernel-state log information, and the log information generated in other cases is referred to as second kernel-state log information. In some embodiments, the first kernel-state log information may be written to the log buffer by a log output thread established at initialization of the security monitoring system. It is understood that the first kernel-state log information and the second kernel-state log information may be processed by the same log output thread or may be processed by different log output threads.

In some embodiments, the user-state log information of the user space may include, but is not limited to, an application software execution log executed in the user space, a modification record of the configuration information in the user space, and the like; the first kernel-state log information or the second kernel-state log information may include, but is not limited to, a running record of the microkernel operating system, an alarm prompt record in the microkernel operating system, an operation log record of the microkernel operating system by the user thread, a behavior record of the user thread in the microkernel operating system, and the like.

The first kernel-state log information and the second kernel-state log information generated by the kernel space can be output from the kernel space to a log buffer of the user space by a specially-arranged log output thread. The user space generated log information may be written into a log buffer of the user space by a corresponding log output thread. In some embodiments, the corresponding log output thread may be initiated after the security monitoring system is running.

reading the log information in the log buffer area in a user space;

In this optional implementation manner, the log information is recorded in a log buffer area established in the user space, the security monitoring system may start a log reading thread after running, and when the log buffer area is full or periodically, the log reading thread may write the log information in the log buffer area into the log file. The process of writing the log file can be carried out in a user space, and the log reading thread can write the log information into the log file from the log buffer area in the user space by calling a file system interface. In other embodiments, the log information in the log buffer may also be directly output to the console by the log reading thread by calling the file system interface, a storage device stored on the console, and/or a display displayed on the console for viewing by a relevant person.

acquiring user space audit information generated by a user space;

In the optional implementation manner, the user space may also generate information that the authorized user wants to audit, the authorized user may also pre-configure audit configuration information for the user space, configure the event type and/or the information type that wants to audit in the audit configuration information, after the user space generates the user space audit information, an audit matching thread started after the security monitoring system operates may be matched with the audit configuration information, if the audit matching thread is matched, the audit matching thread is written into the audit buffer, if the audit matching thread is not matched, the audit matching thread may not be written into the audit buffer, but the related log thread is written into the log buffer.

In this optional implementation, the authorized user may input user configuration information through an interface preset in the user space, and the user configuration information may be used to update audit configuration information stored in the user space in advance. By the method, the authorized user can pre-configure the audit configuration information in the user space and can also modify the audit configuration information and other editing operations in the follow-up process. After the safety monitoring system operates, an interface for a user to input user configuration information can be provided, and through the interface, the safety monitoring system can receive the user configuration information input by the user and update the received user configuration information into a storage file of the configuration information.

receiving a viewing request of a user for a log file in a user space;

outputting the log file to a user based on the viewing request.

In this optional implementation manner, the log file may be stored in a user space, a user may request to view the log file in the user space through a viewing interface provided by the security monitoring system, and after receiving a request from the user, the viewing interface may output the log file to the user by calling a file system interface, for example, the log file may be opened and displayed on a display device of the user.

reading audit information in the audit buffer area in a user space;

In the optional implementation mode, the audit information of the user space and the kernel space is recorded in the audit buffer area established by the user space, the safety monitoring system can start the audit reading thread after running, and the audit information in the audit buffer area can be written into the audit file by the audit reading thread when the audit buffer area is full or regular. The process of writing the audit file can be carried out in a user space, and the audit reading thread writes the audit information into the audit file from the audit buffer zone by calling a file system interface in the user space. In other embodiments, the audit information in the audit buffer can also be directly output to the console, a storage device stored on the console, and/or a display displayed on the console by the audit reading thread by calling a file system interface for viewing by related personnel.

receiving a viewing request of a user for the audit file in a user space;

In this optional implementation manner, after the audit information is written into the audit file, when the authority user views the audit file, the audit information may be generated into an audit report based on a preconfigured audit rule, and output to the authority user. The safety monitoring system can also provide a viewing interface for viewing the audit file for the user, and after the viewing interface receives the request of the user, the auditing system can output the audit report to the user under the condition that the current user is determined to have the authority.

and deleting the corresponding pointer in the audit buffer linked list.

In this optional implementation manner, an audit buffer chain table may be created in the user space during the initialization process of the security monitoring system, and a pointer pointing to the audit buffer is stored in the audit buffer chain table. That is, multiple audit buffers may be created in user space, and a pointer for each audit buffer may be stored in an audit buffer linked list. The maximum number of pointers of the audit buffer area which can be stored in the audit buffer area linked list can be preset, and the maximum number is represented by a preset threshold value. After the number of pointers in the audit buffer linked list exceeds the preset threshold value, a process of writing the audit information in the audit buffer into the audit file can be started, the process writes the audit information in the audit buffer pointed by the pointer stored in the audit buffer linked list into the audit file, and the pointer of the audit buffer where the audit information is successfully written into the audit file can be deleted from the audit buffer linked list.

In an optional implementation manner of the embodiment, the audit buffer and/or the log buffer of the user space adopt a double-buffer mode.

In this optional implementation manner, in order to reduce the number of system calls and thereby reduce the time consumed by switching the operating system between the user mode and the core mode, the embodiment of the present disclosure maintains an audit buffer and a log buffer in the user space, log information and audit information are written into the log buffer and the audit buffer according to a uniform format, and a log reading thread and an audit reading thread in the user space are respectively responsible for monitoring and reading information of the log buffer and the audit buffer, and are written into a log file and an audit file. In the kernel space, the log output thread writes the log information of the kernel into a log buffer area of the user space, and the audit output thread writes the audit information of the kernel state into an audit buffer area of the user space.

The buffer is mainly set to solve the problems of generation of log information or audit information and mismatching of reading rates, except for the problem of mismatching of rates, in the scenario of the embodiment of the present disclosure, the operations of reading the buffer and writing the buffer are often accompanied by a safety problem caused by a read-write thread. Therefore, the log buffer area and the audit buffer area of the user space are designed in a double-buffer mode in the embodiment of the disclosure.

The array is a one-dimensional continuous linear structure in physical storage, frequent memory application and release can be avoided by one-time allocation, and the access efficiency is high, so that the double buffers in the array form are adopted in the embodiment of the disclosure.

As shown in FIG. 2, the audit buffer is implemented as two buffers Buff _1 and Buff _2, buff _1is used for storing audit information in the current write thread, that is, the audit output thread, when the audit buffer Buff _1 is full, the swapping operation is triggered to swap the contents in the audit buffer Buff _1 to the audit buffer Buff _2, and then the read thread is audited by the read line Cheng Yeji to read data from the audit buffer Buff _2 and write the data into the audit file. Similarly, the journal buffer can also be implemented as two buffers, namely, buff _1 and Buff _2, buff _1is used for storing journal information in a current write thread, namely, a journal output thread, when the audit buffer Buff _1 is full, a swap operation is triggered to swap the content in the journal buffer Buff _1 into the journal buffer Buff _2, and then a read line Cheng Yeji reads data from the journal buffer Buff _2 and writes the data into a journal file.

In an optional implementation manner of this embodiment, in a double-buffer mode of the audit buffer, after the first audit buffer for currently writing audit information is full, addresses of the first audit buffer and the second audit buffer are exchanged, so that a buffer pointer for writing audit information of the kernel-state audit output thread is switched from the address of the first audit buffer in the user space to an address pointing to the second audit buffer, and a buffer pointer for reading audit information of the audit read thread points to the address of the first audit buffer.

In this optional implementation, when two audit buffers are exchanged, since the two audit buffers need to be locked respectively, the copy algorithm of the buffer contents will result in a long locking time, which affects the overall performance. Therefore, in the embodiment of the disclosure, when buffer exchange operation is performed, addresses of two audit buffers can be directly exchanged, a pointer pointing to the audit buffer Buff _1 of the audit output thread when write operation is performed points to the audit buffer Buff _2, a pointer pointing to the Buff _2 of the audit read thread when read operation is performed points to the Buff _1, and then subsequent read-write operation is performed, so as to achieve the purpose of exchanging buffers, at this time, only exchanging pointers are performed in the operation in the critical region, so that the execution speed is high. The design of the double-buffer area mode only needs to ensure that one buffer area can write data in and one buffer area can read data, so that when the kernel-state audit output thread writes in the buffer area, the kernel-state audit output thread cannot be blocked from being executed due to the low execution speed of the user state, and the kernel-state processing efficiency is further improved.

In the embodiment of the disclosure, a large buffer area is not required to be established, but a double buffer area in an array form is set, the buffer area used for read-write operation is separated and designed into two buffer areas, and thread blocking caused by long locking time of the same buffer area can be avoided. Meanwhile, the buffer area in the array form is allocated at one time, so that frequent memory allocation and release can be avoided. In an optional implementation manner of this embodiment, in a double buffering mode of a log buffer, after a first log buffer for currently writing log information is full, addresses of the first log buffer and a second log buffer are exchanged, so that a buffer pointer for a log output thread in a kernel mode to write log information is switched from an address of the first log buffer in a user space to an address pointing to the second log buffer, and a buffer pointer for a log read thread to read log information points to an address of the first log buffer.

In this optional implementation manner, when two log buffers are exchanged, because the two log buffers need to be locked respectively, the time for locking is long due to the copy algorithm of the contents of the buffer, which affects the overall performance. Therefore, in the embodiment of the present disclosure, when performing buffer exchange operation, addresses of two log buffers are directly exchanged, a pointer pointing to the log buffer Buff _1 when the log output thread performs write operation points to the log buffer Buff _2, a pointer pointing to the Buff _2 when the log read thread performs read operation points to the Buff _1, and then subsequent read-write operation is performed, so as to achieve the purpose of exchanging buffers, at this time, only exchanging pointers are required for operation in a critical region, so that the execution speed is fast. The design of the double-buffer area mode only needs to ensure that one buffer area can write data and one buffer area can read data, so that when the log output thread in the kernel state writes data into the buffer area, the execution of the log output thread in the kernel state cannot be blocked due to the low execution speed of the user state, and the processing efficiency of the kernel state is further improved.

In addition, a semaphore mechanism can be adopted to solve the problem of synchronous mutual exclusion generated by multithread access buffer, thread mutual exclusion is realized for reading and writing operations of the same buffer, and after the buffer finishes the exchange operation, a reading thread is informed to read the buffer.

establishing an idle audit buffer area;

In this optional implementation manner, when the security monitoring system is initialized, a plurality of idle audit buffers may be established in advance, and pointers of the idle audit buffers are stored in the idle audit buffer linked list. When the system call interface of the kernel space exits, and the audit information in the audit context structure of the execution object calling the system call interface needs to be output to the user space from the kernel space, an idle audit buffer area can be requested from the idle audit buffer area chain table by the audit output thread, and the audit information in the audit context structure is written into the idle audit buffer area.

It should be noted that, the pointer of the audit buffer area written with the audit information can be taken out from the idle audit buffer area linked list by the corresponding audit output thread and then written into the non-idle audit buffer area linked list, and the execution of the idle audit buffer area linked list pointing to the audit buffer area can be deleted.

In the optional implementation mode, the pointer of the created idle audit buffer area can be written into the audit buffer area chain table by the audit output thread, when the execution object in the kernel space requests the audit buffer area, the audit output thread can also find the idle audit buffer area from the audit buffer area chain table, and the audit information in the audit context structure of the execution object is written into the idle audit buffer area.

If the audit buffer chain table has no pointer pointing to the idle audit buffer, the audit output thread can allocate a new audit buffer for the current execution object again, and the corresponding audit output thread writes the audit information in the audit context structure of the execution object into the new audit buffer.

and deleting one or more audit files established firstly according to the time sequence after the number of the audit files exceeds the preset number.

In this alternative implementation, the audit information may be written to the audit file by the audit read thread periodically or after the audit buffer is full. The audit files are stored in a user space, the storage capacity of the audit files can be set in advance when the safety monitoring system is initialized, after the size of audit information stored in one audit file exceeds the preset storage capacity, a new audit file can be established by a file establishing thread started after the safety monitoring system runs, and subsequent audit information can be written into the new audit file.

In some embodiments, when the number of audit files is too large, for example, is more than the preset number, the file deletion thread started after the security monitoring system operates may delete one or more audit files established first according to the time sequence of the audit file establishment, and retain a plurality of newly established audit files.

Fig. 3 (a) -3 (c) are schematic diagrams illustrating one implementation of a logging system and an auditing system included in a security monitoring system of a microkernel operating system according to an embodiment of the present disclosure. As shown in fig. 3 (a), the log system may maintain a log buffer in the user space, log information is written into the log buffer according to a uniform format, and a klogd thread in the log system may be responsible for monitoring and obtaining the log information of the log buffer, and writing the log information into a log file. In kernel space, the log output thread printk may write messages of the kernel space into the log buffer.

The log information can be recorded according to the operating system security technology standard, and the related log information defined in the standard is defined in the standard, and the events to be recorded in the log part are defined as follows: the method comprises the following steps of running records of the system, alarm prompt records, operation log records, user behavior records, application software running logs, configuration information modification records and the like.

As shown in fig. 3 (b), the logging protocol format adopted by the embodiment of the present disclosure is syslog logging protocol standard, and the first part PRI is a priority, including the program module facility of the log and the severity level server of the message. The priority is usually started by the character "<", followed by a number of 1~3 bits, and then ended with ">", where part of the number is calculated from the program module of the log and the severity level number of the message. In some embodiments, the priority value may be equal to the program module code multiplied by 8, plus the severity level number.

The second part HEADER is the HEADER of the log, which consists of a timestamp, ip address of the device, or host name. The timestamp is immediately followed by ">", and the timestamp is separated from the device ip address or host name by a space.

The third part MSG is log information, which is a part that needs to record a log, i.e. description information of the log, and is generally divided into two fields. One field is used for representing the name of a program or thread generated by a message, and the set length is within 32 characters; another field is used to record detailed description information. The two fields are partitioned with "[", ": or spaces between them.

As shown in fig. 3 (c), the audit system reads audit information in the audit buffer by the audiod thread in user space and writes the audit information into the audit file audio. The following introduces the auditing system in this embodiment from four aspects of auditing events, auditing information filtering, auditing buffer setting, and auditing commands.

1. Auditing events

The audit event is the minimum unit of the action of the system audit user, and the collection of the audit event refers to the establishment of the audit event under a certain security level audit standard. From the perspective of a subject, the system needs to record all activities performed by the user, and from the perspective of an object, the system needs to record all access activities of an object. The audit event can be mainly divided into a system call event and a user credible event, and the following design is made for the system call event in the present disclosure:

the system calls the class event, the body can be the thread, this disclosure adds the audit context structure pointer audio _ context in the thread structure, record the audit information of thread context. When a thread goes from entering a system call to exiting the system call, an audit context structure is used to record data, such as parameters, call numbers, success/failure identification, returned results of the system call, etc., that the system call entered and exited.

In some embodiments, the auditing system adds auditing functions (an entry function audio _ syscall _ entry and an exit function audio _ syscall _ exit) at the entry and exit of the system call interface, writes auditing information when the system call interface enters and exits into an auditing context structure, and writes the auditing information when the system call exits into a buffer. After the audit information is written out, the audit context can be emptied.

If an audit context structure is created and a corresponding state is set when a thread is created, filling of the audit context is carried out at an entrance of a system call interface, entry audit information when the system call interface enters is recorded into the audit context structure of the thread through an entry function audio _ syscall _ entry, and exit audit information is written into the audit context structure through an exit function audio _ syscall _ exit. And finally, writing the information in the audit context structure into an audit buffer by an audit output thread.

2. And filtering the audit message.

An authorized user can set the type of an event to be filtered through an audiotctl command designed in an auditing system, namely, configure auditing configuration information, and place an event rule (mainly type information) which is not to be checked into a rule linked list. The auditing system can provide a filter function of audio _ filter _ type (int type), the parameter is event type, and for different types of rule linked lists, the auditing system can output related auditing information only when the filter check is passed and the value is returned. That is, when the current system call event type is matched with the audit configuration information, the audit system outputs the related audit information.

3. Buffer setting

The auditing system sets an auditing buffer area in the user space, and designs an auditing buffer area linked list used for storing a pointer of the auditing buffer area filled with auditing information. When the number of the buffers in the audit buffer linked list exceeds the upper limit, the current thread can wait for the related threads of the user space to write the audit information into the audit log file until the number of the buffers is less than the upper limit.

Meanwhile, an idle audit buffer area chain table can be designed for storing idle audit buffer areas. When applying for audit buffer area, the system checks whether the idle audit buffer area chain list has idle audit buffer area, if yes, it returns to the applicant, if not, it distributes a new audit buffer area. When the applied audit buffer is released, whether the idle buffer linked list exceeds the upper limit or not can be checked, if not, the to-be-released audit buffer is put into the idle buffer linked list, otherwise, the to-be-released audit buffer is directly released.

4. User management tool

In some embodiments, the user can start the three management tools by calling corresponding commands such as audioctl, ausearch, aureport and the like, namely, the audit system is configured and operated by using the commands. The Ausearch command queries the background log based on different search rules; the Aureport command is used for generating a summary report of the audit log; the audiotll command is used for setting an audit rule, and when the system is started, the rule in the configuration file can be read, and the rule can be added or deleted.

And (4) writing audit information conforming to the rules and the formats into an audit file from an audit buffer by a user thread audiod in the audit system.

The present disclosure achieves reduction of space overhead in terms of generation, recording, cleaning, and the like of logs in order to reduce consumption of storage space. The concrete aspects are as follows:

1. setting a buffer area

The log system and the audit system are respectively provided with a log buffer area and an audit buffer area, and an audit buffer area linked list, and the problem of unmatched speeds of log data generation and file writing can be solved by introducing the buffer areas.

2. Reducing the frequency of recordings of the same event

Combining a plurality of same events in a log entry, and recording the number of events in a counter mode, when more events are combined in a log entry, the expense of logging is reduced.

3. Screening and filtering audit events

A tool for configuring audit configuration information is provided in a user space, an authorized user can configure events, formats and the like to be audited according to actual requirements, and an audit system provides related functions so as to conditionally record only related events which the user actually needs to audit.

4. Writing files separately or deleting files periodically

When the log file or the audit file reaches the limited size, a log file or audit is newly created, and new log content or audit is written into the new file; and when the number of the log files or the audit files reaches a set threshold value, deleting partial files according to the file creation sequence.

The safety monitoring system based on the microkernel operating system is designed and realized, and the runtime information of the operating system is recorded and analyzed, so that the safety of the operating system is ensured. At present, few microkernel operating systems are designed for relatively perfecting a security audit module, the security monitoring system based on the microkernel operating system, which meets the security standard of the operating system, is designed and realized by the method, the running state and information of the operating system can be recorded in real time, certain feedback is made to a manager on the basis of log recording, and the security and the reliability of the operating system are ensured; in addition, on the basis of perfect log information, the running state of the system and the user behavior are monitored, potential hazards are pointed out, and meanwhile, the space consumption is reduced as much as possible.

The following are embodiments of the disclosed apparatus that may be used to perform embodiments of the disclosed methods.

Fig. 4 is a block diagram illustrating a security monitoring apparatus based on a microkernel operating system according to an embodiment of the present disclosure. The apparatus may be implemented as part or all of an electronic device through software, hardware, or a combination of both. As shown in fig. 4, the security monitoring apparatus based on microkernel operating system includes:

the response module 401 is configured to respond to a call request of an execution object in a user space to a system call interface in a microkernel operating system, and match a system call event type corresponding to the call request with pre-configured audit configuration information in the kernel space;

a recording module 402, configured to record, when the system call event type matches the audit configuration information, entry audit information when the system call interface enters kernel space for operation in the audit context structure of the execution object, and record exit audit information when the system call interface exits in the audit context structure of the execution object;

a first output module 403, configured to output the entry audit information and the exit audit information in the audit context structure from the kernel space to an audit buffer in a user space when exiting the system call interface.

In this embodiment, for the microkernel operating system, the kernel portion is simplified to the maximum extent. The kernel part only comprises the most basic IPC (inter-process communication) mechanism, address space management and scheduling mechanism and the like for realizing the basic functions of the operating system service, and at the service level, the device driver, the file system, the inter-application program communication and the like are realized by means of a user-mode service program. When a common application program needs related services of an operating system, the common application program needs to initiate inter-process communication to corresponding service programs, the service programs carry out related operations, and the service programs can also be trapped into kernel-mode operation through a system call interface provided by an execution kernel if necessary so as to complete some basic operations, and the results are fed back to the application program through the inter-process communication.

The audit event is the minimum unit of the action of the system audit user, and the collection of the audit event refers to the establishment of the audit event under a certain security level audit standard. From the perspective of a subject, the system needs to record all activities performed by the user, and from the perspective of an object, the system needs to record all access activities of an object.

In the embodiment of the disclosure, the security monitoring system may be implemented by programming, and after the security monitoring system operates, the system call event may be detected by starting one or more detection threads in the user space. After the one or more detection threads in the security monitoring system detect a system call event, the type of the system call event may be matched with a rule set in audit configuration information in a storage file, if the currently detected system call event is an event related to content to be audited, which is pre-configured by a user with a related authority, that is, if the type of the currently detected system call event is matched with the pre-configured audit configuration information, entry audit information when the currently called system call interface enters a kernel mode for operation is written into an audit context structure corresponding to the execution object, and exit audit information when the execution of the system call interface is completed and exits is also written into the audit context structure corresponding to the execution object.

In some embodiments, the audit context structure may be as follows:

struct audit_context{

enum audio _ state// audit state

unique int serial number// serial number of record

struct timing ctime// time of system call entry

int major// System Call number

Signaled long argv [4 ]/system call parameter

Long return code// System Call Return code

int audio table// flag of whether or not it has been written to audit buffer

}。

In an optional implementation manner of this embodiment, the apparatus further includes:

and the first writing module is configured to write first kernel-state log information generated by the system call interface in a kernel space execution process into a log buffer of a user space when the system call event type corresponding to the call request is not matched with the audit configuration information.

In this optional implementation manner, if the system call event type corresponding to the currently called system call interface is not matched with the audit configuration information preferentially configured by the authorized user, it is indicated that the content related to the current system call is not the audit information concerned by the authorized user, so that the related audit information may not be generated. However, for subsequent viewing needs, the relevant log information can be written to a log buffer in user space. In some embodiments, a log output thread, which may be started by the security monitoring system after running, writes the relevant log information to a log buffer in user space.

a second writing module configured to write user-mode log information generated by a user space into the log buffer; and/or the presence of a gas in the atmosphere,

In this optional implementation manner, the log buffer may further record user-mode log information generated by the user space, and the second kernel-mode log information generated by the kernel space may also be written into the log buffer. In this embodiment, in order to distinguish the log information generated by the system call event in the kernel space from the log information generated in other cases, the log information generated by the system call event is referred to as first kernel-state log information, and the log information generated in other cases is referred to as second kernel-state log information. In some embodiments, the first kernel-state log information may be written to a log buffer by a log output thread established upon initialization by the security monitoring system. It is understood that the first kernel-state log information and the second kernel-state log information may be processed by the same log output thread or may be processed by different log output threads.

The first kernel-state log information and the second kernel-state log information generated by the kernel space can be output from the kernel space to a log buffer of the user space by a specially-arranged log output thread. The user space generated log information may be written by the corresponding thread into a log buffer of the user space. In some embodiments, the corresponding thread may be initiated after the security monitoring system is running.

a first reading module configured to read log information in the log buffer in a user space;

In this optional implementation manner, the log information is recorded in a log buffer established in the user space, the security monitoring system may start a log reading thread after running, and when the log buffer is full or at regular intervals, the log reading thread may write the log information in the log buffer into a log file. The process of writing the log file can be carried out in a user space, and the log reading thread can write the log information into the log file from the log buffer area by calling a file system interface in the user space. In other embodiments, the log information in the log buffer can also be directly output to the console, a storage device stored on the console, and/or a display displayed on the console by the log reading thread by calling the file system interface, so as to be viewed by related personnel.

In this optional implementation manner, the user space may also generate some information that the authorized user wants to audit, the authorized user may also pre-configure audit configuration information for the user space, configure the event type and/or the information type that wants to audit in the audit configuration information, after the user space generates the user space audit information, an audit matching thread started after the safety monitoring system runs may be matched with the audit configuration information, if the audit matching thread is matched, the audit matching thread is written into the audit buffer, if the audit matching thread is not matched, the audit matching thread may not be written into the audit buffer, but the related log thread is written into the log buffer.

In this optional implementation manner, the authorized user may input the user configuration information through an interface preset in the user space, and the user configuration information may be used to update audit configuration information stored in the user space in advance. By the method, the authorized user can pre-configure the audit configuration information in the user space and can also modify the audit configuration information and other editing operations in the follow-up process. After the safety monitoring system operates, an interface for a user to input user configuration information can be provided, and through the interface, the safety monitoring system can receive the user configuration information input by the user and update the received user configuration information into a storage file of the configuration information.

In the optional implementation mode, the audit information of the user space and the kernel space is recorded in the audit buffer area established by the user space, the safety monitoring system can start the audit reading thread after running, and the audit information in the audit buffer area can be written into an audit file by the audit reading thread when the audit buffer area is full or regular. The process of writing the audit file can be carried out in a user space, and the audit reading thread writes the audit information into the audit file from the audit buffer area by calling a file system interface in the user space. In other embodiments, the audit information in the audit buffer can also be directly output to the console, a storage device stored on the console, and/or a display displayed on the console by the audit reading thread by calling a file system interface for viewing by related personnel.

In this optional implementation manner, after the audit information is written into the audit file, when the authority user views the audit file, the audit information may be generated into an audit report based on a pre-configured audit rule, and the audit report is output to the authority user. The safety monitoring system can also provide a viewing interface for viewing the audit file for the user, and after the viewing interface receives the request of the user, the auditing system can output the audit report to the user under the condition that the current user is determined to have the authority.

the second calling module comprises:

the calling sub-module is configured to call a file system interface to output the audit information in the audit buffer area to the audit file based on the pointer in the audit buffer area linked list in the user space after the number of the pointers in the audit buffer area linked list exceeds a preset threshold;

In this optional implementation, when two audit buffers are exchanged, since the two audit buffers need to be locked respectively, the copy algorithm of the buffer contents will result in a long locking time, which affects the overall performance. Therefore, in the embodiment of the disclosure, when buffer exchange operation is performed, addresses of two audit buffers are directly exchanged, a pointer pointing to the audit buffer Buff _1 of the audit output thread when write operation is performed points to the audit buffer Buff _2, a pointer pointing to the Buff _2 of the audit read thread when read operation is performed points to the Buff _1, and then subsequent read-write operation is performed, so that the purpose of exchanging buffers is achieved, at this time, only exchanging pointers are performed in the critical region, so that the execution speed is high. The design of the double-buffer area mode only needs to ensure that one buffer area can write data in and one buffer area can read data, so that when the kernel-state audit output thread writes in the buffer area, the kernel-state audit output thread cannot be blocked from being executed due to the low execution speed of the user state, and the kernel-state processing efficiency is further improved.

In the embodiment of the disclosure, a large buffer area is not required to be established, but a double buffer area in an array form is set, the buffer area used for read-write operation is separated and designed into two buffer areas, and thread blocking caused by long locking time of the same buffer area can be avoided. Meanwhile, the buffer area in the array form is allocated at one time, so that frequent memory allocation and release can be avoided.

In an optional implementation manner of this embodiment, in a double buffering mode of a log buffer, after a first log buffer for currently writing log information is full, addresses of the first log buffer and a second log buffer are exchanged, so that a buffer pointer for a log output thread in a kernel mode to write log information is switched from an address of the first log buffer in a user space to an address pointing to the second log buffer, and a buffer pointer for a log read thread to read log information points to an address of the first log buffer.

a first establishing module configured to establish a free audit buffer;

the first output module includes:

If the audit buffer linked list has no pointer pointing to the idle audit buffer, the audit output thread can allocate a new audit buffer for the current execution object again, and the corresponding audit output thread writes the audit information in the audit context structure of the execution object into the new audit buffer.

and the deleting module is configured to delete one or more audit files established at first according to the time sequence after the number of the audit files exceeds the preset number.

In some embodiments, when the number of audit files is too large, for example, more than a preset number, the file deletion thread started after the safety monitoring system operates may delete one or more audit files established first according to the time sequence of the audit file establishment, and retain a few audit files established later.

The embodiment of the present disclosure further provides a chip, where the chip includes the security monitoring apparatus based on the microkernel operating system, the chip may be any one of the chips that can implement the security monitoring process based on the microkernel operating system described above, and the apparatus may be implemented as part or all of the chip by software, hardware, or a combination of the two. The security monitoring process based on the microkernel operating system may refer to the above description of the security monitoring method based on the microkernel operating system, and is not described herein again.

The present disclosure also discloses an electronic device, fig. 5 shows a block diagram of an electronic device according to an embodiment of the present disclosure, and as shown in fig. 5, the electronic device 500 includes a memory 501 and a processor 502; wherein,

the memory 501 is used to store one or more computer instructions, which are executed by the processor 502 to implement the above-described method steps.

As shown in fig. 6, the computer system 600 includes a processing unit 601 which can execute various processes in the above-described embodiments according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data necessary for the operation of the computer system 600 are also stored. The processing unit 601, the ROM602, and the RAM603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. A driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary. The processing unit 601 may be implemented as a CPU, a GPU, a TPU, an FPGA, an NPU, or other processing units.

In particular, the above described methods may be implemented as computer software programs, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a medium readable thereby, the computer program comprising program code for performing the method. In such embodiments, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, a program segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units or modules described in the embodiments of the present disclosure may be implemented by software or hardware. The units or modules described may also be provided in a processor, and the names of the units or modules do not in some cases constitute a limitation of the units or modules themselves.

As another aspect, the present disclosure also provides a computer-readable storage medium, which may be the computer-readable storage medium included in the apparatus in the above embodiment; or it may be a separate computer readable storage medium not incorporated into the device. The computer readable storage medium stores one or more programs for use by one or more processors in performing the methods described in the present disclosure.

The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the present disclosure is not limited to the specific combination of the above-mentioned features, but also encompasses other embodiments in which any combination of the above-mentioned features or their equivalents is possible without departing from the inventive concept. For example, the above features and (but not limited to) the features disclosed in this disclosure having similar functions are replaced with each other to form the technical solution.

Claims

1. A safety monitoring method based on a microkernel operating system is characterized by comprising the following steps:

2. The method of claim 1, further comprising:

3. The method of claim 2, further comprising:

4. The method of claim 2, further comprising:

reading the log information in the log buffer area in a user space;

5. The method of claim 1, further comprising:

acquiring user space audit information generated by a user space;

6. The method of claim 1, further comprising:

7. The method of claim 4, further comprising:

receiving a viewing request of a user for a log file in a user space;

outputting the log file to a user based on the viewing request.

8. The method of claim 1, further comprising:

reading audit information in the audit buffer area in a user space;

9. The method of claim 8, further comprising:

receiving a viewing request of a user for the audit file in a user space;

10. The method according to claim 8 or 9, characterized in that the method further comprises:

calling a file system interface to output the audit information in the audit cache region to an audit file, wherein the method comprises the following steps:

and deleting the corresponding pointer in the audit buffer linked list.

11. The method of claim 1, further comprising:

establishing an idle audit buffer area;

12. The method of claim 11, further comprising:

13. The method of claim 1, further comprising:

14. A microkernel operating system based security monitoring apparatus, comprising:

15. The apparatus of claim 14, further comprising:

16. The apparatus of claim 15, further comprising:

the third writing module is used for writing second kernel-state log information generated by the kernel space into the log buffer area; and the second kernel-state log information is log information generated by a non-system call interface in a kernel space.

17. The apparatus of claim 15, further comprising:

18. The apparatus of claim 14, further comprising:

19. The apparatus of claim 14, further comprising:

20. The apparatus of claim 18, further comprising:

21. The apparatus of claim 14, further comprising:

a second reading module configured to read audit information in the audit buffer in a user space;

22. The apparatus of claim 21, further comprising:

23. The apparatus of claim 21 or 22, further comprising:

the second calling module comprises:

24. The apparatus of claim 14, further comprising:

a first establishing module configured to establish a free audit buffer;

the first output module comprises:

25. The apparatus of claim 24, further comprising:

26. The apparatus of claim 14, further comprising:

27. An electronic device comprising storage, a processor, and a computer program stored on the memory, wherein the processor executes the computer program to implement the method of any of claims 1-13.

28. A computer-readable storage medium having computer instructions stored thereon, wherein the computer instructions, when executed by a processor, implement the method of any one of claims 1-13.

29. A chip for executing instructions which are executed by the chip to carry out the method steps of any of claims 1-13.