TECH

引言 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

引言 随着计算机硬件资源整合的发展，虚拟化的研究与应用日新月异。Virtio/Vhost作为一种设备虚拟化的典型应用，在业界受到了广泛的关注。Virtio 最开始由Rusty Russell在其2008年发表的论文[1]中提出，其先进性不言而喻，除了各种在Virtio Spec规范内对其的优化外，Virtio Spec本身也在逐步演化，到现在Virtio已经有了1.1版本。 异步模式的Vhost/Virtio就是这些优化之一。异步Vhost这个概念在DPDK中已经存在了一年多了，从一开始只支持split ring到后来DPDK 21.05里对packed ring支持的引入，可见异步Vhost已经日渐成熟。本文将从packed ring的ring结构，工作方式，其优缺点，以及异步模式的特点，实现与性能等方面逐步对其展开介绍。 Virtio & Vhost 虚拟化技术背景 在介绍Virtio/Vhost之前，虚拟化相关的技术背景不可不提。虚拟化(Virtualization)技术的普及，是计算机产业发展迅猛，硬件性能急速提升带来的必然结果。从根本上说，虚拟化是一种技术，这项技术可以利用局限于硬件的资源来创建灵活多变的 IT 服务。它让人们能够将物理计算机的工作能力分配给多个用户或多个环境，从而充分利用计算机的运算能力。 虚拟化技术的应用，优化的是计算机计算资源的分配，使得计算资源能够在一个相对细粒度的范畴进行切割分配。这实质上得利于计算机硬件的高速发展，单台物理机器的计算资源十分丰富，丰富到若以传统单台物理机作为基本资源切割单位话，容易造成计算资源的极大浪费。于是，虚拟化技术的应用需求应运而生。 虚拟化技术，基本可以分为两类，一类是全虚拟化(Full virtualization)，一类是半虚拟化 (Paravirtualization)。下面将从这两个分类说起，简单聊聊他们各自的特性。 全虚拟化(Full virtualization)，顾名思义，指的是完全虚拟化。使用这种虚拟化技术能让客户系统(Guest OS)不知道自己运行在一个虚拟环境中。全虚拟化技术提供底层物理系统的全部抽象。客户系统与运行在裸机上的系统相比并没有什么区别，这样带来的好处显而易见，就是模拟环境对客户机操作系统没有任何特别的要求。但是这样带来的坏处也不可忽视，就是由软件提供的硬件模拟势必带来一定的性能损耗。由于全虚拟化的性能损耗不可忽视，半虚拟化(Paravirtualization)找到了它的用武之地，这是另一种虚拟化热门技术。它使用虚拟机管理程序(Hypervisor)分享底层的硬件，客户操作系统集成了虚拟化相关的代码，这种方法因为操作系统自身能够与虚拟进程进行很好的协作，所以性能损失很小，大大提升了虚拟化的性能利用率。缺点就是客户系统中需要运行特定的驱动程序，客户系统需要感知到自己其实是一个虚拟系统，兼容性不是那么强。 由于半虚拟化技术具有非常强劲的性能和相对容易克服的缺点，使得它成为了目前业界的主流应用方案之一。Virtio/Vhost就是一套流行开放的半虚拟化前后端通信标准，在实际生产环境中应用非常广泛。用Virtio/Vhost这套标准可以实现很多设备的模拟，例如网络，硬盘，串口设备等。详细的Virtio/Vhost介绍可以查阅Virtio Spec[2]。本文主要叙述异步路径下packed ring的原理和实现，并与split ring做一定的对比分析。 Virtio与Vhost的基本通信原理 Virtio/Vhost是一套半虚拟化前后端通信标准，我们一般称Virtio为前端Driver，后端Vhost为Device。典型的Virtio/Vhost需要先通过socket通信建立数据面通信连接，数据面通信主要通过共享内存的方式进行。前后端收发包都是基于前端作为生产者，后端作为消费者的一套通信机制。例如前端要将数据发到后端，那么前端提供写好数据的内存区域，后端读取并复制到相应的地方。如果是前端要接收后端发送的数据，也是由前端提供空闲的内存区域，后端将要发送的数据复制到这些内存区域，整个过程简单且高效。 在Virtio 1.1以后存在两种前后端通信的queue结构。一种是一开始就存在的split ring结构，一种是在Virtio 1.1新引入的packed ring结构。下面我将讲讲这两种ring结构的异同，以及他们之间的性能对比，以帮助大家更好的了解packed ring。 Split Ring和Packed Ring 从split ring说起，ring结构上，split ring把descriptor环形缓冲区(descriptor ring)，可用环形缓冲区(available ring)和已用环形缓冲区(used ring) 分别使用3个数据结构来表示，这也是他被叫做split ring的原因。前端作为生产者将新生产可给后端使用的descriptor在available ring中更新，然后由后端从available ring中读取到自己可用的descriptor进行使用，使用完以后将用完的descriptor写到used ring中，供前端处理，循环使用这些内存。这里所谓的使用，可以从别的地方把数据拷贝到这些descriptor所描述的内存区域中，也可以是从这些descriptor所描述的内存区域中把数据拷贝到别的地方。 packed ring是Virtio Spec 1.1提出了一种新的ring结构，前后端通信的逻辑与split ring基本相似，不过ring结构发生了些改变，将split ring中原本分离的ring结构整合在一起全部用一个ring 表示。虽然在操作上确实复杂了一些，但是在前后端收发包操作时packed ring模式下只需访问一个ring结构，相比于split ring每次需要操作3个ring而言，packed ring减少了所需访问的内存空间，对cache来说更加友好。 下图是packed ring的ring结构，这个ring是前后端都可见的，通过descriptor中的标记位判断这个descriptor的归属权在前端还是在后端。后端使用两个指针来追踪生产和消费的进度，分别为last_avail_idx和last_used_idx。前端作为生产者初始化这些descriptor，后端作为消费者不断的取用这些descriptor并在使用结束后将使用完的descriptor写回这个ring中，前端观察到这个descriptor被写回则更新这个descriptor，使得后端在下次可以继续使用。值得一提的是前端按照ring的顺序操作这些descriptor，而后端则是按照完成顺序操作这些descriptor，且在in-order模式下descriptor的可用性一定是连续的，既若X号descriptor不可用，则默认X+1号descriptor同样不可用。这样一套前后端的协作机制构成了packed ring的基本信息传递方式。 Figure 1. descriptor ring结构 由于ring的操作方式发生了改变，使得两种ring的性能产生了一定的差异，从这里可以看到，从下图（本文不提供绝对性能数据）可以看到。这是PVP场景下，使用Intel(R) Xeon(R) Platinum 8180 CPU @ 2....