领手工在家做的网站,在线做任务的网站,页面设计制作网站源码,揭阳市php网站开发找工作作者简介#xff1a;张毅峰#xff0c;某主机厂架构师。一、eBPF安全可观测性的前景展望本次分享将从监控和可观测性、eBPF安全可观测性分析、内核安全可观测性展望三个方面展开。1.监控(Monitoring)vs可观测性(Observability)从上图可以看到#xff0c;监控只是可观测性的冰…作者简介张毅峰某主机厂架构师。一、eBPF安全可观测性的前景展望本次分享将从监控和可观测性、eBPF安全可观测性分析、内核安全可观测性展望三个方面展开。1.监控(Monitoring)vs可观测性(Observability)从上图可以看到监控只是可观测性的冰山一角而大部分都隐藏在水面之下的深层次问题无法简单通过监控解决。目前监控也开始可视化但绝大部分都是事先预定义参数然后事后查看日志进行分析。监控的缺点包括可扩展性差需要修改代码和编译验证周期长数据来源窄等问题。可观测性是通过主动定制度量的搜集和内核数据聚合包括以下三种Logging实时或者事后特定事件信息分布式服务器集群的海量数据溯源图离散信息整理各种异步信息Tracing数据源提供数据来源采集框架往上对接数据源采集解析发送数据往下对用户态提供接口前端交互对接Tracing内核框架直接与用户交互负责采集配置和数据分析Metrics度量这也是可观测性与监控最主要的区别系统中某一类信息的统计聚合比如CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等情况。当度量值触发异常阈值时系统可以发出告警信息或主动处理比如杀死或隔离进程主要目的监控Monitoring和预警Alert总结一下监控和观测的区别监控收集和分析系统数据查看系统当前的状态对可预见的问题进行分析处理可观测性通过观察系统并衡量系统的内部状态从其外部输出的数据推断出来系统此时处于某种程度的度量特别是我们所关心的场景和事件2.eBPF安全可观测性分析先简单定义下什么是安全安全指的是某种对象或者对象属性不受威胁的状态。所谓安全可观测性通过观测整个系统从低级别的内核可见性到跟踪文件访问、网络活动或能力capability变化一直到应用层涵盖了诸如对易受攻击的共享库的函数调用、跟踪进程执行或解析发出的 HTTP 请求。因此这里的安全是整体的概念。提供对各种内核子系统的可观测性涵盖了命名空间逃逸、Capabilities 和特权升级、文件系统和数据访问、HTTP、DNS、TLS 和 TCP 等协议的网络活动以及系统调用层的事件以审计系统调用和跟踪进程执行。从日志、跟踪及度量三个维度检查相关输出进而来衡量系统内部安全状态的能⼒。eBPF的安全可观测性表现为对内核来说其存在感极低但观测能力却异常强大药效好副作用小程序沙箱化通过eBPF验证器保护内核稳定运行。侵入性低无须修改内核代码且无须停止程序运行。透明化从内核中透明搜集数据保证企业最重要的数据资产。可配置Cilium等自定义乃至自动化配置策略更新灵活性高过滤条件丰富。快速检测在内核中直接处理各种事件不需要回传用户态使得异常检测方便和快速。其中的程序沙箱话离不开更安全的eBPF Verifier其中最重要的是边界检查拥有加载eBPF程序的流程所需的特权无crash或其他异常导致系统崩溃的情况程序可以正常结束无死循环检查内存越界检查寄存器溢出eBPF的可观测性应用场景主要有以下三类1.云原生容器的安全可观测性这也是传统BPF基于网络应用场景的进一步发展随着云网边端的急速发展人们的目光越发的聚焦在目前最火热的云原生场景上。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor是现阶段云原生场景下比较流行的几款运行时防护方案。这些方案主要是基于eBPF挂载内核函数并编写过滤策略在内核层出现异常攻击时触发预置的策略无需再返回用户层而直接发出告警甚至阻断。以预防的方式在整个操作系统中执行安全策略而不是对事件异步地做出反应。除了能够为多个层级的访问控制指定允许列表外还能够自动检测特权和 Capabilities 升级或命名空间提权容器逃逸并自动终止受影响的进程。安全策略可以通过 KubernetesCRD、JSON API 或 Open Policy AgentOPA等系统注入。2.应用层安全可观测方案3.内核层安全可观测方案3.内核安全可观测性展望下面从传统内核安全、Android内核安全、KRSI等几个方面展开讨论。传统内核安全方案存在着诸多需要解决的问题正如Linus Torvalds曾经说过的大多数安全问题都是bug造成的而bug又是软件开发过程的一部分是软件就有bug。至于是安全还是非安全漏洞bug内核社区的做法就是尽可能多的测试找出更多潜在漏洞这样近似于黑名单的做法。内核代码提交走的流程比较繁琐应用到具体内核版本上又存在周期长以及版本适配的问题所以导致内核在安全方面发展的速度明显慢于其他模块。同时随着智能化、数字化、云化的飞速发展全球基于Linux系统的设备数以百亿计而这些设备的安全保障主要取决于主线内核的安全性和健壮性当某一内核LTS版本被发有漏洞这样相关的机器都会面临被攻破利用的局面损失难以估量。嵌入式领域的Android内核安全现如今世界上越来越多的智能终端包括手机、TV、SmartBox和IoT、汽车、多媒体设备等等均深度使用Android系统而Android的底层正是Linux内核这也让Linux内核的安全性对Android产生重大影响。由于历史原因Google在Android内核开源的问题上理念和Linux内核社区不是十分的匹配这也导致了Android对内核做了大量的针对性修改但是无法合入到Upstream上。这也导致了Android内核在安全侧有部分不同于Linux内核侧重点也存在不同。在操作系统级别Android平台不仅提供Linux内核的安全功能而且还提供安全的进程间通信 (IPC)机制以便在不同进程中运行的应用之间安全通信。操作系统级别的这些安全功能旨在确保即使是原生代码也要受应用沙盒的限制。无论相应代码是自带应用行为导致的结果还是利用应用漏洞导致的结果系统都能防止违规应用危害其他应用、Android 系统或设备本身。Android内核安全特性HWAddressSanitizer硬件支持的内存检测工具KASANTop-byte IgnoreKCFI流控完整性校验ShadowCallStack堆栈保护目前工作的关注重点是内核安全可观测性利器-KRSIKRSI (Kernel Runtime Security Instrumentation)的原型通过LSM (Linux security module)形式实现可以将eBPF program挂载到kernel的security hook安全挂钩点上。内核的安全性主要包括两个方面Signals和Mitigations这两者密不可分。Signals意味着系统有一些异常活动的迹象、事件Mitigations在检测到异常行为之后所采取的告警或阻断措施KRSI基于LSM来实现这也就使其能够进行访问控制策略的决策但这不是KRSI的工作重心主要是为了全面监视系统行为以便检测攻击最重要的应用场景但目前主要还是只做检测居多因为贸然做阻断处理可能会比较危险。从这种角度来看KRSI可以说是内核审计机制的扩展使用eBPF来提供比目前内核审计子系统更高级别的可配置性。KRSI工具可以看作是eBPF和LSM的强强联合KRSI eBPF LSM1.KRSI允许适当的特权用户将BPF程序挂载到LSM子系统提供的数百个钩子中的任何一个上面。2.为了简化这个步骤KRSI在/sys/kernel/security/bpf下面导出了一个新的文件系统层次结构——每个钩子对应一个文件。3.可以使用bpf()系统调用将BPF程序(新的BPF_PROG_TYPE_LSM 类型)挂载到这些钩子上并且可以有多个程序挂载到任何给定的钩子。4.每当触发一个安全钩子时将依次调用所有挂载的BPF程序只要任一BPF程序返回错误状态那么请求的操作将被拒绝。5.KRSI能够从函数级别做阻断操作相比进程具有更细粒度危险程度也会小得多。后续计划内核安全问题是个非常复杂的话题牵一发而动全身防御机制、加固配置、漏洞利用等等挑战性的技术。在进行加固防御的过程中又会产生性能或者系统稳定性相关的影响。从eBPF LSM的角度可以更加可视化、数据丰富的观测内核安全情况进而在内核Livepatch、漏洞检测以及防御提权相关攻击手段上有着进一步的发展空间。二、Linux进程调度与性能优化本次分享将从进程调度概念、进程调度框架、进程调度算法和性能优化四个方面展开。1.进程调度概念最初的Linux只有进程task_struct相当于进程控制块(PCB)后来出现了线程task_struct就开始对应线程。Linux没有从概念上直接区分两者如果不同的task_struct间共享资源它们属于同一进程中的线程否则就属于不同的进程。这里要注意用户态中的进程和线程与内核态间的映射关系用户态函数getpid()得到的是内核中的tgid用户态函数gettid()得到的是内核中的pid。Posix支持一级调度和二级调度两种模式二级调度会先调度进程然后才是进程中的线程。而Linux选择的是直接调度线程的一级调度效率会比二级调度高。Linux进程调度体系如下图CPU资源管理器(what)调度器scheduler就是CPU资源管理器因为操作系统的重要作用之一是管理各种系统资源而CPU是其中最重要的资源。常用直接共享型资源的管理方法有时分、空分、独占等IO一般是独占资源内存支持空分管理而CPU只支持时分因此这种时分管理方法就是进程调度。为什么要及为什么能调度(why)为什么要调度宏观并行微观串行支持多任务的协作与抢占。最初是协作后来为了防止个别进程长期霸占CPU引入了抢占机制。为什么能调度包括主动调度和被动调度线程上下文可切换。调度时机(when)主动调度通过主动调用sched_yield的自愿性主动调度以及进程由于等待资源而阻塞的非自愿性主动调度。被动调度触发点设置 TIF_NEED_RESCHED 标志主要是时钟中断和唤醒抢占。执行点检查 TIF_NEED_RESCHED 标志 和 满足preempt_count 0的条件。主要包括以下四种场景系统调用完成返回用户空间完成返回用户空间中断完成返回内核空间出禁用抢占临界区如何进行调度(how)调用pick_next_task()选择下一个调度进程和通过context_switch切换进程上下文内存空间寄存器和栈。下面按时间顺序简单介绍一下linux调度器的发展历史传统Unix调度器区分IO密集型和CPU密集型但全局只有一个未排序的运行队列多CPU会有竞争而且调度选择需要遍历整个队列复杂度为O(n)。O(1)调度器运行队列从全局变成每个CPU一个链表分成活动和过期两个数组引入位图复杂度降为为O(1)。SD调度器考虑到会因为个别进程的伪装而造成的实际调度不公平不再区分IO和CPU密集型未合入内核。RSDL调度器组时间配额有点像Cgroup但未合入内核。CFS(完全公平调度器)从SD/RSDL中吸取了完全公平的思想目前内核主流调度器。可以从以下几个方面来评价调度器1.响应性存在大量人机交互的PC和手机要重视响应。2.吞吐量服务器更关心吞吐量而提高响应性会增加进程切换的评论也就会降低吞吐量。所以响应和吞吐是一对矛盾。3.公平性相对公平实际和理论的运行时间应该相符。4.适应性也就是可扩展性。5.节能性智能手机的需求需要通过调度均衡来省电。2.进程调度框架如下图所示Linux一共有5个调度类(stop和idle每个CPU一个)stop无调度策略用户空间不可用内核用来处理线程迁移等优先级极高的事情。idle无调度策略用户空间不可用无其他进程调用时才调用idle进程。deadline硬实时要在确定时延内完成调度。realtime软实时尽力而为保证实时性。time-share按优先级分配时间片。调度类之间的关系除非资源限制优先调度高优先级进程。但要注意Linux考虑到在恶劣环境下普通进程应该仍有被调度的机会会默认预留有5%的带宽给普通进程。如下图所示从用户空间到内核空间进程优先级会发生转换用户空间优先级分为1~99优先级从低到高的实时进程以及nice值-20~19动态优先级从高到低的分时进程。映射到内核空间优先级分为三步1.实时优先级实时进程不变分时进程从动态优先级映射为100~139静态优先级由高到低。2.规范优先级实时进程映射为-1~98优先级由高到低99为空分时进程静态优先级不变。3.动态优先级可以看到动态优先级几乎等于规范优先级只有在解决优先级反转问题时采用优先级继承策略时才会变化此时会体现为动态优先级。注意-1和-2分别对应deadline和stop的逻辑优先级。那如何进行进程切换呢切换用户空间不同进程的用户空间不同需要切换。切换内核栈不同进程共享内核空间但需要切换内核栈。进程切换就像火车切换轨道换道后车上的人感觉火车没变但是因为轨道变了行程也就跟着变了。线程的执行过程就是函数调用树的深度优先遍历进程的切换点是__schedule函数该函数前半部分在进程A的调用栈上执行后半部分就跑到进程B的调用栈上执行了返回则在新进程上执行。3.进程调度算法CFS调度器定义通过引入虚拟运行时间vruntimerealtime / weight每次选择vruntime最小的进程红黑树来管理来调度在真实硬件上模拟理想多任务处理器。枯燥的定义不太容易理解的话下面我们通过一个与实际生活比较贴近的例子来解释CFS调度模型。请仔细观察上图图中事物与进程调度的映射关系如下水杯表示进程盖子打开的水杯表示进程处于就绪和执行状态其中Ready Table上的水杯都是就绪态进程水龙头下的水杯是运行态进程。盖子闭合的表示阻塞态的进程它们都在不同的Wait Box中。水杯的粗细表示不同的优先级。watermark表示虚拟运行时间vruntimemin watermark会被pick to run。Ready Table表示可运行队列rq。Wait Box表示不同Event对应的等待队列如果只能由对应的Event唤醒的话就属于不可中断的深睡眠否则就是也可由signal唤醒的可中断浅睡眠。水龙头表示CPU水龙头中放出来的水就是CPU时间。操作pick to run的手表示调度算法如果调度过于频繁那杯子接的水就少水龙头的水掉地上浪费了响应好但性能差反之调度周期长的话杯子接的水太多会造成不平均性能好但响应差。权衡下来既不能接太少最小值就是调度粒度也不能接太多最大值就是时间片。这里需要特别注意的几点1.进程的状态注意区别进程的5种状态中的运行态和就绪态所有就绪态进程都位于cpu的运行队列中而每个cpu上当前只有一个运行态进程。可以看到下面的代码分别通过on_rq和on_cpu来确定进程是runnable的就绪态还是running的运行态。对应上面的例子桌子上的开口水杯表示就绪(on_rq)水龙头下的开口水杯表示运行(on_cpu)。2.优先级与权重CFS中的nice值会提前转换为权重nice的范围是 [-20 -- 19]为了使得两个相邻的权重的占比差为10%将以nice 0 为基准转化为1024整个数列是以1.25为公比的等比数列。将原来的等差数列转为等比数列因为调度策略的绝对值不重要相对值比例才重要。3.调度周期调度周期 调度粒度 * 就绪和运行进程的数量对应上面的例子就是所有开盖玻璃杯数量桌子上和水龙头下的与调度粒度的乘积等于调度周期所有杯子都接了一次水。最小调度周期等于最小粒度乘以数量如果计算算出来的时间片小于最小调度周期内核就会让时间片直接等于最小调度周期。4.调度延迟调度延迟是另一个概念对应上面的例子就是从开口玻璃杯放到到桌子上开始计算到送到水龙头下接水的时间。但要注意Linux中的调度延迟却不这个意思内核代码体现的调度延迟是最小调度周期也就是调度周期的最小值。4.性能优化单个进程的性能优化对于单个进程来说可以通过下面的系统调用来改变进程(线程)的调度策略和优先级只有特权进程才能调高自己的调度策略或者优先级。一般不要轻易地把进程设置为实时进程或者提高其优先级除非有充足的理由。系统响应性与吞吐量的优化系统的响应性和吞吐量是一对矛盾很多时候我们要根据具体的情况来对系统进行配置。CONFIG_PREEMPT是否开启内核抢占开启可增加响应性不开启可增加吞吐量。一般服务器系统不会开启桌面和移动系统会开启。定时器tick频率HZ定时器tick的频率HZ对系统的响应性和吞吐量也有很大的影响HZ取值较大系统响应性好但是吞吐量会降低HZ取值较小吞吐量会增大但是响应性会降低。避免实时进程过度占用CPU为此内核提供了一对参数可以设置一个运行周期内实时进程最多只能用多少CPU时间这样就可以给普通进程留下一些执行时间。这两个参数对应的文件是/proc/sys/kernel/sched_rt_period_us/proc/sys/kernel/sched_rt_runtime_us可以通过cat和echo来查看和设置具体的值单位是微妙默认值分别是1000000950000也就是说在每一秒内实时进程最多运行0.95s会给普通进程保留0.5s。当然如果此时没有普通进程实时进程还是可以使用100%的CPU时间的。如果我们不希望实时进程使用过多的CPU时间的话可以修改这个值。子进程是否优先运行的问题默认情况下父进程与刚fork出来的子进程谁会先得到执行是不确定的。如果在我们的环境中经常会fork子进程并且我们总是希望子进程比父进程先得到执行那么我们可以将/proc/sys/kernel/sched_child_runs_first值设为1。
