normanr commented on code in PR #6154: URL: https://github.com/apache/incubator-nuttx/pull/6154#discussion_r897684812
########## net/tcp/tcp_conn.c: ########## @@ -49,6 +49,7 @@ #include <assert.h> #include <errno.h> #include <debug.h> +#include <sys/random.h> Review Comment: > If your project use random_pool, but not /dev/[u]random, a possible solution is call arc4random_buf in getrandom too. This doesn't make sense, because getrandom can already use random_pool via `/dev/urandom` when `CONFIG_DEV_URANDOM_RANDOM_POOL` is defined. Also @XinStellaris said that `arc4random_buf` didn't work for them. I was saying that it _would_ work if `board_init_rngseed` was implemented and `CONFIG_BOARD_INITRNGSEED` enabled, and that it would be even better if that could happen automatically if `CONFIG_DEV_RANDOM` was defined. Calling `getrandom(..., GRND_RANDOM)` from `up_randompool_initialize` would be a bit weird (because of the same "calling libc functions from the kernel"), but at least `/dev/random` is registered before `/dev/urandom` so it would be possible. > But do we really need the crypto strength random number generator here? No, but it would be nice to have something that "just-works" with minimal configuration. > It could be fixed by try /dev/random and then /dev/urandom. We probably don't need the security of `random` for initial tcp port. I think reading using `urandom` first and falling back to `random` is fine - as long as `urandom` is properly seeded. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
