Lines Matching refs:it
20 it. This entropy pool needs to be initialized with a minimal level of entropy
21 before it can provide high quality, cryptographic random numbers to
48 Note that the time it takes to initialize the random pool may differ between
61 to credit entropy for it (i.e. data from this source wasn't considered good
62 enough to consider the entropy pool properly filled even though it was
86 to kernel mode Linux will query some random data through it, and feed it into
87 the pool, but not credit entropy to it. What kind of random source is behind
88 the EFI RNG API is often not entirely clear, but it hopefully is some kind of
99 userspace process the kernel invokes. Because of that it runs at a time where
109 * systemd assigns 'invocation' UUIDs to all services it invokes that uniquely
111 service invocation and relate it to other data. For example, log data
147 cryptographic-grade RNGs, it tries to avoid blocking reads to the kernel's RNG,
150 secure random numbers, but before it's initialized it has the nice effect of
158 1. When systemd's PID 1 detects it runs in a virtualized environment providing
159 the `virtio-rng` interface it will load the necessary kernel modules to make
160 use of it during earliest boot, if possible — much earlier than regular
169 into the kernel entropy pool. By default it does not credit entropy for it
173 before generating the image it should be safe to credit entropy, which can
178 became writable. This is usually too late for many applications, it is hence
201 the random seed provided in the EFI variable and credit it fully to the
212 and kept sufficiently secret it should not be possible to regenerate the
231 image there's no point in it. That said, OS builders that know that they are
248 With the four mechanisms described above it should be possible to provide
293 pool, and during early boot it's not going to be filled yet, very likely. We
294 do use it in many cases, but not in all. Please read the above again!
301 `flags` set to zero, and some additional limitations, and thus it also needs
332 already feeds into its pool anyway (and thus shouldn't be fed into it a
333 second time, crediting entropy for it a second time) or is at least
342 This doesn't solve the issue, since it requires a nonce to start from, and
343 it gets that from `getrandom()`, and thus we have to wait for random pool
345 directly. `arc4random()` is nothing more than optimization, in fact it
348 throughput there's little it gets us over just using `getrandom()`. Also,
349 it's not supported by glibc. And as long as that's the case we are not keen
350 on using it, as we'd have to maintain that on our own, and we don't want to
362 since it neither updates the random seed before using it, nor has any
378 functionality though, and it shouldn't be too hard to implement something
386 Well, consider just switching to `systemd-boot`, it's worth it. See