> -----Original Message----- > From: Stephan Mueller <smueller@xxxxxxxxxx> > Am Donnerstag, 2. Januar 2025, 11:33:08 CET schrieb Francesco Valla: > > Hi Francesco, > > > That would be wonderful! Whenever you have the time, please let me know what > > analysis you need. > > > > Ok, some background: the Jitter RNG technically has 2 noise sources which are > sampled concurrently: > > 1. variations of the execution of CPU instructions > > 2. variations of memory access times > > For (1) the Jitter RNG has a fixed set of instructions it performs the > execution time measurements for: the SHA-3 conditioning operation > (specifically the Keccak sponge function). For that, it performs a given set > of Keccak operations. > > For (2) the Jitter RNG allocates a fixed set of memory and simply reads / > writes data there and measures this timing. > > > For (1), the more instructions are samples, the higher the entropy gathered. > This means more time is required to sample that entropy. I.e. when you > increase the number of measured Keccak operations, you get more entropy. > > For (2), when the memory is large enough to "spill over" into the next type of > memory (from L1 to L2 to L3 to RAM), the higher the entropy gathered. > > > So, for (2), to get more entropy, is invariant from the execution time. But > for (1), the entropy rate depends on the execution time. > > > Thus, what you want is to try to reduce the time spend for (1). > > > The key now is that the overall entropy rate the Jitter RNG requires for > functioning must be such that when gathering 256 bits of data from it, it > contains 256 bits of entropy. > > > Now, there are 2 "knobs" to turn via Kconfig: > > - the oversampling rate (OSR): given that the individual number of rounds for > (1) and the number of accesses for (2) are kept the same, the OSR causes the > Jitter RNG to multiply the round counts. For example, the baseline with OSR == > 1 is that for gathering 256 bits of entropy, 256 times both noise sources are > sampled. For an OSR of, say, 3, to get 256 bits of entropy, 3 * 256 = 768 > times both noise sources are sampled. This value was changed from 1 to 3 for > 6.11 because there were reports on some CPUs that the Jitter RNG did not > produce sufficient entropy - most CPUs, however, can perfectly live with OSR > == 1. > > - the amount of memory for (2) can be increased. The default is 2kBytes which > usually means that the L1 can fully handle the accesses. Very interesting. Thanks. > > > ====== > > > Now given the description, what can you do? I would apply the following steps: > > 1. measure whether the timer your system has is really a high-res timer (the > higher the resolution, the higher the detected variations and thus the > entropy) > > 2. assuming that test 1 shows a high res timer, reduce the OSR back to 1 > (CRYPTO_JITTERENTROPY_OSR) and measure the entropy rate - > > 3. if test 2 shows insufficient entropy, increase the amount of memory > (CRYPTO_JITTERENTROPY_MEMSIZE_*) and measure the entropy rate > > > > The tool for measuring the entropy rate is given in [1] - check the README as > you need to enable a kernel config option to get an interface into the Jitter > RNG from user space. As you may not have the analysis tool, you may give the > data to me and I can analyze it. > > > More details on tuning the Jitter RNG is given in [2] - it discusses to the > user space variant, but applies to kernel as well. > > [1] https://github.com/smuellerDD/jitterentropy-library/tree/master/tests/raw-entropy/recording_runtime_kernelspace > > [2] https://github.com/smuellerDD/jitterentropy-library/tree/master/tests/raw-entropy#approach-to-solve-insufficient-entropy First - sorry for the slow response. I'm just getting back from the holidays. And now... Wow! thanks for that detailed response. I will dive into your response a bit deeper, soon, to try to analyze how it may affect our approach. But let me back up a bit and describe our overall approach. I think Francesco answered your query about what we are trying to do here, and what we want from you very well. Let me add a bit of context, and some more thoughts. In general, when trying to improve boot time, we look at 3 general techniques: 1. remove something 2. defer something 3. optimize something Some of the work in optimizing Linux for embedded is finding kernel features that are not needed at all for a particular use case, and just removing them (usually via the kernel config, but sometimes via a command line option). Other times, a feature may be desirable, but the critical capability that must come up quickly (like a camera) does not depend on that item. In that case, we can defer the loading of a feature until after the critical capability is operational and there is no harm done. Finally, some times it may be possible to optimize the initialization of something, so it takes less time (by using pre-calculated values, or optimizing the initialization process). When deferring the initialization of a feature, sometimes it is possible to break it up into parts, such that only the most critical part is initialized first, and the rest of it can be initialized later. In the case of jent_mod_init, I have a few ideas that I'd like to investigate, and your expertise with the driver is very helpful to see which things make sense and which don't. First, I've deferred loading the jitter entropy module, by telling the kernel to defer its initcall (using an out-of-tree patch). That works to eliminate the cost of jent_mod_init during the critical boot phase. Another method might be to just load the jitter entropy module sometime later in the boot sequence. To be honest, this approach, while effective at booting more quickly, makes me nervous because it means that the RNG is not properly seeded (if that's the correct term), until possibly a few seconds after boot. If nothing uses the entropy before then, I don't see a problem. But there may be flows of the entropy data or RNG values data at kernel startup time that I'm not aware of. And I don't want to break security for the kernel by being sloppy. So my first question would be: how bad is it for the RNG if the entropy it not collected until a few seconds after booting? Related to this would be: Do you have an idea which things are using the RNG in early boot that would be affected by a temporary lack of initialization of entropy? Or is it possible to monitor the use of the RNG, to get a report of possibly affected RNG users? Another idea I've had is this - could we save some entropy from a previous boot, to pre-seed the RNG, to avoid having jent_mod_init do it's entropy gathering? My idea would be something like this: check if there's existing entropy from a previous boot, and if so seed the RNG from that (and wipe out the data from the previous boot). If there isn't entropy from a previous boot, work as currently designed to gather the entropy from the measurements for the current boot. I'm working on general mechanisms to transfer data from a previous kernel runtime instantiation to the next, but this particular transfer would involve saving some entropy to some kind of persistent storage on machine shutdown. (Right now I'm looking at using the bootconfig mechanism store the data and re-convey it to a newly booting kernel instance). There are, of course, some security ramifications to this approach as well. Trusting the saved data has its own issues. I would be interested to hear your thoughts on this. How much data would need to be transferred? Would loading the data, parsing it, and injecting it ultimately consume more time than the generation of the data? We are, after all, only talking about ~50ms here. Note that this ability to capture information from one boot, and convey it to a subsequent boot is a feature that I plan to work on independent of this specific scenario. Anyway, I hope that this answers some questions. Thanks for any additional insights you can provide. -- Tim
