< 返回版块

mook 发表于 2023-01-04 18:59


turmoil - 由 Tokio 推出用于开发和测试分布式系统的框架



ReadMore: https://tokio.rs/blog/2023-01-03-announcing-turmoil




alloc-track = "0.2.3"
use alloc_track::{AllocTrack, BacktraceMode};
use std::alloc::System;

static GLOBAL_ALLOC: AllocTrack<System> = AllocTrack::new(System, BacktraceMode::Short);

3.调用 alloc_track::thread_report() 或 alloc_track::backtrace_report() 来生成一个报告。


sync_cow - 线程安全的写时克隆容器,用于快速并发写入和读取。



ReadMore: https://crates.io/crates/sync_cow

如何在 Rust 中生成没有三方库依赖的随机数


但这是如何发生的呢?在开始在 Rust 中生成随机数之前,让我们先了解随机数生成的过程,以及如果没有特殊的硬件,就永远无法创建真正的随机性。



From 日报小组 冰山上的 mook && MalikHou



shanliu 2023-01-05 20:57

都是用于普通场景的伪随机数 不加硬件来生成的情况下不可能产生真随机数

zhuxiujia 2023-01-04 23:45


苦瓜小仔 2023-01-04 19:28

注意,随机数的这篇文章在 reddit 发布 20 小时之后仅有个位数的 upvote,而且被招致许多批评,所以它并不是一篇值得参考的文章。

The current timestamp is often used as a unique seed value. That precise time never occurs again

Except for all the reasons for it to happen again e.g. leap seconds, ntp adjustment, incorrectly configured clock, plain fucking with clock, etc... etc...

The difference between /dev/random and /dev/urandom is that /dev/random only returns random bytes within the estimated number of bits of noise in the entropy pool

That's a linuxism: on openbsd and freebsd they're literally the same device, both block until seeded then never block anymore (and they might never block at all because both have at-boot entropy data).

And it's not even true anymore since kernel 5.6, now /dev/random blocks until initialised then stops blocking forever (/dev/urandom still never blocks, so can provide degraded randomness during boot).

Thus /dev/urandom is theoretically vulnerable to a cryptographic attack on the algorithms used by the driver and less random than /dev/random. /dev/random is more suitable for very high-quality randomness applications such as one-time pad or key generation.

This is and has always been utter nonsense. This literally links to a list of "myths about /dev/urandom then proceeds to repeat these myths ffs.

Another external way of generating random numbers is to call the C library function rand(). [...] This has the same disadvantages as getrandom, it requires the C library for linking and has unsafe code.

The primary disadvantage of rand() is that it's unspecified and usually trash. All the BSDs literally title the manpage "bad pseudo-random number generator". rand(3) is barely a step up from xkcd/221 (if it's a step up at all, at least xkcd/221 is reproducible cross-platform, or even at all, there's no guarantee whatsoever that updating your libc won't change the behaviour of rand(3)).

The bottom line is, if we allocate something, take the pointer to it, retrieve the address, and cast it to an integer; we will get a random number. The address in the memory is not totally random, but probably random enough to do stuff™.

The "randomness" comes from ASLR, which is extremely limited on 32b systems (8~16 bits of entropy). 64b systems have more room, but it's still absolutely awful as an rng, IIRC on x86_64 Linux it defaults to 28 bits (you can check /proc/sys/vm/mmap_rnd_bits for the value on your system, last I checked it could be set from 28 to 32 inclusive).

If the allocator uses brk instead of mmap, it's worse, you get 13 bits of entropy out of the brk ASLR. Or less if you use huge pages.

from: masklinn

Sigh... It's disheartening how often "number of dependencies" gets used as a crate evaluation metric. As I wrote in this proposal, I believe that more often than not it's a misleading metric. You don't like that rand has getrandom, rand_core, and rand_chacha as dependencies? But those crates are developed by rand developers! From a practical standpoint, a project split into a number of crates is as good as a single dependency. Even better, such crates enable parallel compilation and free reuse of relevant parts of the project without pulling the whole monolith with kitchen sink.

from: newpavlov

1 共 3 条评论, 1 页