Am Mittwoch, 20. November 2019, 21:32:32 CET schrieb Greg Kroah-Hartman: Hi Greg, > No, do not abuse sysfs or procfs for something like this. Use a real > syscall please if you really need it. You are right. Ok, let us get back to the drawing board. What are our requirements? We need to have an interface for the TRNG that should ensure other users of entropy are not starved by unprivileged users. What about the following: we use the getrandom(2) system call and add GRND_TRUERANDOM as already indicated. However, there is one more caveat we would add: - if the caller of GRND_TRUERANDOM is !CAP_SYS_ADMIN the entropy pool can only be depleted to the point where at least one or two full seeding operations worth of entropy is left. - if the caller of GRND_TRUERANDOM is CAP_SYS_ADMIN, the entropy can be depleted completely At runtime, the LRNG would then behave like the following: - calling getrandom(..., 0), /dev/random or /dev/urandom would deplete the entropy pool during reseeding operations but leaving an emergency level of 512 bits of entropy in the pool. If equal or less are in the pool, reseeding would be skipped. - calling getrandom(..., GRND_TRUERANDOM) with CAP_SYS_ADMIN allows the entropy pool to be fully depleted. - calling getrandom(..., GRND_TRUERANDOM) without CAP_SYS_ADMIN allows the entropy pool to be depleted down to 1024 bits of entropy. If the pool has equal or less, the caller is blocked. This allows the DRNG feeding /dev/ random, /dev/urandom or getrandom(..., 0) with 512 bits of entropy (i.e. two reseed operations are possible). Only if the entropy pool has more than 1024 bits of entropy, the getrandom call would unblock and provide data. With that approach, I think we can honor the request from Greg to not add any new interface and yet honor the note from Alexander to not allow unprivileged user space to deplete the entropy pool to the extent that other users of entropy are too much affected. If GRND_TRUERANDOM is not implemented, EOPNOTSUPP is returned. Thank you. Ciao Stephan
