CN118410493A - Kernel security reinforcement system - Google Patents
Kernel security reinforcement system Download PDFInfo
- Publication number
- CN118410493A CN118410493A CN202410313131.9A CN202410313131A CN118410493A CN 118410493 A CN118410493 A CN 118410493A CN 202410313131 A CN202410313131 A CN 202410313131A CN 118410493 A CN118410493 A CN 118410493A
- Authority
- CN
- China
- Prior art keywords
- tee
- kernel
- operating system
- measurement
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000002787 reinforcement Effects 0.000 title claims abstract description 19
- 230000003993 interaction Effects 0.000 claims abstract description 3
- 238000005259 measurement Methods 0.000 claims description 75
- 230000006870 function Effects 0.000 claims description 17
- 238000000034 method Methods 0.000 claims description 15
- 230000008569 process Effects 0.000 claims description 12
- 238000012795 verification Methods 0.000 claims description 7
- 238000005516 engineering process Methods 0.000 claims description 6
- 238000002955 isolation Methods 0.000 claims description 5
- 238000012545 processing Methods 0.000 claims description 5
- 230000005540 biological transmission Effects 0.000 claims description 3
- 238000013507 mapping Methods 0.000 claims description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- ZXQYGBMAQZUVMI-GCMPRSNUSA-N gamma-cyhalothrin Chemical compound CC1(C)[C@@H](\C=C(/Cl)C(F)(F)F)[C@H]1C(=O)O[C@H](C#N)C1=CC=CC(OC=2C=CC=CC=2)=C1 ZXQYGBMAQZUVMI-GCMPRSNUSA-N 0.000 description 1
- 230000017525 heat dissipation Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000000691 measurement method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000035515 penetration Effects 0.000 description 1
- 230000003014 reinforcing effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/575—Secure boot
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The kernel security reinforcement system comprises a TEE side and a REE side, wherein the TEE side runs a trusted execution environment TEE, and the REE side runs a general operating system environment REE; a TEE-OS operating system and a TA program running under the TEE-OS operating system are running in the trusted execution environment TEE; the general operating system environment REE runs a general operating system guided by uboot and a TEE driver, and the TEE driver is used as an important interaction channel between the REE side and the TEE side and is responsible for communicating between the REE side and the TEE side. The invention can prevent the inner core file and important parameters from being tampered, thereby realizing the inner core safety reinforcement.
Description
Technical Field
The invention relates to the technical field of kernel safety protection, in particular to a kernel safety reinforcing system.
Background
Operating system security is the basis for computer security, while kernel integrity protection is an important precondition for operating system security.
With the development of software technology, the functions of an operating system are more and more abundant, the kernel functions and the code quantity of the Linux operating system are increased explosively, and the safety problem is also increased. Because of the complexity, security hole, security mechanism of the operating system are easily bypassed, weak isolation among application programs and security threat of Root, virus, trojan horse and the like, confidentiality and integrity of confidential data and common user data cannot be guaranteed by storing the confidential data and the common user data in the same operating system. For this reason, the industry has proposed TEE (Trusted Execution Environment) a trusted execution environment design that builds an operating system TEE that runs specifically for high security applications, in addition to the current conventional operating system REE (Rich Execution Environment). A Trusted Execution Environment (TEE) is a secure area within a host processor. It runs in a stand-alone environment and in parallel with the operating system. It ensures that both the confidentiality and integrity of code and data loaded in the TEE are protected. By protecting data and code using both hardware and software, this parallel system is safer than conventional systems (i.e., REEs, i.e., rich execution environments). The integrity measurement of the kernel is realized based on the trusted execution environment, the security of the system is enhanced, and a trust basis is provided for constructing a safe and trusted computing environment for upper software.
The current common kernel integrity measurement scheme has a trusted starting scheme based on tpm/tcm, and in a trusted 2.0 architecture established based on TCM (trusted cryptography module), a trusted base component is designed to work in a passive mode in a hardware isolation environment for a host CPU to carry out service call. The traditional TPM/TCM also has various problems in application, and the performance is generally low due to the adoption of the cheap chip, and the physical chip has many adverse factors in various aspects such as cost, power consumption, heat dissipation and the like, so that the chip package is not easy to upgrade and maintain. A TEE environment realized by TrustZone technology based on an ARM processor can provide a runtime environment isolated from other software and hardware resources of a computing platform. The TrustZone technology is designed to obtain control right preferentially after the system is powered up, has higher access and control rights than a host, and is a kernel integrity measurement method based on the control right, and has higher safety and higher advantages in terms of cost and upgrade maintainability.
Disclosure of Invention
In order to solve the defects existing in the prior art, the invention provides a kernel security reinforcement system, which comprises a TEE side and a REE side, wherein the TEE side runs a Trusted Execution Environment (TEE), and the REE side runs a general operating system environment (REE); a TEE-OS operating system and a TA program running under the TEE-OS operating system are running in the trusted execution environment TEE; the general operating system environment REE runs a general operating system guided by uboot and a TEE driver, and the TEE driver is used as an important interaction channel between the REE side and the TEE side and is responsible for communicating between the REE side and the TEE side.
The method comprises the steps that the TEE side ensures the data safety of an internal environment of a processor through a hardware level isolation technology of the processor, a TA program provides data safety storage and a measurement interface function, a measurement interface is realized based on an SM3 algorithm, when uboot is started for the first time, the TA program calculates a hash value of a kernel image file through the SM3 algorithm and is used as a reference value for safety storage, when uboot is restarted, the restarted value is compared with the stored reference value, a measurement success result is returned when the comparison is consistent, the uboot is allowed to normally load the kernel and start a general operating system, a measurement failure result is returned when the comparison is inconsistent, and loading of the kernel and starting of the general operating system are stopped.
When the TEE driver is initialized, verification of the TEE-OS version is completed, configuration of a shared memory of the TEE driver and the TEE-OS is obtained, and address mapping of the shared memory is established.
The kernel security reinforcement system realizes the kernel integrity measurement through the following steps:
Step S1: the TEE driver packages the data of the SMC request instruction, and finally, the data is switched to a monitor mode by sending a SMC instruction so as to facilitate the subsequent transmission of the kernel integrity measurement data to a TA program at the TEE side for processing;
Step S2: after the uboot loading kernel images to the memory, a measurement interface provided by a TA program of the TEE-OS operating system is called to measure the integrity of the kernel.
In the step S2, the step of calling a measurement interface provided by a TA program of the TEE-OS operating system to measure the integrity of the kernel includes the following steps:
step S41: invoking a TEE driver to query trusted boot settings:
if the trusted starting function is closed, ending, directly loading the kernel and starting the general operating system;
If the trusted start function is turned on, step S42 is performed;
step S42: judging whether all measurement items are measured to be completed:
if all the processing steps are completed, setting an end interface for starting a measurement stage, ending, judging whether to load a kernel and starting a general operating system based on a measurement result;
If not, acquiring the measurement item data one by one and calling the measurement interface to measure the integrity of the kernel, if all the measurement items are measured successfully, loading the kernel normally and starting the general operating system, and if any measurement item fails, ending the starting flow.
In the step S42, in the process of acquiring and measuring the measurement item data one by one, the TEE driver transmits the measurement item data to the TA program execution kernel mirror image integrity measurement of the TEE-OS operating system in a shared memory manner, the TEE-OS operating system monitors the transmitted data, finds the corresponding TA program, the TA program completes the measurement operation or the data secure storage operation of the data in the trusted execution environment TEE and returns the result to the TEE driver, and the TEE driver judges whether to load the kernel and start the general operating system according to the measurement result returned by the TEE side.
The invention can prevent the inner core file and important parameters from being tampered, thereby realizing the inner core safety reinforcement.
Drawings
Fig. 1: the invention relates to a logic framework diagram of a kernel security reinforcement system.
Fig. 2: the invention relates to a flow chart for realizing the measurement of the integrity of a kernel.
Detailed Description
In order to further understand the technical scheme and beneficial effects of the present invention, the technical scheme and beneficial effects thereof will be described in detail with reference to the accompanying drawings.
In order to resist the tamper attack to the kernel file, the invention develops a TA program in the trusted execution environment TEE based on the trusted execution environment TEE, and the TA program realizes the safe storage of a reference value and provides a measurement interface, so that the integrity measurement (particularly relating to measuring the mirror image size of the kernel, the starting address of the kernel in a memory, the starting parameters of the kernel and the like) of the kernel of the general operating system is carried out in the general operating system environment REE by calling the measurement interface in the process of guiding the starting of the general operating system by the uboot, and the kernel of the general operating system is ensured to be tampered based on the stored reference value, if the measurement is successful, the uboot is allowed to normally load the kernel and start the general operating system, and the loading of the kernel and the starting of the general operating system are stopped when the measurement is failed, so that the kernel file and the important parameters are prevented from being tampered, and the kernel security reinforcement is realized.
FIG. 1 is a diagram of a logical framework of a kernel security reinforcement system provided by the present invention, as shown in FIG. 1, where the present invention includes a TEE side running a Trusted Execution Environment (TEE) and a REE side running a general Operating System (OS) environment (REE); a TEE-OS operating system and a TA program running under the TEE-OS operating system are running in the trusted execution environment TEE; a general operating system (started by uboot boot) and a TEE driver are operated in a general operating system environment (REE), and the TEE driver is used as an important interactive channel between a REE side and a TEE side and is responsible for opening communication between the REE side and the TEE side, so that the switching from an unsafe state to a safe state is realized, and the trusted measurement function is realized.
When the TrustZone technology is supported, each processor core can be virtualized into two virtual cores in running, one is a safety core, the other is a common core, the safety core executes safety codes, the common core executes the common codes, the common operating system runs on the common core, the TEE-OS operating system runs on the safety core, the safety core can obtain the access authority of all resources, the common core can only access the resources of the common system, and can only obtain specific data in the TEE side and call specific functions (functions provided by TA programs) through a client interface which is defined in advance.
The kernel security reinforcement system provided by the invention realizes the complete process and mechanism of the kernel security reinforcement as follows:
1. Running TEE-OS operating system and developing TA program
The TEE-OS operating system runs in a trusted execution environment TEE, and the hardware level isolation technology of the processor ensures the data security of the TEE-OS, so that key data storage or other operations need to be executed in the TEE-OS, and the TA program is developed and realized in the TEE-OS, and realizes two functions:
(1) Secure storage of data
The TA program stores the key data in the safe storage device, so that the key data can be ensured to be accessed only at the TEE side;
(2) Implementing a metrology interface
The measurement interface is realized based on an SM3 algorithm, when uboot is started for the first time, a TA program calculates a hash value of a kernel image file (particularly relates to calculation of the size of the kernel image file, a starting address of the kernel in a memory, a kernel starting parameter and the like) through the SM3 algorithm and is used as a reference value for safe storage, when uboot is restarted, the restarted value is compared with the stored reference value, a measurement success result is returned when the comparison is consistent, the uboot is allowed to normally load the kernel and start a general operating system, a measurement failure result is returned when the comparison is inconsistent, and loading of the kernel and starting of the general operating system are stopped.
In the present invention, the TEE-OS refers broadly to an operating system running in a trusted execution environment, and each manufacturer and organization has respective implementation modes, but external interfaces of all schemes conform to the GP (Global Platform) standard.
2. Initializing TEE drivers on REE side
The step mainly completes the verification of the TEE-OS version, obtains the configuration of the shared memory of the TEE driver and the TEE-OS, establishes the address mapping of the shared memory, and the like.
And then, realizing a TEE driver under uboot, packaging data of SMC request instructions, and finally switching to monitor mode by sending out SMC instructions so as to facilitate the subsequent transmission of kernel integrity measurement data to a TA program at the TEE side for processing.
Penetration of the normal world (the world where the REE side is located) into the secure world (the world where the TEE side is located) is achieved by setting the security status bit (NS bit) in the SCR register in monitor mode or EL 3. SCR is a hardware register that the REE side operating system does not have access to, and can only operate in a secure state: in the unsafe state, the REE side operating system is switched to the safe state through a smc instruction, and in the safe state, the NS bit of the SCR is written to 1, and the REE side operating system is switched to the unsafe state again.
SMC (Secure Monitor Call) is an instruction of the ARM platform that the SMC instruction will generate an exception into EL3, while EL3 will never be implemented in the Non-secure state (i.e., the "unsafe state" above). The system can naturally be put into a security monitoring mode (i.e., monitor mode above), in which the non-security state context is backed up first, then the security state privileged mode is entered, the running environment is the security state TEE-OS, and the underlying security services and TA programs in the TEE-OS are executed. ARMv8 defines four anomaly levels EL3, EL2, EL1, EL0 from high to low, respectively. EL3 has the highest management authority and is responsible for security monitoring and security mode switching. EL2 mainly provides support for virtualization. EL1 is a privileged mode capable of executing privileged instructions for running various operating systems and is a trusted OS in secure mode. EL0 is an unprivileged mode, with all APP applications being in EL0.
3. Booting a general purpose operating system and kernel integrity metrics
The u-boot is a bootloader running in the unsafe world and is responsible for loading various operating systems. The normal starting flow of the operating system is to load the kernel mirror image to the memory through uboot and transmit parameters such as the address of the root file system to the kernel, then run the kernel program, mount the root file system and start the operating system after the kernel is started.
As described above, when the TEE driver is implemented under uboot, the smc instruction is triggered to switch to Monitor mode or EL3, so after the TEE driver is implemented, after the uboot loads the kernel image into the memory, the measurement interface provided by the TA program of the TEE-OS operating system is called to measure the integrity of the kernel.
FIG. 2 is a flow chart of the implementation of the kernel integrity metric, as shown in FIG. 2, after the initialization of the TEE driver of uboot is completed, continuing the uboot start-up flow, and after loading the kernel into the memory, calling the TEE driver to query the trusted start-up settings:
If the trusted starting function is closed, the trusted measurement process is skipped to directly load the kernel and the general operating system is started;
If the trusted starting function is started, the TEE driver is continuously called to perform trusted measurement, whether all measurement items are measured is judged to be completed or not, if the measurement items are all completed, a starting measurement stage ending interface is set, if the measurement items are not completed, measurement item data are acquired one by one and the measurement interface is called to perform kernel integrity measurement, if the measurement is successful, the next item is measured until a general operating system is started after all the measurement items are completed, if any item of the measurement items fails, blocking is performed, in the process of acquiring and measuring the measurement items one by one, the TEE driver transmits data (such as the starting address of a kernel in a memory, the size of a kernel mirror image, the starting parameter of the kernel and the like) related to each measurement item to the TA program of the TEE-OS operating system to perform the integrity measurement of the kernel mirror image, the TEE-OS operating system monitors the transmitted data, the corresponding TA program is found, and the TA program completes measurement operation of the data or data security storage operation in the trusted execution environment TEE and returns a result to the TEE driver. And the TEE driver judges whether to load the kernel and start the general operating system according to the measurement result returned by the TEE side. And if all the measurement items are successful, the kernel is normally loaded and the general operating system is started, and if any measurement item fails, the starting flow is terminated.
The metric term may be increased by user definition according to the requirement, for example, the metric of the key file of the system may be increased, but the starting address in the memory of the kernel, the size of the kernel mirror, i.e. the kernel start-up parameter, are the necessary metric terms. In the actual operation process, the TA program is packed and compiled into the TEE-OS operating system image, and is packed together with the uboot image (the TEE driver is contained in the ubbot image) to generate a trusted firmware bin file, and the trusted firmware bin file is programmed into the BIOS chip. After the programming is completed, the hardware equipment has a safety starting function, namely a safety starting process from the power-on starting to the entering of the universal system login interface of the hardware, wherein the safety starting (Secure Boot) function is a guiding process of verifying the reliability of important mirror image files in the system by using a chain type verification electronic signature mode in the whole starting process of the system and then loading the mirror image files. The initialization and the starting of the TEE environment are completed in a bl32 stage, the measurement process of the uboot kernel is completed in a bl33 stage, which is mentioned below, and uboot is used as the last-stage mirror image in a starting chain and is used for starting the final general-purpose operating system mirror image.
The secure boot functionality may protect the independence and integrity of the secondary vendor system. ARM provides ARM Trusted Firmware (ATF), the trusted firmware bin file mentioned above, in the ARMv8 architecture, which is the underlying firmware provided by the ARM authorities that unifies ARM underlying interface standards such as power state control interfaces (Power Status Control Interface, PSCI), secure boot requirements (Trusted Board Boot Requirements, TBBR), secure World State (SWS) and Normal World State (NWS) switching secure monitoring mode call (secure monitor call, smc) operations, and the like.
The source code implementation of the ATF is divided into parts bl1, bl2, bl31, bl32, bl33, wherein the parts bl1, bl2, bl31 belong to fixed firmware, and bl32 and bl33 are used to load the mirror images of the TEE side and the REE side, respectively. The whole loading process can be configured in a safe starting mode, and each image file can verify whether the signature of the image file is legal or not before being loaded. Starting bl1, bl2, bl31 and bl32 is a complete ATF trust chain establishment flow, and bl33 is unsecure firmware, namely uboot and linux kernel which are common to us, and the function realized by the invention is to increase the trusted measurement to the starting of kernel images in the stage of bl33, so that the trusted starting of an operating system is realized.
ARM authorities divide the start-up into the stages of bl1, bl2, bl31, bl32, and bl33, and according to the sequence, after the chip starts up, the bl1 stage code is executed first, then the label is checked to start up bl2, bl2 starts up either bl31 or bl33 according to the specific design (the system does not support trust, and then no bl31 and bl32 exist), and bl32 can only exist when bl31 exists and is checked to load up.
Bl1: is a root of trust, generally a section of boot loading code solidified in ROM (Read-Only Memory) is used for guiding bl2, and carrying out signature verification on bl2 to ensure trusted execution;
bl2: the method is characterized in that a section of trusted safety starting code in flash is generally established in bl1 for verification, and related initialization of some platforms, such as initialization of memory hardware and the like, is mainly completed, and after initialization is completed, bl31 or bl33 is searched for and executed; if bl31 is found, no bl33 is continued to be called, if no bl31 is present, bl33 must be present;
bl31: unlike bl1 and bl2, which are run once, they exist as the last piece of trusted firmware, switching between the secure world and the non-secure world by smc (smc, described below) instructions at system run time; after the initialization of the bl31 is completed, searching for the bl32 or the bl33 for signature verification and loading and executing;
bl32: it is a trusted and secure OS (TEE-OS), and after the TEE-OS is operated, it returns bl31 through smc instruction, and bl31 is switched to the unsafe world to continue executing bl33;
bl33: unsecure firmware, i.e., UEFI firmware or u-boot, which is common to us.
As described above, when the system is burned, the kernel is measured at the first start-up, and the measured value is used as the reference value measured at the start-up of the subsequent general system.
The scheme disclosed by the invention can be suitable for embedded scenes.
Although the present invention has been described with reference to the above preferred embodiments, it should be understood that the present invention is not limited to the above embodiments, and that various changes and modifications can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (6)
1. A kernel security reinforcement system, characterized by: the method comprises a TEE side and a REE side, wherein the TEE side runs a Trusted Execution Environment (TEE), and the REE side runs a general operating system environment (REE); a TEE-OS operating system and a TA program running under the TEE-OS operating system are running in the trusted execution environment TEE; the general operating system environment REE runs a general operating system guided by uboot and a TEE driver, and the TEE driver is used as an important interaction channel between the REE side and the TEE side and is responsible for communicating between the REE side and the TEE side.
2. The kernel security reinforcement system of claim 1, wherein: the TEE side ensures the data safety of the internal environment through a hardware level isolation technology of the processor, the TA program provides the functions of data safety storage and a measurement interface, the measurement interface is realized based on an SM3 algorithm, when uboot is started for the first time, the TA program calculates a hash value of a kernel mirror image file through the SM3 algorithm and is used as a reference value for safety storage, when uboot is restarted, the restarted value is compared with the stored reference value, a measurement success result is returned when the comparison is consistent, the uboot is allowed to normally load the kernel and start a general operating system, a measurement failure result is returned when the comparison is inconsistent, and the loading of the kernel and the starting of the general operating system are stopped.
3. The kernel security reinforcement system of claim 2, wherein: and when the TEE driver is initialized, finishing verification of the TEE-OS version, acquiring configuration of the shared memory of the TEE driver and the TEE-OS, and establishing address mapping of the shared memory.
4. A core security reinforcement system as defined in claim 3, wherein: the kernel security reinforcement system realizes the kernel integrity measurement by the following steps:
Step S1: the TEE driver packages the data of the SMC request instruction, and finally, the data is switched to a monitor mode by sending a SMC instruction so as to facilitate the subsequent transmission of the kernel integrity measurement data to a TA program at the TEE side for processing;
Step S2: after the uboot loading kernel images to the memory, a measurement interface provided by a TA program of the TEE-OS operating system is called to measure the integrity of the kernel.
5. The kernel security reinforcement system as recited in claim 4 wherein: in the step S2, the step of calling the measurement interface provided by the TA program of the TEE-OS operating system to measure the integrity of the kernel includes the following steps:
step S41: invoking a TEE driver to query trusted boot settings:
if the trusted starting function is closed, ending, directly loading the kernel and starting the general operating system;
If the trusted start function is turned on, step S42 is performed;
step S42: judging whether all measurement items are measured to be completed:
if all the processing steps are completed, setting an end interface for starting a measurement stage, ending, judging whether to load a kernel and starting a general operating system based on a measurement result;
If not, acquiring the measurement item data one by one and calling the measurement interface to measure the integrity of the kernel, if all the measurement items are measured successfully, loading the kernel normally and starting the general operating system, and if any measurement item fails, ending the starting flow.
6. The kernel security reinforcement system as recited in claim 5 wherein: in the step S42, in the process of acquiring and measuring the measurement item data one by one, the TEE driver transmits the measurement item data to the TA program execution kernel mirror image integrity measurement of the TEE-OS operating system in a shared memory manner, the TEE-OS operating system monitors the transmitted data, finds the corresponding TA program, the TA program completes the measurement operation of the data or the data security storage operation in the trusted execution environment TEE and returns the result to the TEE driver, and the TEE driver judges whether to load the kernel and starts the general operating system according to the measurement result returned by the TEE side.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410313131.9A CN118410493A (en) | 2024-03-19 | 2024-03-19 | Kernel security reinforcement system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410313131.9A CN118410493A (en) | 2024-03-19 | 2024-03-19 | Kernel security reinforcement system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118410493A true CN118410493A (en) | 2024-07-30 |
Family
ID=92003818
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410313131.9A Pending CN118410493A (en) | 2024-03-19 | 2024-03-19 | Kernel security reinforcement system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118410493A (en) |
-
2024
- 2024-03-19 CN CN202410313131.9A patent/CN118410493A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10379888B2 (en) | Adaptive integrity verification of software and authorization of memory access | |
| US7937575B2 (en) | Information processing system, program product, and information processing method | |
| JP5512610B2 (en) | Method, system, and machine-readable storage medium for permitting or blocking access to memory from non-firmware agent | |
| US7921286B2 (en) | Computer initialization for secure kernel | |
| CN112800429B (en) | Method for protecting driver in UEFI BIOS firmware system based on basicity | |
| US9367671B1 (en) | Virtualization system with trusted root mode hypervisor and root mode VMM | |
| US9098300B2 (en) | Providing silicon integrated code for a system | |
| US8327415B2 (en) | Enabling byte-code based image isolation | |
| US20090328195A1 (en) | Authentication and Access Protection of Computer Boot Modules in Run-Time Environments | |
| US20090249053A1 (en) | Method and apparatus for sequential hypervisor invocation | |
| US20150135311A1 (en) | Virtual machine validation | |
| US7533101B2 (en) | Extensible loader | |
| KR20160043134A (en) | Authenticated launch of virtual machines and nested virtual machine managers | |
| WO2012139026A2 (en) | System and method for processing requests to alter system security databases and firmware stores in a unified extensible firmware interface-compliant computing device | |
| US7174447B2 (en) | Providing a pre-boot driver for use during operating system runtime of a computer system | |
| CN113448682B (en) | Virtual machine monitor loading method and device and electronic equipment | |
| EP3440586B1 (en) | Method for write-protecting boot code if boot sequence integrity check fails | |
| CN118410493A (en) | Kernel security reinforcement system | |
| US20070174600A1 (en) | Interface for communicating physical presence requests | |
| CN112988262B (en) | Method and device for starting application program on target platform | |
| WO2022093186A1 (en) | Code execution using trusted code record | |
| CN108595981B (en) | Method for encrypting android system | |
| Han et al. | DMSCTS: Dynamic measurement scheme for the containers-hybrid-deployment based on trusted subsystem | |
| CN117786672A (en) | Process protection method based on windows X86 expandability | |
| Parno et al. | How Do We Make Sense of Platform State? |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |