无服务器计算的安全风险与拒绝钱包（DoW）攻击相关的研究

2627PGysical MacGineE序列短命PGysical MacGine……T5→ $Pay-as-you-go附表路线冷功能？启动新的服务器是否超载？规模更大缓冲请求自动缩放负载均衡网关活化剂活化剂斯盖杜勒斯盖杜勒中央处理Func5空闲中央处理CPUO网关Func6功能2功能2请求功能表（活动/运行）功能表（计划）本作品采用知识共享署名国际4.0许可协议进行许可。Gringotts：用于无服务器计算的快速准确的内部拒绝钱包检测沈俊贤清华大学中关村实验室shenjx22@mails.tsinghua.edu.cn李家伟INSC，清华大学li-jw19@mails.tsinghua.edu.cn摘要韩章清 华 大 学 中 关 村 实 验 室INSCzhhan@tsinghua.edu.cn王继龙INSC、清华大学BNRist、清华大学中关村实验室彭成实验室耿彦涛清华大学中关村实验室gyt22@mails.tsinghua.edu.cn徐文INSC、清华大学BNRist、清华大学中关村实验室彭成实验室无服务器计算或功能即服务由于其即用即付的计费模式、灵活性和低成本而越来越受欢迎。然而，这些特征给无服务器租户带来了额外的安全风险，例如拒绝钱包（DoW）攻击。在本文中，我们执行一个真实世界的DoW攻击的commodity无服务器平台，以评估其严重性。 为了识别这种攻击，我们设计，实现和评估古灵阁，一个准确的，易于使用的DoW检测系统与一个可以忽略不计的性能开销。古灵阁通过引入一个设计良好的性能指标收集代理来解决无服务器函数中固有的信息模糊性。然后，古灵阁使用马氏距离来发现度量分布中的异常我们实现了古灵阁作为一个真正的系统，并进行了广泛的实验，使用测试平台来评估古灵阁的性能。我们的研究结果表明，古灵阁有一个性能开销小于1。1%，平均检测延迟为1. 86秒，平均准确率超过95。百分之七十五CCS概念• 网络→网络实验;·安全和隐私拒绝服务攻击。关键词无服务器计算;拒绝钱包攻击;性能异常检测ACM参考格式：JunxianShen，Han Zhang，Yantao Geng，Jiawei Li，Jilong Wang，andXiangXu. 2022年。 Gringotts：用于无服务器计算的快速准确的内部拒绝钱包检测。 在2022年ACM SIGSAC计算机和通信安全会议（CCS '22）的会议记录中，2022年11月7日至11日，美国加利福尼亚州洛杉矶。ACM，纽约州纽约市，美国，15页。https://doi.org/10.1145/3548606.3560629CCS© 2022版权归所有者/作者所有ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560629CPUO 功能1功能2CPU1功能3功能4图1：典型的无服务器平台架构。函数2、4和5是被调度为在函数1和3产生其分配的CPU之后执行的函数。1介绍无服务器计算或功能即服务（FaaS）自诞生以来一直以惊人的速度发展[9]。在无服务器计算模式下，租户将任务部署、环境配置和自动扩展等额外职责委托给平台。越来越多的公司，特别是初创公司，正在考虑将他们的业务转移到无服务器平台，因为它们提供了吸引人的优势，例如，灵活性、低成本和即用即付的计费模式。图1显示了一个典型的无服务器平台架构。用户通常将他们的代码上传到无服务器平台，并且平台将基于代码生成执行实例，其中该实例可以是虚拟机（VM）、容器或进程，这取决于平台的实现。 当一个新的请求通过负载平衡被分派到一个实例时，激活器决定是冷启动、缩放还是将请求直接路由到相关的执行实例。在整个过程中，无服务器体现了三个关键特征：（i）按需付费，即，用户仅为所消耗的资源付费;（ii）自动缩放，即，该平台响应于该信号而自动缩放CCSJunxian Shen etal.2628§§§§§§商业平台工期成本请求成本（/1 M请求）其他费用AWS Lambda[50]一美元66710−5/GB-s$0.20网络+资源预留GCF[51]两块510 −6/GB-s +1美元。010−5/GHz-s$0.40网络+部署成本Azure函数[52]一美元610−5/GB-s$0.20网络+存储成本阿里云FC[49]一美元638410−5/GB-s$0.20联网表1：主要商业无服务器平台的当前计费模式交通;和（iii）短暂的，即，多个功能在同一CPU核心上被多路复用，并且当它们空闲时被回收。这些功能将FaaS与云结构即服务（IaaS）区分开来，但它们也使无服务器租户面临传统攻击以及其他安全威胁。这些安全威胁之一是拒绝钱包（DoW）攻击，它可以被视为专门在无服务器平台上进行的拒绝服务（DoS）攻击的变体有两种主要的DoW攻击类型，即，外部DoW攻击和内部DoW攻击。外部DoW攻击者将通过反复调用受害者无意中暴露的API来从受害者身上榨取资金，而内部DoW攻击者将试图在函数实例上引起资源争用（例如，容器或虚拟机）的受害者，减缓他们的程序。 在本文中，我们专注于内部DoW攻击检测，因为外部DoW攻击可以通过现有技术检测到，例如，入口过滤[13，74]，回溯[63，78]，和来源验证[33，69]。与DoS攻击者类似，内部DoW攻击者进行此类攻击以在恶意行业竞争、勒索或黑客行动中获得优势。 通过延迟受害者功能的执行，内部DoW攻击可以对受害者产生两种直接影响。首先，内部DoW攻击可能会导致受害者破产，这是由于执行时间延长和“现收现付”计费模式导致的平台费用。 例如，一家初创公司报告说，由于无服务器功能配置不当，花费了72，000美元，几乎宣布破产[66]。其次，由于功能持续时间的增加，受害者的关键服务将受到严重干扰。亚马逊声称，页面加载时间每增加100，销售额就会损失1%[26]。对于内部DoW攻击检测，平台必须监视和分析特定裸机的低级别资源使用情况。快速而精确的内部DoW攻击检测是一个巨大的挑战，因为它必须满足两个目标。首先，性能数据的不适当采样可能导致检测中的不准确其次，无服务器函数是瞬态的，高度动态的，导致了嘈杂的环境。有两种性能分析方法。第一种是基于应用级方法：度量工具（例如，Prometheus [53]），追踪工具（例如，Jaeger [22]）和测井工具（例如，Fluentd [14]）。这些工具收集操作系统级别或更高级别的指标，例如CPU利用率和应用程序日志。但是，它们不会收集低级信息，如总线锁定和缓存未命中。 第二种是基于收集硬件指标，如opcm [46]，perf [18]和likwid [31]。这些工具根据硬件执行的操作数量确定物理机的状态。但是它们使用计时器收集指标，这导致数据模糊。此外，由于这些解决方案缺乏对应用程序行为的了解，因此无法确定底层指标的变化是负载波动还是攻击的结果面对这些挑战，我们做出以下贡献：首先，我们对DoW攻击进行了全面的分析，包括其类型，根源等。（见第2段）。然后，我们在商品无服务器平台上进行真实的内部DoW攻击，以显示DoW危害并了解其根本原因。我们还概括了无服务器平台上内部DoW攻击检测的挑战（见3）。其次，我们开发了一个名为Gringotts的通用系统，用于准确及时地检测无服务器平台上的内部DoW攻击（见4）。古灵阁有一个易于使用和快速的面向请求的采样工具，它知道函数的行为（见5）。一方面，古灵阁的实现与函数是松耦合的，并且与所选择的度量无关。另一方面，它的执行与函数紧密耦合，保证了度量收集不受多路复用、运行时析构或函数表达式更改的影响。此外，古灵阁发现了执行时间和HPC之间的线性关系。它集成了基于HPC的工作负载验证的快速高效的内部DoW检测算法，并利用了真正的工作负载在有或没有内部DoW攻击的情况下保持不变的新概念。 它根据工作负载分布的变化确定是否发生了内部DoW攻击。我们假设性能指标在正常条件下遵循可学习的总体趋势，并使用超平面表示此分布然后，古灵阁使用多元高斯分布来描述度量集合中的噪声。最后，通过计算样本与高斯分布中心之间的Maha-lanobis距离，我们能够准确评估内部DoW攻击的发生（参见6）。第三，我们将古灵阁实现为一个真实的系统，并使用测试平台进行了大量的实验（见7）。我们的实验表明，古灵阁可以：（1）强加一个可以忽略不计的开销小于1。1%;（2）检测DoW攻击的发生，1 .一、86秒;（3）平均准确度超过95。百分之七十五本文的其余部分组织如下：在第二节-第二部分介绍了本文的研究背景。在第3节中，我们定义了拒绝钱包攻击（第3.1节），进行了真实世界的DoW攻击（第3.2节），并讨论了检测挑战（第3.3节）。我们在第4节中概述了古灵阁的架构，在第5节中讨论了 我们在第7节中对古灵阁进行了彻底的实验。第8、9和10节是讨论、相关工作和伦理问题。最后，我们在第11节总结了本文2背景在本节中，我们首先简要介绍无服务器概念及其计费模型（第2.1节）。然后我们讨论内存总线锁定技术（第2.2节）和无服务器平台的性能背景噪声（第2.3节）。Gringotts：用于无服务器计算的快速准确的内部拒绝钱包检测CCS2629∗42.1无服务器计算和计费模型作为一种新兴的云编程范式，无服务器计算的吸引力来自于按需付费的计费模式、部署的便利性、看似无限的可扩展性和有竞争力的性能。无服务器计算的计费模型基于“按需付费”的思想，并被AWS[28]，Google [16]，Microsoft [17]和阿里巴巴[7]等云提供商广泛采用，如表1所示计费模型中最重要的组件是持续时间成本，它从接收到新请求时开始，到返回响应时结束。例如，AWSLambda在1秒内处理一个请求，拥有1024 MB内存，将收取1美元的费用。667 10- 5用于持续时间成本。这种基于持续时间的计费模式使FaaS相对于IaaS具有价格但是，如果客户端的功能变慢或在一段时间内根本不运行，则可能会被过度收费。函数可以主动地（例如，睡眠）或被动地（例如， 等待I/O操作）在执行期间产生其分配的CPU。实验表明，CPU在被屈服后可以执行其他任务，但受害者仍将被收费，直到其功能在商品平台上返回响应。攻击者可以造成资源争用，并利用这一缺陷，将受害者的长期执行时间转化为财务枯竭。我们将这种攻击称为“拒绝钱包攻击”（第3.1节）。2.2内存总线锁定现代处理器采用一种特殊的技术来保持某些指令的原子性。当原子存储器操作（例如，ATOMIC_FETCH_ADD）跨越高速缓存线边界，硬件将短暂地停止其他存储器操作，以符合高速缓存一致性协议[2]。这个过程如图2所示，称为内存总线锁定，攻击者可以利用它来发现函数的协同定位或减慢受害者的执行速度。内存总线锁定在大多数云平台上都是允许的，并且很容易实现，无需任何额外的特权。诸如ATOMIC_FETCH_ADD之类的原子存储器操作通常用于多线程应用程序中，用于通过共享资源进行通信，甚至用于语言运行时（例如，2Python）包含这些指令。普通用户可以执行这样的3指令可以直接在它们的函数中编码，如清单2所示，或者通过语言运行时的实现隐式调用它们 鉴于这些操作的普遍性，云提供商无法通过简单的补丁来保护自己，例如禁止所有类型的原子操作。此外，这是一个影响所有x86硬件（Intel [2]和AMD [36]）和大多数云应用程序（例如，机器学习应用、HTTP服务器、键值存储等）。这些指令导致硬件级拥塞，操作系统级工具（例如，C组）不能检测或控制。为了证明现有的云平台仍然支持上述原子内存操作，我们验证了 AWS [28] ， Google Cloud Function [16] ， Microsoft AzureFunction [17]和Alibaba Function Compute [7]。我们分配一个连续的内存区域，然后在这个区域上执行一个八字节的原子操作，并增加偏移量实验结果CPU I攻击程序缓存行（cache_line）Ptr = Ptr +2©循环：ATOMIC_FETCH_ADD（ptr）CPU j……减缓Logical LLC…➀➀©LoopMemoryBus一级缓存（I/D）二级缓存Cache Line1CacL2高速缓存L1 Cache（I/D）受害函数LLC缓存片攻击者功能图2：内存总线锁定概述图3：原子操作导致的延迟峰值如图3所示 当一个8字节的原子内存操作跨越高速缓存线边界（偏移1-7），指令的执行时间从几十毫秒增加到数千毫秒。这为云服务提供商启用内存总线锁定提供了令人信服的证据。2.3性能背景噪声尽管虚拟机提供了强大的隔离性，Linux cgroups接口[34]强制执行了资源消耗限制，但商品FaaS平台显示出普遍的性能背景噪声，这对性能监控模型的精度有重大影响。许多因素导致了这种噪声，包括功能的短暂性，平台的调度等。deflambda_handler（event，context）：return{'statusCode'：200，'body'：b'Hello-World！“}的一个服务器（lambda_handler）。run（）清单1：Python Hello-World函数的示例我们测量类似于清单1的简单Python Hello-World函数的执行时间。 其他影响（如网关拥塞）被排除在外，因为它们不计入执行时间[49-52]。 图4显示了AWS Lambda和阿里云FC在四天内的周期性“流量潮”。同一天，同一功能的最大和最小执行时长差距在AWS Lambda上超过6倍，在阿里云FC上超过17倍3拒绝钱包攻击在接下来的部分中，我们首先介绍拒绝钱包攻击（第3.1节）。然后，我们通过提供一个真实的世界，CCSJunxian Shen etal.26306913# defineLEN 8192虚空memory_bus_locking（）{atomic_llong * ptr =（atomic_llong *）malloc（（LEN +1）*8）;atomic_llong * unalign_ptr = ptr +2;//开始锁定循环public intfindDuplicate（ inti =0; i ++）{public intfindDuplicate（ inti =0; j = 0）{atomic_fetch_add（unalign_ptr +j，1）、}}}空闲时间繁忙的时间图4：AWS Lambda[28]和Alibaba Function Compute[7]中无处不在的背景噪声示例（第3.2节）和讨论内部DoW 攻击检测的挑战（第3.3节）。3.1什么是拒绝钱包攻击我们将拒绝钱包（DoW）攻击定义为专门在无服务器平台上进行的拒绝服务（DoS）攻击的变体。一般来说，DoW攻击者利用DoS技术，如生成请求泛洪或将资源争用强加给4对目标租户施加压力。然而，有三个关键区别5DoW和经典DoS攻击之间的区别7首先，尽管DoS和DoW攻击都试图耗尽re-8受害者的来源，拒绝服务攻击者试图超过资源限制a-10而DoW攻击者则专注于按需付费计费11模型其次，拒绝服务攻击通常会导致完全无效-12服务的能力，而DoW攻击使普通用户可以访问服务最后，DoS和DoW攻击具有不同的财务后果。拒绝服务攻击会导致业务中断、声誉受损和客户流失。另一方面，DoW攻击将目标租户的压力转化为ISP的直接收费，因为受害者必须为使用的资源或实例付费。根据恶意资源消耗的发起位置，DoW攻击可以分为两种类型：外部DoW攻击和内部DoW攻击。 外部DoW攻击利用受害者的服务或资源API[24，38]并生成对这些API的大量调用。外部DoW攻击可以通过现有的DoS检测机制进行防御，例如入口过滤[13，74]，回溯[63，78]和源验证[33，69]。外部DoW攻击不是本文的重点。3.2如何发起内部DoW攻击内部DoW攻击是通过触发共享硬件上的资源争用来执行的。攻击者部署恶意功能利用协同定位检测技术，并调用它们来过度利用未被监视但至关重要的共享资源。受害者将获得正确的函数执行结果，但由于无服务器计费模式（第2.1节）和较长的执行时间，受害者将被多次收费。 在内部DoW攻击中，目标受害者的函数是属于特定用户的一组函数。 在选择目标受害者的功能后，攻击者可以通过以下三个步骤执行标准的内部DoW攻击：步骤1：恶意函数放置。攻击者以普通用户的身份部署了数百个函数，并期望它们与受害者驻留在同一台物理机器上。使用共址验证方法，攻击者然后终止不位于同一位置的函数。 在本文中，我们采用了一个类似于[76]的隐蔽通道进行协同定位验证;其伪代码包含在第8节中。清单2：内存总线锁定的一个例子步骤2：创建资源争用。然后，攻击者执行在步骤1中部署的位于同一位置的恶意函数，以减慢目标函数的执行速度。当调用这些功能时，将执行存储器总线锁定（第2.2节）。为了执行存储器总线锁定，攻击者可以将跨越高速缓存行边界的原子存储器指令编程到它们的函数中。对于Intel x86架构[2]，这些操作是语言指令（例如，互锁。C#中的增量，原子Golang中的.AddUintptr，C++中的ATOMIC_FETCH_ADD等）其将被翻译成将触发自动锁定协议的机器代码（例如，XCHG）或具有前缀#（例如，XADD）。我们使用内存总线锁定（如清单2所示）来创建共享资源争用，但这不是基本的。据报道，对许多共享资源（如PCIe I/O交换机[65]，缓存[23，32，81]甚至电源管理[6，20]）的争用会降低整个物理机的性能。这些对共享硬件资源的争夺也容易进行，难以辩护。第三步：直接资金耗尽。最后，现收现付的计费模式会将性能损失转化为受害者的资金枯竭。假设资源分配保持配置不变，执行时间成倍增加，用户花费的资金量将因攻击而增加为了展示内部DoW攻击的实用性和可行性，我们按照上述三个步骤对AWSLambda [28]，Microsoft Azure Function [17]和Alibaba FunctionCompute [7]Gringotts：用于无服务器计算的快速准确的内部拒绝钱包检测CCS2631∼∗∗∗∗∗∗(a) DoW攻击对函数执行时间的影响图6：Azure跟踪的样本验证率[80]。(b)DoW攻击对每次请求成本的影响图5：真实世界的拒绝钱包攻击示例3.2.1攻击设置。 为了简单和通用性，我们实现了T0T1T2T3T4检索到的数据时间类似于清单1的Hello-World函数作为牺牲函数。为了检测共同居住，我们实现了一个类似于[76]的隐蔽通道受害者和攻击者的功能是从两个不同的帐户部署的，都由我们控制我们使用类似于清单2的代码在恶意函数中实现内存总线锁定。 为了确保受害函数的结果不受背景噪声的影响，我们在正常执行和攻击过程之间交替多次。 图4描述了每小时的性能波动，而我们的实验是在分钟尺度上进行的。在攻击之前和之后，我们观察到受害者功能的持续时间发生了显著而稳定的变化我们使用云平台提供的API检索实验结果（资源使用或按请求计费信息）对于不提供直接定价信息的平台，我们使用相应的计费模型手动计算金额[49，50，52]。3.2.2攻击结果。 图5a描述了受害函数在攻击前后的执行时间。这种攻击大大降低了受害者 在AWS Lambda上，受害者的原始平均函数执行时间为0。93，而这个数字增加到34。44后，被钉，增加了37。03次。在阿里巴巴FC上，受害者的平均持续时间增加了78。88次，从1. 45到11437岁Azure的平均持续时间增加（从13。71������比35）不如AWS Lambda和阿里巴巴FC。这可能是由于Azure平台不允许用户调整函数使用的CPU数量[17]。必须指出的是，所有平台都执行相同的功能。 Azure函数在正常执行期间的平均执行时间（13. 71）比AWS（0. 9月10日），表明Azure计划了受害者函数。在袭击中Azure和AWS都必须为受害者分配整个CPU功能，因此它们的性能几乎相同（35毫秒）。图5b显示了每个请求成本的上升。自2000年以来，受害函数的理论使用在攻击之前和之后没有改变，函数的增加的成本与其执行持续时间成正比。值得注意的是，在阿里巴巴FC中，执行时间和资源消耗不会以相同的因子上升 我们认为，这是因为平台在为资源开发票时，以请求为单位对执行时间进行了舍入。图7：使用固定长度窗口进行采样一个假设的受害者场景。 考虑AWS Lambda定价示例[50]中描述的以下场景：受害者部署移动后端应用程序。 该程序配置有1536MB内存，每月处理300万个请求，每个请求的响应时间为120。该应用程序预计将使用5。410 5的资源，受害者应收取2美元。73减去4 10 5免费层数量后。但是，如果恶意租户进行内部DoW攻击，受害者可能会消耗1。99810 7的资源，并将收取326美元。33、一次申请。3.3准确检测是当务之急DoW攻击是通过恶意利用同一台裸机上的租户之间共享的硬件资源来执行的为了检测这种不当行为，平台必须监视和分析特定裸机的资源使用特征然而，由于无服务器工作负载是短暂的且动态性极强，因此准确检测DoW攻击存在两个重大挑战。不适当的抽样引起的误差 以前的研究，如内存DoS检测[30，79]，性能和资源干扰预测[4，15，29，35，41，54，62，70，75]都使用了固定长度的窗口采样方法来记录性能指标和资源消耗属性。每隔几毫秒，示例代理就会通过硬件处理器计数器监视器（PCM）工具获得与资源相关的统计信息。这种使用固定长度窗口进行采样的方法忽略了无服务器系统中定期变化的函数上下文，导致数据无效和损坏。数据失效是由无服务器函数的众所周知的短暂特性引起的，因为函数在采样时可能不会执行。为了证明，我们使用[80]中的轨迹进行模拟，如图6所示。我们使用10到10的固定采样窗口大小计算每个函数收集的无效数据的累积分数 。 超过80%的函数的有效率低于20%。数据损坏是由函数之间以及同一函数的请求之间的性能指标性能度量实际数据F1（t）性能度量F2（tF2（t信息歧义？？？时间的t0 T 1 T 2 T 3SF′2SF′1F1SSF2SCCSJunxian Shen etal.用户攻击警报攻击警报函数调用运营商数据传输Serverless平台资源监视器共享资源PGysicalMacGine功能 剂功能剂诊断程序图8：古灵阁的建筑。用户和操作员收到攻击警报并采取其他措施。如图7所示一方面，无服务器解决方案通过在同一CPU核心上复用不同功能来实现高资源利用率。由于不同的应用程序呈现显著不同的指标，这种多路复用将组合它们。 另一方面，性能指标可能会根据请求的性质而显著变化。[40]演示了图像模糊函数的内存消耗如何根据输入图像的大小而显着变化。此外，[30]中广泛使用的指标，如末级缓存（LLC）命中/未命中，在处理各种请求时也会发生显著变化。噪声环境引入的错误无服务器系统比IaaS更拥挤，IaaS将虚拟机放在一起，数量小于或等于核心数量。裸机上的无服务器实例数量可能很容易超过100 [64]，这带来了更大的去噪挑战。此外，无服务器功能的突发工作负载[61]使检测模型复杂化 平台必须确定性能指标的变化是由流量激增还是DoW攻击引起的。4系统概述架构古灵阁由两个高级组件组成：（i）代理和（ii）诊断程序。图8显示了古灵阁的简化系统架构。为了利用平台提供的无服务器服务，用户必须将他们的代码集成到云提供商提供的运行时模板中[25，44，45，57-59]。 在收到租户的请求后，云提供商将从集群中选择一台服务器，并在该物理机上部署上传的功能。平台将根据用户的订阅分配指定数量的资源，函数运行时将维护一个处理循环来处理接收到的请求。古灵阁的代理人负责监控目标功能的资源利用情况。 它由平台合并到每个受监视功能的运行时中，并与任何其他运行时组件一样与实例一起部署（例如，HTTP请求处理、函数日志）。该代理将自动执行，收集硬件性能指标，每次用户调用的功能。功能度量被收集，聚集到基于请求的单元中，然后被传输到诊断程序。Agent接受来自平台的协调，并保持与用户功能相同的生命周期.古灵阁的诊断程序在物理机器上执行内部DoW攻击的实际检测从代理接收到的聚合性能指标可以通过HTTP、gRPC [19]等协议传输，甚至可以通过搭便车它对目标功能进行实时的每请求检测，而不需要在同一台机器上执行本地执行，云提供商可能会根据工作负载为每几台机器部署一个诊断程序。当怀疑DoW攻击时，向用户和平台操作员提供攻击警报。他们还可能采取其他行动，例如验证DoW攻击和阻止损失。指标名称指标描述LOAD_L3_MISS失效的加载uop未命中L3。LOAD_L3_HIT使用L3缓存的失效加载uop点击作为数据源。拆分负载已停用的跨拆分的加载uop高速缓存行边界。Split_商店已停用的存储uop跨高速缓存行边界。简体中文L1D和L2为锁定，由于UC锁或分裂锁。公司简介每个缓存未命中条件对于LLC的引用LLC_REF来自核心的请求，引用LLC中的高速缓存行ICACHE_MISS指令缓存（ICACHE）未命中。表2：选定的PCM事件和相关描述[47]。以请求为导向的抽样。如图7所示，使用固定长度窗口进行采样的传统方法将导致无服务器计算中的信息模糊性 Gringotts采用面向请求的采样方法来克服这些缺点，原因有三：首先，通过在每个请求的上下文中监视工作负载，以轻量级的方式自动收集和聚合度量。防止了由功能复用引起的度量的波动。其次，通过跟踪请求上下文，古灵阁知道应用程序逻辑的生命周期。这种对应用程序逻辑的理解消除了大量的无效和冗余数据，这在IaaS或固定长度采样中很难实现。第三，面向请求的采样可以捕获函数的执行模式，使用请求作为模式。这样做是非常直观的，因为类似的输入可能会导致类似的执行。公制选择。表2显示了从英特尔的PCM向量[47]中选择的用于表征资源利用率的确切指标古灵阁根据两个主要标准选择性能指标。首先，它们与DoW攻击相关，因为内部DoWGringotts：用于无服务器计算的快速准确的内部拒绝钱包检测CCS攻击利用存储器总线锁定来产生资源争用。其次，它们反映了应用程序的工作负载 这些指标捕获所监视函数的耗时指令，包括缓存未命中和内存访问。当跨高速缓存线边界的内存区域访问，如SPLIT_LOADS和SPLIT_STORES指标将收集有关地下内存总线锁的信息。其他指标，如LOAD_L3_MISS或LOAD_L3_HIT，与退役的高速缓存或内存操作有关5性能度量收集在本节中，我们首先简要介绍代理（第5.1节）。然后我们讨论古灵阁如何解决数据模糊性挑战（5.2节）并实现低开销（5.3节）。最后，我们强调了代理设计中的一些额外优势（第5.4节）。5.1工作流古灵阁设计的关键要素是以需求为导向的抽样。传统的监测系统往往采用定长采样的方法，无法解决信息模糊的问题。相比之下，面向请求的采样通过将请求处理的应用程序级功能与性能计数器的硬件级指标相结合，准确地捕获了运行时特征。图9显示了古灵阁的一个简化工作流程，用©-®注释。 当函数作为运行时冷启动的结果被部署时，代理立即启动初始化以构造相关联的数据结构（步骤©）。 之后，代理执行PCM事件注册（步骤）。新一轮的度量收集由请求的到达触发（步骤©）。指标收集器利用低级接口从硬件性能计数器（HPC）收集性能度量（步骤104）。步骤③将采样数据入队到环形缓冲区中。 一旦请求完成处理（Step ®），所有缓冲数据将以单一、直接的方式传送到诊断程序。聚合的性能指标存储在JSON样式的字符串中。例如，请选择您的语言，您的语言可能会被格式化为：{_：，_：，_：J−���，������������������������������������������������������������1：���1J−���1;������������������2：���2J−���2;.. .}5.2功能度量协调信息二义性是由于多路复用、运行时破坏以及函数行为的变化而产生的，其中一种度量与无效样本或其他类型的度量混合。古灵阁有效解决信息歧义问题的关键思想是协调高层功能行为，同时收集低层性能指标。为了解决与多路复用相关的问题，我们建议将度量收集行为绑定到运行时。更准确地说，当上下文发生变化时，我们保存或恢复度量。我们通过利用Linux [37]的perf_event_open（）系统调用来实现这一点，选择它是因为该实现提供了最佳性能。然而，应该注意的是，我们的解决方案仅与perf_events工具接口兼容[18]。perf_events的三种分析模式是基于周期/频率的的请求功能发出请求不执行循环T′接收处理请求发送剂however，©请求事件T， T′><度量收集器联系我们登记PCM活动低级接口结果转发HPC诊断程序图9：古灵阁计数、分析和跟踪。它的目标和采样方法与古灵阁有很大不同。为了解决运行时销毁的问题，我们在每个运行时中包含一个Agent。具体来说，我们实现这一点，使用动态的library加载，这最大限度地减少了程序修改的需要。这确保了仅在执行无服务器功能期间收集指标。为了能够正确检测函数行为的变化，我们创造性地利用了无服务器架构的面向请求的特性。每当运行库接收或发送请求时，都会主动调用度量收集器模块，而不是被动调用。 与输入、输出和函数行为之间的映射规则令人困惑的VM相反，无服务器函数以精确表示函数活动边界的方式接收和发送请求。虽然不同的请求可能会导致函数的行为不同，但在处理相同请求时，处理逻辑基本上是相似的。5.3性能开销可忽略不计执行低开销、细粒度的测量并不简单。为了实现这一点，我们必须最大限度地减少任何不必要的性能开销，这会影响古灵阁如何定位代理。我们不能在与被测量的功能分离的进程中运行代理，因为这将使采样进程受到操作系统的调度、跨核HPC访问、上下文切换开销等的影响。因此，古灵阁将代理实现为用户级动态库，该库由函数主动调用，以最大限度地减少采样过程的每次开销。 为了进一步优化采样效率，我们使用用户模式指令（如rdpmc）读取和写入性能监视计数器，从而避免可能导致性能问题的系统调用。 除了与在语言内调用动态库相关联的开销（例如，Python增加了额外的24开销），采样本身可以在不到1的时间内执行。我们构建了Gringotts来收集类似于SHIM[75]和[37]的细粒度度量，如算法1所示。在每个采样周期开始时，古灵阁使用RDTSCP指令来获得CCSJunxian Shen etal.2634←（）（）下一页古灵阁对内存操作施加一个排序约束（第3行）。通过读取元数据，该算法保证：⎣���1⎦⎢⎣������⎢⎥⎦..算法1细粒度度量收集算法输入：-触发事件，-元数据，-预定义寄存器输出：抽样性能指标一曰： 如果，则2：记录时间戳//记录时间戳3：（）//读取前的排序约束4：为←做5：断言不[].6：←（）//在用户模式下读取寄存器���������������的设计是使用HPC来验证受害者功能的工作负载。验证通过采用执行时间和HPC之间的线性关系来解决[35]中指出的归因困难问题。 如果执行时间和工作负载之间的相关性发生了变化，则可以很容易地识别DoW导致的“变慢”现象。古灵阁从代理收集所需的数据。然后，它计算请求接收和响应发送之间度量的增量数据具体地，[ 1，���2，···，������]表示7：���.���������_//存储在缓冲区���8：结束9：（）//读取后的排序约束10：如果结束当处理请求时函数的度量的变化 ，并且时间表示执行时间。 我们将矩阵R1定义为聚合度量输入，矩阵R2定义为时间输入，R3定义为所选PCM事件的数量，R4定义为请求的数量第11章：回归⎡���1���2···������ ⎤⎡ ���1⎤1222112···������ ⎥..⎢ ���2⎥��� =...，���=.⎥当前时间戳（第2行）。然后，内存屏障[37]被用于⎢⎥⎢. ⎥性能监视计数器不多路复用（第5行）。接下来，它访问用户中perf_event_open（）预定义的寄存器模式（第6行）。最后，采样结果立即存储在缓冲区（第7行），然后是另一个存储器屏障（第9行）。5.4额外的优点5.4.1意外刹车发出采样命令的时间与实际采样动作之间的时间差称为事件滑移。 它可能是由操作系统的调度、执行延迟或乱序执行引起的。事件滑移是一个典型的性能分析问题，我们证明了它对古灵阁没有影响。 首先，度量的收集发生在与运行库相同的用户模式环境中。即使操作系统在执行功能时对其进行调度，其度量也会在进程切换期间保留而不进行修改其次，我们利用内存屏障来抑制采样前后的乱序执行。最后，由执行延迟引起的事件滑动被限制在大约10条指令内，并且对无服务器请求的结果没有影响5.4.2易于使用。 Gringotts公开了四个API，允许开发人员自定义Agent的采样 行为： init（）， add（），sample（）和extract（）。 当进程或线程启动时，它会自动调用init（）来构造数据结构。然后它使用add（）命令注册PMC事件sample（）用于执行主动采样，而extract（）用于提取指标。 这对租户来说是透明的，因为它被合并到函数运行时中。此外，平台开发人员可以在某些情况下轻松覆盖这些API。6DOW检测模型在本节中，我们将介绍我们对诊断程序（第6.1节）的主要见解然后，我们演示古灵阁的检测模型（6.2节）。6.1基于HPC的验证诊断程序不是直接检测在诸如存储器总线之类的共享资源我们不检测异常值。在训练阶段，我们假设，所有数据都正常。在测试阶段，离群数据可能这是攻击的结果我们也不对数据应用滑动 每个数据都显示了与处理请求相关的工作负载。当输入不同时，滑动平均值违反了我们的观察。6.2检测模型6.2.1对应用程序和用户行为的假设。对于无服务器功能和用户，我们假设以下行为：该函数由用户定义的外部输入激活，这与无服务器概念一致。即使一个函数有多个触发器，它也不是自动执行的。每个函数的用户输入符合独立同分布（i.i.d.）。 也就是说，输入的分布在整个时间内保持不变，并且在调用之间彼此无关。当新部署功能时，攻击不会立即发生。这意味着每个函数中的第一个解密数据是未受到攻击的正常数据6.2.2检测模型。 我们强调道检测作为一个问题，时间序列异常检测无法解决。 基本原理是完成请求所需的工作负载基本上独立于先前完成的请求。由于FaaS优于IaaS的这一显著特征，我们无法使用之前的检测方法[30，79]。我们将DoW检测问题描述为函数工作负载的多变量分布离群值检测函数的工作负载可以用两种方式表示：其处理时间和其内容（例如，完成的指令的数目、LLC未命中的数目等）。前者可以直接用当前请求的执行时间来表示，而后者表示函数处理请求所执行的任务当函数处于不同的状态（正常或被攻击）时，它们的对应关系是不同的 这是直观的，因为当受到攻击时，函数将继续执行相同的任务，但其执行时间将增加。因此，DoW的核心概念···2···������Gringotts：用于无服务器计算的快速准确的内部拒绝钱包检测CCS2635（）N（）∼（−）/（−）/.E|−.（+）、×（−）/（−）/[客户端]������( ���),������() ∝������������2=（，···，，）中国（ 北京，（2）=1·检测是确定当前工作负载是否符合每个请求级别的正态分布函数工作负载的总体分布是可学习的，但它不能简单地表示为LLC未命中或引用的线性函数。而不是这样，古灵阁将工作负载分解为所选择的性能指标的线性组合。我们使用 “性能指标”来表示性能指标������在处理请求的同时���，古灵阁在检测延迟方面比时间序列异常检测方法有什么优势？(Sec 7.3）诊断程序的参数如何影响古灵阁的精度？(Sec（第7.4段）古灵阁探测模型的总体预测准确性如何？(Sec（第7.5段）7.1实验装置.试验台。我们使用两个节点的Kuber进行实验-在训练阶段，用z分数归一化处理训练集，即，J=，J=。 变 换 后 的