Re: [devel] [sisyphus] Не переключается в графический режим

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

02.11.2018 15:30, Dmitriy Rusetskiy пишет:
> Вот логи - когда подвисало. Если нужны.
>
> https://drive.google.com/file/d/13RxDZzgDtbl7OCAXPh8o_tBPHozIWOBX/view?usp=sharing
>
> пт, 2 нояб. 2018 г. в 15:07, Sergey V Turchin <zerg@altlinux.org>:
>> On Friday, 2 November 2018 15:03:21 MSK Leonid Krivoshein wrote:
>>> 02.11.2018 14:56, Sergey V Turchin пишет:
>>> [...]
>>> haveged в данном случае как раз решает проблему
>> Не решает, т.к. ничего не изменилось.

Спасибо! Стало яснее. Действительно, это другая проблема, новая:

dmesg | grep ' random: '
[    0.000000] random: get_random_bytes called from 
start_kernel+0x94/0x536 with crng_init=0
[    4.115462] random: fast init done
[    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
[    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
[    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
[   32.283736] random: crng init done
[   32.283746] random: 7 urandom warning(s) missed due to ratelimiting

До 32 секунды без haveged загрузка не идёт из-за зависимостей systemd и 
ядерных инноваций:

https://lkml.org/lkml/2018/4/25/163
https://bugzilla.redhat.com/show_bug.cgi?id=1572916


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

02.11.2018 19:27, Michael Shigorin пишет:
> On Fri, Nov 02, 2018 at 07:20:58PM +0300, Leonid Krivoshein wrote:
>> До 32 секунды без haveged загрузка не идёт из-за зависимостей
>> systemd и ядерных инноваций:
>>
>> https://lkml.org/lkml/2018/4/25/163
>> https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> -> https://bugzilla.redhat.com/show_bug.cgi?id=1639840
>

Да, подтверждают её с завидной регулярностью для всех последних ядер 
(4.16, 4.17, 4.18 -- точно). Говорят, что systemd при открытии журнала 
начинает инициализацию libgcrypt, который делает блокирующий вызов из-за 
наличия в ядре FIPS. Дальнейшее поясняет патч:

# Run the FIPS mode initialization in the shared library constructor
Patch18: libgcrypt-1.6.2-fips-ctor.patch


Но я его не нашёл. Понять бы, действительно ли в этом дело или нет? Идея 
с вкорячиванием haveged мне тоже не очень нравится.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Michael Shigorin]

On Fri, Nov 02, 2018 at 08:05:21PM +0300, Leonid Krivoshein wrote:
> Говорят, что systemd

Как там сказано в нашей документации -- "В отличие от sysvinit,
подвисание при запуске одного сервиса не приведет к остановке
всего процесса загрузки"?..

Надо сноску добавить: "если это не сам systemd".

> при открытии журнала начинает инициализацию libgcrypt,
> который делает блокирующий вызов из-за наличия в ядре FIPS.

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

02.11.2018 20:05, Leonid Krivoshein пишет:
> [...] Дальнейшее поясняет патч:
>
> # Run the FIPS mode initialization in the shared library constructor
> Patch18: libgcrypt-1.6.2-fips-ctor.patch
>
> Но я его не нашёл.
>

Нашёл, но не в нашем гите! 45 строка, _gcry_random_initialize() -- похоже:
https://github.com/hifi/libgcrypt-c7/blob/c7/libgcrypt-1.6.2-fips-ctor.patch#L45


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Paul Wolneykien]

02.11.2018 20:23, Leonid Krivoshein пишет:
> 
> 02.11.2018 20:05, Leonid Krivoshein пишет:
>> [...] Дальнейшее поясняет патч:
>>
>> # Run the FIPS mode initialization in the shared library constructor
>> Patch18: libgcrypt-1.6.2-fips-ctor.patch
>>
>> Но я его не нашёл.
>>
> 
> Нашёл, но не в нашем гите! 45 строка, _gcry_random_initialize() -- похоже:
> https://github.com/hifi/libgcrypt-c7/blob/c7/libgcrypt-1.6.2-fips-ctor.patch#L45

  Подтверждаю. Только что проверил: "fips" не упоминается в истории
изменений libgcrypt.spec. Нужно добавить?

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

02.11.2018 23:23, Paul Wolneykien пишет:
> 02.11.2018 20:23, Leonid Krivoshein пишет:
>> 02.11.2018 20:05, Leonid Krivoshein пишет:
>>> [...] Дальнейшее поясняет патч:
>>>
>>> # Run the FIPS mode initialization in the shared library constructor
>>> Patch18: libgcrypt-1.6.2-fips-ctor.patch
>>>
>>> Но я его не нашёл.
>>>
>> Нашёл, но не в нашем гите! 45 строка, _gcry_random_initialize() -- похоже:
>> https://github.com/hifi/libgcrypt-c7/blob/c7/libgcrypt-1.6.2-fips-ctor.patch#L45
>    Подтверждаю. Только что проверил: "fips" не упоминается в истории
> изменений libgcrypt.spec. Нужно добавить?

Вряд ли. :) Странно! Если именно этот вызов в Федоре вызывает проблему, 
а у нас этого куска нет, то обо что тогда у нас спотыкается? Просто в 
баге, что я указал выше, говорится о том, что они дебажили и наткнулись 
на это именно в таком месте. Кроме того, судя по спеку libgcrypt Федоры, 
там не один такой патч, связанный с FIPS. В общем, нам нужно либо без 
оглядки на Федору искать и самим это дебажить в новых ядрах (проверить 
на ТОНК'ах можем), либо не париться, а вкорячить во все дистры haveged, 
как раньше и предлагалось.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

02.11.2018 23:23, Paul Wolneykien пишет:
> 02.11.2018 20:23, Leonid Krivoshein пишет:
>> [...]
>    Подтверждаю. Только что проверил: "fips" не упоминается в истории
> изменений libgcrypt.spec. Нужно добавить?

С другой стороны, весь набор патчей, в том числе FIPS'овых, похоже 
бэкпортирован из новых версий коммерческой Федоры по случаю борьбы как 
раз с зависаниями из-за /dev/random, а сам код из паблика убрали. Но это 
лишь предположение, я в этом не настолько разбираюсь, чтобы советовать.

Просто даже, если мы отдебажим и найдём это место именно в libgcrypt, 
из-за параллелизма systemd завтра всплывёт что-то ещё. В каждом случае, 
как я понял, в идеале надо заменять deprecated чтение из /dev/random на 
системный вызов getrandom(2), что при раннем старте позволяет читать из 
менее секьюрного неблокирующего пула. Но таких мест в дистрибутивах 
может оказаться несколько.

В этой связи возникла мысль использовать haveged только там, где 
действительно без него не обойтись. Следуя букве, 
/proc/sys/kernel/random/entropy_avail показывает размер уже накопленной 
энтропии в битах. Если данных в пуле мало, запускаем haveged. То есть 
это д.б. тест перед запуском haveged, прописанный где-то в его 
systemd-юните.

man 4 random и 
https://pthree.org/2014/07/21/the-linux-random-number-generator/


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Denis Medvedev]

On суббота, 3 ноября 2018 г. 4:05:07 MSK Leonid Krivoshein wrote:
> 02.11.2018 23:23, Paul Wolneykien пишет:
> > 02.11.2018 20:23, Leonid Krivoshein пишет:
> >> [...]
> >> 
> >    Подтверждаю. Только что проверил: "fips" не упоминается в истории
> > 
> > изменений libgcrypt.spec. Нужно добавить?
> 
> С другой стороны, весь набор патчей, в том числе FIPS'овых, похоже
> бэкпортирован из новых версий коммерческой Федоры по случаю борьбы как
> раз с зависаниями из-за /dev/random, а сам код из паблика убрали. Но это
> лишь предположение, я в этом не настолько разбираюсь, чтобы советовать.
> 
> Просто даже, если мы отдебажим и найдём это место именно в libgcrypt,
> из-за параллелизма systemd завтра всплывёт что-то ещё. В каждом случае,
> как я понял, в идеале надо заменять deprecated чтение из /dev/random на
> системный вызов getrandom(2), что при раннем старте позволяет читать из
> менее секьюрного неблокирующего пула. Но таких мест в дистрибутивах
> может оказаться несколько.
> 
> В этой связи возникла мысль использовать haveged только там, где
> действительно без него не обойтись. Следуя букве,
> /proc/sys/kernel/random/entropy_avail показывает размер уже накопленной
> энтропии в битах. Если данных в пуле мало, запускаем haveged. То есть
> это д.б. тест перед запуском haveged, прописанный где-то в его
> systemd-юните.
> 
> man 4 random и
> https://pthree.org/2014/07/21/the-linux-random-number-generator/

 А если энтропии мало, может ее добавить естественным образом? Перед стартом X 
запустить какую-нибудь штуку, которая случайно почитает-попишет (с пользой или 
нет) с диска, к примеру? Что-нибудь типа легкого диск оптимизатора или fsck на 
раздел /boot (он маленький)?

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

03.11.2018 07:01, Denis Medvedev пишет:
> On суббота, 3 ноября 2018 г. 4:05:07 MSK Leonid Krivoshein wrote:
>> [...]
>> В этой связи возникла мысль использовать haveged только там, где
>> действительно без него не обойтись. Следуя букве,
>> /proc/sys/kernel/random/entropy_avail показывает размер уже накопленной
>> энтропии в битах. Если данных в пуле мало, запускаем haveged. То есть
>> это д.б. тест перед запуском haveged, прописанный где-то в его
>> systemd-юните.
>>
>> man 4 random и
>> https://pthree.org/2014/07/21/the-linux-random-number-generator/
>   А если энтропии мало, может ее добавить естественным образом? Перед стартом X
> запустить какую-нибудь штуку, которая случайно почитает-попишет (с пользой или
> нет) с диска, к примеру? Что-нибудь типа легкого диск оптимизатора или fsck на
> раздел /boot (он маленький)?

haveged именно этим и занимается. Точнее, он это делает при фейле ioctl 
(RNDADDENTROPY), что на раннем старте значительно нагружает процессор 
прерываниями и диск фейковым вводом/выводом. В любом случае получается 
некое подобие псевдослучайности /dev/urandom, что по идее может быть 
менее секьюрно, чем /dev/random. А хотелось бы решить проблему так, чтобы:

1) не ухудшать безопасность -- на большинстве машин проблема никак не 
проявляется, чтение из /dev/random не приводит к подвисаниям на раннем 
старте;
2) на тех машинах, где проблема всё же проявляется, запускать haveged 
автоматически, но именно автоматика должна определять необходимость 
запуска при каждом старте.
3) в идеале со временем найти и заменить все места с чтением из 
/dev/random на вызов getrandom(2).

Исходя из этого нужно:

1) определить значение длины минимально необходимой энтропии;
2) сделать тест длины энтропии и добавить его в systemd-unit для haveged;
3) включить haveged во все дистрибутивы.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

03.11.2018 14:43, Leonid Krivoshein пишет:
> Исходя из этого нужно:
>
> 1) определить значение длины минимально необходимой энтропии;
> 2) сделать тест длины энтропии и добавить его в systemd-unit для haveged;
> 3) включить haveged во все дистрибутивы.

Наверное, достаточно включить haveged -- у него самого есть порог (512 
бит энтропии по умолчанию, если меньше, то он включается, число меняется 
в настройках). А вот останавливать haveged после старта сессии или нет 
-- можно оставить на усмотрение пользователя.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

On 2018-11-03 07:01:11 +0300, Denis Medvedev wrote:

 >> Просто даже, если мы отдебажим и найдём это место именно в
 >> libgcrypt, из-за параллелизма systemd завтра всплывёт что-то
 >> ещё.

Ну, куча low entropy issues из-за этого уже есть, но всем как
всегда нет до этого никакого дела.

 >> В каждом случае, как я понял, в идеале надо заменять deprecated
 >> чтение из /dev/random на системный вызов getrandom(2),

С чего бы это /dev/random стал deprecated?

 >> что при раннем старте позволяет читать из менее секьюрного
 >> неблокирующего пула.

Который традиционно доступен из /dev/urandom и отличается от
/dev/random лишь тем, что при пустом пуле энтропии начинает
гаммирование по SHA2-256.

 >> Но таких мест в дистрибутивах может оказаться несколько.

Может. И наверняка есть.

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

Естественным образом - это через add_device_randomness(); все
остальные способы рекомендую считать противоестественными, ибо
велик риск нарваться на что-нибудь похлеще CVE-2008-0166.

 > Перед стартом X запустить какую-нибудь штуку, которая случайно

Как будем обеспечивать случайность, если пул энтропии пустой? :-)

 > почитает-попишет (с пользой или нет) с диска, к примеру?
 > Что-нибудь типа легкого диск оптимизатора или fsck на раздел
 > /boot (он маленький)?

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

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


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

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

On 2018-11-03 14:43:55 +0300, Leonid Krivoshein wrote:

 >> А если энтропии мало, может ее добавить естественным
 >> образом? Перед стартом X запустить какую-нибудь штуку
 > haveged именно этим и занимается. Точнее, он это делает
 > при фейле ioctl (RNDADDENTROPY),

Дурь. И дырища.

 > что на раннем старте значительно нагружает процессор
 > прерываниями и диск фейковым вводом/выводом.

Прерываниями? Значительно нагружает?
У вас там до сих пор 8259, что ли? :-)

 > В любом случае получается некое подобие псевдослучайности
 > /dev/urandom, что по идее может быть менее секьюрно, чем
 > /dev/random.

/dev/urandom намного лучше любого усерспейсного угробища. 

 > А хотелось бы решить проблему так, чтобы:
 > 1) не ухудшать безопасность -- на большинстве машин проблема
 > никак не проявляется, чтение из /dev/random не приводит к
 > подвисаниям на раннем старте;

Одно только это требование полностью исключает любые костыли в
усерспейсе.

 > 2) на тех машинах, где проблема всё же проявляется, запускать
 > haveged автоматически, но именно автоматика должна определять
 > необходимость запуска при каждом старте.

Можно обойтись безо всякой автоматики: не запускать вообще.

 > 3) в идеале со временем найти и заменить все
 > места с чтением из /dev/random на вызов getrandom(2).

Это влияет только на переносимость кода, но не на безопасность:

By default, getrandom() draws entropy from the urandom source
(i.e., the same source as the /dev/urandom device).

Угадаешь, откуда цитата? :-)

 > Исходя из этого нужно:
 > 1) определить значение длины минимально необходимой энтропии;
 > 2) сделать тест длины энтропии и добавить его в systemd-unit
 > для haveged;
 > 3) включить haveged во все дистрибутивы.

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


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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 10:37, Alexey V. Vissarionov пишет:
>   >> В каждом случае, как я понял, в идеале надо заменять deprecated
>   >> чтение из /dev/random на системный вызов getrandom(2),
>
> С чего бы это /dev/random стал deprecated?

man 4 random:

The //dev/random/ interface is considered a legacy interface.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Dmitry V. Levin]

On Mon, Nov 05, 2018 at 07:25:32PM +0300, Leonid Krivoshein wrote:
> 
> 05.11.2018 10:37, Alexey V. Vissarionov пишет:
> >   >> В каждом случае, как я понял, в идеале надо заменять deprecated
> >   >> чтение из /dev/random на системный вызов getrandom(2),
> >
> > С чего бы это /dev/random стал deprecated?
> 
> man 4 random:
> 
> The //dev/random/ interface is considered a legacy interface.

Т.е. вы перевели термин legacy как deprecated?

А вы знаете, что getrandom(2) появился в linux-3.17,
а getrandom(3) только в glibc-2.25?


-- 
ldv

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 11:23, Alexey V. Vissarionov пишет:
>   > В любом случае получается некое подобие псевдослучайности
>   > /dev/urandom, что по идее может быть менее секьюрно, чем
>   > /dev/random.
>
> /dev/urandom намного лучше любого усерспейсного угробища.

Вот поэтому...

>   > А хотелось бы решить проблему так, чтобы:
>   > 1) не ухудшать безопасность -- на большинстве машин проблема
>   > никак не проявляется, чтение из /dev/random не приводит к
>   > подвисаниям на раннем старте;
>
> Одно только это требование полностью исключает любые костыли в
> усерспейсе.

...и поэтому вопрос перенесён в devel@ для общего так сказать обсуждения.


>   > 3) в идеале со временем найти и заменить все
>   > места с чтением из /dev/random на вызов getrandom(2).
>
> Это влияет только на переносимость кода, но не на безопасность:
>
> By default, getrandom() draws entropy from the urandom source
> (i.e., the same source as the /dev/urandom device).
>
> Угадаешь, откуда цитата? :-)

Там же написано, что зависит от флагов. Да, по умолчанию из того же 
неблокирующего пула, это регулируется флагами. Один нюанс: данный вызов 
сам умеет учитывать факт раннего старта, размер имеющейся и запрошенной 
энтропии, этим он лучше простого чтения из /dev/urandom, но есть и 
минус: требуется ядро 3.17+.


>   > Исходя из этого нужно:
>   > 1) определить значение длины минимально необходимой энтропии;
>   > 2) сделать тест длины энтропии и добавить его в systemd-unit
>   > для haveged;
>   > 3) включить haveged во все дистрибутивы.
>
> А можно просто использовать специально для этого предназначенный
> источник - /dev/urandom; когда энтропии достаточно, он работает
> точно так же, как /dev/random, а когда не хватает - ну, хотя бы
> что-то более-менее приемлемое выдаст.

А есть мнение, что простое чтение из /dev/urandom не настолько безопасно 
на раннем старте. И стоит почитать про haveged -- это не просто 
юзерспейсный костыль. Кстати, на данный момент на некоторых железках без 
существенного погружения в код ничего лучше haveged проблему не решает.

When read during early boot time, //dev/urandom/ may return data prior 
to the entropy pool being initialized. If this is of concern in your 
application, use getrandom(2) 
<http://man7.org/linux/man-pages/man2/getrandom.2.html> or //dev/random/ 
instead.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 19:37, Dmitry V. Levin пишет:
> On Mon, Nov 05, 2018 at 07:25:32PM +0300, Leonid Krivoshein wrote:
>> 05.11.2018 10:37, Alexey V. Vissarionov пишет:
>>>    >> В каждом случае, как я понял, в идеале надо заменять deprecated
>>>    >> чтение из /dev/random на системный вызов getrandom(2),
>>>
>>> С чего бы это /dev/random стал deprecated?
>> man 4 random:
>>
>> The //dev/random/ interface is considered a legacy interface.
> Т.е. вы перевели термин legacy как deprecated?
>
> А вы знаете, что getrandom(2) появился в linux-3.17,
> а getrandom(3) только в glibc-2.25?

Знаю. По смыслу что-то сильно не так?
Устаревший, никто от него не отказывается, но лучше не использовать.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Mon, 5 Nov 2018 19:42:39 +0300 Leonid Krivoshein wrote:
> >   > Исходя из этого нужно:
> >   > 1) определить значение длины минимально необходимой энтропии;
> >   > 2) сделать тест длины энтропии и добавить его в systemd-unit
> >   > для haveged;
> >   > 3) включить haveged во все дистрибутивы.
> >
> > А можно просто использовать специально для этого предназначенный
> > источник - /dev/urandom; когда энтропии достаточно, он работает
> > точно так же, как /dev/random, а когда не хватает - ну, хотя бы
> > что-то более-менее приемлемое выдаст.
> 
> А есть мнение, что простое чтение из /dev/urandom не настолько безопасно 
> на раннем старте. И стоит почитать про haveged -- это не просто 
> юзерспейсный костыль. Кстати, на данный момент на некоторых железках без 
> существенного погружения в код ничего лучше haveged проблему не решает.

Давай исходить из задачи. Нужно просто случайные числа или
криптографически стойкие (т.е. алгоритмически неповторяемые
равномерно распределённые) случайные числа?

Если второе, то только /dev/random (или getrandom() с флагом
GRND_RANDOM, что есть точно то же) и *ничего* другого ни при каких
обстоятельствах и ни под каким предлогом. Иначе получится к с Debian
и "улучшением" в OpenSSL.

Если первое, то /dev/urandom (или getrandom() без GRND_RANDOM).

Насколько я понял текущую проблему, инициализируется gcrypt random
pool, ему нужна криптостойкая инициализация. Как решения данную
инициализацию нужно отложить (да, придётся лезть в кишки systemd).


Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 19:37, Dmitry V. Levin пишет:
> А вы знаете, что getrandom(2) появился в linux-3.17,
> а getrandom(3) только в glibc-2.25?

Если имелась ввиду эта статья https://lwn.net/Articles/711013/ , то я её 
тогда сразу прочёл: https://bugzilla.altlinux.org/show_bug.cgi?id=35297#c17

Однако проблема с зависаниями на раннем старте появилась сравнительно 
недавно и проявляется в очень редких случаях.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Mon, 5 Nov 2018 20:05:04 +0300 Andrey Savchenko wrote:
> On Mon, 5 Nov 2018 19:42:39 +0300 Leonid Krivoshein wrote:
> > >   > Исходя из этого нужно:
> > >   > 1) определить значение длины минимально необходимой энтропии;
> > >   > 2) сделать тест длины энтропии и добавить его в systemd-unit
> > >   > для haveged;
> > >   > 3) включить haveged во все дистрибутивы.
> > >
> > > А можно просто использовать специально для этого предназначенный
> > > источник - /dev/urandom; когда энтропии достаточно, он работает
> > > точно так же, как /dev/random, а когда не хватает - ну, хотя бы
> > > что-то более-менее приемлемое выдаст.
> > 
> > А есть мнение, что простое чтение из /dev/urandom не настолько безопасно 
> > на раннем старте. И стоит почитать про haveged -- это не просто 
> > юзерспейсный костыль. Кстати, на данный момент на некоторых железках без 
> > существенного погружения в код ничего лучше haveged проблему не решает.
> 
> Давай исходить из задачи. Нужно просто случайные числа или
> криптографически стойкие (т.е. алгоритмически неповторяемые
> равномерно распределённые) случайные числа?
> 
> Если второе, то только /dev/random (или getrandom() с флагом
> GRND_RANDOM, что есть точно то же) и *ничего* другого ни при каких
> обстоятельствах и ни под каким предлогом. Иначе получится к с Debian
> и "улучшением" в OpenSSL.
> 
> Если первое, то /dev/urandom (или getrandom() без GRND_RANDOM).
> 
> Насколько я понял текущую проблему, инициализируется gcrypt random
> pool, ему нужна криптостойкая инициализация. Как решения данную
> инициализацию нужно отложить (да, придётся лезть в кишки systemd).

Вот здесь поясняется, почему havaged нельзя использовать в
криптографических целях:
https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged

В общем, urandom < havaged < random.

Реальная проблема в том, что на обсуждаемом этапе загрузки random
ещё не нужен, но используется. Очередная глупость от systemd.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Mon, 5 Nov 2018 20:25:26 +0300 Andrey Savchenko wrote:
[...]
> > > А есть мнение, что простое чтение из /dev/urandom не настолько безопасно 
> > > на раннем старте. И стоит почитать про haveged -- это не просто 
> > > юзерспейсный костыль. Кстати, на данный момент на некоторых железках без 
> > > существенного погружения в код ничего лучше haveged проблему не решает.
> > 
> > Давай исходить из задачи. Нужно просто случайные числа или
> > криптографически стойкие (т.е. алгоритмически неповторяемые
> > равномерно распределённые) случайные числа?
> > 
> > Если второе, то только /dev/random (или getrandom() с флагом
> > GRND_RANDOM, что есть точно то же) и *ничего* другого ни при каких
> > обстоятельствах и ни под каким предлогом. Иначе получится к с Debian
> > и "улучшением" в OpenSSL.
> > 
> > Если первое, то /dev/urandom (или getrandom() без GRND_RANDOM).
> > 
> > Насколько я понял текущую проблему, инициализируется gcrypt random
> > pool, ему нужна криптостойкая инициализация. Как решения данную
> > инициализацию нужно отложить (да, придётся лезть в кишки systemd).
> 
> Вот здесь поясняется, почему havaged нельзя использовать в
> криптографических целях:
> https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged

Ещё статьи:
https://lwn.net/Articles/525459/
https://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines

В общем, для задачи получения критографически стойких случайных
чисел havaged не пригоден.
 
> В общем, urandom < havaged < random.
> 
> Реальная проблема в том, что на обсуждаемом этапе загрузки random
> ещё не нужен, но используется. Очередная глупость от systemd.
> 
> Best regards,
> Andrew Savchenko


Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Michael Shigorin]

On Mon, Nov 05, 2018 at 08:29:04PM +0300, Andrey Savchenko wrote:
> В общем, для задачи получения критографически стойких случайных
> чисел havaged не пригоден.

Напомню изначальную проблему: кто-то (наверняка с красной шляпой
на пустом жбане, но не суть) влепил в критический путь загрузки
"init" блокирующее чтение там, где без веских причин крипто не
нужно как таковое.

Давайте, может, не систему ломать под systemd, а наборот?

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 20:32, Michael Shigorin пишет:
> On Mon, Nov 05, 2018 at 08:29:04PM +0300, Andrey Savchenko wrote:
>> В общем, для задачи получения критографически стойких случайных
>> чисел havaged не пригоден.
> Напомню изначальную проблему: кто-то (наверняка с красной шляпой
> на пустом жбане, но не суть) влепил в критический путь загрузки
> "init" блокирующее чтение там, где без веских причин крипто не
> нужно как таковое.
>
> Давайте, может, не систему ломать под systemd, а наборот?

А "наоборот" -- это как, боюсь спросить? :)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Vladislav Zavjalov]

On Mon, Nov 05, 2018 at 08:48:06PM +0300, Leonid Krivoshein wrote:
> 
> 
> 05.11.2018 20:32, Michael Shigorin пишет:
> > On Mon, Nov 05, 2018 at 08:29:04PM +0300, Andrey Savchenko wrote:
> >> В общем, для задачи получения критографически стойких случайных
> >> чисел havaged не пригоден.
> > Напомню изначальную проблему: кто-то (наверняка с красной шляпой
> > на пустом жбане, но не суть) влепил в критический путь загрузки
> > "init" блокирующее чтение там, где без веских причин крипто не
> > нужно как таковое.
> >
> > Давайте, может, не систему ломать под systemd, а наборот?
> 
> А "наоборот" -- это как, боюсь спросить? :)

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

Re: [devel] Не переключается в графический режим

[Dmitry V. Levin]

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

On Mon, Nov 05, 2018 at 08:25:26PM +0300, Andrey Savchenko wrote:
[...]
> Реальная проблема в том, что на обсуждаемом этапе загрузки random
> ещё не нужен, но используется. Очередная глупость от systemd.

$ git grep -Fnw initialize_libgcrypt
src/basic/gcrypt-util.c:9:void initialize_libgcrypt(bool secmem) {
src/basic/gcrypt-util.c:30:        initialize_libgcrypt(false);
src/basic/gcrypt-util.h:14:void initialize_libgcrypt(bool secmem);
src/import/pull-job.c:324:                initialize_libgcrypt(false);
src/journal/fsprg.c:253:        initialize_libgcrypt(false);
src/journal/fsprg.c:289:        initialize_libgcrypt(false);
src/journal/fsprg.c:308:        initialize_libgcrypt(false);
src/journal/fsprg.c:335:        initialize_libgcrypt(false);
src/journal/fsprg.c:374:        initialize_libgcrypt(false);
src/journal/journal-authenticate.c:417:        initialize_libgcrypt(true);
src/resolve/resolved-dns-dnssec.c:852:        initialize_libgcrypt(false);
src/resolve/resolved-dns-dnssec.c:1171:        initialize_libgcrypt(false);
src/resolve/resolved-dns-dnssec.c:1284:        initialize_libgcrypt(false);

Который из них залипает на стадии ранней загрузки?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 20:25, Andrey Savchenko пишет:
> Вот здесь поясняется, почему havaged нельзя использовать в
> криптографических целях:
> https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged

Здесь ставится под сомнение алгоритм HAVEGE, а не конкретный демон 
haveged, который, во-первых, уже давно отказался от использования 
оригинального libhavege, во-вторых, преподносится, как устраняющий 
некоторые недостатки HAVEGE, в-третьих, он проходит многие тесты 
крипто-стойкойсти, если я правильно понимаю. Хотя если честно, я в этом 
нифига не понимаю: http://www.issihosts.com/haveged/ais31.html , поэтому 
обратился к @devel! :) Однако в документации haveged говорится, что на 
некотором железе "из коробки" качественный энтропийный пул можно 
обеспечить лишь после предварительной настройки и тестирования. Вот это 
больше всего напрягает, потому что, с учётом нашей задачи, нереализуемо 
в инсталляторе и его средствами.


> В общем, urandom < havaged < random.

Очень наглядная формула, но на разных этапах загрузки и в зависимости от 
железа она может выглядеть иначе. По ссылке выше предлагается такой 
вариант безопасного использования: haveged -n 1M -f /dev/urandom (IMHO: 
увы, данный способ не избавит от необходимости менять "проблемный" код 
systemd, libgcrypt, gnome-keyring-daemon и иже с ними).


> Реальная проблема в том, что на обсуждаемом этапе загрузки random
> ещё не нужен, но используется. Очередная глупость от systemd.

Вот с этим кто бы спорил! Только боюсь, масштаб проблемы неизвестен, он 
может не ограничиваться systemd. И главное, требуется время на ловлю 
блох, хотя если быстрее и проще вкорячить haveged, то "не будет у нас 
ничего более постоянного, чем временное"!


05.11.2018 20:29, Andrey Savchenko пишет:
> Ещё статьи:
> https://lwn.net/Articles/525459/
> https://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines

Чтобы осилить и осознать вторую ссылку, потребуется какое-то время...

В последней статье и комментариях к ней объясняется, почему haveged 
непригоден для виртуалок и почему вместо него следует использовать 
virtio-rng. С этим, конечно, не поспоришь, но мы говорим о начальной 
инициализации на bare metal. Конечно, работать в виртуальной среде наши 
дистрибутивы могут. Но я не слышал ещё ни разу, чтобы проблема давала о 
себе знать в какой-либо виртуальной среде.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Mon, 5 Nov 2018 21:58:53 +0300 Leonid Krivoshein wrote:
> 
> 05.11.2018 20:25, Andrey Savchenko пишет:
> > Вот здесь поясняется, почему havaged нельзя использовать в
> > криптографических целях:
> > https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged
> 
> Здесь ставится под сомнение алгоритм HAVEGE, а не конкретный демон 
> haveged, который, во-первых, уже давно отказался от использования 
> оригинального libhavege, во-вторых, преподносится, как устраняющий 
> некоторые недостатки HAVEGE, в-третьих, он проходит многие тесты 
> крипто-стойкойсти, если я правильно понимаю. Хотя если честно, я в этом 
> нифига не понимаю: http://www.issihosts.com/haveged/ais31.html , поэтому 
> обратился к @devel! :) Однако в документации haveged говорится, что на 
> некотором железе "из коробки" качественный энтропийный пул можно 
> обеспечить лишь после предварительной настройки и тестирования. Вот это 
> больше всего напрягает, потому что, с учётом нашей задачи, нереализуемо 
> в инсталляторе и его средствами.

Я следующим письмом ещё две ссылки кинул, одну из них повторю:
https://lwn.net/Articles/525459/
Там весьма детально всё разобрано. И не важно какой алгоритм
используется для получения чисел, важно — что он есть и повторяем.

Дальше, по поводу тестов, которые havaged проходит, в статье по
ссылке выше это тоже написано: не существует тестов на случайность
чисел, существуют тесты на неслучайность. И обмануть конкретный
набор тестов не сложно. Авторы Intel RNG это успешно сделали. Если
кто не в теме, в более-менее современных процессорах Intel есть
аппаратный генератор случайных чисел, который успешно проходил все
тесты (на неслучайность, т.е. тесты не выявляли наличия
закономерностей), тем не менее, генератор оказался уязвимым и, судя
по всему, намеренно, как нам поведал тов. Сноуден.

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

> > Реальная проблема в том, что на обсуждаемом этапе загрузки random
> > ещё не нужен, но используется. Очередная глупость от systemd.
> 
> Вот с этим кто бы спорил! Только боюсь, масштаб проблемы неизвестен, он 
> может не ограничиваться systemd. И главное, требуется время на ловлю 
> блох, хотя если быстрее и проще вкорячить haveged, то "не будет у нас 
> ничего более постоянного, чем временное"!

Вкорячим. А потом через пару-тройку лет будет разгромный позор по
наличию в Альте и только Альте уязвимости из-за ненадёжного
источника энтропии для криптозадач.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Mon, 5 Nov 2018 21:58:53 +0300 Leonid Krivoshein wrote:
> 
> 05.11.2018 20:25, Andrey Savchenko пишет:
> > Вот здесь поясняется, почему havaged нельзя использовать в
> > криптографических целях:
> > https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged
> 
> Здесь ставится под сомнение алгоритм HAVEGE, а не конкретный демон 
> haveged, который, во-первых, уже давно отказался от использования 
> оригинального libhavege, во-вторых, преподносится, как устраняющий 
> некоторые недостатки HAVEGE, в-третьих, он проходит многие тесты 
> крипто-стойкойсти, если я правильно понимаю.

По-моему, ты что-то не так понял. haveged как использовал алгоритм
HAVEGE, так и использует:
https://github.com/jirka-h/haveged/blob/master/README

In those cases, an adequate supply of random numbers can be
maintained by feeding additional entropy into /dev/random pool via
a file system interface. The haveged daemon was created to fulfill
this function using random data generated by the HAVEGE algorithm.

Т.е. он в /dev/random записывает данные, полученные с помощью
алгоритма HAVEGE.

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

Best regards,
Andrew Savchenko

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

Re: [devel] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 21:54, Dmitry V. Levin пишет:
> On Mon, Nov 05, 2018 at 08:25:26PM +0300, Andrey Savchenko wrote:
> [...]
>> Реальная проблема в том, что на обсуждаемом этапе загрузки random
>> ещё не нужен, но используется. Очередная глупость от systemd.
> $ git grep -Fnw initialize_libgcrypt
> src/basic/gcrypt-util.c:9:void initialize_libgcrypt(bool secmem) {
> src/basic/gcrypt-util.c:30:        initialize_libgcrypt(false);
> src/basic/gcrypt-util.h:14:void initialize_libgcrypt(bool secmem);
> src/import/pull-job.c:324:                initialize_libgcrypt(false);
> src/journal/fsprg.c:253:        initialize_libgcrypt(false);
> src/journal/fsprg.c:289:        initialize_libgcrypt(false);
> src/journal/fsprg.c:308:        initialize_libgcrypt(false);
> src/journal/fsprg.c:335:        initialize_libgcrypt(false);
> src/journal/fsprg.c:374:        initialize_libgcrypt(false);
> src/journal/journal-authenticate.c:417:        initialize_libgcrypt(true);
> src/resolve/resolved-dns-dnssec.c:852:        initialize_libgcrypt(false);
> src/resolve/resolved-dns-dnssec.c:1171:        initialize_libgcrypt(false);
> src/resolve/resolved-dns-dnssec.c:1284:        initialize_libgcrypt(false);
>
> Который из них залипает на стадии ранней загрузки?
>

Извиняюсь, если кого ввёл в заблуждение: там говорилось о разработчиках 
в красной шляпе и они у себя там чего-то наотлаживали, при этом была 
оговорка, что ничего похожего в нашем гите я не нашёл. Даже предлагал 
решать проблему без оглядки на RedHat. Тем не менее, на моей машине:

# systemd --version
systemd 237
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS 
+KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

# strings /lib/systemd/systemd | grep /dev/random
/dev/random
/dev/random

То есть, теоретически, "залипать" может "САМ"! :) Но у меня равно как и 
у большинства ничего не залипает. IMHO: systemd может не быть 
непосредственным виновником, но его асинхронность в ряде конфигураций 
может привести к тому, что "залипнет". Если бы факт наполненности пула 
можно было бы сделать зависимостью, но увы, это величина не постоянна.

Видимо этой проблеме уже присвоена CVE: 
https://access.redhat.com/security/cve/cve-2018-1108 , её пытаются 
решить с последними ядрами:

4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840

4.19: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d 
- good news, "Здравствуй, доверие"! :)

Но первый вопрос -- как это всё касается нас и касается ли вообще? Есть 
такой прецедент:

https://lists.altlinux.org/pipermail/sisyphus/2018-November/367280.html

Логи пока доступны. Едва ли по ним будет ясна проблема. Но из них ясно, 
что НАШ systemd использует /dev/urandom на стадии инициализации журнала. 
Да, ещё не инициализированный, но на этом он точно не залипает. Если там 
что и может залипать, то скорее NetworkManager или то, что зависит от 
сети и без чего почему-то не стартуют иксы. Возможно, стоит попросить 
отключить пока haveged и показать systemd-analaze critical-chain? Есть 
вообще какие-то способы (от initramfs до финальной загрузки) поймать 
всех, кто читает из /dev/random?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Не переключается в графический режим

[Andrey Savchenko]

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

On Mon, 5 Nov 2018 23:57:20 +0300 Leonid Krivoshein wrote:
[...]
> То есть, теоретически, "залипать" может "САМ"! :) Но у меня равно как и 
> у большинства ничего не залипает. IMHO: systemd может не быть 
> непосредственным виновником, но его асинхронность в ряде конфигураций 
> может привести к тому, что "залипнет". Если бы факт наполненности пула 
> можно было бы сделать зависимостью, но увы, это величина не постоянна.
> 
> Видимо этой проблеме уже присвоена CVE: 
> https://access.redhat.com/security/cve/cve-2018-1108 , её пытаются 
> решить с последними ядрами:

???
Это совсем другая проблема; она в том, что /dev/random мог выдавать
ненадёжные данные. Мало того, её решение только усложнит нашу
проблему, т.к. /dev/random будет выдавать ещё меньше данных на
ранних этапах после загрузки.
 
> 4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
> 4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> 4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840

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

> 4.19: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d 
> - good news, "Здравствуй, доверие"! :)

Это ответ на крики "почему вы таки не доверяете нашему хорошему
аппаратному генератору в процессоре"? Настоятельно советую
выключить эту вещь во всех ядрах.

> Но первый вопрос -- как это всё касается нас и касается ли вообще? Есть 
> такой прецедент:
> 
> https://lists.altlinux.org/pipermail/sisyphus/2018-November/367280.html
> 
> Логи пока доступны. Едва ли по ним будет ясна проблема. Но из них ясно, 
> что НАШ systemd использует /dev/urandom на стадии инициализации журнала. 
> Да, ещё не инициализированный, но на этом он точно не залипает. Если там 
> что и может залипать, то скорее NetworkManager или то, что зависит от 
> сети и без чего почему-то не стартуют иксы. Возможно, стоит попросить 
> отключить пока haveged и показать systemd-analaze critical-chain? Есть 
> вообще какие-то способы (от initramfs до финальной загрузки) поймать 
> всех, кто читает из /dev/random?

Запустить systemd под strace?

Best regards,
Andrew Savchenko

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

Re: [devel] Не переключается в графический режим

[Dmitry V. Levin]

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

On Mon, Nov 05, 2018 at 11:57:20PM +0300, Leonid Krivoshein wrote:
> 
> 05.11.2018 21:54, Dmitry V. Levin пишет:
> > On Mon, Nov 05, 2018 at 08:25:26PM +0300, Andrey Savchenko wrote:
> > [...]
> >> Реальная проблема в том, что на обсуждаемом этапе загрузки random
> >> ещё не нужен, но используется. Очередная глупость от systemd.
> > $ git grep -Fnw initialize_libgcrypt
> > src/basic/gcrypt-util.c:9:void initialize_libgcrypt(bool secmem) {
> > src/basic/gcrypt-util.c:30:        initialize_libgcrypt(false);
> > src/basic/gcrypt-util.h:14:void initialize_libgcrypt(bool secmem);
> > src/import/pull-job.c:324:                initialize_libgcrypt(false);
> > src/journal/fsprg.c:253:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:289:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:308:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:335:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:374:        initialize_libgcrypt(false);
> > src/journal/journal-authenticate.c:417:        initialize_libgcrypt(true);
> > src/resolve/resolved-dns-dnssec.c:852:        initialize_libgcrypt(false);
> > src/resolve/resolved-dns-dnssec.c:1171:        initialize_libgcrypt(false);
> > src/resolve/resolved-dns-dnssec.c:1284:        initialize_libgcrypt(false);
> >
> > Который из них залипает на стадии ранней загрузки?
> 
> Извиняюсь, если кого ввёл в заблуждение: там говорилось о разработчиках 
> в красной шляпе и они у себя там чего-то наотлаживали, при этом была 
> оговорка, что ничего похожего в нашем гите я не нашёл. Даже предлагал 
> решать проблему без оглядки на RedHat. Тем не менее, на моей машине:
> 
> # systemd --version
> systemd 237

В Сизифе systemd-239-alt3.

> +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP 
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS 
> +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
> 
> # strings /lib/systemd/systemd | grep /dev/random
> /dev/random
> /dev/random
> 
> То есть, теоретически, "залипать" может "САМ"! :) Но у меня равно как и 
> у большинства ничего не залипает. IMHO: systemd может не быть 
> непосредственным виновником, но его асинхронность в ряде конфигураций 
> может привести к тому, что "залипнет". Если бы факт наполненности пула 
> можно было бы сделать зависимостью, но увы, это величина не постоянна.
> 
> Видимо этой проблеме уже присвоена CVE: 
> https://access.redhat.com/security/cve/cve-2018-1108 , её пытаются 
> решить с последними ядрами:
> 
> 4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
> 4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> 4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840
> 
> 4.19: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d 
> - good news, "Здравствуй, доверие"! :)
> 
> Но первый вопрос -- как это всё касается нас и касается ли вообще? Есть 
> такой прецедент:
> 
> https://lists.altlinux.org/pipermail/sisyphus/2018-November/367280.html
> 
> Логи пока доступны. Едва ли по ним будет ясна проблема. Но из них ясно, 
> что НАШ systemd использует /dev/urandom на стадии инициализации журнала. 
> Да, ещё не инициализированный, но на этом он точно не залипает. Если там 
> что и может залипать, то скорее NetworkManager или то, что зависит от 
> сети и без чего почему-то не стартуют иксы. Возможно, стоит попросить 
> отключить пока haveged и показать systemd-analaze critical-chain? Есть 
> вообще какие-то способы (от initramfs до финальной загрузки) поймать 
> всех, кто читает из /dev/random?

Пожалуйста, не надо валить всё в одну кучу.

В первую очередь воспроизведите проблему сами,
а потом уже предлагайте гипотезы и берите в руки отладчики.

И выкиньте haveged куда подальше.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Не переключается в графический режим

[Leonid Krivoshein]

06.11.2018 00:19, Andrey Savchenko пишет:
> On Mon, 5 Nov 2018 23:57:20 +0300 Leonid Krivoshein wrote:
> [...]
>> Видимо этой проблеме уже присвоена CVE:
>> https://access.redhat.com/security/cve/cve-2018-1108 , её пытаются
>> решить с последними ядрами:
> ???
> Это совсем другая проблема; она в том, что /dev/random мог выдавать
> ненадёжные данные. Мало того, её решение только усложнит нашу
> проблему, т.к. /dev/random будет выдавать ещё меньше данных на
> ранних этапах после загрузки.

После того, как Ян Хорн сообщил, что функция crng_ready() неправильно 
обрабатывает состояния crng_init и RNG может считаться криптографически 
безопасным на слишком раннем этапе после загрузки системы, началась вся 
эта свистопляска:


>> 4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
>> 4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
>> 4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840
> Это реальные проблемы, схожие с нашей, но решений я в багах невижу.

Это я к тому, что ядерный CRNG до этого тоже был не столь криптостойким. ;-)


>> 4.19:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d
>> - good news, "Здравствуй, доверие"! :)
> Это ответ на крики "почему вы таки не доверяете нашему хорошему
> аппаратному генератору в процессоре"? Настоятельно советую
> выключить эту вещь во всех ядрах.

Конкретно данный патч позволит административно включить доверие к CPU 
RNG даже в тех дистрибутивах, где раньше ядро собиралось без такого 
доверия. По мне, так наоборот -- это шаг в сторону решения проблемы 
недостатка энтропии на некоторых конфигурациях и ждёт нас уже в 4.19.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Не переключается в графический режим

[Dmitry V. Levin]

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

On Tue, Nov 06, 2018 at 12:42:35AM +0300, Leonid Krivoshein wrote:
[...]
> Конкретно данный патч позволит административно включить доверие к CPU 
> RNG даже в тех дистрибутивах, где раньше ядро собиралось без такого 
> доверия. По мне, так наоборот -- это шаг в сторону решения проблемы 
> недостатка энтропии на некоторых конфигурациях и ждёт нас уже в 4.19.

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

05.11.2018 22:46, Andrey Savchenko пишет:
>> [...] Только боюсь, масштаб проблемы неизвестен, он
>> может не ограничиваться systemd. И главное, требуется время на ловлю
>> блох, хотя если быстрее и проще вкорячить haveged, то "не будет у нас
>> ничего более постоянного, чем временное"!
> Вкорячим. А потом через пару-тройку лет будет разгромный позор по
> наличию в Альте и только Альте уязвимости из-за ненадёжного
> источника энтропии для криптозадач.

Он же будет не единственным источником?
И предлагается как временный воркэраунд только на раннем этапе загрузки.


06.11.2018 00:32, Dmitry V. Levin пишет:
> [...]
> И выкиньте haveged куда подальше.

Если haveged добавляет энтропию, она так или иначе пропускается через 
ядерный крипто-фильтр, энтропию выдаёт в конечном итоге ядро, которое 
всё равно использует несколько разных источников. А вот отсутствие 
дополнительного источника энтропии в нужный момент, по крайней мере, до 
исправления CVE-2018-1108, можно считать проблемой.


P.S.: Но я как бы советуюсь, а не настаиваю! :)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Tue, 6 Nov 2018 01:12:57 +0300 Leonid Krivoshein wrote:
> 
> 05.11.2018 22:46, Andrey Savchenko пишет:
> >> [...] Только боюсь, масштаб проблемы неизвестен, он
> >> может не ограничиваться systemd. И главное, требуется время на ловлю
> >> блох, хотя если быстрее и проще вкорячить haveged, то "не будет у нас
> >> ничего более постоянного, чем временное"!
> > Вкорячим. А потом через пару-тройку лет будет разгромный позор по
> > наличию в Альте и только Альте уязвимости из-за ненадёжного
> > источника энтропии для криптозадач.
> 
> Он же будет не единственным источником?

haveged пишет данные в /dev/random, поэтому с точностью до xor он
будет единственным источником при исчерпании собственного пула ядра.
Мало того, если сделать xor (или иные воспроизводимые манипуляции)
с M бит случайных данных и N бит неслучайных (M < N), мы не получим
N бит случайных данных. Энтропия системы всё равно будет уменьшена.

> И предлагается как временный воркэраунд только на раннем этапе загрузки.

Этого будет достаточно для подрыва безопасности. Если внутреннее
состояние (пул) libgcrypt будет инициализирован не случайным
числом, но все полученные на его основе данные, включая сессионное
ключи шифрования, будут нестойкими.

> 06.11.2018 00:32, Dmitry V. Levin пишет:
> > [...]
> > И выкиньте haveged куда подальше.

+1

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

Ядро не создаёт энтропию само, а лишь собирает её из разных
источников и перемешивает пул с целью недопущения накопления
неравномерностей в выборке.

Посмотри drivers/char/random.c, функцию _mix_pool_bytes():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n511

При использовании haveged получается, что пул случайных данных
размывается пулом не таких уж и случаных. Это убивает на корню всё
доверие к /dev/random.

> А вот отсутствие дополнительного источника энтропии в нужный
> момент, по крайней мере, до исправления CVE-2018-1108, можно
> считать проблемой.

Это CVE не о нашей проблеме, а о другом: /dev/random слишком рано
выдавал данные.

Best regards,
Andrew Savchenko

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

Re: [devel] Не переключается в графический режим

[Andrey Savchenko]

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

On Tue, 6 Nov 2018 00:42:35 +0300 Leonid Krivoshein wrote:
> >> 4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
> >> 4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> >> 4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840
> > Это реальные проблемы, схожие с нашей, но решений я в багах невижу.
> 
> Это я к тому, что ядерный CRNG до этого тоже был не столь криптостойким. ;-)

И это не даёт нам права делать его ещё менее стойким. 
 
> >> 4.19:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d
> >> - good news, "Здравствуй, доверие"! :)
> > Это ответ на крики "почему вы таки не доверяете нашему хорошему
> > аппаратному генератору в процессоре"? Настоятельно советую
> > выключить эту вещь во всех ядрах.
> 
> Конкретно данный патч позволит административно включить доверие к CPU 
> RNG даже в тех дистрибутивах, где раньше ядро собиралось без такого 
> доверия. По мне, так наоборот -- это шаг в сторону решения проблемы 
> недостатка энтропии на некоторых конфигурациях и ждёт нас уже в 4.19.

Включать такое доверие ни в коем случае нельзя, по крайней мере,
если нет контроля над разработкой и производством CPU. Особенно
этого нельзя делать на Intel, т.к. там RNG (RdRandr), по видимому,
с бэкдором (умышленно ослабленный):
https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

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

On 2018-11-05 22:46:37 +0300, Andrey Savchenko wrote:

 > Дальше, по поводу тестов, которые havaged проходит, в статье
 > по ссылке выше это тоже написано: не существует тестов на
 > случайность чисел, существуют тесты на неслучайность. И
 > обмануть конкретный набор тестов не сложно. Авторы Intel RNG это
 > успешно сделали. Если кто не в теме, в более-менее современных
 > процессорах Intel есть аппаратный генератор случайных чисел,
 > который успешно проходил все тесты (на неслучайность, т.е. тесты
 > не выявляли наличия закономерностей), тем не менее, генератор
 > оказался уязвимым и, судя по всему, намеренно, как нам поведал
 > тов. Сноуден.

Намеренно - очень дорого и в 99.(9)% случаев бесполезно. Намного
вероятнее ситуация, когда попросту сделали "на отцепись", лишь бы
тесты проходил.

Я уже упоминал ChaosKey (CONFIG_USB_CHAOSKEY) и то, что пользуюсь
самопайным аналогом на AVR, но у меня практически никто особо не
интересовался, что же мне помешало банально повторить полностью
открытое решение (оно вполне кошерное: COSHER == Completely Open
Source, Hardware, Engineering and Research). Причина этого - вот:
https://altusmetrum.org/ChaosKey/v1.0/noise-source.svg (точнее,
https://assets.nexperia.com/documents/data-sheet/PMBT3904VS.pdf)
- ну не шумят транзисторы так, как стабилитроны. И пофигу, что
стабилитрону нужен LM393 или аналог (сдвоенный ОУ; половину его
пользуем как собственно усилитель, половину как компаратор): мне
нужен надежный источник энтропии.

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

К нашему большому счастью, add_device_randomness() в ядре писали
умные люди, и написали грамотно: все полученные биты энтропии
примешиваются в пул с использованием криптографически устойчивой
хеш-функции. Сейчас это SHA2-256, но drivers/char/random.c можно
поправить в любой момент, и при этом гарантированно ничего не
сломается.

Поэтому проблемы с процессорным CONFIG_HW_RANDOM_* могут вылезти
только когда это единственный источник энтропии в системе - что
очевидным образом не соответствует действительности.

 >>> Реальная проблема в том, что на обсуждаемом этапе загрузки
 >>> random ещё не нужен, но используется. Очередная глупость от
 >>> systemd.

И сам по себе systemd не нужен (вообще), но используется. Да,
очередная глупость от RH, но, как некогда сказал незабвенный
Б. Титомир, "быдло хавает".

 >> Вот с этим кто бы спорил! Только боюсь, масштаб проблемы
 >> неизвестен, он может не ограничиваться systemd.

Известен. Не ограничивается. Активно эксплуатируется (SSH оно
накрывает в полный рост). Но всем ээээ... как обычно.

 >> И главное, требуется время на ловлю блох, хотя если быстрее
 >> и проще вкорячить haveged, то "не будет у нас ничего более
 >> постоянного, чем временное"!
 > Вкорячим. А потом через пару-тройку лет будет разгромный
 > позор по наличию в Альте и только Альте уязвимости из-за
 > ненадёжного источника энтропии для криптозадач.

Будет. Причем и разгромный позор, и позорный разгром.

Это только RH может отказываться от надежной криптозащиты по
"рекомендациям" одного из давних "спонсоров" и при этом почти
не рисковать репутацией.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

On 2018-11-05 19:45:18 +0300, Leonid Krivoshein wrote:

 >>>>>> В каждом случае, как я понял, в идеале надо заменять
 >>>>>> deprecated чтение из /dev/random на системный вызов
 >>>>>> getrandom(2)
 >>>> С чего бы это /dev/random стал deprecated?
 >>> man 4 random:
 >>> The //dev/random/ interface is considered a legacy interface.
 >> Т.е. вы перевели термин legacy как deprecated?
 >> А вы знаете, что getrandom(2) появился в linux-3.17,
 >> а getrandom(3) только в glibc-2.25?
 > Знаю. По смыслу что-то сильно не так?

Да. Разница между legacy и deprecated чуть больше, чем между
пением и сопением.

 > Устаревший,

Никоим образом.

 > никто от него не отказывается,

Дур-раков нет! // (ц) попугай из анекдота

 > но лучше не использовать.

Именно его и надо использовать. Любым удобным способом.
Опционально - уже со своим (дополнительным) отбеливанием.


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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

06.11.2018 14:02, Alexey V. Vissarionov пишет:
> On 2018-11-05 19:45:18 +0300, Leonid Krivoshein wrote:
>
>   >>>>>> В каждом случае, как я понял, в идеале надо заменять
>   >>>>>> deprecated чтение из /dev/random на системный вызов
>   >>>>>> getrandom(2)
>   >>>> С чего бы это /dev/random стал deprecated?
>   >>> man 4 random:
>   >>> The //dev/random/ interface is considered a legacy interface.
>   >> Т.е. вы перевели термин legacy как deprecated?
>   >> А вы знаете, что getrandom(2) появился в linux-3.17,
>   >> а getrandom(3) только в glibc-2.25?
>   > Знаю. По смыслу что-то сильно не так?
>
> Да. Разница между legacy и deprecated чуть больше, чем между
> пением и сопением.

Legacy: Describes a feature or behavior that is being retained for 
compatibility with older applications, but which has limitations which 
make it inappropriate for developing portable applications. New 
applications should use alternative means of obtaining equivalent 
functionality.

Знаешь откуда? В контексте сказанного и подтекста RTFM не вижу разницы 
между LEAGCY и DEPRECATED, хотя конечно мы эти термины традиционно 
по-разному рассматриваем. Но если уж так хочется, пусть будет LEGACY!


>   > но лучше не использовать.
>
> Именно его и надо использовать. Любым удобным способом.
> Опционально - уже со своим (дополнительным) отбеливанием.

RTFM гласит иначе, без оглядки на переносимость. Наверное, это 
неправильный RTFM! :)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Sergey Y. Afonin]

On Saturday 03 November 2018, Denis Medvedev wrote:

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

Мне как-то посоветовали rng-tools
https://lists.altlinux.org/pipermail/sysadmins/2008-May/026104.html

-- 
С уважением, Сергей Афонин

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Wed, 7 Nov 2018 01:00:36 +0400 Sergey Y. Afonin wrote:
> On Saturday 03 November 2018, Denis Medvedev wrote:
> 
> > А если энтропии мало, может ее добавить естественным образом?
> 
> Мне как-то посоветовали rng-tools
> https://lists.altlinux.org/pipermail/sysadmins/2008-May/026104.html

Без аппаратных генераторов случайных чисел данный пакет бесполезен. 

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Sergey Y. Afonin]

On Wednesday 07 November 2018, Andrey Savchenko wrote:

> > Мне как-то посоветовали rng-tools
> > https://lists.altlinux.org/pipermail/sysadmins/2008-May/026104.html
> 
> Без аппаратных генераторов случайных чисел данный пакет бесполезен. 

Несовсем. В sysconfig/rngd есть пример:

# Set to the input source for pseudo random data if hardware is absent
#HRNGDEVICE=/dev/urandom

-- 
С уважением, Сергей Афонин

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Wed, 7 Nov 2018 02:10:52 +0400 Sergey Y. Afonin wrote:
> On Wednesday 07 November 2018, Andrey Savchenko wrote:
> 
> > > Мне как-то посоветовали rng-tools
> > > https://lists.altlinux.org/pipermail/sysadmins/2008-May/026104.html
> > 
> > Без аппаратных генераторов случайных чисел данный пакет бесполезен. 
> 
> Несовсем. В sysconfig/rngd есть пример:
> 
> # Set to the input source for pseudo random data if hardware is absent
> #HRNGDEVICE=/dev/urandom

Если Вы предлагаете использовать /dev/urandom в качестве источника
энтропии, идущей в /dev/random, который затем используется для
инициализации libgcrypt, ключей и т.п., то я советую Вам не
заниматься вопросами, связанными с криптографией.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Sergey Y. Afonin]

On Wednesday 07 November 2018, Andrey Savchenko wrote:

> Если Вы предлагаете использовать /dev/urandom в качестве источника
> энтропии, идущей в /dev/random, который затем используется для
 
Он используется, когда в /dev/random не хватает. Что уже не определено.

-- 
С уважением, Сергей Афонин

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Wed, 7 Nov 2018 02:17:28 +0400 Sergey Y. Afonin wrote:
> On Wednesday 07 November 2018, Andrey Savchenko wrote:
> 
> > Если Вы предлагаете использовать /dev/urandom в качестве источника
> > энтропии, идущей в /dev/random, который затем используется для
>  
> Он используется, когда в /dev/random не хватает. Что уже не определено.

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

Кроме того, процедура опустошения /dev/random легко управляема из
вне, так что форсировать использование urandom легко. На ранних
этапах старта системы это будет само собой, т.к. энтропия ещё не
набрана.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Dmitry V. Levin]

On Wed, Nov 07, 2018 at 02:17:28AM +0400, Sergey Y. Afonin wrote:
> On Wednesday 07 November 2018, Andrey Savchenko wrote:
> 
> > Если Вы предлагаете использовать /dev/urandom в качестве источника
> > энтропии, идущей в /dev/random, который затем используется для
>  
> Он используется, когда в /dev/random не хватает. Что уже не определено.

Как же здорово, что вы не мантейните ничего такого, что связано с криптографией.


-- 
ldv

Re: [devel] [sisyphus] Не переключается в графический режим

[Sergey Afonin]

On Wednesday 07 November 2018, Dmitry V. Levin wrote:

> > > Если Вы предлагаете использовать /dev/urandom в качестве источника
> > > энтропии, идущей в /dev/random, который затем используется для
> >  
> > Он используется, когда в /dev/random не хватает. Что уже не определено.
> 
> Как же здорово, что вы не мантейните ничего такого, что связано с
> криптографией. 

Надо чётко представлять, когда случайность последовательности действительно
важна, а не оперировать выражениями "как же хорошо".

-- 
С уважением, Сергей Афонин.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Wed, 7 Nov 2018 09:42:00 +0400 Sergey Afonin wrote:
> On Wednesday 07 November 2018, Dmitry V. Levin wrote:
> 
> > > > Если Вы предлагаете использовать /dev/urandom в качестве источника
> > > > энтропии, идущей в /dev/random, который затем используется для
> > >  
> > > Он используется, когда в /dev/random не хватает. Что уже не определено.
> > 
> > Как же здорово, что вы не мантейните ничего такого, что связано с
> > криптографией. 
> 
> Надо чётко представлять, когда случайность последовательности действительно
> важна, а не оперировать выражениями "как же хорошо".

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

Для начала рекомендую почитать Applied Cryptography by Bruce
Schneier, разделы:
2.8 Random and Pseudo-Random-Sequence Generation.
17.14 Real Random-Sequence Generators

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

07.11.2018 16:12, Andrey Savchenko пишет:
> Вот именно. Нужно понимать, что такое случайные числа, чем они
> отличаются от псевдослучайных, что такое энтропия данных и как это
> всё используется в криптографии. Пока что Вы пишете полную чушь,
> демонстрирующую отсутствие понимания темы обсуждения.

Андрей, Алексей, Дмитрий, не могу с вами согласиться по некоторым 
вопросам. Изучив тему более глубоко, могу теперь быть докладчиком на 
следующей конференции! :) Если серьёзно, в споре рождается ИСТИНА. Почти 
одновременно с нашей дискуссией родился следующий талмуд от коллеги по 
FLOSS: https://www.2uo.de/myths-about-urandom -- мнение там 
высказывается противоположное вашему, даются важные замечания 
относительно оценки размера энтропийного пула (!!!) и новшеств в этой 
связи в ядре 4.8, приводятся мнения некоторых криптологов. Тебе, Андрей, 
будет особо интересно узнать, для чего там используется полиномная 
математика. ;-)


> Для начала рекомендую почитать Applied Cryptography by Bruce
> Schneier, разделы:
> 2.8 Random and Pseudo-Random-Sequence Generation.
> 17.14 Real Random-Sequence Generators

Вот не стоило здесь это приводить, оно совершенно "ни о чём", чесслово! 
Чтобы это понять, придётся прочитать про "мифы" от и до -- там это 
разбивается в пух и прах.

К приведённой тобой статье 2012 года было куда больше интересных 
комментариев относительно "природы истинной случайности", сама статья 
затрагивала haveged постольку-поскольку. Там же автор активно продвигал 
rngd -- другой юзерспейсный демон. А наша бурная дискуссия по следам 
этих дебатов подвела следующие итоги:

1. haveged в чём-то аналогичен /dev/urandom, он генерирует 
"случайность", выполняя функцию аналогичную ядру.
2. единственная претензия к haveged и /dev/urandom в том, что на выходе 
получается больше бит, чем на входе.
3. не надо использовать ни haveged, ни rngd в дистрибутивах Альт, чтобы 
не подрывать себе репутацию.
4. надо находить и устранять причины раннего опустошения энтропии, 
приводящие к блокировкам.
5. желательно всем обзавестись такими энтропийными ключиками, как у 
Алексея! :)

Ничего не упустил?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Paul Wolneykien]

07.11.2018 21:38, Leonid Krivoshein пишет:
> 4. надо находить и устранять причины раннего опустошения энтропии,
> приводящие к блокировкам.

  Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
железе, поскольку для загрузки внезапно понадобились случайные числа?

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

On 2018-11-07 22:41:08 +0300, Paul Wolneykien wrote:

 >> 4. надо находить и устранять причины раннего опустошения
 >> энтропии, приводящие к блокировкам.
 > Я правильно понимаю, что скоро ОС перестанет загружаться на
 > обычном железе, поскольку для загрузки внезапно понадобились
 > случайные числа?

Они уже сейчас нужны (например, для KASLR), но на это энтропии
гарантированно хватит.


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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

07.11.2018 22:41, Paul Wolneykien пишет:
> 07.11.2018 21:38, Leonid Krivoshein пишет:
>> 4. надо находить и устранять причины раннего опустошения энтропии,
>> приводящие к блокировкам.
>    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> железе, поскольку для загрузки внезапно понадобились случайные числа?

Пока что поймать железо (в отладочных целях), где подобное проявляется 
именно с дистрибутивами Альт, нам удалось лишь единожды. По ссылкам из 
этого обсуждения видно, что проблема есть на новых ядрах в других 
дистрибутивах, так что может быть до нас просто ещё эхо не докатилось. И 
видно, что глобального решения пока не предложено. Частным порядком все 
обходятся вкорячиванием haveged/rngd, но как мы уже определились, этого 
делать не надо. Раз так, мы должны предложить альтернативу, и что-то 
подсказывает, что RND-ключик, как у Алексея, в качестве такой 
альтернативы подойдёт далеко не всем. И не просто предложить, а сделать 
автоматически применяемым в дистрибутивах решением, чтобы не было 
блокировок на старте, даже в очень редких случаях.

Однако тема имеет много практических целей. Одной уже достигли, 
определившись с haveged и rngd. Предлагаю ещё вспомнить назначение файла 
и одноимённой службы: 
https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html 
. Тут ещё выяснилось, что для улучшения безопасности systemd не просто 
так собирается с libgcrypt -- он может использовать случайные числа для 
цифровой подписи каждой записи журнала. Отсюда столько интересных 
патчей, связанных с FIPS, портированных в свободную FC из RHEL. Полагаю, 
цель на раннем старте задействовать по-возможности более кошерный 
getrandom(2), на случай доступности "более естественной случайности". Но 
вот что я сейчас вижу в сизифном логе:


[    5.112227] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
+PCRE2 default-hierarchy=hybrid)
[    5.124337] systemd[1]: Detected architecture x86-64.
[    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
[    5.223456] systemd[1]: Listening on Journal Audit Socket.
[    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
[    5.223592] systemd[1]: Listening on udev Control Socket.
[    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
...
[   32.283736] random: crng init done
[   32.283746] random: 7 urandom warning(s) missed due to ratelimiting


То есть, на самом раннем старте (большая часть железа здесь 
инициализируется за 5-й секундой!) журнал systemd уже нужен, но даже для 
его инициализации средствами кошерного /dev/urandom нет энтропии либо 
почему-то (!) он к этому времени всё ещё не проинициализирован. То есть, 
по логике Андрея, мы на сертифицировнных дистрах при большом желании 
сможем подделывать записи (подменять журнал) systemd, верно? Для 
гражданских-то не столь актуально. 384-бит на 5-й секунде -- не жирно так?


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Thu, 8 Nov 2018 01:19:27 +0300 Leonid Krivoshein wrote:
> 
> 07.11.2018 22:41, Paul Wolneykien пишет:
> > 07.11.2018 21:38, Leonid Krivoshein пишет:
> >> 4. надо находить и устранять причины раннего опустошения энтропии,
> >> приводящие к блокировкам.
> >    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> > железе, поскольку для загрузки внезапно понадобились случайные числа?
> 
> Пока что поймать железо (в отладочных целях), где подобное проявляется 
> именно с дистрибутивами Альт, нам удалось лишь единожды. По ссылкам из 
> этого обсуждения видно, что проблема есть на новых ядрах в других 
> дистрибутивах, так что может быть до нас просто ещё эхо не докатилось. И 
> видно, что глобального решения пока не предложено. Частным порядком все 
> обходятся вкорячиванием haveged/rngd, но как мы уже определились, этого 
> делать не надо. Раз так, мы должны предложить альтернативу, и что-то 
> подсказывает, что RND-ключик, как у Алексея, в качестве такой 
> альтернативы подойдёт далеко не всем. И не просто предложить, а сделать 
> автоматически применяемым в дистрибутивах решением, чтобы не было 
> блокировок на старте, даже в очень редких случаях.
> 
> Однако тема имеет много практических целей. Одной уже достигли, 
> определившись с haveged и rngd. Предлагаю ещё вспомнить назначение файла 
> и одноимённой службы: 
> https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html 
> . Тут ещё выяснилось, что для улучшения безопасности systemd не просто 
> так собирается с libgcrypt -- он может использовать случайные числа для 
> цифровой подписи каждой записи журнала. Отсюда столько интересных 
> патчей, связанных с FIPS, портированных в свободную FC из RHEL. Полагаю, 
> цель на раннем старте задействовать по-возможности более кошерный 
> getrandom(2), на случай доступности "более естественной случайности". Но 
> вот что я сейчас вижу в сизифном логе:
> 
> 
> [    5.112227] systemd[1]: systemd 239 running in system mode. (+PAM 
> +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
> +PCRE2 default-hierarchy=hybrid)
> [    5.124337] systemd[1]: Detected architecture x86-64.
> [    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
> [    5.223456] systemd[1]: Listening on Journal Audit Socket.
> [    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
> [    5.223592] systemd[1]: Listening on udev Control Socket.
> [    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
> ...
> [   32.283736] random: crng init done
> [   32.283746] random: 7 urandom warning(s) missed due to ratelimiting
> 
> 
> То есть, на самом раннем старте (большая часть железа здесь 
> инициализируется за 5-й секундой!) журнал systemd уже нужен, но даже для 
> его инициализации средствами кошерного /dev/urandom нет энтропии либо 
> почему-то (!) он к этому времени всё ещё не проинициализирован. То есть, 
> по логике Андрея, мы на сертифицировнных дистрах при большом желании 
> сможем подделывать записи (подменять журнал) systemd, верно? Для 
> гражданских-то не столь актуально. 384-бит на 5-й секунде -- не жирно так?

Суть последних изменений в ядре в том, что urandom теперь тоже
может блокироваться, пока не набрана энтропия для первичного
наполнения пула. Я всячески приветствую это изменение, т.к. оно
защищает от генерации слабых ключей, на которые есть реально
осуществляемая атака. Есть научное исследование и публикация на эту
тему:
https://factorable.net/paper.html
https://factorable.net/weakkeys12.extended.pdf

В статье рассказывается как недостаточно случайные числа можно
использовать для атаки на RSA и DSA полученные с их использованием
и проводится общемировой анализ и статистика использования подобных
ключей.

Советую почитать разделы 5.1 Weak entropy and the Linux RNG
и 6.2 /dev/(u)random as a usability failure. Да, начиная с 4.17 это
должно быть исправлено в ядрах, но сколько ещё всплывёт проблем?
Для долгосрочных ключей пригоден только /dev/random: см. раздел 7
Defenses and Lessons.

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

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
> 07.11.2018 21:38, Leonid Krivoshein пишет:
> > 4. надо находить и устранять причины раннего опустошения энтропии,
> > приводящие к блокировкам.
> 
>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> железе, поскольку для загрузки внезапно понадобились случайные числа?

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

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

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Denis Medvedev]

On 11/08/2018 07:33 PM, Andrey Savchenko wrote:
> On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
>> 07.11.2018 21:38, Leonid Krivoshein пишет:
>>> 4. надо находить и устранять причины раннего опустошения энтропии,
>>> приводящие к блокировкам.
>>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
>> железе, поскольку для загрузки внезапно понадобились случайные числа?
> Не совсем так. Случайные числа нужны были всегда, просто сейчас
> исправили баг с выдачей предсказуемых чисел вместо случайных, что
> ранее имело место при недостаточной энтропии в начале загрузки.
>
> ОС как грузилась, так и будет грузится. Просто некоторым
> пользователям systemd придётся подождать. Ирония в том, что systemd
> породил проблему долгой загрузки для решения которой изначально
> создавался.
Может пользователям десктопных систем показать на экране в это время
какой-нибудь тетрис для развлечения и поднятия энтропии?
> Best regards,
> Andrew Savchenko
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Wed, 7 Nov 2018 21:38:20 +0300 Leonid Krivoshein wrote:
> 
> 07.11.2018 16:12, Andrey Savchenko пишет:
> > Вот именно. Нужно понимать, что такое случайные числа, чем они
> > отличаются от псевдослучайных, что такое энтропия данных и как это
> > всё используется в криптографии. Пока что Вы пишете полную чушь,
> > демонстрирующую отсутствие понимания темы обсуждения.
> 
> Андрей, Алексей, Дмитрий, не могу с вами согласиться по некоторым 
> вопросам. Изучив тему более глубоко, могу теперь быть докладчиком на 
> следующей конференции! :) Если серьёзно, в споре рождается ИСТИНА. Почти 
> одновременно с нашей дискуссией родился следующий талмуд от коллеги по 
> FLOSS: https://www.2uo.de/myths-about-urandom -- мнение там 
> высказывается противоположное вашему, даются важные замечания 
> относительно оценки размера энтропийного пула (!!!) и новшеств в этой 
> связи в ядре 4.8, приводятся мнения некоторых криптологов. Тебе, Андрей, 
> будет особо интересно узнать, для чего там используется полиномная 
> математика. ;-)

Вот именно, там *мнение*, а не научная статья или монография
известного эксперта. Я же ссылаю на публикации и книги, прошедшие
рецензирование и проверку временем.

Я прочитал таки мнение по твоей ссылке. В ней очень много громких
фраз и очень мало фактов. Весь первый раздел "вопрос – ответ" не
имеет ссылок на рецензируемые источники.

Впрочем, во многом автор прав, он вполне корректно приводит
упрощённую схему получения выхлопов (u)random. Главная проблема вот
в чём: он игнорирует факт изменения энтропии пула, считая его не
относящимся к делу (и без аргументации этого):

What about entropy running low?
It doesn't matter. 

Единственный недостаток /dev/random в том, что он работает в
блокирующем режиме, а urandom — в неблокирующем. Начиная с 4.17 это
исправили (CVE-2018-1108, ты сам приводил). Теперь urandom тоже
может быть блокирован при нехватке исходной энтропии. По-моему, на
это вы и напоролись.

Рекомендую также ознакомиться вот с этой работой (уже писал):
https://factorable.net/weakkeys12.extended.pdf

Даже в указанной тобой работе автор пишет о необходимости
сохранения пула энтропии при завершении работы и его загрузке при
запуске:

On Linux it isn't too bad, because Linux distributions save some
random numbers when booting up the system (but after they have
gathered some entropy, since the startup script doesn't run
immediately after switching on the machine) into a seed file that
is read next time the machine is booting. So you carry over the
randomness from the last running of the machine. 

А теперь представим, что питание внезапно отключилось. Даже у нас в
офисе это не редкость, а ИБП не у всех. Получится, что при
следующей загрузке будет использоваться старый пул. А это не
безопасно, очень, т.к. произойдёт повторное использование одной и
той же "неповторяемой" последовательности.

Шутки со случайностью плохи и стоят дорого. Недаром АНБ засунуло
бэкдор прямо в RNG: Dual_EC_DRBG:
https://en.wikipedia.org/wiki/Dual_EC_DRBG#Weakness:_a_potential_backdoor

> > Для начала рекомендую почитать Applied Cryptography by Bruce
> > Schneier, разделы:
> > 2.8 Random and Pseudo-Random-Sequence Generation.
> > 17.14 Real Random-Sequence Generators
> 
> Вот не стоило здесь это приводить, оно совершенно "ни о чём", чесслово! 

Шнайер и не о чём? Ты уверен? Это один из лучших криптографов мира,
работающий в открытую. Да, первое издание его "Прикладной
криптографии" вышло ещё в 1996 году (и одна конторка очень бесилась
по этому поводу) и не потеряло своей актуальности.

> Чтобы это понять, придётся прочитать про "мифы" от и до -- там это 
> разбивается в пух и прах.

Прочитал. Не нашёл, где разбивается. Там одни крики и никакой
математики. Из фактов есть только одна ссылка на Бернштейна,
которая выкручивается наоборот.

> К приведённой тобой статье 2012 года было куда больше интересных 
> комментариев относительно "природы истинной случайности", сама статья 
> затрагивала haveged постольку-поскольку. Там же автор активно продвигал 
> rngd -- другой юзерспейсный демон. А наша бурная дискуссия по следам 
> этих дебатов подвела следующие итоги:
> 
> 1. haveged в чём-то аналогичен /dev/urandom, он генерирует 
> "случайность", выполняя функцию аналогичную ядру.

Согласен.

> 2. единственная претензия к haveged и /dev/urandom в том, что на выходе 
> получается больше бит, чем на входе.

Да. И этого достаточно, чтоб ни для чего важного его не
использовать. Если долгосрочная защита не нужна, то можно и urandom
использовать, но она может быть нужна. Мы априори не знаем, что
будет делать пользователь, поэтому подставляться нельзя.

> 3. не надо использовать ни haveged, ни rngd в дистрибутивах Альт, чтобы 
> не подрывать себе репутацию.

Да.

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

Думаю, дело не в раннем опустошении, а в раннем ненаполнении. На
бездисковых тонких клиентах это очень даже возможно.

> 5. желательно всем обзавестись такими энтропийными ключиками, как у 
> Алексея! :)

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

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Thu, 8 Nov 2018 19:35:54 +0300 Denis Medvedev wrote:
> 
> 
> On 11/08/2018 07:33 PM, Andrey Savchenko wrote:
> > On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
> >> 07.11.2018 21:38, Leonid Krivoshein пишет:
> >>> 4. надо находить и устранять причины раннего опустошения энтропии,
> >>> приводящие к блокировкам.
> >>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> >> железе, поскольку для загрузки внезапно понадобились случайные числа?
> > Не совсем так. Случайные числа нужны были всегда, просто сейчас
> > исправили баг с выдачей предсказуемых чисел вместо случайных, что
> > ранее имело место при недостаточной энтропии в начале загрузки.
> >
> > ОС как грузилась, так и будет грузится. Просто некоторым
> > пользователям systemd придётся подождать. Ирония в том, что systemd
> > породил проблему долгой загрузки для решения которой изначально
> > создавался.
> Может пользователям десктопных систем показать на экране в это время
> какой-нибудь тетрис для развлечения и поднятия энтропии?

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

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Denis Medvedev]

On четверг, 8 ноября 2018 г. 20:15:23 MSK Andrey 
Savchenko wrote:
> On Thu, 8 Nov 2018 19:35:54 +0300 Denis Medvedev 
wrote:
> 
> > 
> > 
> > On 11/08/2018 07:33 PM, Andrey Savchenko wrote:
> > 
> > > On Wed, 7 Nov 2018 22:41:08 +0300 Paul 
Wolneykien wrote:
> > > 
> > >> 07.11.2018 21:38, Leonid Krivoshein пишет:
> > >> 
> > >>> 4. надо находить и устранять причины 
раннего опустошения энтропии,
> > >>> приводящие к блокировкам.
> > >>> 
> > >>   Я правильно понимаю, что скоро ОС 
перестанет загружаться на обычном
> > >> 
> > >> железе, поскольку для загрузки внезапно 
понадобились случайные числа?
> > > 
> > > Не совсем так. Случайные числа нужны были 
всегда, просто сейчас
> > > исправили баг с выдачей предсказуемых чисел 
вместо случайных, что
> > > ранее имело место при недостаточной энтропии в 
начале загрузки.
> > >
> > >
> > >
> > > ОС как грузилась, так и будет грузится. Просто 
некоторым
> > > пользователям systemd придётся подождать. 
Ирония в том, что systemd
> > > породил проблему долгой загрузки для решения 
которой изначально
> > > создавался.
> > 
> > Может пользователям десктопных систем показать 
на экране в это время
> > какой-нибудь тетрис для развлечения и поднятия 
энтропии?
> 
> 
> Идея хорошая, но, как я понял, задержка возникает 
до инициализации
> графики. Теоретически можно вкорячить в консоли 
или фреймбуфере,
> но, думаю, это будет слишком сложно и плохо 
переносимо между разными
> системами.
Текстовые "тараканьи бега"?
(несколько прогрессбаров из * & и + на одной линии 
псевдографикой или "=" которые можно мышкой/
клавиатурой "подбадривать",смотря за кого ты 
"болеешь")?

> 
> Best regards,
> Andrew Savchenko

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Thu, 8 Nov 2018 18:58:34 +0300 Andrey Savchenko wrote:
> On Thu, 8 Nov 2018 01:19:27 +0300 Leonid Krivoshein wrote:
> > 
> > 07.11.2018 22:41, Paul Wolneykien пишет:
> > > 07.11.2018 21:38, Leonid Krivoshein пишет:
> > >> 4. надо находить и устранять причины раннего опустошения энтропии,
> > >> приводящие к блокировкам.
> > >    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> > > железе, поскольку для загрузки внезапно понадобились случайные числа?
> > 
> > Пока что поймать железо (в отладочных целях), где подобное проявляется 
> > именно с дистрибутивами Альт, нам удалось лишь единожды. По ссылкам из 
> > этого обсуждения видно, что проблема есть на новых ядрах в других 
> > дистрибутивах, так что может быть до нас просто ещё эхо не докатилось. И 
> > видно, что глобального решения пока не предложено. Частным порядком все 
> > обходятся вкорячиванием haveged/rngd, но как мы уже определились, этого 
> > делать не надо. Раз так, мы должны предложить альтернативу, и что-то 
> > подсказывает, что RND-ключик, как у Алексея, в качестве такой 
> > альтернативы подойдёт далеко не всем. И не просто предложить, а сделать 
> > автоматически применяемым в дистрибутивах решением, чтобы не было 
> > блокировок на старте, даже в очень редких случаях.
> > 
> > Однако тема имеет много практических целей. Одной уже достигли, 
> > определившись с haveged и rngd. Предлагаю ещё вспомнить назначение файла 
> > и одноимённой службы: 
> > https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html 
> > . Тут ещё выяснилось, что для улучшения безопасности systemd не просто 
> > так собирается с libgcrypt -- он может использовать случайные числа для 
> > цифровой подписи каждой записи журнала. Отсюда столько интересных 
> > патчей, связанных с FIPS, портированных в свободную FC из RHEL. Полагаю, 
> > цель на раннем старте задействовать по-возможности более кошерный 
> > getrandom(2), на случай доступности "более естественной случайности". Но 
> > вот что я сейчас вижу в сизифном логе:
> > 
> > 
> > [    5.112227] systemd[1]: systemd 239 running in system mode. (+PAM 
> > +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> > +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
> > +PCRE2 default-hierarchy=hybrid)
> > [    5.124337] systemd[1]: Detected architecture x86-64.
> > [    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
> > [    5.223456] systemd[1]: Listening on Journal Audit Socket.
> > [    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
> > [    5.223592] systemd[1]: Listening on udev Control Socket.
> > [    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
> > ...
> > [   32.283736] random: crng init done
> > [   32.283746] random: 7 urandom warning(s) missed due to ratelimiting
> > 
> > 
> > То есть, на самом раннем старте (большая часть железа здесь 
> > инициализируется за 5-й секундой!) журнал systemd уже нужен, но даже для 
> > его инициализации средствами кошерного /dev/urandom нет энтропии либо 
> > почему-то (!) он к этому времени всё ещё не проинициализирован. То есть, 
> > по логике Андрея, мы на сертифицировнных дистрах при большом желании 
> > сможем подделывать записи (подменять журнал) systemd, верно? Для 
> > гражданских-то не столь актуально. 384-бит на 5-й секунде -- не жирно так?
> 
> Суть последних изменений в ядре в том, что urandom теперь тоже
> может блокироваться, пока не набрана энтропия для первичного
> наполнения пула. Я всячески приветствую это изменение, т.к. оно
> защищает от генерации слабых ключей, на которые есть реально
> осуществляемая атака. Есть научное исследование и публикация на эту
> тему:
> https://factorable.net/paper.html
> https://factorable.net/weakkeys12.extended.pdf
> 
> В статье рассказывается как недостаточно случайные числа можно
> использовать для атаки на RSA и DSA полученные с их использованием
> и проводится общемировой анализ и статистика использования подобных
> ключей.
> 
> Советую почитать разделы 5.1 Weak entropy and the Linux RNG
> и 6.2 /dev/(u)random as a usability failure. Да, начиная с 4.17 это
> должно быть исправлено в ядрах, но сколько ещё всплывёт проблем?
> Для долгосрочных ключей пригоден только /dev/random: см. раздел 7
> Defenses and Lessons.
> 
> Да, заметь, что это научная статья со всеми надлежащими ссылками на
> литературы и рецензированием, а не рандомная публикация в инете.

Кстати, а на проблемных системах /etc/init.d/random (или
аналогичный unit-файл для systemd) стартует? По идее, он должен
дать достаточно энтропии для запуска системы (если это не загрузка
заранее подготовленного образа по сети, конечно). Ещё нужно следить
за тем, чтоб файл /var/run/random-seed существовал, а то есть
любители /var/run в tmpfs класть (в таком случае файлик нужно
переложить в другое место).

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

08.11.2018 22:22, Andrey Savchenko пишет:
> On Thu, 8 Nov 2018 18:58:34 +0300 Andrey Savchenko wrote:
>> On Thu, 8 Nov 2018 01:19:27 +0300 Leonid Krivoshein wrote:
>>> 07.11.2018 22:41, Paul Wolneykien пишет:
>>>> 07.11.2018 21:38, Leonid Krivoshein пишет:
>>>>> 4. надо находить и устранять причины раннего опустошения энтропии,
>>>>> приводящие к блокировкам.
>>>>     Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
>>>> железе, поскольку для загрузки внезапно понадобились случайные числа?
>>> [...]
>>> Предлагаю ещё вспомнить назначение файла и одноимённой службы:
>>> https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html
>>> [...]
>> [...]
> Кстати, а на проблемных системах /etc/init.d/random (или
> аналогичный unit-файл для systemd) стартует? По идее, он должен
> дать достаточно энтропии для запуска системы (если это не загрузка
> заранее подготовленного образа по сети, конечно). Ещё нужно следить
> за тем, чтоб файл /var/run/random-seed существовал, а то есть
> любители /var/run в tmpfs класть (в таком случае файлик нужно
> переложить в другое место).

Вот и вспомнили! Ага, именно такое у него предназначение было изначально 
и традиционно перекочевало в systemd из sysvinit, но как-то 
кривоватенько получилось: юниты стартуют после инициализации systemd, 
systemd-random-seed -- одна из таких служб, только мы видим, что systemd 
берёт данные из неинициализрованного /dev/urandom ещё на этапе своей 
инцициализации... неувязочка!


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey Shabalin]

пт, 9 нояб. 2018 г. в 1:29, Leonid Krivoshein <klark.devel@gmail.com>:
>
>
> 08.11.2018 22:22, Andrey Savchenko пишет:
> > On Thu, 8 Nov 2018 18:58:34 +0300 Andrey Savchenko wrote:
> >> On Thu, 8 Nov 2018 01:19:27 +0300 Leonid Krivoshein wrote:
> >>> 07.11.2018 22:41, Paul Wolneykien пишет:
> >>>> 07.11.2018 21:38, Leonid Krivoshein пишет:
> >>>>> 4. надо находить и устранять причины раннего опустошения энтропии,
> >>>>> приводящие к блокировкам.
> >>>>     Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> >>>> железе, поскольку для загрузки внезапно понадобились случайные числа?
> >>> [...]
> >>> Предлагаю ещё вспомнить назначение файла и одноимённой службы:
> >>> https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html
> >>> [...]
> >> [...]
> > Кстати, а на проблемных системах /etc/init.d/random (или
> > аналогичный unit-файл для systemd) стартует? По идее, он должен
> > дать достаточно энтропии для запуска системы (если это не загрузка
> > заранее подготовленного образа по сети, конечно). Ещё нужно следить
> > за тем, чтоб файл /var/run/random-seed существовал, а то есть
> > любители /var/run в tmpfs класть (в таком случае файлик нужно
> > переложить в другое место).
>
> Вот и вспомнили! Ага, именно такое у него предназначение было изначально
> и традиционно перекочевало в systemd из sysvinit, но как-то
> кривоватенько получилось: юниты стартуют после инициализации systemd,
> systemd-random-seed -- одна из таких служб, только мы видим, что systemd
> берёт данные из неинициализрованного /dev/urandom ещё на этапе своей
> инцициализации... неувязочка!
>

Брррр. Вы о чем? как можно стартануть юнит не запустив systemd.
Ложитесь спать уже.

-- 
Alexey Shabalin

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey Shabalin]

чт, 8 нояб. 2018 г. в 22:22, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Thu, 8 Nov 2018 18:58:34 +0300 Andrey Savchenko wrote:
> > On Thu, 8 Nov 2018 01:19:27 +0300 Leonid Krivoshein wrote:
> > >
> > > 07.11.2018 22:41, Paul Wolneykien пишет:
> > > > 07.11.2018 21:38, Leonid Krivoshein пишет:
> > > >> 4. надо находить и устранять причины раннего опустошения энтропии,
> > > >> приводящие к блокировкам.
> > > >    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> > > > железе, поскольку для загрузки внезапно понадобились случайные числа?
> > >
> > > Пока что поймать железо (в отладочных целях), где подобное проявляется
> > > именно с дистрибутивами Альт, нам удалось лишь единожды. По ссылкам из
> > > этого обсуждения видно, что проблема есть на новых ядрах в других
> > > дистрибутивах, так что может быть до нас просто ещё эхо не докатилось. И
> > > видно, что глобального решения пока не предложено. Частным порядком все
> > > обходятся вкорячиванием haveged/rngd, но как мы уже определились, этого
> > > делать не надо. Раз так, мы должны предложить альтернативу, и что-то
> > > подсказывает, что RND-ключик, как у Алексея, в качестве такой
> > > альтернативы подойдёт далеко не всем. И не просто предложить, а сделать
> > > автоматически применяемым в дистрибутивах решением, чтобы не было
> > > блокировок на старте, даже в очень редких случаях.
> > >
> > > Однако тема имеет много практических целей. Одной уже достигли,
> > > определившись с haveged и rngd. Предлагаю ещё вспомнить назначение файла
> > > и одноимённой службы:
> > > https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html
> > > . Тут ещё выяснилось, что для улучшения безопасности systemd не просто
> > > так собирается с libgcrypt -- он может использовать случайные числа для
> > > цифровой подписи каждой записи журнала. Отсюда столько интересных
> > > патчей, связанных с FIPS, портированных в свободную FC из RHEL. Полагаю,
> > > цель на раннем старте задействовать по-возможности более кошерный
> > > getrandom(2), на случай доступности "более естественной случайности". Но
> > > вот что я сейчас вижу в сизифном логе:
> > >
> > >
> > > [    5.112227] systemd[1]: systemd 239 running in system mode. (+PAM
> > > +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> > > +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN
> > > +PCRE2 default-hierarchy=hybrid)
> > > [    5.124337] systemd[1]: Detected architecture x86-64.
> > > [    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
> > > [    5.223456] systemd[1]: Listening on Journal Audit Socket.
> > > [    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
> > > [    5.223592] systemd[1]: Listening on udev Control Socket.
> > > [    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
> > > ...
> > > [   32.283736] random: crng init done
> > > [   32.283746] random: 7 urandom warning(s) missed due to ratelimiting
> > >
> > >
> > > То есть, на самом раннем старте (большая часть железа здесь
> > > инициализируется за 5-й секундой!) журнал systemd уже нужен, но даже для
> > > его инициализации средствами кошерного /dev/urandom нет энтропии либо
> > > почему-то (!) он к этому времени всё ещё не проинициализирован. То есть,
> > > по логике Андрея, мы на сертифицировнных дистрах при большом желании
> > > сможем подделывать записи (подменять журнал) systemd, верно? Для
> > > гражданских-то не столь актуально. 384-бит на 5-й секунде -- не жирно так?
> >
> > Суть последних изменений в ядре в том, что urandom теперь тоже
> > может блокироваться, пока не набрана энтропия для первичного
> > наполнения пула. Я всячески приветствую это изменение, т.к. оно
> > защищает от генерации слабых ключей, на которые есть реально
> > осуществляемая атака. Есть научное исследование и публикация на эту
> > тему:
> > https://factorable.net/paper.html
> > https://factorable.net/weakkeys12.extended.pdf
> >
> > В статье рассказывается как недостаточно случайные числа можно
> > использовать для атаки на RSA и DSA полученные с их использованием
> > и проводится общемировой анализ и статистика использования подобных
> > ключей.
> >
> > Советую почитать разделы 5.1 Weak entropy and the Linux RNG
> > и 6.2 /dev/(u)random as a usability failure. Да, начиная с 4.17 это
> > должно быть исправлено в ядрах, но сколько ещё всплывёт проблем?
> > Для долгосрочных ключей пригоден только /dev/random: см. раздел 7
> > Defenses and Lessons.
> >
> > Да, заметь, что это научная статья со всеми надлежащими ссылками на
> > литературы и рецензированием, а не рандомная публикация в инете.
>
> Кстати, а на проблемных системах /etc/init.d/random (или
> аналогичный unit-файл для systemd) стартует? По идее, он должен
> дать достаточно энтропии для запуска системы (если это не загрузка
> заранее подготовленного образа по сети, конечно). Ещё нужно следить
> за тем, чтоб файл /var/run/random-seed существовал, а то есть
> любители /var/run в tmpfs класть (в таком случае файлик нужно
> переложить в другое место).

Пакет startup с измененным местоположением (на
/var/lib/random/random-seed) ждёт апрува.

-- 
Alexey Shabalin

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

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

On 2018-11-08 22:22:36 +0300, Andrey Savchenko wrote:

 > Кстати, а на проблемных системах /etc/init.d/random (или
 > аналогичный unit-файл для systemd) стартует? По идее, он
 > должен дать достаточно энтропии для запуска системы (если
 > это не загрузка заранее подготовленного образа по сети,
 > конечно).

Вот как раз с сетевой загрузкой все хорошо: там столько внешних
факторов, что пул энтропии наполняется чуть быстрее, чем сразу.

 > Ещё нужно следить за тем, чтоб файл /var/run/random-seed
 > существовал, а то есть любители /var/run в tmpfs класть
 > (в таком случае файлик нужно переложить в другое место).

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


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

08.11.2018 20:15, Andrey Savchenko пишет:
> On Thu, 8 Nov 2018 19:35:54 +0300 Denis Medvedev wrote:
>> Может пользователям десктопных систем показать на экране в это время
>> какой-нибудь тетрис для развлечения и поднятия энтропии?
> Идея хорошая, но, как я понял, задержка возникает до инициализации
> графики. Теоретически можно вкорячить в консоли или фреймбуфере,
> но, думаю, это будет слишком сложно и плохо переносимо между разными
> системами.

Не все к этому отнесутся серьёзно, не всем нравятся игрушки. К тому же 
любая значимая задержка на старте -- та же уязвимость, потому что 
пользователи начинают устранять препятствие любой ценой, хоть тем же 
haveged/rngd, благо других советов в сети не водится.

Вообще странно. Когда для военных или других особых применений делается 
дистрибутив, такие "навороты" с безопасностью понять ещё можно. Но для 
всех поголовно гражданских применений стоит ли так круто гайки 
завинчивать, да ещё и таким образом, что это будет просто отпугивать людей?

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


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

09.11.2018 01:34, Alexey Shabalin пишет:
> пт, 9 нояб. 2018 г. в 1:29, Leonid Krivoshein <klark.devel@gmail.com>:
>> [...]
>> Вот и вспомнили! Ага, именно такое у него предназначение было изначально
>> и традиционно перекочевало в systemd из sysvinit, но как-то
>> кривоватенько получилось: юниты стартуют после инициализации systemd,
>> systemd-random-seed -- одна из таких служб, только мы видим, что systemd
>> берёт данные из неинициализрованного /dev/urandom ещё на этапе своей
>> инцициализации... неувязочка!
> Брррр. Вы о чем? как можно стартануть юнит не запустив systemd.
> Ложитесь спать уже.

Именно об этом. Зачем systemd случайные числа на этапе инициализации? 
Если они действительно нужны, то почему бы не сделать данную службу 
частью процесса инициализации? Дайджест можно и без них считать. Здесь 
просто утверждается, что мы нашли порочный круг в systemd и это уже 
которую ночь не даёт покоя! :)


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 01:40:38 +0300 Leonid Krivoshein wrote:
> 
> 08.11.2018 20:15, Andrey Savchenko пишет:
> > On Thu, 8 Nov 2018 19:35:54 +0300 Denis Medvedev wrote:
> >> Может пользователям десктопных систем показать на экране в это время
> >> какой-нибудь тетрис для развлечения и поднятия энтропии?
> > Идея хорошая, но, как я понял, задержка возникает до инициализации
> > графики. Теоретически можно вкорячить в консоли или фреймбуфере,
> > но, думаю, это будет слишком сложно и плохо переносимо между разными
> > системами.
> 
> Не все к этому отнесутся серьёзно, не всем нравятся игрушки. К тому же 
> любая значимая задержка на старте -- та же уязвимость, потому что 
> пользователи начинают устранять препятствие любой ценой, хоть тем же 
> haveged/rngd, благо других советов в сети не водится.
> 
> Вообще странно. Когда для военных или других особых применений делается 
> дистрибутив, такие "навороты" с безопасностью понять ещё можно. Но для 
> всех поголовно гражданских применений стоит ли так круто гайки 
> завинчивать, да ещё и таким образом, что это будет просто отпугивать людей?
 
Простые гражданские создают ключи SSH и GPG, используют VPN,
хранят пароли в кейрингах. Этого достаточно для строгих требований
к качеству случайных чисел.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

09.11.2018 01:49, Andrey Savchenko пишет:
> On Fri, 9 Nov 2018 01:40:38 +0300 Leonid Krivoshein wrote:
>>
>> Вообще странно. Когда для военных или других особых применений делается
>> дистрибутив, такие "навороты" с безопасностью понять ещё можно. Но для
>> всех поголовно гражданских применений стоит ли так круто гайки
>> завинчивать, да ещё и таким образом, что это будет просто отпугивать людей?
>   
> Простые гражданские создают ключи SSH и GPG, используют VPN,
> хранят пароли в кейрингах. Этого достаточно для строгих требований
> к качеству случайных чисел.

Не на 5-й же секунде создавать ключ SSH! Если такое вообще возможно, 
лучше делать это на этапе инсталляции, когда пул уже достаточно 
наполнен, или хотя бы есть диалог с пользователем.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 01:52:48 +0300 Leonid Krivoshein wrote:
> 
> 09.11.2018 01:49, Andrey Savchenko пишет:
> > On Fri, 9 Nov 2018 01:40:38 +0300 Leonid Krivoshein wrote:
> >>
> >> Вообще странно. Когда для военных или других особых применений делается
> >> дистрибутив, такие "навороты" с безопасностью понять ещё можно. Но для
> >> всех поголовно гражданских применений стоит ли так круто гайки
> >> завинчивать, да ещё и таким образом, что это будет просто отпугивать людей?
> >   
> > Простые гражданские создают ключи SSH и GPG, используют VPN,
> > хранят пароли в кейрингах. Этого достаточно для строгих требований
> > к качеству случайных чисел.
> 
> Не на 5-й же секунде создавать ключ SSH! Если такое вообще возможно, 
> лучше делать это на этапе инсталляции, когда пул уже достаточно 
> наполнен, или хотя бы есть диалог с пользователем.

В предыдущих письмах я уже писал, что:

1) неправильно инициированный пул libgcrypt (и любого другого
подобного софта) подрывает доверие ко всей дальнейшей работе.

2) Создания SSH или RSA ключа на этапе старта сервера — достаточно
частная задача. Например, посмотри init-скрипт ssh. Там
ssh-keygen вызывается именно при старте демона для генерации
ключей сервера. Вот тебе и первые 5 секунд загрузки.

Далее я давал ссылку на публикацию, где обнаружили массовое
распространение (~1%) слабых хост ключей, полученных именно таким
образом: генерацией при недостаточности энтропии.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

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

On 2018-11-08 20:06:28 +0300, Andrey Savchenko wrote:

 >> 5. желательно всем обзавестись такими энтропийными ключиками,
 >> как у Алексея! :)
 > И да, и нет. То, что у Алексея ключик аппаратный — это хорошо, но,
 > как я помню, там нет равномеризации выборки и не гарантируется
 > несмещённость.

Первое обеспечивается аппаратно (на том ОУ, который компаратор), а
второе достигается банальным отбеливанием по SHA2 внутри CSPRNG.

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

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

Именно поэтому данные примешиваются в пул через хеш-функцию.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

On 2018-11-09 01:52:48 +0300, Leonid Krivoshein wrote:

 >> Простые гражданские создают ключи SSH и GPG, используют VPN,
 >> хранят пароли в кейрингах. Этого достаточно для строгих
 >> требований к качеству случайных чисел.
 > Не на 5-й же секунде создавать ключ SSH!

Ага! Доперло!

Вот на это существует реальная low-entropy атака. Именно для ОС,
использующих systemd :-)

 > Если такое вообще возможно, лучше делать это на этапе
 > инсталляции, когда пул уже достаточно наполнен,

[голосом двоих из ларца]
АГА!

Только дураки об этом не знают и нарываются на low-entropy.

 > или хотя бы есть диалог с пользователем.

Рекомендую считать, что его нет.


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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

09.11.2018 01:59, Andrey Savchenko пишет:
> On Fri, 9 Nov 2018 01:52:48 +0300 Leonid Krivoshein wrote:
>> 09.11.2018 01:49, Andrey Savchenko пишет:
>>> On Fri, 9 Nov 2018 01:40:38 +0300 Leonid Krivoshein wrote:
>>>> Вообще странно. Когда для военных или других особых применений делается
>>>> дистрибутив, такие "навороты" с безопасностью понять ещё можно. Но для
>>>> всех поголовно гражданских применений стоит ли так круто гайки
>>>> завинчивать, да ещё и таким образом, что это будет просто отпугивать людей?
>>>    
>>> Простые гражданские создают ключи SSH и GPG, используют VPN,
>>> хранят пароли в кейрингах. Этого достаточно для строгих требований
>>> к качеству случайных чисел.
>> Не на 5-й же секунде создавать ключ SSH! Если такое вообще возможно,
>> лучше делать это на этапе инсталляции, когда пул уже достаточно
>> наполнен, или хотя бы есть диалог с пользователем.
> В предыдущих письмах я уже писал, что:
>
> 1) неправильно инициированный пул libgcrypt (и любого другого
> подобного софта) подрывает доверие ко всей дальнейшей работе.

Не думаю, что у libgсrypt есть какой-то свой особый пул. Она выполняет 
функции шифрования и на выбор можно указать источник, хоть файл, хоть 
пароль с клавиатуры. /dev/[u]random тоже. Но такой пул может быть у 
конкретных пользователей этой библиотеки. И в каких-то не редких случаях 
твоё утверждение будет тогда справедливо, например, если по /etc/inittab 
ключ для SWAP создаётся на основе недоинициализированного /dev/urandom, 
а по сути там 0 бит реальной энтропии, то чёрт-возьми да, грош цена 
тогда такому шифрованию!


> 2) Создания SSH или RSA ключа на этапе старта сервера — достаточно
> частная задача. Например, посмотри init-скрипт ssh. Там
> ssh-keygen вызывается именно при старте демона для генерации
> ключей сервера. Вот тебе и первые 5 секунд загрузки.

Это всё понятно и как я уже говорил, на уровне дистрибутива можно 
считать багом, если необходимые ключи не были созданы на этапе 
инсталляции. init-скрипт ssh таким был, когда ещё не было systemd, и 
тогда это было оправдано. Теперь же другие реалии.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 02:07:05 +0300 Alexey V. Vissarionov wrote:
> On 2018-11-08 20:06:28 +0300, Andrey Savchenko wrote:
> 
>  >> 5. желательно всем обзавестись такими энтропийными ключиками,
>  >> как у Алексея! :)
>  > И да, и нет. То, что у Алексея ключик аппаратный — это хорошо, но,
>  > как я помню, там нет равномеризации выборки и не гарантируется
>  > несмещённость.
> 
> Первое обеспечивается аппаратно (на том ОУ, который компаратор), а
> второе достигается банальным отбеливанием по SHA2 внутри CSPRNG.

Покажи мне, пожалуйста, где там SHA2?
Вот последние исходники random.c ядра:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c

Для смешивания входных данных используется CRC-32 полином:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n323
 * For the purposes of better mixing, we use the CRC-32 polynomialas
 * well to make a (modified) twisted Generalized Feedback Shift
 * Register.

Для выходных данных используется SHA-1 (чтоб не выдавать внутреннее
состояние пула), который затем замешивается обратно в пул:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n333
 * The mixing operation is much less sensitive than the output hash,
 * where we use SHA-1.  All that we want of mixing operation is that
 * it be a good non-cryptographic hash; i.e. it not produce collisions
 * when fed "random" data of the sort we expect to see.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1417
 * We mix the hash back into the pool to prevent backtracking
 * attacks (where the attacker knows the state of the pool
 * plus the current outputs, and attempts to find previous
 * ouputs), unless the hash function can be inverted. By
 * mixing at least a SHA1 worth of hash data back, we make
 * brute-forcing the feedback as hard as brute-forcing the
 * hash.

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

Однако, в исходном коде по ссылкам выше это не совсем так.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 02:49:49 +0300 Leonid Krivoshein wrote:
> 
> 09.11.2018 01:59, Andrey Savchenko пишет:
> > On Fri, 9 Nov 2018 01:52:48 +0300 Leonid Krivoshein wrote:
> >> 09.11.2018 01:49, Andrey Savchenko пишет:
> >>> On Fri, 9 Nov 2018 01:40:38 +0300 Leonid Krivoshein wrote:
> >>>> Вообще странно. Когда для военных или других особых применений делается
> >>>> дистрибутив, такие "навороты" с безопасностью понять ещё можно. Но для
> >>>> всех поголовно гражданских применений стоит ли так круто гайки
> >>>> завинчивать, да ещё и таким образом, что это будет просто отпугивать людей?
> >>>    
> >>> Простые гражданские создают ключи SSH и GPG, используют VPN,
> >>> хранят пароли в кейрингах. Этого достаточно для строгих требований
> >>> к качеству случайных чисел.
> >> Не на 5-й же секунде создавать ключ SSH! Если такое вообще возможно,
> >> лучше делать это на этапе инсталляции, когда пул уже достаточно
> >> наполнен, или хотя бы есть диалог с пользователем.
> > В предыдущих письмах я уже писал, что:
> >
> > 1) неправильно инициированный пул libgcrypt (и любого другого
> > подобного софта) подрывает доверие ко всей дальнейшей работе.
> 
> Не думаю, что у libgсrypt есть какой-то свой особый пул.

Ты зря так думаешь:
https://www.gnupg.org/documentation/manuals/gcrypt/Random_002dNumber-Subsystem-Architecture.html

И он инициализируется как раз из /dev/(u)random в зависимости от
настроек.

> Она выполняет 
> функции шифрования и на выбор можно указать источник, хоть файл, хоть 
> пароль с клавиатуры. /dev/[u]random тоже. Но такой пул может быть у 
> конкретных пользователей этой библиотеки. И в каких-то не редких случаях 
> твоё утверждение будет тогда справедливо, например, если по /etc/inittab 
> ключ для SWAP создаётся на основе недоинициализированного /dev/urandom, 
> а по сути там 0 бит реальной энтропии, то чёрт-возьми да, грош цена 
> тогда такому шифрованию!

На моих системах шифрованный swap берёт ключ из /dev/random.
И ничего, загружаются.

> > 2) Создания SSH или RSA ключа на этапе старта сервера — достаточно
> > частная задача. Например, посмотри init-скрипт ssh. Там
> > ssh-keygen вызывается именно при старте демона для генерации
> > ключей сервера. Вот тебе и первые 5 секунд загрузки.
> 
> Это всё понятно и как я уже говорил, на уровне дистрибутива можно 
> считать багом, если необходимые ключи не были созданы на этапе 
> инсталляции. init-скрипт ssh таким был, когда ещё не было systemd, и 
> тогда это было оправдано. Теперь же другие реалии.

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

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

09.11.2018 03:30, Andrey Savchenko пишет:
> On Fri, 9 Nov 2018 02:07:05 +0300 Alexey V. Vissarionov wrote:
>> On 2018-11-08 20:06:28 +0300, Andrey Savchenko wrote:
>>
>>   >> 5. желательно всем обзавестись такими энтропийными ключиками,
>>   >> как у Алексея! :)
>>   > И да, и нет. То, что у Алексея ключик аппаратный — это хорошо, но,
>>   > как я помню, там нет равномеризации выборки и не гарантируется
>>   > несмещённость.
>>
>> Первое обеспечивается аппаратно (на том ОУ, который компаратор), а
>> второе достигается банальным отбеливанием по SHA2 внутри CSPRNG.
> Покажи мне, пожалуйста, где там SHA2?
> Вот последние исходники random.c ядра:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c
>
>
> Для выходных данных используется SHA-1 (чтоб не выдавать внутреннее
> состояние пула), который затем замешивается обратно в пул:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n333
>   * The mixing operation is much less sensitive than the output hash,
>   * where we use SHA-1.  All that we want of mixing operation is that
>   * it be a good non-cryptographic hash; i.e. it not produce collisions
>   * when fed "random" data of the sort we expect to see.
>

Когда на клетке с тигром надпись бык, не верь глазам своим! Не верь 
комментариям, в коде точнее. Они действительно использовали до 4.8 sha1, 
хотя много лет обсуждался переход чуть ли не на sha3, но в 4.8 
свершилось чудо и они перешли на чачу. Она просто рвёт sha1. Меня больше 
интересовал размер внутреннего состояния этого CPRNG, ну и сопоставление 
сообщений из исходников тому, что вижу в логах, даёт теперь больше 
понимания происходящему. Из того, что уже увидел и сопоставил -- много 
забавного.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

09.11.2018 04:33, Leonid Krivoshein пишет:
>
> ... но в 4.8 свершилось чудо и они перешли на чачу...
>

Даже раньше -- это случилось где-то между 4.4 и 4.9, гита нет под рукой.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey V. Vissarionov]

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

On 2018-11-09 03:30:19 +0300, Andrey Savchenko wrote:

 >>> как я помню, там нет равномеризации выборки и не гарантируется
 >>> несмещённость.
 >> Первое обеспечивается аппаратно (на том ОУ, который компаратор), а
 >> второе достигается банальным отбеливанием по SHA2 внутри CSPRNG.
 > Покажи мне, пожалуйста, где там SHA2?

Похоже, его там на чачу поменяли... как будто других симметричных
алгоритмов нет. Впрочем, не на Rijndael - и то хорошо.

 >> Именно поэтому данные примешиваются в пул через хеш-функцию.
 > Однако, в исходном коде по ссылкам выше это не совсем так.

Разгребусь - посмотрю повнимательнее: мои воспоминания о random.c
основательно устарели, ибо его столь же основательно переписали.

Хотя мне от него кроме add_device_randomness(void*, size_t) уже
давно ничего не нужно.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 04:33:48 +0300 Leonid Krivoshein wrote:
> 
> 09.11.2018 03:30, Andrey Savchenko пишет:
> > On Fri, 9 Nov 2018 02:07:05 +0300 Alexey V. Vissarionov wrote:
> >> On 2018-11-08 20:06:28 +0300, Andrey Savchenko wrote:
> >>
> >>   >> 5. желательно всем обзавестись такими энтропийными ключиками,
> >>   >> как у Алексея! :)
> >>   > И да, и нет. То, что у Алексея ключик аппаратный — это хорошо, но,
> >>   > как я помню, там нет равномеризации выборки и не гарантируется
> >>   > несмещённость.
> >>
> >> Первое обеспечивается аппаратно (на том ОУ, который компаратор), а
> >> второе достигается банальным отбеливанием по SHA2 внутри CSPRNG.
> > Покажи мне, пожалуйста, где там SHA2?
> > Вот последние исходники random.c ядра:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c
> >
> >
> > Для выходных данных используется SHA-1 (чтоб не выдавать внутреннее
> > состояние пула), который затем замешивается обратно в пул:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n333
> >   * The mixing operation is much less sensitive than the output hash,
> >   * where we use SHA-1.  All that we want of mixing operation is that
> >   * it be a good non-cryptographic hash; i.e. it not produce collisions
> >   * when fed "random" data of the sort we expect to see.
> >
> 
> Когда на клетке с тигром надпись бык, не верь глазам своим! Не верь 
> комментариям, в коде точнее. Они действительно использовали до 4.8 sha1, 
> хотя много лет обсуждался переход чуть ли не на sha3, но в 4.8 
> свершилось чудо и они перешли на чачу. Она просто рвёт sha1.

Не путай вещи. sha1 там как был в extract_buf(), так и остался:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1437

А chacha20 используется в crng:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n893


Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Paul Wolneykien]

08.11.2018 19:33, Andrey Savchenko пишет:
> On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
>> 07.11.2018 21:38, Leonid Krivoshein пишет:
>>> 4. надо находить и устранять причины раннего опустошения энтропии,
>>> приводящие к блокировкам.
>>
>>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
>> железе, поскольку для загрузки внезапно понадобились случайные числа?
> 
> Не совсем так. Случайные числа нужны были всегда, просто сейчас
> исправили баг с выдачей предсказуемых чисел вместо случайных, что
> ранее имело место при недостаточной энтропии в начале загрузки.
> 
> ОС как грузилась, так и будет грузится. Просто некоторым
> пользователям systemd придётся подождать. Ирония в том, что systemd
> породил проблему долгой загрузки для решения которой изначально
> создавался.

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Paul Wolneykien]

09.11.2018 01:47, Leonid Krivoshein пишет:
> 
> 09.11.2018 01:34, Alexey Shabalin пишет:
>> пт, 9 нояб. 2018 г. в 1:29, Leonid Krivoshein <klark.devel@gmail.com>:
>>> [...]
>>> Вот и вспомнили! Ага, именно такое у него предназначение было изначально
>>> и традиционно перекочевало в systemd из sysvinit, но как-то
>>> кривоватенько получилось: юниты стартуют после инициализации systemd,
>>> systemd-random-seed -- одна из таких служб, только мы видим, что systemd
>>> берёт данные из неинициализрованного /dev/urandom ещё на этапе своей
>>> инцициализации... неувязочка!
>> Брррр. Вы о чем? как можно стартануть юнит не запустив systemd.
>> Ложитесь спать уже.
> 
> Именно об этом. Зачем systemd случайные числа на этапе инициализации?
> Если они действительно нужны,

  В смысле, действительно нужны? Какие криптографические операции
выполняет systemd? Его дело — читать юнит-файлы и порождать дочерние
процессы. По-моему, так.

> то почему бы не сделать данную службу
> частью процесса инициализации? Дайджест можно и без них считать. Здесь
> просто утверждается, что мы нашли порочный круг в systemd и это уже
> которую ночь не даёт покоя! :)

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 12:44:10 +0300 Paul Wolneykien wrote:
> 08.11.2018 19:33, Andrey Savchenko пишет:
> > On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
> >> 07.11.2018 21:38, Leonid Krivoshein пишет:
> >>> 4. надо находить и устранять причины раннего опустошения энтропии,
> >>> приводящие к блокировкам.
> >>
> >>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> >> железе, поскольку для загрузки внезапно понадобились случайные числа?
> > 
> > Не совсем так. Случайные числа нужны были всегда, просто сейчас
> > исправили баг с выдачей предсказуемых чисел вместо случайных, что
> > ранее имело место при недостаточной энтропии в начале загрузки.
> > 
> > ОС как грузилась, так и будет грузится. Просто некоторым
> > пользователям systemd придётся подождать. Ирония в том, что systemd
> > породил проблему долгой загрузки для решения которой изначально
> > создавался.
> 
>   Это меняет дело. Я правильно понимаю, что можно собрать такой JEOS,
> который будет грузиться без тормозов, исключив потребителей случайных
> чисел, но оставив systemd?

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

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Leonid Krivoshein]

09.11.2018 13:10, Andrey Savchenko пишет:
> On Fri, 9 Nov 2018 12:44:10 +0300 Paul Wolneykien wrote:
>> 08.11.2018 19:33, Andrey Savchenko пишет:
>>> On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
>>>> 07.11.2018 21:38, Leonid Krivoshein пишет:
>>>>> 4. надо находить и устранять причины раннего опустошения энтропии,
>>>>> приводящие к блокировкам.
>>>>    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
>>>> железе, поскольку для загрузки внезапно понадобились случайные числа?
>>> Не совсем так. Случайные числа нужны были всегда, просто сейчас
>>> исправили баг с выдачей предсказуемых чисел вместо случайных, что
>>> ранее имело место при недостаточной энтропии в начале загрузки.
>>>
>>> ОС как грузилась, так и будет грузится. Просто некоторым
>>> пользователям systemd придётся подождать. Ирония в том, что systemd
>>> породил проблему долгой загрузки для решения которой изначально
>>> создавался.
>>    Это меняет дело. Я правильно понимаю, что можно собрать такой JEOS,
>> который будет грузиться без тормозов, исключив потребителей случайных
>> чисел, но оставив systemd?
> Уже разобрались в другой ветке, что проблема была в несохранении
> random pool между перезагрузками, т.к. для пользователей systemd
> он был в tmpfs, исправление ожидает коммита.

Да ладно, Поттеринг уже два года с этим "разбирается"!
https://github.com/systemd/systemd/issues/4167


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [sisyphus] Не переключается в графический режим

[Alexey Shabalin]

пт, 9 нояб. 2018 г. в 13:11, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Fri, 9 Nov 2018 12:44:10 +0300 Paul Wolneykien wrote:
> > 08.11.2018 19:33, Andrey Savchenko пишет:
> > > On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
> > >> 07.11.2018 21:38, Leonid Krivoshein пишет:
> > >>> 4. надо находить и устранять причины раннего опустошения энтропии,
> > >>> приводящие к блокировкам.
> > >>
> > >>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> > >> железе, поскольку для загрузки внезапно понадобились случайные числа?
> > >
> > > Не совсем так. Случайные числа нужны были всегда, просто сейчас
> > > исправили баг с выдачей предсказуемых чисел вместо случайных, что
> > > ранее имело место при недостаточной энтропии в начале загрузки.
> > >
> > > ОС как грузилась, так и будет грузится. Просто некоторым
> > > пользователям systemd придётся подождать. Ирония в том, что systemd
> > > породил проблему долгой загрузки для решения которой изначально
> > > создавался.
> >
> >   Это меняет дело. Я правильно понимаю, что можно собрать такой JEOS,
> > который будет грузиться без тормозов, исключив потребителей случайных
> > чисел, но оставив systemd?
>
> Уже разобрались в другой ветке, что проблема была в несохранении
> random pool между перезагрузками, т.к. для пользователей systemd
> он был в tmpfs, исправление ожидает коммита.

Ничего не разобрались, у systemd всегда сохранялось нормально.
Изменения касаются SysV.

PS: вообще заметил двойные стандарты - ошибки в systemd раздуваются до
вселенских маштабов, а в sysv просто не замечаются :)

-- 
Alexey Shabalin

Re: [devel] [sisyphus] Не переключается в графический режим

[Andrey Savchenko]

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

On Fri, 9 Nov 2018 15:52:10 +0300 Alexey Shabalin wrote:
> пт, 9 нояб. 2018 г. в 13:11, Andrey Savchenko <bircoph@altlinux.org>:
> >
> > On Fri, 9 Nov 2018 12:44:10 +0300 Paul Wolneykien wrote:
> > > 08.11.2018 19:33, Andrey Savchenko пишет:
> > > > On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
> > > >> 07.11.2018 21:38, Leonid Krivoshein пишет:
> > > >>> 4. надо находить и устранять причины раннего опустошения энтропии,
> > > >>> приводящие к блокировкам.
> > > >>
> > > >>   Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> > > >> железе, поскольку для загрузки внезапно понадобились случайные числа?
> > > >
> > > > Не совсем так. Случайные числа нужны были всегда, просто сейчас
> > > > исправили баг с выдачей предсказуемых чисел вместо случайных, что
> > > > ранее имело место при недостаточной энтропии в начале загрузки.
> > > >
> > > > ОС как грузилась, так и будет грузится. Просто некоторым
> > > > пользователям systemd придётся подождать. Ирония в том, что systemd
> > > > породил проблему долгой загрузки для решения которой изначально
> > > > создавался.
> > >
> > >   Это меняет дело. Я правильно понимаю, что можно собрать такой JEOS,
> > > который будет грузиться без тормозов, исключив потребителей случайных
> > > чисел, но оставив systemd?
> >
> > Уже разобрались в другой ветке, что проблема была в несохранении
> > random pool между перезагрузками, т.к. для пользователей systemd
> > он был в tmpfs, исправление ожидает коммита.
> 
> Ничего не разобрались, у systemd всегда сохранялось нормально.
> Изменения касаются SysV.
> 
> PS: вообще заметил двойные стандарты - ошибки в systemd раздуваются до
> вселенских маштабов, а в sysv просто не замечаются :)

А где в sysv ошибка? /var/run там на обычной fs.

Best regards,
Andrew Savchenko

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

Re: [devel] [sisyphus] Не переключается в графический режим

[Антон Мидюков]

09.11.2018 20:14, Andrey Savchenko пишет:
> On Fri, 9 Nov 2018 15:52:10 +0300 Alexey Shabalin wrote:
>> пт, 9 нояб. 2018 г. в 13:11, Andrey Savchenko <bircoph@altlinux.org>:
>>> On Fri, 9 Nov 2018 12:44:10 +0300 Paul Wolneykien wrote:
>>>> 08.11.2018 19:33, Andrey Savchenko пишет:
>>>>> On Wed, 7 Nov 2018 22:41:08 +0300 Paul Wolneykien wrote:
>>>>>> 07.11.2018 21:38, Leonid Krivoshein пишет:
>>>>>>> 4. надо находить и устранять причины раннего опустошения энтропии,
>>>>>>> приводящие к блокировкам.
>>>>>>    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
>>>>>> железе, поскольку для загрузки внезапно понадобились случайные числа?
>>>>> Не совсем так. Случайные числа нужны были всегда, просто сейчас
>>>>> исправили баг с выдачей предсказуемых чисел вместо случайных, что
>>>>> ранее имело место при недостаточной энтропии в начале загрузки.
>>>>>
>>>>> ОС как грузилась, так и будет грузится. Просто некоторым
>>>>> пользователям systemd придётся подождать. Ирония в том, что systemd
>>>>> породил проблему долгой загрузки для решения которой изначально
>>>>> создавался.
>>>>    Это меняет дело. Я правильно понимаю, что можно собрать такой JEOS,
>>>> который будет грузиться без тормозов, исключив потребителей случайных
>>>> чисел, но оставив systemd?
>>> Уже разобрались в другой ветке, что проблема была в несохранении
>>> random pool между перезагрузками, т.к. для пользователей systemd
>>> он был в tmpfs, исправление ожидает коммита.
>> Ничего не разобрались, у systemd всегда сохранялось нормально.
>> Изменения касаются SysV.
>>
>> PS: вообще заметил двойные стандарты - ошибки в systemd раздуваются до
>> вселенских маштабов, а в sysv просто не замечаются :)
> А где в sysv ошибка? /var/run там на обычной fs.
>
Сейчас на sysV чехарда. Кто-то смотрит в /var/run/, кто-то в /run; 
кто-то в /run/lock, кто-то в /var/lock. На systemd /var/run и /run одно 
и тоже, а на sysV нет. После того, как в начале сентября в пакете 
filesystem /var/lock/subsys превратился в ghost, случился маленький 
армагедец для sysV. Есть желание превратить /var/run в симлинк на 
../run, /var/lock в симлинк на ../run/lock. bug 35350 Об этом баге уже 
писал.

Кстати, в сборке regular-xfce-sysv наблюдаю очень долгую загрузку, чего 
нет в других регулярках.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] [sisyphus] Не переключается в графический режим

[Sergey Y. Afonin]

On Friday 09 November 2018, Alexey Shabalin wrote:

> PS: вообще заметил двойные стандарты - ошибки в systemd раздуваются
> до вселенских маштабов, а в sysv просто не замечаются :)
 
Потому, что всё работало, и тут появился systemd. :-)

-- 
С уважением, Сергей Афонин