泰晓资讯 07月 / 第一期 / 2019 —— 资讯收集

[unicornx]

泰晓资讯 07月 / 第一期 / 2019 —— 资讯收集

[unicornx]

The TCP SACK panic: an unpleasant remote denial-of-service vulnerability in the kernel's networking stack.

Selective acknowledgment (SACK) is a technique used by TCP to help alleviate congestion that can arise due to the retransmission of dropped packets. It allows the endpoints to describe which pieces of the data they have received, so that only the missing pieces need to be retransmitted. However, a bug was recently found in the Linux implementation of SACK that allows remote attackers to panic the system by sending crafted SACK information.

Selective acknowledgment (SACK) 是 TCP 协议中用到的一种机制，该方案提出时间是在 1996 年，具体可以参考 RFC 2018，其用处是可以帮助减少丢包重传所导致的拥塞。网络的端点（endpoint）可以利用这个机制，来告诉对端自己收到了哪部分数据，然后对端就只需要重新传送缺失的部分数据即可。不过，最近在 Linux 的 SACK 实现中发现了一个 bug。远程攻击者可以利用该漏洞，通过发送特制的 SACK 信息让接收方的 Linux 系统产生 panic。

[unicornx]

More frequent Python releases?: the Python community considers changing its release cadence.

Python has followed an 18-month release cycle for many years now; each new 3.x release comes at that frequency. It has worked well, overall, but there is interest in having a shorter cycle, which would mean that new features get into users' hands more quickly. But changing that longstanding cycle has implications in many different places, some of which have come up as part of a discussion on switching to a cycle of a different length.

多年来，Python 一直按照 18 个月的周期进行发布; 至少每个新的 3.x 版本都是以这个频率发布的。 总体而言，该机制运作良好，但社区中有些人希望能够缩短发布的周期，这样新的功能可以更快地进入用户的手中。 但是改变这个周期势必会在许多不同的地方产生影响，不少人对这个想法提出了各自的意见，比较激进的人建议调整后的周期为 9 个月，也有人建议是 12 个月，也就是按年为单位发布。究竟最后的决定是多少，让我们拭目以待。

[unicornx]

Short waits with umwait: kernel support for a new set of power-saving Intel instructions, but there are some possible security implications.

If a user-space process needs to wait for some event to happen, there is a whole range of mechanisms provided by the kernel to make that easy. But calling into the kernel tends not to work well for the shortest of waits — those measured in small numbers of microseconds. For delays of this magnitude, developers often resort to busy loops, which have a much smaller potential for turning a small delay into a larger one. Needless to say, busy waiting has its own disadvantages, so Intel has come up with a set of instructions to support short delays. A patch set from Fenghua Yu to support these instructions is currently working its way through the review process.

对于一个应用来说，虽然内核可以提供好几种实现超时等待的手段，但如果等待的时间较短，譬如是几微秒级别的，则这些手段都无法保证超时时长的确定性（由于时钟精度等问题可能会导致等待超长），所以程序员一般更倾向于直接采用忙等待的方式（有限次数的忙循环，busy loops）。毫无疑问，这么做有好处也有坏处，最大的坏处就是忙等待会浪费处理器的计算能力，除了导致发热，对于支持超线程(hyperthread)的处理器来说还会阻碍另一个超线程的运行。为此，Intel 公司在其即将推出的 "Tremont" 处理器上提供了几个新的指令来改进这个问题，可以支持无需忙等下的短时长延迟，而从 kernel 的角度来说，则需要为该特性提供一定的封装，方便用户的使用。具体的补丁由 Fenghua Yu 实现。在对该补丁的 review 过程中有人提出该功能可能会涉及一些安全性方面的问题。具体内容请参考原文描述。

[unicornx]

Dueling memory-management performance regressions: an important memory-management fix is held up due to a performance regression with a different workload.
这篇介绍过于专业，不适合在资讯中介绍

[unicornx]

Rebasing and merging in kernel repositories: an upcoming kernel document on repository management.

Maintaining a subsystem, as a general rule, requires a familiarity with the Git source-code management system. Git is a powerful tool with a lot of features; as is often the case with such tools, there are right and wrong ways to use those features. This document looks in particular at the use of rebasing and merging. Maintainers often get in trouble when they use those tools incorrectly, but avoiding problems is not actually all that hard.

如果你需要维护内核代码，首先需要熟悉的是如何使用 Git 这个源码管理工具。Git 是一个功能强大的工具，该工具的每个功能都有其正确的用法，但我们也会发现一些常见的错误用法。这篇文章主要专注于给大家介绍了 rebase 和 merge 这两个方面，如果您对提交和维护内核代码感兴趣，不妨仔细读读这篇文章。当然与之对应的，这篇文章的作者（大名鼎鼎的 Jonathan Corbet 先生）为了在合并内核代码期间减少子系统维护者所碰到的问题，专门提交了一份类似主题的 kernel document，预计会随 5.3 版本合入，放在 Documentation/maintainer/rebasing-and-merging.txt 目录下，另外还有一个在线的维护者手册页在 https://www.kernel.org/doc/html/latest/maintainer/index.html ，大家也可以去看看。

[unicornx]

CNCF outlines its technical oversight goals: the evolution of the Cloud-Native Computing Foundation's governance.

At KubeCon + CloudNativeCon Europe 2019 there was a public meeting of the [Cloud Native Computing Foundation](Cloud Native Computing Foundation) (CNCF) Technical Oversight Committee (TOC); its members outlined the current state of the CNCF and where things are headed. What emerged was a picture of how the CNCF's governance is evolving as it brings in more projects, launches a new special interest group mechanism, and contemplates what to do with projects that go dormant.

来自 KubeCon + CloudNativeCon Europe 2019 的报道。随着 Cloud Native Computing Foundation (CNCF) 引入了越来越多的项目，有关如何加强基金会管理的问题日益突出。CNCF 在 2016 年创始之初只有一个项目，即 Kubernetes。截至 2019 年，该基金会旗下第一梯队（相对成熟）的项目有 6 个，处于 “孵化期（incubating）” 阶段的项目有 17 个，另外还有 15 个项目刚刚启动。这么多的项目是否值得被基金会接受以及如何发展，这些工作都由 CNCF 中的一个独立的委员会 Technical Oversight Committee (TOC) 来负责。

[unicornx]

https://seclists.org/oss-sec/2019/q2/223

自称 Linux 内核黑客的微软开发者 Sasha Levin 希望代表雇主申请加入 Linux-Distros 邮件列表，要知道 Linux-Distros 邮件列表被各大 Linux 发行版用于报告、协调和讨论尚未公开的安全问题。如果获得批准微软将能了解有关内核及其代码漏洞、补丁和安全问题的幕后讨论。为了证明微软有资格像 Ubuntu、Debian 和 SUSE 那样成为 Linux-Distros 的成员，Sasha Levin 举了 Azure Sphere 和 Windows Subsystem For Linux (WSL) 2 的例子。有趣的是内核的主要维护人员 Greg Kroah-Hartman 也发邮件力挺 Sasha，愿意为其担保。

[unicornx]

Linux Boots On “Shakti” — India’s First Ever RISC-V Based Silicon Processor

RISC-V Workshop in Chennai, India, hosted by The Indian Institute of Technology Madras (IIT Madras), achieved a significant milestone by booting Linux on its first ever RISC-V based silicon chip processor named Shakti (Project Page).

印度钦奈的 RISC-V 研讨会由印度马德拉斯技术学院（IIT Madras）主办，在发布了其首款基于 RISC-V 架构的处理器 “Shakti”(代表女性力量的印度神话人物)之后，又成功地在基于该处理器的系统上启动了Linux，实现了一个重要的里程碑。据悉印度 Shakti 处理器 2016 年启动开发，基于开源的 RISC-V 指令集架构，得到了印度电子和信息技术部的大力支持。

[unicornx]

Huawei Adding New LZ4 Inplace Decompression To EROFS File-System

华为向 EROFS 文件系统添加新的 LZ4 解压缩支持

This new EROFS support allows for LZ4 decompression to happen in-place so that data decompression can be done without any memory copies. This, of course, is helping out performance. Gao Xiang of Huawei commented on one of the patches, "On kirin980 platform, sequential read is slightly improved to 778MiB/s after the new decompression backend is used."

EROFS 的新特性支持 LZ4 本地解压缩，避免了数据解压缩过程中的内存拷贝。 这有助于提高处理效率。 来自华为的补丁提交者 Gao Xiang 在注释中介绍说，“在 kirin980 平台上，在使用新的解压缩算法后，顺序读的速率略微提升，达到 778MiB/s。”