泰晓资讯·5 月 / 第一期 / 2022

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

• Linux 内核最新消息

https://lkml.org/lkml/2022/4/24/467

Linus Torvalds 发布了 Linux 5.18-rc4，到目前为止，内核在 5.18 版本的开发周期已经过半，总的来说看起来不错。Linus Torvalds 在 rc4 的发布邮件列表中指出：

Fairly slow and calm week - which makes me just suspect that the other shoe will drop at some point. But maybe things are just going really well this release. It’s bound to happen occasionally, after all. It’s not only a fairly small set of commits, the diffstat is pretty small and flat too. The biggestsingle patch is literally killing off a zombie file that had already been deleted - well, renamed,really - once, but it didn’t know to stay dead, and was resurrected by a merge mistake. The changes are sprinkled all over, they just aren’t all that big: arch updates (sound being the bulkof it, but “bulk” really is fairly misleading), some driver updates, a couple of filesystem fixes,memory management, networking, and some tooling (mainly a couple of selftests).

看上去老李对目前版本进展之顺利都有点不太自信了。rc4 的变化依然不大：和往常一样，主要涉及一些 arch 上的更新、一些驱动程序更新、一些文件系统修复、内存管理、网络，以及一些工具。

不出意外，Linux 5.18 应该会在 5 月底左右发布。

https://www.kernel.org/ updated by 2022/4/28

关键词: Linux

• 统一 /dev/random 和 /dev/urandom 工作的最新进展

Originally attempted with Linux 5.18 were patches so /dev/urandom and /dev/random would behave exactly the same. That was dropped though due to not enough randomness at boot for some platforms like Arm 32-bit, Motorola m68k, Microblaze, Xtensa, and others. But then the change went in to opportunistically initialize /dev/random as a best-effort approach where it at least works nicely on x86/x86_64. The good news is that original unification effort may be re-visited in the future now that the original blocker issue has been addressed.

社区曾经在 5.18 开发期间尝试统一 /dev/urandom 和 /dev/random 的行为。不过，由于 ARM32、Motorola m68k、Microblaze、Xtensa 等平台在启动时无法提供足够的随机性种子，这个尝试被放弃了。随后的尝试是希望通过 opportunistically 的方式在初始化 /dev/random 改进其行为，并至少在 x86/x86_64 上获得比较好的效果。

好消息是，相关补丁的作者 Jason Donenfeld 在 twitter 上发布消息声称，影响统一行为的那些老架构的问题已得到解决：

So what this means is: the rationale for reverting the /dev/random + /dev/urandom unification has now been fixed. That’s some real tangible progress.

Now, I don’t want to rush into trying the unification again too soon. I think if anything, the lesson from the first attempt wasn’t simply, “I should fix a few of Guenter’s test cases,” but rather that the problem is fairly nuanced and will take a lot wider testing and research. However, the fact that the initial thing, across multiple platforms, that lead to the revert has been fixed gives me a decent amount of optimism that at /some point/ down the road, we’ll be able to try this again. One step at a time.

这真是一个实实在在的进步。Jason 在 twitter 上对未来表示乐观，认为既然最初的阻碍问题已经得到解决，那么将来我们可能会重新尝试最初的统一工作。

Hopefully we’ll be able to reattempt the unification of /dev/random and /dev/urandom at some point down the road. https://t.co/G93meKsluu was the first good news about the prospects for that in the future, with some very preliminary patches that chip away at the challenges. https://t.co/rgPZsiW9Tl — Edge Security (@EdgeSecurity) April 25, 2022

更多介绍请访问新闻原文出处，“/dev/random + /dev/urandom Unification May Be Revisited In The Future, Blocker Addressed” https://www.phoronix.com/scan.php?page=news_item&px=Random-Unification-Future。

关键词: Linux, random，urandom

• Linux 5.19 将支持采用 Zstd 压缩固件（Firmware）

For two years there has been interest and unmerged patches for allowing Linux’s plethora of firmware blobs to be Zstd-compressed for helping to save disk space. Finally it looks like for Linux 5.19 that optional Zstd firmware compression support will be merged.

两年来社区一直有兴趣在 Linux 中采用 Zstd（Zstandard 压缩算法）压缩固件，从而帮助节省磁盘空间，但相关修改一直没有合入主线。但目前看起来这个功能会合入 Linux 5.19。

之所以 Linux 内核希望更多地使用这个由 Facebook 开发的 Zstandard 压缩算法，在很大程度上要归功于其非常快速的解压缩性能和其他现代特性。从透明文件系统支持的压缩功能到使用 Zstd 压缩内核映像，内核中越来越多地使用它。采用 Zstd 压缩固件其压缩率比不上目前的 XZ 算法，但解压缩的速度要快得多，这对于快速加载固件是一个优势。

截至上周末，Greg Kroah-Hartman 已将 Zstd 加入 driver-core-next 开发分支，这为其代码合入 5.19 做好了准备，而 Linux 5.19 的合并窗口估计在 5 月底左右会打开。

在补丁中将现有的 FW_LOADER_COMPRESS 配置选项进行了拆分，原 FW_LOADER_COMPRESS 作为总开关控制是否启用固件压缩，同时新增两个子项 FW_LOADER_COMPRESS_XZ 和 FW_LOADER_COMPRESS_ZSTD，前者使用 XZ 算法，后者使用 Zstd 算法，Zstd 算法解压缩的固件后缀以 .zst 结尾。

更多介绍请访问新闻原文出处，“Zstd Compressed Firmware Will Finally Be Supported With Linux 5.19” https://www.phoronix.com/scan.php?page=news_item&px=Zstd-Firmware-Linux-5.19-Next。

关键词: Linux, Zstd

• Linux 内核的 KMSAN 补丁，有助于捕获未初始化的内存问题

One of the Linux patch series that has been in the works for years in conjunction with Clang compiler side changes and already being responsible for exposing hundreds of kernel bugs is the KernelMemorySanitizer (KMSAN). Sent out today was the latest patch series working on the kernel infrastructure for catching uninitialized memory issues.

KernelMemorySanitizer (KMSAN) 这个补丁已经开发了好几年了，这个补丁配合 Clang 编译器端的修改，而 Clang KMSAN 代码可以追溯到 2018 年。虽然该补丁还未被合入主线，但在两者相互配合下，已经帮助我们找出了内核中数百个错误。

26 日来自 Google 的 Alexander Potapenko，也是 KMSAN 补丁的作者，又发布了一个新的版本，可以用于捕获未初始化的内存问题。Potapenko 指出， "KMSAN has reported more than 300 bugs in the past few years, most of them with the help of syzkaller. Such bugs keep getting introduced into the kernel despite new compiler warnings and other analyses (the 5.16 cycle already resulted in several KMSAN-reported bugs). Mitigations like total stack and heap initialization are unfortunately very far from being deployable. The proposed patchset contains KMSAN runtime implementation together with small changes to other subsystems needed to make KMSAN work."。KMSAN 在过去几年中报告了 300 多个错误，其中大多数是在 syzkaller 的帮助下。尽管有新的编译器警告和其他分析支持，但针对栈和堆初始化的检测还未支持。这次新提交的补丁包含 KMSAN 运行时的实现以及对其他子系统的小改动。这包括了超过四千行新代码。对 KernelMemorySanitizer 感兴趣的人可以阅读 Alexander Potapenko 的这个 2020 年的 PDF slids（https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/glider/Fighting_uninitialized_memory_%40_CBL_Meetup_2020.pdf）

更多介绍请阅读新闻出处，“KMSAN Patches For The Linux Kernel Updated For Catching Uninitialized Memory Problems”: https://www.phoronix.com/scan.php?page=news_item&px=KernelMemorySanitizer-2022。

关键词: Linux, KMSAN

• Android 13 Beta 1 发布，继续关注隐私和安全性

Google today announced the first public beta of Android 13.

Google 于本月 26 日发布了 Android 13 的第一个公开测试版。Google 在 Android 13 开发中继续关注 “隐私（privacy）和安全（security）”，包括新的通知权限、更精细的媒体文件访问权限，这里的媒体文件仅限于图像/视频/音频类型，更好的密钥处理错误报告等等。Android 13 Beta 1 还计划支持 anticipatory audio routing、蓝牙 LE 音频、基于 USB 的 MIDI 2.0、以及新的 API 等。但这些心功能预期要到今年晚些时候才能就绪。

新发布的 Android 13 Beta 1 版本可以在受支持的 Google Pixel 设备和 Android 模拟器上运行。

更多有关 Android 13 Beta 1 版本的详细信息，请访问 Android 开发者博客：https://android-developers.googleblog.com/2022/04/android-13-beta-1-blog.html。

更多介绍请阅读新闻出处，“Android 13 Beta 1 Released - Continues Focus On Privacy & Security”: https://www.phoronix.com/scan.php?page=news_item&px=Android-13-Beta-1。

关键词: Android

• Yocto 4.0 来了

The Linux Foundation based Yocto Project for making it easy to create Linux-based IoT/embedded operating system software builds is out today with Yocto 4.0.

Linux 基金会旗下的 Yocto 项目使得创建基于 Linux 的物联网和嵌入式操作系统软件构建变得容易，本月 27 日该项目发布了 Yocto 4.0 版本。

Yocto 4.0 在构建中将 Linux 内核升级到 5.15 LTS，并支持更新的工具链组件（如 GNU C Library 2.35），以及其他大约 300 种软件的升级。

Yocto 4.0 中还包含了其他各种修复和改进，譬如在网络访问上现在默认情况下设置为禁用，添加了许多新的 Python 3 扩展包等。Yocto 4.0 还从 Gzip 切换到 Zstd 以提供更好的性能，本次升级还带来了各种针对 ARM 和 RISC-V 的改进，以及各种其他增强。

更多有关 Yocto 4.0 的信息，请访问 YoctoProject.org （https://www.yoctoproject.org/）上的发布公告和项目网站。

新闻出处，“Yocto 4.0 Released For Embedded/IoT Linux Software Stack”: https://www.phoronix.com/scan.php?page=news_item&px=Yocto-4.0-Released。

关键词: Yocto

• GCC 11.3 发布，包含近 200 个错误修复

While GCC 12 (GCC 12.1 stable) will be out in the coming weeks, GCC 11.3 is out today as the latest stable release in the current GCC 11 series.

虽然 GCC 12（GCC 12.1 stable）将在未来几周内发布，但 GCC 11 系列的升级并没有停止，本月 21 日还发布了 11.3 版本。GCC 11.3 是去年推出的 GCC 11 系列的最新错误和回归修复小版本。自去年引入 GCC 11.2 以来，GCC 11.3 修复了超过 189 个错误。大多数错误修复不会被广泛关注，但很高兴看到 GNU 编译器工具包中改正了这么多问题。

在 GCC 11.3 中的众多修复中，有针对各种 Darwin 和 macOS 的问题、许多 C++ 和 libstdc++ 修复、许多 RISC-V 修复等。

新闻出处，“GCC 11.3 Released With Nearly 200 Bug Fixes”: https://www.phoronix.com/scan.php?page=news_item&px=GCC-11.3-Released。

关键词: GCC

• LLVM 14.0.2 发布

LLVM 14.0.1 released just earlier this month while already LLVM 14.0.2 is out today. LLVM normally sees just a single point release and traditionally happened mid-to-late in the development cycle ahead of LLVM’s next major release. But now LLVM is moving to shipping point releases every two weeks.

LLVM 14.0.1 刚刚在本月初发布，四月还未结束，27 日又发布了 LLVM 14.0.2。虽然过去 LLVM 通常只会在两个主要版本发布之间的开发周期的中后期针对上一个主要版本发布一个小版本。但现在 LLVM 正在改变这一策略，而是更频繁地发布小版本，大概每两周就会发布一次小版本。这些小版本严格遵守只对错误进行修复的原则，并保持与当前主要版本的 API/ABI 兼容。根据这个发布时间表，大概发布大约五个小版本后，会停下来专注于推出下一个主要的 LLVM 版本。LLVM 主要版本坚持大约每六个月更新一版的节奏。

LLVM 发布经理 Tom Stellad 于 27 日早上宣布了 LLVM 14.0.2。此版本中有三十多个修复，解决了 RISC-V、CMake 构建相关的问题。在这次小版本发布中改动最多的是和 RISC-V 有关的问题修复。

与此同时，LLVM 15.0 将在 9 月到 10 月之间发布，这个新版本将包含一批令人兴奋的编译器新功能。

新闻出处，“LLVM 14.0.2 Released With The Compiler Moving To Bi-Weekly Releases”: https://www.phoronix.com/scan.php?page=news_item&px=LLVM-14.0.2-Released。

关键词: LLVM

联系我们

欢迎扫描二维码加微信联系我们：