[Whonix-devel] How to confirm jitter .ko was loaded
procmem at riseup.net
procmem at riseup.net
Fri Apr 26 18:08:48 CEST 2019
On 4/26/19 1:59 PM, Stephan Mueller wrote:
> Am Mittwoch, 24. April 2019, 20:32:59 CEST schrieb procmem at riseup.net:
>> On 4/24/19 6:21 PM, Stephan Mueller wrote:
>>> Am Mittwoch, 24. April 2019, 19:30:28 CEST schrieb procmem at riseup.net:
>>>> Hi Stephan. Whonix dev here. We are a VM based privacy distro and so are
>>>> very interested in jitter for our RNG needs.
>>>> I was wondering how we can confirm jitterentropy's kernel module was
>>>> successfully loaded during boot so we can be sure it works on some
>>> cat /proc/crypto | grep jitter
>> Thanks for your great input. I'm not going to turn this into a support
>> thread, but I wanted to get to the bottom of this. This command doesn't
>> return anything for me.
> On Fedora 29:
> name : jitterentropy_rng
> driver : jitterentropy_rng
> module : kernel
> priority : 100
> refcnt : 1
> selftest : passed
> internal : no
> type : rng
> seedsize : 0
> Kernel config: CONFIG_CRYPTO_JITTERENTROPY=y
I see. On Debian it is just set to 'm'
I went ahead and reported this upstream so they can get to the bottom of it:
Thanks for the explanation on the kernel DRBG in the other message. I
hope they would just mainline your LRNG code and call it a day instead
of the convoluted implementation they have.
>> We have jitterentropy-rngd installed with a 4.19
>> kernel for Debian Buster. The service reports it's up and running though.
> This is good :-)
> I will check the measurement results now.
>>>> Do you know if it should be functional on the Xen hypervisor where Linux
>>>> does not have full control over bare-metal?
>>> Yes, definitely. Besides, the Jitter RNG will not initialize if it finds
>>> that the platform does not provide the correct properties for the RNG.
>>> The Jitter RNG has also a runtime check. If that runtime check identifies
>>> platform failures, you will see that in dmesg :-)
>> I see. No such errors though.
> If you do not have this listing above, the question is whether it is enabled
> in the kernel :-)
Yeah this is likely the problem I think. 'y' would make it load always
while 'm' means the module is available to be called upon and loaded
when needed but otherwise it is dormant.
More information about the Whonix-devel