对改进单片操作系统特加文德·比西安德引用此版本：TegawendeBissyande. 对 改 进单 片 操 作系 统 内 核 级服 务 调 试的 贡 献Autre [cs.OH]. UniversitéSciences et Technologies - Bordeaux I，2013.法语NNT：2013BOR14768。电话：00821893HAL Id：tel-00821893https://theses.hal.science/tel-008218932013年5月13日提交HAL是一个多学科的开放获取档案馆，用于存放和传播科学研究文件，无论它们是否已这些文件可能来自法国或国外的教学和研究机构，或来自公共或私人研究中心。L’archive ouverte pluridisciplinaire订单THAPOSEPrésentée devantLDEB ORDEAUX数学与信息博士学校pour obtenir le grade de：D OCTEUR DE L 'U NIVERSITTHEY DEB ORDEAUX提及一parTegawendé FrançoisÉquipeÉcole Doctorale：Mathématiques etInformatique大学组成：LABRITitre de la thèse：提高单片操作系统内核级服务可扩展性的贡献对改进单一开采系统中Noyau服务开发的贡献2013年3月12日在委员会检查后继续M.：嗯。：泽维尔·伊夫奥拉夫BLANCLEDRUSPINCZYK主席报告员毫米：朱莉娅LAWALL考官大卫LO洛朗雷韦亚尔M. ：Gilles穆勒因维特乔西为我们表演，米歇尔为我们寻找还有我妈妈露西为了他的勇气和放弃。确认如果没有几位独立人士的支持、帮助或指导，这篇论文是不可能完成的，他们以这样或那样的方式为我的大学学习做出了贡献，并提供了宝贵的帮助这些人中有博士。米歇尔医学博士Nikiéma（tonton Michel）对我来说就像父亲一样我还要感谢我母亲露西·比斯安德的勇气Ouindpouiré Josiane Sedogo在整个博士经历中一直支持我，我将永远感谢她。我还想提到我的兄弟姐妹，特别是Flore Bissyandé，他一直支持我。在研究界，我感谢几位研究人员和教师，他们引导我实现了这篇论文。我特别感谢认识INRIA的研究主任Olivier Beaumont，他是我在工程学院遇到的最好的老师。我要向波尔多大学的泽维尔·布兰克教授表示最深切的感谢，他优雅地接受了我的辩护委员会主席的职位。其次，特别感谢格勒诺布尔大学的Yves Ledru教授和柏林大学的Olaf Spinczyk教授，他们同意在委员会开会之前审查我的论文文件。我还要感谢其他委员会成员，朱莉娅L。Lawall，INRIA研究主任，David Lo，新加坡管理大学助理教授，Laurent Réveillère，我的论文导师，波尔多理工学院副教授我还要感谢INRIA的研究主任Gilles Muller，他的指导贯穿于整个论文。首先，我要感谢我在法国结识的朋友CVT在LaBRI的朋友：Rémi Laplace（and JDB），Jonathan Ouoba，Jérémie Albert，Damien Dubernet，Hugo Balacey，Daouda Ahmat，Cyril Cassagnes ，Jigar Solanki，Vincent Autefage，Télesphore Tiendrebeogo and Alfretien Bindel.LaBRI的其他博士生：Thomas Morsellino，Florent Foucaud，Vincent Filou，VincentRabeux和Yi Ren。最后，我一如既往地感激上帝，他使一切成为可能。··摘要尽管对系统软件的质量进行了大量的研究，但操作系统仍然受到主要由内核级服务（如设备驱动程序和文件系统）缺陷引起的可靠性问题的困扰。研究确实表明，Linux内核的每个版本都包含600到700个错误，设备驱动程序包含错误的倾向比内核的任何其他部分高出7倍这些数字表明，内核级服务代码没有经过充分的测试，许多错误仍然没有被注意到，或者很难被占大多数服务开发人员的非专业程序员修复本文提出了一种新的方法来调试和测试内核级服务，专注于服务和核心内核之间的交互。该方法解决了内核API函数实现中的安全漏洞问题。对于Linux，我们已经实例化了Diagnosys自动化方法，该方法依赖于对内核代码的静态分析来识别，分类和暴露API函数的不同安全漏洞，当开发人员在服务代码中使用这些函数时，这些漏洞可能会变成运行时故障，这些开发人员对内核代码的复杂性了解有限为了说明我们的方法，我们已经实现了Linux 2.6.32的诊断系统，并显示了它的好处，适合支持开发人员在他们的测试和调试任务。本论文的贡献在于：我们确定的接口内核导出的功能作为一个甜蜜点，它是可能的，以提高可调试性，但不引入过多的运行时开销的方式，以确保生成的调试信息。我们确定安全漏洞作为一个显着的问题，在一个服务和内核之间的接口。事实上，在703个Linux 2.6提交中，更新日志明确引用了Linux 2.6.32中导出的函数，其中38%的错误与我们确定的安全漏洞有关因此，尽管我们可以假设树内内核代码比开发中的新服务代码经过了更彻底的测试，但违反这些安全漏洞仍然会导致许多崩溃和挂起。在这篇论文中，我们提出了一个扩展的Linux内核的这些安全漏洞的特征我们提出了一种方法，允许服务开发人员无缝地生成，集成，并利用专门的服务代码的内核调试接口。这种方法具有较低的学习曲线，特别是不需要任何特定的Linux内核专业知识。使用10个Linux内核服务的故障注入实验，我们证明了我们的方法提供的可调试性的改善。我们发现，在发生崩溃的90%的情况下，日志包含与缺陷起源相关的信息，并且在95%的情况下，与崩溃相关的消息是记录的最后一条信息。我们还发现，在93%的崩溃或挂起发生的情况下，日志信息减少了必须查阅的文件数量，以找到错误的原因。我们表明，生成的调试接口只会在服务执行时产生最小的运行时开销，允许它通过早期部署使用。除了操作系统软件之外，本文中描述的Diagnosys方法可以应用于任何基于插件模型的软件，其中编写扩展代码以通过不断扩展的接口与核心软件进行因此，所提出的解决方案为改进这种软件的调试开辟了关键词诊断软件，固件，包装器，Linux，设备驱动程序，软件工程，可靠性，测试.·····VIII简历通过对系统代码质量的研究，发现开发系统的可行性问题主要是由于开发系统的试点和系统的实施。Des études ont en effet montré que que chaque version du noyau Linux content entre 600et 700 fautes，et que la propension des pilotes de périphériques如果有错误，我们就应该把所有的错误都排除在外。这些问题表明，目前的服务准则不足以进行测试，而且许多缺陷都不合格，或者很难让非专家程序员回答，这些缺陷主要是由于服务缺陷造成的这就提出了一个新的方法来检验新的服务。Notre approche est focalisée sur l'interactionentre les services noyau and le noyau central en abortant a question of“trous de souvenreté”dans lecode de definition des functions de l'API du noyau.在noyau Linux的环境中，我们使用了一种自动化的方法，即Diagnosys，它可以对noyau的代码进行标识符统计分析，对API的不同属性进行分类和分类，这些属性可以代替执行错误，因为这些函数在服务代码中被用户使用，但这些用户对noyau的细节有一个认识上的限制为了说明我们的方法，我们安装了用于Linux 2.6.32版本的诊断系统。我们要在蒙特利尔的试验和设计活动中取得进步，以支持这些失败者。这些贡献来自于以下几个方面：Nous identifions l'interface des fonctions exportées du noyau comme un endroit opportunopportail est possible d'interferor la génération des information de débogage.这一干预措施是现实的，因为它使预算更加合理，但没有引入一个过度执行的程序Nous identifions les trous de sécurité comme un problem important dans l'interface entre lesservice noyau et le noyau central.实际上，Linux 2.6的703个提交解决了一个明确使用API的问题，38%的错误被纠正到我们所识别的安全漏洞中。此外，我们假设，由于Linux的故障，在新的维护中的代码很好地测试了一个新的服务，这些服务违反了安全规则，并导致了大量的崩溃和挂起在这一点上，我们提出了一个新的Linux系统的特征。我们建议采用一种渗透性、表面透明的方式，以使一般服务更加透明、完整，并利用一种服务代码专用的界面Cette approche a une faible courbe在此基础上，我们对10项服务进行了改进，使我们的改进方案在改进期间得以实施。我们认为，在90%的事故中，事故相关的信息来源于事故日志，而在95%的事故中，与事故相关的信息是最重要的信息我们认为，在93%的事故案例中，或在系统失效的情况下，在调查事故原因后的阶段，在期刊上提供的信息可能会记录到事故发生时的胶片名称。····XiNous montrons que l'interface de débogage générée rajoute une surcharge d'exécution mini-male sur l'exécution normale de service，lui permettant d'être utilisée jusqu'en phase de pré-deploiement.在开发系统代码的基础上，开发诊断软件可以将这些代码应用于所有基于插件模式的应用程序中，而扩展代码则是为交互而产生的，并可以为我们提出的解决办法是默茨克莱斯Diagnosys，Débogage，Linux，Pilotes de périphériques，Génie Logiciel，Fiabilité，Test·XIV文件目录我们建议三个当事人的法文简历和构成该文件的章节。第一章在导言中，我们在单一开采系统的背景下提出了这一问题，这些系统在我们的业务中得到了进一步的利用这些SE类型不应被看作是扩展的核心，就像Périphériques的试点一样，它应该是按层实现的。因此，在这些扩展中引入一个错误可能会导致整个系统的缺陷。Malheureusement，我们的建议是基于对noyau的编程接口（API）中的“安全漏洞”的识别，以及对本地化程序的统计分析技术的La réalisation de我们确认了这些经验性的贡献。第一部分：艺术的背景与现状这一部分是根据主题的背景和一个深刻的动机编写的。第二章我们专注于Linux，一个SE单体。Nous décrivons les observa- tions de notre étude desAPIs de noyau de Linux.这些APIs代表了对上诉进行控制的前提条件。Malheureusement，ellessont peu documentées et évoluent constamment.在所有权方面，（1）开发人员对APIs的大量使用不足以满足需求，（2）在使用API的服务中出现故障第三章在这一章中，我们对Linux内核中的错误类型进行了分析。错误的分类是根据周恩来的一本书进行的。[CYC+ 01]。我们讨论了各种故障（碰撞和凝胶）。因此，我们通过各种各样的技术来检查错误，从而解决问题。当然，我们认为这些技术的应用是有限的。第四章Linux的API是脆弱的。其他人也一样• 为了不惩罚那些表演，• 拟议职能和法律签字的不断演变• 职能和相关文件缺失方面的重大问题此外，由于事故日志中的信息不完整，因此事故日志很难发布 最后，在事故发生后对错误信息进行统计分析并不令人满意，因为这些信息不连续，相关信息不存在Tous ces élémentsplaident en faveur de nouveaux outils automa- tisésXIII第五章在我们的工作中，我们将优先分析研究博格的各种技术。在这一章中，我们提到了统计分析中重要的概念：复杂性、纠正、假正面、假负面。Nous presésentons ensuite Coccinelle[PLHM 08]，Nous montrons ensuite comment nous Coccinelle，bien qu第六章该主席报告了第一党的重要观点，并宣布了第二党的贡献。第二部分：确定安全第七章 本章详细介绍了安全孔概念的定义。他想用一段代码来解释这个问题，但前提是不Linux之夜的所有支持者都在这本书中讨论。Nous faisons ensuite la distinction entre unentrysafety hole ， optimle noyau est appelé applément par le code du pilote ， et unexit safety holeoptimle résultatUne taxonomie des trous de soccureté est ensuite proposée：pour chaque type debogue defini dans第八章在本章中，我们提出了各种不同的实际问题，以便于达到诊断目的。他SHAna，DIGen，le générateur de• CRELSys，le mécanisme de sauvegarde persistant des logs et de redémarrage chaud.第九章第一章阐述了诊断系统在两种故障中的应用，包括第一次系统崩溃和第二次凝胶我们认为，在CRELSys的循环缓冲区中由Diagnosys注册的最新消息与系统故障的识别符相关。第三部分：评估方法的第十章在这一章中，我们评估了诊断的必要性和基础。在我们看来，沙娜可能会获得数百万美元的奖学金。我们的团队在此对今天的任务进行了一次研究，其中38%的API功能利用率的修正都是在后台进行的Enfin grâce à une exérimen- tation ciblée durant laquelle nous avonsinjection des fautes dans 10 services noyau pour produire des crashes et des gels，nous montronsque Diagnosys est efficace pour fournir des information perti- nentes sur la cause et··XIV第十一章这一章是对我们的诊断方法的补充的评价。 D’autre part nous évaluons le la perte deperformance à l’exécution liée à la vérification这些评估表明诊断的成本是可支持的。第12章 这是我的第一个想法。 Nous y rappelons les contributions de 我们要先看 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插件软件架构2.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.2Kernel19中的错误3.3系统故障：该怎么办？.....................................................................................................203.3.1系统稳健性测试203.3.2操作系统软件生产自动化213.3.3从操作系统故障中213.3.4伐木223.3.5静态bug查找223.3.6实施健全的接口233.3.7合同方案编制233.4摘要.24XVII4支持Linux内核级服务开发人员254.1API安全孔264.1.1执行特点4.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.2Coccinelle355.2.1SmPL35样品5.2.2程序间分析385.3摘要386步骤416.1问题416.2方法和步骤II拟议办法457安全孔的特征477.1安全孔47的示例7.1.1API函数参数487.1.2错误处理策略497.1.3关键部分517.1.4启用和禁用中断517.2安全孔的分类527.2.1A.方法527.2.2Taxonomy537.3摘要558Diagnosys578.1SHAna：安全孔分析仪588.1.1Theory of precondition inference前提推理598.1.2分析过程608.1.3认证过程638.2DIGen：接口生成器648.2.1生成调试接口658.2.2将调试接口集成到服务中67目录.十九8.3CRELSys：抗崩溃高效测井系统678.3.1在任意内核内存区域678.3.2快速和非破坏性的系统重启688.4摘要699使用Diagnosys71进行内核调试9.1重放内核崩溃719.2重放内核挂起739.3摘要74III评估7510 Diagnosys77的机会和优势10.1 内核代码77中的安全漏洞10.2 安全漏洞对代码质量10.3 改进可调试性7910.3.1 Diagnosys79的覆盖范围10.3.2 调试过程的简易性8010.4 摘要8111 间接费用8311.1 分析结果的认证开销8311.2 服务执行开销8511.2.1 Diagnosys primitives引入的惩罚8511.2.2 Diagnosys对服务性能8611.3 摘要8612 结论8912.1 捐款8912.1.1 安全孔的表征9012.1.2 Diagnosys9012.1.3 经济效益9012.1.4 有限的间接费用12.2 正在进行和今后的工作9112.3 结束语.91A Relevant kernel primitives相关内核原语93A.1锁定功能93A.2电子邮件管理职能A.3结合锁定和中断管理的93A.4内核/用户域访问原语93
我的内容管理
展开
