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=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FUZZY_XPILL autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=iPUmI0mY54vtCztHksKbmwUZatYh3zd37nU/aseHlTM=; b=vdEvddyM25c373TmBiqPsdH5TVFZ6rscSTR4N55xqoiU8Jfu7MUDo5iwE1qgL4F+eU ePuM3fWGJnn/NOLa0QFuVD1kyalUyjDkK6v2JTqPmVj6/t0mxRsZMNNs05v95QBO93eg Cv2PmsrPAquJIJsHZvMP6PnS5byQV9RcfrLylnQGmoal0FGvgAR6lVmdJ7F30uE10dHL 4yWg/KcRkaQjE1RrZT6W0uqSQ/Rnb+GG0S4nhSRr2czf2av7qNmN2jzHudfnVOCFmFaN qh4phPcMzAtTSry6Y9RXscZz2/c+9l8PNvFq5nbJkKeycJ/b6cNiLsLiINwRxnp6weAv UMow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iPUmI0mY54vtCztHksKbmwUZatYh3zd37nU/aseHlTM=; b=BnmJkakh3SpDAyMfqU34cPlcU3sZaCLTHP2ohqTmNpK+waNrxbEvHMQ5L/aR5prlhN /H6W/xtHDAPlOahR7SYHGIFlhM/bK5eGznrIvG/ytWG5xWCuBDigS8DBACu8aHWIPGNb FJjVM8kNSHZ11V+x7jQDApvt27ox8nWilCj8PJ7aHuZlNKGPURZz8SErPjRePAoh7GuF JsNv+yCOhyUdaqr6qA3uDpoq0lsmnFwTAwJ2yCdZ3nrdaQ2pDlCogOncl6pmPEGpUxfw n02uOAdbrsoVfRVxR5zIwi0V/TjZ0bDsSb9yKKmPDhZtGNdZo6CsY/W+mJaAbF9ffNn9 WhNA== X-Gm-Message-State: APjAAAUq5rBddKmqESW8r4TFayfoCwMDTfWKzXbk3FVKxMKfMhranyR4 9zFOe369fzzevwJKrqcHX5J+9mt9 X-Google-Smtp-Source: APXvYqyGm+HTXpPvFLZwhfJCaeD+bZGPkf3CBUaH5MpExHt0xcuoguhSs9fn2h2diTAIo7QEDAGQOg== X-Received: by 2002:a2e:b047:: with SMTP id d7mr2619896ljl.133.1567496440733; Tue, 03 Sep 2019 00:40:40 -0700 (PDT) To: devel@lists.altlinux.org References: <20190530164054.GA27835@altlinux.org> <4041b3c1-b134-9720-0f01-1a2527ed1721@basealt.ru> <20190531105614.GD27835@altlinux.org> <975ac233-dc84-d9eb-1d24-975ee807c075@basealt.ru> <20190831123520.GD12903@altlinux.org> <936a2336-e8c6-8274-37cf-a8059ee9bf44@gmail.com> <20190831154243.GE12903@altlinux.org> <7e2bba2a-867f-b8a0-6e27-1a07521e13fb@gmail.com> <20190902235913.GO12903@altlinux.org> From: Leonid Krivoshein Message-ID: <12b305ed-4e3c-c4c1-7d19-17649f0817fe@gmail.com> Date: Tue, 3 Sep 2019 10:37:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20190902235913.GO12903@altlinux.org> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] rngd vs haveged vs crng (khwrngd) 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, 03 Sep 2019 07:40:42 -0000 Archived-At: List-Archive: List-Post: 03.09.2019 02:59, Alexey V. Vissarionov пишет: > [...] > > >> 2. к моменту начала использования недоверенного RNG пул должен > >> быть заполнен данными из других источников. > > Вот он ещё не заполнен. Почти... а уже надо! > > Если почти, то можно и недоверенный источник подмешивать. В смысле: пул почти почти пуст. > [...] > > > хотяи с заданными пороговыми значениями, чтобы число бит на > > выходе не было меньше реальной энтропии на входе. > > Дядя, ты как сам-то? Если не меньше - значит, строго равно (ибо Конечно, оговорка по Фрейду: s/не меньше/не больше/ :) > [...] > > > Единственное, что делается ДО -- инициализация devtmpfs. > > Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется до > run_init_process(), но после mount_block_root() Инициализация экземпляра файловой системы внутри ядра и монтирование её в userspace -- две разные вещи. Монтирование /dev в userspace инициируется процессом с PID 1 уже после того, как ядро проинициализировало initramfs, devtpmfs, нашло и запустило /sbin/init. Никаких устройств на этом этапе ещё нет, ramfs/tpmfs в ядро вкомпилируются. Даже если не указывать путь к собственному initramfs, оно тоже в ядре имеется всегда. Пустое, без /sbin/init, чтобы отработал твой любимый fallback с /dev/md0. > > К моменту запуска /sbin/init может быть даже не загружено ещё > > никаких модулей. > > И это очень плохо. Потому что очень многие из них используют как > минимум один способ (из четырех возможных) помочь ядерному ГСЧ > набрать энтропию перед run_init_process() К счастью, в initramfs у нас не systemd, иначе с проблемой мы сталкивались бы раньше и на большем охвате железа. systemd только так генерирует UUID'ы для сервисов, множество временных файлов, использует внутренние хэш-таблицы и случайные числа для всевозможных "сетевых" нужд. Так что плохо, да, но может быть ещё хуже. Полагаю, тем, у кого нет systemd, эта проблема неведома. На SysV-init вероятность запуска сервиса, требующего CRNG, примерно равна нулю. > > Процесс асинхронной инициализации хорошо виден в dmesg и > > journalctl. У нас, правда, тут не systemd сейчас стартует, а > > другой /sbin/init. Но надо понимать, что прохождение stage1 > > зависит от железа и конфигурации системы. > > Что ты в данном случае называешь stage1? initrafms (initrd) -- первая стадия загрузки. > [...] > > > Блокировку на этапе загрузки можно рассматривать не только как > > баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS для > > всего HA-кластера. В конце концов, подкопив энтропии, можно > > обновить состояние инициализации CRNG. > > Да: низкоэнтропийная криптография - это уязвимость. Исправлять ее > будем, или как обычно? > > > А терпеть тормоза при загрузке можно далеко не во всех сценариях. > > При вводе системы в промышленную эксплуатацию сервер должен быть > запущен позавчера. -- Best regards, Leonid Krivoshein.