Hi, Sorry for the delay - Easter holidays + I was trying to arrange my brain around proposed options. Here what I think our options are with regards to the source of randomness:
1) rdtsc or variations based on it (David proposed some CRC-based variants for example) 2) prandom-based options 3) some proper crypto (chacha8 for example seems to be the lightest out of existing options, and probably enough for our purpose, but looks like kernel has only chacha20) 4) rdrand or other HW-based crypto Option 4 was measured to be heavy for the purpose: base: Simple syscall: 0.1774 microseconds random_offset (rdtsc): Simple syscall: 0.1803 microseconds random_offset (rdrand): Simple syscall: 0.3702 microseconds Option 2 (even if we fork our own state(s), do it per-cpu, reseed, etc.) starts to look for me as the least desired. The existing generator's state, as people mentioned before, is trivially solvable given a very little amount of equations (syscalls in our case) you need to issue and offsets to leak. Even if we isolate the state/seed to just this purpose of stack randomization (and don't leak anything about the rest of the system or net prandom usage), it still probably makes the randomization more easily solvable than some constructs based on lower bits of rdtsc. In addition building on top of existing kernel LFSR would add more (probably not useful for any other purpose) code, a possible misconception that it can be used for "real security", etc. So, I would propose to abandon this idea. Option 3 we have to measure I guess, but if it is as heavy as rdrand, then this is also out. In that case, we are only left with rdtsc-based variants. I guess for measuring I will have to use existing chacha20 kernel implementation, never used it before, so will check how to use it/initialize, etc. Any other option I missed? Best Regards, Elena.
