Инженер из компании Meta в списке рассылки разработчиков ядра Linux обратил внимание на проблему с работой инструкции RDSEED в процессорах AMD на базе микроархитектуры Zen 5. В проведённых тестах инструкция RDSEED, предоставляющая доступ к аппаратному генератору энтропии, в 10% случаев возвращала значение 0 с успешным флагом завершения операции (CF=1). Так как значение 0 также возвращается в случае невозможности вернуть корректное случайное число и подобное состояние выделяется иным значением флага завершения операции (CF=0), предполагается, что в процессорах AMD имеется ошибка, приводящая к неверному определению состояния операции...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64066
Если это происходит в рандомных экземплярах, то выходит нормально?
а если в псевдорандомных? атас
Если целенаправленная закладка работает и её туда специально заложили это нормально. В этом и смысл.
Что останется у Сообщества, если лишить его последнего хардварного фетиша - АМД?
RISC-V
>выдаёт 0 в 10% случаевКак страшно жить. Неужели это прям так плохо?
да, ты ухцдшаешь качество генерируемых хэшей, эьо опасно
>качество генерируемых хэшейХэш есть функция текста. Случайные числа тут мимо.
Если энтропия берется только отсюда, то отвратительно плохо. Много криптоалгоритмов становятся бессмысленными с плохим ГПСЧ.
Обычно источников энтропии много, но даже если бы был один этот - то при reseed обычно старое значение не сбрасывают, а подмешивают новую энтропиюЕсли к хорошему источнику энтропии (старые, правильные результаты RDRAND) подмешать плохой источник (RDRAND вернувший 0), то он не станет хуже
Так что при правильном использовании даже генератор с таким браком не должен приводить к проблемам с безопасностью.
А если в других источниках энтропии тоже баги?
Модель швейцарского сыра никто не отменял
> А если в других источниках энтропии тоже баги?Во всех сразу? Даже вещи вроде сети, vfs и прочих preemption (Они тоже подмешивают всякое в энтропию) резко стали deterministic?
Ну даже не знаю, представь что ты запрашиваешь 256 битный рандомный ключ для шифрования, у которого диапазон значений 0 .. 2^256-1, а тебе с вероятностью 10% выпадает ноль, а вероятность нуля должна быть = 1 / 2^256
Это буквально "КРИТИЧЕСКАЯ НЕУДАЧА" для твоего биткоин-кошелька (точнее программы, которая держит твой кошель), а если на таком процессоре сервер биткоин-кошельков, типа какого-нибудь бинанс...
Ну короче последствия надеюсь ты понял...
Инструкция возвращает 16/32/64 битное значение, а не 256. Так что вероятность того, что пр и 64 бит тебе 4 раза подряд вернется значение 0 равно 1*10-4. Во всех остальных случаях вернется таки достаточно случайное число (как минимум, 64 битное). Аккуратней надо быть с циферками.
>как минимум, 64 битное64 битную энтропию в биткоин адресах щелкают как орехи, несколько часов и готово
Согласно документации, разрядность регистра 16, 32, 64 бита. Так что всё ещё хуже.
Да в 8086 была 16 бит. Только это было при царе горохе.
Особо измудренные люди сказали бы что случайность рандомного генератора чисел предсказуема.
Охранник парковки Михалыч высчитывает сложные формулы в уме, не то что ученые всякие.
Ну конечно же ты не имел ввиду деление 1 на 3(или ищо там чыво) с дальнейшим округлением от балды и использыванием этих результатов в вычислениях дальше....Да и т.н. генератор случайных чисел работает по не случайным алгоритмам.... Не, не так?
И конечно же, он демонстрировал вам это лично после совместного изрядного количества "подсчетов".
Дело не в предсказуемости,а в плохих статисческих характеристиках. Для моделирования это важно.
.
Всего лишь бракованный процессор, неужели это прям так плохо?
Откуда ты знаешь. Может переведен в специальный режим при помощи недокументированных возможностей?
> неужели это прям так плохо?Всё зависит от того, где стоит этот процессор и при выполнении какой конкретно задачи будет выдан ноль.
Да никому не нужен такой брак.
> Как страшно жить. Неужели это прям так плохо?Неа, эта инструкция является лишь одним из (обычно "худшим") источников энтропии в системе. Можно совмещать с другими или вообще не использовать (скорее всего отключением по умолчанию и кончится, по крайней мере при наличии другого качественного источника вроде TPM2).
TPM2 - в большинстве случаев, чисто софтовый. Как ты думаешь, откуда он берет энтропию?
Правильная реализация рандома будет работать нормально даже если один (либо даже единственный) генератор энтропии иногда будет выдавать не рандом, плохая энтропия смешанная с хорошей не приводит к ухудшению качества
Только вот "хорошей" у тебя может и не быть. К примеру, в первое время после старта системы.RDRAND, а позднее и RDSEED, изначально позиционировались как решение этой проблемы - как дешевый (в плане производительности и ресурсов) источник случайных данных, в любой момент времени и везде. В итоге RDSEED не работает чуть менее чем всегда, а RDRAND мы всё равно не верим (и он тоже нет-нет, да и лажает).
Кстати, прогнал тут тест на Alder Lake на одном потоке, и он выдал эффективность RDSEED порядка 12%. Так что низкая эффективность не только у AMD.
> а RDRAND мы всё равно не веримв смысле не верим? он не проходит тесты случайности? то что он не крипто-стойкий таков он по определению, а для всего остального - применим.
> а RDRAND мы всё равно не веримОтказываясь от источников энтропии, даже если они совсем плохие, вы не делаете систему безопаснее)
> Отказываясь от источников энтропии, даже если они совсем плохие, вы не делаете
> систему безопаснее)А отказываясь пить отравленную воду - мы не становимся здоровее? :)
> А отказываясь пить отравленную воду - мы не становимся здоровее? :)А теперь изучите немного математики первого курса теории информации, для некоррелированных битовых строк с разными распределениями энтропия смеси не может уменьшиться, H(X_1) <= H(X_1, X_2).
> эффективность RDSEED порядка 12%а что это значит?
А как вы определили качество энтропии TPM2? Он работает под управлением отдельной ОС - с закрытым и обфусцированным исходным кодом, с защитой от анализа. Что туда насовал дорогой Интел/АМД можно только догадываться. Или тратить кучу оплачиваемых человекочасов на обратную разработку для каждой отдельной железки.
Гугли fTPM
https://en.wikipedia.org/wiki/Trusted_Platform_Module#Open_s...
>Неужели это прям так плохо?Предполагай, что RDSEED выдал 0, и будешь прав в одном случае из 10.
и что? мне теперь выбросить мой Ryzen 5 9600X?
Сначала прогони небольшой тестик на ASMе. N раз вызывай эту RDSEED и смотри, возвращает ли 0 с флагом 1.
Вот это ты конечно опростоволосился.
Не волнуйся, закроют микрокодом.
Ну, например, отбрасывать 0 как результат. диапазон от 0 - 2^64-1 исключая 0. Что будет с формулами?
Тото мне в онлайн играх лут с шансом упасть 50% выпадает с 20й попытки, а лут с шансом упасть 20% надо гриндить 4 дня без остановки. Это оказывается AMD виноваты, а не жадные разрабы, желающие развести меня на оплаченное игровое время.
Ну лут с шансом 0.02 выпадает с шансом 75% же. Причём, знаешь, когда 4 раза на рейдбосса завалишься (это там где толпа конкурентов помимо вероятности того что вообще что-то выпадет) и 3 раза забираешь лучший предмет. Секрет в том, чтобы играть раз в неделю, вот вам и "шанс".
Зачем полностью отключать использование, если можно в случае выпадения 0 сделать ретрай?
Выпадет 0xFFFFFFFF, годится?
По крайней мере, это значение не связано с готовностью генератора.
Спорный костыль
Предложи неспорный.
Вполне себе рабочий костыль: если не равно 0 или 0xffffffff, то все норм. Во времена NES такой костыль использовали для считывания с геймпада, т.к. DPCM из за аппаратных косяков мог загадить шину. Надо было считать состояние геймпада 3 раза. И все было норм только если все 3 раза совпадали.
Вероятность выпадения нуля должна оставаться ненулевой. То есть иногда ноль -- это нормально, если он выпадает раз в N итераций. Ты же предлагаешь, чтобы ноль не возвращался никогда. Это плохо. Отсутствие нуля -- это неслучайность: кто-то явно вписал if (result == 0) continue. Как ты догадываешься, неслучайностям нет места там, где требуется именно случайность.
Спорно.
> Вероятность выпадения нуля должна оставаться ненулевой. То есть иногда ноль -- это
> нормально, если он выпадает раз в N итераций. Ты же предлагаешь,
> чтобы ноль не возвращался никогда. Это плохо. Отсутствие нуля -- это
> неслучайность: кто-то явно вписал if (result == 0) continue. Как ты
> догадываешься, неслучайностям нет места там, где требуется именно случайность.При генерации рандома у тебя в любом случае должна использоваться хеш функция например поверх всего этого, а с ней у тебя даже если процессор будет только 0x00000000 и 0xffffffff выдавать - никакого эффекта от подобного на качество генерации случайных чисел не будет.
> в любом случае должна использоваться хеш функцияс чего бы? хеш функция в качестве рандома - бред, который продвигают, как и бред использовать шифрование aes на рандомно ключе. Рандом должен быть рандомом!
>> в любом случае должна использоваться хеш функция
> с чего бы? хеш функция в качестве рандома - бред, который продвигают,
> как и бред использовать шифрование aes на рандомно ключе. Рандом должен
> быть рандомом!Т.е по твоему хеш функция/aes не вносят энтропию?)
Через что по твоему примитивы CSPRNG реализованы, если не через aes/другое шифрование/хеширование?Нука найди мне что-то без этого что требованиям к CSPRNG соответствует.
> Т.е по твоему хеш функция/aes не вносят энтропию?)Начнем с определения энтропии?
> Через что по твоему примитивы CSPRNG реализованы
В этом то и беда, я же выше сказал об этом.
> Нука найди мне что-то без этого что требованиям к CSPRNG соответствует
Какое главное требование к csprng?
>> Через что по твоему примитивы CSPRNG реализованы
> В этом то и беда, я же выше сказал об этом.По твоему CSPRNG не нужны, и всегда нужно использовать TRNG?)
Приведи пример софта который полагается только на TRNG.Именно потому что люди думают что TRNG волшебным образом бессмертные и в результате криво этим пользуются, из linux выпилили /dev/random, решив все проблемы с зависаниями от недостатка энтропии и при этом не в ущерб безопасности.
> По твоему CSPRNG не нужны, и всегда нужно использовать TRNG?)Я такого не утверждал, необходимость CSPRNG - в ее требованиях.
> Приведи пример софта который полагается только на TRNG.
Если ваш TRNG удовлетворяет требованиям CSPRNG, то почему бы и не использовать? Но дело в том, что TRNG по природе может и не быть равновероятностным, и неизвестно существует ли такой источник (даже квантовый).
> Именно потому что люди думают что TRNG волшебным образом бессмертные и в
> результате криво этим пользуются, из linux выпилили /dev/random, решив все проблемы
> с зависаниями от недостатка энтропии и при этом не в ущерб
> безопасности.Не понял мысли, в смысле бессмертные?
> Нука найди мне что-то без этого что требованиям к CSPRNG соответствует.Могу привести только один пример, это случайная перестановка, для которой требуется TRNG.
//en.wikipedia.org/wiki/Random_permutation
пс: крипто-силу перестановок специально замалчивают. Существует совершенный крипто-алгоритм основанный на перестановках (своего рода одноразовый блокнот, но на перестановках)!
> пс: крипто-силу перестановок специально замалчивают.Потому что перестановки не изменяют распределение бит в тексте, если ты чистой перестановке передашь десять нулей - то десять нулей на выходе и будет, а значит она не спасает от частотного анализа.
Все нормальные алгоритмы использующие перестановку (diffusion) имеют ещё и подстановку (confusion).
И нет, генерация рандома к этому отношения не имеет.
> Потому что перестановки не изменяют распределение бит в тексте, если ты чистой
> перестановке передашь десять нулей - то десять нулей на выходе и
> будет, а значит она не спасает от частотного анализа.Так речь не о перестановке текста (битов открытого текста), речь о некотором перестановочном множестве, а сам открытый текст в него "энкапсулирован" (мечта Бекона) :))
> Все нормальные алгоритмы использующие перестановку (diffusion) имеют ещё и подстановку
> (confusion).Не все нормальные, а то что известно публике по теории Шеннона, но он практически умолчал (цензура) о силе перестановок. Я могу привести конкретный пример, но не буду. Да и ваша перестановка (diffusion) в том же aes - линейна, единственная нелинейность это блок подстановок (s-box).
> И нет, генерация рандома к этому отношения не имеет.
Случайная перестановка требует истинного рандома. Отсюда ее можно использовать как случайное значение.
Так как речь идет о 2^64 итераций (~10^19), то снижение на единицу на случайность практически не повлияет никак. Даже если CPU с частотой в 5ГГц (5*10^9) будет только выполнять RDSEED, то отсутствие нуля в качестве результата может быть замечено, в среднем, только через 10^9 секунд или через ~32 года. Выглядит вполне терпимо.
Вероятность не-нуля тоже повышается, поэтому все ~32 года ты получаешь числа с искаженной, увеличенной вероятностью.
> Вероятность не-нуля тоже повышается, поэтому все ~32 года ты получаешь числа с
> искаженной, увеличенной вероятностью.Но, как я показал, не существует способов обнаружить это искажение ранее, чем через 32 года. Так что, практического значения это не имеет.
Искажение можно обнаружить еще в теории, глянув на код, который отсекает ноль. И твои размышления про 32 года -- это тоже не "практика", а теория: на нормальном процессоре нормальный ноль может вернуться и через год, и через минуту спустя начала теста. Невозможно уменьшить вероятность нуля, не повысив вероятность не-нуля.
> Искажение можно обнаружить еще в теории, глянув на код, который отсекает ноль.Я уже доказал, что это теоретическое искажение практического влияния не имеет.
> И твои размышления про 32 года -- это тоже не "практика",
> а теория: на нормальном процессоре нормальный ноль может вернуться и через
> год, и через минуту спустя начала теста.Вы очень поверхностно представляете себе теорию вероятностей. Не важно когда "может", важно сколько нужно экспериментов, что можно было обнаружить отличие распределения от белого шума. В данном случае, нижний предел - 2^64 экспериментов суммарной длительностью свыше 32 года.
Так как ни один из этих CPU столько не прослужит, то практически невозможно столкнуться с неравномерностью распределения случайных чисел на нем, в случае исключения нуля.
> Я уже доказалТо есть вы доказали, что период внутреннего состояния вашего генератора - максимален (2^64)? :)
>> Я уже доказал
> То есть вы доказали, что период внутреннего состояния вашего генератора - максимален
> (2^64)? :)Вот из подобных утверждений я и делаю вывод, что Вы очень плохо представляете себе понятие вероятности. Никакого внутреннего состояния у генератора случайных числе нет и быть не может.
В противном случае - это будет уже генератор псевдослучайной последовательности.Какое внутреннее состояние у стабилитрона в режиме обратного пробоя? )))
> Никакого внутреннего состояния у генератора случайных числе нет и быть не может.:)) то что он генератор говорит о том, что он представлен в виде алгоритма, а результат его работы - ПСЕВДОСЛУЧАЕН!!! Отсюда и название prng. И у него есть всегда внутреннее состояние, а то с чем он будет работать?
> В противном случае - это будет уже генератор псевдослучайной последовательности.
Так он такой и есть, вы сами себе противоречите. 2^64 это именно его внутреннее состояние.
Вот описание у амд
//www.amd.com/content/dam/amd/en/documents/developer/amd-secure-random-number-generator-library-2.0-whitepaper.pdf
На рисунке 1.
1. Noise Source: The RNG uses 16 separate ring oscillator chains as the noise source.
During runtime, the 16 ring oscillators are continually sampled to generate noise
values.2. Entropy Conditioner: The 16-bits of ring oscillator noise are fed into the entropy
conditioner, based on AES-256[1] CBC-MAC[2], which gathers multiple noise
samples over time to use in generating the entropy needed by the RNG design. To
create a seed value, 3 iterations are executed, each generating 128 bits of full entropy,
thus generating a 384-bit seed. The seed is then fed into the deterministic random bit
generator, AES-256 CTR_DRBG module.3. Deterministic Random Bit Generator (DRBG): AMD RNG design includes a
deterministic random bit generator, based on AES-256 CTR_DRBG construct. It
uses the 384-bit seed value from the entropy conditioner and produces fast, highquality random values. The values are stored in a FIFO buffer to support fast read
bursts. Maximum of 2048 32-bit samples are generated per seed by the DRBG
module. It attempts to aggressively re-seed well before this limit is reached. The
DRBG module is compliant with NIST SP 800-90A standard [1] for random bit
generation.> Какое внутреннее состояние у стабилитрона в режиме обратного пробоя? )))
To create a seed value, 3 iterations are executed, each generating 128 bits of full entropy, thus generating a 384-bit seed.
Это называют внутреннее состояние.
пс: вся ваша случайность в этом конкретном примере и криптостойкость основана лишь на вере в aes, и его свойствах и лавинных критериях.
>> Никакого внутреннего состояния у генератора случайных числе нет и быть не может.
>> В противном случае - это будет уже генератор псевдослучайной последовательности.
> Так он такой и естьЧитать умеете?
> 1. Noise Source: The RNG uses 16 separate ring oscillator chains as the noise source.Что в статье написано сумели прочитать?
>> обратил внимание на проблему с работой инструкции RDSEEDПо ссылке, прочитать содержимое которой Вы не осилили, указано, что RDSEED - хеш функция от 16 генераторов белого шума, которая ну никак не может быть псевдослучайной.
В документе AMD популярно объясняется, чем "hardware random number generator" лучше "software based
pseudorandom number generator" и почему в "AMD Cryptographic Co-processor" реализовано именно первое. Как Вы умудрились этого не увидеть - для меня загадочно )))
> которая ну никак не может быть псевдослучайной16 separate ring oscillator chains as the noise source
это вот вы называете генератором? это источники энтропии (случайности) и они могут быть любые и никак не является генератором, генератор там по картинке далее по стрелке.
> В документе AMD популярно объясняется, чем "hardware random number generator" лучше "software based
по ссылке описан именно железный генератор, это в железном генераторе используют AES-256 CTR_DRBG, вот он ваш CSPRNG, а за обычный PRNG у них AES-256 CBC-MAC.
> Как Вы умудрились этого не увидеть - для меня загадочно
У них реализован CSPRNG детерминированный, а PRNG это необходимость (первичен), и все это в железе, о софтверной реализации вообще речи не шло (где я такое писал?), алгоритм есть алгоритм, а вот реализация - аппаратная. А в конце там буфер (на картинке), для чего он? :)
>> которая ну никак не может быть псевдослучайной
> 16 separate ring oscillator chains as the noise source
> это вот вы называете генератором?Если Вы не знаете английского, переведу - это источники шума. А любой генератор случайных чисел базируется именно на источниках шума, в отличии от псевдослучайных. И по Вашей же ссылке это весьма популярно разжевано. Воспользуйтесь хотя бы гугл-переводчиком, если не можете понимать текст на английском.
>> В документе AMD популярно объясняется, чем "hardware random number generator" лучше "software based
> по ссылке описан именно железный генератор, это в железном генераторе используют AES-256Который необходим, чтобы из источников шума получить уже случайные целочисленные значения в заданном диапазоне.
> А в конце там буфер (на картинке), для чего он? :)
Так как RDSEED работает некорректно, то забудьте о RDRAND и буфере. Они не применимы. А вот если применить AES-256 CTR_DRBG программно к значениям кроме нуля, возвращаемым RDSEED, то и получим то, что нам требуется. На что явно и указал Jason A. Donenfeld: "your 10% failure rate, that's still 688 bits, which is roughly 2.69x as much as we really "need" anyway."
https://lore.kernel.org/lkml/aPK-2iYHnt8DYFAF@zx2c4.com/
> Который необходим, чтобы из источников шума получить уже случайные целочисленные значения в заданном диапазоне.Это алгоритм!!! вы получаете не случайные, а псевдо-случайные!!! CS (криптографик секюр) PRNG (генератор псевдо-случайных чисел) - используется в криптографии!!! И это не RNG и тем более не TRNG.
> Так как RDSEED работает некорректно
В смысле, он работает не корректно? У вас разве результат 128 бит aes блока не может в 64 последовательных битах быть нулями? Это один столбец или строка блока или как там выбирается эти 64 бита у них, хз.
> А вот если применить
А где гарантия, что при некорректно работающем RDSEED он выдает равномерно распределенные остальные значения? Таким макаром там и какое-то другое определенное значение в диапазоне от 1-2^64-1 может вообще с большим процентом выпадать, этого же ведь не тестили, столкнулись случайно со статистикой нуля. Зачем не проводим тщательного разбора полетов, "вы" (Jason A. Donenfeld) сразу предлагаете совершенно бездарный воркараунд? С точки зрения безопасности это не приемлемо! Решение ввести полный мораторий на использования данной функции до полного выяснения причин, считаю совершенно верным.
> Это алгоритм!!! вы получаете не случайные, а псевдо-случайные!!!Очень интересно. Вы можете доказать, что этот алгоритм из белого шума формирует псевдослучайную последовательность? Можете предоставить формулу, которая на основании предыдущих значений предскажет следующее?
> Можете предоставить формулу, которая на основании предыдущих значений предскажет следующее?Я смотри вы проводили схемотехнический анализ имплементированного на чипе генератора? В студию полный даташит этого генератора. Этой инфой даже ваши линух девелопперы не обладают.
>> Можете предоставить формулу, которая на основании предыдущих значений предскажет следующее?
> Я смотри вы проводили схемотехнический анализ имплементированного на чипе генератора?Сначала ответьте на мои вопросы.
> Сначала ответьте на мои вопросы.//en.wikipedia.org/wiki/Dual_EC_DRBG
В этом конкретном случае да предсказывается! И это такой же принятый и продвинутый анб стандарт был.
пс: повторяю, если вам нужен точный ответ (формула, как вы выразились), предоставьте мне полную схематехнику имплементированного алгоритма.
> теоретическое искажение практического влияния не имеетКак это не имеет, если буквально каждое число, выводимое генератором, является искаженным, с искусственно повышенной вероятностью за счет нуля?
> Вы очень поверхностно представляете себе теорию вероятностей.
Это не я рассказывал про то, что при нормальном генераторе ноль встретится лишь через 32 года. Твоя ошибка в том, что ты считаешь, что у случайностей есть состояние. Спойлер: его нет. Именно поэтому твое убеждение, что ноль встретится лишь через 32 года, является заблуждением. Ноль запросто может встретиться три раза подряд и сразу после начала теста -- и это при нормально работающем генераторе! Вероятность этого ненулевая. Искусственно уменьшая вероятность нуля до нуля, и увеличивая вероятность остальных чисел, ты делаешь результат менее распределенным, и основываешь ты это на теории, которая гласит, что "моя теория на самом деле не теория, а практика". Спойлер: твои измышления -- теоретические от самого начала и до конца, и к практике отношения не имеют.
> Как это не имеет, если буквально каждое число, выводимое генератором, является искаженным,
> с искусственно повышенной вероятностью за счет нуля?На 2^(-64), что пренебрежимо мало.
>> Вы очень поверхностно представляете себе теорию вероятностей.
> Это не я рассказывал про то, что при нормальном генераторе ноль встретится
> лишь через 32 года.И я этого не говорил. У Вас глюки )))
Я писал:
> не существует способов обнаружить это искажение ранее, чем через 32 годаПри этом доказать существование этого искажения изучением событий невозможно никогда.
> доказать существование этого искажения изучением событий невозможно никогдаНевозможно доказать, что генератор, выдающий ноль в 10% случаев, работает некорректно. Может быть мы просто в той вселенной, в которой числа генерируются именно так? That is, даже нормальный генератор, предоставленный самому себе, в некоторых вселенных из multi world interpretation, будет временами выдавать ноль в 10% случаев в каком-то временном отрезке. Может мы обнаружили себя именно в такой вселенной и в таком временном отрезке? Кто знает...
А раз невозможно доказать некорректность генератора из практики, значит практику придется отбросить полностью и выходить обратно на уровень теории. И в теории [т.е. до практики] мы видим, что реализация генератора некорректная, следовательно, от него стоит полностью отказаться. Игнорирование нуля не сделает генератор "более корректным" -- тут нет градаций. Генератор либо корректен, либо нет, tertium non datur.
>> доказать существование этого искажения изучением событий невозможно никогда
> -- тут нет градаций. Генератор либо корректен, либо нет, tertium non
> datur.В таком случае, корректных генераторов в природе не существует, так как все известные источники случайных сигналов зависят от значений какого-либо атрибута физической среды, который практически невозможно смоделировать ПРИ ТЕКУЩЕМ УРОВНЕ ЗНАНИЙ.
Это даже не касаясь того, что значения любого атрибута физической среды могут выходить за пределы минимума и максимума генератора случайных чисел. Что можно решить только снижая вероятность таких событий, но исключить полностью их всё равно нельзя )))
От генератора требуется быть непредсказуемым и выдавать значения равномерно. "Не выдает нули" -- это предсказуемость и неравномерность. Вот и все.
> От генератора требуется быть непредсказуемым и выдавать значения равномерно. "Не выдает
> нули" -- это предсказуемость и неравномерность. Вот и все.Предсказуемость с вероятностью 2^(-64) - это меньше, чем вероятность распада протона за время существования Вселенной. А о равномерности в применении к белому шуму вообще речи быть не может по его определению.
> это меньше, чем вероятность распада протона за время существования ВселеннойДавай объясню на пальцах. Имея множество S всех возможных значений { 0, 1, ..., N - 1 }, вероятность выпадения любого элемента X должна быть такой:
P(X) = 1 / N
Это то, как должно быть, точка. Ты же предлагаешь что-то вообще бредовое:
P(X = 0) = 0
P(X ≠ 0) = 1 / (N - 1)Это совершенно недопустимо с точки зрения криптографических алгоритмов, и не важно, какова мощность множества. Причина первая: криптоалгоритм ожидает, что иногда возвращается ноль, а ты его не возвращаешь никогда. Причина вторая: криптоалгоритм ожидает, что остальные числа возвращаются с вероятностью 1 / N. А ты повышаешь их вероятность до 1 / (N - 1). Думаю, не стоит тебе объяснять, что:
0 ≠ 1 / N
1 / (N - 1) ≠ 1 / NМожет быть для твоего локалхоста, генерирующего поле для сапёр.exe, такое бы сгодилось, но в standard-compliant системах предлагаемый тобой забагованный RNG не допускается. Важнейший пользователь линукса -- это энтерпрайз и корпорации с серьезным бизнесом, с криптовалютами, обычными валютами, банкингом, эл. подписями и так далее, следующие каким-то стандартам, разработанными в том числе математиками. И твой забагованный RNG там все ломает напрочь.
>> это меньше, чем вероятность распада протона за время существования Вселенной
> Давай объясню на пальцах.Ну Вы на пальцах и показали тоже самое. Вероятность появления хотя бы одного нуля в последовательности случайных 64-битных целых чисел приблизится к единице не ранее, чем через 32 года и только в случае, если CPU будет заниматься только генерацией этой последовательности с частотой 5 миллиардов чисел в секунду.
> Это совершенно недопустимо с точки зрения криптографических алгоритмов, и не важно, какова
> мощность множества.А вот такое утверждение требует доказательства.
> Причина первая: криптоалгоритм ожидает, что иногда возвращается ноль,
> а ты его не возвращаешь никогда.https://ru.wikipedia.org/wiki/%D0%94%D0%...
> Причина вторая: криптоалгоритм ожидает, что
> остальные числа возвращаются с вероятностью 1 / N. А ты повышаешь
> их вероятность до 1 / (N - 1).Тоже самое.
Так что, если хотите что-то доказать, то прекратите применять демагогию.> И твой забагованный RNG там все ломает напрочь.
Это при том, что ни один из этих CPU просто не доживет до тех времен, когда вероятность появления нуля превысит хотя бы вероятность попадания метеорита ровно Вам в темечко? )))
> когда вероятность появления нуля превысит хотя бы вероятность попадания метеорита ровно Вам в темечко?харэ троллить, у вас новость ровно о том, что вам в темечко и прилетает в 10% случаях.
>> когда вероятность появления нуля превысит хотя бы вероятность попадания метеорита ровно Вам в темечко?
> харэ троллить, у вас новость ровно о том, что вам в темечкоВы сами захотели заняться демагогией. А троллить демагога - дело святое )))
> и прилетает в 10% случаях.Которые и предлагается считать ошибочными так же, как и остальные с CF=1. Вас же не смущает, что CF=1 может легко возникать даже в более, чем 10%, если Вы попробуете каждый такт выполнять RDSEED? )))
CF=1 это всего лишь сигнал о готовности данных.пс: на этом думаю надо заканчивать.
> Вероятность появления хотя бы одного нуля в последовательности случайных 64-битных целых чисел приблизится к единице не ранее, чем через 32 годаАга, причем всё это время, все 32 года, тебе прилетают числа, которые должны были прилетать реже. У тебя иллюзия, будто вероятность появления ненулевых чисел не изменилась. А я тебе математически (нет, даже арифметически, как пятикласснику) показал, что она увеличилась. Все 32 года. Проц. Присылал тебе. Числа. Чаще, чем надо. А ты делал вид, что все в порядке. При этом удивиться "а чёй-то мне ноль не приходит?" ты собирался через 32 года. А удивиться надо было прям во время самого первого броска кости: "а чёй-то вероятность ненуля увеличилась?"
> такое утверждение требует доказательства
Погугли, какие бывают источники случайных чисел, а также загляни в любую апишку RNG любой стандартной библиотеки любого языка. Удивись, увидев, что там стоит явная приписка, для каких случаев использовать тот или иной генератор. У гипотетического getRandomNumberButZero() стояла бы приписка: "годится только для сапёра; для криптографии не использовать, так как математически^W арифметически доказана его забагованность".
>> Вероятность появления хотя бы одного нуля в последовательности случайных 64-битных целых чисел приблизится к единице не ранее, чем через 32 года
> Ага, причем всё это время, все 32 года, тебе прилетают числа, которые
> должны были прилетать реже.Но никаких практических средств обнаружить это за время жизни CPU нет.
> показал, что она увеличилась.
Но увеличилась на такую величину, что даже путем специального исследования обнаружить это не удастся
> При этом удивиться "а чёй-то мне ноль не приходит?"
Так он может вообще никогда не прийти. И это совершенно нормально )
>> такое утверждение требует доказательства
> Погугли, какие бывают источники случайных чиселЗачем мне гуглить, если я сами их не раз делал?
> гипотетического getRandomNumberButZero() стояла бы приписка: "годится только для сапёра;
Это Вы называете доказательством того, что генератор случайных чисел от 1 до 2^64-1 не является генератором случайных чисел и не может быть использован в криптографии? )))
Вы будете, наверное, сильно удивлены, что в криптографии до сих пор применяются генераторы случайных чисел от 0 до 2^32-1. И в подавляющем большинстве случаев этого достаточно. По крайней мере АНБ допускает использование даже 24-х битных генераторов случайных чисел. А в максимально критичных случаях минимумом заявлено 40 бит, что в миллионы раз меньше, чем в нашем случае.
> По крайней мере АНБ допускает использование даже 24-х битных генераторов случайных чисел.Задайтесь вопросом, кому оно разрешает такое? Себе? :))
>> По крайней мере АНБ допускает использование даже 24-х битных генераторов случайных чисел.
> Задайтесь вопросом, кому оно разрешает такое? Себе? :))Ну да, себе и прочим ведомствам США, которые обязаны соблюдать его требования. Включая ЦРУ, ФБР и Пентагон.
> Ну да, себе:) Требования к самим себе никогда в публичном доступе опубликованы быть не могут, даже Сноуден не знает их!
> В таком случае, корректных генераторов в природе не существуетТак это открытый вопрос, не надо открывать америки, никто не доказал и не опроверг детерминизм вселенной, существует ли вообще случайность и т.д. Случайность в природе распределяется по законам природы (нормальное распределение), и быть равновероятной (равномерно распределена) она не обязана, как требует этого криптография.
> При этом доказать существование этого искажения изучением событий невозможно никогда.Новости бы этой тогда бы не было, в чем дело? У вас в 10% случаях выдает 0, о чем это говорит?
>> При этом доказать существование этого искажения изучением событий невозможно никогда.
> Новости бы этой тогда бы не было, в чем дело? У вас
> в 10% случаях выдает 0, о чем это говорит?О том, что эту проблему нужно решать. И один из вариантов решения - считать нулевое значение RDSEED некорректным, вне зависимости от значения флага CF.
А вот отказ от RDSEED в некоторых сценариях может привести к тому, что энтропия перестанет быть случайной и станет исключительно псевдослучайной, о чем и писал Jason A. Donenfeld: "your 10% failure rate, that's still 688 bits, which is roughly 2.69x as much as we really "need" anyway."
https://lore.kernel.org/lkml/aPK-2iYHnt8DYFAF@zx2c4.com/
> И один из вариантов решениясамообман это чистой воды!!!
> что энтропия перестанет быть случайной и станет исключительно псевдослучайной
RDSEED хоть и написано, что это лоу-левел бла бла бла, посмотрите на картинку в документации амд, там этот ваш RDSEED это результат трех AES-256 CBC-MAC (create a seed value, 3 iterations are executed, each generating 128 bits of full entropy, thus generating a 384-bit seed), из которого выдернули 64 бита информации и это по определению никакой не рандом, это псевдо-рандом. Нету у вас случайности о которой вы говорите, случайность - истинная которая, не является и не должна являться результатом какого-либо детерминированного алгоритма!!!
> much as we really "need" anyway
с чего он взял что этого достаточно? что за предположения? и точно знает что этот RDSEED используют многие и он о них думает. Как по мне это тупо анбешная прокладка, тут говорить не о чем. Мы самого аппаратного устройства этого самого RDSEED не знаем, и как он вообще прошел тесты того же NIST тоже вопрос, если обычный человек снял статистику и заметил такое.
пс: анб не даст никому реализовать ни нормальный алгоритм шифрования ни генератор случайных чисел, это все противоречит их сущности.
> Нету у вас случайности о которой вы
> говорите, случайность - истинная которая, не является и не должна являться
> результатом какого-либо детерминированного алгоритма!!!Учите английский. Алгоритм не может быть детерменированным, если основан на белом шуме.
>> much as we really "need" anyway
> с чего он взял что этого достаточно?А Вы почитайте. Он это объяснил.
> знает что этот RDSEED используют многие и он о них думает.
Знает и утверждает, что его использовать из-за выявленной ошибки недопустимо, без применения криптографических функций, исключающих нулевые значения.
> Мы самого аппаратного устройства этого самого RDSEED не знаем
Как это не знаем? 16 стабилитронов генерируют белый шум, который оцифровывается АЦП и результат корректируется для равномерного распределения AES-256 CBC-MAC.
> Учите английский.Вам бы толковый словарь открыть, алгоритм по определению - это описание детерминированного (пошагового) процесса.
> исключающих нулевые значения.
Чем это страшен 0 в 10% и не страшен 123 в 15%? Вы доказали, что 123 в 15% не выпадает, если у вас уже в 10% выпадает 0? Откуда такая уверенность, что только 0 там грешит? Вот отсюда и считаю полным бредом предложенный вами воркараунд!
> Как это не знаем?
Схемы устройства в студию, мне ваши предположения не нужны!!!
> Вам бы толковый словарь открыть, алгоритм по определению - это описание детерминированного
> (пошагового) процесса.Детерменированность алгоритма обозначает лишь то, что он выдаёт один и тот же результат для одних и тех же исходных данных. Но так как исходные данные у нас недетерменированы, то недетерменирован и результат работы алгоритма.
>> Как это не знаем?
> Схемы устройства в студию, мне ваши предположения не нужны!!!Могу поинтересоваться, за сколько их согласны продать. Подробности в личку.
Если интересен только принцип, то он общеизвестен - многоканальная оцифровка шума стабилитронов в режиме обратного пробоя компараторами с дальнейшим применением сглаживающей криптографической функции.
> Детерменированность алгоритма обозначает лишь то, что он выдаёт один и тот же результат для одних и тех же исходных данных.Детерменированность необходима именно для CSPRNG, я повторяю свой вопрос, который давал выше - какие основные требования к CSPRNG?
> Но так как исходные данные у нас недетерменированы, то недетерменирован и результат работы алгоритма.
Если ваш алгоритм линеен, то он обратим!!! И какие бы не были недетерминированные (случайные) входные данные это не повлияет на его взлом!!! Алгоритм должен быть нелинейным (что и объясняет использования aes) либо one-way (всякого рода крипто-стойкая хеш функция).
> Могу поинтересоваться, за сколько их согласны продать. Подробности в личку.
Мне они не интересны, денег за такое Г давать не собираюсь.
> Если интересен только принцип, то он общеизвестен
И уязвим, я думаю (конечно же до применения этапа "сглаживания").
Явно аноним не ходил на теорвер.Надо не ретрай делать, а при помощи формулы Байеса сделать выравнивание вероятности до равномерного.
Предполагаеморавномерного.
На Fedora вот такое выдает FALSE через несколько случайных цикловset -euo pipefail
x=0
while ldconfig -p | grep -q 'libc.so.6'; do
echo "$((x++))"
done
echo "FALSE"
По твоему мнению, что этот бессвязный набор букв делает?
А если так
x=0 ; while z=`ldconfig -p` && echo $z | grep -q 'libc.so.6' ; do echo -n "$((x++)) " ; done ; echo $zу меня на убунте в первом варианте вылетело на 148 и примерно на 2000, больше не вылетало
Квантовые технологии. Просто побольше количество попыток выполнить и можно будет подразумевать,что всё на самом деле хорошо с энтропией.
Бекдоры, ослабляющее генераторы случайных чисел определённым образом, вещь не то чтобы новая. Думаешь, с квантовыми технологиями не получится мухлевать?
По-моему квантовые как бв вычисления и есть мухлёж.
Требуем криминализировать злоупотребление квантовой запутанностью!
нет!!!
А Вы проверти!
На это и расчёт. )
AMD упорно наступает на одни и те же грабли.
может быть просто проц ещё не прогрелся и шума маловато
Плохая пайка. Китайцы.
Припой без свинца. Евроэкологи.
> шума маловатоШума вентилятора? Случайные числа надо получать считая количество пыли на кулере. Броуновское движение пылинок.
Пылинки - макрообъекты. Броуновское - это молекулы. :glasses:
Увеличить напряжение накала... Ой, я перепутал с Эльбрусом.
Аппаратуру не достаточно трясёт. )
Странно, что не в 2,02% ака 4.
если значение из RDSEED уже и так рано 0то можно не отключать использование RDSEED для инотропии…
зачем его отключать(?) если «0» (либо другое одно и тоже число) можно уже и так считать что «RDSEED не работает».
отключение RDSEED не даст ровным счётом ни чего — кроме ухудшения энтропии для тех 90% случаев когда оно не «0».
на AMD64: 0 - 2^64-1 нуля не должно быт практически никогда
//www.amd.com/content/dam/amd/en/documents/developer/amd-secure-random-number-generator-library-2.0-whitepaper.pdfДостаточно посмотреть на картинку.
Как пояснили разработчики: "Эта ошибка вышла случайно"
Вот поэтому для работы сижу на кор 2 дуо и оупенбсд. Эта связка максимально стабильная и безопасная. А более тонкие техпроцессы неизбежно приводят к аппаратным ошибкам и деградации кремния даже от простого использования. Имеется ещё комп на i9-9900k для игр. Так он стабильно зависает минимум раз в 3 дня. Причём зависание аппаратное, т.к. в логах нет ничего от слова совсем. И зависает так, что помогает только кнопка reset.
Потому что эту печку охладить нормально не можешь. У топовых интелов техпроцесс размером с бревно. Топовые процы только АМД если под игры. А не секурность.
Вот текущие флагманы:
- https://www.techpowerup.com/cpu-specs/core-ultra-9-285k.c3773
- https://www.techpowerup.com/cpu-specs/ryzen-9-9950x.c3649
А новые Intel "Panther Lake" будут изготовлены в Аризоне по техпроцессу 18A (18 ангстрем = 1,8 нм).
Сколько покупателю за это придётся заплатить?
Ну это буквально передовые полупроводниковые технологии.
если у тебя на борту есть Intel Management Engine у меня плохие новости
А если на борту AMD Platform Security Processor ?
Конфликт чипов? Это интересно. Война внутри коробки!
Конфликт качества. Сам взяпался в это. Турбо буст интела жжёт на овервольтаже - несмотря на то, что недавно были новости о "браке в 13-14 поколениях", на тематических форумах всё чаще всплывают сдеградировавшие 8-9-10(особенно)-11(пик)-12-13-14(антитоп2, если прошивка стартовая) поколения.Про 3-7 поколения ничего не скажу, не было ни у меня, ни "в руках"; на 1-2 подобной дичи не было;
У амд та же ерунда с поколения 5000 - когда начал подниматься шум, что их цп не достигают "пиковых" значений за многие часы работы, амдшки выкатили биос, который может кратковременно выходить в опасную зону вольтажа.
p.s. секте свидетелей "кратковременный дефолтный овервольтаж безопасен" желаю познать мой опыт на собственной шкуре.
p.p.s. теперь любой цп любой шарашкиной конторки - если не мощная СЖО - это сразу выкл. турбо, либо полная ручная настройка, особенно на ноутбуках.
> особенно на ноутбуках.С ноутбуками всё ещё интереснее. Бенчмарки мало что говорят, так как современные ноутбучные процессоры большую часть времени работают на минимальной частоте. Чтобы поднять частоту, возникает значительная задержка, а иногда процессор вообще не повышает частоту, хотя и должен, из-за чего происходят неиллюзорные феерические лаги. Всё во имя маркетингового увеличения времени автономной работы от батареи и упомянутых выше проблем с техпроцессом.
Это другая проблема - не низкой надёжности, а плохой настройки "из коробки".Решается настройкой параметра "парковки ядер" на трояндовс7 и выше;
А на линуксах у меня ядра/гиперпотоки стартуют вместе с приложениями через "chcpu -e ядра", +привязка с помощью taskset (для ноутов и пк с TDP-лимтами можно настроить ещё и выбор плана (щас по памяти, т.к. на пк это не юзаю): echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor);
все 3 действия требуют рут -> запросы обслуживает демон, хотя можно сделать через suidЧастоты цп (в рамках от мин до базы) не трогал - можно и это твикнуть;
Частоты ноутбучной памяти хз можно сбросить на ходу или нет, но запарковать все планки, кроме одной - linux давно умеет (но это уже ощутимо порежет производительность в угоду батареи).
можно выключить в bios неиспользуемые устройства (прим. usb-порты) и т.п.При правильном настраивании ноута - отзывчивость выше, да и батарею удержит дольше (важно - турбо-буст выкл, и не забыть поставить прошивки, вкл. igpu).
> scaling_governorИ ваш ноутбук не теряет заряд батареи за 10 минут? Вообще, эту функцию лучше не использовать даже на настольных компьютерах. У меня на стационарном, далеко не самом старом ПК, энергопотребление в режиме простоя увеличивается с 2 Вт до 60, а вместе с этим возрастает и нагрев (охлаждение пассивное, нулевая толерантность к шуму).
Этот параметр выключает все сберегающие параметры и конкретное ядро работает просто на базовой частоте (если выключен турбо);Но если не выключен авторазгон - то да, ядро(а) попытается упереться в какой-либо лимит (tdp, температура, лимиты System Agent, лимиты tau, остальные не помню), и скорее всего сожжёт много ватт впустую, как у вас
Выше написано как "получить производительность" на ноуте.
А энергоэффективность уже настраивается правильным балансом расхода ресурса, в т.ч. поядерной настройкой.
Таким образом можно не только уменьшить потребление (например игры) - но и получить ускорение за счёт освобождения лимитов; например, для встройки
p.s. смотрел, как развлекаются над handheld-приставками msi claw энтузиасты - выжимают много производительности сверх стока; хотя они НЕ применяют и 70% возможностей настройки железки под нагрузку
> ядро работает просто на базовой частотеИ вы теряете половину производительности, на выходе получая комп уровня Athlon XP.
Верно! Ведь намного лучше, когда в нагруженной задаче ноут держит турбо аж около 15-30 сек на 5 ГГц, чтобы упасть не просто до базы, а аж сразу в защиту до 1,7 ГГц на несколько последующих минут!Уверен, ваше понимание строится на теории "больше герц - лучше", но увы, на устройствах с серьёзными ограничениями по в т.ч. охладу (ноуты), в тяжёлых для ЦП задачах, вы можете получить где-то прирост комфортной производительности (в играх меньше подвисаний), а где-то даже прирост абсолютной производительности (ускорение сборки крупного проекта на неск минут)
Понимаю, что убедить человека, без переноса знаний в его задачи практически невозможно;
Однако за последние лет 8, в сети набрали широкую популярность инструменты, вроде ThrottleStop - которые используются не для "ускорения, через уменьшение герц", а для контроля причин снижения производительности - перегрев, tdp-лимиты и т.п.
Вообще-то он прав. Бенчмарки с сухими цифрами вам в помощь, как говорится вместо тысячи пустых слов и надувания щек в стиле политбюро цк кпсс.
Разве проблему нельзя решить просто подключением внешнего Ethernet-адаптера или WiFi-модуля? Кстати, Intel Core 2 — последнее поколение, где это можно полностью выкорчевать с корнями под ноль.
> более тонкие техпроцессы неизбежно приводят к аппаратным ошибкам и деградации кремния даже от простого использованияКстати, 8 и 9 поколения действительно печально известны частыми зависаниями, особенно если не отключить c-states. А при постоянном повышении напряжения турбобустом начинаются необратимые изменения на самом кристалле. В своё время об этом много писали.
Про новые модели ничего не могу сказать, сижу на Core 2 Quad Q9650.
Я не пойму, чем им ноль не случайное число. Он имеет те же права быть случайным, как и 1, и как все остальные числа.
Опа, закладочку спалили, при определенных режимах можно понизить энтропию
Да и фиг с ней, с энтропией, новости не читаете? Не нужно париться с генераторами, как и переборами: программисты и мейнтейнеры сами все сливают в готовом виде.
> Опа, закладочку спалили, при определенных режимах можно понизить энтропиюВ случае современного линуха - толку с этой активности ноль: он энтропию из разных источников в пул подмешивает, не довреяя вслепую качеству энтропии никого из. Даже если выгружать одни нули - остальные источники вскоре сделают состояние пула не реконструируемым в плане его состояния и предсказаний значений. Его Донфилд подрихтовал в адекватное состояние, автор вайргада. Этот в крипто все же более-менее шарит в силу своей специфики.
А в системах с s-d еще по дефолту грузится в самом начале пул random seed с накопленной ранее энтропией который оно также ядру отдает как seed. Ибо в VM и эмбедовке с энтропией бывает душно - слишком детерминированные системы бывают. И когда выбор между заякорить программу ожидая энтропию или отгрузить низкокачественную энтропию потенциально подставив крипто - такой себе выбор.
А что с "HW_NRND_GEN.ready" Исследователи не уточняли?IF HW_NRND_GEN.ready = 1
THEN
CASE of
operand size is 64: DEST[63:0] := HW_NRND_GEN.data;
operand size is 32: DEST[31:0] := HW_NRND_GEN.data;
operand size is 16: DEST[15:0] := HW_NRND_GEN.data;
ESAC;
CF := 1;
ELSE
CASE of
operand size is 64: DEST[63:0] := 0;
operand size is 32: DEST[31:0] := 0;
operand size is 16: DEST[15:0] := 0;
ESAC;
CF := 0;
FI;
OF, SF, ZF, AF, PF := 0;
Прошу прощение. Присвоение CF не заметил.
Если так, то надо отзывать все процы.
Микрокодом поправят.
Что если "HW_NRND_GEN.ready" = 1 , а CF := 0 не происходит? Это же брак?
* Что если "HW_NRND_GEN.ready" = 0 , а CF := 0 не происходит? Это же брак?
Надо воспринимать 0 как HW_NRND_GEN.ready = 0 - генератор не готов и не принимать 0 в работу всегда.
У конкурента вполне возможно тоже самое. Просто у AMD нет такого отдела (или статьи финансирования) как у конкурента.
Так цифр то 10, вот каждая с 10% шансом и выдаётся.
> Так цифр то 10, вот каждая с 10% шансом и выдаётся.Это шутка такая?
"предложено вместо выборочной блокировки прекратить использование RDSEED"
А не проще 0x0 и 0xffffffff просто игнорировать?
> "предложено вместо выборочной блокировки прекратить использование RDSEED"
> А не проще 0x0 и 0xffffffff просто игнорировать?Это может создать новые проблемы с безопасностью. Вспомни историю со взломом Энигмы. Одним из факторов, который помог её взломать, заключался в обязательной замене буквы на другую.
> А не проще 0x0 и 0xffffffff просто игнорировать?И обнаружить что кто-то заимплмементил вон то с return 4? Оок! Да, разработчики отже XKCD читают :D
AMD снова знатно обделались. Ещё одна причина покупать процессоры лишь от Intel. Хотя и там тоже бывают проблемы, но не столь эпические.
В чем эпичность данной проблемы, сможете на пальцах объяснить ?
Или просто продаван от интела ?
> AMD снова знатно обделались. Ещё одна причина покупать процессоры лишь от Intel.
> Хотя и там тоже бывают проблемы, но не столь эпические.Ну да, незначительные проблемки. Типа подыхания проца за полгода эксплуатации от косяков с выбором вольтажа и общим уровнем инженерии интела. Недостаточно эпично наверное, только финансовые отчеты интела с этим что-то не согласны.
>Типа подыхания процаНу тогда вам лучше не стоит гуглить "ryzen сгорел".
> Ну тогда вам лучше не стоит гуглить "ryzen сгорел".Нюансик в том что у интеля они вообще целыми семействами массово выгорают - и эффект настолько жесткий что интел признал проблему и выкатил затыкание факапа микрокодом. С уточнением что если проц уже впал в паразм - апдейт микрокода ему уже не помогает, конечно.
>у интеляСудя по всему вы фанатик, поэтому вам тяжело воспринимать реальность.
Адекватные люди видят, что проблемы есть у обеих компаний, и у Интела и у АМД.
>массово выгораютВы видимо не сильно следите за "железной" темой, у Ryzen массово горели и 7000-я линейка и 9000-я.
> предполагается, что в процессорах AMD имеется ошибка, приводящая к неверному определению состояния операции."return 4; // Chosen by fair dice roll!"
> fair diceу реального fair dice дырочек на гранях быть не должно (только цветовое различие, хотя даже оно имеет значение ибо каждый цвет (пигмент) имеет свой вес), ведь неравномерность получается когда на одной стороне одна дырочка (выемка, ямка), а на другой их 6, ну и какая сторона тяжелее?