安全漏洞、eBPF、机密计算、商用密码等技术分享|龙蜥大讲堂113期
内容分析
1. 龙蜥社区漏洞治理
2. 龙蜥社区赛题介绍
3. 基于 eBPF 的容器异常检测
4. 赛题解析系列
龙蜥社区是由阿里云在 2020 年牵头，联合企事业单位、高等院校、科研单位以及非营利组织和个人等，按照平等、开放、协作、创新的原则成立的非营利性开源社区。它的成立是为了应对一个挑战：CentOS 项目宣布在 2021 年停止服务。为了应对这一挑战，社区联合开发了 ANNOISE OS，作为 CentOS 的替代品。同时，我们致力于打造一个国内主导的 LINUX 操作系统开源社区及创新平台，推动软硬件及应用生态的繁荣发展。
截至目前，社区已有 24 家理事单位，合作伙伴超过 800 家。龙蜥操作系统的下载量已超过 250 万次，用户量达到 600 万。社区的兴趣小组已达到 60 个，衍生发行版也达到了 12 个。这里我简要解释一下龙蜥操作系统，它的英文名是 ANALYS IS NOT ONLY LINUX SYSTEM。这个名称的寓意在于，龙蜥操作系统不仅仅是操作系统本身，还包括与操作系统相关的应用、技术以及兴趣小组等。
龙蜥操作系统的前身是阿里巴巴 Cloud Linux，它是基于阿里内部业务的硬件基础设施研发的内核操作系统。到了 2017 年，我们将这个原本仅服务于阿里云内部业务的操作系统开源，提供给阿里云上的公有云客户。它面向的是阿里云的基础设施。到了 2020 年，随着龙蜥社区的成立，我们将操作系统捐献给社区，并更名为 ANONYX OS。它现在不仅面向阿里云基础设施，还支持更多硬件设施。
整个龙蜥操作系统采用的是 2+1 的布局，即上中下三层。上层是所有开源组件的社区，中层是龙蜥操作系统本身，下层则是基于龙蜥操作系统的下游衍生版，包括企业级的商业发行版，如通信领域的李麒麟，以及阿里云、浪潮等操作系统。截至目前，龙蜥操作系统已发布了三个主要版本：ONIONOS 7 和 NEBULIOS 8，它们主要是为了兼容 CentOS 生态而设计的。而最新的 AMONGUS IS OS 23 则是面向下一代生态研发的新一代操作系统。这个版本标志着我们从基于 CentOS 生态的兼容，转向了自主研发和创新。
接下来，我将介绍龙蜥社区的漏洞治理流程。
01. 龙蜥社区漏洞治理
众所周知，软件难免存在漏洞，没有绝对安全的系统。只要有 bug，就可能被黑客利用，从而形成安全风险。
因此，所有软件都需要一个全生命周期的漏洞治理和管理流程。龙蜥社区的漏洞治理流程大致分为四个阶段：
首先是漏洞感知，我们需要了解存在哪些漏洞。我们的流程大致分为三个部分。首先，我们需要监控漏洞，这包括已公开的漏洞——即那些已经公之于众且我们已知的漏洞——以及尚未公开的漏洞，我们称之为零日漏洞。
这些漏洞的发现有两种途径：一是通过社区和用户报告，二是通过我们自己或合作的安全团队主动发掘。一旦感知到漏洞，无论是开源已公开的漏洞还是我们申报的潜在漏洞，我们都需要进行分析和验证。
分析验证过程包括对漏洞的多个维度进行评分，比如完整性、信息缺失或提权等，我们采用 CVSS 评分框架来为漏洞打分并定级。定级反映了漏洞的严重程度，我们将其分为四级：超危、高危、中危和低危。
评估完漏洞对产品的威胁性以及对产品的影响后，我们就能判断出产品是否受到漏洞影响，以及是否需要修复或缓解。如果漏洞确实影响到我们的产品，我们就必须采取修复或缓解措施。修复完成后，我们会对补丁进行测试和验证。这是漏洞修复阶段。
在这个阶段产生的漏洞修复补丁或安全更新，我们会对外发布。发布分为两种情况：一种是预先发布，通常针对零日漏洞，在漏洞尚未大规模影响且影响可控的情况下，我们会对特定单位进行有限披露；另一种是公开披露，我们会向所有用户及公众公开漏洞的细节及其修复情况。通常，我们会在漏洞修复补丁准备好后才进行公布。
为了提高漏洞治理的效能，我们龙蜥社区打造了一个全流程自动化平台，从漏洞感知、评估、修复到披露，实现了全自动化处理。我们以隆鑫的安全中心为核心，串联起整个漏洞处理流程。在流程的前端，我们会与第三方合作伙伴、商业漏洞情报机构以及阿里云安全团队合作，共同搜集漏洞信息。一旦收到情报，我们会自动将任务分配给安全委员会和安全团队，由他们对漏洞进行评估和分析。分析完成后，我们会对漏洞进行评分、定级，并评估其对产品的影响程度，然后创建漏洞工单。工单创建完毕后，我们会将其指派给研发团队进行修复。修复后的代码将提交至代码平台，经过构建系统打包、测试后，一旦漏洞被修复且补丁已整合至安全更新中，我们便会发布漏洞安全公告至公众平台。这是我们龙蜥社区的自动化漏洞处理平台。
关于龙蜥社区的漏洞治理策略，我们首先对外承诺了漏洞修复的服务水平协议（SLA）。通常情况下，我们承诺在一周内处理完毕并发布安全公告。对于高危漏洞，我们给予两周时间；对于中等风险漏洞，我们通常在三个月内修复，因为这些漏洞的影响相对较小。我们会在所有补丁或发行版的例行版本更新时修复这些漏洞。
由于漏洞层出不穷，我们基于当前的人力资源，采取基于风险的漏洞管理策略。我们对所有受影响的组件进行分层分类，分为核心组件、系统核心组件和应用层等五个层级。越往上层，漏洞的影响范围越小，风险也相对较低。因此，对于这些低风险漏洞，我们可以安排较长的修复时间。然而，对于影响核心组件的高风险漏洞，我们会优先处理。这就是我们漏洞修复策略的总体框架。首先，我们拥有一个龙蜥安全委员会，负责接收漏洞报告。随后，委员会会对漏洞的攻击原理、风险影响进行分析，并对其严重性进行评分定级，同时制定修复策略。龙蜥安全实验室将负责 POC（概念验证）的分析工作。阿里云安全团队也将协助进行 POC 和风险评估。产品团队将从产品角度对漏洞进行分析，而业务团队则会从商业视角审视。研发团队将从漏洞的逻辑层面分析其影响。测试团队则会对漏洞进行验证。发布团队负责漏洞修复后的发布工作。
此外，龙蜥社区已申请成为国际 CVE 组织的 CNA 单位，CNA 即为漏洞编号分配的资格。获得此资格后，我们社区就有权为上报给龙蜥安全区的漏洞分配 CVID。截至目前，我们已与蚂蚁安全团队以及一些高校安全团队合作，申报了 19 个开源组件的漏洞。我们也欢迎更多人与龙蜥社区合作，在漏洞挖掘方面共同进步。通过龙蜥社区，挖掘的漏洞可以申报 CVID，从而获得相应的荣誉。
02. 龙蜥社区赛题介绍
接下来，我将向大家介绍龙蜥社区本次的相关赛题。本次赛题分为三个赛道，共八个题目。
在系统创新赛道中，我们社区提出了三个赛题：第一个是针对龙芯自研组件的漏洞挖掘，与我们的漏洞治理工作密切相关；第二个赛题是基于 EBBF 的容器异常检测；第三个赛题是针对易操作系统 GPA 工具集成国密算法。
应用创新赛道也推出了三个赛题，第一个是关于操作系统三方安全应用的适配。接下来，我们将详细介绍第二个赛题，即为高敏感精密计算工作负载设计并构建一个安全且高效的机密容器平台。另一个设计赛题则关注面向云原生系统的故障注入与常态分析。在研究创新赛道中，我们提出了两个赛题。
首先是龙蜥操作系统安全研究报告，其次是基于龙蜥操作系统的应用性能检测与预测软件。其他赛题可能由其他视频进行分析，而我们这里仅关注与漏洞治理相关的三个赛季。第一个赛季是漏洞挖掘。我们希望通过这个赛题，鼓励从事计算机网络安全研究的学生们，将他们在漏洞挖掘上的新技术和创新点应用于实际，积极帮助龙蜥社区发现龙蜥操作系统中潜在的安全隐患，尤其是龙蜥资源组件中的问题。由于这些资源组件是我们龙蜥社区对外发布的，我们不希望它们含有任何漏洞。因此，我们希望同学们能发现并帮助解决这些安全漏洞，共同提升我们国产软件的安全性，并推动网络安全研究的创新。
漏洞挖掘技术自 60 年代起就已存在，早期主要依赖人工代码审计，随后发展到静态分析，进入 2000 年后，出现了新的动态漏洞挖掘技术，如模糊测试和启发式技术。特别是近年来，人工智能和大数据等新技术的出现，也对漏洞挖掘技术产生了推动作用。我们希望相关网络安全研究的学生们在这方面有所研究，并在新技术的支持下，对龙蜥操作系统相关组件进行漏洞挖掘。
关于评审规则，首先，漏洞挖掘的质量至关重要，需要挖掘出影响较大、级别较高的漏洞。其次，漏洞的数量以及漏洞挖掘报告的完整性也很重要，最好能提供漏洞的 POC 验证以及无法利用的验证程序。我们鼓励大家在传统漏洞挖掘的基础上，研究一些创新的挖掘技术。加分项是挖掘出漏洞后，能提出修复改进方案，最好能直接修复漏洞。这个赛题相对简单，就是要求大家运用自己掌握的网络安全知识和漏洞挖掘技术，对龙心操作系统进行漏洞挖掘。
关于漏洞上报流程，大家可以参考龙蜥社区的相关指南，挖掘出漏洞后，可以直接向我们的社区进行上报。本次漏洞挖掘的范围主要集中在农机操作系统本身，特别是我们的自研组件部分，包括我们自研的 KingToco、OM、HT、One 等。大家可以参考以下链接，查看我们开源组件的代码。由于代码完全开放，无论是通过代码审计还是其他方法，大家都可以尝试对这些组件进行漏洞挖掘。
第二个赛题是关于三方应用的适配。龙吟操作系统作为国产操作系统，依赖于许多三方安全应用，尤其是开源软件。例如，我们提到的 Trivy 它是一个用于容器、镜像、文件系统以及 git 仓库的安全扫描工具。随着云原生技术的兴起，Trivy 作为开源软件，其影响力日益增强。目前，它已经支持了如 Fedora、Red Hat、Debian 以及 Windows 等主流操作系统。我们鼓励同学们积极参与开源社区，贡献自己的力量，并尝试在 Trivy 社区中为 ANALYSE 操作系统添加支持。该赛题要求研究 Trivy，参与其测序数据的开发，并帮助将 ANALYSE 操作系统的支持集成到 Trivy 软件中。评审规则相对简单：首先，需要使 Trivy 支持 ANALYSE 操作系统，包括漏洞扫描和特定语言包的扫描。同时，需要学习 Trivy 插件的原理和结构。结合龙蜥社区发布的安全公告和补丁，了解如何为 Trivy 添加对 AROMATIOS 漏洞扫描的支持。提交的作品应直接向龙蜥社区的代码仓库提交补丁，我们将进行审核。适配工作应包括补丁和测试用例，以及能够完整适配并提供设计报告和测试报告。
接下来，我们将探讨最后一个赛题，即龙吟操作系统的系统安全报告。请注意，我们的农机操作系统是专为云业务场景设计的服务器操作系统，它支持关键业务和日常应用的运行。我们已经提到，该系统拥有 800 万次的下载量，用户数达到 250 万。
随着新技术的快速发展和网络环境的日益复杂，操作系统面临的安全挑战越来越多。因此，我们鼓励同学们深入研究和分析我们的农机操作系统，帮助我们系统地梳理在安全性能方面所做的努力以及所面临的挑战。我们希望同学们能从学术角度出发，对操作系统进行分析，为容器用户提供一个中肯且准确的安全评估，并为操作系统本身提出一些有针对性的改进意见和建议。让我们共同为操作系统的未来发展出谋划策。
这项任务主要涉及分析龙蜥操作系统的系统架构、安全架构设计、安全特性，以及它在安全漏洞、安全威胁、安全加固和安全性方面所做的工作。报告中最好包含横向对比，以便为统一综合系统提供一个合适的系统安全水平分析评估。当然，整个安全报告还需要对龙蜥操作系统在安全方面存在的问题和短板进行分析，并提出建议，指导龙蜥未来在安全方面的工作。
这是一个学习报告的形式，因此报告内容需要规范，结论应准确，报告应体现一定的深度和广度。我们还希望报告中的分析方法和评估方法具有创新性和可操作性。我们鼓励参赛者在报告中加入实际业务调研，以进一步支持报告中的观点或结论。我们希望这些作品能够像论文一样，呈现出研究报告的深度和严谨性。对于优秀的报告，我们计划在龙蜥社区进行发布，这将是整个龙蜥社区赛题解析的一部分。如果同学们有任何问题，可以通过以下方式与我们联系：安全团队或荣誉社区。
03. 基于 eBPF 的容器异常检测
今天主要向大家介绍了松山湖杯首届中国研究生大赛操作系统开源创新大赛的基于 1BBF 的容器异常检测赛题。
赛题解析主要分为五个部分：首先介绍赛题背景，图中展示了两个架构图，左边是容器架构，右边是虚拟机架构。
在容器架构中，所有应用程序运行在同一操作系统之上，通过 Docker 引擎进行管理。容器通过共享操作系统内核，减少了资源占用，因此更加轻量级，启动速度也更快。相比之下，在虚拟机架构中，每个虚拟机都有自己的独立操作系统，通过管理程序 HAVIOR 进行协调管理。这种方式虽然提供了更高的隔离性，但每个虚拟机都需要自己的操作系统，这会带来显著的资源开销和启动延时。通过对比分析，我们可以清晰地发现容器的主要优势：不需要为每个应用实例搭载一个完整的操作系统，这使得它们启动更快，几乎瞬间完成。这对于快速扩展和微服务架构的应用提供了极大的便利。尽管容器技术具有许多优势，但也存在一些需要注意和解决的问题，主要问题在于隔离性较差。虽然容器在进程层面提供了一定的隔离性，但与虚拟机相比，隔离性相对较弱。如果某个容器出现异常，所有运行在其上的容器都可能受到影响。因此，容器的异常检测对于系统的稳定性至关重要。
接下来，我们将介绍相关工作。GEPPI 容器异常检测的开源项目有很多，例如 CSDG 和 TRACY，还有 Falco。我们将重点介绍 Falco 项目，它主要是基于 ebPF 实现数据采集。通过在内核空间运行 PPIP 程序，可以高效地获取当前系统的系统调用、网络通信等关键信息。在采集到这些关键信息后，Falco 会根据预先设定的规则对数据进行分析和筛选，以检测可能的异常情况。通过这些预定义的规则，能够快速且精准地定位出异常事件，并实时发出报警通知，从而实现对容器系统的实时监控和及时响应。最终，该系统支持功能的插件化，以增强其灵活性和可扩展性。通过将检测和处理功能模块化，设计成插件，我们提升了系统的整体性能。
接下来，我将对赛题进行详细解析，主要从数据采集、数据分析到数据呈现这三个主要环节进行展开讲解。首先，让我们关注数据采集阶段。在这个阶段，我们可以通过 e-app 来采集系统调用、网络等关键信息。系统调用是操作系统与应用程序之间交互的接口，通过捕捉这些调用，我们可以获取大量容器运行的数据。网络特征主要包括数据包和连接信息等网络活动特征。
这些数据的采集为后续的数据分析和异常检测奠定了基础。在数据分析阶段，主要包含两个部分。首先，我们会对数据进行清洗和处理，这包括数据清洗、转换和优化等步骤，以确保数据的质量和一致性。随后，我们可以利用各种算法和技术手段来识别数据中的异常情况，检测出容器异常。这一步骤对于保障容器的安全和稳定运行至关重要。最后是数据呈现部分，在这里，我们将数据分析的结果以直观的方式展现出来。
通过各种图表和指标，我们可以展示容器系统的健康状态、标记和报告容器的异常事件。在数据采集部分，我们将基于 EbPF 技术，这是一种在内核中运行的虚拟机技术，它允许用户以安全的方式扩展内核功能。EBPF 具有四个核心特性：可编程性、安全性、高性能和无侵入性。EBPF 的可编程性是其最大的优势之一，它允许开发者编写 EBPF 程序，这些程序可以在内核中执行，从而实现对内核信息的自定义采集。安全性是 EBPF 设计的另一个关键点，所有 EBPF 程序在加载到内核之前都会经过严格的验证过程，以确保它们不会对系统的稳定性和安全性造成威胁。
EBPF 还利用即时编译（JIT）技术，将字节码转换成机器码，提高了程序的运行性能。EBPF 的无侵入性意味着开发者无需修改现有应用程序，就可以通过 EBPF 程序来采集容器的运行状态。正是因为这些特性，EBPF 非常适合用于生产环境中的数据采集。当然，现在也已经出现了许多 EBPF 开发工具。它们主要是一个用于加载和运行 app 程序的 C 语言开发库。它们提供了一系列 API，简化了 APF 程序的编写和操作。接着是 BCC 和 pf trace，这些是较为高级的跟踪工具，允许开发者使用 Python 或类似 AWK 的语法编写跟踪脚本。
然后是数据分析部分，这里主要介绍三种分析方法：统计方法、机器学习方法和深度学习方法。统计方法中，经典的有十分位数和三西格玛法，通过计算数据的中位数以及上下四分位数，可以快速识别数据中的异常值。三西格玛方法适用于数据符合正态分布的情况，通过计算数据的标准差，假设大部分数据落在平均值的正三西格玛范围内，从而轻易识别出落在这一区间之外的异常值。统计方法简单直接，能够快速识别数据中的异常点，适用于相对简单且数据量较小的场景。
接下来是机器学习方法，例如 k-最近邻算法（k-NN），通过计算样本与其最近邻样本之间的距离来判断该样本是否为异常点。如果该样本与最近邻的距离远远大于正常样本之间的距离，则该样本会被视为异常。随机森林是一种基于决策树的集成学习方法，通过构建多个决策树并综合其结果实现异常检测。随机在处理大规模数据时非常有效且具有较高的准确性。机器学习方法适用于数据复杂且规模较大的场景，可以通过训练模型来识别更复杂的异常模式。最后是深度学习方法，例如自编码器，这是一种无监督的学习算法，通过将数据进行编码和解码实现数据的降维和特征提取。
通过比较输入和输出数据的差异，自编码器可以识别出异常数据。生成对抗网络（GAN）通过生成器和判别器之间的竞争学习，能够生成类似真实数据的样本，从而实现异常检测。生成对抗网络能够处理非常复杂的异常模式，也是当前异常检测领域中的前沿技术。深度学习方法适用于数据非常复杂且需要高精度异常检测的场景，通过训练深度神经网络可以实现异常的精准识别。结合数据的异常特征选择合适的算法是数据分析过程中最关键的一步。无论是统计方法、机器学习还是深度学习，我们都需要根据具体的数据特征和业务需求来选择最适合的算法来进行异常检测。
在数据处理的最后阶段，我们主要关注两类数据：持续数据和异常事件。通过图表，我们可以轻松地将时序数据以表格或图形的方式展示出来。同时，利用 GRAPHAALERTATION 方法，我们可以对异常数据区间进行标注，并通过告警机制上报异常事件。接下来，我将介绍赛前的要求。首先，对于赛题，我们需要一个具有高可扩展性的框架，以适应不同数据采集需求，无论是网络性能、系统调用还是安全事件的采集，都能轻松应对。
更重要的是，整个采集系统对当前系统性能的影响微乎其微，确保业务的连续性和稳定性。其次，在异常检测方面，我们需要结合业务指标特征，采用多种先进算法，精确识别数据中的异常，检测出异常容器。
最后，我们需要提供一个清晰、直观的用户界面，该界面不仅展示实时数据和检测结果，还需详细展示整个检测过程，使用户能够轻松理解和操作。
除了前面提到的赛题外，我们还有另外两个赛题：第一个是面向云原生系统的故障注入与诊断；第二个是基于龙蜥操作系统的应用性能监测与预测。
04. 赛题解析系列
我是龙蜥社区云原生机密计算的负责人乾越。今天，我将为大家解析松山湖北首届中国研究生 OS 开源大赛龙记社区赛题。我负责的题目是为高敏感性精密计算工作负载设计并构建一个安全且高效的精密计算平台。整个解析文 PPT 分为三个部分：第一部分介绍龙蜥社区与人声精密计算的背景；第二部分对赛题所使用的 CVM 技术和背后的 shatter 技术框架进行介绍；最后，对赛题进行细致分析。
首先，让我们了解一下云原生机密计算社区的情况。SIG 本身基于机密计算开源站，旨在通过开源的精密计算技术降低精密计算的使用门槛，让更多人能够通过龙蜥指针轻松进行精密计算，从硬件支持、OS 适配到社区服务等各个层次，满足大家在云上部署和使用精密计算的需求。目前，我们的社区已经与 TE 精密计算硬件平台建立了广泛的合作关系。如图所示，目前黑色部分已经得到支持，而新的 T1 平台也将陆续在第一时间提供支持。这不仅包括硬件，还包括从底层到最上层的社区服务，整个技术栈都是目前在云原生、机密计算领域可用的组件。大家可以根据自己的需求和实际使用情况，选择适合自己的解决方案层次。
接下来，我将向大家介绍我们团队的背景。我们团队之前隶属于达摩院操作系统实验室，后来整体转入阿里云操作系统实验室，继续从事系统安全方面的工作。在精密计算领域，我们团队积累了丰富的经验。
过去五年，我们一直致力于在开源社区开发相关的精品资源项目。例如，我们介绍了业界首个进程级机密容器开源项目 Inclure Containers，以及与业界领先公司合作共同打造的 Pod 级机密容器开源项目 Confidential Containers。目前，在这些项目中，我们团队的成员，包括 TC 和相关核心同学，不仅为这些核心项目贡献代码，还担任了重要的维护者角色。
此外，我们在远程证明方面也有所建树，比如我们自行设计并实现了 rST，支持广泛的 TE 平台。我们还与业界保持合作，在 TLS 标准上贡献了我们的建议和力量。最后，在龙蜥社区，我们发布了国内首个支持多种平台的第三方远程证明服务 OAS。感兴趣的朋友可以点击以下链接尝试体验。此外，吉米镇 4K 在龙蜥社区中也占据了热度排行第四的高位。
现在，让我们进入第二部分，即与本次赛题相关的前置背景技术知识。首先，我们有 CVM 机密虚拟机技术，以及 shelter 基础框架。本次赛题背后实际上源于一个真实的业务场景需求，这是一个相当大的需求场景。云原生发展迅速，随之而来的是对上云机密数据的安全防护需求日益迫切。这是一个紧迫的需求。我们希望通过本次赛题，能够更贴近实际业务需求，使用户能够将操作敏感数据的高敏感工作负载运行在通用的精密计算平台上。此外，还有一个具体需求：许多业务需要将传统运行在主机上的 Linux 应用程序迁移到 CVM 中，但他们对机密虚拟机技术、机密计算、远程证明等知之甚少。他们如何能够无缝且轻松地迁移到 CVM 场景中，是我们认为需要工具或体系来协助解决的问题。
一旦这样的体系或工具建立起来，原本运行在主机上的 Linux 应用程序能够无缝地运行在 CVM 中，这可以被视为一种抽象的执行范式，无疑是一个通用且实用的技术。机密虚拟机，简称 CVM，其技术背景和基础可以通过一张图来清晰展示。机密虚拟机顾名思义，首先它必须是一个普通的虚拟机。然而，传统的虚拟化技术，即目前云上使用最广泛的虚拟化技术，本质上是从平台提供者的角度出发。平台提供者不希望运行在虚拟机中的工作负载在最坏情况下，如果是恶意程序，它试图攻击主机上的 Hypervisor 并横向移动，造成更大的损失。
因此，从平台提供者，即 CSP 的角度来看，他们希望使用虚拟机这种隔离技术，实现多租户工作负载的安全隔离、性能隔离和故障隔离。本质上，他们认为虚拟机中的工作负载是不可信的。而今天，机密计算 TE 带来的视角则正好相反。它是从数据提供者的角度出发，即运行在虚拟机内，为虚拟机内提供代码和数据的提供者。这个提供者担心他的程序或敏感数据遭到来自主机，尤其是拥有特权的主机系统管理员，或是攻破云基础设施的攻击者的攻击，渗透到他的虚拟机或 TE 环境中，窃取他的敏感数据和代码。
在这种情况下，用户更倾向于使用 TE 来保护其执行环境中的高敏感数据。机密虚拟机实际上结合了这两种技术，并共同使用。例如，今天的海光、英特尔、AMD、ARM 等都有类似的技术。因此，如果能够无缝地结合这两种底层技术，并在此之上迁移一些流行的云原生技术，如容器技术等，让用户在享受现有云原生技术的使用体验的同时，又能够无感知地获得 CVM 和 TE 的保护，结合虚拟化技术，那么将会得到一个非常好的完整用户体验。用户能够几乎不费吹灰之力，就能获得高级别的安全防护。
这张图展示了一个系统的威胁模型，主要分为使用传统虚拟机技术和机密虚拟机（CVM）技术的系统。无论是 CVM 还是普通 VM，用户都拥有自己的虚拟机。在这样一个系统架构上，我们可以看到左侧灰色部分描述了使用传统备案时存在的安全不足之处。如果我们采用机密虚拟机技术，那么今天的机密虚拟机并不依赖于整个计算平台，平台拥有者。用户只需信任提供信任根的芯片厂商，即我们认为的可信执行环境（TEE）提供商。
芯片厂商提供的安全能力和 CVM 的信任根保证了整个 CVM 的安全可信。因此，从信任关系的角度来看，CVM 用户不再像普通 VM 用户那样，为了确保 VM 的安全，需要信任主机平台，即平台拥有者所拥有的所有软件栈，包括主机固件、BIOS 以及 VM 的安全性。今天使用 CVM 后，用户只需信任 TEE 是可信的，而 TEE 也有相应的信任机制来保证整个 CVM 的安全可信。基于最小可信计算基（TCB）原则，我们可以发现，CVM 可以提供执行环境、验证 SOOS 镜像、加密 CVM 内存访问控制、物理内存加密等一系列安全能力。
接下来，我们介绍 CVM 的技术背景，然后转向介绍赛迪主要使用的一个名为 Shelter 的技术框架。首先，Shelter 是一个相对较新的设计，是我们内部的一个创新理念。Shelter 框架实际上满足了一个实际需求，即将运行在宿主机上的应用程序无缝地运行在 CVM 中。我们需要将这种范式和能力抽象并总结成 Shelter 框架和工具。
这张图展示了 Shelter 如何在 Shelter 环境中运行敏感程序。例如，最左边的传统方式是在执行环境中直接运行一个敏感程序。在我们的场景中，可能有一个部署工具，然后运行一个敏感程序。传统方式是通过调用和参数传递，敏感程序执行后将结果返回给部署工具，完成整个交互过程。但今天，我们希望使用 Shelter 实现一种方式，部署工具仍然使用，但调用和参数传递的对象不再是直接的敏感程序，而是 Shelter 程序。Shelter 程序的责任是通过虚拟化技术启动 CVM，并在 CVM 中运行一系列包括固件、Bootloader 以及 Gas OS 的 SOOS，然后运行其中的敏感程序。这时，敏感程序实际上并不是像左侧图那样在宿主机上与部署工具直接交互，而是通过 Shelter 间接启动，在一个 VM 或 CVM 中运行。
如果敏感应用需要与部署工具进行交互，就需要将它的标准输出进行相应的重定向，这种重定向不是进程间重定向，而是跨越虚拟机传递到宿主机上。因此，这里使用了经典的虚拟机与宿主机之间传输信息的 VS 机制。我们希望 Shelter 能够将启动运行 VSOP 程序以及如何启动运行 QING 等细节都封装在 Shelter 工具中，让用户在实际使用过程中，即部署工具的编写者，只需调用 Shelter 即可。关于 Shelter，从第二步开始的所有这些细节都是 Shelter 要负责的，部署工具的编写者无需关心底层封装的细节。因此，Shelter 必须是一个设计良好的工具。我们也希望通过 Shelter 工具，可以轻松地将任何应用程序以一种安全可信的方式运行在 Gas 中。
这张图展示了一个基于 Shelter 的敏感应用保护的具体方案和流程。这仍然是一个相对简单的流程，我们先以这个最简单的方案和流程进行讲解，然后再引入更复杂的以及本次赛题要讨论的真正主题内容。首先，我们假设在整个微型模型或运行环境中，我们区分内部环境和外部环境。外部环境是不可信的物理环境，处于虚线框内。
首先，在内部环境中，我们需要先搭建一个信任管理服务，这涉及到 K8S 和 Testing Service。这些内容在后续的学习资料中也会有相关的链接或解释。在这里，我们可以简认为 KBS 和 Testing Service 都是一种信任管理服务，主要用于提供远程证明和敏感资源下载。
第二步是将真正运行在 CVM 中的敏感程序连同一个名为 Test And Agent 的应用一起集成到印尼 RD 中，并将隐匿 RDONMF、Gas 固件、Gas Kernel 以及 Shelter 程序等一系列组件打包在一起，然后部署在事先部署在外部环境拥有者所拥有的不可信物理机上。所谓的不可信物理机是相对于我们内部环境而言的。我们的最终目标是希望将我们的敏感应用运行在一个 CVM 中。
因此，敏感应用在运行过程中，它操作访问的资源以及密钥等都围绕敏感数据进行。整个敏感程序的执行过程以及它所依赖的执行环境需要安全可信，相对于我们来说是安全的。如果敏感程序像前面的图示那样直接运行在不可信的物理机环境中，那么不可信物理机是由别人控制的，别人可能在无底线之前就运行了后门。当你的敏感应用真正操作敏感数据时，中间涉及的密钥实际上都会被物理机上预先设置的后门所截获。你的敏感数据，无论你做了什么样的保护，包括加密，最终的明文也会被别人盗取。
因此，为了防止这样的场景，我们需要按照刚才的逻辑，使用部署工具来调用 Shelter，内部再调用 QING 来启动 CVM，这样敏感应用程序就在 CVM 中运行。因此，它整个执行过程都被 CVM 所保护。即使不可信物理机拥有最高权限，它也无法去篡改这个敏感程序的执行过程。整个执行过程中，还有一个重要的步骤是远程证明。远程证明的做法是在运行敏感程序之前，在 RD 中先运行。测试站代理通过远程证明向我们控制的信任管理服务发起请求。在信任管理服务中，我们会彻底验证 CVM 内的所有组件，包括 OBMF、固件以及印尼 2D 镜像。
印尼 2D 镜像中预先集成了敏感程序和泰森代理。通过这种方式，信任管理服务能够确认，向我请求敏感信息（如解密密钥等）的请求确实来自一个经过验证的、可信的 CVM，而非普通虚拟机或攻击者植入后门的虚拟机。我只信任预先指定的 CVM 组件，只有符合预期的请求才会被验证通过。信任管理服务会通过安全信道将敏感信息（如解密密钥或签名密钥等）返回给测试代理。测试代理再将这些敏感信息传递给敏感程序，使其像在主机上一样正常运行并处理敏感数据。敏感程序的输入参数和运行结果通过 Vsock 传输到 Shelter，然后 Shelter 将结果返回给部署工具。
通过这一流程，我们实现了从直接调用敏感程序到通过 shelter 间接运行敏感程序的转变，同时利用 CVM 的能力对敏感程序进行安全保护。这个方案相对简单，偏向于概念验证（POC），其最大特点是敏感程序只需集成在轻量级的 RD 镜像中。但需要注意的是，RD 镜像本身不提供机密性保护，因此如果敏感程序包含敏感数据，这个方案并不适用。此外，RD 镜像的完整性可能受到篡改，但没关系，因为即使在部署到不可信环境的过程中组件被篡改，远程证明服务也能通过远程证明发现。
只有通过验证的组件才会接收到敏感数据，然后命令程序才会使用这些数据。因此，远程证明过程确保了即使部署到不可信环境，这些组件也未被篡改。接下来的方案是一个演示（Demo），它比基于 RD 镜像的方案更复杂，但在原理上是类似的。相同的部分不再赘述，主要介绍不同之处。在这个场景中，需要保护的是敏感程序的机密性，因为敏感程序可能包含希望保护的逻辑或实现，不希望被逆向工程。在这种情况下，我们在内部环境制作镜像时不能使用 RD 镜像，而应使用 LVM 卷，即 Quick Setup 工具。LVM 卷的细节不再详述，这是 Linux 世界中一个成熟且广泛使用的技术。我们将敏感程序集成到 LVM 卷中，然后以加密 GUAS 镜像的方式部署到不可见的物理应用环境中。
部署工具启动 Shelter，Shelter 启动 CVM，然后依次传递并启动。引擎 RD 中的 CVM MD 自带挂载和解密 LVM 卷的能力。我们只需额外做一点工作，通过远程证明获取密钥。这与泰森 AA 和太阳代理的逻辑类似，只不过我们需要按照 CND 的要求提供解密 LVM 卷的密码。这个密码通过 Keep Error 程序通过远程证明从 KBS 获得。Attendant Service 按照前面方案的逻辑验证 CVM 是否可信，只有在可信的情况下，才会通过安全信道将解密 LVM 卷的密码传递给 Key Rider，再传递给 SAMDCMD。在第七步完成 LVM 卷的挂载和解密。接着，整个系统继续运行，直至达到敏感程序。
此时，操作与之前相同，通过 VSK 将 STDIO 重定向到 Host。同样，遵循先前的安全性原则，不仅能够获取 Last Pass Face，还能获得额外的解密 Key 等，进而操作敏感数据。因此，如果我们将 Shelter 工具比作 Docker，那么刚才展示的两个 Demo 方案实际上体现了 Sheltertle 用法中的前两个功能。第一个功能是部署工具，通过 SHA 拉起 Cmm 过程，我们称之为 Shelter Run。例如，Shelter Run 后面可以跟上要运行的 LINUX 命令行程序，这与 docker 的运行方式类似。
另一个功能是在集成过程中，无论是将敏感程序集成到引念而地里，还是集成到一个拉克丝卷，一个盖茨的镜像里，我们都希望使用 Shelterup Build 命令来完成。使用体验也与现有的 Docker 相似。此外，我们是否可以添加 SHTEAC 这样的命令，甚至删除它独有的远程证明啊 Test 命令，这些都是可行的，并且有足够的显存空间来为 Shelter 工具做更多的事情。至于 SHADER 组件，我这边就简单列举一下刚才几个方案中用到的这些组件，并做一个简单的说明。
第三个部分是今天我们这个赛题所涉及的，如何使用 Shelter 以及我们要解决什么样的问题。首先，整个赛题利用 Shelter 工具或框架进行比赛，不同队伍肯定有不同的考虑和不同维度的解决方案。赛题的评分体系大致可以分为基础要求和进阶要求。可以简单认为基础要求是 60 分的水平，进阶要求是 80 分的水平。至于在 80 分之上是否能做出超出预期的成果，这就要靠大家的发挥了。
基础要求是 60 分，也就是说，不能达到基础要求的作品，产出是不能达到标准的。我们这个基础要求是基于 Shelter 的容器镜像来实现一个机密容器的整体方案。在此过程中，我们引入了容器的概念。如果大家对 Docker、Run c 等云原生容器引擎有所了解，那么底层的技术细节就非常清晰了。例如，当我们运行 Docker Run 时，后面可以跟上我们提前制作好的 12 容积金强的 Shell 程序作为入口点程序。然后，Docker Run 后面跟 Shelter，Shelter 后面跟 Shelter 的 Commander。比如我们运行一个 Echo 程序，Hello world。我们这样调用 ShelterSHTT 底层，通过 CTRLD 来获取容器镜像，然后 Mount 通过 OVERLINEFS 挂载成一个容器的文件系统。这些都是正常的过程。
接着，我们要调用 Osd Run Time 来运行我们制作好的 Shelter 容器镜像。Shelter 容器镜像里有 Shelter 程序，有刚才几个方案中看到的 Rdo MF gas 固件，以及集成到镜像中的 QING 程序。这些 Shelter 容器组件通过 Shelter 程序，与刚才的方案和流程一样，启动一个 CVM。里面的过程实际上与刚才完全一样，包括远程证明 CVM 是否可信，以及通过 VSC 将 Hello World 这个标准输入通过 VISQL 重定向给引尼 RD 中的 Echo 程序。然后，Echo 程序返回 Hello Word，再通过 Visa 打回到 Shelter 容器镜像中的 SHER 程序，最后打印出来。整个过程实际上与先前的方案以及 Shelter 的标准用法大同小异。主要区别在于，这次比赛要求我们将 Shelter 的功能进行容器化处理。这是比赛的基础要求，即获得 60 分的基准。至于我们的进阶要求，我们希望将题目的难度提升，使其更加开放。鉴于题目本身是围绕 Shelter 来实现一个机密容器的方案，不同的参赛者可以根据自己擅长的技术领域，选择一个或多个方向来扩展 Shelter 的功能。
我这里列举了一些例子，但这些例子并不是唯一的。例如，如果 Shelter 工具实现的功能非常简单，那么使用重型系统语言来实现它就显得没有必要。然而，如果有同学擅长 Rust 语言，并且我们确实希望将 Shelter 发展成为一个成熟的大型工具，那么用 Rust 语言重写它就是值得鼓励的。此外，正如之前介绍 Shelter 时提到的，理论上 Shelter 可以实现更多丰富的功能，这些功能的扩展也是我们所期待的。再者，在先前的方案中，已经提到了一些基础的安全性要求，例如容器镜像的安全性。既然 Shelter 需要在 CVM 中运行，那么镜像中的内容应该是受到重点保护的。假设前面例子中的 Echo 程序是一个敏感应用，它被放置在镜像中，但这个镜像被下载到宿主机上，并挂载到宿主机的 Mount 上。这意味着宿主机完全有机会在挂载为 OverlayFS 之前篡改 Echo 程序，导致运行的程序带有后门。这样的安全问题应该如何阻止？有哪些有效的方法可以预防？这是第三个进阶要求，我们希望看到同学们能够解决。此外，还有一些工程实践上的问题，比如我图中方案中提到的 QA，是否可以使用 Kubernetes、Hawthorn Lip、CARRN 等方案。这些后续的点都是不同维度的进阶要求。因此，大家可以基于这些描述，或者根据自己的专长，去扩展这个题目，以达到进阶要求。例如，我之前提到的一个进阶要求就是如何将 Shadow 容器运行时以及如何将容器镜像从 Host 转换为 Guest 的 Rootfs。这张图展示了一个大致的过程。在这个过程中，Shelter 本身不再是一个容器镜像，而是一个 Shelter 容器运行时。
这与 Shelter 的容器化现象有着本质的不同。你可以看到，在第二步中，Docker Run 时，这里打错了，应该是 Docker Run Echo Hello World，而没有 Shelter。实际上，由于它类似于 WRC 的地位，运行时不需要在命令行中明确指定，因此，这个进阶方案考验了同学们对 WRC、Docker 以及容器底层运行时的理解。理解如何通过 Run c 嫁接，或者如何创建一个 SHAW 运行时，同时调用已有的 RC 能力，然后将整个 CVM 运行在 LINUX 容器环境中，这确实考验了同学们对容器运行时和容器底层运行引擎的工作原理的基本理解。其他赛题信息，包括基础知识的掌握，如虚拟化、工具使用等，这些都是需要掌握的基本常识。此外，评审规则首先要求参赛选手必须使用 TECVM 技术，具体哪种都可以，如 SEVC、SVT、DS 等。其次，必须使用 T 远程证明技术，这一点之前已经提到。还必须使用 Shelter 技术框架。
其他要求实际上都是任何比赛都需要的一些基本要求。整个作品以及联系方式等信息也都在这里。
介绍一下目前这个赛题的一些基本情况。题目是 JPG 工具集成国密算法。从整体来看，这个题目相对简单，因为目标和整个实现机制都非常清晰。题目的背景是这样的：随着这些年国产化趋势的快速推进，国密算法在基础操作系统、内核以及在 BESOS 中的集成成为一个相对较大的趋势。这些年，我们在 Seek 依托这个平台，做了很多工作，在操作系统的内核以及 BESOS 的许多软件包中支持国密的 SM2、SM3、SM4 算法，并利用这些算法支持了相当多的场景，包括文件和磁盘加密、内核模块以及文件签名等。但仍然有一些场景，我们目前还没有支持国密算法。今天这个题目实际上也是其中之一，即在这一套软件包中，我们如何支持国密算法，并将其应用起来。
JPG 工具是 GNU PG 这一套 GNU 软件包中的一个工具集，它提供了一些密码学算法库，包括 Libgcrypt 以及 JPG 下的算法库，还有 JPG 提供给用户直接使用的一套工具。这些工具集成了包括加解密、签名、验签等非常常用的一些密码学相关能力。这些能力主要用在文件的加解密以及完整性认证上。同时，这些工具也被集成到许多常用的基础工具中，包括一些常见的邮件客户端会使用 JPG 工具来做邮件的加解密，以及 Rpm 等软件包管理工具会使用 JPG 来做软件包的完整性校验。这些都是整个生态中能运用到 JPG 的一部分功能。
题目的基本目的是需要在 JPG 工具中支持国密算法，包括 SM2、SM3、SM4 等基础算法能力。其次，我们使用这套工具和算法来做文件的加解密、文件签名和验签等基础场景的技术支持。这是最终的目的。其次，在实现路径上，我们需要考虑几个方面。首先，我们需要尽可能保持兼容性，因为这个工具在 OS 层面还是相对底层的。我们需要保证使用国密算法时，用户体验和流畅度上没有大的变化。我们只是相当于提供了一个算法的额外支持和切换，不会带来其他使用成本的增加。其次，我们需要在实现路径上考虑，支持国密算法后，需要将这些能力全部推送到上游社区。这也是我们在开发过程中需要考虑的一个点。因为之前依托龙蜥社区的商品软件，我们已经做了很多这方面的工作，并将这些能力推向了社区上游，并在上游进行了全面的沉淀。我也希望 JPG 这一套工具在国际上的支持和场景上的应用，能通过上游社区来支撑，并慢慢沉淀下来，最终将这些能力支持到龙蜥操作系统上。
这是一个基本的要求和目标。有一些参考资料大家可以参考，包括 JNUPG 的官网，我在上面提供了一个链接。其次是国密算法标准，包括 SM2、SM3、SM4 以及 SM2 算法的签名验签标准和加解密标准，这些都是比较具体的。还有就是我们在 JPG 底层实际上调用 Libgcrypt 来完成一些基础能力。我们之前在 Libgcrypt 中已经有了一些国密算法能力的支持。有兴趣的同学可以参考 Libgcrypt 中已经有的这些国密算法是如何调用的。当然，最终我们也需要继承这个能力去做国密相关的功能支持。
另外，在评审规则上，目前是工具的使用规范必须与已有的对比工具保持兼容，同时也要满足工具本身的要求。当然，如果你最终要推到上游社区，这也是一个前提条件。其次，我们需要支持完整的最基本的密码学方面的能力，包括加密、解密、签名、验签这四个能力。第三，在实现路径上，我们的代码风格、注释、文档等都需要详细符合 GUPJ 社区本身的标准和要求。此外，测试用例和文档也需要有全面的支持。我希望最终能有一套最佳实践，有一些样例，告诉用户这个工具怎么使用，或者如何一步步地使用起来，需要有一个完整的文档和使用手册。介绍就到这里，谢谢大家。
