引言

DPDK作为一个被广泛应用的高性能网络开发套件，用户群体和开发者群体十分庞大。代码一旦出现问题，波及面十分广泛，容易造成重大经济损失。所以及时解决代码bug，是DPDK社区最应该重视的问题之一。一般用户或者开发者碰到有bug都可以向bugzilla提交bug，提交了以后会有专人跟进，及时解决。但是，如果这个问题不是一般的bug，而是容易造成重大影响的安全问题，情况似乎就不再是那么简单。本文把DPDK社区处理安全问题的一般流程给大家介绍一下，让大家心里有数，遇到类似的情况可以比较好地处理。

安全问题的发现与报告

可能这个时候很多人会产生一个疑问：什么是安全问题？其实很简单，如果用一句话说，就是如果一个问题能造成重大影响的话，那这个问题就属于安全问题。详细地说就是，如果这个问题造成的影响符合这三点之中的任何一点，则认为这个问题属于一个安全问题。第一，软件的数据不再安全，造成了一定程度的数据泄露；第二，软件的正确性不再得到保证；第三，软件的可靠性受到影响。

第一点很好理解，如果这个bug能造成数据泄露，让用户的数据安全得不到保证，则这个问题肯定是一个安全问题。第二点，软件的行为不再正确，那视程度而定看这个问题能不能带来安全隐患来判定其是否为安全问题。最后一点，如果这个软件提供的是一项服务，这个问题让这个服务不可用，或者不稳定，都是容易造成损失的，所以这也是一个安全问题。一般来说，DPDK社区只认可在主仓库或者DPDK-stable这两个仓库中的安全问题，别的仓库可以认为是临时仓库或者有别的用途的仓库，一般也不会有人会去把它部署在生产环境中，自然也就没必要去细究其中的问题。当然，DPDK-stable中不在维护期的仓库也同样如此。开发者或者用户们，如果不能确认自己发现的问题是不是一个安全问题，也可以先向DPDK的安全团队提交报告，DPDK的安全团队将会接手处理。

那可疑的安全问题应该怎么报告呢？安全问题不同于普通的问题，安全问题有可能造成严重的财产损失，所以我们在处理安全问题的时候尤其需要小心谨慎。原本用来报告普通问题的bugzilla是不能用来报告安全问题的，因为bugzilla的公开性，在这里报告问题，有可能让心怀不轨的人提前知道问题从而利用这个问题来达到一些不可告人的目的。报告一个安全问题，我们应该使用GPG加密，将加密后的邮件发送到security@dpdk.org ，任何人都可以向这个邮箱发送他们认为疑似的安全问题。为了将影响降低到最小，这个邮箱列表里的成员规模会控制的很小。不单单是在汇报阶段，在处理和沟通问题的过程中，我们也鼓励全程使用加密邮件沟通。安全问题跟普通问题一样，你提供的信息越多，相关的工作人员就能越快地查清楚问题原因并及时修复好。如果你已经有了这个问题的修复方案，那请你随着报告一起发给DPDK的安全团队，这样能大大加速整个处理过程。值得一提的是，在报告中，请你告知工作人员你需要得到怎么样的嘉奖。

DPDK 安全团队的成员会在收到问题报告后回复报告者，确认报告已经收到。随后他们会和一两个相关领域的专家一起查阅这份报告，如果最后的审查结果发现这不是一个安全问题，那么安全团队会联系报告者让其在bugzilla里报告这个问题。而如果这个问题最后确认是属于安全问题的话，那么安全团队将调查哪些版本的DPDK受到了影响，同时在bugzilla上创建一个私有条目，用以记录完整的处理过程，然后开始后续流程。

安全问题的处理流程

接下来跟报告者相关的事情就不多了，不过既然是科普，那就聊聊安全团队这个时候会有哪些动作。这个时候他们会用一个评分系统来评估这个问题的严重性也就是CVSS calculator。这个系统会根据你的输入信息最终产生一个分数，再根据报告人的意见，最终得出这个问题的严重性分数，也就是CVSS Score。然后再用这个CVSS Score去申请一个CVE (Common Vulnerabilities & Exposures) 号。

在处理安全问题的时候，会牵涉到一个信息解禁时间的概念，这个解禁时间安全团队会根据release时间的安排，报告人的意见，以及问题的严重性综合考量。当然，如果问题十分轻微，那可能也完全不需要解禁时间。信息解禁时间指的是所有的知情人约定一个时间，并在在这一天部署修复问题的补丁，然后公开这个问题的细节。这样就可以在问题曝光的同时修复好问题，尽量减少这个问题被不法分子利用的机会。一般来说解禁时间距离问题确认时间之间不能超过十周。如果这个问题不需要信息解禁时间，那只要按照正常的时间安排处理就行了。

安全团队会制定安全信息文档，这个一般是由安全团队和报告人员一起制定的。当文档完成后，安全团队需要向CAN(CVE Numbering Authority) 请求CVE号，来追踪处理这个问题。关于为什么要CVE号，这个大家可以自行查阅参考资料，有点复杂，本文就不再详细说明了。同样的，安全团队对CVE的请求也应使用GPG加密电子邮件。在走这些流程的同时，安全团队也在和指定的一两个相关领域的专家一起完成问题的修复工作，完成修复补丁后尽快进行测试工作，这样可以最大化地缩短问题修复时间。

安全问题的修复与公开

在修复的补丁准备好后，补丁和关于这个安全问题的相关建议将发送给DPDK社区的利益相关者们 (security-prerelease@dpdk.org)，并指定好信息解禁的日期和时间。通知信息的日期与公开日期的间隔应少于一周，以减少信息暴露风险。这些人不能提前部署或公开这个补丁，否则它们将被从利益相关者列表中删除。提前部署修复补丁或者暴露安全问题信息都是一种极其不负责任的行为。可能这里有人会好奇，DPDK社区的利益相关者主要是哪些人。其实他们主要是打包 DPDK软件包的操作系统供应商和DPDK技术委员会认为值得信赖的主要 DPDK 用户这两种群体。于此同时，安全团队的成员也会在信息解禁前一周内联系OSS Security (Open-Source Security) 私人邮件列表，描述漏洞的详细信息并提供修复补丁。发行版和主要供应商收到相应的通知后应有相应的动作，所有的邮件都要使用安全团队的成员GPG密钥签名发送。

在信息禁运期满时，安全团队会将所有安全问题的详细信息公开并将修复补丁推送到对应的分支，对于已修复的稳定分支，应发布新版本。一般来说首选周一至周三发布安全更新，这样各个组织的管理员就不必在周末加班了。一旦补丁被推送到相应的分支，安全团队还会将相应安全公告发布到announce@dpdk.org和OSS Security安全邮件列表，然后将补丁发送到dev@dpdk.org和 stable@dpdk.org。到此为止，一个安全问题才算处理完毕。

总结

处理一个安全问题的过程十分繁杂，这都是为了能尽可能地降低问题可能带来的损失。里面牵涉到了很多人，很多部门，甚至很多公司。大家通力合作，为了一个共同的目标。本文只是阐述了一个安全问题的基本处理流程，有很多特别的案例本文就不再啰嗦了，希望能帮助到DPDK社区广大的用户和开发者。

参考文献

1.https://doc.dpdk.org/guides/contributing/vulnerability.html

2.https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

转载须知

DPDK与SPDK开源社区

公众号文章转载声明

推荐阅读

SPDK NVMe-oF多路径结合Delay Bdev使用场景

SPDK发布v22.05版本

从SPDK Blobstore到 Blob FS

用户态虚拟化IO通道实现概览及实践（下）

点点“赞”和“在看”，给我充点儿电吧~