[devel] rngd vs haveged vs crng

[devel] rngd vs haveged vs crng

[Konstantin Lepikhov]

Привет!

В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
несколько тестов. Идея - замерить как быстро будет заканчиваться энтропия
в случае использования haveged/rngd/ничего (ядра).

В качесте теста был выбран rngtest из пакета rng-tools. rngtest позволяет
проверить качество энтропии из /dev/random по стандарту FIPS 140-2 и
замерить скорость чтения данных.

Кол-во запусков rngtest - 5 (выбрано просто так, чтобы быстрее).
Ядро: 5.0.0-lks-wks-alt0.3

1. запускаем rngtest без всего (rngd/haveged сервисы выключены). В этом
случае ядро будет само наполнять /dev/random.

$ rngtest -c 1000 </dev/random
...
rngtest: input channel speed: (min=1.721; avg=2.008; max=2.143)Mibits/s
rngtest: FIPS tests speed: (min=49.413; avg=60.802; max=151.377)Mibits/s
rngtest: Program run time: 9815390 microseconds

2. Запускаем тесты с rngd:

$ ll /dev/hwrng 
crw------- 1 root root 10, 183 23 apr 11:01 /dev/hwrng

$ egrep "^HRNGD" /etc/sysconfig/rngd
HRNGDEVICE=/dev/hwrng

$ cat /proc/cpuinfo
...
model name      : AMD FX(tm)-6300 Six-Core Processor
...
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes
xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr
tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb vmmcall bmi1
arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
decodeassists pausefilter pfthreshold
bugs            : fxsave_leak sysret_ss_attrs null_seg spectre_v1
spectre_v2 spec_store_bypass

$ rngtest -c 1000 </dev/random
...
rngtest: input channel speed: (min=1.488; avg=5.397; max=18.217)Mibits/s
rngtest: FIPS tests speed: (min=40.324; avg=138.440; max=152.588)Mibits/s
rngtest: Program run time: 3673417 microseconds

run time отличается между тестами +- 0.5s.

3. Запускаем тесты с haveged:

$ service rngd stop && service haveged start
$ rngtest -c 1000 </dev/random
...
rngtest: input channel speed: (min=2.047; avg=17.271; max=21.076)Mibits/s
rngtest: FIPS tests speed: (min=20.465; avg=141.851; max=153.818)Mibits/s
rngtest: Program run time: 1239069 microseconds

run time отличается между тестами +- 0.5s.

Еще более интересные результаты на моем ноуте, который с Intel CPU и TPM:

1. Запускаем без всего, используем только ядро:

for i in $(seq 1 5); do rngtest -c 1000 </dev/random; done
rngtest 6.7
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

rngtest: starting FIPS tests...
^Crngtest: bits received from input: 3720
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: FIPS tests speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: Program run time: 317191113 microseconds
....
(тут я не дождался и прервал тест). Видно, что ядро ничего может
сгенерить за приемлемое время.

2. Запускаем с rngd:

$ ll /dev/hwrng 
crw------- 1 root root 10, 183 23 apr 11:01 /dev/hwrng

$ egrep "^HRNGD" /etc/sysconfig/rngd
HRNGDEVICE=/dev/hwrng

$ cat /proc/cpuinfo
...
model name	: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
...
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64
monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs
ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt
intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp
hwp_notify hwp_act_window hwp_epp flush_l1d
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf

$ dmesg|fgrep tpm
[    9.695064] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)

$ for i in $(seq 1 5); do rngtest -c 1000 </dev/random; done
rngtest 6.7
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

rngtest: starting FIPS tests...
^Crngtest: bits received from input: 4997088
rngtest: FIPS 140-2 successes: 249
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=24.220; avg=31.911; max=51.710)Kibits/s
rngtest: FIPS tests speed: (min=26.128; avg=54.413; max=181.652)Mibits/s
rngtest: Program run time: 152957345 microseconds
(тут я опять прервал тест). Уже получше, но все равно скорость не очень
приемлема для реальных условий.

3. Запускаем с haveged:

$ for i in $(seq 1 5); do rngtest -c 1000 </dev/random; done
...
rngtest 6.7
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.810; avg=20.824; max=23.635)Mibits/s
rngtest: FIPS tests speed: (min=14.983; avg=176.216; max=188.846)Mibits/s
rngtest: Program run time: 1024351 microseconds

среднее отклонение run time +- 10000ms

В общем, выводы можно сделать.

-- 
WBR et al.

Re: [devel] rngd vs haveged vs crng

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

On Thu, 25 Apr 2019 12:29:00 +0200 Konstantin Lepikhov wrote:
> Привет!
> 
> В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
> несколько тестов. Идея - замерить как быстро будет заканчиваться энтропия
> в случае использования haveged/rngd/ничего (ядра).
[...]
> В общем, выводы можно сделать.

Вы перепутали скорость получения данных из обозначенных источников
и энтропию этих данных.

haveged энтропию не добавляет вообще по сравнению с /dev/random, он
её размывает псевдослучайным мусором.

rngd сам по себе ни хорош, ни плох. Он лишь позволяет добавлять
новые аппаратные источники энтропии, вопрос в качестве этих
источников. TPM, hwrng на Intel или AMD не являются доверямыми
источниками (читайте материалы Сноудена), в частности, Шнайер и
Теодор Цо пишут, что rdrandr доверять нельзя:

https://www.schneier.com/blog/archives/2013/09/surreptitiously.html
https://lkml.org/lkml/2017/8/14/1064

Нет ничего плохого в добавлении rdrandr и аналогов в пул энтропии
ядра, плохо, когда его пытаются заменить этими источниками, что
rdrandr в описанных тестах и делает. А havaged даже этого не
делает и тупо размешивает всё псевдослучайными данными.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] rngd vs haveged vs crng

[Denis Medvedev]

On четверг, 25 апреля 2019 г. 22:17:20 MSK Andrey Savchenko wrote:
> On Thu, 25 Apr 2019 12:29:00 +0200 Konstantin Lepikhov wrote:
> 
> > Привет!
> > 
> > В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
> > несколько тестов. Идея - замерить как быстро будет заканчиваться энтропия
> > в случае использования haveged/rngd/ничего (ядра).
> 
> [...]
> 
> > В общем, выводы можно сделать.
> 
> 
> Вы перепутали скорость получения данных из обозначенных источников
> и энтропию этих данных.
> 
> haveged энтропию не добавляет вообще по сравнению с /dev/random, он
> её размывает псевдослучайным мусором.
> 
> rngd сам по себе ни хорош, ни плох. Он лишь позволяет добавлять
> новые аппаратные источники энтропии, вопрос в качестве этих
> источников. TPM, hwrng на Intel или AMD не являются доверямыми
> источниками (читайте материалы Сноудена), в частности, Шнайер и
> Теодор Цо пишут, что rdrandr доверять нельзя:
> 
> https://www.schneier.com/blog/archives/2013/09/surreptitiously.html
> https://lkml.org/lkml/2017/8/14/1064
> 
> Нет ничего плохого в добавлении rdrandr и аналогов в пул энтропии
> ядра, плохо, когда его пытаются заменить этими источниками, что
> rdrandr в описанных тестах и делает. А havaged даже этого не
> делает и тупо размешивает всё псевдослучайными данными.
> 
> Best regards,
> Andrew Savchenko
Кстати, довольно случайным, но полезным явилось
перенесение генерации hostkeys из первого старта системы в ее инсталлер, 
в конец его работы - в это время в системе уже полно энтропии.

Re: [devel] rngd vs haveged vs crng

[Michael Shigorin]

On Thu, Apr 25, 2019 at 10:21:20PM +0300, Denis Medvedev wrote:
> Кстати, довольно случайным, но полезным явилось перенесение
> генерации hostkeys из первого старта системы в ее инсталлер,
> в конец его работы - в это время в системе уже полно энтропии.

Это явно есть смысл утащить в installer (не забыв,
что sshd в целевой системе может и не быть, разумеется).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

25.04.2019 22:26, Michael Shigorin пишет:
> On Thu, Apr 25, 2019 at 10:21:20PM +0300, Denis Medvedev wrote:
>> Кстати, довольно случайным, но полезным явилось перенесение
>> генерации hostkeys из первого старта системы в ее инсталлер,
>> в конец его работы - в это время в системе уже полно энтропии.
> Это явно есть смысл утащить в installer (не забыв,
> что sshd в целевой системе может и не быть, разумеется).

Хотя вот это было написано не так давно:

https://www.altlinux.org/Rescue/Recovery#Привязка_к_новому_"железу"_и_установка_загрузчика

Все ноуты для школ и другие крупные развёртывания делались по той же 
схеме: ssh-keygen -A вызывался в самом конце процедуры. Мы с год назад 
обсуждали, что у нас в стартовых скриптах sshd эта команда запускается 
при первом старте в самом начале, но тогда решили оставить, как есть, 
потому что, если ключей нет, их надо первый раз сгененрировать. 
Пользуясь случаем, решил об этом напомнить -- есть повод для пересмотра 
такого поведения, раз некоторые считают, что на старте этого делать не 
следует.

Однако замечу: по факту ssh-keygen -A берёт из ядра всего 32 байта через 
getrandom() с флагом 0. Делает он это для инициализации собственного 
ГПСЧ seed_rng(), строка #2463. Собран он у нас с libcrypto (OpenSSL). 
Весь выхлоп этой программы -- отнюдь не первородные Теодоровские нули и 
единицы! Да и getrandom() не просто синтаксический сахар, если кто 
забыл. Флаг 0 означает блокируемое чтение из не блокируемого 
/dev/urandom,  для запрошенных 32 байт это не прерываемый и не 
блокируемый вызов. В детали не углублялся, если кто просветит, буду 
признателен! Думаю, если на старте тут и пожирается реальная энтропия, 
то какие-то сущие крохи.

Если мы не хотим вкорячивать rngd/haveged, чтобы не ухудшать 
криптостойкость большинства систем, и одновременно хотим искоренить 
проблему подвисания на раннем старте в отдельных редких случаях 
(сизифная сборка JeOS -- хорошо воспроизводимый пример, хотя может это 
нечто другое), нужно искать потребителей энтропии на раннем старте и 
решать, что с ними делать и возможно ли их вызов немного отложить, 
сделать остальное менее зависимым от них, итп. И вопрос к знатокам: как 
это лучше дебажить? auditd? fanotify?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

26.04.2019 03:01, Leonid Krivoshein пишет:
>
> ... ssh-keygen -A берёт из ядра всего 32 байта через getrandom() с 
> флагом 0... Флаг 0 означает блокируемое чтение из не блокируемого 
> /dev/urandom,  для запрошенных 32 байт это не прерываемый и не 
> блокируемый вызов....
>

Тут забыл одну деталь: чтение из /dev/urandom после исправления CVE 
теперь тоже блокируется, если CPRNG в ядре ещё до конца не инициализирован.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

25.04.2019 22:52, Aleksey Novodvorsky пишет:
>
> чт, 25 апр. 2019 г., 22:26 Michael Shigorin <mike@altlinux.org 
> <mailto:mike@altlinux.org>>:
>
>     On Thu, Apr 25, 2019 at 10:21:20PM +0300, Denis Medvedev wrote:
>     > Кстати, довольно случайным, но полезным явилось перенесение
>     > генерации hostkeys из первого старта системы в ее инсталлер,
>     > в конец его работы - в это время в системе уже полно энтропии.
>
>     Это явно есть смысл утащить в installer (не забыв,
>     что sshd в целевой системе может и не быть, разумеется).
>
> Да.
> Вообще, стоит перетащить в сизиф и p9 все разумное из наших 
> сертифицируемых на конфиденциальность систем.
>

random.trust_cpu как опция в /etc/sysconfig/grub2 доступна для ядер 
4.19-rc3+, равно как и молоток с гвоздями в виде 
CONFIG_RANDOM_TRUST_CPU. Но это разве что для un-def'ов и пока что в 
обратную сторону только.

А кто сомневается, что /dev/random не используется совсем, перед 
генерацией SSH-ключей под strace'ом может удалить этот девайс. :-)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

26.04.2019 3:01, Leonid Krivoshein пишет:
> Если мы не хотим вкорячивать rngd/haveged, чтобы не ухудшать 
> криптостойкость большинства систем, и одновременно хотим искоренить 
> проблему подвисания на раннем старте в отдельных редких случаях 
> (сизифная сборка JeOS -- хорошо воспроизводимый пример, хотя может это 
> нечто другое), нужно искать потребителей энтропии на раннем старте и 
> решать, что с ними делать и возможно ли их вызов немного отложить, 
> сделать остальное менее зависимым от них, итп. И вопрос к знатокам: 
> как это лучше дебажить? auditd? fanotify?

Помимо потребителей энтропии на раннем стадии бывают ещё такие 
устройства, как virtio-rng, без которых на виртуалках совсем грустно.

Откуда там энтропия без клавиатуры и мыши ?

Re: [devel] rngd vs haveged vs crng

[Mikhail Efremov]

On Thu, 25 Apr 2019 22:26:17 +0300 Michael Shigorin wrote:
> On Thu, Apr 25, 2019 at 10:21:20PM +0300, Denis Medvedev wrote:
> > Кстати, довольно случайным, но полезным явилось перенесение
> > генерации hostkeys из первого старта системы в ее инсталлер,
> > в конец его работы - в это время в системе уже полно энтропии.  
> 
> Это явно есть смысл утащить в installer (не забыв,
> что sshd в целевой системе может и не быть, разумеется).
> 

У меня давно коммитв гите. Пока не собираю, может еще что придет в
голову сделать в инсталлере. Но скоро в любом случае отправлю в Сизиф.

-- 
WBR, Mikhail Efremov

Re: [devel] rngd vs haveged vs crng

[Alexey V. Vissarionov]

On 2019-04-25 22:26:17 +0300, Michael Shigorin wrote:

 >> Кстати, довольно случайным, но полезным явилось перенесение
 >> генерации hostkeys из первого старта системы в ее инсталлер,
 >> в конец его работы - в это время в системе уже полно энтропии.
 > Это явно есть смысл утащить в installer (не забыв, что sshd в
 > целевой системе может и не быть, разумеется).

Это никоим образом не отменяет того, что после установки следует
запустить ssh-keygen -A || true

Ну и систему без sshd себе еще представить надо... Лично я такое
себе представляю с трудом, ибо непонятно, как ее администрировать.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Denis Medvedev]

On суббота, 27 апреля 2019 г. 01:46:18 MSK Alexey V. Vissarionov wrote:
> On 2019-04-25 22:26:17 +0300, Michael Shigorin wrote:
>  >> Кстати, довольно случайным, но полезным явилось перенесение
>  >> генерации hostkeys из первого старта системы в ее инсталлер,
>  >> в конец его работы - в это время в системе уже полно энтропии.
>  > 
>  > Это явно есть смысл утащить в installer (не забыв, что sshd в
>  > целевой системе может и не быть, разумеется).
> 
> Это никоим образом не отменяет того, что после установки следует
> запустить ssh-keygen -A || true
Вы не доверяете только что запускавшемуся вами же установщику?
(если он запускался не вами и, главное, не только для этой системы, то 
запускать стоит).
> 
> Ну и систему без sshd себе еще представить надо... Лично я такое
> себе представляю с трудом, ибо непонятно, как ее администрировать.
C консоли?

Re: [devel] rngd vs haveged vs crng

[Ivan A. Melnikov]

On Sat, Apr 27, 2019 at 07:17:38AM +0300, Denis Medvedev wrote:
> On суббота, 27 апреля 2019 г. 01:46:18 MSK Alexey V. Vissarionov wrote:
> > On 2019-04-25 22:26:17 +0300, Michael Shigorin wrote:
> >  >> Кстати, довольно случайным, но полезным явилось перенесение
> >  >> генерации hostkeys из первого старта системы в ее инсталлер,
> >  >> в конец его работы - в это время в системе уже полно энтропии.
> >  > 
> >  > Это явно есть смысл утащить в installer (не забыв, что sshd в
> >  > целевой системе может и не быть, разумеется).
> > 
> > Это никоим образом не отменяет того, что после установки следует
> > запустить ssh-keygen -A || true
> Вы не доверяете только что запускавшемуся вами же установщику?
> (если он запускался не вами и, главное, не только для этой системы, то 
> запускать стоит).

На всякий случай напомню, что у нас больше одного установщика. Например,
системы на arm и mipsel чаще всего устанавливаются из тарболов rootfs.

--
  wbr,
    iv m.

Re: [devel] rngd vs haveged vs crng

[Alexey Shabalin]

чт, 25 апр. 2019 г. в 13:29, Konstantin Lepikhov <lakostis@altlinux.org>:
>
> Привет!
>
> В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
> несколько тестов. Идея - замерить как быстро будет заканчиваться энтропия
> в случае использования haveged/rngd/ничего (ядра).

В копилку дополнительных решений. Случайно наткнулся на специальный
клиент-сервер :)
pollen - сервер (https://github.com/dustinkirkland/pollen) - на golang
pollinate - клиент (https://github.com/dustinkirkland/pollinate) - простой sh
Делали для Ubuntu, и Ubuntu предоставляет сервис Entropy-as-a-Service
https://entropy.ubuntu.com
Никто не запрещает его поднять внутри своей сети.
И cloud-init (виртуалки в облачных окружениях) умеeт использовать клиента.

-- 
Alexey Shabalin

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

23.05.2019 2:08, Alexey Shabalin пишет:
> чт, 25 апр. 2019 г. в 13:29, Konstantin Lepikhov <lakostis@altlinux.org>:
>> Привет!
>>
>> В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
>> несколько тестов. Идея - замерить как быстро будет заканчиваться энтропия
>> в случае использования haveged/rngd/ничего (ядра).
> В копилку дополнительных решений. Случайно наткнулся на специальный
> клиент-сервер :)
> pollen - сервер (https://github.com/dustinkirkland/pollen) - на golang
> pollinate - клиент (https://github.com/dustinkirkland/pollinate) - простой sh
> Делали для Ubuntu, и Ubuntu предоставляет сервис Entropy-as-a-Service
> https://entropy.ubuntu.com
> Никто не запрещает его поднять внутри своей сети.
> И cloud-init (виртуалки в облачных окружениях) умеeт использовать клиента.
>
Не факт, что когда нет сети - есть энтропия. Наверное, это интереснее на 
хост-систему пробрасывать, а уже оттуда в виртуалку через virtio-rng

Re: [devel] rngd vs haveged vs crng

[Michael Shigorin]

On Thu, May 23, 2019 at 02:08:28AM +0300, Alexey Shabalin wrote:
> В копилку дополнительных решений. Случайно наткнулся на
> специальный клиент-сервер :)

То есть сперва создать проблему на ровном месте,
затем героически её решать.

Лёш, чинить journald апстрим часом не собирается?
Например, на предмет ручки "не подписывать логи",
"подписывать, если есть энтропия", "подписывать всегда"?

По умолчанию в "обычных" выпусках, как мне кажется,
работоспособность системы в течение разумного времени
после включения/перезагрузки важнее, чем подписи,
которые не проверит/посмотрит никто.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

27.05.2019 14:59, Michael Shigorin пишет:
> On Thu, May 23, 2019 at 02:08:28AM +0300, Alexey Shabalin wrote:
>> В копилку дополнительных решений. Случайно наткнулся на
>> специальный клиент-сервер :)
> То есть сперва создать проблему на ровном месте,
> затем героически её решать.
>
> Лёш, чинить journald апстрим часом не собирается?
> Например, на предмет ручки "не подписывать логи",
> "подписывать, если есть энтропия", "подписывать всегда"?
>
> По умолчанию в "обычных" выпусках, как мне кажется,
> работоспособность системы в течение разумного времени
> после включения/перезагрузки важнее, чем подписи,
> которые не проверит/посмотрит никто.
>
При чём тут journald ?


Энтропии может не быть для каких-то других задач.

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

27.05.2019 14:59, Michael Shigorin пишет:
> On Thu, May 23, 2019 at 02:08:28AM +0300, Alexey Shabalin wrote:
>> В копилку дополнительных решений. Случайно наткнулся на
>> специальный клиент-сервер :)
> То есть сперва создать проблему на ровном месте,
> затем героически её решать.

Справедливости ради: специально её не создавали, так уж сложилось. Рынок 
жаждет быстрых компьютеров, быстрых SSD. Overal Perfomance Index 
определяется отнюдь не скоростью загрузки и временем отклика на данную 
команду, но обыватель не любит ждать и ему важнее эти два "субъективных" 
показателя, конечно, непосредственно о распараллеливании загрузки никто 
особо не думает. Однако init-системы начали вырастать одна за другой в 
угоду этим хотелкам рынка, systemd -- не первая, и наверняка не 
последняя. Скорее всего, ещё и не самая плохая реализация параллельной 
загрузки. Самой удачной она могла бы стать, если бы не ломала 
надёжности, не создавала бы гонок на ровном месте, позволяла бы работать 
с разными профилями надёжности и совместимости. Для бывалых никакого 
значения не имеет скорость загрузки, надёжность важнее.

Но ведь даже не systemd стал проблемой. Не было бы его, здесь был бы 
upstart или любой другой имярек. Просто, с одной стороны, компьютеры и 
диски стали быстрее, система загрузки стала слишком непоследовательной, 
с другой -- апстрим ядра закрутил гайки с CPRNG. И проблема вылазит 
точечно, даже виртуалок это больше касается. Потому что и там прогресс, 
и там тоже закрутили.


> Лёш, чинить journald апстрим часом не собирается?
> Например, на предмет ручки "не подписывать логи",
> "подписывать, если есть энтропия", "подписывать всегда"?

Выходит, в первую очередь именно мы должны думать, как компоновать 
системы, чтобы не было потребителей энтропии на раннем старте. 
Персонально отлавливать и отстреливать. Хороший пример с ssh-keygen -A.


> По умолчанию в "обычных" выпусках, как мне кажется,
> работоспособность системы в течение разумного времени
> после включения/перезагрузки важнее, чем подписи,
> которые не проверит/посмотрит никто.

Все варианты решения уже известны и обсуждались много раз. Можно ещё 
один вариант рассмотреть. Допустим, мы уже точно знаем, какие приложения 
сколько выжрут энтропии. Будучи запущенными в первые несколько секунд, 
это создаст проблему. Оценить текущий пул через sysfs мы можем, время от 
начала запуска известен. Для таких программ создаются фэйки-обёртки, 
выполняющие их отложенный запуск. А systemd пусть думает, что всё уже 
случилось. Если для ряда таких программ заблокировать запуск полностью 
возможно без ущерба для загрузки, значит, сразу после логина юзера с uid 
500 чтобы вылазило системное предупреждение, типа: внесите такие-то 
изменения в свои настройки или мы и дальше будем блокировать запуск 
таких-то приложений. Для таких программ, как gnome-keyring, если 
создавать временное хранилище на основе ненадёжных данных -- тоже сразу 
чтобы прилетало уведомление юзеру, но запуск не блокировался. На худой 
конец, не создавать это временное хранилище. Короче, отстреливать 
индивидуально или как-то так.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

27.05.2019 17:18, Anton Farygin пишет:
> 27.05.2019 14:59, Michael Shigorin пишет:
>> On Thu, May 23, 2019 at 02:08:28AM +0300, Alexey Shabalin wrote:
>>> В копилку дополнительных решений. Случайно наткнулся на
>>> специальный клиент-сервер :)
>> То есть сперва создать проблему на ровном месте,
>> затем героически её решать.
>>
>> Лёш, чинить journald апстрим часом не собирается?
>> Например, на предмет ручки "не подписывать логи",
>> "подписывать, если есть энтропия", "подписывать всегда"?
>>
>> По умолчанию в "обычных" выпусках, как мне кажется,
>> работоспособность системы в течение разумного времени
>> после включения/перезагрузки важнее, чем подписи,
>> которые не проверит/посмотрит никто.
>>
> При чём тут journald ?
>

По несчастью он оказывается первым её пожирателем. Но если хватит ему, 
значит может не хватить следующему. Журнал минуту можно в оперативку 
сливать на машинах с очень большим ОЗУ -- они быстрые и их эта проблема 
больше касается. А когда минута истечёт или появится лишняя энтропия, 
фейковая обёртка может запустить настоящий journald, передав все 
накопленные данные ему.

>
> Энтропии может не быть для каких-то других задач.
>

Обратил внимание: нормальные виртуалки, пролежавшие год без дела, при 
запуске в новом окружении тоже стали "застревать". И на Сизифе, и на p8. 
Раньше за ними такого не замечалось. Что говорит о закручивании гаек с 
совершенно другой стороны.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

23.05.2019 02:08, Alexey Shabalin пишет:
> чт, 25 апр. 2019 г. в 13:29, Konstantin Lepikhov <lakostis@altlinux.org>:
>> Привет!
>>
>> В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
>> несколько тестов. Идея - замерить как быстро будет заканчиваться энтропия
>> в случае использования haveged/rngd/ничего (ядра).
> В копилку дополнительных решений.

https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

Поглядим по сторонам. :) Разные интересные решения в одном месте. И про 
jitterentropy_rng, и особенно заманчиво приглянулось убивать самим 
systemd застрявшие процессы через coredump.


> Случайно наткнулся на специальный
> клиент-сервер :)
> pollen - сервер (https://github.com/dustinkirkland/pollen) - на golang
> pollinate - клиент (https://github.com/dustinkirkland/pollinate) - простой sh
> Делали для Ubuntu, и Ubuntu предоставляет сервис Entropy-as-a-Service
> https://entropy.ubuntu.com
> Никто не запрещает его поднять внутри своей сети.
> И cloud-init (виртуалки в облачных окружениях) умеeт использовать клиента.

-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

28.05.2019 2:53, Leonid Krivoshein пишет:
>> Лёш, чинить journald апстрим часом не собирается?
>> Например, на предмет ручки "не подписывать логи",
>> "подписывать, если есть энтропия", "подписывать всегда"?
>
> Выходит, в первую очередь именно мы должны думать, как компоновать 
> системы, чтобы не было потребителей энтропии на раннем старте. 
> Персонально отлавливать и отстреливать. Хороший пример с ssh-keygen -A. 

Отстреливание застрявших по причине отсутствия энтропии процессов - это 
тоже один из вариантов приведения системы в негодность.

Процесс, отстреливающий процессы, знать не может о том, важную ли он 
задачу убивает или нет.

Тот же logger, например, лучше не убивать - мало ли чего важного он 
пропустит с момента загрузки системы.

Re: [devel] rngd vs haveged vs crng

[Alexey V. Vissarionov]

On 2019-05-28 02:53:12 +0300, Leonid Krivoshein wrote:

 >>> В копилку дополнительных решений. Случайно наткнулся на
 >>> специальный клиент-сервер :)
 >> То есть сперва создать проблему на ровном месте,
 >> затем героически её решать.
 > Справедливости ради: специально её не создавали, так уж
 > сложилось.

Именно создали.

 > Рынок жаждет быстрых компьютеров, быстрых SSD.

И они появились.

 > Overal Perfomance Index определяется отнюдь не скоростью
 > загрузки и временем отклика на данную команду, но обыватель
 > не любит ждать и ему важнее эти два "субъективных" показателя,

Обывателям вообще начхать на любые показатели - им нужны котики.

 > конечно, непосредственно о распараллеливании загрузки никто
 > особо не думает.

Разумеется: основная задача - обеспечить запуск демонов в нужной
последовательности с учетом их взаимных зависимостей (httpd надо
запустить после postgresql, но до nginx, так как CMS сайтов нужен
доступ к БД, а FE требует работающего BE), а распараллеливание
загрузки - не более, чем приятный побочный эффект.

 > Однако init-системы начали вырастать одна за другой в угоду
 > этим хотелкам рынка, systemd -- не первая, и наверняка не
 > последняя. Скорее всего, ещё и не самая плохая реализация

На данный момент - самая.

 > параллельной загрузки.

Еще раз: не параллельной загрузки, а запуска демонов с учетом их
взаимных зависимостей.

 > Самой удачной она могла бы стать, если бы не ломала надёжности,

Собственно, этой причины уже достаточно для того, чтобы избегать
этого поделия в промышленных системах.

 > не создавала бы гонок на ровном месте,

Для этого и нужны взаимные зависимости. И, кстати, их можно легко
реализовать даже на основе SysVinit - для этого достаточно сделать
обязательным `service $name status` с унифицированным выводом
("unknown", "disabled", "stopped", "failed", "running").

 > позволяла бы работать с разными профилями надёжности

Эээээто как? Отключать глюкодром там, где надо сделать хорошо? :-)

 > и совместимости.

С чем?

 > Для бывалых никакого значения не имеет скорость загрузки,
 > надёжность важнее.

А для остальных - "пипл хавает"?

 > Но ведь даже не systemd стал проблемой.

Именно он и стал. Из-за головожопости разработчиков, у которых
фантазия улетела в дальние дали и окончательно оторвалась от
реальности - именно это мы наблюдаем в ситуации, когда во имя
скорости загрузки эти (выражусь дипломатично) дебилы жертвуют
надежностью и безопасностью.

 > Не было бы его, здесь был бы upstart или любой другой имярек.

Что любопытно, в upstart это настолько явно не проявляется.

 > Просто, с одной стороны, компьютеры и диски стали быстрее,

Да. Нужно успевать.

 > система загрузки стала слишком непоследовательной,

И что? Пока не прочитали из /proc/sys/kernel/random/poolsize
число 4096 (что означает полностью заполненный пул энтропии) -
просто не запускаем ничего. По буквам: Николай, Иван, Харитон,
Ульяна, Яков. Повторяю: ничего.

А, ну да... это же замедлит загрузку, и пользователю придется
(о ужас!) подождать несколько секунд...

 > с другой -- апстрим ядра закрутил гайки с CPRNG.

Да ничего они там особо не крутили... немного поменяли логику
работы и вместо SHA2 теперь используют игрушечный poly1305.

 > И проблема вылазит точечно, даже виртуалок это больше
 > касается. Потому что и там прогресс, и там тоже закрутили.

А нефиг их на горячуу клонировать...

 > Выходит, в первую очередь именно мы должны думать, как
 > компоновать системы, чтобы не было потребителей энтропии
 > на раннем старте. Персонально отлавливать и отстреливать.
 > Хороший пример с ssh-keygen -A.

Хороший. А теперь подумай, как ты от него избавишься... ну,
например, в эталонном образе виртуалки.

Или будешь плодить кучу хостов с одинаковыми ключами? :-)

 >> По умолчанию в "обычных" выпусках, как мне кажется,
 >> работоспособность системы в течение разумного времени
 >> после включения/перезагрузки важнее, чем подписи,
 >> которые не проверит/посмотрит никто.
 > Все варианты решения уже известны и обсуждались много раз.
 > Можно ещё один вариант рассмотреть. Допустим, мы уже точно
 > знаем, какие приложения сколько выжрут энтропии.

Откуда и как мы это можем узнать точно?

 > Будучи запущенными в первые несколько секунд, это создаст
 > проблему. Оценить текущий пул через sysfs мы можем, время
 > от начала запуска известен. Для таких программ создаются
 > фэйки-обёртки, выполняющие их отложенный запуск. А systemd
 > пусть думает, что всё уже случилось.

Это даже не просто костыль - это специально сломать ногу, а
потом компенсировать это костылем.

 > Если для ряда таких программ заблокировать запуск полностью
 > возможно без ущерба для загрузки, значит, сразу после логина
 > юзера с uid 500

А почему не 512? :-)

 > чтобы вылазило системное предупреждение, типа: внесите
 > такие-то изменения в свои настройки или мы и дальше будем
 > блокировать запуск таких-то приложений.

И усер такой: http://pics.rsh.ru/img/sova_pwivfaew.jpg

 > Для таких программ, как gnome-keyring, если создавать
 > временное хранилище на основе ненадёжных данных

... то лучше вообще не создавать такое хранилище.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

28.05.2019 11:57, Alexey V. Vissarionov пишет:
> А, ну да... это же замедлит загрузку, и пользователю придется
> (о ужас!) подождать несколько секунд...

Почему же секунд ?

в случае с виртуализацией энтропии не появится вообще никогда.

Re: [devel] rngd vs haveged vs crng

[Anton Gorlov]

28.05.2019 13:51, Anton Farygin пишет:
> 
> Почему же секунд ?
> 
> в случае с виртуализацией энтропии не появится вообще никогда.


На 1 сервере,где по некоторым причинам стоит деб..когда там включили 
жёсткую энтропию... после загрузки  сервера и поднятия сети до поднятия 
ssh уходило... минут 10-15.. и это на HP-сервере в bare metal

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087

Re: [devel] rngd vs haveged vs crng

[Anton Gorlov]

28.05.2019 13:51, Anton Farygin пишет:
> 
> Почему же секунд ?
> 
> в случае с виртуализацией энтропии не появится вообще никогда.


На 1 сервере,где по некоторым причинам стоит деб..когда там включили 
жёсткую энтропию... после загрузки  сервера и поднятия сети до поднятия 
ssh уходило... минут 10-15.. и это на HP-сервере в bare metal

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

29.05.2019 11:46, Anton Gorlov пишет:
> 28.05.2019 13:51, Anton Farygin пишет:
>>
>> Почему же секунд ?
>>
>> в случае с виртуализацией энтропии не появится вообще никогда.
>
>
> На 1 сервере,где по некоторым причинам стоит деб..когда там включили 
> жёсткую энтропию... после загрузки  сервера и поднятия сети до 
> поднятия ssh уходило... минут 10-15.. и это на HP-сервере в bare metal
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087 

virtio-rng работает и помогает передать энтропию с хоста в гостя, но её 
нужно у virtio-rng забирать с помощью rngd и наполнять пул ядра

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Vitaly Chikunov]

On Wed, May 29, 2019 at 01:52:42PM +0300, Anton Farygin wrote:
> virtio-rng работает и помогает передать энтропию с хоста в гостя, но её
> нужно у virtio-rng забирать с помощью rngd и наполнять пул ядра

Не нужно с linux 3.17 (2014 г.)

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be4000bc464
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34679ec7a0c

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

30.05.2019 4:11, Vitaly Chikunov пишет:
> On Wed, May 29, 2019 at 01:52:42PM +0300, Anton Farygin wrote:
>> virtio-rng работает и помогает передать энтропию с хоста в гостя, но её
>> нужно у virtio-rng забирать с помощью rngd и наполнять пул ядра
> Не нужно с linux 3.17 (2014 г.)
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be4000bc464
>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34679ec7a0c
>
>
Теперь осталось понять, почему это не заработало у меня на виртуалке.

Посмотрю, спасибо.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

30.05.2019 7:39, Anton Farygin пишет:
> 30.05.2019 4:11, Vitaly Chikunov пишет:
>> On Wed, May 29, 2019 at 01:52:42PM +0300, Anton Farygin wrote:
>>> virtio-rng работает и помогает передать энтропию с хоста в гостя, но её
>>> нужно у virtio-rng забирать с помощью rngd и наполнять пул ядра
>> Не нужно с linux 3.17 (2014 г.)
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be4000bc464
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34679ec7a0c
>>
>>
> Теперь осталось понять, почему это не заработало у меня на виртуалке.
>
> Посмотрю, спасибо.

Всё, на виртуалке похоже заработало, хотя поток случайностей заметно 
хуже хоста. - /dev/random отдаёт порядка 14 килобайт в секунду. А без 
virtio-rng этот поток равен нулю (я не дождался появления никаких цифр).

rngd на виртуальной машине действительно не увеличивает энтропию, если 
не использовать в качестве источника JITTER Entropy generator

Кстати, из двух зол - какое выбрать - Intel RDRAND или TPM ?

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-05-30 08:16:25 +0300, Anton Farygin wrote:

 > Кстати, из двух зол - какое выбрать - Intel RDRAND или TPM ?

Оба одновременно: при наличии в системе хотя бы одного доверенного
источника энтропии они не смогут нагадить даже при всем желании(*),
ибо ложка стохастического говна превращает бочку детерминированного
меда в бочку стохастического говна :-)

Зачем отказались от SHA2 в пользу poly1305 мне немного неочевидно,
но для подмешивания данных в пул энтропии в принципе годится любая
хеш-функция с достаточной длиной слова состояния.

И таки да, мой выбор - аппаратный генератор. Теперь на управляемых
стабилитронах TL431 (в китайпосылторге 20 рублей за 10 штук) и LM339
(счетверенный компаратор, 26 рублей за 10 штук):
https://www.aliexpress.com/item/TL431/32835691100.html
https://www.aliexpress.com/item/LM339/33021332665.html


(*) за исключением совсем очевидной ситуации с неграмотно собранным
ядром, когда систему теоретически можно несколько секунд удерживать
в полностью детерминированном состоянии (надо будет проверить).

-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

30.05.2019 19:40, Alexey V. Vissarionov пишет:
> On 2019-05-30 08:16:25 +0300, Anton Farygin wrote:
>
>   > Кстати, из двух зол - какое выбрать - Intel RDRAND или TPM ?
>
> Оба одновременно: при наличии в системе хотя бы одного доверенного
> источника энтропии они не смогут нагадить даже при всем желании(*),
> ибо ложка стохастического говна превращает бочку детерминированного
> меда в бочку стохастического говна :-)
>
> Зачем отказались от SHA2 в пользу poly1305 мне немного неочевидно,
> но для подмешивания данных в пул энтропии в принципе годится любая
> хеш-функция с достаточной длиной слова состояния.
>
> И таки да, мой выбор - аппаратный генератор. Теперь на управляемых
> стабилитронах TL431 (в китайпосылторге 20 рублей за 10 штук) и LM339
> (счетверенный компаратор, 26 рублей за 10 штук):
> https://www.aliexpress.com/item/TL431/32835691100.html
> https://www.aliexpress.com/item/LM339/33021332665.html
А вот такие генераторы в виде, в котором их допустят к установке в 
серьёзных местах - существуют ли и сколько стоят ?

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-05-30 19:51:51 +0300, Anton Farygin wrote:

 >>> из двух зол - какое выбрать - Intel RDRAND или TPM ?
 >> Оба одновременно: при наличии в системе хотя бы одного
 >> доверенного источника энтропии они не смогут нагадить
 >> даже при всем желании
 >> И таки да, мой выбор - аппаратный генератор. Теперь на
 >> управляемых стабилитронах TL431
 > А вот такие генераторы в виде, в котором их допустят к
 > установке в серьёзных местах - существуют ли и сколько
 > стоят ?

В серьезных местах проведут аудит схемы (благо, она простая,
как валенок) и ПО контроллера (которое в основном состоит из
общеизвестной открытой библиотеки для работы по USB), погоняют
опытный образец на тестах - да и составят протокол испытаний,
согласно которому данное изделие будет рекомендовано для.

Но для этого нужно показать им опытный образец, и здесь весьма
желательно, чтобы он выглядел как готовое изделие, а не колхоз
на базе https://www.aliexpress.com/item/STM32/32656048071.html
(как у меня сейчас).

Что любопытно, оригинальный https://altusmetrum.org/ChaosKey/
(мои поделки прикидываются именно им, так как для него есть
готовый ядерный модуль) вряд ли пройдет проверку - зарубят на
аналоговой части.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Alexey V. Vissarionov]

On 2019-05-28 13:51:12 +0300, Anton Farygin wrote:
 >> А, ну да... это же замедлит загрузку, и пользователю придется
 >> (о ужас!) подождать несколько секунд...
 > Почему же секунд ?
 > в случае с виртуализацией энтропии не появится вообще никогда.

Антоша, таки уже откройте для себя CONFIG_HW_RANDOM_VIRTIO :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

30.05.2019 20:54, Alexey V. Vissarionov пишет:
> On 2019-05-28 13:51:12 +0300, Anton Farygin wrote:
>   >> А, ну да... это же замедлит загрузку, и пользователю придется
>   >> (о ужас!) подождать несколько секунд...
>   > Почему же секунд ?
>   > в случае с виртуализацией энтропии не появится вообще никогда.
>
> Антоша, таки уже откройте для себя CONFIG_HW_RANDOM_VIRTIO :-)
>
>
Проснулся. Он у нас по умолчанию enabled в ядрах.

Без настройки виртуалки со стороны хоста - это не работает.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

30.05.2019 19:40, Alexey V. Vissarionov пишет:
> On 2019-05-30 08:16:25 +0300, Anton Farygin wrote:
>
>   > Кстати, из двух зол - какое выбрать - Intel RDRAND или TPM ?
>
> Оба одновременно: при наличии в системе хотя бы одного доверенного
> источника энтропии они не смогут нагадить даже при всем желании(*),
> ибо ложка стохастического говна превращает бочку детерминированного
> меда в бочку стохастического говна:-)

ну собственно rngd так и делает - замешивает все существующие источники 
энтропии в один.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

On Thu, 30 May 2019 19:51:51 +0300 Anton Farygin wrote:
> 30.05.2019 19:40, Alexey V. Vissarionov пишет:
> > On 2019-05-30 08:16:25 +0300, Anton Farygin wrote:
> >
> >   > Кстати, из двух зол - какое выбрать - Intel RDRAND или TPM ?
> >
> > Оба одновременно: при наличии в системе хотя бы одного доверенного
> > источника энтропии они не смогут нагадить даже при всем желании(*),
> > ибо ложка стохастического говна превращает бочку детерминированного
> > меда в бочку стохастического говна :-)
> >
> > Зачем отказались от SHA2 в пользу poly1305 мне немного неочевидно,
> > но для подмешивания данных в пул энтропии в принципе годится любая
> > хеш-функция с достаточной длиной слова состояния.
> >
> > И таки да, мой выбор - аппаратный генератор. Теперь на управляемых
> > стабилитронах TL431 (в китайпосылторге 20 рублей за 10 штук) и LM339
> > (счетверенный компаратор, 26 рублей за 10 штук):
> > https://www.aliexpress.com/item/TL431/32835691100.html
> > https://www.aliexpress.com/item/LM339/33021332665.html
> А вот такие генераторы в виде, в котором их допустят к установке в 
> серьёзных местах - существуют ли и сколько стоят ?

Существуют. Тот же nitrokey даёт 40 kbit/s TRNG, схемотехника
и прошивка полностью открыты. Стоит 49€.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-05-31 09:50:09 +0300, Anton Farygin wrote:

 >>> из двух зол - какое выбрать - Intel RDRAND или TPM ?
 >> Оба одновременно: при наличии в системе хотя бы одного
 >> доверенного источника энтропии они не смогут нагадить
 >> даже при всем желании(*), ибо ложка стохастического
 >> говна превращает бочку детерминированного меда в бочку
 >> стохастического говна:-)
 > ну собственно rngd так и делает - замешивает все существующие
 > источники энтропии в один.

Энтропия нужна _до_ запуска init.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Alexey V. Vissarionov]

On 2019-05-31 08:08:50 +0300, Anton Farygin wrote:

 >>>> А, ну да... это же замедлит загрузку, и пользователю
 >>>> придется (о ужас!) подождать несколько секунд...
 >>> Почему же секунд ? в случае с виртуализацией энтропии
 >>> не появится вообще никогда.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^
 >> Антоша, таки уже откройте для себя CONFIG_HW_RANDOM_VIRTIO :-)
 > Проснулся.

Доброе утро!

 > Он у нас по умолчанию enabled в ядрах.
 > Без настройки виртуалки со стороны хоста - это не работает.

То есть, подчеркнутое - исключительно головожопость админов. QED.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Anton Gorlov]

Там BARE METAL....

29.05.2019 13:52, Anton Farygin пишет:
> 29.05.2019 11:46, Anton Gorlov пишет:
>> 28.05.2019 13:51, Anton Farygin пишет:
>>>
>>> Почему же секунд ?
>>>
>>> в случае с виртуализацией энтропии не появится вообще никогда.
>>
>>
>> На 1 сервере,где по некоторым причинам стоит деб..когда там включили
>> жёсткую энтропию... после загрузки  сервера и поднятия сети до
>> поднятия ssh уходило... минут 10-15.. и это на HP-сервере в bare metal
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087 
>
> virtio-rng работает и помогает передать энтропию с хоста в гостя, но
> её нужно у virtio-rng забирать с помощью rngd и наполнять пул ядра
>
>
>

Re: [devel] rngd vs haveged vs crng

[Anton Gorlov]

Там BARE METAL....

29.05.2019 13:52, Anton Farygin пишет:
> 29.05.2019 11:46, Anton Gorlov пишет:
>> 28.05.2019 13:51, Anton Farygin пишет:
>>>
>>> Почему же секунд ?
>>>
>>> в случае с виртуализацией энтропии не появится вообще никогда.
>>
>>
>> На 1 сервере,где по некоторым причинам стоит деб..когда там включили
>> жёсткую энтропию... после загрузки  сервера и поднятия сети до
>> поднятия ssh уходило... минут 10-15.. и это на HP-сервере в bare metal
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087 
>
> virtio-rng работает и помогает передать энтропию с хоста в гостя, но
> её нужно у virtio-rng забирать с помощью rngd и наполнять пул ядра
>
>
>

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

31.05.2019 13:56, Alexey V. Vissarionov пишет:
> On 2019-05-31 09:50:09 +0300, Anton Farygin wrote:
>
>   >>> из двух зол - какое выбрать - Intel RDRAND или TPM ?
>   >> Оба одновременно: при наличии в системе хотя бы одного
>   >> доверенного источника энтропии они не смогут нагадить
>   >> даже при всем желании(*), ибо ложка стохастического
>   >> говна превращает бочку детерминированного меда в бочку
>   >> стохастического говна:-)
>   > ну собственно rngd так и делает - замешивает все существующие
>   > источники энтропии в один.
>
> Энтропия нужна_до_  запуска init.

А зачем она тебе до запуска init ?

Re: [devel] rngd vs haveged vs crng

[Anton Farygin]

31.05.2019 14:01, Alexey V. Vissarionov пишет:
> То есть, подчеркнутое - исключительно головожопость админов. QED.

Не совсем. Я не знаю ни одну облачную среду, которая настраивает 
virtio-rng по умолчанию.

Надо Лёшу Шабалина попросить проверить и добавить дефолт туда, где нету.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey Shabalin]

пт, 31 мая 2019 г. в 19:58, Anton Farygin <rider@basealt.ru>:
>
> 31.05.2019 13:56, Alexey V. Vissarionov пишет:
> > On 2019-05-31 09:50:09 +0300, Anton Farygin wrote:
> >
> >   >>> из двух зол - какое выбрать - Intel RDRAND или TPM ?
> >   >> Оба одновременно: при наличии в системе хотя бы одного
> >   >> доверенного источника энтропии они не смогут нагадить
> >   >> даже при всем желании(*), ибо ложка стохастического
> >   >> говна превращает бочку детерминированного меда в бочку
> >   >> стохастического говна:-)
> >   > ну собственно rngd так и делает - замешивает все существующие
> >   > источники энтропии в один.
> >
> > Энтропия нужна_до_  запуска init.
>
> А зачем она тебе до запуска init ?

Для информации, от разработчиков systemd.
https://systemd.io/RANDOM_SEEDS

-- 
Alexey Shabalin

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

31.08.2019 02:06, Alexey Shabalin пишет:
> пт, 31 мая 2019 г. в 19:58, Anton Farygin <rider@basealt.ru>:
>> [...]
>> А зачем она тебе до запуска init ?
> Для информации, от разработчиков systemd.
> https://systemd.io/RANDOM_SEEDS

Увы, тут нет сколько-нибудь обнадёживающей информации.

systemd, равно как и ядро, не решают проблему наполнения пула 
качественной энтропией на ранней стадии загрузки для тех приложений, 
которым она действительно нужна. А должны ли они решать эту проблему?

Сам systemd не использует криптографию, допустим. Но есть службы, 
которые её используют. И есть машины, для которых нет решения с 
аппаратными источниками в TPM/CPU. А решение для UEFI-систем с 
/sys/firmware/efi/efivars/LoaderRandomSeed-4a67b082-0a4c-41cf-b6c7-440b29bb8c4fи 
перезаписью /boot/efi/loader/random-seed, доступного в момент 
монтирования ВСЕМ пользователям -- так себе решение, если не сказать хуже.

Для тех, кто будет сталкиваться с этой проблемой, по-прежнему остаётся 
два варианта: использовать дополнительный аппаратный (доверенный) 
источник ЛИБО ослаблять энтропию программными демонами типа 
rngd/haveged/etc.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

On 31.08.2019 2:06, Alexey Shabalin wrote:
> пт, 31 мая 2019 г. в 19:58, Anton Farygin <rider@basealt.ru>:
>> 31.05.2019 13:56, Alexey V. Vissarionov пишет:
>>> On 2019-05-31 09:50:09 +0300, Anton Farygin wrote:
>>>
>>>    >>> из двух зол - какое выбрать - Intel RDRAND или TPM ?
>>>    >> Оба одновременно: при наличии в системе хотя бы одного
>>>    >> доверенного источника энтропии они не смогут нагадить
>>>    >> даже при всем желании(*), ибо ложка стохастического
>>>    >> говна превращает бочку детерминированного меда в бочку
>>>    >> стохастического говна:-)
>>>    > ну собственно rngd так и делает - замешивает все существующие
>>>    > источники энтропии в один.
>>>
>>> Энтропия нужна_до_  запуска init.
>> А зачем она тебе до запуска init ?
> Для информации, от разработчиков systemd.
> https://systemd.io/RANDOM_SEEDS
>
When systemd’s PID 1 detects it runs in a virtualized environment 
providing the |virtio-rng| interface it will load the necessary kernel 
modules to make use of it during earliest boot, if possible — much 
earlier than regular kernel module loading done by 
|systemd-udevd.service|. This should ensure that in VM environments the 
entropy pool is quickly filled, even before systemd invokes the first 
service process — as long as the VM environment provides virtualized RNG 
hardware (and VM environments really should!).

Т.е. - со стороны системы виртуализации должно обязательно создаваться 
устройство virtio.

Тот же PVE, например, сейчас этого по умолчанию не делает.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-08-31 09:36:36 +0300, Leonid Krivoshein wrote:
 >>> А зачем она тебе до запуска init ?
 >> Для информации, от разработчиков systemd.
 >> https://systemd.io/RANDOM_SEEDS
 > Увы, тут нет сколько-нибудь обнадёживающей информации.
 > systemd, равно как и ядро, не решают проблему наполнения пула
 > качественной энтропией на ранней стадии загрузки для тех
 > приложений, которым она действительно нужна. А должны ли они
 > решать эту проблему?

Что любопытно, ядро эту задачу прекрасно решает. Особенно если
его об этом грамотно попросить.

 > Для тех, кто будет сталкиваться с этой проблемой, по-прежнему
 > остаётся два варианта: использовать дополнительный аппаратный
 > (доверенный) источник

Разве что на компутерах, где живет какой-нибудь CA... для всего
остального хватает грамотно собранного ядра (которое накапливает
энтропию начиная уже где-то с третьей секунды работы и к запуску
init успевает наполнить пул).

 > ЛИБО ослаблять энтропию программными демонами типа rngd/haveged/etc.

А вот эту срань вообще использовать нельзя. Нигде и никогда.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

31.08.2019 15:35, Alexey V. Vissarionov пишет:
> On 2019-08-31 09:36:36 +0300, Leonid Krivoshein wrote:
>   >>> А зачем она тебе до запуска init ?
>   >> Для информации, от разработчиков systemd.
>   >> https://systemd.io/RANDOM_SEEDS
>   > Увы, тут нет сколько-нибудь обнадёживающей информации.
>   > systemd, равно как и ядро, не решают проблему наполнения пула
>   > качественной энтропией на ранней стадии загрузки для тех
>   > приложений, которым она действительно нужна. А должны ли они
>   > решать эту проблему?
>
> Что любопытно, ядро эту задачу прекрасно решает. Особенно если
> его об этом грамотно попросить.

Если имеется ввиду |rng_core.default_quality=1000| , это тоже не совсем 
доверенный источник, да и про |CONFIG_RANDOM_TRUST_CPU=y| некоторые 
скажут, что эту хрень не надо никогда использовать. В любом случае 
перечисленное энтропию ухудшает. Ну так я уже написал, что это доступно 
не на всём железе, и даже на современных железках не со всеми версиями 
фирмвари (микрокода CPU).


>   > Для тех, кто будет сталкиваться с этой проблемой, по-прежнему
>   > остаётся два варианта: использовать дополнительный аппаратный
>   > (доверенный) источник
>
> Разве что на компутерах, где живет какой-нибудь CA... для всего
> остального хватает грамотно собранного ядра (которое накапливает
> энтропию начиная уже где-то с третьей секунды работы и к запуску
> init успевает наполнить пул).

Так в том и проблема, что есть железо, где не успевает. Только о нём 
спич. И здесь речь о случайных числах для запуска самого systemd, 
который может стартануть и быстрее, чем через три секунды.


>   > ЛИБО ослаблять энтропию программными демонами типа rngd/haveged/etc.
>
> А вот эту срань вообще использовать нельзя. Нигде и никогда.
>

-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-08-31 17:47:06 +0300, Leonid Krivoshein wrote:

 >>> systemd, равно как и ядро, не решают проблему наполнения пула
 >>> качественной энтропией на ранней стадии загрузки
 >> Что любопытно, ядро эту задачу прекрасно решает. Особенно если
 >> его об этом грамотно попросить.
 > Если имеется ввиду |rng_core.default_quality=1000| , это тоже
 > не совсем доверенный источник,

Нет - я про дисковые и сетевые контроллеры.

Для первых существует специальная функция add_disk_randomness(),
а вторые вызывают срабатывание add_interrupt_randomness() через
handle_irq_event_percpu()

 > да и про |CONFIG_RANDOM_TRUST_CPU=y| некоторые скажут, что
 > эту хрень не надо никогда использовать.

Использовать ее можно, но при соблюдении двух простых условий:
1. должны быть и другие источники энтропии;
2. к моменту начала использования недоверенного RNG пул должен
быть заполнен данными из других источников. И хорошо бы, чтобы
продолжал хотя бы чучуть пополняться из них.

После этого можно хоть cat /dev/zero > /dev/random запускать - на
качество энтропии это уже не повлияет :-)

 >>> остаётся два варианта: использовать дополнительный аппаратный
 >>> (доверенный) источник
 >> Разве что на компутерах, где живет какой-нибудь CA... для
 >> всего остального хватает грамотно собранного ядра (которое
 >> накапливает энтропию начиная уже где-то с третьей секунды
 >> работы и к запуску init успевает наполнить пул).
 > Так в том и проблема, что есть железо, где не успевает.

Полностью детерминированное железо? Где? Хочу!
Продам - стану миллиардером.

 > Только о нём спич. И здесь речь о случайных числах для запуска
 > самого systemd, который может стартануть и быстрее, чем через
 > три секунды.

Он при всем желании не может стартануть раньше, чем ядро скажет
run_init_process("/sbin/init");

А к этому времени пул энтропии уже должен быть хотя бы не пустым.
И достигается это (внезапно!) грамотной настройкой ядра.

 >>> ЛИБО ослаблять энтропию программными демонами типа rngd/haveged/etc.
 >> А вот эту срань вообще использовать нельзя. Нигде и никогда.

Здесь, насколько я понимаю, возражений нет?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

31.08.2019 18:42, Alexey V. Vissarionov пишет:
> On 2019-08-31 17:47:06 +0300, Leonid Krivoshein wrote:
>
>   >>> systemd, равно как и ядро, не решают проблему наполнения пула
>   >>> качественной энтропией на ранней стадии загрузки
>   >> Что любопытно, ядро эту задачу прекрасно решает. Особенно если
>   >> его об этом грамотно попросить.
>   > Если имеется ввиду |rng_core.default_quality=1000| , это тоже
>   > не совсем доверенный источник,
>
> Нет - я про дисковые и сетевые контроллеры.
>
> Для первых существует специальная функция add_disk_randomness(),
> а вторые вызывают срабатывание add_interrupt_randomness() через
> handle_irq_event_percpu()
>
>   > да и про |CONFIG_RANDOM_TRUST_CPU=y| некоторые скажут, что
>   > эту хрень не надо никогда использовать.
>
> Использовать ее можно, но при соблюдении двух простых условий:
> 1. должны быть и другие источники энтропии;

Вот их нет. Совсем!

> 2. к моменту начала использования недоверенного RNG пул должен
> быть заполнен данными из других источников.

Вот он ещё не заполнен. Почти... а уже надо!


> И хорошо бы, чтобы
> продолжал хотя бы чучуть пополняться из них.
> После этого можно хоть cat /dev/zero > /dev/random запускать - на
> качество энтропии это уже не повлияет :-)

Энтропия -- это не продукт алгоритмов криптостойкого хэширования с 
начальным состоянием, это "совершенно случайные нули и единицы". Но 
вывод /dev/random и getrandom(), как я сейчас понимаю, это не чистая 
энтропия, а всё же переработанная, хотяи с заданными пороговыми 
значениями, чтобы число бит на выходе не было меньше реальной энтропии 
на входе. Если же такое качество не требуется, достаточно брать 
случайные числа из /dev/urandom, только вот с недавних пор лишь после 
инициализации начального состояния.


>   >>> остаётся два варианта: использовать дополнительный аппаратный
>   >>> (доверенный) источник
>   >> Разве что на компутерах, где живет какой-нибудь CA... для
>   >> всего остального хватает грамотно собранного ядра (которое
>   >> накапливает энтропию начиная уже где-то с третьей секунды
>   >> работы и к запуску init успевает наполнить пул).
>   > Так в том и проблема, что есть железо, где не успевает.
>
> Полностью детерминированное железо? Где? Хочу!
> Продам - стану миллиардером.

Один такой ТОНК отправлен в Обнинск. Вообще подверженное проблеме железо 
периодически всплывает. Можем завести тему в ответ на данный запрос -- 
список с наименованиями конкретных железок будет полезен многим.


>   > Только о нём спич. И здесь речь о случайных числах для запуска
>   > самого systemd, который может стартануть и быстрее, чем через
>   > три секунды.
>
> Он при всем желании не может стартануть раньше, чем ядро скажет
> run_init_process("/sbin/init");

Процессы инициализации ядра и запуска /sbin/init асинхронны. 
Единственное, что делается ДО -- инициализация devtmpfs. К моменту 
запуска /sbin/init может быть даже не загружено ещё никаких модулей. 
Процесс асинхронной инициализации хорошо виден в dmesg и journalctl.

У нас, правда, тут не systemd сейчас стартует, а другой /sbin/init. Но 
надо понимать, что прохождение stage1 зависит от железа и конфигурации 
системы. К моменту stage2, где в качестве /sbin/init будет уже systemd, 
загрузка модулей продолжится, службы же начнут запускаться по-новой.


> А к этому времени пул энтропии уже должен быть хотя бы не пустым.
> И достигается это (внезапно!) грамотной настройкой ядра.

Осталось лишь огласить способ "грамотной настройки".


>   >>> ЛИБО ослаблять энтропию программными демонами типа rngd/haveged/etc.
>   >> А вот эту срань вообще использовать нельзя. Нигде и никогда.
>
> Здесь, насколько я понимаю, возражений нет?

А что делать тем, кому "аппаратный" вариант недоступен? Блокировку на 
этапе загрузки можно рассматривать не только как баг юзабилити. В ряде 
задач это тоже CVE, вплоть до DoS для всего HA-кластера. В конце концов, 
подкопив энтропии, можно обновить состояние инициализации CRNG. А 
терпеть тормоза при загрузке можно далеко не во всех сценариях.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 00:31, Leonid Krivoshein пишет:
>>> И здесь речь о случайных числах для запуска
>>> самого systemd, который может стартануть и быстрее, чем через
>>> три секунды.

  Мне тоже стало интересно, о чём вы тут спорите.

31.08.2019 18:42, Alexey V. Vissarionov пишет:
>> Он при всем желании не может стартануть раньше, чем ядро скажет
>> run_init_process("/sbin/init");

  Означает ли это, что в ядре есть код, который сперва ждёт накопления N
байт хорошей энтропии, и только после этого выполняет
run_init_process("/sbin/init") ?

03.09.2019 00:31, Leonid Krivoshein пишет:
> Процессы инициализации ядра и запуска /sbin/init асинхронны.

31.08.2019 18:42, Alexey V. Vissarionov пишет:
>> 2. к моменту начала использования недоверенного RNG пул должен
>> быть заполнен данными из других источников.

  Когда читаешь "должен быть заполнен" как отдельное условие, то
кажется, что тут есть элемент желательности. Мол, должен быть заполнен,
если всё идёт по плану. А если не заполнен, то значит вы это не
обеспечили, должным образом не настроили и т.д.

  Если это так, то мне стало интересно, почему это сделано так сложно,
что изначально содержит в себе потенциальную возможность race и
deadlock? По описываемым симптомам, проблема явно в том, что PID 1
стартует раньше, чем заполнен пул энтропии (необходимым и достаточным её
количеством). Но поскольку за запуск PID 1 и за энтропию отвечает одно и
то же ядро, то непонятно, почему нельзя сначала накопить энтропию
(послушать диски, сеть и т.п.), и только потом уже запустить PID 1?

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 00:31:05 +0300, Leonid Krivoshein wrote:

 >>>>> systemd, равно как и ядро, не решают проблему наполнения
 >>>>> пула качественной энтропией на ранней стадии загрузки
 >>>> Что любопытно, ядро эту задачу прекрасно решает. Особенно
 >>>> если его об этом грамотно попросить.
 >>> Если имеется ввиду |rng_core.default_quality=1000| , это тоже
 >>> не совсем доверенный источник,
 >> Нет - я про дисковые и сетевые контроллеры.
 >> Для первых существует специальная функция add_disk_randomness(),
 >> а вторые вызывают срабатывание add_interrupt_randomness() через
 >> handle_irq_event_percpu()

(1)

 >>> да и про |CONFIG_RANDOM_TRUST_CPU=y| некоторые скажут, что
 >>> эту хрень не надо никогда использовать.
 >> Использовать ее можно, но при соблюдении двух простых условий:
 >> 1. должны быть и другие источники энтропии;
 > Вот их нет. Совсем!

См. (1) - они есть всегда, просто особо одуренные явно отказываются
их использовать.

 >> 2. к моменту начала использования недоверенного RNG пул должен
 >> быть заполнен данными из других источников.
 > Вот он ещё не заполнен. Почти... а уже надо!

Если почти, то можно и недоверенный источник подмешивать.

 >> И хорошо бы, чтобы продолжал хотя бы чучуть пополняться из них.
 >> После этого можно хоть cat /dev/zero > /dev/random запускать -
 >> на качество энтропии это уже не повлияет :-)
 > Энтропия -- это не продукт алгоритмов криптостойкого
 > хэширования с начальным состоянием, это "совершенно случайные
 > нули и единицы".

Вообще-то энтропия - это просто мера неопределенности. Численно
определяется как двоичный логарифм от количества состояний системы
(в дебри определений от Шеннона, Рени и Хайзенберга не полезу).

 > Но вывод /dev/random и getrandom(), как я сейчас понимаю,
 > это не чистая энтропия, а всё же переработанная,

Перемешивание и отбеливание. Еще недавно использовали SHA2, щас
зачем-то поменяли хеш на Poly1305.

 > хотяи с заданными пороговыми значениями, чтобы число бит на
 > выходе не было меньше реальной энтропии на входе.

Дядя, ты как сам-то? Если не меньше - значит, строго равно (ибо
больше оно не может быть по определению), но после отбеливания
оно может быть только строго меньше.

А вот обеспечить некоторое заданное наперед качество ("не хуже")
уже реально. И пороговые значения определяют именно это качество
случайных данных на выходе генератора.

 > Если же такое качество не требуется, достаточно брать случайные
 > числа из /dev/urandom,

Я бы сказал, что /dev/urandom следует использовать почти для всего.
Единственное разумное исключение, где нужен /dev/random - генерация
ключевых пар для алгоритмов с открытым ключом.

 > только вот с недавних пор лишь после инициализации начального
 > состояния.

Оно всегда так было. Только время загрузки ядра было таким, что
одних только IRQ14 и IRQ15 (а то и IRQ6) хватало на полноценный
/dev/random (а ведь еще были IRQ1 и всякие IRQ10 с IRQ11).

Вот интересно: кто из тутошних читателей сможет назвать все
устройства, генерирующие перечисленные мной прерывания (кроме
двух последних), не пользуясь справочными материалами? :-)

 >>>>> остаётся два варианта: использовать дополнительный
 >>>>> аппаратный (доверенный) источник
 >>>> Разве что на компутерах, где живет какой-нибудь CA... для
 >>>> всего остального хватает грамотно собранного ядра (которое
 >>>> накапливает энтропию начиная уже где-то с третьей секунды
 >>>> работы и к запуску init успевает наполнить пул).
 >>> Так в том и проблема, что есть железо, где не успевает.
 >> Полностью детерминированное железо? Где? Хочу!
 >> Продам - стану миллиардером.
 > Один такой ТОНК отправлен в Обнинск.

Видел я эти ваши тонки... нихренасеньки они не детерминированные,
обычная писюшатина.

 > Вообще подверженное проблеме железо периодически всплывает.
 > Можем завести тему в ответ на данный запрос -- список с
 > наименованиями конкретных железок будет полезен многим.

Сильно подозреваю, что источник проблемы - в явном отказе от
использования доверенных и проверенных (десятилетиями!) источников
случайных данных.

 >>> Только о нём спич. И здесь речь о случайных числах для запуска
 >>> самого systemd, который может стартануть и быстрее, чем через
 >>> три секунды.
 >> Он при всем желании не может стартануть раньше, чем ядро скажет
 >> run_init_process("/sbin/init");
 > Процессы инициализации ядра и запуска /sbin/init асинхронны.

Они могут быть сколько угодно асинхронными, но run_init_process()
ядро выполнит никак не раньше, чем mount_block_root()

 > Единственное, что делается ДО -- инициализация devtmpfs.

Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется до
run_init_process(), но после mount_block_root()

 > К моменту запуска /sbin/init может быть даже не загружено ещё
 > никаких модулей.

И это очень плохо. Потому что очень многие из них используют как
минимум один способ (из четырех возможных) помочь ядерному ГСЧ
набрать энтропию перед run_init_process()

 > Процесс асинхронной инициализации хорошо виден в dmesg и
 > journalctl. У нас, правда, тут не systemd сейчас стартует, а
 > другой /sbin/init. Но надо понимать, что прохождение stage1
 > зависит от железа и конфигурации системы.

Что ты в данном случае называешь stage1?

 > К моменту stage2, где в качестве /sbin/init будет уже systemd,
 > загрузка модулей продолжится, службы же начнут запускаться
 > по-новой.

Пофигу: все это - уже работа процессов в userspace.

 >> А к этому времени пул энтропии уже должен быть хотя бы не
 >> пустым. И достигается это (внезапно!) грамотной настройкой
 >> ядра.
 > Осталось лишь огласить способ "грамотной настройки".

Такой, чтобы источники энтропии запускались до run_init_process()

 >>>>> ЛИБО ослаблять энтропию программными демонами типа
 >>>>> rngd/haveged/etc.
 >>>> А вот эту срань вообще использовать нельзя. Нигде и никогда.
 >> Здесь, насколько я понимаю, возражений нет?
 > А что делать тем, кому "аппаратный" вариант недоступен?

Чаво?! Дисковый контроллер недоступен? Или сетевой адаптер?

 > Блокировку на этапе загрузки можно рассматривать не только как
 > баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS для
 > всего HA-кластера. В конце концов, подкопив энтропии, можно
 > обновить состояние инициализации CRNG.

Да: низкоэнтропийная криптография - это уязвимость. Исправлять ее
будем, или как обычно?

 > А терпеть тормоза при загрузке можно далеко не во всех сценариях.

При вводе системы в промышленную эксплуатацию сервер должен быть
запущен позавчера.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 01:25:00 +0300, Paul Wolneykien wrote:

 >>> Он при всем желании не может стартануть раньше, чем ядро
 >>> скажет run_init_process("/sbin/init");
 > Означает ли это, что в ядре есть код, который сперва ждёт
 > накопления N байт хорошей энтропии, и только после этого
 > выполняет run_init_process("/sbin/init") ?

В ядре такой проверки нет. И вероятность ее появления лично я
оцениваю как пренебрежимо малую.

 >>> 2. к моменту начала использования недоверенного RNG пул
 >>> должен быть заполнен данными из других источников.
 > Когда читаешь "должен быть заполнен" как отдельное условие,
 > то кажется, что тут есть элемент желательности. Мол, должен
 > быть заполнен, если всё идёт по плану.

Именно так. Потому что если он не будет заполнен - недоверенный
источник может выдать детерминированную последовательность и тем
самым ослабить криптозащиту.

 > А если не заполнен, то значит вы это не обеспечили, должным
 > образом не настроили и т.д.

Разумеется.

 > Если это так, то мне стало интересно, почему это сделано так
 > сложно, что изначально содержит в себе потенциальную возможность
 > race и deadlock?

Строго наоборот: очень долгое время (много лет) проблемы просто не
возникали, так как ядро успевало набрать энтропию всеми четырьмя
возможными способами - add_device_randomness(), add_disk_randomness(),
add_input_randomness() и add_interrupt_randomness(). Сейчас компутеры
стали производительнее и загружаются быстрее, да еще и люди мешают:
источники энтропии инициализируют поздно, а данные из ГСЧ хотят рано.

 > По описываемым симптомам, проблема явно в том, что PID 1 стартует
 > раньше, чем заполнен пул энтропии (необходимым и достаточным её
 > количеством). Но поскольку за запуск PID 1 и за энтропию отвечает
 > одно и то же ядро, то непонятно, почему нельзя сначала накопить
 > энтропию (послушать диски, сеть и т.п.), и только потом уже
 > запустить PID 1?

Почему нельзя-то? Можно. Но, похоже, никому не нужно.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Anton Farygin]

On 03.09.2019 8:58, Alexey V. Vissarionov wrote:
>   > По описываемым симптомам, проблема явно в том, что PID 1 стартует
>   > раньше, чем заполнен пул энтропии (необходимым и достаточным её
>   > количеством). Но поскольку за запуск PID 1 и за энтропию отвечает
>   > одно и то же ядро, то непонятно, почему нельзя сначала накопить
>   > энтропию (послушать диски, сеть и т.п.), и только потом уже
>   > запустить PID 1?
>
> Почему нельзя-то? Можно. Но, похоже, никому не нужно.

Сеть до PID 1 не обязана быть.

обращений к диску на этапе initramfs не так много.
interrupt'ам и input'ам на виртуалке не откуда взяться, пока её никто не 
начнёт использовать. Так и будет висеть в стадии загрузки почти вечность.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

03.09.2019 01:25, Paul Wolneykien пишет:
> 03.09.2019 00:31, Leonid Krivoshein пишет:
>>>> И здесь речь о случайных числах для запуска
>>>> самого systemd, который может стартануть и быстрее, чем через
>>>> три секунды.
>    Мне тоже стало интересно, о чём вы тут спорите.

В данном случае речь о проблемах, обсуждаемых в статье: 
https://systemd.io/RANDOM_SEEDS -- разработчики systemd заверяют, что 
случайные числа на раннем этапе запуска им тоже нужны, но их источник не 
обязан быть криптографического качества. В принципе, даже 1 бит энтропии 
вместе с текущим временем и glibc rand() это обеспечивают. Поэтому речь 
явно не только запуске самого systemd, иначе бы так сильно не 
заморачивались.


> 31.08.2019 18:42, Alexey V. Vissarionov пишет:
>>> Он при всем желании не может стартануть раньше, чем ядро скажет
>>> run_init_process("/sbin/init");
>    Означает ли это, что в ядре есть код, который сперва ждёт накопления N
> байт хорошей энтропии, и только после этого выполняет
> run_init_process("/sbin/init") ?
>
> 03.09.2019 00:31, Leonid Krivoshein пишет:
>> Процессы инициализации ядра и запуска /sbin/init асинхронны.
> 31.08.2019 18:42, Alexey V. Vissarionov пишет:
>>> 2. к моменту начала использования недоверенного RNG пул должен
>>> быть заполнен данными из других источников.
>    Когда читаешь "должен быть заполнен" как отдельное условие, то
> кажется, что тут есть элемент желательности. Мол, должен быть заполнен,
> если всё идёт по плану. А если не заполнен, то значит вы это не
> обеспечили, должным образом не настроили и т.д.
>
>    Если это так, то мне стало интересно, почему это сделано так сложно,
> что изначально содержит в себе потенциальную возможность race и
> deadlock? По описываемым симптомам, проблема явно в том, что PID 1
> стартует раньше, чем заполнен пул энтропии (необходимым и достаточным её
> количеством). Но поскольку за запуск PID 1 и за энтропию отвечает одно и
> то же ядро, то непонятно, почему нельзя сначала накопить энтропию
> (послушать диски, сеть и т.п.), и только потом уже запустить PID 1?
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Aleksei Nikiforov]

03.09.2019 1:25, Paul Wolneykien пишет:
[...]>    Если это так, то мне стало интересно, почему это сделано так 
сложно,
> что изначально содержит в себе потенциальную возможность race и
> deadlock? По описываемым симптомам, проблема явно в том, что PID 1
> стартует раньше, чем заполнен пул энтропии (необходимым и достаточным её
> количеством). Но поскольку за запуск PID 1 и за энтропию отвечает одно и
> то же ядро, то непонятно, почему нельзя сначала накопить энтропию
> (послушать диски, сеть и т.п.), и только потом уже запустить PID 1?

А разве всем реализациям PID 1 нужна энтропия для работы во всех 
сценариях запуска? Кажется, нет, потому и не ждут энтропию для PID 1.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

03.09.2019 02:59, Alexey V. Vissarionov пишет:
> [...]
>
>   >> 2. к моменту начала использования недоверенного RNG пул должен
>   >> быть заполнен данными из других источников.
>   > Вот он ещё не заполнен. Почти... а уже надо!
>
> Если почти, то можно и недоверенный источник подмешивать.

В смысле: пул почти почти пуст.


> [...]
>
>   > хотяи с заданными пороговыми значениями, чтобы число бит на
>   > выходе не было меньше реальной энтропии на входе.
>
> Дядя, ты как сам-то? Если не меньше - значит, строго равно (ибо

Конечно, оговорка по Фрейду: s/не меньше/не больше/ :)


> [...]
>
>   > Единственное, что делается ДО -- инициализация devtmpfs.
>
> Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется до
> run_init_process(), но после mount_block_root()

Инициализация экземпляра файловой системы внутри ядра и монтирование её 
в userspace -- две разные вещи. Монтирование /dev в userspace 
инициируется процессом с PID 1 уже после того, как ядро 
проинициализировало initramfs, devtpmfs, нашло и запустило /sbin/init. 
Никаких устройств на этом этапе ещё нет, ramfs/tpmfs в ядро 
вкомпилируются. Даже если не указывать путь к собственному initramfs, 
оно тоже в ядре имеется всегда. Пустое, без /sbin/init, чтобы отработал 
твой любимый fallback с /dev/md0.


>   > К моменту запуска /sbin/init может быть даже не загружено ещё
>   > никаких модулей.
>
> И это очень плохо. Потому что очень многие из них используют как
> минимум один способ (из четырех возможных) помочь ядерному ГСЧ
> набрать энтропию перед run_init_process()

К счастью, в initramfs у нас не systemd, иначе с проблемой мы 
сталкивались бы раньше и на большем охвате железа. systemd только так 
генерирует UUID'ы для сервисов, множество временных файлов, использует 
внутренние хэш-таблицы и случайные числа для всевозможных "сетевых" 
нужд. Так что плохо, да, но может быть ещё хуже. Полагаю, тем, у кого 
нет systemd, эта проблема неведома. На SysV-init вероятность запуска 
сервиса, требующего CRNG, примерно равна нулю.


>   > Процесс асинхронной инициализации хорошо виден в dmesg и
>   > journalctl. У нас, правда, тут не systemd сейчас стартует, а
>   > другой /sbin/init. Но надо понимать, что прохождение stage1
>   > зависит от железа и конфигурации системы.
>
> Что ты в данном случае называешь stage1?

initrafms (initrd) -- первая стадия загрузки.


> [...]
>
>   > Блокировку на этапе загрузки можно рассматривать не только как
>   > баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS для
>   > всего HA-кластера. В конце концов, подкопив энтропии, можно
>   > обновить состояние инициализации CRNG.
>
> Да: низкоэнтропийная криптография - это уязвимость. Исправлять ее
> будем, или как обычно?
>
>   > А терпеть тормоза при загрузке можно далеко не во всех сценариях.
>
> При вводе системы в промышленную эксплуатацию сервер должен быть
> запущен позавчера.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 10:28:59 +0300, Aleksei Nikiforov wrote:

 >> Но поскольку за запуск PID 1 и за энтропию отвечает одно и
 >> то же ядро, то непонятно, почему нельзя сначала накопить
 >> энтропию (послушать диски, сеть и т.п.), и только потом уже
 >> запустить PID 1?
 > А разве всем реализациям PID 1 нужна энтропия для работы
 > во всех сценариях запуска? Кажется, нет, потому и не ждут
 > энтропию для PID 1.

По уму процесс, работающий с PID == 1, может вообще выглядеть
так (цитирую содержательную часть):

  sigfillset(&sset);
  sigprocmask(SIG_BLOCK, &sset, NULL);
  if(fork())
  {
    for(;;)
      wait(NULL);
  }
  else
  {
    sigprocmask(SIG_UNBLOCK, &sset, NULL);
    setsid();
    setpgrp();
    /* find and execute startup script */
    execve("/etc/rc", (char *[]){"rc", NULL}, (char *[]){NULL});
    /* this would cause kernel panic and (if enabled) reboot */
    return 1;
  }

Ясен пень, никакой ГСЧ ему для работы не нужен.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 10:02, Leonid Krivoshein пишет:
> 
> 03.09.2019 01:25, Paul Wolneykien пишет:
>> 03.09.2019 00:31, Leonid Krivoshein пишет:
>>>>> И здесь речь о случайных числах для запуска
>>>>> самого systemd, который может стартануть и быстрее, чем через
>>>>> три секунды.
>>    Мне тоже стало интересно, о чём вы тут спорите.
> 
> В данном случае речь о проблемах, обсуждаемых в статье:
> https://systemd.io/RANDOM_SEEDS -- разработчики systemd заверяют, что
> случайные числа на раннем этапе запуска им тоже нужны, но их источник не
> обязан быть криптографического качества.

  И, стало быть, разницы между /dev/random и /dev/urandom им
недостаточно? Одного слишком много — встаёт колом, другой — слишком
низкого качества. В таком случае им нужен третий — какой-нибудь
/dev/boot_random, качество и количество энтропии в котором будет
необходимого и достаточного качества.
  Но мне кажется, что это ошибка и вполне опасная. В вопросах
безопасности "серединный путь" не годится, я считаю. Если уж
пользователь выбрал ОС с криптозагрузкой (назовём это так), то
требования должны быть высокими во избежание. С быстрой загрузкой без
спецоборудования это вряд ли совместимо и поэтому не нужно пытаться
делать вид, что это так.

> В принципе, даже 1 бит энтропии
> вместе с текущим временем и glibc rand() это обеспечивают. Поэтому речь
> явно не только запуске самого systemd, иначе бы так сильно не
> заморачивались.

  А кто ещё, sshd? Почему с ним раньше проблем не возникало? Ну и опять
же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
какая-то служба долго не стартует, то в журнале должно быть что-то про
нехватку энтропии.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 08:58, Alexey V. Vissarionov пишет:
>> Если это так, то мне стало интересно, почему это сделано так
>  > сложно, что изначально содержит в себе потенциальную возможность
>  > race и deadlock?
> 
> Строго наоборот: очень долгое время (много лет) проблемы просто не
> возникали, так как ядро успевало

  Вот это ненадёжное слово — "успевало"! Оно мне страшно не нравится.

> набрать энтропию всеми четырьмя
> возможными способами - add_device_randomness(), add_disk_randomness(),
> add_input_randomness() и add_interrupt_randomness(). Сейчас компутеры
> стали производительнее и загружаются быстрее, да еще и люди мешают:
> источники энтропии инициализируют поздно, а данные из ГСЧ хотят рано.
> 
>  > По описываемым симптомам, проблема явно в том, что PID 1 стартует
>  > раньше, чем заполнен пул энтропии (необходимым и достаточным её
>  > количеством). Но поскольку за запуск PID 1 и за энтропию отвечает
>  > одно и то же ядро, то непонятно, почему нельзя сначала накопить
>  > энтропию (послушать диски, сеть и т.п.), и только потом уже
>  > запустить PID 1?
> 
> Почему нельзя-то? Можно. Но, похоже, никому не нужно.

  Я так подумал, что ведь и сам PID 1 можно модифицировать
соответствующим образом, чтобы он адекватно говорил, чего ему не хватает
и корректно ждал накопления шума.
  Вот тот же GnuPG, когда генерирует ключи, пишет сообщение вида: "Мне
не хватает случайных чисел — будь добр, посовершай какие-нибудь
действия". Мне кажется, что если энтропия действительно нужна при
загрузке, то подобное сообщение тоже должно быть. С той лишь разницей,
что обращено оно должно быть больше не к пользователю, а к
администратору и содержать в себе вероятные рецепты увеличения энтропии.
Вроде: подключите компьютер к локальной сети, подключите аппаратный
генератор СЧ и т.п.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 09:02, Anton Farygin пишет:
> On 03.09.2019 8:58, Alexey V. Vissarionov wrote:
>>   > По описываемым симптомам, проблема явно в том, что PID 1 стартует
>>   > раньше, чем заполнен пул энтропии (необходимым и достаточным её
>>   > количеством). Но поскольку за запуск PID 1 и за энтропию отвечает
>>   > одно и то же ядро, то непонятно, почему нельзя сначала накопить
>>   > энтропию (послушать диски, сеть и т.п.), и только потом уже
>>   > запустить PID 1?
>>
>> Почему нельзя-то? Можно. Но, похоже, никому не нужно.
> 
> Сеть до PID 1 не обязана быть.
> 
> обращений к диску на этапе initramfs не так много.
> interrupt'ам и input'ам на виртуалке не откуда взяться, пока её никто не
> начнёт использовать. Так и будет висеть в стадии загрузки почти вечность.

  Ну значит *данную* ОС на *данном* оборудовании запустить нельзя — вот
и всё. Только этот вывод должен быть однозначным и понятным
пользователю: мол, ты сам просил ОС с криптозагрузкой, а оборудование
соответствующее не предоставил.
  Тут ещё высока вероятность, что в принципе запустить эту ОС на данном
оборудовании можно не нарушая требование к энтропии, но только при
правильной конфигурации — т.е. чтобы ядру объяснили, как получить
энтропию в данном случае.
  У виртуалок же оборудование виртуальное. Стало быть хост (супервизор)
должен предоставлять энтропию. Понятно, что для того, чтобы её хватило
на всех, при одновременной загрузке всех виртуалок, хосту требуется
необычное оборудование.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 11:49:20 +0300, Paul Wolneykien wrote:

 >>> Если это так, то мне стало интересно, почему это сделано
 >>> так сложно, что изначально содержит в себе потенциальную
 >>> возможность race и deadlock?
 >> Строго наоборот: очень долгое время (много лет) проблемы
 >> просто не возникали, так как ядро успевало
 > Вот это ненадёжное слово — "успевало"! Оно мне страшно не
 > нравится.

Наполнение пула энтропии джля ГСЧ - вопрос времени. Если нет
специализированного оборудования (вроде моего клона ChaosKey),
для нормальной инициализации хватает примерно 10 секунд при
условии, что ядро начинает накачку энтропии за 5 секунд до
запуска /sbin/init (с аппаратным ГСЧ - 200...300 миллисекунд).

А у нас пул энтропии начинает наполняться уже _после_ запуска
/sbin/init - но всем пофигу.

 >> набрать энтропию всеми четырьмя возможными способами

Очень прошу по возможности избегать фигурной нарезки цитат -
это искажает их смысл. Или хотя бы явно обозначать это.

 >>> По описываемым симптомам, проблема явно в том, что PID 1
 >>> стартует раньше, чем заполнен пул энтропии [...]
 >>> Но поскольку за запуск PID 1 и за энтропию отвечает одно и
 >>> то же ядро, то непонятно, почему нельзя сначала накопить
 >>> энтропию (послушать диски, сеть и т.п.), и только потом уже
 >>> запустить PID 1?
 >> Почему нельзя-то? Можно. Но, похоже, никому не нужно.
 > Я так подумал, что ведь и сам PID 1 можно модифицировать
 > соответствующим образом, чтобы он адекватно говорил, чего
 > ему не хватает и корректно ждал накопления шума.

Можно. Более того, можно смонтировать /proc и ждать появления в
/proc/sys/kernel/random/entropy_avail четырехзначного числа:

% egrep '[0-9]{4}' /proc/sys/kernel/random/entropy_avail
3749

 > Вот тот же GnuPG, когда генерирует ключи, пишет сообщение
 > вида: "Мне не хватает случайных чисел — будь добр, посовершай
 > какие-нибудь действия".

Генерация ключевой пары - дело ответственное, и блокировка до
получения качественных случайных битов здесь не только допустима,
но и полностью оправдана.

 > Мне кажется, что если энтропия действительно нужна при загрузке,
 > то подобное сообщение тоже должно быть. С той лишь разницей, что
 > обращено оно должно быть больше не к пользователю, а к
 > администратору и содержать в себе вероятные рецепты увеличения
 > энтропии. Вроде: подключите компьютер к локальной сети,
 > подключите аппаратный генератор СЧ и т.п.

Пользователь от такой заявки вообще припухнет мрачно, а 95% админов
(http://lurkmore.to/95) снесут нахрен всю систему по причине "лучше
%s поставлю, там такой ботвы нет и все работает".


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 12:54, Alexey V. Vissarionov пишет:
> Наполнение пула энтропии джля ГСЧ - вопрос времени. Если нет
> специализированного оборудования (вроде моего клона ChaosKey),
> для нормальной инициализации хватает примерно 10 секунд при
> условии, что ядро начинает накачку энтропии за 5 секунд до
> запуска /sbin/init (с аппаратным ГСЧ - 200...300 миллисекунд).

  А откуда взялось это число 5 секунд? Или это просто твоя оценка
времени от загрузки ядра до запуска /sbin/init?

> А у нас пул энтропии начинает наполняться уже _после_ запуска
> /sbin/init - но всем пофигу.

  Если бы это было просто, то наверняка бы включили. Так что наверное
это не просто.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 10:37:07 +0300, Leonid Krivoshein wrote:

 >>> Единственное, что делается ДО -- инициализация devtmpfs.
 >> Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется
 >> до run_init_process(), но после mount_block_root()
 > Инициализация экземпляра файловой системы внутри ядра
 > и монтирование её в userspace -- две разные вещи.

А можно ссылочки в виде имен файлов и названий функций? Мало ли,
вдруг в ядре что-то кардинально поменялось, а я это пропустил...

 > Монтирование /dev в userspace инициируется процессом с PID 1

Да ну?

/*
 * If configured, or requested by the commandline, devtmpfs will be
 * auto-mounted after the kernel mounted the root filesystem.
 */
int devtmpfs_mount(const char *mntdir)
{
        int err;

        if (!mount_dev)
                return 0;

        if (!thread)
                return 0;

        err = ksys_mount("devtmpfs", mntdir, "devtmpfs", MS_SILENT, NULL);
        if (err)
                printk(KERN_INFO "devtmpfs: error mounting %i\n", err);
        else
                printk(KERN_INFO "devtmpfs: mounted\n");
        return err;
}

Это drivers/base/devtmpfs.c

 > уже после того, как ядро проинициализировало initramfs, devtpmfs,
 > нашло и запустило /sbin/init.

Не... корень смонтирован, devtmpfs смонтирован - а /sbin/init еще не
запущен.

Удивительно, правда? :-)

 > Никаких устройств на этом этапе ещё нет, ramfs/tpmfs в ядро
 > вкомпилируются.
 > Даже если не указывать путь к собственному initramfs, оно тоже в
 > ядре имеется всегда. Пустое, без /sbin/init,

Да - init/noinitramfs.c

 > чтобы отработал твой любимый fallback с /dev/md0.

Тут либо слово fallback не к месту, либо мысль куда-то ускользнула.

 >>> К моменту запуска /sbin/init может быть даже не загружено ещё
 >>> никаких модулей.
 >> И это очень плохо. Потому что очень многие из них используют
 >> как минимум один способ (из четырех возможных) помочь ядерному
 >> ГСЧ набрать энтропию перед run_init_process()
 > К счастью, в initramfs у нас не systemd, иначе с проблемой мы
 > сталкивались бы раньше и на большем охвате железа. systemd только
 > так генерирует UUID'ы для сервисов, множество временных файлов,
 > использует внутренние хэш-таблицы и случайные числа для
 > всевозможных "сетевых" нужд. Так что плохо, да, но может быть ещё
 > хуже. Полагаю, тем, у кого нет systemd, эта проблема неведома.

Да какая разница? Запустили init - появились процессы в userspace,
которым нужен ГСЧ.

 > На SysV-init вероятность запуска сервиса, требующего CRNG, примерно
 > равна нулю.

В этом тысячелетии я компутеров без SSH уже не видел.

 >>> Процесс асинхронной инициализации хорошо виден в dmesg и
 >>> journalctl. У нас, правда, тут не systemd сейчас стартует, а
 >>> другой /sbin/init. Но надо понимать, что прохождение stage1
 >>> зависит от железа и конфигурации системы.
 >> Что ты в данном случае называешь stage1?
 > initrafms (initrd) -- первая стадия загрузки.

Пофигу - это уже userspace.

 >>> Блокировку на этапе загрузки можно рассматривать не только
 >>> как баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS
 >>> для всего HA-кластера. В конце концов, подкопив энтропии,
 >>> можно обновить состояние инициализации CRNG.
 >> Да: низкоэнтропийная криптография - это уязвимость. Исправлять
 >> ее будем, или как обычно?

Это отнюдь не риторический вопрос.

 >>> А терпеть тормоза при загрузке можно далеко не во всех
 >>> сценариях.
 >> При вводе системы в промышленную эксплуатацию сервер должен
 >> быть запущен позавчера.

Здесь, насколько я понимаю, возражений нет?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 13:01:14 +0300, Paul Wolneykien wrote:

 >> Наполнение пула энтропии джля ГСЧ - вопрос времени. Если нет
 >> специализированного оборудования (вроде моего клона ChaosKey),
 >> для нормальной инициализации хватает примерно 10 секунд при
 >> условии, что ядро начинает накачку энтропии за 5 секунд до
 >> запуска /sbin/init (с аппаратным ГСЧ - 200...300 миллисекунд).
 > А откуда взялось это число 5 секунд? Или это просто твоя оценка
 > времени от загрузки ядра до запуска /sbin/init?

Это результат моего эксперимента по измерению этого времени. Всех
делов - напихать в ядро (файл drivers/char/random.c) кучку вызовов
pr_notice(entropy_store.entropy_count) и потом посмотреть на вывод
dmesg.

 >> А у нас пул энтропии начинает наполняться уже _после_ запуска
 >> /sbin/init - но всем пофигу.
 > Если бы это было просто, то наверняка бы включили. Так что
 > наверное это не просто.

Предельно просто: запустить `make menuconfig` и понажимать "Y" в
нужных местах.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 13:29, Alexey V. Vissarionov пишет:
>  >> А у нас пул энтропии начинает наполняться уже _после_ запуска
>  >> /sbin/init - но всем пофигу.
>  >
>  > Если бы это было просто, то наверняка бы включили. Так что
>  > наверное это не просто.
> 
> Предельно просто: запустить `make menuconfig` и понажимать "Y" в
> нужных местах.

  Так может быть ты тогда просто соберёшь отдельный пакет
kernel-image-early-random ? Его тогда можно будет поставить на те
машинки, где наблюдается проблема, и посмотреть поможет ли.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 13:35:30 +0300, Paul Wolneykien wrote:

 >>>> А у нас пул энтропии начинает наполняться уже _после_ запуска
 >>>> /sbin/init - но всем пофигу.
 >>> Если бы это было просто, то наверняка бы включили. Так что
 >>> наверное это не просто.
 >> Предельно просто: запустить `make menuconfig` и понажимать "Y"
 >> в нужных местах.
 > Так может быть ты тогда просто соберёшь отдельный пакет
 > kernel-image-early-random ? Его тогда можно будет поставить на
 > те машинки, где наблюдается проблема, и посмотреть поможет ли.

Я подумаю в эту сторону.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Michael Shigorin]

On Tue, Sep 03, 2019 at 01:38:01PM +0300, Alexey V. Vissarionov wrote:
>  >>>> А у нас пул энтропии начинает наполняться уже _после_
>  >>>> запуска /sbin/init - но всем пофигу.
>  >>> Если бы это было просто, то наверняка бы включили. Так что
>  >>> наверное это не просто.
>  >> Предельно просто: запустить `make menuconfig` и понажимать
>  >> "Y" в нужных местах.

[*]

>  > Так может быть ты тогда просто соберёшь отдельный пакет
>  > kernel-image-early-random ? Его тогда можно будет поставить на
>  > те машинки, где наблюдается проблема, и посмотреть поможет ли.
> Я подумаю в эту сторону.

А diff от std-def на шаге [*] хорошо бы повесить как FR на
kernel-image-std-def; вот и будет конструктив по шажочку :-)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

03.09.2019 11:49, Paul Wolneykien пишет:
> 03.09.2019 10:02, Leonid Krivoshein пишет:
>> 03.09.2019 01:25, Paul Wolneykien пишет:
>>> 03.09.2019 00:31, Leonid Krivoshein пишет:
>>>>>> И здесь речь о случайных числах для запуска
>>>>>> самого systemd, который может стартануть и быстрее, чем через
>>>>>> три секунды.
>>>     Мне тоже стало интересно, о чём вы тут спорите.
>> В данном случае речь о проблемах, обсуждаемых в статье:
>> https://systemd.io/RANDOM_SEEDS -- разработчики systemd заверяют, что
>> случайные числа на раннем этапе запуска им тоже нужны, но их источник не
>> обязан быть криптографического качества.
>    И, стало быть, разницы между /dev/random и /dev/urandom им
> недостаточно? Одного слишком много — встаёт колом, другой — слишком
> низкого качества. В таком случае им нужен третий — какой-нибудь
> /dev/boot_random, качество и количество энтропии в котором будет
> необходимого и достаточного качества.
>    Но мне кажется, что это ошибка и вполне опасная. В вопросах
> безопасности "серединный путь" не годится, я считаю. Если уж
> пользователь выбрал ОС с криптозагрузкой (назовём это так), то
> требования должны быть высокими во избежание. С быстрой загрузкой без
> спецоборудования это вряд ли совместимо и поэтому не нужно пытаться
> делать вид, что это так.

В целом, согласен. Статус этого документа не совсем ясен. Я бы назвал 
это "отмазками". Преподносится как информация для разработчиков. И 
действительно из этого документа можно задействовать множество способов, 
где железо позволяет. А где не позволяет, здесь говорится, чем грозит и 
что это будет вашим риском. Всё честно.


>
>> В принципе, даже 1 бит энтропии
>> вместе с текущим временем и glibc rand() это обеспечивают. Поэтому речь
>> явно не только запуске самого systemd, иначе бы так сильно не
>> заморачивались.
>    А кто ещё, sshd?

Нет, даже при запуске ssh-keygen -A используется /dev/urandom для 
инициализации внутреннего ГПСЧ. Возможности сменить источник СЧ я там не 
увидел. Но в командной строке есть возможность использовать готовый 
сертификат. Тот факт, что при запуске службы возможна генерация 
криптографических пар таким вот генератором меня тоже удивляет. Тут надо 
иметь ввиду, что зависимость от /dev/urandom порождает меньшее из зол: с 
какого-то ядра (4.16 кажись) принято блокировать обращение к 
/dev/urandom до полной инициализации пула ядра. Судя по логам, первым, 
кто оттуда хапает трижды по 16 байт -- systemd. В дальнейшем в лог 
выводятся лишь предупреждения о недостатке энтропии, но блокировки не 
выполняется. И нет, на практике с sshd проблем не вылазило ни разу. 
Проблемы вылазили и будут вылазить со всей криптухой, начиная с 
cryptsetup до всяких keyring'ов.


> Почему с ним раньше проблем не возникало?

Тут gremlin@ уже верно ответил. Лишь добавлю деталей: массовый переход с 
HDD на SSD/NVME (прерываний в первых секундах старта ощутимо меньше), 
более быстрый параллельный запуск. Раньше можно было увидеть загруженный 
desktop MATE за 14-20 секунд, на некоторых новых машинках уже 5-7 
секунд. Раньше загрузка была последовательной, сам SysVinit не требовал 
ГПСЧ.


> Ну и опять
> же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
> какая-то служба долго не стартует, то в журнале должно быть что-то про
> нехватку энтропии.

Тут сложнее. Никто (systemd тоже) не может заранее предугадать, какая из 
служб попросит у ядра getrandom(), а на время блокировки все зависимые 
службы не будут грузиться. Например, при запуске графического сеанса с 
включенным авто-входом в MATE, стартует gnome-keyring, и вместо рабочего 
стола несколько минут чёрный экран. В журнале dmesg через несколько 
минут может появиться одна запись. Типа crng init done. Тогда процесс 
загрузки продолжится. Ускорить помогает хаотичное движение мышкой и 
нажатие клавиш.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

03.09.2019 11:49, Paul Wolneykien пишет:
> 03.09.2019 09:02, Anton Farygin пишет:
>> [...]
>> Сеть до PID 1 не обязана быть.
>>
>> обращений к диску на этапе initramfs не так много.
>> interrupt'ам и input'ам на виртуалке не откуда взяться, пока её никто не
>> начнёт использовать. Так и будет висеть в стадии загрузки почти вечность.
> [...]
>    У виртуалок же оборудование виртуальное. Стало быть хост (супервизор)
> должен предоставлять энтропию. Понятно, что для того, чтобы её хватило
> на всех, при одновременной загрузке всех виртуалок, хосту требуется
> необычное оборудование.

При этом зачастую такого оборудования просто нет. А как быть, если на 
моей личной машине стартует куча виртуалок? Даже не одновременно, а 
последовательно. Тоже обзаводиться спецоборудованием? По-моему, задачи 
криптографии нужно просто отделять и создавать для них требуемые условия 
отдельно.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Tue, 3 Sep 2019 22:52:16 +0300 Leonid Krivoshein wrote:
> 
> 03.09.2019 11:49, Paul Wolneykien пишет:
> > 03.09.2019 09:02, Anton Farygin пишет:
> >> [...]
> >> Сеть до PID 1 не обязана быть.
> >>
> >> обращений к диску на этапе initramfs не так много.
> >> interrupt'ам и input'ам на виртуалке не откуда взяться, пока её никто не
> >> начнёт использовать. Так и будет висеть в стадии загрузки почти вечность.
> > [...]
> >    У виртуалок же оборудование виртуальное. Стало быть хост (супервизор)
> > должен предоставлять энтропию. Понятно, что для того, чтобы её хватило
> > на всех, при одновременной загрузке всех виртуалок, хосту требуется
> > необычное оборудование.
> 
> При этом зачастую такого оборудования просто нет. А как быть, если на 
> моей личной машине стартует куча виртуалок? Даже не одновременно, а 
> последовательно. Тоже обзаводиться спецоборудованием? По-моему, задачи 
> криптографии нужно просто отделять и создавать для них требуемые условия 
> отдельно.

Купи себе TRNG генератор, или попроси gremlin@ спаять :)

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

03.09.2019 13:12, Alexey V. Vissarionov пишет:
> On 2019-09-03 10:37:07 +0300, Leonid Krivoshein wrote:
>
>   >>> Единственное, что делается ДО -- инициализация devtmpfs.
>   >> Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется
>   >> до run_init_process(), но после mount_block_root()
>   > Инициализация экземпляра файловой системы внутри ядра
>   > и монтирование её в userspace -- две разные вещи.
>
> А можно ссылочки в виде имен файлов и названий функций? Мало ли,
> вдруг в ядре что-то кардинально поменялось, а я это пропустил...

Это больше к ядерщикам. Из общедоступного:

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
https://lwn.net/Articles/330985/
https://lwn.net/Articles/345480/
https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt


>   > Монтирование /dev в userspace инициируется процессом с PID 1
>
> Да ну?
>
> /*
>   * If configured, or requested by the commandline, devtmpfs will be
>   * auto-mounted after the kernel mounted the root filesystem.
>   */
> int devtmpfs_mount(const char *mntdir)
> {
> ...
> }

Комментарий *НАД* внимательно прочитал? Твой аргумент правильно понимать 
иначе: авто-монтирование тоже возможно. Но на практике ни разу не 
встречал. По крайней мере, во всех альтовых скриптах /dev монтируется по 
инициативе PID 1. И в других дистрибутивах тоже так. И опять же: 
авто-монтирование отработает при определённом конфигурировании только 
после монтирования rootfs. Другое дело, что...


> Это drivers/base/devtmpfs.c
>
>   > уже после того, как ядро проинициализировало initramfs, devtpmfs,
>   > нашло и запустило /sbin/init.
>
> Не... корень смонтирован, devtmpfs смонтирован - а /sbin/init еще не
> запущен.
>
> Удивительно, правда? :-)

Не удивительно, а описано в вышеприведённой статье:

After the rootfs is mounted by the kernel, the
populated tmpfs is mounted at /dev. In initramfs, it can be moved
to the manually mounted root filesystem before /sbin/init is
executed.


Есть всё же два init'а: /init (у нас в initramfs/stage1 и /sbin/init -- 
systemd в stage2).
На практике даже у нас встречал оба варианта в разных версиях.
Как предварительный mount --bind, так и отдельный экземпляр tmpfs.
Но это только при переходе из stage1 в stage2.

stage1:

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/etc/rc.d/init.d/mountfs;h=8e10d7b49e1d0bf4c4cc26bb04562b94029d51a8;hb=04d5b713fccb53022fd82c222316fed8aaeebe88#l18

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/etc/rc.d/rc.sysexec;h=292f440abfcfc0ac7b2fd32654cdb7ae15c6ffdd;hb=04d5b713fccb53022fd82c222316fed8aaeebe88

http://git.altlinux.org/gears/k/kinit-utils.git?p=kinit-utils.git;a=blob;f=kinit/run-init/runinitlib.c;h=8f1562fba7ff007cc2e719a4aa3abd4fb5a8b259;hb=f2f5cd25b9bac163e1a0e8a6e0a0878bb9373634

stage2:

http://git.altlinux.org/gears/a/alterator-pkg.git?p=alterator-pkg.git;a=blob;f=alterator-pkg/backend3/pkg-init;h=9e76ca686d4d6744d50027d884f51615c7271ac3;hb=7f733b649837a386a368c9d79366528e49200864#l40

http://git.altlinux.org/gears/s/startup.git?p=startup.git;a=blob;f=startup/rc.d/rc.sysinit;h=b332f6788ebff22cc1c88b7f0d6e5b84ff4b725b;hb=d176d6ded32e643fb4e7c45894d6c721756f8ad0#l264


>   > Никаких устройств на этом этапе ещё нет, ramfs/tpmfs в ядро
>   > вкомпилируются.
>   > Даже если не указывать путь к собственному initramfs, оно тоже в
>   > ядре имеется всегда. Пустое, без /sbin/init,
>
> Да - init/noinitramfs.c
>
>   > чтобы отработал твой любимый fallback с /dev/md0.
>
> Тут либо слово fallback не к месту, либо мысль куда-то ускользнула.

fallback -- что делать, если не задан какой-то внешний initramfs.
Твой любимый внутри-ядерный авто-поиск корневой системы, так ОК?


> [...]
>
>   > На SysV-init вероятность запуска сервиса, требующего CRNG, примерно
>   > равна нулю.
>
> В этом тысячелетии я компутеров без SSH уже не видел.

Да, но не в первые же секунды.


> [...]
>
>   >>> Блокировку на этапе загрузки можно рассматривать не только
>   >>> как баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS
>   >>> для всего HA-кластера. В конце концов, подкопив энтропии,
>   >>> можно обновить состояние инициализации CRNG.
>   >> Да: низкоэнтропийная криптография - это уязвимость. Исправлять
>   >> ее будем, или как обычно?
>
> Это отнюдь не риторический вопрос.
>
>   >>> А терпеть тормоза при загрузке можно далеко не во всех
>   >>> сценариях.
>   >> При вводе системы в промышленную эксплуатацию сервер должен
>   >> быть запущен позавчера.
>
> Здесь, насколько я понимаю, возражений нет?

Готового решения в Сизиф пока никто не выложил. Безопасного решения, 
ставшего панацеей в других дистрибутивах с systemd, пока тоже не 
наблюдается. Есть только disclamers от Поттеринга и Ко.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

03.09.2019 23:01, Andrey Savchenko пишет:
> On Tue, 3 Sep 2019 22:52:16 +0300 Leonid Krivoshein wrote:
>> [...]
>>
>> При этом зачастую такого оборудования просто нет. А как быть, если на
>> моей личной машине стартует куча виртуалок? Даже не одновременно, а
>> последовательно. Тоже обзаводиться спецоборудованием? По-моему, задачи
>> криптографии нужно просто отделять и создавать для них требуемые условия
>> отдельно.
> Купи себе TRNG генератор, или попроси gremlin@ спаять :)

Да gremlin@'у завод пора открывать! :-) А у меня почти нет криптографии.
Но догадываюсь, что делать, если придётся генерировать крипто-ключи.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 22:52, Leonid Krivoshein пишет:
> 
> 03.09.2019 11:49, Paul Wolneykien пишет:
>> 03.09.2019 09:02, Anton Farygin пишет:
>>> [...]
>>> Сеть до PID 1 не обязана быть.
>>>
>>> обращений к диску на этапе initramfs не так много.
>>> interrupt'ам и input'ам на виртуалке не откуда взяться, пока её никто не
>>> начнёт использовать. Так и будет висеть в стадии загрузки почти
>>> вечность.
>> [...]
>>    У виртуалок же оборудование виртуальное. Стало быть хост (супервизор)
>> должен предоставлять энтропию. Понятно, что для того, чтобы её хватило
>> на всех, при одновременной загрузке всех виртуалок, хосту требуется
>> необычное оборудование.
> 
> При этом зачастую такого оборудования просто нет. А как быть, если на
> моей личной машине стартует куча виртуалок? Даже не одновременно, а
> последовательно. Тоже обзаводиться спецоборудованием? По-моему, задачи
> криптографии нужно просто отделять и создавать для них требуемые условия
> отдельно.

  Дык, об том и речь, что виртуалки с криптозагрузкой должны стартовать
на хосте с необычным оборудованием. А ОС с обыкновенной загрузкой не
должны требовать энтропии.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Paul Wolneykien]

03.09.2019 22:46, Leonid Krivoshein пишет:
>> Ну и опять
>> же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
>> какая-то служба долго не стартует, то в журнале должно быть что-то про
>> нехватку энтропии.
> 
> Тут сложнее. Никто (systemd тоже) не может заранее предугадать, какая из
> служб попросит у ядра getrandom(), а на время блокировки все зависимые
> службы не будут грузиться. Например, при запуске графического сеанса с
> включенным авто-входом в MATE, стартует gnome-keyring, и вместо рабочего
> стола несколько минут чёрный экран. В журнале dmesg через несколько
> минут может появиться одна запись. Типа crng init done. Тогда процесс
> загрузки продолжится. Ускорить помогает хаотичное движение мышкой и
> нажатие клавиш.

  Это очень печально. Почему он не рисует на экране и не просит шевелить
мышкой? Впору багу на апстрим вешать.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-03 23:56:12 +0300, Leonid Krivoshein wrote:

 >> Купи себе TRNG генератор, или попроси gremlin@ спаять :)
 > Да gremlin@'у завод пора открывать! :-)

Завод не завод, но я таки подумаю, какой гешефт на этом можно
будет сделать. И как :-)

 > А у меня почти нет криптографии. Но догадываюсь, что делать,
 > если придётся генерировать крипто-ключи.

В домашних условиях можно накачать торрентов и встать на раздачу,
остальное делают сетевые карты через add_interrupt_randomness()

А в офисных условиях достаточно просто быть подключенным к сети.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

04.09.2019 02:33, Paul Wolneykien пишет:
> 03.09.2019 22:46, Leonid Krivoshein пишет:
>>> Ну и опять
>>> же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
>>> какая-то служба долго не стартует, то в журнале должно быть что-то про
>>> нехватку энтропии.
>> Тут сложнее. Никто (systemd тоже) не может заранее предугадать, какая из
>> служб попросит у ядра getrandom(), а на время блокировки все зависимые
>> службы не будут грузиться. Например, при запуске графического сеанса с
>> включенным авто-входом в MATE, стартует gnome-keyring, и вместо рабочего
>> стола несколько минут чёрный экран. В журнале dmesg через несколько
>> минут может появиться одна запись. Типа crng init done. Тогда процесс
>> загрузки продолжится. Ускорить помогает хаотичное движение мышкой и
>> нажатие клавиш.
>    Это очень печально. Почему он не рисует на экране и не просит шевелить
> мышкой? Впору багу на апстрим вешать.

Потому что демоны не интерактивны, их в/в зачастую куда-то перенаправлен.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng

[Nikolai Kostrigin]

28.05.2019 3:53, Leonid Krivoshein пишет:
>
> 23.05.2019 02:08, Alexey Shabalin пишет:
>> чт, 25 апр. 2019 г. в 13:29, Konstantin Lepikhov
>> <lakostis@altlinux.org>:
>>> Привет!
>>>
>>> В продолжение обсуждения у кого энтропия длиннее^W лучше я тут провел
>>> несколько тестов. Идея - замерить как быстро будет заканчиваться
>>> энтропия
>>> в случае использования haveged/rngd/ничего (ядра).
>> В копилку дополнительных решений.
>
> https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html
>
>
> Поглядим по сторонам. :) Разные интересные решения в одном месте. И
> про jitterentropy_rng, и особенно заманчиво приглянулось убивать самим
> systemd застрявшие процессы через coredump.

В преддверии выхода kernel-5.3 завязалась дискуссия как раз по поводу
нехватки энтропии "на взлете" системы.

Точка входа в тред, может быть выбрана неудачно, но, заинтересованные,
думаю походят по треду туда-сюда...

https://lore.kernel.org/linux-ext4/20190915084802.GB29771@gardel-login/

>
>
>> Случайно наткнулся на специальный
>> клиент-сервер :)
>> pollen - сервер (https://github.com/dustinkirkland/pollen) - на golang
>> pollinate - клиент (https://github.com/dustinkirkland/pollinate) -
>> простой sh
>> Делали для Ubuntu, и Ubuntu предоставляет сервис Entropy-as-a-Service
>> https://entropy.ubuntu.com
>> Никто не запрещает его поднять внутри своей сети.
>> И cloud-init (виртуалки в облачных окружениях) умеeт использовать
>> клиента.
>
-- 
Best regards,
Nikolai Kostrigin

Re: [devel] rngd vs haveged vs crng

[Alexey V. Vissarionov]

On 2019-09-17 23:08:44 +0300, Nikolai Kostrigin wrote:

 > В преддверии выхода kernel-5.3 завязалась дискуссия как
 > раз по поводу нехватки энтропии "на взлете" системы.

Жареный петух - птица мудрости...

 > Точка входа в тред, может быть выбрана неудачно, но,
 > заинтересованные, думаю походят по треду туда-сюда...
 > https://lore.kernel.org/linux-ext4/20190915084802.GB29771@gardel-login/

Задача накачки пула энтропии до запуска init уже давно имеет
весьма красивое решение (даже не требующее никаких изменений
в ядерном коде), но всем как обычно.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng

[Leonid Krivoshein]

18.09.2019 0:51, Alexey V. Vissarionov пишет:
> On 2019-09-17 23:08:44 +0300, Nikolai Kostrigin wrote:
>
>   > В преддверии выхода kernel-5.3 завязалась дискуссия как
>   > раз по поводу нехватки энтропии "на взлете" системы.
>
> Жареный петух - птица мудрости...
>
>   > Точка входа в тред, может быть выбрана неудачно, но,
>   > заинтересованные, думаю походят по треду туда-сюда...
>   > https://lore.kernel.org/linux-ext4/20190915084802.GB29771@gardel-login/
>
> Задача накачки пула энтропии до запуска init уже давно имеет
> весьма красивое решение (даже не требующее никаких изменений
> в ядерном коде), но всем как обычно.

Это красивое решение хоть где-то опубликовано? Если нет, то не 
считается. Хотя постановка вопроса верная, Патраков о том же пишет: до 
запуска инита пул надо наполнять. Но мужики во главе с Торвальдсом пока 
не знают, как это сделать...


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Sergey Bolshakov]

>>>>> "Paul" == Paul Wolneykien <manowar-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

[skipped]

 >   А кто ещё, sshd? Почему с ним раньше проблем не возникало? Ну и опять
 > же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
 > какая-то служба долго не стартует, то в журнале должно быть что-то про
 > нехватку энтропии.

Подписчикам devel@ наверное будет небезынтересно узнать, что
ssh-keygen -A, запускающийся всякий раз перед стартом sshd,
сначала делает getrandom(), а уж затем проверяет наличие ключей,
растрачивая, таким образом, впустую драгоценную случайность в
подавляющем большинстве запусков.

-- 

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Alexey V. Vissarionov]

On 2019-09-20 13:47:56 +0300, Sergey Bolshakov wrote:

 >> А кто ещё, sshd? Почему с ним раньше проблем не возникало?
 >> Ну и опять же, на мой взгляд это проблема, в первую очередь,
 >> в диагностике. Если какая-то служба долго не стартует, то в
 >> журнале должно быть что-то про нехватку энтропии.
 > Подписчикам devel@ наверное будет небезынтересно узнать, что
 > ssh-keygen -A, запускающийся всякий раз перед стартом sshd,
 > сначала делает getrandom(), а уж затем проверяет наличие ключей,
 > растрачивая, таким образом, впустую драгоценную случайность в
 > подавляющем большинстве запусков.

Blattella vulgaris. То есть, баг обыкновенный.

Как в самом ssh-keygen, так и в init-скрипте (нужно добавить test -s
/etc/ssh/ssh_host_rsa_key и test -s /etc/ssh/ssh_host_ed25519_key, а
сами ключи генерировать в %post).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein]

20.09.2019 18:12, Leonid Krivoshein пишет:
>
>
> 20.09.2019 17:46, Leonid Krivoshein пишет:
>>
>> 20.09.2019 13:47, Sergey Bolshakov пишет:
>>>>>>>> "Paul" == Paul Wolneykien<manowar-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>  writes:
>>> [skipped]
>>>
>>>   >   А кто ещё, sshd? Почему с ним раньше проблем не возникало? Ну и опять
>>>   > же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
>>>   > какая-то служба долго не стартует, то в журнале должно быть что-то про
>>>   > нехватку энтропии.
>>>
>>> Подписчикам devel@ наверное будет небезынтересно узнать, что
>>> ssh-keygen -A, запускающийся всякий раз перед стартом sshd,
>>> сначала делает getrandom(), а уж затем проверяет наличие ключей,
>>> растрачивая, таким образом, впустую драгоценную случайность в
>>> подавляющем большинстве запусков.
>>
>> Прям всякий раз? Вроде только, если ключи ещё не сгенерированы.
>>
>> А откуда инфа про getrandom() ? Когда я последний раз бегло изучал 
>> этот код, как раз был сильно удивлён отсутствием именно криптографии 
>> -- там используется собственный генератор случайных чисел, а для его 
>> инициализации берётся несколько байт из /dev/urandom.
>>
>> Но давайте, наконец, развеем мои заблуждения чтобы поставить точку 
>> для подписчиков devel@ ... ))
>>
>
> Вспомнил: полез в самый свежий код из Сизифа, потому что удивил запуск 
> ssh-keygen -A под strace'ом -- ни одного вызова getrandom(), но чтение 
> /dev/urandom имело место. Так что, скорее всего, не заблуждение.
>

Нет, лучше всё же проверить. :-) Точно не помню, что там было, 
getrandom() или чтение /dev/urandom.


> Но, насколько я знаю, в новых инсталляторах ключи теперь создаются в 
> конце установки теперь. Убирать проверку и запуск ssh-keygen перед 
> стартом службы sshd смысла нет, если ключей нет, их лучше всё равно 
> создать. А вот идея создавать их в post% пакета мне видится вредной.
>

-- 
Best regards,
Leonid Krivoshein.