[GitHub] [incubator-nuttx] juniskane edited a comment on pull request #2488: libs/libc: correct the getrandom(2) prototype

[GitBox <gi...@apache.org>]

juniskane edited a comment on pull request #2488:
URL: https://github.com/apache/incubator-nuttx/pull/2488#issuecomment-740469936


   > But now we support many different transport layer(IPv6, Unix Domain, Bluetooth, CAN) which represent addresss in the different way(sockaddr_in6, sockaddr_un, sockaddr_can). Should we change addr type from `struct sockaddr *` to `void *`? I don't think so.
   
   Nobody is suggesting we should change well entrenched APIs like socket functions. They are also in OpenGroup specs of course. I think simple library wrappers like bzero() are fine as well, as there is widespread existing practise to have such compatibility wrappers, they are trivial to implement, harmless to those who don't need them, and everyone agrees how they work.
   
   > Do you know why @anchao find the wrong getrandom prototype? Because he blindly believe that NuttX implement getrandom as man described and then follow the documentation to write the code, but finally it fail to compile. I think nobody like this experience especially we always emphasize NuttX standard compliance.
   
   It is good it failed to compile. That allows programmer to notice, that maybe something is different for NuttX. Users should not expect that Linux man pages describe NuttX APIs. This is especially important for security code. I have seen at least one TLS implementation that resorts back to using rand() if getrandom() fails. It is very good that that kind of insecure code fails to compile for NuttX!
   
   It is unfortunate the NuttX function is called getrandom(). I originally wanted it to have a distinctive name, but it was changed to getrandom() by other people.
   
   This commit just introduces more confusion to system as it adds things that do not work or are contradicting existing code, like this piece in comments:
   
   `GRND_NONBLOCK  Don't block and return EAGAIN instead`
   
   NuttX getrandom() cannot return EGAIN and it cannot block (for an indefinite time at least, as the semaphore there can not really cause starvation). Comment is incorrect, because it hints that getrandom() blocks by default. On Linux it does, which is just another design failure of the Linux version. Why should we ever block for random numbers, or even have a blocking API, since we already have the ability to generate nearly infinite sequences of them without blocking? 
   
   > getrandom is designed to can be implemented by the hardware crypto accelerator, nobody can make 100% guarantee that the hardware will always work as expect(especially some accelerator connect to CPU through SPI, SDIO, USB bus). Now we have no way to report the error with your prototype?
   
   getrandom() is not designed specifically for hardware crypto accelerators. We use it in real products with MCUs that lack hardware RNG. It only needs enough initial entropy for one cryptographical key (unless generate huge amounts, several Gb, of output, then it must re-key itself) and it can get that from sensors, interrupt timings, factory production line etc.
   
   To better understand these issues, please try this exercise: 1) implement Linux getrandom() using OpenBSD's arc4random_buf() function 2) implement arc4random_buf() using Linux's getrandom(). Part 1) is trivial, but for 2) one has an insurmountable problem, what to do if getrandom() fails (for any reason)?


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org