Как известно, все объекты на Земле подвергаются бомбардировке высокоэнергетическими частицами из различных источников. И если частица «снайперским выстрелом» попадёт точно в электронный компонент, то последствия могут быть неприятными, вплоть до сбоя компонента.
В авионике такие феномены называют «одиночные сбои» (single event upset, SEU). Для авиации космическое излучение особенно опасно, потому что лайнеры поднимаются в верхние слои атмосферы, где защита магнитного поля Земли намного слабее.
Но SEU происходят и на обычных компьютерах, в смартфонах, на серверах и т. д. Причём довольно часто. И если такой сбой произошёл во время тестирования, вы никогда не сможете его повторить, потому что состояние Вселенной отличается в каждый момент времени.
Известные примеры сбоев
В мае 2013 года на выборах в Бельгии многие регионы использовали электронное голосование. Каждый избиратель выбирал имя стилусом на экране. На всякий случай сохранялись резервные копии голосов в виде индивидуальных магнитных карт.
При подсчёте результатов голосования в брюссельском муниципалитете Schaerbeek произошёл странный инцидент. Общее число голосов превысило количество избирателей на данном участке. Пришлось достать магнитные карточки из резервного хранилища — и пересчитать их.
Оказалось, что реальных карточек за одного из кандидатов на 4096 меньше, чем показала система.
Эксперты проверили код программного обеспечения, но не нашли такого бага. Тестирование аппаратного обеспечения тоже не дало результата. Ошибку невозможно было воспроизвести.
Осталась только версия, что где-то в компьютерной памяти произошла перемена одного-единственного бита, потому что 4096 — это как раз один разряд в двоичной системе.
409610 = 10000000000002
На аппаратном уровне в машине для голосования это означает включение/выключение единственного транзистора. То есть вышеупомянутый баг может возникнуть, если данный транзистор изменит значение с 0 на 1.
Возможно, такое и произошло. Проверить данную версию очень трудно, потому что SEU — «обратимый» сбой. Он практически не оставляет необратимых изменений (повреждений). Но именно эта причина указана основной версией в официальном отчёте об инциденте.
Это далеко не первый случай, когда произошла такая история. Ещё в 1978 году Intel сообщала о странных изменениях в регистрах модулей памяти P2107C, которые во время тестирования меняли значение с 1 на 0 без программного кода, который мог вызвать такие изменения.
Проблема оказалась в корпусировке микросхем. Дело в том, что корпусировка выполнялась на заводе в Колорадо рядом с заброшенным урановым карьером. Радиационное загрязнение попало в реку Колорадо, а оттуда — на завод Intel.
Инженеры выяснили, что даже остаточных следов урана или тория в корпусе микросхемы памяти достаточно для повреждения данных. Пролетающие альфа-частицы способны временно изменить заряд отдельных ячеек памяти (как на картинке в начале статьи).
Инженеры Intel провели эксперимент с корпусировкой разной степени радиоактивности — и обнаружили точную корреляцию количества альфа-частиц с количеством случайных ошибок.
Источник: A New Physical Mechanism for Soft Errors in Dynamic Memories, 16th International Reliability Physics Symposium, 18-20 April 1978, doi: 10.1109/IRPS.1978.362815
Опубликованная научная статья вызвала большой резонанс в индустрии — и с тех пор производители микросхем стали более тщательно подходить к корпусировке, избегая радиоактивных материалов.
Разумеется, альфа-излучение — не единственный враг электроники. Из космоса тоже прилетает немало высокоэнергетических частиц. Количество ионов на квадратный сантиметр зависит от высоты над уровнем моря.
Источником значительной части частиц является Солнце, но это относительно низкоэнергетические частицы. Больше энергия у тех, что образовались в результате взрыва сверхновых. А максимальная энергия — у частиц, которые образовались в результате активности чёрных дыр в дальних частях нашей и соседних галактик. Отражаясь от магнитных полей, частицы многократно меняют направление, могут ускоряться и миллиарды лет путешествовать по Вселенной (см. Origin of Cosmic Rays от 16 марта 2012 года, arXiv:1203.3681). Происхождение частицы можно лишь предположить исходя из её энергии. Ситуация примерно как с метеоритами. Чем выше скорость камня — тем дальше отправитель.
У субатомных частиц космического излучения гигантская энергия, и в результате столкновения с материальными ядрами создаётся каскад новых частиц, которые порождают новые столкновения: пионы, нейтроны, протоны, мюоны, электроны, позитроны, фотоны. В научной статье Зиглера Terrestrial cosmic rays (IBM Journal of Research and Development, doi:10.1147/rd.401.0019) изучается каскад, рассеяние и энергия некоторых частиц этого потока.
Источник: Terrestrial cosmic rays, doi:10.1147/rd.401.0019
Такой бомбардировке подвергаются наши микросхемы. Возможно, одна из этих частиц и стала причиной изменения заряда в транзисторе на бельгийских выборах. Исследование IBM от 1979 года показывает примерный уровень ошибок из-за космического излучения в некоторых кремниевых микросхемах.
Источник: Effect of Cosmic Rays on Computer Memories (1979), Science, doi:10.1126/science.206.4420.776
Разработчики иногда думают, что всё в этом мире работает абсолютно предсказуемо. Но тестировщикам и специалистам по QA приходится учитывать физическую реальность. Они знают, что абсолютной предсказуемости не существует.
В современных микросхемах компьютерной памяти и CPU проблема усугубляется тем, что производители начинают использовать многослойную компоновку типа 3D NAND с несколькими десятками активных слоёв друг над другом. Такие структуры невозможно протестировать низкоэнергетическими ионами из-за большой глубины чувствительных слоёв.
Источник: Investigating the Effects of Cosmic Rays on Space Electronics
Телеметрия Mozilla
В этом году представители Mozilla обсуждали возможность, как на базе своей телеметрии найти примеры SEU.
Они предлагали посмотреть на характерные изменения символов в коде, которые соответствуют разнице в 1 бит, например:
"o".charCodeAt() -"n".charCodeAt()
1В связи с этим у специалистов Mozilla даже возникла идея, что с помощью телеметрии Firefox они могут детектировать всплески ионизирующего излучения на Земле почти в реальном времени.
Mozilla собирает 100 ТБ в день телеметрии (снимков памяти) у пользователей Firefox. Таким образом, если предположить ориентировочно 1 битфлип на 256 МБ оперативной памяти в месяц, то в телеметрии Mozilla, должно быть:
1*4*1024 = 4096 битфлипов на 1 ТБ в месяц
то есть
4096/30= 136,5(3) битфлипов на 1 ТБ в день
Получается, в телеметрии Mozilla может присутствовать 13 653 SEU в день, если мы не напутали с расчётами.
Осталось только найти способ детектировать SEU, кроме очевидных примеров c изменением букв (см. выше).
Частота компьютерных сбоев резко возрастает при увеличении высоты над уровнем моря, за пределами гелиосферы. В 1970-е годы американцами был зафиксирован уровень ошибок в спутниковых микросхемах из-за космического излучения 1,5 × 10−3 на микросхему в год (см. Binder, D., Smith, E. C., & Holman, A. B. Satellite Anomalies from Galactic Cosmic Rays. IEEE Transactions on Nuclear Science, doi:10.1109/tns.1975.4328188). После этого защита космической электроники была серьёзно усилена. Но до сих пор большие проблемы возникают из-за самых высокозаряженных тяжёлых ионов с энергией до 1020 eV (см. статью Investigating the Effects of Cosmic Rays on Space Electronics, опубликована 18 сентября 2020 года в журнале Frontiers in Physics, doi: 10.3389/fphy.2020.00318).
Первые исследования для авионики
Авионика — совокупность всей электроники, которая применяется в авиации.
Первые серьёзные исследования эффектов SEU в авионике датируются началом девяностых (1993, 1996).
В 90-е данные военных/экспериментальных полётов и лабораторных испытаний показали, что на большой высоте обычные (незащищённые) SRAM на 64 и 256 К демонстрируют значительное количество SEU из-за быстрых нейтронов, возникающих под воздействием космических частиц. Тогда возникла идея рассмотреть схему обнаружения и коррекции ошибок для всех конструкций авионики.
Результаты из исследования 1993 года:
Данные 1996 года:
В 2015 году были проведён эксперимент Radiation Dosimetry Experiment (RaD-X) с замером частоты SEU на высоте 38 км с воздушного шара.
Эксперимент 1996 года показал значительную частоту ошибок компьютерной памяти на уровне моря:
Есть версия, что именно SEU стала причиной инцидента с рейсом Qantas flight 72, когда Airbus A330 резко спикировал вниз из-за неожиданного изменения бита
angle of attack в электронной системе управления ARINC.
К счастью, пилоты успели уменьшить угол атаки и совершить аварийную посадку.
Никакой магии
Конечно, SEU не должны стать «универсальной причиной» для оправдания любых сбоев, причина которых на первый взгляд непонятна. Вместо того чтобы разобраться в истинной причине бага, легко сослаться на «космическое излучение». Мол, в соседней галактике как раз произошло слияние сверхмассивных чёрных дыр…
Конечно, у любого якобы «магического» явления всегда найдётся причина и рациональное объяснение… По этому поводу можно вспомнить байку о зарубежных нейлоновых чулках, которые выводили из строя советские ЭВМ («вражеский нейлон»).
Судя по всему, в мире не существует ничего идеального. Ошибки неизбежны. Поэтому для памяти существуют механизмы коррекции ошибок вроде ECC. Всё приходится многократно проверять и перепроверять. И даже это не гарантирует идеального результата. Любая система рано или поздно падает. Вопрос только в количестве девяток после запятой, но показатель ровно 100% надёжности невозможен в принципе из-за физической природы окружающего мира, встроенных в него ошибок и непредсказуемости.
Даже в пустоте абсолютного вакуума из квантового возмущения рождаются новые частицы, собственно, примерно так появилась наша Вселенная, по одной из текущих версий. Скажите, разве можно надёжно прогнозировать реальность и тестировать её в условиях квантовой неопределённости? Иногда даже кажется удивительным, когда наши программы выдают одинаковый результат на каждом прогоне.
Биологические SEU
По мнению некоторых биологов, аналогичные сбои из-за космического излучения происходят также в биологических «программах» — в геноме живых организмов. Речь о случайных изменениях участков ДНК. Важно понимать, что случайные мутации являются важной частью эволюции (см. The genomic rate of adaptive evolution, doi: 10.1016/j.tree.2006.06.015). Некоторые из мутаций оказываются удачными — и позволяют популяции приспособиться к непредсказуемо изменившимся условиям.
То есть эволюционный прогресс невозможен без постоянного тестирования и ошибок. Нет ошибок — нет прогресса. А источник ошибок — генетические мутации.
Непредсказуемые случайности нельзя недооценивать ни в одной сфере жизни. Та же космическая частица в любой момент может попасть куда угодно: не только в компьютерную память, но и на сетчатку глаза (космонавты на орбите якобы видят световые вспышки) или прямо в мозг.
Учёные ещё не разобрались, как рождаются человеческие мысли и как они взаимодействуют друг с другом. По одной из последних теорий, это генерация электромагнитных полей группами нейронов в разных частях мозга. То есть мысли — это не конкретные нейроны, а скорее определённые поля, которые могут генерироваться разными комбинациями нейронов. Подробнее см. Beyond dimension reduction: Stable electric fields emerge from and allow representational drift. Статья опубликована 8 марта 2022 года в журнале NeuroImage (doi: 10.1016/j.neuroimage.2022.119058).
Оценка амплитуды нейронного электрического поля на каждом электроде в течение 800 миллисекунд, источник
Если пофантазировать, то вполне можно допустить, что частица из дальней галактики может случайным образом сгенерировать совершенно случайную мысль у одного человека. Эдакий биологический SEU с непредсказуемыми последствиями.
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.
Комментарии (145)
BasicWolf
30.05.2022 12:58+20Не уверен насчёт взломать, но программировать так судя по этому комиксу можно:
SGordon123
30.05.2022 13:13+2А датчики альфы есть на таком принципе , Чип в неэкранирующем копусе , и считать сколько единиечек выбило?
Javian
30.05.2022 16:29+1Фотокамера смартфона для этого может использоваться https://habr.com/ru/post/389569/
Alyoshka1976
31.05.2022 19:49Гамма-кванты, электроны и мюоны (редко) отлично ловятся, да, веб-камерой ноутбука или камерой смартфона (особенно интересны "большие" пятна, хотя один раз я поймал их три за несколько часов, причем в довольно близких точках матрицы, что странно). Но альфа не пройдет сквозь оптику, нужно "аппаратное" вмешательство.
Javian
01.06.2022 08:37Альфа через атмосферу не должна долететь.
Alyoshka1976
01.06.2022 15:26Я комментировал ответ на вопрос про датчики альфы без указания ее "генезиса". А так то и с компАсом :-); старым фигня приключиться может, там альфа годная будет, хотя лучше до этого не доводить.
agalakhov
30.05.2022 17:17+2Да, и это один из простейших способов регистрации альфа-излучения. В качестве чипа берется просто диод. Есть детекторы медленных электронов на том же принципе, используются в электронных микроскопах.
Rouse
30.05.2022 13:54+12Ну вот все и выяснилось, когда программа падает с ошибкой - это не у разработчиков руки из задницы, а космические лучи :))))))))
Я должен ЭТО лайкнуть :)
starik-2005
30.05.2022 14:07+8Сервера комплектуются памятью ECC, о которой в статье даже мельком упомянуто. Поэтому ну я бы не доверял даже официальному отчету о том, что (скорее всего, но мы точно не знаем, бла-бла-бла) вот прям так уж космический луч проголосовал сразу 4096-ю голосами за какого-то конкретного доброго и все такое прочее претендента на какой-то там престол или что там у них есть. Если один бит поменялся, то ЕСС уже покажет, что данные невалидны - тут достаточно одного бита четности - так что нужно, чтобы несколько бит поменялись в "одной ячейке", а это уже точно "воля божья".
По космические лучи и память в последнее время что-то много статей. А тут, видимо, и тестеры решили с этого профит поиметь, чтобы не отвечать лишний раз за баги )))
Nikita22007
30.05.2022 14:57+1Это было в 2003 году
starik-2005
30.05.2022 16:00+1https://www.ixbt.com/mainboard/memfaq2.html#21
Тут про модули с четностью рассуждают из тех времен, когда еще пентиумы третьи бороздили просторы. Так вот там был какой-то лайфхак, когда появились т.н. модули с "логической четностью", суть которой отсутствовала от слова совсем. Но "во всех серверах того времени" были модули с контролем четности. Более того, до изобретения этой самой "логической четности" вообще вроде как не было модулей памяти без этого самого "контроля четности".
Реально, в интернетах так мало про контроль четности в исторической ретроспективе, что я даже устал искать ))) Но DDR1 на 2003-й году уже очень как была, даже DDR 2 вроде как, хотя точных дат я и не нашел (
EvilBeaver
30.05.2022 16:17+1Контроль четности я видел на военной советской технике родом из 70-80-х. А если учесть что существенная ее часть подсмотрена у IBM, то контроль четности очень стар и распространен в этих ваших айти.
starik-2005
30.05.2022 16:20+2В те времена без контроля четности мне кажется вообще ничего бы не завелось - слишком грубые технологии.
johnfound
30.05.2022 22:19+1Как раз нет. Память малой плотности намного устойчивей – смотрите таблицы в статье. Просто тогда все делали "как надо", а не "чтобы дешевле было". На ранних PC/XT иногда возникала "parity check" с рестартом системы. Но это было примерно раз в месяц. Но кстати, здесь имеется и другое соображение – если ошибка четности возникает раз в месяц, то ошибка именно там где лежат важные данные наверное случалась раз в год. Потому что память и так полна неважными данными. А сбой раз в год, никто даже и не заметит. Все знают, что компьютеры зависают просто так и тогда их надо перезагружать. Ведь они именно так и должны работать. :)
quwy
31.05.2022 20:00+1Дело не в грубости технологий (которая в этом противостоянии как раз на светлой стороне), а в плохих материалах. Понимание причин сбоев появилось далеко не мгновенно. Основным источником частиц оказывался пластик корпусов со следами урана-тория. И это носило системный характер, а единичный случай. Когда начали использовать нерадиоактивный пластик, контроль четности перешел из разряда must have в разряд heavy duty.
amartology
01.06.2022 19:28+1Дело в том, что у ячейки памяти на толстых технологиях необходимый для сбоя внешний заряд может быть на пару порядков больше, и найти такую частицу, чтобы она что-то сломала, крайне проблематично.
balamutang
30.05.2022 17:22На SIMM 30 пиновой для PC уже был контроль четности - грубо говоря память была 9-битной. Для мака память была 8-битной, т.е. контроля те было. ,т.е. это еще времена 486 и пентиумов.
DGN
31.05.2022 01:39Он конечно был в стандарте модулей, но в связи с ценой памяти, (как сейчас помню, прям константа была непреложная, 35$ за мегабайт лет 10 наверное, буду признателен за ссылочку на график цены ОЗУ от начала эпохи ПК до наших дней), большинство модулей для настольных ПК выпускали 8 битными. Но некоторые сервера, прям отказывались работать без памяти с четностью. Соответственно, некоторые работали. И мы не знаем, какой именно сервер хранил данные о голосовании. Собственно, кроме памяти, в сервере полно мест, в которых может произойти инвертирование бита - шины данных, регистры процессора наконец. Не уверен я и в проверке четности в кеш-памяти процессора, она там есть? Была всегда или в какой-то момент появилась?
VT100
31.05.2022 07:33полно мест, в которых может произойти инвертирование бита — шины данных, регистры процессора наконец.
Все эти места — намного "дубовее" ДОЗУ, там статические триггеры.
balamutang
31.05.2022 10:16Я просто заморочился несколько лет назад с этими симмами, тк они ставились еще и в синтезаторы. И большинство ПКшных модулей что мне попадались были 9битными, т.е. либо стояло 9 однобитных чипов , либо 2 4х битных и 1 однобитная.
вот например, можно посмотреть в даташитах, крайние правые чипы будут однобитные, а слева и посередине - 4х битные
Наверно тут дело еще в том что в ПК мог быть контроль четности, а мог и не быть - в целях экономии, но это не мешало клепать память с контролем.
DGN
01.06.2022 08:33По крайней мере, когда я искал SIMM для принтера HP 4plus (25 лет однако служит машинка мне), то было сложно найти именно планки с четностью, были как у вас на фото средний - без микросхемы четности, в основном.
balamutang
01.06.2022 16:46Ну тут видимо закон подлости работает, я как раз искал без контроля четности, а попадалось наоборот :)
lopatoid
30.05.2022 16:36+2А причём тут серверы, ошибка произошла в электронной машине для голосования, там обычные PC внутри
The Belgian electronic voting system permit some silly kind of recount. Citizen do vote on magnetic card with the help of a diskless PC equiped with a light pen and a card reader/writer. Then those card are inserted into an electronic ballot box for counting. It is assumed that it is the computer controlling that ballot box that did fail. A quotBelgian-evoting-recountquot consist in recounting the magnetic card... but of course it assume the magnetic card has not been modified and contain an accurate expresion of the voter intent. That's where the 4096 discrepency was detected, after the culprit ballot box was identified because it is forbiden by law to publish result of a single ballot box, so result are always merged by a minimum of 10.
Tarakanator
30.05.2022 14:12+3Тема нераскрыта:
1)как часто типичный компьютер может столкнуться с данной проблемой?
2)как на это влияет толщина корпуса?
3)системы, которые для охлаждения полностью погружены в масло\воду более защищённые?Moraiatw
30.05.2022 14:56Что, если на микросхему приклеивать сверху и снизу свинцовые пластинки? Не в производстве, а в своих устройствах, критичных к целостности памяти.
Borjomy
30.05.2022 15:42Изотопы свинца сами по себе являются источником ионизирующего излучения, а от них не так просто избавиться. В том числе по-этому отказались от свинцовых припоев в современной электронике. В вашей идее проще (и дешевле) использовать золото.
Moraiatw
30.05.2022 16:43Но ведь всегда свинец считался хорошей защитой от радиации?
balamutang
30.05.2022 17:40В защите от радиации материал не важен, важна масса. Чем больше масса защиты(количество атомов между источником радиации и мишенью) тем больше вероятность что излучение поглотиться каким-либо атомом. Поэтому материал не важен, хоть воздух, хоть пенопласт, хоть бетон.
Свинец удобен только при том что у него высокая удельная масса (защита получается компактнее).
Tarakanator
31.05.2022 10:28Количество атомов и масса это несколько разные вещи.
Сравните свинец с водородом.balamutang
31.05.2022 15:38Ок, уточню: чем больше количество нуклонов - тем лучше
Tarakanator
31.05.2022 15:42хм... масса на единицу объёма это плотность.
а какой параметр характеризует количество нуклонов на единицу объёма?
понятно что можно пересчитать из средней массы нуклона и плотности, но есть такой отдельный параметр? чтоб его загуглить и вообще посмотреть насколько сильно материалы отличаются?balamutang
31.05.2022 16:22Ну чем больше нуклонов - тем выше атомный вес, он указан в таблице Менделеева. Соответственно надо брать таблицу Менделеева и справочник плотности и выбирать оптимальный материал (спойлер: это будет свинец, достаточно компактный и дешевый)
Но я о другом писал - что гасить излучение можно любым материалом, главное набрать достаточную массу, т.е. килограмм свинца защитит от радиации также как килограмм пенопласта. Нас например вообще хорошо атмосфера защищает, хотя она состоит не из свинца, а из воздуха.
Tarakanator
01.06.2022 11:05килограмм свинца защитит от радиации также как килограмм пенопласта.
У меня не получилось нагуглить, по быстрому, но вроде не так. И в комментах что-то про протоны пишут.
Javian
01.06.2022 16:35Килограмм свинца даст осколки, которые вызовут вторичную радиацию. В комментариях к этой статье https://habr.com/ru/news/t/512760/ обсуждалось.
TheRikipm
31.05.2022 17:06Молярная плотность.
Но в вашем случае легче загуглить молярный объем и отсортировать материалы по возрастанию.
Tarakanator
01.06.2022 11:06Я нагуглил молярный объём только для атомов, но не для молекул.
И тем более не для материалов, которые могут состоять из разных молекул.
VT100
31.05.2022 21:46Рассматривая соударения как упругие — получим, что для протонов и нейтронов — наилучшая экранировка обеспечивается протонами (водой, предельными углеводородами). На каждом соударении с веществом экрана — рассеивается половина энергии.
Тяжёлые ионы (ТЗЧ) производят большие эффекты, но их интенсивность — мала.
КМК.Tarakanator
01.06.2022 11:04Протонами в смысле ядрами водорода, или в смысле при равном весе нам нужно максимальное отношение протонов к нейтронам?
VT100
01.06.2022 17:16Протонами в смысле ядрами водорода
Да.
или в смысле при равном весе нам нужно максимальное отношение протонов к нейтронам?
Не понял.
КМК — диаметры атомов довольно мало изменяются при увеличении атомного веса. Поскольку все нуклоны — в маленьком ядре, то шанс протону или нейтрону столкнуться с протоном экранирующего вещества должен быть выше у лёгких веществ.По экранировке — надо поискать и перечесть посты amartology.
SadOcean
30.05.2022 17:45Предположу, что речь о разных уровнях излучения.
Свинец - хорошая защита от мощного кратковременного излучения, но сам является источником слабого постоянного.
Так то и бананы интенсивно испускают радиоактивные частицы, просто уровень очень невысокий.
rPman
30.05.2022 18:07пологаю что лучший из доступных способов экранизаации — вода?
'держите компьютеры в бочке с водой и они будут меньше глючить'
интересно, какой слой воды должен быть чтобы уменьшить вероятсноть сбоя в два раза? в четыре? на N порядков?Tarakanator
31.05.2022 10:29Слышал что лучшая защита-водород.
Но его неудобно хранить.
Поэтому либо вода, либо полиэтилен.
begin_end
31.05.2022 00:55+1Иногда лучше, чтобы очень скоростная частица прошила насквозь, может быть даже не провзаимодействовав. Чем надежно словить ее в свинец, но вызвать массивный шквал вторичного излучения.
На практике тяжелые металлы не применяют в защите микросхем от космического излучения.
Очень редко бывают частицы с экстремальной энергией 50 Дж (на 1 частицу!). Полный эффект этой энергии был бы эквивалентен одномоментному получению примерно 77 рентген на объект в 65 кг (или 0,77 грей). То есть гипотетически, 1 такая частица могла бы (в благоприятных условиях для конверсии своей энергии) нанести заметный урон здоровью космонавта, вплоть до лучевой болезни. В реальности такое обычно пролетает насквозь, оставляя гораздо меньшую дозу.Tarakanator
31.05.2022 10:31Судя по тому, что чем выше(меньше слой атмосферы) тем больше радиация, данный эффект недостаточно силён для земных условий.
edo1h
31.05.2022 17:251 такая частица могла бы (в благоприятных условиях для конверсии своей энергии)
что-то мне кажется, что свинцовой пластины не хватит, чтобы «поймать» такую частицу, слишком велика её кинетическая энергия.
quwy
31.05.2022 20:14+1Так речь и не о "поймать". Через человека такая частица при везении может проскочить вообще не провзаимодействовав. Или попав на легкий водород нанести минимум повреждений.
А влетая в плотный свинец она с большой вероятностью найдет там тяжеленное атомное ядро, и после столкновения даст такой "сноп", что у человека искры из глаз посыпятся.
DGN
31.05.2022 01:46Единственный прилетевший протон высоких энергий, вместо того чтобы инвертировать один бит, а скорее всего просто пролететь мимо полупроводникового перехода, вызовет лавину вторичных менее энергетических частиц и массированный сбой. В общем, клейте свинцовые радиаторы на память врагов!
Читал, что в космических изделиях чипы памяти располагают неким оптимальным образом относительно друг друга, минимизируя вероятность одновременного сбоя.
qwerty1023
30.05.2022 17:291)как часто типичный компьютер может столкнуться с данной проблемой?
На компьютере с серверной материнкой работающем почти 24/7 видел в логах биоса 1 ошибку ECC за пару лет работы. Не знаю в какой момент они туда попадают, но если всегда при работе то вот.
arheops
30.05.2022 19:01+1У меня сервера баз данных работающие с биллинговой информацией.
ECC на памяти в 512Гб дает одну ошибку каждый месяц.Зависит как бы от общего обьема RAM.
Еще некоторые сервера умеют дублировать вычисления на втором сокете.
Ну и сам сокет как минимум закрыт алюминиевой пластиной радиатора и со всех сторон еще куча корпусов и конструкций.qwerty1023
30.05.2022 20:14Памяти там в 32 раз меньше, так что все сходиться.
arheops
30.05.2022 20:47На 32Гб серверах hetzner один раз в год. Оно не особо то линейно.
edo1h
30.05.2022 23:51ECC на памяти в 512Гб дает одну ошибку каждый месяц
На 32Гб серверах hetzner один раз в год. Оно не особо то линейно.как раз достаточно линейно получается.
а что вы на этих серверах делаете?
я уже писал, с одиночными ошибками памяти практически не сталкивался, массовые были, лечились заменой памяти или сервера.но число ошибок зависит от активности работы с памятью (контрольная сумма проверяется же при чтении памяти), есть подозрение, что я просто недостаточно нагружаю свои сервера )
arheops
30.05.2022 23:53Системы биллинга воип-телефонии.
В основном куча мелких тупых запросов к базам данным в пол террабайта.
На всех серверах в памяти, в осномном, будет кэш.
На самом деле нелинейно. На серверах до 16Гб вообще все работает без ECC, проблемы начинаются где-то как раз с 32.
И проблемы сильно растут с ростом обьемом ОЗУ/кешей.edo1h
31.05.2022 00:03ну у меня тоже есть машины с 128-256-384 гигами памяти, не много, но больше десятка точно, многим уже не так мало лет.
и там тоже есть базы данных. ну вот чистые логи ошибок, хоть ты тресни )если брать последние лет пять и актуальное железо, то ошибки ecc встречал только на одной машине на ryzen у хетцера, пожаловался, поменяли, ошибки продолжились, пожаловался ещё раз, поменяли, ошибки пропали.
при этом да, встречал несколько отзывов о массовости единичных ошибок памяти, нет оснований им не верить, но не согласуется с моим опытом.
arheops
31.05.2022 00:18Может ваше железо их просто не показывает.
Некоторые материнки показывают только в SEL лог, тоесть для просмотра надо перегрузиться и посмотреть в БИОС.
Я знаю, поскольку у меня кластера master-slave и в списке операций стоит просмотр того лога…
Единичные ошибки это норма, для них собственно ECC и придумано.edo1h
31.05.2022 00:41Некоторые материнки показывают только в SEL лог, тоесть для просмотра надо перегрузиться и посмотреть в БИОС.
так они не только в лог bmc пишутся, можно ещё через edac-util смотреть, да и в dmesg, помнится, при наличии ошибок были сообщения.
root@test:~# uptime 00:44:43 up 370 days, 5:05, 2 users, load average: 28,59, 20,28, 18,61 root@test:~# free -h total used free shared buff/cache available Mem: 187Gi 85Gi 6,5Gi 29Mi 95Gi 100Gi Swap: 0B 0B 0B root@test:~# edac-util -v mc0: 0 Uncorrected Errors with no DIMM info mc0: 0 Corrected Errors with no DIMM info mc1: 0 Uncorrected Errors with no DIMM info mc1: 0 Corrected Errors with no DIMM info mc2: 0 Uncorrected Errors with no DIMM info mc2: 0 Corrected Errors with no DIMM info mc3: 0 Uncorrected Errors with no DIMM info mc3: 0 Corrected Errors with no DIMM info edac-util: No errors to report.и таких серверов у меня есть. а с единичными ошибками нет.
AuroraBorealis
30.05.2022 14:34+11Космические лучи?
SadOcean
30.05.2022 17:46Скорее батч обработка, например внесение в систему обработанной (вручную посчитанной) почты.
eurol
31.05.2022 10:36Как объясняется тот факт, что только демократы голосуют по почте? :)
SadOcean
31.05.2022 10:43+1У республиканцев там тоже рывок симметричной формы, просто меньше.
И до этого есть совпадающие рывки.
Это может быть подключение другого штата или сельских / городских регионов с другим соцдемом.
Но конечно и вбросы могут быть, в том числе через ту же почту.
Кто ж их знает, что у них там
muxa_ru
30.05.2022 14:43+3Кажется, в реальность воплотилась ещё одна идея из 1990-х - "меньше транзистор делать нельзя - его будут переключать пролетающие мимо ...-частицы" :)
Format-X22
30.05.2022 14:53+6Глядишь придёт время и начнут не ускорять процессоры, а оптимизировать софт.
rPman
30.05.2022 18:10+1Маловероятно (нужно что действительно страшное чтобы произошло, чтобы люди стали писать софт правильно), скорее в облако все вернутся (я имею в виду те времена когда были большие компьютеры и терминалы к ним), централизованно удобнее организовывать защиту, вплоть до синхронного выполнения на нескольких машинах (не процессорах а именно компьютерах) и сравнение результата перед отсылкой обратных пакетов.
Format-X22
30.05.2022 18:20С синхронным исполнением, к слову, уже всякие блокчейны есть, правда там обычно какая-нибудь своя виртуальная машина со своим языком и пачкой ограничений, в том числе такими что процесс внутри поддерживаться не может и только сценарная логика, как в старых PHP, кстати, а крона там встроенного нет, оракулы - не то. Но глядишь и любой код начнет поддерживаться. Я, к слову, даже стартовал такой проект, но притормозил - не знаю нужно ли миру p2p облако, с запуском JS скриптов, для начала, p2p доменами, статикой и прочим всяким, но не знаю - не будет ли как пятая нога собаке, однако некоторое время и ресурс в это вложил.
rPman
30.05.2022 18:34блокчейн с одновременным исполнением на сотне машин тут совершенно не нужен
а про большой компьютер я серьезно, не где то в облаке а по одному на многоквартирный дом, сотни человек пользуются одной большой машиной, эффективно расходуя энергию… для клиентов бесшумные удобные (например беспроводные включая подачу энергии) терминалы
да подобная схема не применима в современном мире, где человек человеку волк, и большие дяди спят и видят как сделать гадость большинству, но помечтать то можно? С другой стороны предприятиям такая схема идеальна (ее и используют — rdp, но современное лицензирование и цены сводят все бонусы ее использования на нет)Format-X22
30.05.2022 18:55Как раз когда-то я на таком работал - большой офис разработки, у всех тонкие клиенты с rdp до серверной стойки в одной из комнат на этаже. Что-то в этом есть, но сложно рассуждать о плюсах-минусах, почти 10 лет прошло, возможно иначе всё сейчас, но нынче в моде раздать ноутбуки, как минимум там где наблюдаю сам.
rPman
30.05.2022 19:42Современный rdp лагает, это особенность реализации, тут ничего не поделаешь, но главное, современный софт и стратегия его использования, не готово к многопользовательскому окружению, как только программист начинает настраивать себе окружение, это сразу конфликтует с соседом, т.е. как минимум нужно договариваться об ограничениях.
мне нравится реализация от ibik aster (то же самое заводится нативно на linux — multiseat) когда в сервер пихается по максимуму мониторов клавиатур и мышек, длинные кабели (hdmi 20-30 метров легко и есть на сотни метров правда дорого) и usb трансиверы по ethernet — доступно уже сейчас, есть ряд неудобств исключительно программного характера, например при использовании рабочего места win не серверной ревизии, все пользователи получают доступ к флешкам, в linux так же по умолчанию, или сложности с настройкой звуковых карт, доступ в интернет с разных ip и прочее прочее, но все решаемо, и конечно лицензионные ограничения, если софт не желает работать в многопользовательском окружении то селяви.
ну и конечно перезагрузка, много ситуаций, когда машину все же нужно перезагружать, и это затрагивает сразу всех пользователей
я пробовал, когда второе рабочее место (linux multiseat) запускает windows в виртуалке, и сидит в фулскрине, глупо но работает
Tsimur_S
30.05.2022 14:52При подсчёте результатов голосования в брюссельском муниципалитете Schaerbeek произошёл странный инцидент.
В мае 2003 года а не 2013 как можно сделать вывод из абзаца выше.
amphasis
30.05.2022 16:44+2Ну так частица же пролетела, достаточно переключить один бит, что-бы получился 2013 ;)
bfDeveloper
30.05.2022 17:282 бита для разницы в 10 <zanuda/>
Kreastr
30.05.2022 18:09+41 бит, если частица прилетела в память тогда, когда число уже превратили в ASCII. В случае с сохраненной в UTF-8 статьей тоже 1 бит.
Stratum
30.05.2022 15:00Пожалуй, проведу эксперимент: запишу на microSD файлы, запущу в небо на воздушном шарике на 10..20 км, а после полёта (1...4 часа) сравню файлы. Кто желает помочь сгенерировать файл мегабайт на 100 из одних единичек? Как располагать флешку?
Format-X22
30.05.2022 15:11+1Ну флешку горизонтально к небу, дабы площадь возможного контакта была больше, под углом то частицы часть энергии потеряют, с горизонтальным вероятность должна выходить выше. И хотя эксперимент из разряда буханки хлеба и троллейбуса, всё равно любопытно что получится.
muxa_ru
30.05.2022 15:23На высоте 20 км начинают возникать дополнительные факторы - https://habr.com/ru/post/379345/ .
Stratum
30.05.2022 15:29Так та статья утверждает, что при снижении температуры надежность хранения флэшки возрастает....
muxa_ru
30.05.2022 15:40В статье говорится о рисках связанных с повышением температуры в пределах допустимого диапазона температур.
Экстремально низкие температуры там не рассматриваются, за исключением фразы:
>Для дисков достаточно промежутка между −40° и 70°, а для SSD может потребоваться контролируемая температура — к примеру, твердотельник недопустимо забывать на несколько дней в автомобиле на солнце.Так что, учитывая физику процесса и размер ячеек, экстремально низкие температуры могут повлиять.
Stratum
30.05.2022 16:26+2Я знаю только один способ узнать что выйдет. Постараюсь до конца недели запустить.
muxa_ru
30.05.2022 23:42Сделайте один контрольный образец,в металлическом футляре.
Это уменьшит влияние лучей и будет рассматриваться как влияние исключительно холода.Stratum
30.05.2022 23:47+2Я могу положить флешку в отсек с электроникой. Там не ниже -15гр. А толстый металл не получится использовать по причине ограничения веса
Tarakanator
31.05.2022 10:37в полиэтилен замотай. Там много водорода, он вроде как хорошо защищает.
Stratum
31.05.2022 11:05Мне кажется, что надо наоборот более жесткие условия делать. Будет защита только 15мм пенопласта.
vadimk91
30.05.2022 15:25помочь сгенерировать файл мегабайт на 100 из одних единичек?
Ctrl-C / Ctrl-V :)
А если серьезно, не надо из одних единичек. Намедни знакомые принесли битую карту памяти из телефона с просьбой восстановить фото-видеофайлы. Так вот, часть битых файлов была заполнена кодом 0xFF. Лучше возьмите, к примеру, старую утилиту h2testw, она как раз для проверки подойдет.Stratum
30.05.2022 15:34+1Да, действительно, лучше чтоб и единички, и нолики были. Тем более, что физически ноль это наличие заряда, т.е. пролетающая частица из ноля сделает единицу.
ToSHiC
30.05.2022 21:41Всё сложнее. В рамках flash памяти действительно вполне можно попасть в саму ячейку, а вот в случае с DRAM можно так же с большим успехом попасть в затвор транзистора и 1 превратится в 0. У меня есть ещё предположение, что в flash величина заряда должна быть на порядок больше, чем у DRAM памяти, но быстро цифры не нагуглились.
psycho-coder
30.05.2022 16:20+1помочь сгенерировать файл мегабайт на 100 из одних единичек?
$ dd if=/dev/urandom of=~/file100mb bs=1024 count=100Stratum
30.05.2022 16:30К сожалению, для меня это просто набор символов. Если есть возможность, скиньте пожалуйста ссылки на готовые файлы из единичек, и из ноликов
psycho-coder
30.05.2022 17:10+1Сжато gzip'ом disk.yandex.ru/d/Po_55FkiMUufWA
Если кому интересно будет, сделал так, именно с нулями и еденицами.$ shuf -i 0-1 -r -n 104857600 | tr -d '\n' > ~/100mb
Ritan
30.05.2022 17:09bs в байтах - у вас 100кб получилось
$ dd if=/dev/urandom of=~/file100mb bs=1M count=100
balamutang
30.05.2022 17:44Почему 100мб, а не на всю емкость SD?
Для чистоты эксперимента надо 10 карт на земле и 10 поднять высоту и через недельку (а лучше через полгода) сравнить и данные усреднить
SadOcean
30.05.2022 17:59+1Лучше не из одних единичек, а некоторый паттерн
например 01010101
Забить все байтовыми 85
Вот вам питончик, скопировать в файл и запустить
Там где 1024*1024 - указать размер, например 512*1024*1024 - файл на 512 МБfile_size = 1024*1024
symbol = int('01010101', 2) # 85 code 'U' symbol
with open('test_file.txt', 'w') as f:
for s in range(file_size):
f.write(chr(symbol))
print("done")
EvilBeaver
30.05.2022 16:13+1Подождите, а как же старый-добрый контроль четности и "контрольный разряд" в регистре? Разве он не предназначен как раз и защищать от сбоя в один бит?
asakasinsky
30.05.2022 17:32+2Доклад от А. Миловидова про баг, причиной которого являлись битфлипы в контроллере сетевой карты и совпадающей при этом контрольной сумме.
SadOcean
30.05.2022 18:01+1Он может помочь, но их ведь используют в процессах, где шум подразумевается (типа сети и дисков), но внутренняя среда компьютера считается надежной.
К тому же даже самые продвинутые системы не защищают 100 процентов (хотя конечно радикально снижают шанс)
adeshere
30.05.2022 16:42+5Похоже, автор сейчас офлайн, и не может оперативно поправить публикацию. Поэтому напишу сюда, хотя об опечатках обычно лучше сообщать через механизм ЛС.
потому что лайнеры поднимаются в верхние слои атмосферы, где защита магнитного поля Земли намного слабее.
Тут ошибка, по-моему
Магнитосфера находится много выше атмосферы. Поэтому даже в полярных широтах подъем вверх на 10км от поверхности очень слабо влияет назащитный эффект магнитного поля
Разумеется, в полярных широтах этот защитный эффект слабее, чем в низких. Но мы-то сравниваем не низкие широты с высокими, а защитный эффект магнитного поля на разных высотах в одной и той же географической точке...
А вот толщина атмосферы над самолетом на земле и в полете меняется в разы (точнее, в 2- 3 раза). И вот как раз ее защитный эффект ослабевает пропорционально уменьшению массы атмосферы над самолетом.
Частота компьютерных сбоев резко возрастает при увеличении высоты над уровнем моря, за пределами гелиосферы.
Может быть, все-таки имелась в виду атмосфера? Или хотя бы магнитосфера?
Гелиосфера — это от ГЕЛИОС, т.е. Солнце. Это зона, где солнечный ветер и связанное с ним магнитное поле преобладают над магнитным полем межзвездной среды. Для выхода за пределы гелиосферы надо очень сильно подняться над уровнем моря - на много астрономических единиц. Насколько я знаю, пока что такой опыт имеется только у Вояджеров. А вот за пределами магнитосферы уже побывало множество космических аппаратов, и там уже накоплена определенная статистика по подобным сбоям.
SergeyMax
30.05.2022 17:00-1Похоже, автор сейчас офлайн, и не может оперативно поправить публикацию Поэтому напишу сюда
А если сюда напишете, то 1) автор сразу станет онлайн или 2) сможет оперативно поправить публикацию?
adeshere
30.05.2022 17:21+4А если сюда напишете, то 1) автор сразу станет онлайн или 2) сможет оперативно поправить публикацию?
Если я напишу сюда, то это поможет читателю узнать, что по некоторым затронутым в публикации вопросам существует альтернативная точка зрения. Да, ему для этого придется прочитать комментарии - это менее удобно, чем если бы в публикации изначально не было опечаток. Но все-таки лучше, чем если такая опечатка останется непрокоментированной.
Хотя Вы наверно правы, что мои извинения за выбранный формат исправления опечаток сформулированы
чересчур витьевато :-(
Автору я сперва отправил ЛС, - понадеялся, что он сразу ответит. Но оперативного ответа не получил, а статью-то читают. Поэтому вот так :-((( Извините за косноязычие :-(((
SergeyMax
30.05.2022 17:37136,5(3) битфлипов на 1 ТБ в день
то есть 10 ошибок в день на 128 гб озу?
arheops
30.05.2022 19:03+1По моим данным где-то одна ошибка пойманная ECC в месяц на 512Гб сервере. +- 20%.
Как ловить непойманные неизвестно, но шанс на них на порядок меньшеSergeyMax
30.05.2022 19:07Это больше похоже на правду, т.к. если я сейчас запущу мемтест, то и близко не получу значений, упомянутых в статьею
arheops
30.05.2022 19:20Не, мемтест ничего не находит.
Даже за сутки на серверах с 2Тб памяти(больше никогда не пробывал).
Вообще за всю мои историю админом/девопсом я видел всего два случая memtest fail.
Бывает модуль явно битый, дает на одном и том же модуле ошибку постоянно, два раз в сутки, а мемтест — в норме.SergeyMax
30.05.2022 19:25Вообще за всю мои историю админом/девопсом я видел всего два случая memtest fai
Дак вы частоту на модуле поднимите)
iShrimp
30.05.2022 20:36Эта проблема так же стара, как и интегральные схемы, но внимания ей уделяется по-прежнему мало. Сбой может произойти как в мощной серверной машине, так и в микроконтроллере, стоящем в промышленном или медицинском оборудовании. Проблема в том, что система обычно не крашится сразу, а продолжает спокойно работать до какого-то момента. Одно дело, если испортятся числовые данные, и совсем другое - порча указателя или программного кода, тогда программа может совершить непредсказуемые действия.
Интересно, есть ли в современных ОС контроль целостности данных (ядра, драйверов, прикладного ПО)? И насколько он эффективен?
На первый взгляд кажется, что многозадачные системы имеют неплохую защиту от ошибок на уровне межпроцессного интерфейса. Любой системный вызов с недопустимыми параметрами сразу же вызовет ошибку. Доступ к недопустимому адресу памяти будет заблокирован контроллером памяти. Для Java-приложений множество проверок обеспечивает JVM - на выход за границы массива, на валидность указателей и т.д. Это всё хорошо, а кто-нибудь предусмотрел ситуацию, что баг может случиться в самой JVM? Например, из-за кривого указателя изменилось количество объектов в куче, и как на это отреагирует сборщик мусора - промолчит или выдаст исключение?
Наверно, разработчики ОС и прикладного софта должны вводить больше явных проверок в свой код. Ошибку лучше выявить своевременно, особенно во встраиваемых системах. В ответственных участках кода стоит проверять не только аргументы функций, но и результаты вычислений, индексы массивов, указатели стека (в разумных пределах). Желательно использовать вычислительно устойчивые алгоритмы, для которых малое изменение входных данных мало влияет на результат.
arheops
30.05.2022 20:59В большинстве случаев это никому не нужно. Даже в космических аппарата ставят три процессора(а надо три, чтоб знать какое решение правильное) в паралель только на аппаратах дальнего космоса.
Писать код, который подразумевает, что КАЖДАЯ операция может стать любой другой — практически невозможная задача. Дубликация делает sync через определенные промежутки.
KvanTTT
31.05.2022 02:23Прикладные программы это усложнит и замедлит, а профит минимальный. К тому же едва ли возможно полностью, а в таком случае смысла ещё меньше.
KvanTTT
31.05.2022 02:21Интересно, а нейтрино когда-нибудь были причиной подобных сбоев? Ведь каждую секунду каждый см^2 земли пересекает более чем 10^10 этих частиц. Они, конечно, практически не взаимодействуют с веществом, тем не менее периодически детектируются специальными устройствами.
Pavel_nobranch
31.05.2022 03:08Клавиатуры в банкоматах умирают сразу по нескольку штук в регионе с сообщением зафиксировано вскрытие. Видимо микросхемы защиты криптомодуля ловят частицы.
karambaso
31.05.2022 11:58-1В общем-то, это обычный наброс с целью привлечь внимание и развлечь. Никаких конкретных данных о статистике явления не показано, кроме указания на то, что Mozilla каждый день собирает со своих пользователей 100 ТБ какой-то полезной мозилле информации, из которой кто-то в мозилле каким-то непонятным образом вычислил некую цифирь.
То, что мозилла за нами следит, это интересно, но память с коррекцией ошибок сегодня очень распространена, поэтому закатывать глаза и делать грустное лицо совершенно нет необходимости. Ну а у кого память без ECC, тому оно и так не надо, потому что глючность обычного хомячкового софта на много порядков больше, нежели могут при всём своём желании выдать космические лучи.
KvanTTT
31.05.2022 15:57> Ну а у кого память без ECC, тому оно и так не надо, потому что глючность обычного хомячкового софта на много порядков больше, нежели могут при всём своём желании выдать космические лучи.
Проблема в том, что космическая частица может поразить любой бит память, включая критические компоненты ядра, пользовательские баги не имеют доступа к ядру.karambaso
31.05.2022 19:08Для конечного пользователя любой вариант будет выглядеть как "неправильное" поведение программы, включая такое поведение, о котором пользователь только думает, что оно неправильное, а на самом деле так было задумано.
Теперь прикиньте количество таких неправильных варинтов. И сравните с количеством частиц, целенаправленно развлекающихся с вашим ядром линукс.
VT100
31.05.2022 21:55Ну как это нет? Есть данные на начало 80-х.
Другое дело, что память на CCD (шта-а-а?) не взлетела. А динамическая КМОП память, при использовании "low alpha mold", — достаточно надёжна в "быту". И, при минимальной ECC, — "в проде".karambaso
01.06.2022 01:44Есть данные на начало 80-х.
Перечисленные в статье эксперименты (не из 80-х) проводились по разным методикам на разном железе. Например, изучали влияние радиоактивных корпусов на их внутренности, или летали на самолёте и считали некие события, которые интерпретировали как "нападение космических лучей".
Всё это к тому, что само явление, видимо существует, но каких-то серьёзных статистических данных по его воздействию на современное железо не приведено. Экстраполировать же эксперименты с самолётами в облаках на сегодняшние реалии с кардинально отличающимися плотностями упаковки микросхем, которые чаще всего находятся не в самолётах, есть занятие не совсем обоснованное.
Принципиально тестирование не выглядит сложным, если есть в наличии источник с близкими характеристиками частиц. Почему его не провести на современной базе? Хотя по возможности генерации частиц соответствующей энергии я не в курсе.
Soukhinov
31.05.2022 13:48+4Когда моя программа аварийно завершается, я действую в следующем порядке. Вначале предполагаю, что это космическая частица влетела в микросхему и что-то там сделала. Если же программа падает снова и снова, то, видимо, микропроцессор содержит аппаратную ошибку. Если тщательное тестирование микропроцессора ничего не выявило, то, возможно, дефект оперативной памяти. После этого моё подозрение падает на компилятор — скорее всего, он забагованный. Потом надо проверить операционную систему. Если к этому моменту меня ещё не уволили, то после проверки операционной системы можно и в исходный код программы заглянуть.
vyahhi
31.05.2022 18:14Выпуск Veritasium про это с похожими примерами – https://www.youtube.com/watch?v=AaZ_RSt0KP8.
grishkaa
А можно ли целенаправленно стрелять заряженными частицами в чипы памяти с целью, например, взломать DRM и прочие формы защиты устройства от его владельца?
Brak0del
Да, например с помощью сфокусированного ионного пучка (Focused Ion Beam). Только дороговато пожалуй.
screwer
Fault injection это называется. Кроме излучений - игрища с наносекундными бросками питания Или наоборот, высокоточное отслеживание потребления, чтобы распознать что выполняется на чипе.
imageman
Гораздо проще поднять температуру на несколько десятков градусов выше. Медленно поднимаем температуру и рано или поздно будет сбой.