Привет-привет! С вами снова Оля — программист Учебного центра компании «Тензор»... и радиофизик. До этого я рассказывала вам о рабочих кейсах, а сегодня поведаю о программистско-астрофизическом эксперименте.
Бывало ли на вашем пользовательском веку такое, что компьютер внезапно завис или не смог прогрузить страницу? Грешили ли в этот момент на проклятую технику? А ведь причина может быть в другом — космическое излучение могло быть источником ваших бед! В этой статье разберем уязвимость с самого известного фреймворка cwe.mitre.org.
Историческая справка
Бельгийские вафли, выборы и голос технологий
В 2003 году в Бельгии проходили выборы, на которых большая часть избирательных участков была оборудована для электронного голосования. Во время подсчета результатов организаторы столкнулись с проблемой: на одном из участков не сошлось количество голосов. В сумме их оказалось больше, чем нужно. Чтобы понять причину, пришлось перепроверять всё вручную. Выяснилось, что компьютер правильно посчитал голоса за всех кандидатов, кроме одного: Мария Виндевогель получила на 4096 голосов больше, чем за неё проголосовали.
В поисках ответа на вопрос, как такое могло произойти, эксперты тщательно протестировали и программу, и железо. Ошибок обнаружено не было. Местные программисты терялись в загадках до тех пор, пока кто-то не задумался: почему разница составила именно 4096?
Загадочное число
С точки зрения компьютера 4096 — это 2 в 12-й степени. Если записать это число в двоичной системе счисления, внутри процессора оно будет выглядеть так:
0001 0000 0000 0000
Получается, чтобы Мария получила лишние 4096 голосов, достаточно поменять один бит во время обработки голосов:
Было: 0000 0010 0000 0010 (514 голосов)
Стало: 0001 0010 0000 0010 (4610 голосов)
Как бит случайным образом изменился в памяти компьютера?
Причины сбоев или бодрые космические частицы
Космос переполнен волнами и частицами: радиоволны, гамма-излучение, всевозможные электроны, нейтрино и т.п. Атмосфера Земли, конечно, защищает человечество от доброй части этого хозяйства. И всё-таки, если частица достаточно бодрая, энергия позволяет ей пройти сквозь любые барьеры, достигнуть Земли и поставить подножку транзистору микросхемы, выбив из нее заряд. Так в ячейке памяти и возникают незапланированные 0 или 1. Это явление зовется «нарушением в результате единичного события» (single-event upset, SEU).
Бодрых частиц в космосе много. Очень. Поэтому, случайная бомбардировка ими микросхем — не редкость, в любой момент значение любого бита может измениться (живите с этим).
Утечка данных
Описанный феномен может приводить к утечке конфиденциальных данных. В 2010 году исследователи выяснили, что на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней. Так бит может измениться в участке памяти, где записан адрес сайта, на который происходит переход: пользователь ввел в адресную строку браузера домен windows.com, бит перевернулся аки Сивка-Бурка — адрес поменялся на, скажем, windo7s.com и запрос ушел на совсем другой сервер.
Страх в том, что домены с измененным символом могут быть использованы для перехвата конфиденциальной информации. Причем, чтобы получить трафик на такой сайт и делать-то ничего не нужно, только тихонечко подождать единичного события, которое перевернет бит у пользователя. Рай для мошенников!
Такой способ перехвата данных называется Битсквоттинг (Bit-squatting). На примере сайта windows.com исследователи получили более 200 000 событий за 14 дней, так как каждый компьютер на ОС Windows сверяет свои часы через сайт time.windows.com. (https://xakep.ru/2021/03/05/bitsquatting/).
Рубрика «Эксперименты»
Суть и подготовка
Мне, как патриоту Тензора и СБИСа, конечно, тяжело было жить с мыслью о коварных космических частицах, вторгающихся в сервера компании. Именно поэтому в 2022 году я отважилась на проверку возможности получения конфиденциальных данных с сайта нашей компании (например, online.sbis.ru).
Я ждала аншлага, ведь к тому моменту у Тензора уже было более 3,5 млн клиентов — а значит вероятность обнаружения и регистрации хотя бы одного сбоя, была невероятно высока.
Я купила и зарегистрировала три свободных домена: online.sjis.ru, online.sbhs.ru, online.sbiq.ru. В каждом, как вы уже заметили, изменен один символ на один бит. Другие названия, к сожалению, уже были заняты мошенниками.
На арендованном хостинге я создала простой сервер и ждала переходов на наши сайты. Чтобы отслеживать запросы было поудобнее, написала html-страницу.
Гости
Время шло — вызовы не приходили, но я не сдавалась. Чтобы увеличить вероятность поймать вызов от ошибки SEU, дополнительно купила несколько доменов «Сбербанка» и «TikTok».
Когда вызовы наконец появились, оказалось, что они не подходят под ошибку SEU. Результаты приходили с разных доменов. Это можно объяснить тем, что наши сайты пытались проверить на уязвимости.
Выяснилось, что по сайтам могут ходить боты, которые проверяют на прочность все домены подряд, интересуясь в основном сайтами, написанными на PHP. Однако, наш сервер написан на Python с использованием flask, поэтому никакие боты нам не угрожают.
Ниже примеры url, которые нам попались:
/debug/default/view?panel=config
/login?redirect=%2F
/Upload/upload_file.php?l=test
/manage/log/view?base=../../../../../../../../../../&filename=/etc/passwd
/getCorsFile?urlPath=file:///c://windows/win.iniИсходя из статистики, которую мы получили, выявили два критерия для определения, какие вызовы могли случиться из-за ошибки SEU.
Ждать запросы с «куками». В cookies передаются данные сессии, являющиеся конфиденциальными.
Ждать запросы, у которых в url есть «/service/». В случае sbis.ru эта часть используется для служебных вызовов, которые выполняет браузер при загрузке страницы. Наличие «/service/» в url не дает абсолютной гарантии, что все такие вызовы будут из-за ошибки SEU, но хотя бы исключит множество других запросов. Способ подходит только для доменов sbis.ru.
Кроме того, запросы, которые мы ищем, будут всегда приходить с уникального IP. Вероятность, что компьютер успеет выполнить несколько запросов на измененный домен из-за ошибки, крайне мала, так как следующий запрос будет сформирован заново и адрес уже не будет содержать ошибку.
Итоги эксперимента
Итак, к моменту написания статьи на наши домены пришло более 100 000 запросов. Некоторые сайты до сих пор работают и ждут SEU-события. К нашему сожалению, ни один вызов не был последствием внезапного удара космической частицы по «железу» компьютера. Вызовы с cookies, увы, не содержали сессии, а запросов с «/service/» в url было очень мало.
Надежда найти подходящий для события SEU вызов забрезжила среди множества входящих GET-запросов с пустым url. Но беглый анализ показал, что такого рода запросы выполняются в основном ботами, так как за относительно небольшое время приходило много вызовов с одного и того же IP.
Почему не получилось поймать ошибку? Может быть, активность космического излучения за последние два года не была высокой. Другое, более вероятное объяснение состоит в том, что на сегодняшний день практически не осталось техники, подверженной ошибки SEU. Такого рода ошибки сейчас корректируются и маловероятны. Тут, пожалуй, стоит только порадоваться качеству оборудования.
Все желающие могут сами попробовать найти интересные для вас запросы по ссылке.
Также прилагаю ссылку на уязвимость https://cwe.mitre.org/data/definitions/1261.html. Раз она есть на этом сайте, то точно заслуживает внимания. А сталкивались ли вы с космической проблемой?
Спасибо за прочтение, успеха вашим частицам!
Комментарии (123)
raamid
06.05.2024 11:06+7Интересный эксперимент. Я думаю, если финансы позволяют, есть смысл его продолжить чтобы дождаться активности на Солнце и проверить, будут ли случайные заходы.
Хотя, что-то мне подсказывает, что можно сделать гораздо проще. Можно написать программу, которая создаст 3 больших массива с одинаковыми данными и через определенные промежутки времени сравнивать их между собой. Или просто, вычислить контрольную сумму для каждого мегабайта и периодически проверять.
Shura_m
06.05.2024 11:06+4Я когда-то так и делал.
чтобы доказать, что в сетевом оборудовании есть какие-то сбои, файл из 10 миллионов нулей гонял по сети. За час появлялось пару измененных байтов.
isden
06.05.2024 11:06+16У вас сервера на проде без ECC? :)
ZlobniyShurik
06.05.2024 11:06+12Так, по идее, заходят-то клиенты на битфлипнутые домены. А у клиентов какой только хлам в качестве компов не стоит.
Правда, тут другая проблема вырисовывается - а где гарантия, что битфлип произошёл от заряженной частицы, а не из-за высохшего электролита на древней мамке и/или в кЕтайском БП?
isden
06.05.2024 11:06+2Пойду протру линзы :)
У меня сразу мысль появилась, что это имело бы хоть какой-то смысл на сервере - изменение ссылок в коде страниц (какой-нибудь горячий кэш nginx например). А на клиенте - это слишком многое должно наложиться чтобы произошло именно так. Кмк можно считать вероятность такого события стремящейся к нулю.
CoruNethron
06.05.2024 11:06+1У меня тоже коллизии с 1 апреля после прочтения.
Пусть, вероятность флипа какого-то одного бита в 4Гб памяти в течение 3 суток равна 0.96. Тогда, вероятность флипа того-самого бита за сутки будет 1e-11, если считать, что равновероятен флип любого из битов (однако, я не уверен, не имеет ли места быть что-то типа парадокса дней рождения, из-за чего вероятность поменьше). Пусть у домена 1млн посетителей в сутки и они проводят на сайте по 30 минут. Итого, 2e-7 вероятность такого события за день. Или 0.72% (0.0072) за 100 лет.
Путь лучше те мошенники ждут, что Вы промахнётесь пальцем по клавише.
ugenk
06.05.2024 11:06+17У исследователей был ntp, где достаточно одного пакета (с). У вас tls over tcp. Вряд ли вы дождетесь.
Zolg
06.05.2024 11:06Несомненно они врядли дождутся.
Но какой вклад в это вносит tls over tcp ? Вероятность того, что при безопасном для оператора радиационном фоне бит вадреседоменном имени будет испорчен непосредственно в момент установки соединения настолько мала, что ей можно полностью пренебречь.
А в ситуации когда где-то в памяти доолго лежит (попорченная за время лежания) строчка cадресомдоменным именем не так уж важно по udp ли будет идти коннект после резолвинга, или по tcp, а сверху - tls. Да, могут быть (а могут и не быть) нюансы с проверкой сертификата клиентом, но в логи сервера такие (попытки установки) подключения все равно попадут (при их правильной настройке).
edo1h
06.05.2024 11:06+3Как раз вероятность искажения бит в момент передачи очень высока, потому во всяких Ethernet избыточное кодирование. А поверх этого контрольные суммы в tcp. Ну а если ещё поверх этого и tls, то вероятностью непреднамеренного искажения можно вообще пренебречь.
Zolg
06.05.2024 11:06Исходная статья про ошибки связанные с воздействием ионизирующего излучения на электронные компоненты (в первую очередь - память), а не про помехи в линиях связи.
Впрочем, это не столь важно: ибо описанная в статье атака пытается эксплуатировать предположение, что у кого-то из пользователей в результате искажения бита станет испорченадресдоменное имя целевого ресурса. Процессу же разрешения доменного имени абсолютно безразлично, будет ли разрешенный адрес дальше использоваться для UDP, или TCP с TLS.
ps: нет во всяких Ethernet никакого избыточного кодирования. Лишние битики в поток данных добавляют (плюс скремблируют) не для коррекции ошибок, а для упрощения приемо-передающей части (в частности - возможности использования трансформаторной развязки, и синхронизации тактовых последовательностей).
sci_nov
06.05.2024 11:06В радиоканалах (wi-fi) применяют прямую коррекцию ошибок, FEC, а в медных каналах (over twisted) хватает повторного запроса по CRC. В оптике тем более только повторный запрос. То есть зависит от типа физической среды передачи.
sci_nov
06.05.2024 11:06Хотя в гигабитном ethernet over twisted применяется FEC, ибо скорость высокая (не 100 Мб/с), но та же среда передачи.
Zolg
06.05.2024 11:06+22на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней.
ввел в адресную строку браузера домен windows.com, бит перевернулся
Пусть даже не "ввел в адресную строку" (что требует переворота бита не за три дня, а за три секунды) а "где-то в памяти хранится". Мы же понимаем, что даже при 100% вероятности переворота одного бита в 4GB памяти, вероятность того, что этот переворот произойдет именно в 16 байтах time.windows.com -
, т.е. 0,0000004 %. А если учитывать то, что из этих 16 байт реально доступны для атаки всего 8 (.windows), а в этих байтах можно атаковать далеко не все биты, то шансы еще меньше.Впрочем количество количество windows ПК столь велико, что единичные (но никак не 200000) события с обусловленным SEU доступом к условному windo7s.com представляются относительно вероятными.
А вот затея со sbis.ru практически наверняка обречена на провал: во-первых буковок меньше, а в главных - на многие порядки менше количество ПК.
А сталкивались ли вы с космической проблемой?
Каждый раз, покупая ECC-память вы сталкиваетесь с ее решением (не 100%, но близким к тому).
Daimos
06.05.2024 11:06Крайне мало персоналок поддерживает ЕСС.
mpa4b
06.05.2024 11:06Нонче не проблема купить неынтерпрайзные проц, мамку и память, поддерживающие ECC. AMD-only. А ынтiль как обычно причмокивает :)
VADemon
06.05.2024 11:0690% персоналок на платформе AMD с 2017 г.
\* 10% упоротых моделей матерей, где ECC заводится только под Linux, потому производитель не удосужился хоть как-то включить ECC в прошивке. Поздние матери все без официальной на то поддержки заявляют работоспособность c ECC.
AuroraBorealis
06.05.2024 11:06Простите? Я уже двадцать лет как немного далек от компьютерного железа (хвала эппл, абстрагировала меня от этого), но всегда полагал intel - вендором с 70% рынка, а amd - фаблесс-конторкой на оставшиеся 30. А успехи AMD последних лет связанными с геймерами, то есть преходяще.
Хм, и первая ссылка в гугле согласна: In the second quarter of 2024, 64 percent of x86 computer processor or CPU tests recorded were from Intel processors, while 33 percent were AMD processors. When looking solely at laptop CPUs, Intel is the clear winner, accounting for 75 percent of laptop CPU test benchmark results in the second quarter of 2024
upd: извините, я понял - кажется, вы про наличие ECC на PC.. Комментарий можно удалить?
1dNDN
06.05.2024 11:06В эти "крайне мало" входят AMD Ryzen 2000, 3000, 5000 плюс 3000G Pro и 4000G Pro. Кроме того, ECC поддерживают некоторые модели Intel, в частности младшие i3 (например 9100), а так же, как будто бы, многие другие старшие модели intel, начиная с 12000 серии (но там вроде надо дорогой чипсет).
Ну и в DDR5 ECC насколько я понимаю во всех.
DirectX
06.05.2024 11:06DDR5 подавляющее число без ECC, хотя и можно найти модели из официального списка совместимости памяти с сайта производителя материнских плат. Есть даже обсуждение на Реддите на тему успешных конфигураций с ECC. И если коротко, там в основном упоминается ASUS X670 + память Kingston KSM48E40BD8KM-32HM.
Ситуация с DDR4 ещё хуже. Эксперимент по установке серверной памяти например на не самую старую гигабайтовскую материнку B550 + AM-4 + Ryzen 5950X успеха не имел даже с последними версиями BIOS.
edo1h
06.05.2024 11:06+2«серверная» память будет registered скорее всего, а ryzen поддерживают только unbuffered
sci_nov
06.05.2024 11:06+3Конечно корректируются. Вы попросту не дождетесь ошибочного события.
Единичные ошибки очень просто обнаружить и исправить. Это можно делать прямо в динамике работы оперативной памяти.
Zolg
06.05.2024 11:06+4Можно, нужно и давно делается в ecc-памяти.
Проблема только в том, что используется ecc‑память в основном в серверном оборудовании. В ПК, ноутбуках, планшетах‑телефонах по традиции продолжают экономить. Ну и в том, что SEU возможны не только в [основном объеме] памяти.sci_nov
06.05.2024 11:06Кажется, сейчас ЕСС память для коррекции одиночных ошибок не требуется, подтягивание битов (регенерация) реализовано во всех модулях, автоматом с коррекцией одиночных сбоев.
ЕСС это уже профессиональное решение с коррекцией более сложных паттернов ошибок.
Zolg
06.05.2024 11:06+5Какой бы алгоритм не применялся, в какой бы части системы он бы не был реализован, для того, чтобы распознать (а тем более - скорректировать) ошибку в хранимой информации должна присутствовать избыточность. Т.е. в случае памяти - дополнительный физический объем. Это стоит денег.
ЕСС это уже профессиональное решение с коррекцией более сложных паттернов ошибок.
Ну прям. Классический вариант - одну [ошибку в слове] исправляем, о двух и более - сигнализируем (если повезет).
sci_nov
06.05.2024 11:06Да, избыточность необходима.
Zolg
06.05.2024 11:06Вот за эту избыточность (место для ее хранения) деньги и берут. Не важно, по старинке ли она отдельным корпусом на модуле распаяна, или как в DDR5 непосредственно на кристалле. А в потребительских устройствах деньги экономят.
Да и к тому же в потребительских устройствах 90+% памяти занято картинками
с котикамии прочей устойчивой к искажениям единичных бит информацией: ну слетит один пиксель в каком-то элементе GUI, да и фиг с ним.sci_nov
06.05.2024 11:06В ядре ОС может быть software ECC
mayorovp
06.05.2024 11:06+2Не может: каждое обращение к памяти не перехватишь, это слишком долго.
sci_nov
06.05.2024 11:06Да по любому где-то это отслеживается/корректируется, иначе бы периодически ПК сваливались в BSOD. Где-нибудь вычисляются CRC для блоков и стоит, например, код Рида-Соломона в режиме восстановления стертого символа - блока, как это делается в data storage.
BugM
06.05.2024 11:06+5иначе бы периодически ПК сваливались в BSOD
Так они периодически и сваливаются. Раз во много лет это тоже периодически. Кому какое дело? Перезагрузили и поехали дальше. На всем важном стоит ECC память.
Программно валидировать память вам никаких ресурсов не хватит. Так никто не делает.
BugM
06.05.2024 11:06+2Какого я только бреда не писал в курсовых и дипломах. Не стоит воспринимать студенческие работы серьезно.
Tamashii
06.05.2024 11:06На какой странице есть сравнения производительности с и без SoftECC-реализации?
Ибо сдаётся мне, что автор откровенно лукавит.
Sun-ami
06.05.2024 11:06Там скорее не код Рида-Соломона - на него нужно довольно много дополнительной памяти - а простая перезагрузка страниц с диска. Может быть по ошибке CRC, а может быть просто периодическая. Потому что большая часть памяти, повреждение которой может привести к BSOD, занята исполняемым кодом, а он часто является просто файлом, отображенным на память, а если нет - его всё равно легко перезагрузить.
chupasaurus
06.05.2024 11:06В хранении данных скорость ответа не измеряется в наносекундах и IOPS - не в миллиардах.
Sun-ami
06.05.2024 11:06Речь шла про длительное хранение данных в оперативной памяти. Почему компьютеры без ECC не сваливаются в BSOD с периодичностью в сутки, если работают круглосуточно без перезагрузки.
PS поздно увидел, что это ответ не на мой комментарий. При добавлении контроля целостности кода в оперативной памяти дело не в IOPS и скорости ответа, а в расходе памяти и вычислительной мощности на контроль и восстановление программными средствами.
chupasaurus
06.05.2024 11:06В ECC программные средства на однобитные ошибки не задействуются в принципе уже давно, этим занимаются отдельные транзисторные цепочки (даже в L1 кэшах процессоров!). С многобитными история другая, т.к. появляется треугольник выбора "минимальное кол-во транзисторов - точность детектирования - минимальное время ответа", и коды Рида-Соломона не попадают в первый и третий критерии совсем.
sci_nov
06.05.2024 11:06С первым абсолютно согласен.
А вот по кодам Рида Соломона... не совсем. Они являются кодами с максимальным достижимым расстоянием, и точность обнаружения ошибок у них на высоте. С исправлением ошибок - проблема, но та же проблема и у кодов Хэмминга и у любых блоковых кодов. Лучше исправляют сверточные коды. А вот с режимом восстановления стертых символов у кодов Рида Соломона все очень хорошо)
По количеству транзисторов - что ж поделать, ресурс он и в Африке ресурс, особенно не с экономить. Код Рида Соломона - циклический код и описывается полиномом, экономнее уже некуда)
sci_nov
06.05.2024 11:06Тоже верно... Космические лучи ограничивают потенциал компьютерных систем человечества)
VADemon
06.05.2024 11:06В DDR5 тот ECC, о котором вы написали, только сглаживает изьяны производства кристалла.
sci_nov
06.05.2024 11:06Да, более распространены модули с коррекцией одной ошибки. Там абсолютная избыточность примерно log N, где N - длина слова в битах. Код Хэмминга) или определение локации ошибки методом деления пополам.
wataru
06.05.2024 11:06+1по традиции продолжают экономить.
Тут не столько традиция, сколько жадность intel, которые как-то сегментировали рынок для извлечения побольше прибыли. Часть этой стратегии заключалась в ограничении поддержки ECC только в серверных процессорах. Если бы не эта умышленная деталь, давно бы уже ECC распространилась во всей памяти.
Zolg
06.05.2024 11:06+1не столько традиция, сколько жадность intel
Не столь давно были времена, когда контроллер памяти был интегрирован не в процессор, а в чипсет (а самих производителей чипсетов для x86 было больше двух). И что-то и тогда не наблюдалось массового применения ECC в customer сегменте. Да и не массового, откровенно говоря, тоже не вспомню. Так что сегментировал рынок интел вполне следуя уже сложившейся традиции.
И это только про x86. Всякие ARM и причий MIPS интел под себя не подмял, но опять же не наблюдается что-то ECC ни в телефонах с хромбуками, ни в soho (и даже части не совсем уж и soho) маршрутизаторах. В последних, кстати, вполне уместно было б.wataru
06.05.2024 11:06В самых массовых конфигурациях ECC не поддерживается => нет спроса на такую память => нет предложения такой памяти.
iShrimp
06.05.2024 11:06+6Эта статья - напоминание каждому программисту (от ардуино до энтерпрайз-сегмента), что глюки и порча данных возможны в любой программе, даже написанной на самом безопасном языке и использующей самые математически точные алгоритмы. И это не обязательно приводит к полному отказу системы, она может какое-то время спокойно работать дальше :)
alysnix
06.05.2024 11:06+10предлагаю совместить исследования и неплохой заработок.
а именно - завести много-много банковских счетов, и как только на одном из них в результате сбоя от космического излучения окажется миллион долларов - немедля их снимать и бежать в Аргентину.
edo1h
06.05.2024 11:06Не прокатит, там контрольные цифры есть, надо испортить много бит чтобы обойти проверку
matabili1973
06.05.2024 11:06+6А вместо этого сменится какой-нибудь бит, отвечающий за знак числа, и в результате окажешься банку должен тот же миллион
alysnix
06.05.2024 11:06не забываем плюсовать мне карму, ибо завистники и интриганы, действуя в составе банды и по предварительному сговору, опустили мне ее по самое немогу.
заранее спасибо.
Serge78rus
06.05.2024 11:06+1Это не завистники и интриганы, это космическая частица с высокой энергией в ОЗУ сервера попала.
vvzvlad
06.05.2024 11:06ибо завистники и интриганы, действуя в составе банды и по предварительному сговору
Уменьшил влияние банд и предварительного сговора на вашу карму.
nv13
06.05.2024 11:06+8Крайне сомнительно, что сценарий включает какие то частицы, я быстрей поверю в разогнанное или некачественное железо, а то и в нейлоновые чулки, правда не в курсе носят их сейчас или нет)
В конце 90х меняющийся текст в NC под DOS или сообщениях загрузчика встречался, изменение настроек всяких таймингов и режимов BIOS иногда приводило к положительному результату. DOS и Windows при этом, как правило, продолжали работать, Linux мог зависнуть, Warp ругался и вис. Причина была в совместимостях и обычных сбоях обмена по шинам из за помех по питанию и некачественрого проектирования.
edo1h
06.05.2024 11:06+1Насколько я помню, с ростом высоты над уровнем моря число ошибок действительно растёт.
Но оценки вероятности сбоев, упомянутые в статье, сильно завышены по сегодняшним меркам, мы спокойно пользуемся ноутбуком и смартфоном в самолёте, да и на Марсе, считай лишённом зашиты магнитным полем и атмосферой, вертолётик с обычной консьюмерской электроникой достаточно долго и успешно летал.
nikolz
06.05.2024 11:06Интересно, если бы радиофизик был бы радио инженером, то он стал бы охотиться за космическими частицами бороздящими корпус компьютера?
saboteur_kiev
06.05.2024 11:06+5на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней.
Почему не получилось поймать ошибку? Может быть, активность космического излучения за последние два года не была высокой.
Тут еще нужно угадать, чтобы перевернулся именно тот бит, который отвечает за реквест урл в браузере, это может быть почти какой угодно адрес в 4гб.
То есть шанс в 96% делим на, ну например 4 гб и на 8 бит, получаем 0.000000003.
Теперь делим шанс, что перевернется бит именно в ту (мили)секунду, когда его вводят. Ну или хотя бы секунду. 0.000000003 / (24*60*60) = .00000000000003472222 (виндовый калькулятор,кстати уже не осилил, заюзал bc)
И это я явно не учел еще какие-то мелочи, которые легко могут добавить еще множество порядков.
SinsI
06.05.2024 11:06+9что на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней
Более тщательный анализ говорит про большую разницу в разных чипах памяти.
80-96% чипов DIMM не дали ни единой ошибки за год, в то время как плохие ловили их гораздо чаще.
Хороший чип получит один-единственный случайный переворот битов за 6 лет его типичной жизни с вероятностью 1/5.
Гораздо больше вероятность его порчи (1/3 за пару лет) и перехода после этого в категорию "плохих".
isadora-6th
06.05.2024 11:06Плотное накрытие Wi-Fi и всякие микроволновки через стену (была какая-то история про компьютер который выключался когда через стенку включали микроволновку) и прочие наводки GSM на слабо экранированный вывод с подгулявшим тактированием (из-за сохнущих конденсаторов) намного более вероятно поломает биты.
Я сталкивался с тем, что esp8266 периодически перелетая через границу долетали до заказчика в "невключаемом" состоянии и грешили на рентген аппараты в аэропортах, но насколько это правда - не понятно. А так, периодически даже включенные ноутбуки не крашаться проезжая через сканнер.
VADemon
06.05.2024 11:06+1была какая-то история про компьютер который выключался когда через стенку включали микроволновку
Плохое электропитание, высокий входной ток микроволновки, плохой БП компа, железо компа на грани стабильности. Врядли прямо из-за наводки. У нас проводка старая, новая микроволновка пробки вышибала. Пришлось старую оставить.
Borjomy
06.05.2024 11:06+3Проще сверять контрольную сумму дампов оперативной памяти. И не надо какие-то сайты делать, запросы их отслеживать и т.п. выделили массив в несколько Гб и знай себе считай КС. Это намного эффективнее. Ловятся все дефекты в этой области памяти. Просто, оценив такие события, можно оценить вероятность замены в определённом байте. Можно еще положить какой-нибудь источник радиоактивного излучения, например свинцовую фольгу. Кстати, от свинцовых припоев отказались еще и потому, что в свинце присутствуют короткоживущие изотопы, которые нельзя удалить, но распад которых на контактных площадках микросхем памяти, может вызывать как раз эти сбои. Раньше, когда у микросхем выводы были удалены от кристалла и нормы топологии были большие, это не так влияло. А сейчас контактные площадки находятся непосредственно под кристаллом. И вероятность сбоя резко увеличивается.
NutsUnderline
06.05.2024 11:06+2Поясните кто эрудирован : частица реально прошибает атмосферы, крышу, стены и железный корпус компа? Ладно еще в комосе (но там и электроника соответвующая).
И после всего этого она из милионов битов прошибает именно нужный??? Я еще вроде помню теорию вероятности. Иголку в стоге сена искать - не такая уж плохая идея выходит.
Для меня пока что выглядит как дикая профанация.
А что до оригинального случая, 4096 конечно намекает, на "взрыв болотного газа в верхних слоях атмосферы". Явно где то че то програмисты учудили.
sci_nov
06.05.2024 11:06+1Говорят, что на высоте 10 км в 300 раз повышается вероятность bit-flip по сравнению с уровнем моря. На самолетах уже надо отслеживать сбои, а в космосе тем более. А мы тут возле поверхности: либо покупай ECC память, либо рой бункер и организуй там ЦОД).
FrankNStein
06.05.2024 11:06+2Там же одна высокоэнергетическая частица создает каскад из частиц с постепенным уменьшением энергии каждой. И это только в атмосфере, сравнительно разреженном газе.
С ростом плотности вещества шансы взаимодействия с ним у частицы возрастают на порядки, т.е. снижение энергии одной частицы за каджую единицу расстояния возрастает скачком. И несколько жб перекрытий способно погасить очень многое, что долетело из соседней галактики )
Но даже если что и долетит в ячейку памяти, нужно, чтобы заряда захваченной частицы хватило на "перезапись" всего заряда ячейки - а это сильно больше одного электрона (хотя с возрастанием плотности записи уменьшается объем каждой ячейки и как следствие, ее заряд).
Т.е. шансы сбоев тем выше, чем более современный у вас комп)
Ну и как выше люди написали - там, где это критично - используются избыточность и алгоритмы коррекции ошибок (где-то читал, что в космосе расчеты ведут сразу 3 чипа, и значение считается верным, если у как минимум двух результат совпал).
В остальных случаях - семь бед, один резет.
edo1h
06.05.2024 11:06+1Т.е. шансы сбоев тем выше, чем более современный у вас комп)
Почему-то это не так, оценки прошлых десятилетий говорят, что на системах с сотнями гигабайт ОЗУ мы должны видеть коррекции ошибок чуть ли не ежедневно, а реально на большинстве серверов этих ошибок нет годами.
isden
06.05.2024 11:06Техпроцесс уменьшается - размер элементов меньше - меньше вероятность удачно попасть в нужное место.
mpa4b
06.05.2024 11:06Реально на DDR4 ECC - алерты вылетают в dmesg примерно раз в 1-2 месяца.
isden
06.05.2024 11:06У меня две планки DDR4 (2х32) в домашнем сервачке, алерты были ДВА раза за чуть меньше чем три года.
edo1h
06.05.2024 11:06и наверняка по одним и тем же адресам.
99%, что у вас «слегка сбойная» память. но с такой частотой возникновения проблемы вероятность двойной ошибки, которую ecc не сможет исправить, околонулевая, так что особого смысла в замене железа нет.на большинстве серверов я никогда не видел ошибок ecc. на некоторых массовые ошибки (которые исчезают после замены железа).
P.S. если ошибки по разным адресам, я бы на всякий случай проверил нет ли повышенного излучения
mpa4b
06.05.2024 11:06Если честно, я даже не очень понимаю, ошибку чего именно мне в dmesg сообщают. Может, это вовсе Л3 кеш процессорный. АМД, да, десктопное с ЕЦЦ.
vadimyar
06.05.2024 11:06Так, так, вот были же компы с ОЗУ на ферритовых кольцах и эл.вак.лампах - не было таких сбоев :))
saboteur_kiev
06.05.2024 11:06+1Для частицы проще прошибить крышу и стены, и даже железный корпус компа, чем прошибить магнитное поле Земли. Но да, прошибают.
mpa4b
06.05.2024 11:06+1Особо высокоэнергетическая частица слабенького магнитного поля земли вовсе не замечает. А те что от солнца летят -- медленные (низкоэнергетичные) и у них пролететь атмосферу до земли нет никаких шансов.
saboteur_kiev
06.05.2024 11:06Вот прям все что от солнца летит - медленное и низкоенергетичное?
Странно, зачем нужны кремы от солнца.. и вспышки на солнце вообще маркетологи придумали наверное.. И в океане недавно связь вырубили наверное из-за инопланетянmpa4b
06.05.2024 11:06Все солнечные частицы типа протонов -- да. Медленные (относительно), низкоэнергетичные. Атмосферу вообще не прошибают, магнитным полем земли сгребаются на полюса, где и высыпаются северными (или южными) сияниями. Фотоны -- это отдельная история, те, для кого атмосфера прозрачна, задерживаются буквально тонюсеньким слоем вашей кожи, внутрь электроники в приниципе попасть не могут. Высокоэнергетические фотоны, точно так же как и остальные высокоэнергетические частицы, устраивают в атмосфере буквально ливень частиц, который может и прошибить чего.
А эти ваши вспышки на солнце в основном "покачивают" магнитное поле земли настолько, что "связь вырубили".
MountainGoat
06.05.2024 11:06частица реально прошибает атмосферы, крышу, стены
... НИИ, потом фундамент, уходит в толщу Земли, попадает в подземную камеру, где и регистрируется немудрёным прибором - чаном с жидкостью, которая светится от ударов частиц.
Dr_Faksov
06.05.2024 11:06Я в серверах почти ноль. Мне тут достался недавно один со свалки, а там RAID1 из ECC. Это перебор, или нормально? А то физически 32 гига, а на уровне операционки 16.
NutsUnderline
06.05.2024 11:06Начать предлагаю с таблеток от жадности :) Я правильно понимаю: хочется в два раза больше памяти за те же деньги? Я бы просто рассматривал в вопрос не как норм (это вообще то от задачи зависит), а можно ли вообще что то сделать с этим (и каких усилий это будет стоить), возможно есть какая то магическая настройка, а возможно вообще все залочено.
DaemonGloom
06.05.2024 11:06+2Сделать - можно. Такие вещи у серверов задаются в биосе, в разделе настроек ОЗУ. Соответственно, требуемые усилия - зайти в биос и переключить память с зеркалирования на объединение.
sci_nov
06.05.2024 11:06А если RAM память используется в режиме сжатия (компрессии)? Тогда там наверняка поверх используется CRC, которая обнаружит сбой. Возможно даже программный ECC. Как в архиваторе RAR)
DaemonGloom
06.05.2024 11:06Как минимум, в линуксе контрольные суммы считаются только если включена дедупликация сжатой памяти. По умолчанию - их нет.
mayorovp
06.05.2024 11:06+1Да, сжатую память можно и защитить программным ECC. Но это лишь частичное решение, потому что программы не могут работать со сжатой памятью напрямую, сжатая память - это та же подкачка, только не на диск а в память.
Jury_78
С нейтрино еще сложней. :)
alysnix
для нейтрино надо все домены инета купить.