CN113268366A - 内核运行方法、设备和系统 - Google Patents

Abstract

公开了一种内核运行方法、系统和终端设备。该方法包括：下载内核的更新版本；加载所述内核的当前版本；加载所述内核的更新版本；跳转至所述内核的更新版本；以及运行所述内核的更新版本。本发明通过在保留内核的当前版本的同时，直接在内存中加载经缺陷修复的完整内核(例如，内核镜像)，在无需实际进行系统内核升级的情况下，运行经修复的内核，从而避免内核缺陷对系统安全运行所造成的影响。本发明的上述方案还可适用于操作系统中其他缺陷的快速修复。

Description

内核运行方法、设备和系统

技术领域

本公开涉及一种软件更新领域，尤其涉及一种操作系统内核的运行方法、设备和系统。

背景技术

操作系统缺陷无法被完全消除。内核作为系统的基础，在出现缺陷时，会对系统造成更大危害。这些缺陷可能进一步转变为安全漏洞，对系统用户造成安全风险。因此，在系统出现缺陷时，如何快速修复缺陷、缩小影响窗口就成为了值得研究的问题。

现有的移动设备中普遍采用了OTA更新机制来对系统组件进行更新。传统的OTA更新时需要烧写硬件，更新耗时长，无法满足快速修复的要求。在无AB分区的情况下，烧写失败就会造成系统不可用。现有的自适应热修复方案需要在运行态修改内核代码，与体系结构相关，维护难度大，并且对部分缺陷无法完美修复。

为此，需要一种能够快速修复操作系统缺陷，尤其是内核缺陷的方案。

发明内容

本公开要解决的一个技术问题是提供一种能够快速修复内核缺陷的方案。该方案在保留内核的当前版本的同时，直接在内存中加载经缺陷修复的完整内核(例如，内核镜像)，由此在无需实际进行系统内核升级的情况下，运行经修复的内核，从而避免内核缺陷对系统安全运行所造成的影响。本发明的上述方案也适用于对操作系统中除内核之外的其他部分，例如，对用户态进行缺陷修复和快速运行。

根据本公开的第一个方面，提供了一种内核运行方法，包括：下载内核的更新版本；加载所述内核的当前版本；加载所述内核的更新版本；跳转至所述内核的更新版本；以及运行所述内核的更新版本。

根据本公开的第二个方面，提供了一种终端设备，用于：下载内核的更新版本；加载所述内核的当前版本；加载所述内核的更新版本；跳转至所述内核的更新版本；以及运行所述内核的更新版本。

根据本公开的第三个方面，提供了一种内核运行系统，包括：服务器；以及如本公开第二方面所述的多个终端设备，其中，所述服务器用于：构建所述内核的更新版本；以及将所述更新版本下发至多个终端设备。

根据本公开的第四个方面，提供了一种操作系统运行方法，包括：获取操作系统的更新版本；为所述更新版本分配内存并加载所述更新版本；以及启动对加载的所述更新版本的运行。

根据本公开的第五个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第一和第四方面所述的方法。

根据本公开的第六个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第一和第四方面所述的方法。

由此，本方案能够使用修复后的更新版本，动态地替换当前系统中存在缺陷的操作系统或其部分，例如内核部分。该方案可以利用kexec_load进行内核缺陷快速修复；还可以通过为kexec_load添加内核镜像文件签名校验的流程，避免传输过程中文件被篡改带来的安全风险；另外，还设计了容错措施，避免内核补丁的缺陷导致设备不可用的更差情况。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1A和1B示出了OTA固件升级时的系统连接例。

图2示出了根据本发明一个实施例的操作系统运行方法的示意性流程图。

图3示出了容错机制中的状态迁移例。

图4示出了服务器端构建新内核并下发的流程例。

图5示出了根据本发明一个实施例的内核运行方法的示意性流程图。

图6示出了根据本发明一实施例可用于实现上述操作系统运行方法的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

操作系统缺陷无法被完全消除。内核作为系统的基础，在出现缺陷时，会对系统造成更大危害。这些缺陷可能进一步转变为安全漏洞，对系统用户造成安全风险。因此，在系统出现缺陷时，如何快速修复缺陷、缩小影响窗口就成为了值得研究的问题。

在计算机领域中，0day(零日)漏洞通常指是已经被发现(有可能未被公开)，还没有官方补丁的安全漏洞，而零日攻击则是指利用这种漏洞进行的攻击。由于缺乏补丁保护，零日漏洞的利用程序对网络安全具有巨大威胁。内核作为系统的基础，当它出现缺陷时，例如系统级的零日漏洞，则有可能造成更大的危害。一般而言，零日攻击唯一彻底解决方法便是由原操作系统发行公司提供修补程序，但修补程序(补丁包或是升级包)的准备通常较慢。另外，即便在获取了补丁包或是升级包的情况下，诸如车载娱乐系统等的移动设备在进行更新(例如，OTA更新)时，也会由于OTA更新本身需要烧写硬件，且更新耗时长，而更加无法满足快速修复的要求。

虽然现有的自适应热修复方案可以动态修改内核的执行逻辑修复缺陷，但是这些方案需要专业的技术人员单独制作相应的补丁，无法利用业界和社区的力量，并且对一些复杂缺陷无法完美修复或修复难度极大。

为此，本发明提出一种能够快速修复内核缺陷的方案。该方案在保留内核的当前版本的同时，直接在内存中加载经缺陷修复的完整内核(例如，内核镜像)，由此在无需实际进行系统内核升级的情况下，运行经修复的内核，从而避免内核缺陷对系统安全运行所造成的影响。本发明的上述方案也适用于对操作系统中内核之外的其他部分，例如，用于对用户态进行缺陷修复和快速运行。

本发明的操作系统修复和运行方案尤其适用于物联网设备。随着物联网的发展，智能设备的种类愈加丰富。为了降低维护成本、提升用户体验，OTA(Over-the-Air，可被称为“在线升级”或“空中升级”)技术成为智能物联网时代的标配。随着4G、WiFi和蓝牙Mesh技术在物联网升级设备上的普及，更多设备对升级的要求日渐增高。

物联网规模化部署面临着众多挑战，例如：众多设备近距共终端和庞大数量的设备互连。这些挑战催生出对OTA固件升级的需求，它将是物联网系统必不可缺的一个组成部分。例如手机会通过定期升级来接收新功能和修补漏洞。为了防范病毒攻击，设备固件可通过OTA固件升级流程获得最新补丁和更多安全算法。任何物联网系统都由两个部分组成：硬件和固件。在基于SoC的应用中，OTA固件升级功能不仅能够更新固件，还能够重新配置片上硬件资源。

图1A和1B示出了OTA固件升级时的系统连接例。如图1A所示，在某些应用场景或是针对某些特定的设备，物联网单芯片设备1可以直接联网，以在检测到有新版本需要安装时从例如OTA管理平台2上下载所需的升级包。而OTA管理平台2上的升级包例如是由设备供应商(未示出)基于原始版本和更新版本制作并上传的。如图1B所示，物联网单芯片设备1也可以经由例如手机或是网关设备3间接OTA管理平台2联网进行升级。此时，可由中间设备3利用OTAAPP进行升级包的下载和下发的相关的OTA管理操作。

然而，由于OTA更新本身需要烧写硬件，且更新耗时长，而更加无法满足快速修复的要求，例如，无法满足避免零日攻击的需求。

为此，本发明首先提出了一种操作系统运行方法。图2示出了根据本发明一个实施例的操作系统运行方法的示意性流程图。该方法适用于移动终端，例如功能相对较为复杂的物联网设备(例如，车载娱乐系统)或是诸如手机的智能设备实施。

在步骤S210，获取操作系统的更新版本，所述更新版本不同于所述操作系统的当前版本。上述操作系统的更新版本，通常并非是操作系统本身的全部完整更新，而是操作系统中一部分内容的更新版本，例如在如下将详述的操作系统内核的更新版本。在其他实施例中，操作系统的更新版本也可以是单纯的内核更新版本之外的其他内容的更新版本，例如，用户态的更新版本，或是内核某一部分的更新版本，或是部分内核态部分用户态的更新版本等。

在步骤S220，为所述更新版本分配内存并加载所述更新版本。在步骤S230，启动对加载的所述更新版本的运行。在此，启动对加载的所述更新版本的运行指的是在不升级当前版本的操作系统的情况下，启动对加载的所述更新版本的运行。即，在本发明的方案中，并不会在终端设备中实际“安装”或是“升级”上述更新版本，而是在保留所述操作系统当前版本的安装的情况下，直接通过在物理内存中对更新版本的加载，实现对上述更新版本的运行。由此，终端设备只需获取并加载该“更新版本”即可，无需经历云端准备升级包和本地烧录的过程，从而提高操作系统漏洞响应速度，缩小攻击窗口，从而降低攻击对用户产生的危害程度，同时避免OTA升级失败带来的风险。

在此，操作系统的“更新版本”指的是相比于移动终端上安装的同一操作系统的当前版本有更新的版本。例如，在发现操作系统漏洞时，开发人员可以制作修复补丁，并将修复所涉及的那一部分操作系统(例如，经修复安全漏洞的内核)制作成镜像，作为该操作系统的更新版本。随后，在步骤S210，终端设备可以从外部获取上述更新版本。类似于图1所示的OTA升级的连接方式，适用于本发明的终端设备也可以如图1A所示，直接联网，以在检测到有本发明所述的“更新版本”时从云端直接下载上述“更新版本”。上述“更新版本”是由设备供应商或管理方基于当前版本和补丁制作并上传的。适用于本发明的终端设备也可以如图1B所示，物以经由例如手机或是网关设备作为中间设备间接云端服务器进行升级。此时，可由中间设备利用物联网管理APP进行“更新版本”通知的接收和相应镜像的下载和下发。

在此，获取的“更新版本”是可被恢复成完整操作系统的完整版本，例如，是经漏洞修复的操作系统镜像。但更为优选的是，获取的“更新版本”是所述操作系统的某一特定部分的更新版本，例如是操作系统内核的更新版本，换句话说，所述更新版本可以是内核镜像。在例如经由直接或间接下载获取了所述操作系统的更新版本之后，该方法还可以存储所述更新版本，同时保留对所述当前版本的存储，例如，保留当前版本在内核物理分区上的存储。在此，存储指代非易失性存储，例如，在物联网设备的flash上的存储，与步骤S220中物理内存中的加载(“易失性存储”)相区别。在存储了上述能够完整执行的更新版本之后，就能够在不经安装的情况下通过从存储空间读入内存进行加载而实现对更新版本的直接执行。

在实际操作中，可以在内存中默认加载所述操作系统的当前版本。加载的当前版本可以是与更新版本相对应的那一部分的操作系统，例如，加载当前版本的内核。随后，可以在内存中加载步骤S210获取的更新版本，随后可以从加载的所述当前版本跳转至加载的所述更新版本，以实现更新版本的运行。具体地，在更新版本是操作系统内核的情况下，设备可以在每次上电时正常加载并运行当前内核，随后将新内核加载之内存，并跳转至该新内核进行直接运行。

由于该更新版本是外部获得的，因此优选在获取该更新版本之后进行安全性验证操作，以避免在传输过程中该更新版本本身(例如，内核镜像)的完整性被破坏，例如，避免加载被恶意篡改的更新版本。具体地，云端可以在生成更新版本之后使用服务器私钥进行签名，在终端则可以用发布的公钥解密经配对私钥加密的所述更新版本，以由此验证更新版本的完整性。如果验证通过，则可以执行后续的解压、存储、加载和运行操作，如果验证未通过，则正常运行当前版本。由于非对称加密对终端设备的算力要求较高，在其他实施例中，针对算力有限的终端设备，也可采用诸如堆成加密等对算力消耗更小的验证方法。

本发明的更新版本运行方案还可以包括对新版本的容错措施。上述容错措施可以用来应对更新版本构建过程中的差错导致的加载后更新版本无法正常运行的状况。上述措施对于更新内核尤为重要，因此不同于用户态内应用的无法正常运行，内核无法被正常加载会导致系统无法运行，使得设备处于不可用的状态。若没有容错措施，设备将会从存在漏洞但可用变为持续不可用的状态，客观上使系统问题变得更为严重。于是，该方法还可以包括：在判定所述更新版本运行失败时，运行所述操作系统的当前版本。在判定所述更新版本运行失败时，可以重启以运行所述操作系统的当前版本。例如，更新的内核镜像如果因为存在缺陷而无法正常运行，则可以通过重启来恢复对当前版本内核的运行。

在加载内核的示例中，本发明的容错措施可以记录新内核的状态，并作为后续操作的依据。图3示出了容错机制中的状态迁移例。该容错机制如图所示可以具有以下4种状态：

1，NEW：下载的新内核初始状态；

2，LOADED:已加载未运行；

3，RUNNING：运行中；

4，INVALID：运行失败，此状态是一个最终态，具有此状态的新内核将不再被加载。

具体地，在步骤S220在物理内存中加载新内核时，可以设定新内核的启动参数时，在其中加入标志字符串，如“kernel_patched＝1"。在此，内核启动参数可以指代Linux内核启动时的参数，用于设定内核的一些参数，启动后可以通过/proc/cmdline查看。随后在步骤S230启动运行新内核后，检查该内核启动参数，查看其中是否含有标志字符串。如果内核参数中含有标志字符串：说明新内核正常启动，这种情况下将状态修改为RUNNING；如果内核参数中不含有标志字符串：说明新内核启动失败，系统重启后启动了旧内核，这种情况下将状态修改为INVALID。

容错措施可以在此基础上进一步扩展，设定更多的状态；也可以设计其他判定运行成功的方案。在一个实施例中，可以在构建新内核时，为新内核添加特殊的标记，运行后检查是否含有这个标记。在另一个实施例中，可以在新内核运行后通过执行某个用户态程序判断新内核的功能是否正常。具体地，当云端发现旧内核某个功能存在漏洞，可以在推送新内核时附带一个测试新内核是否正常运行的应用程序。启动新内核后，可以使用该应用程序测试相关的功能是否正常。另外，也可以在设备上附带一个通用的内核测试程序，启动新内核后使用该程序对新内核进行全面测试。

如上结合内核说明了本发明的容错机制。在更广泛的实施例中，本发明的操作系统运行方法还可以包括设定所述更新版本的启动参数，并在所述启动参数中加入区分标志；以及检测所述区分标志，并判定所述操作系统的更新版本是否运行失败。作为补充或是替换，还可以如上使用测试程序判定所述操作系统的更新版本是否运行失败。

如前所示，本发明的提及的“更新版本”是用于能够在内存中直接加载并运行的所述操作系统的免安装版本。上述版本能够最快速度实现对新发现缺陷的修补。而在操作系统支持方针对上述缺陷发布了正式的升级包之后，该方法还可以包括：获取所述操作系统的升级包；安装所述升级包；以及删除在前获取的所述更新版本。

本发明的计算方案还可以实现为一种内核运行系统。该系统包括：服务器以及多个终端设备。每个终端设备可以执行如上和如下所述的操作系统(或优选为内核)的运行方法。服务器则可用于：构建所述内核的更新版本；以及将所述更新版本下发至多个终端设备。

服务器还可用于：对构建的所述更新版本进行签名。进一步地，服务器还可用于：下发用于判定所述更新版本的内核在启动后是否正常运行的测试程序。

图4示出了服务器端构建新内核并下发的流程例。在步骤S410，运营人员发现新的内核缺陷，根据针对该新缺陷的内核补丁，构建修复后的内核镜像。随后，在步骤S420，使用私钥对内核镜像进行签名。在步骤S430，向设备端发送更新消息，下发内核镜像到设备端。

在本发明的系统中，各个终端设备可以如图1A所示，直接与服务器相连并进行相应的下载操作。在其他实施例中，各个终端设备也可以如图1B所示，经由中间设备与服务器相连并进行相应的下载操作。在此情况下，该系统还可以包括中间设备，用于：获取所述服务器下发的更新版本；以及将所述更新版本下发至相应的终端设备。

在实际应用中，服务器端可以是支持同种设备的小型平台，也可以是支持多种设备的各个内核版本的大型平台。为此，多个终端设备可以是安装相同内核的多个同类终端设备，也可以是安装不同内核的多个种类的多个终端设备。在一个实施例中，本发明的上述操作系统运行系统可以并入已有的OTA升级系统，云端可以在发现缺陷(例如，会严重危急系统正常运行的安全漏洞)后快速制作内核镜像并下发，进行本发明的无更新加载和运行。随后，在升级包准备好之后，在下发对应的升级包供相应设备进行升级。

上述系统中的终端设备尤其适用于执行一种内核运行方法。本方案的核心正是使用修复后的内核镜像，动态地替换当前系统中存在缺陷的内核。在本文中，可以将前者称为新内核，后者称为旧内核。图5示出了根据本发明一个实施例的内核运行方法的示意性流程图。该方法可以看作是图2所示操作系统运行方法的一个优选实施例。在步骤S510，下载内核的更新版本(新内核)。在步骤S520，加载所述内核的当前版本(旧内核)。在步骤S530，加载所述内核的更新版本。在步骤S540，跳转至所述内核的更新版本。在步骤S550，运行所述内核的更新版本。具体地，可以保留一段物理内存，将新内核拷贝到这里，并设定内核启动的参数。在例如使用kexec_load进行跳转之后，可以在保留的物理内存处，开始执行新内核。完成上述流程后，设备上运行的将是修复缺陷之后的内核镜像，也就是说，原有内核中的缺陷和漏洞被修复。

具体地，在步骤S510，可以下载修复了当前版本中缺陷的内核镜像。终端设备可以按照常规操作加载内核的当前版本，并利用kexec_load指令加载始自当前地址空间中的新内核。另外，该方法还可以包括在下载内核镜像之后，校验所述更新版本的签名，例如，基于非对称加密。如果校验成功，则可以对获取的新内核进行后续的存储和内存加载操作。如果校验失败，则正常使用现有内核。进一步地，在判定所述更新版本运行失败时，终端设备还可以重启以运行所述内核的当前版本。可以利用不同的机制对新内核是否正常运行进行判定。在一个实施例中，可以设定所述内核的内核启动参数，并在在所述启动参数中加入区分标志；以及检测所述区分标志，并判定所述内核的更新版本是否正常运行。作为替换或是补充，还可以在启动对加载的所述更新版本的运行后，在所述内核中运行的测试程序进行测试，以判定所述内核的更新版本是否正常运行。

另外，本发明还可以实现为一种终端设备，该设备可以执行如上结合图2和图5描述的操作系统运行方法。具体地，该设备可以用于：下载内核的更新版本；加载所述内核的当前版本；加载所述内核的更新版本；跳转至所述内核的更新版本；以及运行所述内核的更新版本。

在一个实施例中，该设备可以用于下载修复了当前版本中缺陷的内核镜像。

在一个实施例中，该设备可以还用于：校验所述更新版本的签名。

在一个实施例中，该设备可以还用于：在判定所述更新版本运行失败时，重启以运行所述内核的当前版本。具体地，可以基于如下至少一项判定所述更新版本运行失败：在设定所述内核的内核启动参数时在所述启动参数中加入区分标志，并在启动对加载的所述更新版本的运行后检查内核是否含有所述区分标志；以及在启动对加载的所述更新版本的运行后，在所述内核中运行的测试程序进行测试，以判定所述内核的更新版本是否正常运行。

图6示出了根据本发明一实施例可用于实现上述操作系统运行方法的计算设备的结构示意图。

参见图6，计算设备600包括存储器610和处理器620。

处理器620可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器620可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器620可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器610可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器620或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器610可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器610可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器610上存储有可执行代码，当可执行代码被处理器620处理时，可以使处理器620执行上文述及的操作系统运行方法。

上文中已经参考附图详细描述了根据本发明的操作系统运行，尤其是内核运行方法。本方案使用修复后的内核镜像，动态地替换当前系统中存在缺陷的内核。具体地，该方案利用kexec_load进行内核缺陷快速修复的方案，第一次将现有的kexec_load指令用于缺陷修复领域；该方案还通过为kexec_load添加了内核镜像文件签名校验的流程，避免传输过程中文件被篡改带来的安全风险；另外，还设计了容错措施，避免内核补丁的缺陷导致设备不可用的更差情况。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机操作系统或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (32)

1.一种内核运行方法，包括：

下载内核的更新版本；

加载所述内核的当前版本；

加载所述内核的更新版本；

跳转至所述内核的更新版本；以及

运行所述内核的更新版本。

2.如权利要求1所述的方法，其中，下载内核的更新版本包括：

下载修复了当前版本中缺陷的内核镜像。

3.如权利要求1所述的方法，其中，跳转至所述内核的更新版本包括：

利用kexec_load指令加载始自当前地址空间中的新内核。

4.如权利要求1所述的方法，还包括：

校验所述更新版本的签名。

5.如权利要求1所述的方法，还包括：

在判定所述更新版本运行失败时，重启以运行所述内核的当前版本。

6.如权利要求1所述的方法，还包括：

设定所述内核的内核启动参数，并在在所述启动参数中加入区分标志；以及

检测所述区分标志，并判定所述内核的更新版本是否正常运行。

7.如权利要求1所述的方法，还包括：

在启动对加载的所述更新版本的运行后，在所述内核中运行的测试程序进行测试，以判定所述内核的更新版本是否正常运行。

8.一种终端设备，用于：

下载内核的更新版本；

加载所述内核的当前版本；

加载所述内核的更新版本；

跳转至所述内核的更新版本；以及

运行所述内核的更新版本。

9.如权利要求8所述的设备，用于：

下载修复了当前版本中缺陷的内核镜像。

10.如权利要求8所述的设备，还用于：

校验所述更新版本的签名。

11.如权利要求8所述的设备，还用于：

在判定所述更新版本运行失败时，重启以运行所述内核的当前版本。

12.如权利要求8所述的设备，还用于基于如下至少一项判定所述更新版本运行失败：

在设定所述内核的内核启动参数时在所述启动参数中加入区分标志，并在启动对加载的所述更新版本的运行后检查内核是否含有所述区分标志；以及

在启动对加载的所述更新版本的运行后，在所述内核中运行的测试程序进行测试，以判定所述内核的更新版本是否正常运行。

13.一种内核运行系统，包括：

服务器；以及

如权利要求8-12中任一项所述的多个终端设备，其中，

所述服务器用于：

构建所述内核的更新版本；以及

将所述更新版本下发至多个终端设备。

14.如权利要求13所述的系统，其中，所述服务器还用于：

对构建的所述更新版本进行签名。

15.如权利要求13所述的系统，其中，所述服务器还用于：

下发用于判定所述更新版本的内核在启动后是否正常运行的测试程序。

16.如权利要求13所述的系统，还包括：

中间设备，用于：

获取所述服务器下发的更新版本；以及

将所述更新版本下发至相应的终端设备。

17.如权利要求13所述的系统，其中，所述多个终端设备包括如下至少一项：

安装相同内核的多个同类终端设备；以及

安装不同内核的多个种类的多个终端设备。

18.一种操作系统运行方法，包括：

获取操作系统的更新版本；

为所述更新版本分配内存并加载所述更新版本；以及

启动对加载的所述更新版本的运行。

19.如权利要求18所述的方法，其中，启动对加载的所述更新版本的运行包括：

在不升级所述操作系统的当前版本的情况下，启动对加载的所述更新版本的运行。

20.如权利要求19所述的方法，其中，获取操作系统的更新版本包括：

下载所述操作系统的更新版本；

存储所述更新版本，并且保留对所述当前版本的存储。

21.如权利要求18所述的方法，还包括：

在内存中默认加载所述操作系统的当前版本；以及

从加载的所述当前版本跳转至加载的所述更新版本。

22.如权利要求18所述的方法，其中，所述更新版本是可被恢复成完整操作系统的完整版本。

23.如权利要求18所述的方法，其中，所述更新版本是所述操作系统一部分的更新。

24.如权利要求18所述的方法，其中，所述更新版本是所述操作系统中经漏洞修复的内核镜像。

25.如权利要求18所述的方法，还包括：

验证所述更新版本的安全性。

26.如权利要求25所述的方法，其中，验证所述更新版本的安全性包括：

用公钥解密经配对私钥加密的所述更新版本。

27.如权利要求18所述的方法，还包括：

在判定所述更新版本运行失败时，运行所述操作系统的当前版本。

28.如权利要求27所述的方法，还包括：

设定所述更新版本的启动参数，并在所述启动参数中加入区分标志；以及

检测所述区分标志，并判定所述操作系统的更新版本是否运行失败。

29.如权利要求27所述的方法，还包括：

使用测试程序判定所述操作系统的更新版本是否运行失败。

30.如权利要求18所述的方法，还包括：

获取所述操作系统的升级包；

安装所述升级包；以及

删除在前获取的所述更新版本。

31.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-7以及18-30中任一项所述的方法。

32.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1-7以及18-30中任一项所述的方法。

Images