一种linux内核异常的处理方法、设备及装置

技术领域

本文涉及计算机技术，尤指一种linux内核异常的处理方法、设备及装置。

背景技术

随着网络技术的迅猛发展，网络所面临的安全威胁越来越大，安全类产品在网络中的应用也越来越广。我国经过多年的信息安全建设，在防病毒、网络和边界安全方面到得了一定成果，但是没有足够重视存储和处理数据的网络安全类产品的环境安全建设，这是信息安全最重要、也是最后一道防线。某些黑客会针对网络安全类产品的内核缺陷进行攻击，造成操作系统堆栈异常，导致网络安全类产品不能正常运行，影响整个网络的连通性和安全性。因为linux内核无法对这类堆栈进行记录和跟踪，导致定位异常非常困难。

因为网络安全类产品对自身的安全性有非常严格的标准，所以如何解决linux内核异常时的记录和自动复位是安全厂家面临的重要技术问题。

发明内容

本申请提供了一种linux内核异常的处理方法、设备及装置，能够防止linux内核因异常而挂起，并且能记录内核异常信息。

本公开提供了一种linux内核异常的处理方法，所述linux内核包括第一操作系统内核和第二操作系统内核，方法包括：

当第一操作系统内核异常时，捕获异常信息保存在内存中；

启动第二操作系统内核；

启动第二操作系统内核成功后，提取保存在内存中的所述异常信息，将所提取的所述异常信息保存到非易失性存储器中；

重启所述第一操作系统内核，并复位硬件系统内核。

一种示例性的实施例中，所述启动第二操作系统内核前还包括：

所述第一操作系统内核初始化时在内存中预留预设大小的存储空间作为预留内存；所述第一操作系统内核启动后将所述第二操作系统内核的镜像文件导入所述预留内存；

所述启动第二操作系统内核包括：

跳转到所述预留内存中的所述第二操作系统内核，运行所述第二操作系统内核。

一种示例性的实施例中，所述捕获异常信息保存在内存中包括：

将所述第一操作系统内核记录的异常信息编码存储到vmcore文件的note区域；

所述提取保存在内存中的异常信息包括：

从vmcore文件的note区域读取编码后的所述异常信息并解码。

一种示例性的实施例中，所述捕获异常信息包括：

按照不同的异常类型解析相应的信息存储为异常信息，其中，所述异常类型包括：非法内存、软件死锁、内存耗尽、其它异常；

当异常类型为非法内存、软件死锁和其它异常时，解析的信息包括：描述信息、寄存器信息和堆栈信息；

当异常类型为内存耗尽时，解析的信息包括：描述信息、堆栈信息和内存占用排行。

一种示例性的实施例中，所述将所提取的异常信息保存到非易失性存储器中包括：

将所提取的异常信息保存为文本文件后，保存到非易失性存储器中；

在所述文本文件中，所述异常信息按照信息的种类进行分类，同一种类的信息在所述文本文件中集中在一个区域进行展示；所述信息的种类包括：描述信息、堆栈信息、寄存器信息、内存占用排行。

本公开还提供了一种linux内核异常的处理设备，所述linux内核包括第一操作系统内核和第二操作系统内核；所述处理设备包括：

存储控制模块用于当第一操作系统内核异常时，捕获异常信息保存在内存中；

内核控制模块用于启动第二操作系统内核；

所述存储控制模块还用于在所述内核控制模块启动第二操作系统内核成功后，提取保存在内存中的所述异常信息，保存到非易失性存储器中；

所述内核控制模块还用于在所述存储控制模块将异常信息保存到非易失性存储器中后，重启所述第一操作系统内核，并复位硬件系统内核。

一种示例性的实施例中，所述内核控制模块还用于当所述第一操作系统内核初始化时在内存中预留预设大小的存储空间作为预留内存；当所述第一操作系统内核启动后将所述第二操作系统内核的镜像文件导入所述预留内存；

所述内核控制模块启动第二操作系统内核包括：

所述内核控制模块跳转到所述预留内存中的所述第二操作系统内核，运行所述第二操作系统内核。

一种示例性的实施例中，所述存储控制模块包括：

异常解释子模块，用于当第一操作系统内核异常时，捕获异常信息；

异常转存/恢复子模块，用于将所述异常解释子模块所捕获的异常信息编码存储到vmcore文件的note区域；以及当所述内核控制模块启动第二操作系统内核成功后，从vmcore文件的note区域读取编码后的异常信息并解码；

异常存储子模块，用于将解码得到的异常信息保存到非易失性存储器中。

一种示例性的实施例中，所述异常解释子模块捕获异常信息包括：

所述异常解释子模块按照不同的异常类型解析相应的信息存储为异常信息；所述异常类型包括：非法内存、软件死锁、内存耗尽、其它异常；当异常类型为非法内存、软件死锁和其它异常时，解析的信息包括：描述信息、寄存器信息和堆栈信息；当异常类型为内存耗尽时，解析的信息包括：描述信息、堆栈信息和内存占用排行。

一种示例性的实施例中，所述异常存储子模块将解码得到的异常信息保存到非易失性存储器中包括：

所述异常存储子模块将解码得到的异常信息保存为文本文件后，保存到非易失性存储器中；在所述文本文件中，所述异常信息按照信息的种类进行分类，同一种类的信息在所述文本文件中集中在一个区域进行展示；所述信息的种类包括：描述信息、堆栈信息、寄存器信息、内存占用排行。

本公开还提供了一种linux内核异常的处理装置，所述linux内核包括第一操作系统内核和第二操作系统内核，所述处理装置包括存储器和处理器；所述存储器用于保存进行linux内核异常处理的程序，所述处理器用于读取执行所述用于进行linux内核异常处理的程序，执行上述实施例中任一项所述的方法。

本公开还提供了一种存储介质，应用于包括第一操作系统内核和第二操作系统内核的业务系统，所述存储介质中存储有进行linux内核异常处理的程序，所述程序被设置为在运行时执行上述实施例中任一项所述的方法。

与相关技术相比，本申请实施例主要通过双内核切换的方法，以达到把内核异常信息记录到存储设备、并自动复位系统的目的，使得安全设备能够在无人值守的情况下从内核异常中自动恢复，并记录相关异常信息方便管理员后续定位分析，迅速恢复业务接续，避免长时间业务中断。

在阅读并理解了附图和详细描述后，可以明白其他方面。

附图说明

图1为本申请实施例的linux内核异常的处理方法流程图；

图2为本申请实施例linux内核异常的处理设备示意图；

图3为一些示例性实施例中处理装置中的子模块与所述业务系统中各部分的连接关系示意图；

图4为一些示例性实施例中双内核架构子模块的工作原理示意图；

图5为一些示例性实施例中异常转存/恢复子模块的工作原理示意图；

图6为一些示例性实施例中内核异常记录日志示意图。

具体实施方式

本申请描述了多个实施例，但是该描述是示例性的，而不是限制性的，并且对于本领域的普通技术人员来说显而易见的是，在本申请所描述的实施例包含的范围内可以有更多的实施例和实现方案。尽管在附图中示出了许多可能的特征组合，并在具体实施方式中进行了讨论，但是所公开的特征的许多其它组合方式也是可能的。除非特意加以限制的情况以外，任何实施例的任何特征或元件可以与任何其它实施例中的任何其他特征或元件结合使用，或可以替代任何其它实施例中的任何其他特征或元件。

本申请包括并设想了与本领域普通技术人员已知的特征和元件的组合。本申请已经公开的实施例、特征和元件也可以与任何常规特征或元件组合，以形成由权利要求限定的独特的发明方案。任何实施例的任何特征或元件也可以与来自其它发明方案的特征或元件组合，以形成另一个由权利要求限定的独特的发明方案。因此，应当理解，在本申请中示出和/或讨论的任何特征可以单独地或以任何适当的组合来实现。因此，除了根据所附权利要求及其等同替换所做的限制以外，实施例不受其它限制。此外，可以在所附权利要求的保护范围内进行各种修改和改变。

此外，在描述具有代表性的实施例时，说明书可能已经将方法和/或过程呈现为特定的步骤序列。然而，在该方法或过程不依赖于本文所述步骤的特定顺序的程度上，该方法或过程不应限于所述的特定顺序的步骤。如本领域普通技术人员将理解的，其它的步骤顺序也是可能的。因此，说明书中阐述的步骤的特定顺序不应被解释为对权利要求的限制。此外，针对该方法和/或过程的权利要求不应限于按照所写顺序执行它们的步骤，本领域技术人员可以容易地理解，这些顺序可以变化，并且仍然保持在本申请实施例的精神和范围内。

针对linux内核缺陷类的攻击，往往造成网络安全类产品系统重启，甚至挂起的严重异常。如果内核重启，内核的异常栈信息通常打印到控制台（串口或显示器等）上，如果事先没有连接控制台，打印的内核异常栈信息也就消失了，进而导致维护人员不能及时发现、获取到异常栈信息，也无法进行分析导致异常的原因。如果内核异常造成系统挂起，整个设备不能运转，不能自动恢复系统，将导致出现断网的严重事故。

现有的linux系统在发生异常时通常有两种处理方式：

一种处理方式是利用linux内核的kdump机制进入另一个系统，kdump是一种内核崩溃转储机制，如果内核使用了kdump机制，当系统崩溃时，kdump机制会启动第二个内核，此时系统会停在第二个kdump内核中，等待管理员对系统崩溃信息（vmcore文件）进行手动分析处理，并重启恢复整个系统；但是，手动分析异常需要使用各种linux工具分析vmcore文件中的汇编代码，找到断言位置，对管理员技术水平要求非常高，往往难以找到对应的CVE（Common Vulnerabilities & Exposures，通用漏洞披露）。而且对于没有公布的漏洞，更加难以分析成因。而且手动恢复系统会造成漫长的断网时间，对一些对实时性要求很高的业务场景，往往会造成很大的损失。

另一种处理方式是不做任何处理，依赖linux内核自身的健壮性设计。这个时候系统有可能处于宕机状态，等待手动复位，这样同样会造成业务长时间无法恢复的问题；或是自动重启恢复业务，这样虽然业务能够短时间内恢复，但是此时错误现场已经被覆盖，无法定位问题原因，异常原因不可追溯。

本申请实施例提供了一种linux内核异常的处理方法，其中，所述linux内核包括第一操作系统内核和第二操作系统内核；所述处理方法如图1所示，包括步骤S110-S140：

S110、当第一操作系统内核异常时，捕获异常信息保存在内存中；

S120、启动第二操作系统内核；

S130、启动第二操作系统内核成功后，提取保存在内存中的所述异常信息，将所提取的所述异常信息保存到非易失性存储器中；

S140、重启所述第一操作系统内核，并复位硬件系统内核。

本申请实施例能够完成linux双内核的系统功能，并设计成在内核异常时双内核协同工作的运行机制。双内核的含义是系统包含以下两个内核：

1）业务内核，即上文的第一操作系统内核，它是用户业务场景的常驻操作系统内核。在不出现内核异常的情况下，这个内核是一直运行的。

2）救援内核，即上文的第二操作系统内核，在业务内核出现异常的情况下，负责记录异常信息的操作系统内核。它只在业务内核异常发生时短暂运行并自复位。

业务内核不能自己记录异常信息的原因是，往往当致命异常发生的时候，内核系统已经陷入崩溃（crash），此时业务内核已经无法正常访问硬盘等外设。所以需要另外一个正常运行的内核系统（即救援内核）来完成异常信息的记录和复位功能。

linux原生的kdump技术能在主业务系统发生某些内核异常时进入kdump内核系统，但是进入kdump系统后就会陷入静默等待的状态，无法自动恢复业务系统的运行，而本申请实施例的实现关键点就是避免这种系统挂起状态的产生。

Linux原生的kdump技术，只能在非常有限的几种内核异常下触发。而本申请实施例能够在几乎所有内核异常发生时触发双内核系统生效，自动完成一系列的相关操作。

本申请实施例在几乎所有内核异常情况下都能够触发设备重启并恢复到正常业务系统，保证最短业务中断时间；而且在几乎所有内核异常情况下，都能保证异常信息被记录到非易失存储设备（比如但不限于CF卡或硬盘灯）中，业务恢复后可随时查看。

本申请实施例用双内核系统以及处于互联网出口、处于大量高频率网络攻击下的高风险业务系统。针对内核的攻击是一种最底层的，对系统破坏力最大的攻击，本申请实施例能够在这种破坏下迅速恢复业务接续，避免长时间业务中断，并且能保留住异常信息。

一些示例性实施例中，所述启动第二操作系统内核前还包括：

所述第一操作系统内核初始化时在内存中预留预设大小的存储空间作为预留内存；所述第一操作系统内核启动后将所述第二操作系统内核的镜像文件导入所述预留内存；

所述启动第二操作系统内核包括：

跳转到所述预留内存中的所述第二操作系统内核，运行所述第二操作系统内核。

其它实施例中，不排除在其它时间节点、以其它方式进行内存的预留和第二操作系统内核镜像文件的保存，本申请对此不进行限制。

一些示例性实施例中，所述捕获异常信息保存在内存中包括：

将所述第一操作系统内核记录的异常信息编码存储到vmcore文件的note区域；

所述提取保存在内存中的异常信息包括：

从vmcore文件的note区域读取编码后的所述异常信息并解码。

双内核系统间的信息交换，以及核心有效异常信息的提取，是本实施例的一个重要的关键点。由于面对的是系统已经发生了致命异常，各种操作系统分析工具都已经失效的场景，因此这个时候通过vmcore文件的note区这种有效的加载信息的方式，才是最稳定的保存现场信息的方法。

其它实施例中，不排除采用别的方式在两个内核之间进行异常信息的传递，本申请对此不进行限制。

一些示例性实施例中，所述捕获异常信息包括：

按照不同的异常类型解析相应的信息存储为异常信息；所述异常类型包括：非法内存、软件死锁、内存耗尽、其它异常；当异常类型为非法内存、软件死锁和其它异常时，解析的信息包括：描述信息、寄存器信息和堆栈信息；当异常类型为内存耗尽时，解析的信息包括：描述信息、堆栈信息和内存占用排行。

在本实施例中，可以通过内核补丁的方式自动捕获非法内存、软件死锁、内存耗尽、其它异常这四类异常信息。

本实施例中，可以通过设计异常信息的记录功能，在第一操作系统内核中原生的各个系统异常点调用该功能以记录各类异常信息。

本实施例可以针对内核的各类错误，记录不同的异常信息。异常信息中包括了最容易被IT人员所理解的堆栈信息，这样不需要二次分析就可以了解到异常成因。

其它实施例中，可以根据需要和业务系统的情况自行设计不同异常类型时要记录哪些信息作为异常信息。本申请对于异常的类型、所解析并存储的信息的种类均不进行限制。

一些示例性实施例中，所述将所提取的异常信息保存到非易失性存储器中包括：

将所提取的异常信息保存为文本文件后，保存到非易失性存储器中；在所述文本文件中，所述异常信息按照信息的种类进行分类，同一种类的信息在所述文本文件中集中在一个区域进行展示；所述信息的种类包括：描述信息、堆栈信息、寄存器信息、内存占用排行。

本实施例可以将内核异常时的异常信息进行梳理，分类、展示，便于后续分析。本实施例中，对异常信息可以日志的形式进行展示，按照异常发生时间由近及远进行排序。每一次异常形成一条完整的描述，描述的示例格式如图6所示，包含的信息有：发生时间、描述信息、详细异常信息（如堆栈信息、寄存器信息、内存占用排行等）、记录结束标识。

linux原生的kdump技术在触发之后，并无法自动将异常信息展现、分类、存储下来，其生成的包含故障信息的vmcore文件的大小为物理内存等大，也就是说一个4G字节物理内存的服务器，单次故障产生的vmcore文件也有4G字节，很难进行导出离线分析操作。只能在本地进行分析，而且分析过程非常耗费人力，导致业务系统长时间瘫痪。本实施例有针对性的将故障信息进行提炼和存储，可以在故障恢复之后再进行分析。而且单次故障产生的一条记录也只有几百字节，非常方便导出分析。

其它实施例中，可以根据需要和业务系统的情况自行设计信息的种类，以及存储时的格式，本申请对此均不进行限制。

本申请实施例提供了一种linux内核异常的处理设备，其中，所述linux内核包括第一操作系统内核和第二操作系统内核；如图2所示，所述处理设备包括：

存储控制模块，用于当第一操作系统内核异常时，捕获异常信息保存在内存中；

内核控制模块，用于启动第二操作系统内核；

所述存储控制模块还用于在所述内核控制模块启动第二操作系统内核成功后，提取保存在内存中的所述异常信息，保存到非易失性存储器中；

所述内核控制模块还用于在所述存储控制模块将异常信息保存到非易失性存储器中后，重启所述第一操作系统内核，并复位硬件系统内核。

一些示例性实施例中，所述内核控制模块还用于当所述第一操作系统内核初始化时在内存中预留预设大小的存储空间作为预留内存；当所述第一操作系统内核启动后将所述第二操作系统内核的镜像文件导入所述预留内存；

所述内核控制模块启动第二操作系统内核包括：

所述内核控制模块跳转到所述预留内存中的所述第二操作系统内核，运行所述第二操作系统内核。

其它实施例中，不排除在其它时间节点、以其它方式进行内存的预留和第二操作系统内核镜像文件的保存，本申请对此不进行限制。

一些示例性实施例中，所述存储控制模块包括：

异常解释子模块，用于当第一操作系统内核异常时，捕获异常信息；

异常转存/恢复子模块，用于将所述异常解释子模块所捕获的异常信息编码存储到vmcore文件的note区域；以及当所述内核控制模块启动第二操作系统内核成功后，从vmcore文件的note区域读取编码后的异常信息并解码；

异常存储子模块，用于将解码得到的异常信息保存到非易失性存储器中。

其它实施例中，可以采用其它的子模块划分方式实现存储控制模块，本申请对此不进行限制。

其它实施例中，不排除采用别的方式在两个内核之间进行异常信息的传递，本申请对此不进行限制。

一些示例性实施例中，所述异常解释子模块捕获异常信息包括：

所述异常解释子模块按照不同的异常类型解析相应的信息存储为异常信息；所述异常类型包括：非法内存、软件死锁、内存耗尽、其它异常；当异常类型为非法内存、软件死锁和其它异常时，解析的信息包括：描述信息、寄存器信息和堆栈信息；当异常类型为内存耗尽时，解析的信息包括：描述信息、堆栈信息和内存占用排行。

其它实施例中，可以根据需要和业务系统的情况自行设计不同异常类型时要记录哪些信息作为异常信息。本申请对于异常的类型、所解析并存储的信息的种类均不进行限制。

一些示例性实施例中，所述异常存储子模块将解码得到的异常信息保存到非易失性存储器中包括：

所述异常存储子模块将解码得到的异常信息保存为文本文件后，保存到非易失性存储器中；在所述文本文件中，所述异常信息按照信息的种类进行分类，同一种类的信息在所述文本文件中集中在一个区域进行展示；所述信息的种类包括：描述信息、堆栈信息、寄存器信息、内存占用排行。

其它实施例中，可以根据需要和业务系统的情况自行设计信息的种类，以及存储时的格式，本申请对此均不进行限制。

下面用一个示例说明上述处理设备，所述处理设备应用在包括业务内核、救援内核、易失存储设备（如内存）和非易失性存储器的业务系统中；所述处理装置中的子模块与所述业务系统中各部分的连接关系如图3所示，包括以下子模块：

双内核架构子模块（即上文的内核控制模块），负责实现异常发生时从业务内核跳转到救援内核，在救援内核中重启恢复到业务内核的框架性子模块。

异常转存/恢复子模块，负责实现在业务内核中异常信息的转存，以及在救援内核中异常信息的恢复。

异常解释子模块、异常存储子模块，分别负责在业务内核中将异常信息进行解析和存储，以及在救援内核中对异常信息进行归类存储。

如图3所示，整个业务系统运作如下：双内核架构子模块负责调度两个内核的导入、启动、重置、复位。保证整个系统的运行链条能够正常完成整个异常信息记录并自恢复的过程；异常转存/恢复子模块完成异常信息在两个内核之间的传递以及恢复；异常解释/存储子模块完成具体的每一种内核异常的信息萃取，以及分类存储。

下面说明本示例中双内核架构子模块的工作原理，如图4所示，双内核架构子模块负责整个业务系统运作，正常情况下系统会在业务内核运转，遭遇异常后会进入救援内核进行异常信息的捕捉和记录，然后重启系统。

双内核架构子模块的关键技术点如下：

①业务内核启动初始化时，强制预留一定内存空间用于救援内核导入。

实现方式：内核编码修正内核cmdline参数实现相关功能。

实现函数/工具：void tb_adjust_x86_64_cmdline(char *cmdline) 修正linux启动内存预留参数。

②业务内核启动后，将救援内核的镜像文件导入预留的内存。

实现方式：在启动配置文件中加入相关操作；

实现函数/工具：kexec；

具体操作：kexec -p /mnt/boot/cap_kernel.img --initrd=/mnt/boot/cap_rootfs.img；

③业务内核遭遇异常后，跳转到预留内存中存储的救援内核，运行救援内核。

实现方式：内核编码调用kexec跳转函数；

实现函数/工具：void crash_kexec(struct pt_regs *regs)；

④救援内核完成异常信息的记录后，重启系统。

实现方式：在启动配置文件中加入相关操作

实现函数/工具：reboot

具体操作：reboot –f

下面说明本示例中的异常转存/恢复子模块的工作原理，如图5所示。

由于业务内核和救援内核是两个独立的操作系统，而在业务系统由业务内核向救援内核切换的时候，一方面业务内核已经陷入恐慌（panic）而无法访问硬盘，另一方面整个内存空间的存储数据是易失的，因此异常信息如何传递是该子模块的关键技术点。

linux操作系统在运行过中会维护一个vmcore文件，这个文件提供给kdump机制中的管理员，供分析异常原因所用，可以在两个内核之间传递。本示例中业务内核如果遭遇异常，会将需要记录的异常信息编码存储到vmcore文件的note区域。进入救援内核后，note区域存储的信息被读出并解码，获取到相应的异常日志。

异常转存/恢复子模块的关键技术点如下：

①实现业务内核向vmcore文件中编码、插入异常记录；

实现方式：内核编码实现相关功能；

实现函数/工具：

void tb_print_kdump(const char *fmt, ...)将异常信息进行编码格式化；

void tb_append_exception_to_vmcore_note(void)将异常信息插入vmcore文件的note区域；

②实现救援内核从vmcore文件中读取异常信息；

实现方式：开发/使用工具实现相关功能；

实现函数/工具：

readelf 文件信息提取工具

vmcore_note_parse 异常信息解码工具

具体操作：

readelf -n /proc/vmcore > /tmp/vmcore_note_info

将vmcore文件中的note区域的异常信息读取出来，存储到临时文件中；

vmcore_note_parse /tmp/vmcore_note_info /mnt/boot/exception.txt

将临时文件中的异常信息解码，记录到异常日志文件中。

其中，异常转存/恢复子模块是将异常解释子模块捕获并保存的异常信息编码插入vmcore文件，将所记录的异常日志文件发送给异常存储子模块，以保存到非易失性存储器中。下面说明本示例中的异常解释子模块、异常存储子模块的工作原理。本模块主要是深入挖掘各个内核异常的原因，梳理其在内核代码中的触发点，以及定位这些异常需要的信息。

其中，异常解释子模块所支持的、能够捕获的异常包括：

（1）非法内存(bad_area)：指内核中某个功能访问了非法地址。此情况需要解析并存储的内容有：

典型描述：unable to handle kernel pointer dereference at xxx

寄存器信息：此时运行现场的各种变量和寄存器的值；

堆栈信息：出现异常的功能前后的函数调用关系。

（2）软件死锁(soft lockup)：指内核中某个功能发生了死循环。这种问题是对用户业务系统危害最大的一种问题，一旦发生，业务系统将瘫痪无法自恢复。此情况需要解析并存储的内容有：

典型描述：soft lockup - CPU#0 stuck or xxxs!

寄存器信息：此时运行现场的各种变量和寄存器的值；

堆栈信息：出现死循环的功能前后的函数调用关系。

（3）内存耗尽(OOM) ：指整个操作系统的内存耗尽。此时情况比较复杂，有可能是系统内存不足。也有可能是某一个功能存在内存泄漏，或是被攻击导致内存泄漏。此情况最需要捕获足够的信息来定位，需要解析并存储的内容有：

典型描述：BUG: Kernel panic for Out of memory

堆栈信息：当前触发异常的内存不足事件前后函数调用关系，有一定参考意义，但很有可能并不是造成问题的根本原因。

内存占用排行：这是定位此类问题的重要信息，内存占用排行高的应用，往往是存在内存泄漏或是被攻击的应用。

（4）其他异常（trap）。上述三种异常是linux内核异常中占绝大部分的异常情况，还有一些不常见的异常，例如异常指令、除零异常等，本示例中也均可以捕获。此情况需要解析并存储信息包含：描述、寄存器信息、堆栈信息。

其中，异常存储子模块将异常日志文件中的异常信息按照信息的种类（如描述、堆栈信息、寄存器信息、内存使用情况等）分类保存在文本文件中，可以将一条异常信息保存为一条内核异常记录日志。

本示例中一条完整的内核异常记录日志如图6所示。其中内存占用排行、堆栈信息各自集中展示。

对于一个不断自完善的系统来说，不但需要从故障中迅速恢复，而且需要在事故之后有效分析出事故原因，有针对性的找到解决方法及补丁，避免后续再次出现同样问题。本示例中，能够将现场信息还原为简单易存储传递的文本文件；二是截取保留了典型的linux内核异常时典型描述的原语句，非常方便管理员去各类开源网站或是CVE公布网站去进行检索，及时有效获取相关的补丁。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质（或非暂时性介质）和通信介质（或暂时性介质）。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息（诸如计算机可读指令、数据结构、程序模块或其他数据）的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于 RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘（DVD）或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。