提要内容： 本次记录主要按照会议顺序来记录
30:00 Kickoff, eBPF themes and use cases
42:00 The Future of eBPF in the Linux Kernel
57:00 Q&A
1:02:02 Multi-cluster networking with Cilium at Form3
1:13:37 Q&A
1:19:10 Large Scale Cloud Native Networking and Security with Cilium/eBPF
1:33:00 eBPF - The Capital Market's Perspective
1:59:50 Welcome back after the break
2:00:59 Cilium Standalone XDP L4 Load Balancer
2:13:56 eBPF, a road to invisible network: S&P Global's Network Transformation Journey
2:56:15 When you need to overcome your fear and build your own data-driven eBPF firewall
3:12:32 Troubleshooting and healing networks with eBPF
3:17:57 IO latency monitoring using eBPF
3:24:20 Improving Cilium's eBPF-based DSR performance by adding support for IP-in-IP
3:29:40 The promise of eBPF for the edge
3:44:23 Capture the Flag (CTF)
4:00:43 eBPF: Innovations in cloud native
4:25:52 Q&A
4:30:34 eBPF and Cilium at Google
4:34:40 Q&A
4:48:53 Closing
the future of eBPF in the Linux Kernel
by Alexei Starovoitov
一开始回顾了ebpf技术的发展历史以及个人感想： to innovate and enable others into innovate
Rust and BPF
很快Rust也要合并在Linux Kernel 6.1 中，他与BPF有着相同的目标： 安全的内核编程 【意大利转舌式英文】 通过举例说明了： BPF 通过 稳定的API或者是关联内核进程来执行，那么Rust是否也会一样呢？
Rust: safer than C
BPF: true safe C
Multi-cluster networking with cilium at form3
Form3的广告宣传时间 商业上判断世界支付方式的发展：
- Volume -- 用户数量
- Reliability & durability -- SLA and 低成本纠错
- Maintenance -- 附加服务的增值
cilium 的安装配置经验分享：
- 使用Helm chart 安装，在集群配置好的时候安装【但是在work node 加入之前】
Large Scale Cloud Native Networking
trip.com--携程
没听懂怎么应对这个Large的，结构上如何使用了cilium也待再次探究
the capital market's perspective
Alex Mackenzie
主要分享的是自己对于eBPF技术发展的看法，从市场的角度来说。 eBPF 是市场宠儿：
- APM
- Runtime Obeservability
- API Obervability
- Service Mesh
cilium standalone XDP Load Banlancer
首先介绍了其使用xdp cilium 的架构环境
将原本的IPVS变成cilium
实验结果证明是：
它说明cilium替换了IPVS有更高的性能，更低的消耗 我找到一篇相关的文章来说明对应的问题：
a road to invisible network
(讲话好快啊，吐字有点不太清楚。。) S&P Global 所属的人www.spglobal.com/en/
系统架构图：
开始使用多云CNI的一些建议（主要是怎样使用ciliunm来解决对应的问题）
Signed eBPF Programs
ThalerDave
code is permitted if program is provably safe AND source is authorized
本演讲的核心是对在内核当中何时代码才能够被准许运行（Signed）机制的一个调研和汇总说明
首先对比了经典的积累代码验证的机制：
- HyperVisor
- Binary Signing
- Volume Signing 补充动静态函数的验证不相同，静态是在编译的时候，动态是在运行的时候。
那么对于eBPF程序，他是如何被验证的呢？
- eBPF 验证的形式：
- source code
- byte code eBPF 指令，以ELF格式存储，在JIT，compiler中使用的
- Position-independent code 他所提及的是： Processor-specific code ，pre-relocation 比如x64指令集
- native code 重定向之后的结果，是实际在内存当中执行的代码
- eBPF-enlightened application 调用eBPF的程序或者是使用他们的程序
- Signature 所能够包含认证的内容
- 程序本身（字节码， PIC，或者是native code）
- Package/Container（在这里指的是： 一个用户空间的app + 任何配套的eBPF程序）
- 满足协同存储，比如kubernetes
- L3AS 使用 Packages
- Bumblebee 使用 容器
- Repository(Signature覆盖整个Volumer,directory 以及其他repository） 补充到认证只会检验eBPF是否都来自同一个仓库
- Source of program (eBPFB本身没有Signed,只有当app运载她的时候才会认证)
- 能够支持动态程序而不使用在线验证码
- 需要 interpreter（side channel attack concerns）或者是 动态码页支持（no HVCI）
- eBPF的选择 如此多的选择和想法，eBPF实际采用的内容：
GateKeeper 概念
- Strict default GateKeeper可以在开始之后的任何时候加载
- Loose default 必须在否认某些程序之前运行： Linux （eBPF在内核当中，就会在启动阶段加载） Windows （eBPF属于外来的驱动，就会在启动eBPF Driver的时候加载）
最终结论是，经过以上考虑得出目前的eBPF验证设计过程。【可能科研上有钻的地方】
When you need to overcome your fear and build your own data-driven eBPF firewall
eBPF + XDP 手动实现一个firewall 【抱怨了怎样来对eBPF deBug】
eBPF&XDP 在内核拦截数据包之后，获取 源地址IP，目标地址IP ，目标地址MAC,并检测eBPF Map当中是否有记录，没有记录的包就直接丢弃。 在用户层，写一个控制面的程序，不断读取或者直接修改eBPF Map当中的内容，以此达到 firewall 的功能.
Troubleshooting and healing networks with eBPF
Martynas Pumnutis
就是主要介绍下自己写的eBPF包，功能上能干些啥，我感觉和他的题目没有太大关系？
包的位置： github.com/cilium/pwru
- 读取
/sys/kernel/btf/* - 找到可以接受skb的函数
- 将eBPF关联到2当中找到的内核函数
- 读取 perf buffer
能够将数据从物理网卡直接转到pod的虚拟网卡，只需要设置两个参数就可以
-filter_)dst = $POD_ID
-output-meta -kmods = $KMODS
【第二个参数干啥还需要理解下】
IO latency monitoring using eBPF
在哪里监测，怎样检测，对比proc stats,整个流程。
1.eBPF HOOK
raw_tracepoint/block_bio_aueue
raw_tracepoint/block_bio_complete
-
eBPF monitoring 下述是控制结构，但没给详细的代码
-
未来的一些工作 可以提交PR？
【没有更多了，比我期望讲的少】
Improving Cilium's eBPF-based DSR performance by adding support for IP-in-IP
字节跳动的人
字节现有两种地址转换的方式：
-
SNAT
走两遍LoadBalancing,让他来做ClientIP--VIP--PodIp之间的转换
-
DSR(Direct Server Return)
这个相当于减少了在一层在LoadBalancer这里的地址转换，但需要多考虑一个VIP地址转换回来该怎么对应的问题。
然后发现了一个瓶颈问题就是：
在网络交换机上有 slowpath 和 fastpath，IP报文附带有option会选择slowpath，这个情况下，交换机的CPU几乎是满载的
【没有进一步解释怎么导致这个问题或者说明白之间的因果关联】
这样做的好处：
- 走的是fast path
- 对UDP更小的MTU以及对TCP更小的Syn pkt
The promise of eBPF for the edge
Toke Hoiland Jorgensen
先是讲了Ebpf and RedHat的 过往史 然后提出：
- 网络流量上
- 更低成本的路由，对象是Container 或者NFV
- 更小的CPU消耗
- 控制面
- 低成本监控
- 应用资源消耗报告
- 安全
- 防火墙优化和DDoS防护
- 应用的隔离
- 更多自定义的安全防控方式
再来提到 hook co-existence 的进一步强化
- 可以让其他程序访问hook
- 限制这类访问的范围
- 该做的工作
- 安全模式的定义
- root权限覆盖的工具
Capture the Flag (CTF)
Kahoot
问答知识环节，主要是回顾
eBPF: Innovations in cloud native
解释eBPF为何适合云原生的发展：
- eBPF加速开发的流程:主要是因为他帮助了内核的分模块式开发或者说把内核的开发完善相当于外包了
- 让应用更加接近数据，不用再走内核繁杂的处理流程，各取所需。
- eBPF能够带来更短暂的数据使用周期以及地址位置可知的环境
- eBPF能让流量更加快速的转发和流动，延迟更低
- eBPF提供了内核专有的隔离能力，不用再造轮子，尤其对于一些子系统来说，不需要再额外实现基础内核就能提供的功能【这是不是能够减少docker镜像的大小啊，让他直接用操作系统的内容就可以了】
- 更快的内核错误觉察以及修改测试
- eBPF能够提供更加深层的观测视角，以及系统视角；主要功能还是体现在监测上面。
- eBPF实现了操作系统的数控分离【原话是将UAPI解耦同时提高了数据处理的效率】
- 有更强的标记能力和规则制定管理能力，比如标签识别、定位转发等等、
- “开发内核”，但是却更加安全的方式
提出了未来eBPF要做到的内容：【目前还不能够做到】
- 建立更多模块，吸引更多的开发者
- 认证以及供给链的安全
- Profiling BPF with BPF【自动化啊】
eBPF and Cilium at Google
一句话： cilium好用。。。
