From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Tue, 28 May 2019 11:57:45 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20190528085745.GD7916@altlinux.org> References: <20190425102859.GA12238@lks.home> <20190527115951.GC9183@imap.altlinux.org> <68691384-e187-bb8b-70ab-df82f54a1d25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68691384-e187-bb8b-70ab-df82f54a1d25@gmail.com> Subject: Re: [devel] rngd vs haveged vs crng X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 08:57:49 -0000 Archived-At: List-Archive: List-Post: On 2019-05-28 02:53:12 +0300, Leonid Krivoshein wrote: >>> В копилку дополнительных решений. Случайно наткнулся на >>> специальный клиент-сервер :) >> То есть сперва создать проблему на ровном месте, >> затем героически её решать. > Справедливости ради: специально её не создавали, так уж > сложилось. Именно создали. > Рынок жаждет быстрых компьютеров, быстрых SSD. И они появились. > Overal Perfomance Index определяется отнюдь не скоростью > загрузки и временем отклика на данную команду, но обыватель > не любит ждать и ему важнее эти два "субъективных" показателя, Обывателям вообще начхать на любые показатели - им нужны котики. > конечно, непосредственно о распараллеливании загрузки никто > особо не думает. Разумеется: основная задача - обеспечить запуск демонов в нужной последовательности с учетом их взаимных зависимостей (httpd надо запустить после postgresql, но до nginx, так как CMS сайтов нужен доступ к БД, а FE требует работающего BE), а распараллеливание загрузки - не более, чем приятный побочный эффект. > Однако init-системы начали вырастать одна за другой в угоду > этим хотелкам рынка, systemd -- не первая, и наверняка не > последняя. Скорее всего, ещё и не самая плохая реализация На данный момент - самая. > параллельной загрузки. Еще раз: не параллельной загрузки, а запуска демонов с учетом их взаимных зависимостей. > Самой удачной она могла бы стать, если бы не ломала надёжности, Собственно, этой причины уже достаточно для того, чтобы избегать этого поделия в промышленных системах. > не создавала бы гонок на ровном месте, Для этого и нужны взаимные зависимости. И, кстати, их можно легко реализовать даже на основе SysVinit - для этого достаточно сделать обязательным `service $name status` с унифицированным выводом ("unknown", "disabled", "stopped", "failed", "running"). > позволяла бы работать с разными профилями надёжности Эээээто как? Отключать глюкодром там, где надо сделать хорошо? :-) > и совместимости. С чем? > Для бывалых никакого значения не имеет скорость загрузки, > надёжность важнее. А для остальных - "пипл хавает"? > Но ведь даже не systemd стал проблемой. Именно он и стал. Из-за головожопости разработчиков, у которых фантазия улетела в дальние дали и окончательно оторвалась от реальности - именно это мы наблюдаем в ситуации, когда во имя скорости загрузки эти (выражусь дипломатично) дебилы жертвуют надежностью и безопасностью. > Не было бы его, здесь был бы upstart или любой другой имярек. Что любопытно, в upstart это настолько явно не проявляется. > Просто, с одной стороны, компьютеры и диски стали быстрее, Да. Нужно успевать. > система загрузки стала слишком непоследовательной, И что? Пока не прочитали из /proc/sys/kernel/random/poolsize число 4096 (что означает полностью заполненный пул энтропии) - просто не запускаем ничего. По буквам: Николай, Иван, Харитон, Ульяна, Яков. Повторяю: ничего. А, ну да... это же замедлит загрузку, и пользователю придется (о ужас!) подождать несколько секунд... > с другой -- апстрим ядра закрутил гайки с CPRNG. Да ничего они там особо не крутили... немного поменяли логику работы и вместо SHA2 теперь используют игрушечный poly1305. > И проблема вылазит точечно, даже виртуалок это больше > касается. Потому что и там прогресс, и там тоже закрутили. А нефиг их на горячуу клонировать... > Выходит, в первую очередь именно мы должны думать, как > компоновать системы, чтобы не было потребителей энтропии > на раннем старте. Персонально отлавливать и отстреливать. > Хороший пример с ssh-keygen -A. Хороший. А теперь подумай, как ты от него избавишься... ну, например, в эталонном образе виртуалки. Или будешь плодить кучу хостов с одинаковыми ключами? :-) >> По умолчанию в "обычных" выпусках, как мне кажется, >> работоспособность системы в течение разумного времени >> после включения/перезагрузки важнее, чем подписи, >> которые не проверит/посмотрит никто. > Все варианты решения уже известны и обсуждались много раз. > Можно ещё один вариант рассмотреть. Допустим, мы уже точно > знаем, какие приложения сколько выжрут энтропии. Откуда и как мы это можем узнать точно? > Будучи запущенными в первые несколько секунд, это создаст > проблему. Оценить текущий пул через sysfs мы можем, время > от начала запуска известен. Для таких программ создаются > фэйки-обёртки, выполняющие их отложенный запуск. А systemd > пусть думает, что всё уже случилось. Это даже не просто костыль - это специально сломать ногу, а потом компенсировать это костылем. > Если для ряда таких программ заблокировать запуск полностью > возможно без ущерба для загрузки, значит, сразу после логина > юзера с uid 500 А почему не 512? :-) > чтобы вылазило системное предупреждение, типа: внесите > такие-то изменения в свои настройки или мы и дальше будем > блокировать запуск таких-то приложений. И усер такой: http://pics.rsh.ru/img/sova_pwivfaew.jpg > Для таких программ, как gnome-keyring, если создавать > временное хранилище на основе ненадёжных данных ... то лучше вообще не создавать такое хранилище. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net