Method and tool for detecting Rust operating system

Abstract

The embodiment of the invention provides a method and a device for detecting an OS (operating system) of a Rust. The detection method is executed by using a detection tool, and the detection tool comprises a gasket layer, an address management module, a memory operation module and an inspection module. Wherein the gasket layer provides a plurality of interfaces. The detection method comprises the steps that a gasket layer converts calling of an OS code on a first interface into a first instruction; wherein the first interface is used for realizing operation related to the physical memory. The memory operation module responds to the first instruction and executes first operation based on target data maintained by the address management module, and the target data is used for maintaining use of the physical page in the target memory section. The checking module checks whether the first operation relates to a first behavior item related to a physical page state error to detect an undefined behavior.

Description

Technical Field

[0001] One or more embodiments of this specification relate to computer operating systems, and in particular, to a method and a detection tool for detecting a Rust operating system. Background Art

[0002] The Rust language is a new system programming language that can eliminate many problematic codes during compilation through security checks. In addition, features such as no runtime and garbage collection mechanism make Rust code run much faster than languages like Java and Python and be competent for high-performance scenarios. These advantages have made the Rust language increasingly concerned by people. Recently, operating systems written in Rust have also emerged, such as Thesus, RedLeaf, and Tock.

[0003] The Rust compiler performs mandatory checks during compilation. This mandatory check can detect most undefined behaviors UB (Undefined Behavior) that cause runtime errors, such as accessing a null pointer, etc., thereby eliminating many problematic codes during compilation and ensuring the correct operation of the program. However, in Rust, there is also a special keyword called unsafe, which can mark a code block so that the compiler does not perform some mandatory checks on this code block, and the programmer is responsible for the security of this code block. The appearance of this keyword is because using only code checked by the compiler is not flexible in some scenarios, making the program unable to perform special operations. In order to enable the program to have higher performance or implement special functions, the Rust compiler provides the unsafe keyword to give the program higher permissions.

[0004] However, this also brings risks and hidden dangers to the correct and secure operation of Rust programs. Incorrect use of the unsafe keyword can easily lead to a large number of undefined behaviors being introduced into the system, resulting in system instability or even crashes. In particular, in Rust operating systems, it is almost inevitable to use the unsafe keyword extensively.

[0005] Therefore, it is hoped that there can be an improved solution to detect Rust-written operating systems to discover problematic codes that may cause undefined behavior UB, thereby improving the stability and reliability of the operation of system programs. Summary of the Invention

[0006] One or more embodiments of this specification describe a method and a device for detecting a Rust operating system, which can detect and discover problematic codes in the Rust operating system that may cause undefined behavior UB through dynamic detection.

[0007] According to a first aspect, there is provided a method for detecting a Rust operating system OS, which is executed by a detection tool including a shim layer, an address management module, a memory operation module, and an inspection module; the shim layer provides a number of interfaces; the method includes:

[0008] The shim layer converts the call of the OS code to the first interface among the number of interfaces into a first instruction; the first interface is used to implement operations related to physical memory;

[0009] The memory operation module, in response to the first instruction, performs a first operation based on the target data maintained by the address management module, where the target data is used to maintain the use of physical pages in a target memory section;

[0010] The inspection module checks whether the first operation involves a first behavior item related to a physical page state error to detect undefined behavior.

[0011] In a specific implementation, the above target data may include a first data structure for maintaining the use state of physical pages; the use state includes: a Reserved state indicating system reservation, a Free state indicating unallocated, an Untyped state indicating allocated but not typed, and a Typed state indicating allocated and typed.

[0012] Specifically, the above first operation includes at least one of the following: modifying the use state of a target physical page; typing an Untyped state physical page; performing a read operation, a write operation, or a copy operation on a physical page in a specified state.

[0013] In a specific implementation, the above target data may include a page table. Correspondingly, the first operation includes one or more of the following: activating the page table, looking up a page table entry, modifying a page table entry.

[0014] In one embodiment, the first behavior items checked by the inspection module include at least one of the following: accessing a physical page in the Reserved state or the Free state; the conversion of the physical page use state does not conform to the predetermined migration logic; typing a Free state physical page; repeatedly typing the same physical page.

[0015] Furthermore, the first behavior items also include at least one of the following: a Typed state physical page belonging to the kernel mode is mapped to the user mode space in the page table; a Typed state physical page has multiple active mappings at the same time.

[0016] According to one implementation, the above-mentioned target memory section is a physical memory section allocated when the detection tool is started. Correspondingly, the above method further includes: the address management module initializes the target data when starting the detection.

[0017] In one embodiment, the target data includes a multi-level page table; correspondingly, initializing the target data specifically includes initializing the root page table in the multi-level page table.

[0018] In one implementation, several interfaces provided by the shim layer further include a second interface; the detection tool further includes a thread simulation module; the above method further includes:

[0019] The shim layer converts the call of the OS code to the second interface into a second instruction; the second interface is related to thread scheduling;

[0020] The thread simulation module performs a second operation, and the second operation includes performing thread scheduling-related operations corresponding to the second instruction;

[0021] The inspection module checks whether the second operation involves a second behavior item related to thread scheduling errors to detect undefined behavior.

[0022] In a specific embodiment, the second interface is used for thread switching; the thread scheduling-related operations corresponding to the second instruction may include: switching the first thread currently executing on the first CPU to the second thread.

[0023] In one embodiment, the second operation performed by the thread simulation module further includes: switching the thread on the first CPU to the thread on a randomly determined second CPU according to a preset probability.

[0024] In a specific example, the second behavior items checked by the inspection module include at least one of the following: a thread that has exited is scheduled again; a single thread is scheduled to multiple CPUs simultaneously.

[0025] In one embodiment, the above-mentioned OS code is the middle-level intermediate representation MIR code obtained by compiling the Rust source code of the Rust operating system.

[0026] In one implementation, the above-mentioned detection tool is written in the Rust language and implemented based on the Rust standard library.

[0027] According to a second aspect, there is provided a detection device for detecting the Rust operating system OS, the detection device includes a shim layer, an address management module, a memory operation module, and an inspection module; the shim layer provides several interfaces; wherein:

[0028] The gasket layer is used to convert the call of the first interface among the several interfaces by the OS code into a first instruction; the first interface is used to implement operations related to physical memory;

[0029] The address management module is used to maintain target data, and the target data is used to maintain the usage of physical pages in the target memory section;

[0030] The memory operation module is used to execute a first operation based on the target data in response to the first instruction;

[0031] The check module is used to check whether the first operation involves a first behavior item related to physical page state errors to detect undefined behavior.

[0032] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is made to execute the method of the first aspect.

[0033] According to a fourth aspect, a computing device is provided, including a memory and a processor. An executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0034] The embodiments of this specification provide a method and a detection tool for detecting the Rust operating system. The above detection tool is extended based on the existing dynamic UB detection tool Miri, inheriting the good usability of Miri while maintaining compatibility. Compared with the existing Miri tool, the improved detection tool supports an address management system that is more in line with the OS. Specifically, a data structure for maintaining the usage of physical pages is introduced to support the memory operation requirements of the OS kernel. The detection tool also overcomes the problem that Miri cannot interpret and execute OS programs through the extension of the gasket layer. Through the above detection tool, using the detection method in the embodiments, effective and comprehensive dynamic UB detection can be performed on the Rust operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0036] Figure 1 A schematic structural diagram showing the dynamic UB detection tool Miri;

[0037] Figure 2 A schematic structural diagram showing the improved detection tool in an embodiment;

[0038] Figure 3 Show the operation of the Rust operating system in different architectures;

[0039] Figure 4 Show the method flow for detecting the Rust operating system OS according to an embodiment;

[0040] Figure 5 Show the flowchart for detecting thread-related UB according to an embodiment;

[0041] Figure 6 Show the execution logic of the thread simulation module. Detailed implementation manners

[0042] The following describes the solution provided in this specification in conjunction with the accompanying drawings.

[0043] Hereinafter, a program written in the Rust language will be referred to as a Rust program; an operating system written in the Rust language will be referred to as a Rust operating system. The Rust operating system can be regarded as a special Rust program.

[0044] As mentioned above, Rust provides the unsafe keyword, enabling the code segment identified by this keyword to avoid the mandatory checks of the Rust compiler. To reduce the risk of errors occurring during the runtime of Rust programs, in related technologies, various auxiliary detection means have been proposed to detect and discover undefined behavior UB in Rust programs.

[0045] One detection method is formal verification. In theory, the correctness of a Rust program can be formally verified through deductive verification or bounded model checking (such as the Kani model). However, in practice, on the one hand, the cost of formal verification is relatively high and it is difficult to sustain for rapidly developing projects because the development speed of the verification code is hard to keep up with the development speed of the program code. In addition, for the development of the Rust operating system, the verification tools for formal verification often limit the set of Rust language features available to system developers, which is in conflict with some projects that use advanced features in the Rust toolchain. Therefore, whether in terms of cost or limitations, the current formal verification method is not suitable for UB detection of the Rust operating system.

[0046] Another detection method is static UB detection. In recent years, many static analysis tools for Rust programs have been developed in the academic community, such as Rudra, SafeDrop, MirChecker, etc. However, these static analysis tools only analyze and detect certain specific types of UBs, suffering from problems such as incomplete UB coverage and high false positive and false negative rates. At the same time, they cannot understand many semantics specific to operating systems, such as the alias relationship caused by a physical page being mapped to two virtual addresses, and thus cannot detect UB behaviors specific to operating systems.

[0047] In the related art, a dynamic UB detection scheme and tool have also been proposed. The Rust official provides a powerful UB detection tool Miri, which is easy to use and can capture UB errors in practice. Miri is implemented based on the internal interpretation execution interface provided by the Rust compiler and supports the latest Rust language features. The working principle of Miri is to compile Rust code into MIR, interpret and execute MIR, and use a set of built-in checkers to capture undefined behaviors during the interpretation execution process. However, Miri was initially designed for Rust (user-space) programs and lacks support for the Rust operating system kernel involving underlying software and hardware interactions. If the existing Miri tool is used to detect UBs in the Rust operating system, the privileged code (such as assembly code and interfaces encapsulated by assembly) involving underlying hardware interactions in the Rust operating system needs to be stripped out, and "pure" Rust code needs to be abstracted additionally. This part of the "pure" Rust code is then input into Miri for testing. This is because Miri cannot directly run kernel code, so developers need to abstract the kernel code into "pure" Rust code additionally. For example, the Task structure is taken out separately and placed in a user-space Rust program, and some hardware-related operation statements are replaced with dummy implementations. Only this code completely decoupled from the kernel can be interpreted and executed by Miri. This method cannot directly use the Miri tool and may also miss environment-level undefined behaviors caused by underlying hardware configuration errors (such as page table configuration errors).

[0048] In view of this, this specification proposes to improve and extend dynamic UB detection tools such as Miri to make them applicable to UB detection of the Rust operating system.

[0049] First, the detection method of the Miri tool is further introduced below, and the reasons why it does not support OS code detection are analyzed; then, the improved detection tool obtained by modifying and extending Miri is described.

[0050] Figure 1 The structural schematic diagram of the dynamic UB detection tool Miri is shown. As Figure 1As shown, the Miri tool takes the Middle-level Intermediate Representation (MIR) corresponding to the Rust program as input and performs detection and analysis based on Rust MIR. Specifically, the Miri tool at least includes: a MIR interpreter 11, a shims layer 12, a virtual address module 13, a memory operation module 14, and a UB check module 15. The following will describe them separately.

[0051] The Middle-level Intermediate Representation (MIR) is an intermediate code form generated by the Rust compiler during the compilation process, located between the high-level Abstract Syntax Tree (HIR) and the low-level LLVM IR. The design purpose of MIR is to simplify the ownership and borrowing checks in Rust, while providing a clearer structure for compiler optimization. It is a key step for the Rust compiler to perform memory safety checks, optimizations, and code generation.

[0052] Miri obtains the above Rust MIR as its input and interprets and executes the MIR corresponding to the Rust program through the MIR interpreter 11.

[0053] The shims layer is a software adaptation layer used to provide compatibility between different systems or components. It is usually implemented by encapsulating or converting interfaces, enabling the upper-layer code to interact with the underlying system without modification. In Figure 1 the shown Miri tool, the shims layer 12 is used to simulate various services of the operating system that the Rust program may use (such as memory allocation, thread management, etc.) to support standard library functions when interpreting and executing Rust MIR.

[0054] Specifically, during the execution of the Rust program, it will inevitably call the services related to memory allocation in the operating system. At this time, the shims layer 12 converts such system calls into memory-related simulation services in Miri, and this simulation service can be specifically implemented based on the virtual address module 13 and the memory operation module 14.

[0055] In Miri, the virtual address module 13 provides a linear and single virtual address space for Rust programs. As shown in the right figure, Miri provides a continuous virtual address space, and all memory objects are sequentially assigned virtual addresses in this virtual address space. For example, in the illustrated example, memory objects include stack objects, static objects, and heap objects. Object 1 belongs to a static object, and Object 2 belongs to a stack object, but their virtual addresses are linearly and continuously arranged in the virtual address space. The memory operation module 14 operates on each object based on the virtual address. The virtual address module 13 and the memory operation module 14 only need to focus on the alignment of virtual addresses and the correctness of internal use. The UB checking module 15 uses comprehensive Rust language UB checking logic to check whether each operation causes UB.

[0056] The above address management method is sufficient for ordinary Rust programs. Because the operations of user-state Rust programs on each object generally remain at the virtual address level and do not pay attention to the physical addresses of the objects. However, the Rust operating system OS inevitably involves interactions with the underlying hardware. For memory operations, the OS must use memory addresses precisely, not only paying attention to virtual addresses but also using physical addresses. Specifically, in the OS, a paging system is generally used to divide physical memory into memory pages and establish a mapping between physical memory and virtual memory. Therefore, at least for the basic memory operations during program execution, the address management method in the Miri tool is not suitable for detecting Rust OS.

[0057] Therefore, according to the embodiments in this specification, the existing UB detection tool (such as Miri) is extended and modified to obtain an improved detection tool. For simplicity, the improved detection tool is hereinafter referred to as KernMiri. However, it should be understood that this is only for the convenience and clarity of description and does not mean to limit the implementation method, name, etc. of this detection tool.

[0058] Figure 2 Shows a schematic structural diagram of the improved detection tool in an embodiment. As Figure 2 shown, the improved detection tool KernMiri includes a MIR interpreter 21, an extended shim layer 22, an address management module 23, a memory operation module 24, a checking module 25; optionally, it also includes a thread simulation module 26.

[0059] The MIR interpreter 21 can reuse the existing MIR interpreter 11 in Miri. The extended shim layer 22 is further extended based on the existing shim layer 12.

[0060] It can be understood that the original shim layer 12 of Miri is used to simulate operating system services. However, in practice, only the simulation services for mainstream operating systems such as Linux and Windows are implemented. The interfaces of the newly developed Rust OS system services are usually different from the mainstream OS interfaces originally supported by Miri. Therefore, additional support from a shim layer is required. In addition, the original shim layer 12 of Miri only simulates and forwards system services that Rust programs may use. However, for interpreting and executing the operating system, some more underlying operations related to the kernel Kernal also need to be simulated. In Rust OS, underlying operations usually need to be implemented in assembly code, and assembly code is not MIR and cannot be interpreted and executed by the MIR interpreter. This also requires an additional shim layer to simulate, so that Rust OS can interact smoothly with the improved detection tool KernMiri.

[0061] In some embodiments, the extended shim layer 22 can provide several interfaces for the OS code to call to simulate the implementation of more underlying operations. Specifically, the shim layer 22 can be implemented by declaring extern Rust function interfaces. The OS code can call these extern function interfaces, and KernMiri implements corresponding simulation operations for each interface. For example, when a certain interface of the shim layer 22 is called, the call is converted into an internal operation instruction of KernMiri and passed to the corresponding module, and the internal module of KernMiri implements the simulation operation of the function of this interface.

[0062] The interfaces provided by the shim layer 22 for Rust OS can include interfaces related to the underlying operation functions of the kernel.

[0063] For example, an interface 1 for requesting the allocation of physical addresses / physical pages, and the form of this interface 1 can be, for example:

[0064] Fn kern_miri_alloc_pages(paddr:usize,count:usize)

[0065] The above interface 1 is used to notify KernMiri to allocate count memory pages at the address paddr.

[0066] The above interfaces can also include multiple interfaces related to the read / write, release, and status change functions of physical pages; interfaces related to thread management, and other underlying operation functions involved in the OS kernel.

[0067] To support the operation of physical memory in Rust OS, the address management module 23 is adopted in KernMiri to replace the original virtual address module 13. By simulating the physical memory system and implementing a paging system, the address management module 23 maintains target data related to the use of physical pages, enabling KernMiri to correctly interpret various operations in the OS that involve physical memory addresses.

[0068] Specifically, the address management module 23 can simulate the physical memory required by the OS and maintain a data structure regarding the status of each physical page. It can be understood that when KernMiri starts running, it can apply for and obtain a large block of memory. The address management module 23 can simulate all or part of this physical memory as individual physical pages for Rust OS to use as the physical memory for interpreting and executing the OS. The use and operation of the physical memory by the OS will ultimately be reflected on the corresponding physical pages. Therefore, the address management module 23 maintains a data structure regarding the usage status of physical pages to ensure the correctness of the OS's interpretation and execution. Generally speaking, there are the following several states for the OS's use of physical pages:

[0069] The Reserved state indicates a physical page reserved for the system and cannot be used.

[0070] The Free state represents a physical page that has not been allocated; in the context of the OS's use, it specifically refers to a physical page that has not been allocated to the OS.

[0071] The Untyped state indicates a physical page that has been allocated (in the context of the OS, allocated to the OS) but has not been specified for a specific use or data type. The process of specifying the specific use or data type of a physical page can be called typing. Correspondingly, the Untyped state can also be called the untyped state.

[0072] The Typed state represents a physical page for which a specific use or data type has been specified, such as being split into several equal-sized slots, with each slot serving as a Rust memory object, or using a physical page as a stack. This state is also called the typed state.

[0073] In addition, the address management module 23 further includes a paging system to implement the setting and management of page tables. Specifically, in one example, the address management module 23 can maintain an abstraction of a simple four-level page table, supporting basic page table entry markers such as read, write, and large pages. When starting the detection of Rust OS and beginning to interpret and execute the OS, the address management module 23 can initialize the root-stage page table before the execution starts, and at the same time, the interface provided by the shim layer 22 allows the OS to set the page table in physical memory by itself during runtime. In this way, KernMiri has a paging mechanism during the interpretive execution stage, and the corresponding address access process can include the process of accessing based on the virtual address and finding the corresponding physical address through the page table, thereby simulating the real underlying operations in the kernel.

[0074] Intuitively, as Figure 2 shown on the right, the management of memory addresses by the address management module 23 involves the physical page and physical address levels. Different from Figure 1 the management of virtual addresses only in a linear single virtual space shown in, the address management module 23 simulates the management of a section of real physical memory and maintains the mapping between physical addresses and virtual addresses through the page table. Each memory object can be allocated and stored in different sections of the physical memory according to the real physical memory allocation principle. For example, different types of memory objects shown by different background blocks are each allocated a continuous physical memory space to simulate the real storage scenario. The address management module 23 realizes the simulated management of the physical address space by maintaining the usage status of each physical page and maintaining the page table.

[0075] The memory operation module 24 can reuse the existing memory operation module 14, except that the address management data it is based on is different when performing memory operations.

[0076] The checking module 25 can be extended on the basis of reusing the checking logic in the existing checking module 15. Specifically, the checking module 25 includes a language UB checking sub-module and an environment UB checking sub-module. Among them, the language UB checking sub-module follows the Rust language UB checking function in the original checking module 15, while the environment UB checking sub-module is used to check for UB caused by the error of the program execution environment due to the destruction of certain states of the OS. Execution environment errors can include, for example, page table mapping errors, physical page status management errors, thread scheduling errors, etc. These errors in the execution environment will also cause UB to occur. This type of UB behavior is not generated by the Rust language itself and cannot be detected by the language UB checking.

[0077] Optionally, in one embodiment, KernMiri further includes a thread simulation module 26 for simulating thread scheduling on the CPU. It should be noted that Miri also has a thread system internally, which interacts with Rust applications through a shim layer. Rust applications are unable to perceive the thread scheduling behavior of the running system, so Miri's thread system randomly switches threads when interpreting and executing MIR. However, different from ordinary Rust applications, Rust OS may control thread scheduling in the OS code. Therefore, in KernMiri, the shim layer 22 provides corresponding interfaces to enable the OS to interact with the thread simulation module 26. The thread simulation module 26 can simulate the thread operation on the CPU and perform thread switching and scheduling according to the code control of the OS code. In addition, the thread simulation module 26 can also simulate thread switching between multiple cores, thereby generating random thread switching to trigger the detection of concurrent UB.

[0078] The KernMiri proposed above can perform UB detection on Rust OS. For Rust OS, to utilize KernMiri for UB detection, it needs to support the architecture provided by KernMiri. Figure 3 Shows the operation of the Rust operating system in different architectures.

[0079] It can be understood that the test run of the operating system needs to be under a specific architecture. The system's various resource configurations are initialized through a bootloader, and then the startup program for the corresponding architecture is run. After initialization and the system state is stable, the tests are executed in sequence. For example, as Figure 3 In the conventional test mode shown on the left, the Rust operating system can be started and run on the x86 architecture or the riscv architecture. Generally, for the implementation of some functions of the operating system, specific implementations are carried out separately for each different architecture because these implementations often rely on the support of assembly code, such as the enabling operation of page tables and the memory initialization in the startup phase. Correspondingly, in Figure 3 the test mode shown on the left, some functions of the Rust operating system may have different implementations for x86 or riscv.

[0080] KernMiri can be regarded as a lightweight and minimalist pseudo-CPU architecture with MIR as its instruction set, which can be simply referred to as the Mirch architecture (MIR architecture). This architecture supports a simplified paging scheme and defines a direct startup protocol. The essence of the Mirch architecture is to replace some functions that the operating system needs to support with assembly by providing additional encapsulation interfaces through the shim layer of KernMiri. In this way, the Rust operating system can support Mirch in almost the same way as it supports a real CPU architecture. Specifically, for specific operations or functions in the kernel (such as allocating physical pages, setting the root page table, etc.), the Rust operating system can introduce the corresponding interface functions provided by the shim layer as the implementation of these functions under the Mirch architecture. When choosing to run the Rust OS on the Mirch architecture, when running or using the above functions, the functions are implemented in KernMiri by calling the interfaces provided by the shim layer.

[0081] Figure 3 The right side shows a schematic diagram of the Rust operating system running and testing in the Mirch architecture. In this example, the KernMiri tool itself is a program written and implemented in Rust, so it runs based on the Rust standard library. Based on the Mirch architecture startup program provided by KernMiri, the Rust operating system OS is started and run. On top of this, operating system test cases can be run, and these cases can test at least part of the OS code of the running operating system.

[0082] Based on the Rust operating system OS supporting the improved test tool KernMiri, the Rust OS can be interpreted and executed, and whether it contains UB behavior can be detected and found.

[0083] Figure 4 The method flow for detecting the Rust operating system OS according to an embodiment is shown. This method is executed using a detection tool, which (such as the aforementioned KernMiri) includes a shim layer, an address management module, a memory operation module, and an inspection module. The following combines Figure 4 , to describe the specific steps of the detection method.

[0084] As mentioned above, the shim layer of the detection tool provides several interfaces for the OS code to call, and these interfaces can provide the specific implementation of some basic and underlying operation functions for the OS. Correspondingly, the Rust OS that supports the Mirch architecture can call the corresponding interfaces provided by the shim layer when using a certain operation function. Memory operation is a basic operation in the operating system. Assume that the Rust OS calls an interface provided by the shim layer, hereinafter referred to as the first interface, to implement an operation related to physical memory.

[0085] Thus, in step S42, in response to the call of the OS code to the first interface, the shim layer converts it into a first instruction; or rather, the shim layer converts the call of the OS code to the first interface into a first instruction. The first interface is used to implement operations related to physical memory.

[0086] For example, in one example, the first interface can be the following interface 1, which is used to request the allocation of a specific physical address / physical page: Fn kern_miri_alloc_pages(paddr: usize, count: usize).

[0087] In another example, the first interface can be the following interface 2, which is used to release the physical pages of a specific physical address: fn kern_miri_dealloc_pages(paddr: usize, count: usize).

[0088] In yet another example, the first interface can be the following interface 3, which is used to type the physical pages of a specific physical address: fnkern_miri_type_pages(paddr: usize, count: usize, page_type: PageType).

[0089] In other examples, the first interface can be other interfaces provided by the shim layer that are related to the functions of physical memory operations, which will not be enumerated one by one here.

[0090] After receiving the call to the first interface, the shim layer, as an adaptation layer, converts the call into a first instruction. There are no restrictions on the form and content of the first instruction as long as it is an instruction that can be recognized inside the detection tool.

[0091] Next, in step S44, the memory operation module, in response to the above first instruction, performs a first operation based on the target data maintained by the address management module, where the target data is used to maintain the usage of physical pages in the target memory section.

[0092] As mentioned above, the address management module in the detection tool KernMiri maintains target data related to the usage of physical pages. The target memory section managed by the address management module is the physical memory section allocated when the detection tool starts. Correspondingly, the address management module can initialize the target data when starting the detection.

[0093] Further, in one embodiment, the target data may include a data structure for maintaining the usage status of physical pages, where the usage status of physical pages includes: a Reserved status indicating system reservation, a Free status indicating unallocated, an Untyped status indicating allocated but untyped, and a Typed status indicating allocated and typed. In one embodiment, the target data includes a page table. For example, the address management module may include a paging system and maintain a multi-level page table. The address management module may initialize the root page table in the multi-level page table during startup detection. Other levels of page tables can be used and set by the OS code as needed through the aforementioned interfaces.

[0094] The memory operation module performs a first operation related to physical pages based on such target data. The specific content of the first operation corresponds to the function implemented by the first interface.

[0095] In some examples, the first operation involves physical page status data, such as the following operations: modifying the usage status of the target physical page; typing an Untyped physical page; performing read, write, or copy operations on physical pages in a specified status; and so on.

[0096] In other examples, the first operation is based on the page table, such as the following operations: activating the page table, looking up page table entries, modifying page table entries; and so on.

[0097] In still other examples, the first operation may involve both physical page status data and the page table. For example, in the operation of allocating / releasing physical pages, it may be necessary to modify the usage status of the physical page and modify the mapping relationship of the physical page in the page table; and so on.

[0098] Correspondingly, in step S46, the checking module checks whether the above first operation involves a first behavior item related to physical page status errors to detect undefined behavior. Here, the first behavior item can be a behavior item predefined as an error in the execution environment caused by physical page status errors, and these behavior items will trigger UB behavior.

[0099] Specifically, the first behavior item may include the following error situations related to physical page status data: accessing a physical page in the Reserved or Free status; the conversion of the physical page usage status does not conform to the predetermined migration logic; typing a physical page in the Free status; repeatedly typing the same physical page; and so on. Further, the first behavior item may also include the following error situations related to both the page table and status data: a physical page in the Typed status belonging to the kernel mode is mapped to the user mode space in the page table; a physical page in the Typed status has multiple active mappings at the same time; and so on.

[0100] When the inspection module detects the above first item, it is determined that the OS code contains code that causes UB behavior.

[0101] As described above, in some embodiments, the detection tool further includes a thread simulation module for simulating the operation and scheduling of threads. At the same time, the interfaces provided by the shim layer include interfaces for controlling thread scheduling. Accordingly, the method for detecting UB in the Rust operating system may further include the process of detecting thread-related UB. Figure 5 The flowchart showing the detection of thread-related UB according to an embodiment is shown.

[0102] Assume that the Rust OS calls another interface of the shim layer, hereinafter referred to as the second interface, to implement an operation related to threads. Then, in step S52, the shim layer responds to the call of the second interface by the OS code and transforms it into a second instruction. Similar to the first instruction, the specific form of the second instruction is not limited here, as long as it is an instruction that can be recognized inside the detection tool. It can be understood that the second interface is related to thread scheduling.

[0103] For example, in one example, the second interface may be the following interface 4:

[0104] fn kern_miri_create_new_thread(func:fn(),thread_id:usize,stack_end_vaddr:usize,stack_size:usize)

[0105] The above interface 4 requests to create a thread for executing "func"; when creating the thread, the stack top virtual address stack_end_vaddr and stack size stack_size corresponding to the thread are also set.

[0106] In another example, the second interface may be the following interface 5:

[0107] fn kern_miri_switch_to(thread_id:usize)

[0108] The above interface 5 is used for thread switching, specifically for switching the thread to the thread with ID "thread_id".

[0109] In other examples, the second interface may be other interfaces provided by the shim layer with functions related to thread scheduling.

[0110] Correspondingly, in step S54, the thread simulation module performs a second operation, which includes performing operations related to thread scheduling corresponding to the second instruction to implement the thread control logic in the OS code. In addition, as mentioned above, the thread simulation module can also provide a certain degree of random switching to trigger concurrent UB detection.

[0111] Figure 6 The execution logic of the thread simulation module is shown. As shown in the figure, the thread simulation module associates threads with simulated CPUs to implement thread control in the OS code. Specifically, the thread simulation module can initialize a number of simulated CPUs and create corresponding threads in response to interface calls from the shim layer or according to the needs of the detection tool. The initialized threads are correspondingly bound to the simulated CPUs, for example, having the same id. Subsequently, the thread simulation module can create new threads according to the calls of the OS code to the corresponding interfaces, such as the call to interface 4. Each thread is assigned to each simulated CPU for execution. Here, a CPU in the context refers to a CPU core. A CPU will bind a thread at each moment. The thread switch on the same CPU will only occur when the corresponding thread switch logic in the OS code is interpreted and executed.

[0112] In one example, the second interface called by the OS code is used for thread switching. At this time, the thread simulation module responds to the second instruction for this interface conversion and switches the first thread currently executing on the first CPU to the second thread. For example, as shown in the figure, it switches the thread 1A on CPU1 to thread 1B. More specifically, the OS code can specify the thread ID of the target thread to be switched through, for example, the above-mentioned interface 5. The thread simulation module determines the simulated CPU that will execute the target thread, that is, CPU1, suspends the thread 1A currently executing on it, and instead executes thread 1B, that is, the target thread.

[0113] In addition, to simulate the situation of thread concurrency, as Figure 6 shown, the thread simulation module can also randomly switch between multiple CPUs with a certain probability when interpreting and executing the OS code, so as to achieve the original thread random switching effect of Miri to detect UB caused by thread competition or concurrency. Reflected in Figure 5 the execution process, that is, the second operation performed by the thread simulation module can also include switching the thread on the first CPU to the thread on the second CPU randomly determined according to a preset probability.

[0114] Back to Figure 5 . In the subsequent step S56, the check module checks whether the second operation involves a second behavior item related to thread scheduling errors to detect undefined behavior. Here, the second behavior item can be a behavior item that is predefined and causes the execution environment to go wrong due to thread scheduling errors, and these behavior items will also trigger UB behavior.

[0115] Specifically, the second type of item for behavior may include the following situations: a thread that has exited is scheduled again; a single thread is scheduled to multiple CPUs simultaneously, and so on. When the checking module detects the above-mentioned second type of item for behavior, it is determined that the OS code contains code that causes UB behavior.

[0116] Looking back at the above, through Figure 2 the improved detection tool shown, using at least Figure 4 the detection methods, effective and comprehensive dynamic UB detection can be performed on the Rust operating system. The above detection tool is extended based on the existing dynamic UB detection tool Miri, inheriting the good usability of Miri while maintaining compatibility. For an OS with a fast iteration speed, as long as sufficient test cases are ensured and the OS is comprehensively covered, comprehensive UB detection can be performed in a very short time. Compared with the existing Miri tool, the improved detection tool KernMiri supports an address management system that is more suitable for the OS. Specifically, a data structure for maintaining the usage of physical pages is introduced to support the memory operation requirements of the OS kernel. KernMiri also overcomes the problem that Miri cannot interpret and execute OS programs through the extension of the shim layer. At the same time, in terms of UB checking, in addition to language UB, UB checking related to the system environment is also extended, and it has a stronger reliability detection ability for the OS.

[0117] On the other hand, corresponding to the above method process, an embodiment of this specification also provides a detection device for detecting the Rust operating system OS. This detection device can be understood as Figure 2 the device implementation of the detection tool shown. This detection device includes a shim layer, an address management module, a memory operation module, and a checking module; the shim layer provides several interfaces. And, in this detection device:

[0118] The shim layer is configured to convert the call of the OS code to the first interface among several interfaces into a first instruction; the first interface is used to implement operations related to physical memory;

[0119] The address management module is configured to maintain target data, and the target data is used to maintain the usage of physical pages in the target memory section;

[0120] The memory operation module is configured to, in response to the first instruction, perform a first operation based on the target data;

[0121] The checking module is configured to check whether the first operation involves a first type of item for behavior related to physical page state errors to detect undefined behavior.

[0122] Further, in one implementation, the above detection device further includes a thread simulation module; and,

[0123] The above gasket layer is further configured to convert the call of the OS code to the second interface into a second instruction; the second interface is related to thread scheduling;

[0124] The thread simulation module is configured to perform a second operation, and the second operation includes performing operations related to thread scheduling corresponding to the second instruction;

[0125] The checking module is further configured to check whether the second operation involves a second behavior item related to thread scheduling errors to detect undefined behaviors.

[0126] For an example of the specific execution process of the detection device, reference may be made to the descriptions in combination with Figure 2 and Figure 4 before, which will not be repeated here.

[0127] According to an embodiment of still another aspect, there is also provided a computer-readable storage medium, on which a computer program is stored. When the computer program is executed in a computer, the computer is made to execute the method described above in combination with Figure 4 the description.

[0128] According to an embodiment of yet another aspect, there is also provided a computing device, including a memory and a processor. Among them, an executable code is stored in the memory, and when the processor executes the executable code, the method described above in combination with Figure 4 the description is implemented.

[0129] Those skilled in the art should be able to realize that in the above one or more examples, the functions described in the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0130] The specific embodiments described above further elaborate on the purpose, technical solutions, and beneficial effects of the present invention. It should be understood that the above is only the specific embodiments of the present invention and is not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for detecting the Rust operating system OS, the method is executed using a detection tool, the detection tool includes a shim layer, an address management module, a memory operation module, and an inspection module; The gasket layer provides a number of interfaces; the method includes: The gasket layer converts a call by the OS code to a first interface among the number of interfaces into a first instruction; the first interface is used to implement operations related to physical memory; The memory operation module responds to the first instruction and performs a first operation based on the target data maintained by the address management module, where the target data is used to maintain the usage of physical pages in a target memory section; The check module checks whether the first operation involves a first behavior item related to a physical page state error to detect undefined behavior.

2. The method according to claim 1, wherein, The target data includes a first data structure for maintaining the usage status of physical pages; the usage status includes: a Reserved state indicating system reservation, a Free state indicating unallocated, an Untyped state indicating allocated but not typed, and a Typed state indicating allocated and typed.

3. The method according to claim 2, wherein, The first operation includes at least one of the following: Modify the usage status of the target physical page; Type an Untyped state physical page; Perform a read operation, a write operation, or a copy operation on a physical page in a specified state.

4. The method according to claim 1, wherein, The target data includes a page table; the first operation includes one or more of the following: activate the page table, look up a page table entry, modify a page table entry.

5. The method according to claim 2, wherein The first behavior item includes at least one of the following: Access a physical page in the Reserved state or the Free state; The conversion of the physical page usage status does not conform to the predetermined migration logic; Type a Free state physical page; Type the same physical page repeatedly.

6. The method according to claim 5, wherein, The target data further includes a page table; the first behavior item further includes at least one of the following: A physical page in the Typed state belonging to the kernel mode is mapped to the user mode space in the page table; A Typed state physical page has multiple active mappings at the same time.

7. The method according to claim 1, wherein The target memory section is a physical memory section allocated and obtained when the detection tool is started; the method further includes: The address management module initializes the target data when starting the detection.

8. The method according to claim 7, wherein The target data includes a multi-level page table, and initializing the target data, includes initializing the root page table in the multi-level page table.

9. The method according to claim 1, wherein The number of interfaces further includes a second interface; the detection tool further includes a thread simulation module, and the method further includes: The gasket layer converts a call by the OS code to the second interface into a second instruction; the second interface is related to thread scheduling; The thread simulation module performs a second operation, and the second operation includes performing thread scheduling related operations corresponding to the second instruction; The check module checks whether the second operation involves a second behavior item related to thread scheduling error to detect undefined behavior.

10. The method according to claim 9, wherein, The second interface is used for thread switching; the thread scheduling related operations corresponding to performing the second instruction include: switching the first thread currently executing on the first CPU to the second thread.

11. The method according to claim 9, wherein, The second operation further includes: With a preset probability, switch the thread on the first CPU to a thread on a randomly determined second CPU.

12. The method according to claim 9, wherein The second behavior item includes at least one of the following: A thread that has exited is scheduled again; A single thread is simultaneously scheduled to multiple CPUs.

13. The method according to claim 9 further includes: The thread simulation module initializes a number of simulated CPUs and a number of threads.

14. The method according to claim 1, wherein, The OS code is the Middle-Level Intermediate Representation (MIR) code obtained by compiling the Rust source code of the Rust operating system.

15. The method according to claim 1, wherein The detection tool is written in the Rust language and implemented based on the Rust standard library.

16. A detection device for detecting a Rust operating system OS, the detection device includes a shim layer, an address management module, a memory operation module, and an inspection module; the shim layer provides a number of interfaces; wherein: The shim layer is used to convert the call of the OS code to the first interface among the number of interfaces into a first instruction; the first interface is used to implement operations related to physical memory. The address management module is used to maintain target data, and the target data is used to maintain the use of physical pages in the target memory section. The memory operation module is used to execute a first operation based on the target data in response to the first instruction. The inspection module is used to check whether the first operation involves a first behavior item related to a physical page state error to detect undefined behavior.

17. The detection device according to claim 16 further includes a thread simulation module; and The shim layer is further used to convert the call of the OS code to the second interface into a second instruction; the second interface is related to thread scheduling. The thread simulation module is used to execute a second operation, and the second operation includes executing the thread scheduling related operation corresponding to the second instruction. The inspection module is further used to check whether the second operation involves a second behavior item related to a thread scheduling error to detect undefined behavior.

18. A computer-readable storage medium, on which a computer program is stored. When the computer program is executed in a computer, the computer is made to execute the method according to any one of claims 1-15.

19. A computing device, comprising a memory and a processor, characterized in that, An executable code is stored in the memory. When the processor executes the executable code, the method according to any one of claims 1-15 is implemented.

Images