xiaoxiang781216 commented on pull request #5837: URL: https://github.com/apache/incubator-nuttx/pull/5837#issuecomment-1078688420
> why do you replace arc4random_buf with getrandom? One problem is that arc4random_buf couple with the random pool and only exist when CONFIG_DEV_URANDOM_RANDOM_POOL is defined, but this is just one of three software algos: https://github.com/apache/incubator-nuttx/blob/master/drivers/crypto/Kconfig#L30-L73 The more important problem is that if SOC has the true random number generator(DEV_URANDOM_ARCH), the software based random generator drives(drivers/crypto/dev_urandom.c) will be replaced by the hardware implementation, which mean that: 1. arc4random_buf doesn't exist anymore 2. user has to open /dev/[u]random by self > > it seems awkward as one of the purpose of arc4random_buf (renamed from getrandom) was to avoid descrptor shortage and your getrandom is based on device files. It's an implementation detail, we can change it later. It's always better than the current situation(spread /dev/[u]random access in the whole code base) as I highlight before. Why I can't remove fd in this patch directly? This is because the random number generator drivers always register /dev/[u]random directly which mean there isn't no other no-file based approach to access the hardware. So, the block issue is to refine the random number driver interface to remove the depend on file handle directly, the rest work is very easy: 1. Add syscall to expose getrandom to userspace directly 2. Add a char driver to expose /dev/[u]random This PR can simplify the refinement later. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
