A method for upgrading based on a kernel vulnerability of a kylin system

Abstract

The application discloses a kind of based on kirin system kernel vulnerability upgrade method, it is related to operating system technical field, the application includes the following steps: whether it is x86_64, non then error termination process;Query current kernel package version, if matching vulnerability repair target version is prompted to complete and terminates;Determine SP version to match upgrade package, not support then error termination;Backup GRUB configuration according to start mode, record default kernel start item, pause key service and generate system state snapshot;Select the kernel package of corresponding SP version and execute installation, installation fails then trigger automatic rollback;Restart server, and the starting state is monitored by BMC, timeout / failure triggers hardware recovery, success then confirm kernel version;Verify kernel, service, system log etc., then complete upgrade;Failure then automatically rollback and verify rollback result.The application integrates automatic backup and rollback mechanism in kirin system kernel upgrade process, improves the security and reliability of system update.

Description

Technical Field

[0001] This invention belongs to the field of operating system technology, and in particular relates to a method for upgrading the Kylin system kernel based on vulnerabilities. Background Technology

[0002] Kylin OS, as a domestically developed core operating system, is widely used in industrial scenarios with stringent availability requirements, such as power dispatching. Server clusters in these scenarios need to operate 24 / 7 to ensure the continuity of critical services such as real-time load balancing and fault detection. To address the risks posed by known security vulnerabilities such as the Linux kernel netfilter: nf_tables component, kernel upgrades have become a necessary security hardening measure. However, the existing Kylin system kernel upgrade process has significant shortcomings—a lack of automated and systematic backup and rollback mechanisms. In practice, upgrade failures are common: incompatibility conflicts between the new kernel and hardware drivers, third-party security software, or business applications can cause system startup freezes, service crashes, or kernel module loading failures; upgrade anomalies can also occur due to incorrect upgrade package version identification or data corruption during installation. Once an upgrade fails, the existing process often relies on manual intervention for recovery. This not only makes it difficult to quickly rebuild GRUB configurations and roll back the kernel version, but also, due to the lack of prior backup of core configurations and service states, can lead to prolonged system downtime, directly causing interruptions to critical services such as power dispatching and resulting in severe losses in industrial scenarios. Therefore, the following solutions are proposed to address these issues. Summary of the Invention

[0003] The purpose of this invention is to provide a method for upgrading the system kernel based on the Kylin system. By integrating an automated backup and rollback mechanism into the Kylin system kernel upgrade process, the security and reliability of system updates are improved. This solves the problems of existing methods lacking automation, requiring manual intervention for recovery after failure, and being prone to interruption of critical business due to version incompatibility or configuration loss.

[0004] To solve the above-mentioned technical problems, the present invention is achieved through the following technical solution: This invention relates to an upgrade method based on a vulnerability in the Kylin system kernel. The upgrade method specifically includes the following steps: Step S1, Pre-configuration IPMI / BMC: Log in to the server BMC management interface, enable the automatic recovery function for startup failure, set the recovery policy to roll back to the previous valid startup item, configure the maximum number of automatic restarts, and verify the BMC network connectivity; Step S2, System Architecture Determination: Execute the system command used to obtain the server hardware architecture. If the architecture is x86_64, continue to the next step. If it is not x86_64, output an error message and terminate the process. Step S3, Kernel Version Verification: Execute the system command used to query the version of the currently installed kernel package, compare the query result with the target kernel version after the vulnerability is patched, output "Vulnerability has been patched" when a match is found and terminate the process, continue when no match is found; Step S4: Determine the SP version of the Kylin system: Execute the system command used to extract system version information, obtain the SP version identifier from the standard version configuration file of the Kylin system, execute the upgrade process corresponding to SP1 when the identifier is SP1, execute the upgrade process corresponding to SP2 when the identifier is SP2, and output an error message and terminate the process when neither is true. Step S5, System Status Backup: Based on the server boot mode (UEFI or BIOS), back up the GRUB boot configuration file under the corresponding path; execute the system command used to obtain the current default kernel boot item and write the result to the log file; suspend critical power dispatch services (including dispatch service and monitoring service) and record the state before the service is suspended; execute the system command used to save the list of currently loaded kernel modules and the current kernel package information to generate a system status snapshot; Step S6, Upgrade Package Installation: Enter the preset upgrade package directory, select the kernel RPM package group that matches the SP version, execute the system command for installing the kernel package, output the installation process log to the specified log file in real time, and terminate the installation immediately and trigger the subsequent rollback steps when an error occurs. Step S7, Server Reboot: Execute system commands to reboot the server, monitor the boot process through the BMC interface, trigger IPMI / BMC hardware-level recovery when boot times out or fails, and confirm and record the current running kernel version as the target version after successful boot. Step S8, Upgrade Result Verification and Rollback: The verification process is run automatically, including confirming kernel version matching, checking system logs for kernel errors, restoring and verifying the normal operation of critical power dispatch services; when all verification items pass, "Upgrade Successful" is output and the upgrade is completed; when any verification item fails, an automatic rollback is performed, which includes: restoring the GRUB boot configuration file in the corresponding boot mode, setting the old kernel as the default boot option, restarting the server, verifying the normal operation of the old kernel and the restoration of critical services after the rollback, and outputting "Rollback Successful".

[0005] Furthermore, in step S1, logging into the server BMC management interface specifically involves accessing the Web management interface via a pre-set BMC management IP address on the server.

[0006] Furthermore, the judgment logic for executing the system command for obtaining the server hardware architecture in step S2 is as follows: when the command output result is x86_64, it is determined to meet the architecture requirements; when the output is "aarch64" or "i386", it is determined to be a non-x86_64 architecture.

[0007] Furthermore, in step S3, executing the system command to query the currently installed kernel package version specifically involves querying all kernel-related packages installed in the system and filtering the results that contain kernel version identifiers. The target kernel version is the kernel version determined according to the official patch announcement for the Linuxkernelnetfilter:nf_tables component vulnerability.

[0008] Furthermore, in step S4, the standard version configuration file of the Kylin system is / etc / os-release. Specifically, executing the system command for extracting system version information involves filtering the content containing the "VERSION" field from this configuration file and determining the SP version by the identifier "SP1" or "SP2" in the field.

[0009] Furthermore, the method for determining the server boot mode in step S5 is as follows: check if the system has a directory for identifying UEFI boot; if it exists, it is determined to be in UEFI mode; otherwise, it is in BIOS mode. In UEFI mode, the GRUB boot configuration file path is / boot / efi / EFI / kylin / grub.cfg, and in BIOS mode, the path is / boot / grub2 / grub.cfg. The step of recording the state before the service is suspended specifically involves appending service status information to the log file.

[0010] Furthermore, in step S6, when executing the system command for installing the kernel package, parameters are added to force overwrite old version dependencies and ignore non-critical dependencies to ensure that the installation process is not blocked by unnecessary factors; the specified log file is / var / log / rpm_upgrade.log.

[0011] Furthermore, the timeout criterion in step S7 is that the server has not entered the normal system interface for more than 5 minutes after restarting, and the method to confirm the current running kernel version is to execute a system command used to view the current kernel version.

[0012] Furthermore, the recovery and verification of key power dispatch services in step S8 specifically includes: sequentially starting the dispatch service and monitoring service, executing system commands to view the service running status, confirming that the service status is "active (running)," and triggering a simulated dispatch task to verify that the service function is normal; the checking of the system log specifically involves querying the system log file to see if there are error messages containing "kernelerror" or "fail."

[0013] Furthermore, the method for setting the old kernel as the default boot option in step S8 is as follows: read the old kernel boot option identifier from the log file recorded in step S5, and execute the system command used to set the default boot option. The old kernel boot option identifier is the boot option name corresponding to the Kylin system, and the format is "KylinLinuxAdvancedServer (old kernel version) system main version". Step S8, verifying the normal operation of the old kernel and the recovery of critical services after the rollback, specifically includes: executing a system command to check the current kernel version and confirming that the version is the old kernel before the upgrade; executing a system command to check the service status and confirming that the scheduling service and monitoring service are running normally; and checking the system logs for any kernel abnormality information.

[0014] The present invention has the following beneficial effects: This invention improves the security and reliability of system updates by integrating automated backup and rollback mechanisms into the Kylin system kernel upgrade process. It reduces the risk of system service interruptions due to upgrade failures or version incompatibility, ensuring the continuity of critical business operations. Automated preprocessing and state saving reduce the need for manual intervention and the possibility of operational errors. Proactively backing up core configurations and service states during the upgrade process allows the system to quickly recover to a stable version in abnormal situations, enhancing overall fault tolerance and operational efficiency. Simultaneously, this process balances the timeliness of vulnerability patching with the stability of system operation, making it suitable for industrial scenarios with stringent availability requirements, achieving an effective balance between security hardening and operational assurance.

[0015] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the overall process of a method for upgrading a Kylin system kernel vulnerability according to the present invention; Figure 2 This is a schematic diagram of the logical flow of a method for upgrading the kernel vulnerability of the Kylin system according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Please see Figure 1-2 As shown, this invention is an upgrade method based on a vulnerability in the Kylin system kernel. The upgrade method includes: Step S1, Pre-configuration IPMI / BMC: Log in to the server BMC management interface, enable the automatic recovery function for startup failure, set the recovery policy to roll back to the previous valid startup item, configure the maximum number of automatic restarts, and verify the BMC network connectivity; Step S2, System Architecture Determination: Execute the system command used to obtain the server hardware architecture. If the architecture is x86_64, continue to the next step. If it is not x86_64, output an error message and terminate the process. Step S3, Kernel Version Verification: Execute the system command used to query the version of the currently installed kernel package, compare the query result with the target kernel version after the vulnerability is patched, output "Vulnerability has been patched" when a match is found and terminate the process, continue when no match is found; Step S4: Determine the SP version of the Kylin system: Execute the system command used to extract system version information, obtain the SP version identifier from the standard version configuration file of the Kylin system, execute the upgrade process corresponding to SP1 when the identifier is SP1, execute the upgrade process corresponding to SP2 when the identifier is SP2, and output an error message and terminate the process when neither is true. Step S5, System Status Backup: Based on the server boot mode (UEFI or BIOS), back up the GRUB boot configuration file under the corresponding path; execute the system command used to obtain the current default kernel boot item and write the result to the log file; suspend critical power dispatch services (including dispatch service and monitoring service) and record the state before the service is suspended; execute the system command used to save the list of currently loaded kernel modules and the current kernel package information to generate a system status snapshot; Step S6, Upgrade Package Installation: Enter the preset upgrade package directory, select the kernel RPM package group that matches the SP version, execute the system command for installing the kernel package, output the installation process log to the specified log file in real time, and terminate the installation immediately and trigger the subsequent rollback steps when an error occurs. Step S7, Server Reboot: Execute system commands to reboot the server, monitor the boot process through the BMC interface, trigger IPMI / BMC hardware-level recovery when boot times out or fails, and confirm and record the current running kernel version as the target version after successful boot. Step S8, Upgrade Result Verification and Rollback: The verification process is run automatically, including confirming kernel version matching, checking system logs for kernel errors, restoring and verifying the normal operation of critical power dispatch services; when all verification items pass, "Upgrade Successful" is output and the upgrade is completed; when any verification item fails, an automatic rollback is executed. The automatic rollback includes: restoring the GRUB boot configuration file in the corresponding boot mode, setting the old kernel as the default boot option, restarting the server, verifying the normal operation of the old kernel and the restoration of critical services after the rollback, and outputting "Rollback Successful".

[0020] In step S1, logging into the server BMC management interface specifically involves accessing the Web management interface via the server's preset BMC management IP.

[0021] The judgment logic for executing the system command used to obtain the server hardware architecture in step S2 is as follows: when the command output result is x86_64, it is determined that it meets the architecture requirements; when the output is "aarch64" or "i386", it is determined that it is not an x86_64 architecture.

[0022] In step S3, the system command used to query the version of the currently installed kernel package is executed. Specifically, this involves querying all kernel-related packages installed in the system, filtering the results that contain kernel version identifiers, and the target kernel version being the kernel version determined according to the official patch announcement for the Linuxkernelnetfilter:nf_tables component vulnerability.

[0023] In step S4, the standard version configuration file for the Kylin system is / etc / os-release. The system command used to extract system version information is to filter the contents containing the "VERSION" field from the configuration file and determine the SP version by the identifier "SP1" or "SP2" in the field.

[0024] The method for determining the server boot mode in step S5 is as follows: check if the system has a directory for identifying UEFI boot. If it exists, it is determined to be in UEFI mode; otherwise, it is in BIOS mode. In UEFI mode, the GRUB boot configuration file path is / boot / efi / EFI / kylin / grub.cfg, and in BIOS mode, the path is / boot / grub2 / grub.cfg. Recording the state before the service is suspended specifically involves appending the service status information to the log file.

[0025] In step S6, when executing the system command used to install the kernel package, parameters are added to force overwrite old version dependencies and ignore non-critical dependencies to ensure that the installation process is not blocked by unnecessary factors; the log file is specified as / var / log / rpm_upgrade.log.

[0026] In step S7, the timeout criterion is that the server has not entered the normal system interface for more than 5 minutes after restarting. The way to confirm the current running kernel version is to execute the system command used to check the current kernel version.

[0027] Step S8, restoring and verifying key power dispatch services, specifically includes: sequentially starting the dispatch service and monitoring service, executing system commands to view the service running status, confirming the service status as "active (running)," and triggering a simulated dispatch task to verify that the service functions normally; checking the system log specifically involves querying the system log file to see if there are error messages containing "kernelerror" or "fail."

[0028] In step S8, the old kernel is set as the default boot option by reading the old kernel boot option identifier from the log file recorded in step S5 and executing the system command used to set the default boot option. The old kernel boot option identifier is the boot option name corresponding to the Kylin system, and the format is "KylinLinuxAdvancedServer (old kernel version) system main version". Step S8 verifies the normal operation of the old kernel and the recovery of critical services after the rollback, specifically including: executing system commands to check the current kernel version and confirming that the version is the old kernel before the upgrade; executing system commands to check the service status and confirming that the scheduling service and monitoring service are running normally; and checking the system logs for kernel exception information.

[0029] One specific application of this embodiment is: Preliminary steps: IPMI / BMC pre-configuration (to ensure hardware-level recovery takes effect) To ensure automated hardware recovery is triggered in the event of server startup failure, IPMI / BMC configuration must be completed beforehand: Log in to the BMC Web management interface via the server's BMC management IP (e.g., 192.168.0.1); Go to the "Boot" → "Boot Failure Recovery" configuration page and enable the "Automatic recovery after startup failure" function; Set the recovery policy to "Rollback to Previous Boot Option" and configure the "Maximum number of automatic restarts" to 3. After saving the configuration, verify the BMC network connectivity using the ping command to ensure that recovery can be triggered normally in the event of a subsequent startup failure.

[0030] S1. Determine the current server's system architecture. Execute the command `uname -m` to obtain the server's hardware architecture. If the output is x86_64, continue with the subsequent steps; if the output is not x86_64 (such as aarch64 or i386), print the error message "Abnormal environment, stopped running" and terminate the script process. This step ensures that the upgrade only applies to servers with x86_64 architecture, avoiding installation failure or system crashes due to architecture incompatibility.

[0031] S2. Verify whether the current kernel version includes vulnerability fixes. Execute the command `rpm -qa|grep kernel|grep 5.10.0-60.el7.x86_64` (Note: 5.10.0-60.el7.x86_64 is the target kernel version after the vulnerability was patched; it needs to be replaced with the actual version according to the official vulnerability announcement) to query the currently installed kernel package version: If the query results contain the target kernel version (e.g., output kernel-5.10.0-60.el7.x86_64), then print the message "Vulnerability upgrade completed" and terminate the process directly. If the query results do not show the target version or the corresponding kernel is not installed, continue with the subsequent steps.

[0032] This step avoids repeated upgrades, improves execution efficiency, and directly verifies the core object of vulnerability patching (kernel package), ensuring the accuracy of the judgment.

[0033] S3. Determine the SP version of the Kylin system kernel. Use a common system version detection method to avoid relying on a fixed file structure: Execute the command `cat / etc / os-release | grep VERSION` to extract system version information (Kylin system supports the standard file ` / etc / os-release` by default). If the output contains VERSION="10 (SP1)" (e.g., VERSION="Kylin Linux AdvancedServer 10 (SP1)"), then the upgrade process corresponding to SP1 will be executed subsequently. If the output contains VERSION="10 (SP2)", then execute the upgrade process corresponding to SP2. If the output does not contain either "SP1" or "SP2", the error message "Abnormal environment stopped running" will be printed and the process will be terminated.

[0034] This step ensures that the upgrade package is strictly matched with the Kylin system version, avoiding version misjudgment due to differences in file structure.

[0035] S4. Back up the current kernel boot configuration and critical scheduling service status. This step provides the foundation for the rollback mechanism and requires compatibility with both BIOS (Legacy) and UEFI boot modes: Determine the boot mode and back up the GRUB configuration: The command `if [ -d " / sys / firmware / efi" ]; then echo "UEFI"; else echo "BIOS";` is executed to detect the boot mode. If it is in UEFI mode: execute cp / boot / efi / EFI / kylin / grub.cfg / boot / efi / EFI / kylin / grub.cfg.backup to back up the Kylin system UEFI boot configuration; If in BIOS mode: Execute cp / boot / grub2 / grub.cfg / boot / grub2 / grub.cfg.backup to back up the BIOS boot configuration.

[0036] Record the current default kernel version: Execute the command `grub2-editenv list|grep saved` to obtain the current default boot entry and write the result to the log file ` / var / log / kernel_upgrade.log`. Example format: `saved_entry=Kylin Linux AdvancedServer (3.10.0-1160.el7.x86_64) 10 (SP1)`.

[0037] Suspension of critical power dispatch services: Execute the commands `systemctl stop power-dispatch.service` and `systemctl stop grid-monitor.service` in sequence to pause the scheduling and monitoring services and ensure that there are no data write conflicts during the upgrade process; at the same time, execute `systemctl status power-dispatch.service grid-monitor.service >> / var / log / kernel_upgrade.log` to record the status of the services before they were paused.

[0038] Generate a system status snapshot: Execute the command `lsmod> / var / log / kernel_modules.list` to save the list of currently loaded kernel modules, and execute `rpm -qa | grep kernel>> / var / log / kernel_upgrade.log` to save the current kernel package information for easy comparison during rollback.

[0039] S5. Select and install the corresponding upgrade package based on the server kernel version. Navigate to the pre-configured upgrade package directory (e.g., / opt / kernel-upgrade / ), and select the corresponding Kylin system kernel RPM package group based on the SP version determined by S3 (e.g., SP1 corresponds to kernel-5.10.0-60.el7.x86_64.rpm and kernel-devel-5.10.0-60.el7.x86_64.rpm): Execute the installation command rpm -Uvh *.rpm --force --nodeps (--force ensures that old version dependencies are overwritten, --nodeps prevents non-critical dependencies from blocking the installation). During the installation process, the logs are output to / var / log / rpm_upgrade.log in real time using the tee command (command: rpm -Uvh *.rpm --force --nodeps 2>&1 | tee -a / var / log / rpm_upgrade.log); If an error with a non-zero return value occurs during the installation process (such as "dependency missing" or "file conflict"), the installation will be terminated immediately and the S8 automatic rollback mechanism will be triggered.

[0040] S6. Restart the server to activate the new kernel. Execute the command reboot to restart the server, and monitor the startup status through the BMC interface: After the system reboots, it will boot from the new kernel by default, and the boot process log will be written to / var / log / boot.log in real time; If the boot timeout occurs (e.g., the system fails to boot within 5 minutes) or the boot fails (e.g., the GRUB rescue mode is entered), IPMI / BMC hardware-level recovery is triggered (rolling back to the old boot entry according to the strategy configured in the previous steps). After successful startup, execute `uname -r` to confirm that the current kernel version is the target version, and write the result to ` / var / log / kernel_upgrade.log`.

[0041] S7. Run the verification script again to check the upgrade result. After the server restarts, a verification script will run automatically to ensure vulnerability patching and system availability. Kernel version verification: Execute `rpm -qa | grep kernel | grep 5.10.0-60.el7.x86_64` to confirm that the target kernel is installed; execute `uname -r` to confirm that the currently running kernel is the target version. System log check: Execute `grep -i "kernel error" / var / log / messages` or `dmesg |grep -i "fail"` to check for kernel error messages. If no errors are found, continue. Dispatch service recovery and verification: Execute `systemctl start power-dispatch.service` and `systemctl start grid-monitor.service` in sequence to restore the scheduling and monitoring services; Execute `systemctl status power-dispatch.service grid-monitor.service` to confirm that the service status is "active (running)" and there are no exception logs. Trigger a simulated scheduling task once (e.g., systemctl restart power-dispatch.service && sleep 10 && systemctl is-active power-dispatch.service) to verify that the service function is normal.

[0042] If all checks pass, "Upgrade successful" is printed and the result is written to / var / log / kernel_upgrade.log, and the system enters normal operation. If any check fails, the S8 automatic rollback mechanism is immediately triggered.

[0043] S8. If verification fails, perform automatic rollback. This step ensures rapid system recovery in the event of an upgrade failure; the entire process is automated and requires no manual intervention. Triggering condition: If any verification item in S7 fails (such as kernel version mismatch, service startup failure, kernel error), the script will automatically call the rollback program.

[0044] Restore GRUB configuration: If in UEFI mode: execute `cp / boot / efi / EFI / kylin / grub.cfg.backup / boot / efi / EFI / kylin / grub.cfg` to overwrite the current configuration; If in BIOS mode: execute cp / boot / grub2 / grub.cfg.backup / boot / grub2 / grub.cfg to restore the old boot configuration.

[0045] Set the old kernel as the default boot option: Read the old kernel boot entry recorded in S4 from / var / log / kernel_upgrade.log (e.g., saved_entry=Kylin Linux Advanced Server (3.10.0-1160.el7.x86_64) 10 (SP1)), and execute the command grub2-set-default "Kylin Linux Advanced Server (3.10.0-1160.el7.x86_64) 10(SP1)" (which needs to be replaced with the actual old kernel boot entry name).

[0046] Restart to take effect and rollback: Execute reboot to restart the server, monitor the boot process through BMC, and ensure that the system boots from the old kernel.

[0047] Verification after rollback: After the server starts, execute `uname -r` to confirm that the current kernel is the old version before the upgrade; Execute `systemctl status power-dispatch.service grid-monitor.service` to confirm that the dispatch and monitoring services are running normally. Checking / var / log / messages for kernel error logs, print "Rollback successful" and write it to / var / log / kernel_upgrade.log; Through the above rollback steps, the system can be restored to its stable state before the upgrade, avoiding interruption of power dispatch services.

[0048] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0049] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for upgrading the Kylin system kernel based on vulnerabilities, characterized in that, The upgrade method specifically includes the following steps: Step S1, Pre-configuration IPMI / BMC: Log in to the server BMC management interface, enable the automatic recovery function for startup failure, set the recovery policy to roll back to the previous valid startup item, configure the maximum number of automatic restarts, and verify the BMC network connectivity; Step S2, System Architecture Determination: Execute the system command used to obtain the server hardware architecture. If the architecture is x86_64, continue to the next step. If it is not x86_64, output an error message and terminate the process. Step S3, Kernel Version Verification: Execute the system command used to query the version of the currently installed kernel package, compare the query result with the target kernel version after the vulnerability is patched, output "Vulnerability has been patched" when a match is found and terminate the process, continue when no match is found; Step S4: Determine the SP version of the Kylin system: Execute the system command used to extract system version information, obtain the SP version identifier from the standard version configuration file of the Kylin system, execute the upgrade process corresponding to SP1 when the identifier is SP1, execute the upgrade process corresponding to SP2 when the identifier is SP2, and output an error message and terminate the process when neither is true. Step S5, System Status Backup: Based on the server boot mode, back up the GRUB boot configuration file under the corresponding path; execute the system command used to obtain the current default kernel boot item and write the result to the log file; suspend the critical power dispatch service and record the state before the service is suspended; execute the system command used to save the list of currently loaded kernel modules and the current kernel package information, and generate a system status snapshot; Step S6, Upgrade Package Installation: Enter the preset upgrade package directory, select the kernel RPM package group that matches the SP version, execute the system command for installing the kernel package, output the installation process log to the specified log file in real time, and terminate the installation immediately and trigger the subsequent rollback steps when an error occurs. Step S7, Server Reboot: Execute system commands to reboot the server, monitor the boot process through the BMC interface, trigger IPMI / BMC hardware-level recovery when boot times out or fails, and confirm and record the current running kernel version as the target version after successful boot. Step S8, Upgrade Result Verification and Rollback: The verification process is run automatically, including confirming kernel version matching, checking system logs for kernel errors, restoring and verifying the normal operation of critical power dispatch services; when all verification items pass, "Upgrade Successful" is output and the upgrade is completed; when any verification item fails, an automatic rollback is performed, which includes: restoring the GRUB boot configuration file in the corresponding boot mode, setting the old kernel as the default boot option, restarting the server, verifying the normal operation of the old kernel and the restoration of critical services after the rollback, and outputting "Rollback Successful".

2. The method for upgrading the Kylin system kernel based on a vulnerability, as described in claim 1, is characterized in that... In step S1, logging into the server BMC management interface specifically involves accessing the Web management interface via the server's preset BMC management IP.

3. The method for upgrading the Kylin system kernel based on a vulnerability, as described in claim 1, is characterized in that... The judgment logic for executing the system command used to obtain the server hardware architecture in step S2 is as follows: when the command output result is x86_64, it is determined that it meets the architecture requirements; when the output is "aarch64" or "i386", it is determined that it is not an x86_64 architecture.

4. The method for upgrading the Kylin system kernel based on a vulnerability, as described in claim 1, is characterized in that... In step S3, executing the system command to query the currently installed kernel package version specifically involves querying all kernel-related packages installed in the system and filtering the results that contain kernel version identifiers. The target kernel version is the kernel version determined according to the official patch announcement for the Linuxkernelnetfilter:nf_tables component vulnerability.

5. The method for upgrading the Kylin system kernel based on a vulnerability, as described in claim 1, is characterized in that... In step S4, the standard version configuration file of the Kylin system is / etc / os-release. Specifically, executing the system command to extract system version information involves filtering the contents containing the "VERSION" field from the configuration file and determining the SP version by the identifier "SP1" or "SP2" in the field.

6. The method for upgrading the Kylin system kernel based on a vulnerability as described in claim 1, characterized in that, The method for determining the server boot mode in step S5 is as follows: check if the system has a directory for identifying UEFI boot. If it exists, it is determined to be in UEFI mode; otherwise, it is in BIOS mode. In UEFI mode, the GRUB boot configuration file path is / boot / efi / EFI / kylin / grub.cfg, and in BIOS mode, the path is / boot / grub2 / grub.cfg. The step of recording the state before the service is suspended specifically involves appending service status information to the log file.

7. The method for upgrading the Kylin system kernel based on a vulnerability, as described in claim 1, is characterized in that... In step S6, when executing the system command for installing the kernel package, parameters are added to force overwrite old version dependencies and ignore non-critical dependencies to ensure that the installation process is not blocked by unnecessary factors; the specified log file is / var / log / rpm_upgrade.log.

8. The method for upgrading the Kylin system kernel based on a vulnerability as described in claim 1, characterized in that, The timeout criterion in step S7 is that the server has not entered the normal system interface for more than 5 minutes after restarting. The method to confirm the current running kernel version is to execute a system command used to view the current kernel version.

9. The method for upgrading the Kylin system kernel based on a vulnerability as described in claim 1, characterized in that, The recovery and verification of key power dispatch services in step S8 specifically includes: sequentially starting the dispatch service and monitoring service, executing system commands to view the service running status, confirming that the service status is "active (running)," and triggering a simulated dispatch task to verify that the service function is normal; the check of the system log specifically involves querying the system log file to see if there are error messages containing "kernelerror" or "fail." 10. The method for upgrading the Kylin system kernel based on a vulnerability according to claim 1, characterized in that, The method for setting the old kernel as the default boot option in step S8 is as follows: read the old kernel boot option identifier from the log file recorded in step S5, and execute the system command used to set the default boot option. The old kernel boot option identifier is the boot option name corresponding to the Kylin system, and the format is "KylinLinuxAdvancedServer system main version". Step S8, verifying the normal operation of the old kernel and the recovery of critical services after the rollback, specifically includes: executing a system command to check the current kernel version and confirming that the version is the old kernel before the upgrade; executing a system command to check the service status and confirming that the scheduling service and monitoring service are running normally; and checking the system logs for any kernel abnormality information.

Images