改进单片操作系统中内核服务调试的贡献 2013年 波尔多第一大学

对改进单操作系统中Tegawende Bissyande引用此版本：TegawendeBissyande。对改进单操作系统中内核级服务调试的贡献其他[cs.OH]。科学与技术大学-波尔多第一大学，2013年。法语。NNT：2013BOR14768。电话：00821893HAL ID：电话：00821893https://theses.hal.science/tel-00821893提交日期：2013年HAL是一个多学科的开放存取档案馆，用于存放和传播科学研究论文，无论它们是否被公开。论文可以来自法国或国外的教学和研究机构，也可以来自公共或私人研究中心。L’archive ouverte pluridisciplinaire订单号论文呈现在U来自B波尔多数学与计算机科学博士学院要获得以下等级：D产科医生 德 U级 来自B波尔多我提到了Nformatic通过Tegawende弗朗西斯阿欢迎团队博士学校：数学和计算机科学学术部分：LABRI论文标题：对改进单片操作系统中内核级服务调试的贡献对改进单片操作系统中内核服务调试的贡献2013年3月12日在审查委员会上答辩M.先生们。：泽维尔·伊夫奥拉夫白色莱德鲁斯平奇克主席报告员MM.：朱莉娅拉沃尔检查员大卫LO劳伦特启示录M. ：吉勒穆勒邀请感谢乔西从头到尾都在那里，感谢托尼·米歇尔的"父亲般的支持感谢我的母亲露西的勇气和自我牺牲。确认书如果没有几位独立学者的支持、帮助或指导，这篇论文是不可能的，他们以这样或那样的方式为我的大学研究的综合和完成做出了贡献，并提供了宝贵的帮助。其中一个人是博士。迈克尔医学博士Nikiema（Tonton Michel），他是我的父亲。我也知道我母亲露西·比斯-西安德的勇气，她在Ouindpouiré Josiane Sedogo在整个博士经历中一直支持我，我将继续感谢她。我还想提到我的兄弟姐妹，特别是Flore Bissyandé，他们总是支持我。在研究界，我非常感谢几位指导我完成这篇论文的研究人员和教师。我特别感谢INRIA的研究主任Olivier Beaumont，他是我在工程学校遇到的最好的老师。我谨向波尔多大学教授Xavier Blanc教授表示最深切的感谢，他慷慨地接受担任我的辩护委员会主席。第二，特别感谢格勒诺布尔大学的Yves Ledru教授和柏林大学的Olaf Spinczyk教授，他们同意在委员会开会之前审查我的论文。我还要感谢其他委员会成员Julia L. INRIA研究主任Lawall、新加坡管理大学助理教授David Lo和我的论文导师、波尔多理工学院副教授LaurentRéveillère我还要感谢INRIA的研究主任Gilles Muller，他的指导意见被纳入了整个论文。我想认识一下我在法国结交的朋友：LABRI CVT的朋友：雷米·拉普拉斯（和JDB）、乔纳森·乌巴、热雷米·阿尔伯特、达米安·杜伯内、雨果·巴拉西、达乌达·艾哈迈德、西里尔·卡萨涅、吉加尔·索兰基、文森特·奥特法奇、泰勒斯福尔·蒂恩德雷博戈和塞巴斯蒂安·宾德尔。LaBRI博士生：Thomas Morsellino、Florent Foucaud、Vincent Filou、Vincent Rabeux和Yi Ren。最后，我永远欠上帝的债，他使一切成为可能。··摘要尽管存在大量关于系统软件质量的研究，但操作系统仍然存在可靠性问题，主要是由内核级服务（如设备驱动程序和文件系统）的缺陷引起的。研究表明，Linux内核的每个版本都包含600到700个错误，并且设备驱动程序包含错误的倾向比内核的任何其他部分都高7倍。这些数字表明，内核级别的服务代码没有经过充分的测试，许多缺陷仍然没有被注意到，或者对于占大多数服务开发人员的非专家程序员来说很难修复。本文提出了一种新的内核级服务调试和测试方法，重点关注服务与内核之间的交互。该方法解决了内核API函数实现中的安全漏洞问题。对于Linux，我们已经实例化了诊断系统自动化方法，该方法依赖于内核代码的静态分析，以识别、分类和暴露API函数的各种安全漏洞，当开发人员在服务代码中使用这些函数时，这些漏洞可能会变成运行时故障，而这些开发人员对内核代码的复杂性了解有限。为了说明我们的方法，我们已经实现了Linux 2.6.32的诊断系统，并证明了它非常适合支持开发人员的测试和调试任务。本文的贡献是：我们将内核导出函数的接口确定为可以插入调试信息生成的最佳点，以提高可调试性但不引入过多运行时开销的方式。我们将安全漏洞识别为服务和内核之间接口中的重大问题。尽管如此，在703个Linux2.6提交中，更改日志明确引用了Linux 2.6.32中导出的函数，38%的错误与我们确定的安全漏洞之一有关因此，尽管我们可以假设树内内核代码比正在开发的新服务代码经过了更彻底的测试，但违反这些安全漏洞仍然会导致大量的崩溃和挂起。在本文中，我们提出了Linux内核中这些安全漏洞的扩展特征化我们提出了一种方法，允许服务开发人员无缝地生成、集成和利用专门针对服务代码的内核调试接口。这种方法具有较低的学习曲线，特别是不需要任何特定的Linux内核专业知识。通过对10个Linux内核服务的错误注入实验，我们证明了我们的方法在可调试性方面的改进。我们发现，在90%发生崩溃的情况下，日志包含与缺陷来源相关的信息，在95%的情况下，与崩溃相关的消息是最后一条记录的信息。我们还发现，在93%发生崩溃或挂起的情况下，日志信息减少了为查找错误原因而必须访问的文件数量。我们表明，生成的调试接口在服务执行时仅减少了最小的运行时开销，允许其在早期部署中使用。除了操作系统软件之外，本文中描述的诊断方法可以应用于任何基于插件模型的软件，其中编写扩展代码以通过不断扩展的接口与核心软件交互并补充核心软件。所提出的解决方案为改进此类软件的调试开辟了新的可能性。关键词诊断、调试、包装、Linux、设备驱动程序、软件工程、可靠性、测试。·····八摘要虽然对系统代码质量的研究已经取得了巨大的成功，但操作系统仍然受到可靠性问题的困扰，特别是由于核心服务（如设备驱动程序和文件系统实现）中的编程错误。研究表明，每个版本的Linux内核都包含600到700个错误，而设备驱动程序的错误倾向是内核的错误率比内核的任何其他部分都高出7倍。这些数字表明，内核服务代码本文提出了一种调试和测试内核服务的新方法。我们的方法通过解决内核API函数定义代码中的"安全漏洞"问题，专注于内核服务和核心内核之间的交互。在Linux内核的上下文中，我们实现了一种称为诊断的自动化方法，该方法依赖于内核代码的静态分析来识别、分类和暴露各种API安全漏洞，这些漏洞在由对内核复杂性知之甚少的开发人员编写的服务代码中使用函数时可能导致运行时错误为了说明我们的方法，我们为Linux内核版本2.6.32实现了诊断系统我们已经展示了它在支持开发人员的测试和调试活动方面的优势本文的贡献如下：我们将从内核导出的函数的接口标识为可以插入调试信息生成的方便位置。这样做是为了在不引入过多的执行开销的情况下改进调试我们认为安全漏洞是内核服务和中央内核之间接口中的一个重要问题。事实上，在703个Linux 2.6提交中，有38%的提交解决了与API函数使用明确相关的错误，其中一个提交解决了与我们发现的安全漏洞相关的错误。因此，虽然我们可以假设Linux开发人员维护的内核中的代码比正在开发的新服务经过更好的测试，但安全漏洞的破坏已经导致了大量的崩溃和挂起在本文中，我们提出了Linux内核中这些安全漏洞的扩展特征。我们提供了一种方法，使服务开发人员能够无缝地生成、这种方法的学习曲线很短基于对10个内核服务的错误注入实验，我们展示了我们的方法在调试方面的改进。我们发现，在90%发生崩溃的情况下，调试日志包含有关故障原因的信息，而在95%的情况下，与崩溃相关的消息是记录的最我们还发现，在93%发生崩溃或系统冻结的情况下，日志信息有助于减少在调试期间需要访问的文件数量，以找到错误的原因。····十一我们展示了生成的调试接口如何在正常的服务执行上添加一个最小的执行开销，使其能够一直使用到预部署阶段。除了操作系统代码之外因此，所提出的解决方案为改进此类应用的开发开辟了新的可能性关键词诊断，调试，Linux，设备驱动程序，软件工程，可靠性，测试·十四文档概述我们提供了组成这篇论文的三个部分和章节的法语摘要。第一章。在引言中，我们在单片操作系统（OS）的背景下激发了论文的动机这些类型的操作系统不会将内核与扩展（如设备驱动程序）分开，这些扩展通常由第三方完成。因此，在这些扩展中的任何一个中引入的故障都可能导致整个系统的故障。不幸的是，因此，我们提出了一种基于识别Diagnosys工具的实现我们已经通过实验验证了这些贡献第一部分：背景和技术状况本节回顾了论文的背景，并有一章深入探讨了论文的动机。第二章。我们专注于Linux，一个单一的操作系统。我们描述了我们对Linux内核API研究的观察结果。这些API依赖于调用时很少检查的前提条件。不幸的是，它们的记录很少，而且不断演变。这样的属性会导致（1）无法充分控制API的开发人员滥用API，以及（2）第三章。在本章中，我们将重点介绍Linux内核中最常见的错误类型。故障分类是从周和的研究中借用的[CYC+ 01]。我们还讨论了这些故障导致的故障类型（崩溃和冻结）。最后，我们回顾了各种技术，这些技术可以检测故障或减轻其后果。然而，我们发现，这些技术的范围往往过于有限。第四章许多因素削弱了Linux API。其中，• 缺乏鲁棒性，旨在不影响性能• 提议的职能及其特征的不断演变• 功能过多且此外，调试也很困难，因为崩溃日志中提供的信息性消息 最后，在发生所有这些都需要新的自动化工具十三第五章。在我们的工作中，我们优先考虑各种bug搜索技术中的分析。在本章中，我们将回顾静态分析中的一些重要概念：完整性、校正、假阳性、假阴性。然后，我们介绍了Coccinelle [PLHM08]，这是然后，我们展示了我们的Coccinelle，尽管最初仅设计用于程序内分析，但如何第六章。本章回顾了第一部分的要点，并宣布了第二部分所述的贡献。第二部分：安全漏洞的识别第七章 本章详细介绍了安全孔概念的定义。这本章将讨论Linux内核中安全漏洞的实际示例然后，我们区分了输入安全漏洞和退出安全漏洞，前者是驱动程序代码错误调用内核，后者是驱动程序错误使用内核调用结果然后提出了安全漏洞的分类：对于Palix等人[ PST + 11 ]的实证研究中定义的每种类型的bug第八章。在本章中，我们将介绍用于开发诊断方法的不同工具。这SHAna是DIGen是调试接口生成器• CRELSys，持久日志备份和热重启机制第九章。本章说明如何我们表明，诊断系统在CRELSys循环缓冲区中记录的最后一条消息通常与识别导致系统故障的故障相关第三部分：评估该第十章。在本章中，我们将评估诊断方法的需求和优势。因此，我们首先展示了SHAna可以发现数千个安全漏洞。接下来，我们通过对内核提交的研究表明，38%的API函数使用修复最后，通过一个有针对性的实验，我们将错误注入到10个核心服务中，以产生崩溃和冻结，我们证明了诊断系统在提供有关错误原因和起源的相关信息方面是有效的··十四第十一章。本章专门讨论Diag-nosys方法的增量成本评估。 D’autre part nous évaluons le laperte de performance à l’exécution liée à la vérification这些评估表明，诊断的成本是可以承受的。第十二章。 第12章结束了这一论点。 我们回顾了 在我们勾勒出前景之前，我们先做好准备 D’autre part, nous émettons l’idée de la correction automatique des bogues découverts avec内容物1简介11.1本论文。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...21.2捐款。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...31.3文件概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...3我 背景52整体式操作系统72.1操作系统. . . . . . . . . . . . . . . . . . . . . . . . . . . . ...82.2单片操作系统的一般原则。. . . . . . . . . . . . . . . . . . . . . . . .92.3插件软件体系结构102.3.1可加载内核模块102.3.2API使用挑战112.4Linux案例研究122.4.1开发模式122.4.2内核导出函数132.5摘要153处理系统故障– Testing, Debugging, Recovery –3.1内核故障173.1.1内核崩溃183.1.2内核挂183.2内核19中的缺陷3.3系统故障：如何处理？.....................................................................................................203.3.1系统稳健性测试203.3.2自动化操作系统软件生产213.3.3从操作系统故障中恢复213.3.4记录223.3.5静态错误查找223.3.6实现健壮接口233.3.7使用合同进行编程233.4摘要24十七4支持Linux内核级服务开发人员4.1API安全漏洞264.1.1实施特质264.1.2不稳定的API264.1.3未记录的API264.1.4大型API274.2其他调试信息274.3低开销动态监控274.4可靠的碰撞信息检索284.5摘要305静态程序分析315.1静态分析的一般原理325.1.1错误发现325.1.2API使用协议335.1.3分析故障335.2甲壳虫355.2.1SmPL35样品5.2.2程序间分析385.3摘要386论文步骤416.1问题416.2方法和步骤42II拟议方法457安全孔的特征477.1安全孔示例477.1.1API函数参数487.1.2错误处理策略497.1.3关键部分517.1.4启用和禁用中断517.2安全孔分类527.2.1方法论527.2.2分类学537.3摘要558诊断系统578.1SHAna：安全孔分析仪588.1.1前提推理理论598.1.2分析过程608.1.3认证流程638.2DIGen：调试接口生成器648.2.1生成调试接口658.2.2将调试接口集成到服务中内容十九8.3CRELSys：抗碰撞高效记录系统678.3.1任意内核内存区域中的环缓冲区8.3.2快速、非破坏性系统重启688.4摘要699使用诊断系统71进行内核调试9.1重新播放内核崩溃719.2重新播放内核挂739.3摘要74III评估7510 诊断系统77的机会和优势10.1 内核代码77中安全漏洞的普遍性10.2 安全漏洞对代码质量的7810.3 可调试性的改进7910.3.1 诊断的覆盖范围7910.3.2 调试过程的简易性8010.4 摘要8111 开销8311.1 分析结果的间接认证8311.2 服务执行开销8511.2.1 原始诊断系统引入的惩罚8511.2.2 诊断对服务性能8611.3 摘要8612 第89章12.1 捐款8912.1.1 安全孔的表征9012.1.2 诊断系统9012.1.3 调试的好处9012.1.4 有限开销9012.2 正在进行的工作和未来的工作9112.3 结论性意见91A 相关内核基元93A.1锁定功能93A.2中断管理功能93A.3结合锁定和中断管理的93A.4内核/用户访问基元93