Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using getrandom() or getentropy() for NetBSD 10.0 #274

Closed
josephlr opened this issue Jul 31, 2022 · 8 comments
Closed

Consider using getrandom() or getentropy() for NetBSD 10.0 #274

josephlr opened this issue Jul 31, 2022 · 8 comments
Labels
waiting on upstream Waiting for upstream changes in an external project

Comments

@josephlr
Copy link
Member

josephlr commented Jul 31, 2022

One of the things pointed out in #273 was that NetBSD 10.0 is set to introduce getrandom() and getentropy() compatibility functions in its libc. Similar to what we already do on DragonFly BSD, FreeBSD, and OpenBSD, we should consider if we want to use one of these functions as our randomness source.

As we still want to support NetBSD 9.2 and lower, we will need to check if this function exists, and only then call it. Otherwise, we should fall back to using the existing implementation. An example of this sort of functionality is our NetBSD implementation.

Note that we will not make any changes to our implementation until the NetBSD 10.0 API has been finalized.

Links

Mailing List discussion
Draft manpage

@alarixnia
Copy link
Contributor

alarixnia commented Jul 31, 2022

Please don't change the status quo at least until NetBSD 10.0 is finalized.

The NetBSD community is still divided over the API contracts we want to provide, and the behavior and availability of getrandom might change at a moment's notice.

@josephlr
Copy link
Member Author

josephlr commented Jul 31, 2022

@alarixnia I would assume if FreeBSD provides a getrandom() function as part of it's libc, it would have the same properties as all the other OSes that have a getrandom() function, namely that with no flags it:

  • returns cryptographically secure random bytes
  • blocks if the kernel rng is not yet initialized

We don't really care about the semantics of the flags as we never use a non-zero flags value (except on Linux).

Am I mistaken about something here?

@josephlr
Copy link
Member Author

josephlr commented Jul 31, 2022

Please don't change the status quo at least until NetBSD 10.0 is finalized.

Rest assured, we would not make this change until the API of 10.0 was finalized. However, it should be noted that OpenSSL already has code using the getrandom() function for NetBSD 10 and up.

EDIT: This was added in openssl/openssl@ef2a44e by @devnexen

@josephlr
Copy link
Member Author

josephlr commented Jul 31, 2022

Also, it seems like the getrandom syscall is already listed on the "Significant changes from NetBSD 9.0 to 10.0" page. However, I do recognize that pre-release software is subject to change.

@alarixnia
Copy link
Contributor

alarixnia commented Jul 31, 2022

blocks if the kernel rng is not yet initialized

The devil is in the details, right? There isn't a way to check if the RNG is initialized from userspace (it will be initialized by the boot loader or init system). There is only a way to check the state of the entropy estimator... which has been removed in 10.0, so simply reports whether an HWRNG is present or not. Which results in the application hanging forever waiting for an estimation that will never arrive on systems without one.

Checking the state of the entropy estimator is something that's only reasonable to do during NetBSD setup, not during regular Rust application usage.

@riastradh
Copy link

The OpenSSL code to call getrandom under NetBSD is unreachable (an earlier #if branch will match, using sysctl kern.arandom) and is unlikely to have ever been tested.

@josephlr josephlr changed the title Use getrandom() libc function on NetBSD Consider using getrandom() or getentropy() for NetBSD 10.0 Aug 1, 2022
@josephlr
Copy link
Member Author

josephlr commented Aug 1, 2022

The OpenSSL code to call getrandom under NetBSD is unreachable (an earlier #if branch will match, using sysctl kern.arandom) and is unlikely to have ever been tested.

Thanks @riastradh, I missed that.

I've also updated this issue to make it clear this is about if we should call one of these methods once NetBSD 10.0 is out, rather than my ealier phrasing which made it sound like we would definitly call getrandom().

@josephlr josephlr added the waiting on upstream Waiting for upstream changes in an external project label Oct 23, 2022
@josephlr
Copy link
Member Author

josephlr commented Feb 9, 2023

Implemented in #331

@josephlr josephlr closed this as completed Feb 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting on upstream Waiting for upstream changes in an external project
Projects
None yet
Development

No branches or pull requests

3 participants