30 июня 2026 года были опубликованы уведомления об исправлении 13 новых уязвимостей в ОС FreeBSD.

( читать дальше... )

>>> FreeBSD Security Advisories (freebsd.org)

systemd в очередной раз мне тайком нагадил

Jun 30 01:07:59 nb2 systemd-timesyncd[595]: Initial synchronization to time server 92.255.126.4:123 (0.debian.pool.ntp.org)

Начались такие сообщения примерно неделю назад, при этом разумеется я этот timesyncd не трогал и даже не знал что он у меня установлен. Впрочем, сам timesyncd, как оказалось, был и раньше - первое упоминание его в логе в августе 2025, при том что лог начинается с февраля 2025, но время он мне тайком не портил и я его не замечал.

Собственно, почему такое произошло и как его отключить чтобы он потом назад опять не включился?

Однажды он мне переставил время аж на целых 5 секунд назад (мне об этом сообщил запущеный в это время пинг), точные масштабы вредительства в остальные моменты времени не знаю.

systemd-timesyncd оказался отдельным пакетом, так что apt-get purge позволил даже не лазить по конфигам systemd для его отключения. Однако вопрос «почему он годами молчал а теперь начал активно синхронизировать время» - всё равно актуален.

Обнаружил сильную зависимость скорости работы одной вычислительной функции от того, на каком адресе она начинается. Локализовал проблему с помощью вставки NOP-ов в разные её места, выяснилось что корень всех странностей находится в этом цикле (подозреваю, что различие в скорости работы тоже локализовано в нём, хотя как это точно проверить не знаю):

00000000000016b9 <.bL11>:
    16b9:       48 8b 04 ce             mov    rax,QWORD PTR [rsi+rcx*8]
    16bd:       48 19 04 cf             sbb    QWORD PTR [rdi+rcx*8],rax
    16c1:       48 ff c1                inc    rcx
    16c4:       75 f3                   jne    16b9 <.bL11>
    16c6:       48 83 1f 00             sbb    QWORD PTR [rdi],0x0

00000000000016ba <.bL11>:
    16ba:       48 8b 04 ce             mov    rax,QWORD PTR [rsi+rcx*8]
    16be:       48 19 04 cf             sbb    QWORD PTR [rdi+rcx*8],rax
    16c2:       48 ff c1                inc    rcx
    16c5:       75 f3                   jne    16ba <.bL11>
    16c7:       48 83 1f 00             sbb    QWORD PTR [rdi],0x0

00000000000016c5 <.bL11>:
    16c5:       48 8b 04 ce             mov    rax,QWORD PTR [rsi+rcx*8]
    16c9:       48 19 04 cf             sbb    QWORD PTR [rdi+rcx*8],rax
    16cd:       48 ff c1                inc    rcx
    16d0:       75 f3                   jne    16c5 <.bL11>
    16d2:       48 83 1f 00             sbb    QWORD PTR [rdi],0x0

Собственно, если отметить первый лагающий вариант (где .bL11=0x16BA) за точку отсчёта, то итоги такие:

-7..-1 - хорошая скорость
0..11 - замедление на 30-35%
12..15 - хорошая скорость
16..23 - замедление на 15-20%
24..31 - хорошая скорость
32..32+11 - замедление на 30-35%
32+12..32+31 - хорошая скорость

Ещё я проверил что будет если вставлять NOP-ы внутрь цикла. Так вот, добавление например 2 NOP-ов приводит к тому, что лаги начинаются на 2 байта раньше (т.е. при той же позиции JNE как и раньше начинались), а вот заканчиваются на том же месте как раньше, т.е. при той же позиции метки (т.е. лаги от -2 до 11). Вторая зона лагов стала какой-то размазанной с усилившимся пиком в самом начале, а так же она появилась таки во втором цикле на 32+16-2.

сдвиг   время выполнения бенчмарка
-6       511.9 +- 14.8
-5       515.2 +- 12.3
-4       511.6 +- 8.9
-3       507.3 +- 7.2
-2       683.0 +- 9.2    <-- первый круг
-1       672.1 +- 12.3
0        670.5 +- 8.6
1        674.8 +- 17.1
2        669.4 +- 7.4
3        672.5 +- 11.0
4        675.0 +- 9.1
5        669.9 +- 8.9
6        675.5 +- 8.8
7        679.1 +- 7.6
8        696.9 +- 23.6
9        691.6 +- 14.8
10       680.5 +- 9.5
11       684.0 +- 9.0
12       516.5 +- 7.9
13       517.2 +- 11.6
14       792.3 +- 36.8   <--
15       605.4 +- 37.5
16       575.8 +- 24.2
17       566.0 +- 16.0
18       555.8 +- 21.6
19       562.0 +- 14.5
20       555.7 +- 8.7
21       537.2 +- 10.7
22       534.4 +- 11.2
23       549.9 +- 14.6
24       522.1 +- 10.6
25       517.8 +- 9.5
26       515.5 +- 8.4
27       517.0 +- 4.2
28       512.2 +- 7.4
29       516.8 +- 8.6
30       680.3 +- 9.2  <-- второй круг
31       675.0 +- 19.7
32       671.7 +- 8.9
33       669.2 +- 9.1
34       668.3 +- 10.8
35       667.0 +- 9.6
36       669.0 +- 8.9
37       671.0 +- 9.5
38       670.6 +- 10.8
39       676.5 +- 10.1
40       681.0 +- 10.5
41       682.1 +- 12.7
42       693.5 +- 16.7
43       689.8 +- 13.5
44       512.5 +- 4.9
45       516.9 +- 7.1
46       685.5 +- 12.3   <--
47       515.2 +- 7.6
48       519.0 +- 8.7
49       513.2 +- 7.9
50       512.4 +- 6.2
51       510.8 +- 4.7
52       510.3 +- 7.3
53       507.4 +- 7.0
54       509.2 +- 6.9

Вообще мне казалось что для более быстрой работы кода надо выравнивать начала циклов по 16-байтным границам, но тут ничего подобного незаметно, все адреса не пойми какие. Есть замеченная закономерность: когда JNE доползает до адреса 0x16c5 - лаги начинаются, когда до него доползает и начало цикла - заканчиваются. Но JNE двухбайтовый, т.е. когда он на 0x16c4 то второй его байт на 0x16c5 и лагов ещё нет.

Есть ли шанс объяснить почему так? А то мне совсем не нравится что код рандомно теряет треть скорости на ровном месте, тут я заметил, где-то не замечу, да и на разных процах это может быть по-разному, что делать?

---------------

Почти итог: адреса в дампах выше считал от начала объектного модуля, оказывается модуль автоматически (если явно не указать) по 16-байт границе не выравнивается, и адреса в бинарнике уплыли. Реальное замедление получается если тело цикла пересекает 32-байт границу (кроме случая когда за неё вылезает только один байт последней инструкции, почему-то), выглядит логично.

https://www.freebsd.org/security/advisories/FreeBSD-SA-26:26.ktls.asc

Механизм аналогичный линуксовому copyfail.

Но переживать особо не стоит - баг в ktls, который выключен по-дефолту (sysctl kern.ipc.tls.enable=0).

Баг в KTLS, при этом KTLS включён по умолчанию начиная с релиза 15.0, в более ранних - выключен и можно не переживать. Проверить тут: sysctl kern.ipc.tls.enable.

Для новости слишком поздно - объявили 9 июня.

Перехожу по ссылке из поиска куда-то, а там

Ошибка при установлении защищённого соединения

ищу где кнопка добавления исключений, но её почему-то нет. Читаю внимательнее что написано

При соединении с otvet.mail.ru произошла ошибка. Сертификат узла был отозван.
Код ошибки: SEC_ERROR_REVOKED_CERTIFICATE

Вобщем, там GlobalSign и он отозван. На главной у них выпущеный сегодня утром сертификат от какого-то греческого CA, а в других местах видимо забыли переделать.

Почитал, оказалось что GlobalSign запланировал отзыв сертификатов и вообще всех российских клиентов. А чего новости на лоре не было или даже темы в толксах? Только про LE.

https://www.phoronix.com/news/Arch-Linux-AUR-Russian-Spam

скриншот оттуда

Современные диски очень долго пересобираются после замены, шанс того что во время пересборки слетит и второй (raid5) или даже третий (raid6) становится всё выше. Причём они не обязательно должны именно сломаться в этот момент, может быть в них например давно уже пачки бэдов, по их никто не читал (с большими дисками шансы этого тоже растут), а во время пересборки вылезло и навернуло массив. Как вы относитесь к данной проблеме?

1) избегаем рейды кроме миррора, расходы на диски соответственно повысились

2) боимся, но желание сэкономить перевешивает, делаем raid5/6

3) это всё страшилки, нет там никаких проблем, пользуемся raid5/6 без лишних страхов

4) проблема есть, но всё забекаплено и если что восстановим, а на простои пофиг

Речь про диски типа 20тб и похожие.

Фу такими быть.

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

https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#automated-contri...

Additionally, AI-generated code conflicts with this project's license (Unlicense), since you cannot truly release code into the public domain if you didn't author it yourself.

Вот тут ИИ нашёл решение до сих пор нерешенной проблемы из области дискретной геометрии: гипотезы Эрдёша (номер 90) (комментарий) VIT заявляет, что существуют полноценные квантовые компы на 700 кубитов, и что 2048-битные модули уже умеют факторизовать (что означает что большинство современных RSA, который повсеместно 2048-битные, можно считать взломанными). Выглядит несколько странно, если это действительно так но по всему миру до сих пор не поднялось много шума об этом.

greenman и LightDiver там, как и я, интересовались подробностями.

Сообщение VIT оттуда про 700 кубитный проц Интел:

Продемонстрировала в декабре 2025 года. Вы об этом не знаете, но мнение имеете и выражать его не стесняетесь. Результаты отличные, как вам может быть известно, это сподвигло US Department of Commerce сделать несколько громких заявлений на прошлой неделе.

и ещё сообщение

Думаю, это стоит обсуждать в отдельной теме, чтобы все заинтересованные могли её найти, почитать и поделиться информацией.

Запускаю раст-сборку одной штуки, она на компиляции какого-то пакета устраивает SIGILL.

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

1) Как узнать точнее где он крашится? В dmesg только ip, туда можно как-то инструкцию вывести? coredump он не создаёт, команда ulimit -c unlimited перед сборкой не помогла.

2) Как расту глобально подсунуть требование не использовать новомодные инструкции?

Хотя странно - куча всего скомпилировалась а несколько пакетов падают.

SIGILL в бинарниках с названием build-script-build, судя по датам перд этим скопилированных.

www.linux.org.ru/forum/general/18298017 это не спам, это иностранец хотел обсудить red5 (опенсорсный видеостриминговый сервер, довольно старый) если и удалять то за 4.8

Я всегда думал что его там нет - ни ** ни pow() не работают, и считал его как e(l(x)*y). Сейчас заглянул в ман чтобы посмотреть как там определить кастомную функцию (чтобы задать pow в каком-нить конфиге), и случайно наткнулся на список арифметических операторов, где значком, обычно использующимся для XOR (^), оказывается обозначается возведение в степень. Правда, только в целочисленную, но в большинстве случаев другого и не надо.

Вскоре после обнаружения 18-летнего потенциального RCE было обнаружено ещё одно, CVE-2026-9256, на этот раз просуществовавшее ещё дольше — 21 год, начиная с версии 0.1.17, выпущенной в начале 2005 года. Для эксплуатации уязвимости требуется наличие в конфиге сервера директивы rewrite, у которой:

• в первом аргументе имеются перекрывающиеся выделяемые параметры регулярного выражения,
• во втором используется два или больше из них, но не используются переменные,
• при этом либо указан тип «redirect», либо параметры во втором аргументе находятся после знака вопроса.

( читать дальше... )

>>> Официальное объявление F5 (f5.com)

20 мая 2026 года разработчики FreeBSD объявили об исправлении семи новых уязвимостей в системе. Не все они одинаково опасны, но есть и крайне неприятные.

( читать дальше... )

>>> FreeBSD Security Advisories (freebsd.org)

13 мая была исправлена уязвимость в популярном для нагруженных систем веб-сервере nginx: CVE-2026-42945, потенциально могущая привести к RCE. Уязвимость появилась 18 лет (2008 год) назад в версии 0.6.27.

( читать дальше... )

Информация об уязвимости была предоставлена Zhenpeng (Leo) Lin из DepthFirst. Кроме того, он же сообщил о следующих проблемах, которые тоже исправлены:

• CVE-2026-40701 (коммит) use-after-free при использовании ssl_verify_client+ssl_ocsp (вроде бы без RCE)
• CVE-2026-42934 (коммит) чтение за пределами буфера в utf-8 парсере при специфических обстоятельствах, может привести к небольшой утечке данных или крашу рабочего процесса
• CVE-2026-42946 (коммит) чрезмерное выделение памяти и чтение за пределами буфера при использовании модулей scgi/uwsgi, проблема проявляется при наличии злонамеренного бекэнда (upstream) через указанные протоколы, либо при mitm канала общения с бекэндом, может привести к чтению памяти nginx или крашу рабочего процесса

>>> Официальное объявление F5 (f5.com)

Во-первых, оцените контакты на нижней стороне платы: картинка

Во-вторых, я заметил что на верхней контактные площадки тоже есть: картинка - зачем они нужны?

А ещё если их (речь про первые) залудить станет лучше или хуже?

Запускаю железку, попадаю в recovery mode, /boot не смонтировалось.

Написал mount -a - смонтировалось успешно, выхожу из recovery и всё грузится дальше и работает. Ребутать для проверок больше нельзя.

В journalctl -b было такое

systemd[1]: Mounting /boot...
systemd[1]: boot.mount mount process exited, code=exited status=32
systemd[1]: Failed to mount /boot.
systemd[1]: Unit boot.mount entered failed state

Прописано в fstab через UUID. Файловая система xfs. boot на том же устройстве что и /, при этом / разумеется ещё раньше смонтирован успешно, то есть устройство не могло к тому времени ещё не найтись ядром. В dmesg ничего про это не написано, только лог успешного монтирования из моего mount -a.

Что ему не понравилось и куда системг спрятал лог неудавшегося mount-а при старте?

«i/o error» на любые действия, после перетыкания в слот есть небольшое время когда можно запустить smartctl, затем опять отваливается.

=== START OF INFORMATION SECTION ===
Device Model:     SATAFIRM   S11

  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       271978

271978 - враньё, разумеется.

Понятное дело, что у него что-то слетело и чинить его нецелесообразно, но в чём причины могут быть? Это признак того что он поддельный или просто неудача? Стоял практически без нагрузки с момента покупки - занято меньше 10гб из 120, запись наверно меньше мегабайта в день (а может и вообще около нуля), чтение тоже не особо большое.

Допустим, я добавлю в свою пермиссивную лицензию пункт о запрете скармливания кода LLM-обучателям (включая косвенное скармливание путём отправки кода туда, где это с большой вероятностью будет сделано автоматически). Какие негативные последствия для продукта от этого могут случиться?

Обсуждения того, что бессовестные llm-щики на всё это наплюют и всё равно украдут код в свои бредогенераторы, прошу тут не устраивать, вопрос не про это.