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

A way to get the global g state from the initialization of the RNG device. #138

Open
dinosaure opened this issue Sep 2, 2021 · 3 comments

Comments

@dinosaure
Copy link
Member

Currently, with MirageOS, it's not possible to get the g state from the initialization (and be able to pass it to some others computations). It should be very nice for the initialize function to return the g state - and then, get it from the start function of an unikernel instead of an unit value. WDYT? The patch should be small but I think it breaks the API.

@hannesm
Copy link
Member

hannesm commented Sep 2, 2021

I'm not sure I understand what you try to achieve here, sorry. Could you elaborate on the use case you have in mind?

@dinosaure
Copy link
Member Author

So, I have an application (functorized over the Mirage_random.S given by mirage) which expects the g state to be able to generate something random from this state. So I need to pass it from whatever it comes from. In the MirageOS context, due to Mirage_random.S, the type g is completely abstract and I don't have any way to get/create it and use it. It would be nice to have this g state at the start function to pass it then to my application (and ensure a full control of how the application generate random stuffs).

More concretely, a SMTP submission service needs Random.g to generate a stamp needed for the SMTP authentication.

Of course, I can rely on the global state but I lost the ability to fully control the behavior of my application.

@hannesm
Copy link
Member

hannesm commented Sep 2, 2021

hmm, I fail to understand your requirement. do you need to preserve the generator state for later (potentially a restart)?

Indeed, g is abstract and global. it also changes quickly over time (using rdrand/rdseed and lwt enter_hook). if you have the requirement to preserve g and re-generate the exact same random, my best bet would be to generate random data (with Mirage_crypto_rng.generate) and then construct your own generator (e.g. https://github.com/mirleft/ocaml-x509/blob/v0.14.1/lib/private_key.ml#L23-L26). Since g is abstract, you won't be able to dump and restore it.

In other applications (see the X509 code as well) I've just used an optonal g -- would that be an option for you as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants