Rust 1.35 稳定版预发布测试
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable
1.35增加的一些特性摘要:
- 为
Box<FnOnce>
,Box<FnMut>
, 和Box<Fn>
实现了FnOnce/FnMut/Fn。(来自社区 @crlf0710的贡献 ),相关PR:#59500 - 支持将闭包转换为usnafe的函数指针。
- 增加了
wasm32-unknown-wasi
Target。 - 线程在Debug模式下将显示ID。
alloc::System
实现了Default
。dbg!()
支持无参数调用。- ASCII转换速度提升了4倍速。
- 稳定了一些API。
kakoune编辑器已经支持了async/await关键字高亮
#kakoune #IDE #editor
(头一次听说kakoune这个编辑器,恕我无知)。期待其他编辑器也支持,最好是能支持自定义各种emoji。
不过VSCode又多了一个语法高亮的插件:Tree Sitter,号称可以提供更好的Rust高亮。
「异步Explained系列」Rust异步如何工作
#futures #async
cargo-permissions: 检测篡改依赖的Cargo权限
#crate #cargo #security #PoC
为了在crates.io中保持健康安全的包(crate),需要尽可能多地强制检测任何类型的漏洞。随着软件包之间依赖关系的使用增加,漏洞传播的风险也会增加。在NPM等其他平台上,我们已经看到了很多这样的安全问题。Rust开发人员需要一个工具来回答有关其依赖关系的问题:
- 为什么png库使用网络层?
- 为什么http库使用文件系统层?
- 可能的场景(Possible scenarios)
- 读取未授权文件
- 请求不可信域名
- 执行未授权代码
- 盗取信息
- 盗用CPU资源
- 不安全地执行代码
cargo-permissions是一个概念证明的库(PoC),基于通过查找代码中的特定路径来检测恶意代码的想法,来保证crate的安全。此项目的主要思想是拥有一组与某些特定标准包列表相关联的权限。另一方面,通过AST分析,检查crate中使用的标准库。例如,如果包A开始使用std::net
库,则将获得net权限。所有使用包A作为依赖的crate都会间接获得net权限。遵循此方法,可以构建具有所有获取权限的依赖关系树。通过这组权限可以获取「超出控制范围的crate」尽可能多的信息。
### 「官方」Unsafe Rust安全检查:栈借用模型 2.1
#miri #unsafe_ub_check #stack_borrow
ralfj比较高产,他负责Unsafe下内存模型相关的工作,目的是用miri来检测unsafe中的UB行为。为了达成这个目标,他陆续研究出以下一些借用模型:
栈借用模型1:
他在去年引入了栈借用模型1用于定义在unsafe内存模型中允许哪种别名。建立合理的别名规则,才能基于miri来检查unsafe下的UB行为。
该模型的核心思想是: 对于一个内存位置,逐步建立可跟踪的引用,形成一个栈结构。比如有一个&mut i32,可以对其重新借用获得一个新引用。这个新引用是必须用于此位置的引用,建立在旧引用之上。当新引用过期的时候,旧引用会被激活,就好像是栈结构push和pop。
在Safe Rust中,通常有借用检查来保护内存。但是在编写Unsafe代码的时候,借用检查就无法提供帮助了。所以,Rust核心团队就必须要定义一组规则,即使对于Unsafe代码来说也是非常有意义的。
栈借用模型2:
在上一篇文章中,ralfj又带来了栈借用模型的升级,栈借用2。
在栈借用1模型中,有一个概念叫做「frozen」,处于frozen位置的指针,只能读取,不能写入。它允许可变借用也能读取(检查粒度比较粗,把可变指针和共享指针同一化处理)。但是现在该模型被发现一个问题:当使用可变借用的时候,在该模型下可能会把某些未定义行为判断为合法。为了改进这个问题,栈借用模型2将精确跟踪允许访问的原生指针(更细粒度的检查,区分了共享指针和可变指针),而不是「frozen」。检查粒度比模型1更细。
栈借用模型2还有很多已知的问题,比如其实并没有真正使用到「栈」,反而更像「树」。但这还不是最后的结论。本文比较长,去原文阅读更多信息。
栈借用模型2.1:
在今天这篇文章中,ralfj又发现了上次的栈借用2模型存在一些问题:结合内部可变性,行为并不总是他们想要的。在模型2.0中,说到其实没有真正使用「栈结构」是在读取访问的时候,事实上进行「写访问」的时候,还是可以维护一个「栈结构」。
fn main() { unsafe {
let c = &UnsafeCell::new(UnsafeCell::new(0));
let inner_uniq = &mut *c.get();
// stack: [c: SharedReadWrite, inner_uniq: Unique]
let inner_shr = &*inner_uniq; // adds a SharedReadWrite
// stack: [c: SharedReadWrite, inner_uniq: Unique, inner_shr: SharedReadWrite]
*c.get() = UnsafeCell::new(1); // invalidates inner_shr
// stack: [c: SharedReadWrite]
let _val = *inner_shr.get(); // error because the tag is not on the stack any more
} }
对于这段代码,之前是「合法的」,但是用栈模型2.1来处理的话,就是UB。UnsafeCell是一个内部可变性容器,栈借用模型2.1会在栈中维护SharedReadWrite指针。像上面代码第4行,如果在设置了inner_shr之后,又重置了c变量容器内的值,栈借用结构就会改变,最后一行再使用inner_shr指针就可以检测到非法了,它是一个UB。但是在栈借用模式2.0中,最后代码执行的时候,堆栈将改为[c:SharedReadWrite,inner_shr:SharedReadWrite],从而允许最终访问,这就是问题所在。
这样一来,相当于是栈模型1.0和栈模型2.0的结合?还可以在Unsafe代码导读中看到栈借用模型2.1的完整描述。
后续:ralfj将会写一篇关于栈借用模型的完整论文,当然,可能还是他自己的博士论文更重要吧,毕业最重要了。
Rendy 0.2发布
#gfx #Amethyst #Render
Rendy是基于gfx-hal的一个渲染引擎,属于Amethyst的项目。提供各种工具,如内存分配,资源管理,渲染图执行等。gfx-hal是99%的Vulkan API。 这就是Rendy存在的原因。而不是解决内存分配和纹理上传等低级任务,用户可以专注于创建令人敬畏的高性能渲染器。
case-studies: Rust实例探究
#learning #study
该库展示了一些棘手的Rust代码示例,这些代码是dtolnay(syn作者,Rust宏的高手)在使用Rust(他自己和其他人)中的各种高级宏库时遇到的问题集合。该项目致力于对Rust宏开发的一个深刻洞察:擅长使用宏的人和宏专家之间的区别主要与他们擅长“宏”的程度是无关的。
这也许是学习Rust宏的一个非常好的案例。
Mozilla图像团队发布WebRender MVP
#mozilla #webrender
WebRender使用与游戏相同的基于GPU的加速技术重写了Firefox渲染架构,现在适用于一些选定的Win10设备。WebRender使用的现代架构主要是:
- 合成器中页面的表示不再是一组栅格化图层,而是现在的一个未经过图形化的显示列表。
- 合成和光栅化步骤已加入到单个GPU驱动的渲染步骤中。
有关更多详细信息,请参阅Lin Clark的Hacks系列文章。
Rust Nightly 1.36.0中已经弃用了mem::uninitialized
#nightly
Rust的臭名昭著的mem::uninitialized
方法在今天的每晚构建中已被弃用。它的替代品MaybeUninit
已经开始稳定。如果你正在使用前者,则应尽快迁移到使用后者(可能在6周内达到稳定)。因为这是一个break change的修改。
这篇文章主要讨论了未初始化内存的性质以及如何在Rust中使用它。并且探讨了mem::uninitialized
为什么会被弃用,以及MaybeUninit
是什么。
多语言混合项目的一些经验
#ffi #C #Polyglot
长文预警!作者在写自己的库bitvec的时候,开始考虑,如何将其用于其他语言,比如他如果在一个C++程序中想用bitvec怎么办?所以他开始设计一套针对为Rust crate编写FFI的惯用法。这篇文章记录了他从API设计到实现的一些经验,值得一读。
From 日报小组 @Chaos
日报订阅地址:
独立日报订阅地址:
社区学习交流平台订阅:
评论区
写评论还没有评论