[Whonix-devel] How to confirm jitter .ko was loaded

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:
>
> Hi,
>
>> 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,
>>>
>>>> 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
>>>> platforms.
>>> 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:

https://bugs.debian.org/927972
https://bugs.debian.org/927974

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.

OK

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