☰

Каковы примеры программного обеспечения, на которое может серьезно повлиять скачок времени?

tag-icon • tag-icon chrony
Каковы примеры программного обеспечения, на которое может серьезно повлиять скачок времени?

Документация хрони предупреждает

ВНИМАНИЕ: некоторые программы могут серьезно пострадать от таких скачков системного времени. (Именно поэтому chronyd обычно использует поворот.)Документация

Но в документации нет примеров. Каковы примеры ПО, которое будет серьезно затронуто? Подвергается ли ОС или фоновые процессы риску?

решение1

Это немного открытый вопрос, но позвольте мне привести несколько примеров:

  • базы данных - большинство из них во многом опираются на точное время для хранения записей, индексов и т. д.
  • безопасность - точное время очень важно для безопасности, чтобы сопоставлять действия со временем, а пробелы или дублирование времени не допускаются
  • цифровая подпись — обычно частью подписанного документа является временная метка, поэтому неправильное время может сделать подпись недействительной
  • программное обеспечение для планирования — может пропускать или повторять задания дважды в зависимости от направления скачка времени.
  • программное обеспечение для кластеризации — вероятно, любой кластер должен быть синхронизирован, и любой скачок одного или нескольких узлов может иметь непредсказуемый результат.

решение2

Недавно я столкнулся с ошибкой, которая появилась еще в 1999 году и затрагивает как JVM, так и Android Runtime:https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4290274

... два дополнительных выполнения запускаются (неожиданно), когда системные часы переводятся вперед на одну минуту после того, как задача запланирована с помощью scheduleAtFixedRate().

Я работаю на устройстве, которое начинает с эпохи 1970 года как текущего времени, а затем получает правильное сетевое время немного позже. Иногда сторонняя библиотека инициализируется до установки времени, из-за чего происходит скачок времени на 50 лет.

Результатом стала scheduleAtFixedRateпопытка наверстать упущенное за ~50 лет призываний... что составило около 27миллионпоследовательные вызовы без задержки между ними.

Это приведет к сбою GC и, как правило, остановит систему до тех пор, пока ее не перезапустят.

решение3

Все программное обеспечение, взаимодействующее с реальным оборудованием. Если у вас есть тостер, который поджаривает хлеб в течение 20 секунд, и его программное обеспечение настолько глупо, что сверяется с настенными часами, вы получите либо белый, либо подгоревший хлеб, если вы скорректируете часы, ожидая тоста.

Практически все приложения, которые управляют любым промышленным устройством, требуют точного времени, например, «открыть клапан на 5,3 секунды, чтобы получить необходимое количество жидкости». Ошибки более чем на несколько миллисекунд испортят ваш продукт.

Приложения, которые позиционируют что-либо с помощью двигателей, будут использовать либо шаговые двигатели (которые медленные), либо конечные выключатели, чтобы определить, когда остановиться. Но часто у вас нет выключателя в каждой важной позиции, поэтому вы будете использовать логику "xm/s для A миллисекунд, затем ym/s для B миллисекунд". Теперь представьте, что ваш демон NTP корректирует время даже на одну миллисекунду, пока эта логика работает...

решение4

ГолубятняIMAP-сервер подвержен этой уязвимости, и (в более старых версиях) он (намеренно) завершает работу, если обнаруживает, что системное время перешло назад. В версии 2.0 он, по крайней мере, пытается исправить ситуацию.

Видетьhttps://wiki.dovecot.org/TimeMovedBackwards

Связанный контент