Прошлый год интересно проходил для SSH. Весной — бэкдор в xz-utils (CVE-2024-3094), в результате эксплуатации которого были скомпрометированы системы с systemd. В июле — критически опасная уязвимость «состояния гонки» для систем на базе glibc, получившая название regreSSHion. Спустя еще неделю была опубликована схожая проблема, получившая идентификатор CVE-2024-6409. А в августе — еще одна, уже специфичная для FreeBSD, CVE-2024-7589.

Как заявляют исследователи, успешная эксплуатация «состояний гонки» позволяет получить RCE (удаленное выполнение кода) на подверженных системах. Более того, regreSSHion — главный баг, ставящий под угрозу безопасность множества SSH-серверов с glibc. Интересно, что эксплуатация уязвимости не требует особой конфигурации сервера (проблема актуальна и для конфигурации по умолчанию). При этом публичного PoC нет до сих пор. Мы решили разобраться в вопросе: так ли страшны эти «состояния гонки», так ли критически опасны? И какие механизмы в sshd призваны не допустить эксплуатации этой уязвимости или хотя бы уменьшить ущерб в случае успешной атаки?

Это продолжение цикла статей о том, как я занимался оптимизацией и получил самый быстрый ресайз на современных x86 процессорах. В каждой статье я рассказываю часть истории, и надеюсь подтолкнуть еще кого-то заняться оптимизацией своего или чужого кода. В предыдущих сериях:

→ Часть 0
→ Часть 1, общие оптимизации

В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.

Привет! Сегодня мы выложили в опенсорс Perforator — систему непрерывного профилирования (continuous profiling), которую используем внутри Яндекса для анализа производительности большинства сервисов.

В Github-репозитории доступен исходный код системы и инфраструктура для развёртывания своей инсталляции Perforator на кластере Kubernetes. Кроме того, Perforator можно использовать на своём компьютере как более простую замену perf record: профили получаются точнее, а оверхед меньше. Исходный код доступен под лицензией MIT (и GPL для eBPF-программ) и запускается под x86-64 Linux.

При помощи Perforator и прошлых подходов к задаче профилирования мы регулярно оптимизируем самые крупные сервисы в Яндексе, например Баннерную крутилку или Поиск, на десятки процентов. Кроме того, Perforator реализует недостающий в опенсорсе компонент профилирования для простой автоматической оптимизации программ с использованием profile-guided optimization. Наши тесты показывают, что использование PGO даёт ускорение около 10% в разных сценариях.

Под катом поговорим про профилирование под Linux, опишем вызовы и сложности, возникающие при профилировании, изучим, как устроен Perforator внутри, и обсудим, как можно использовать полученную систему.

Привет! Меня зовут Станислав Ермохин, я руководитель группы методического обеспечения в команде КОМПАС-3D. По ходу подготовки версии КОМПАС-3D для Linux мы встречаемся с «очевидными и невероятными» ситуациями. Решением одной из них решили поделиться. Тем более, что в Рунете не удалось найти достаточно полного описания, как назначать пользовательские иконки для файлов. Вся информация разрозненная, отрывочная или устаревшая. 

В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.

В целом эта функция обладает сомнительной прикладной полезностью, поэтому не удивительно, что в Linux готового аналога CreateRemoteThread нет. Однако, мне было интересно, как он может быть реализован. Изучение темы вылилось в неплохое приключение.

Я подробно расскажу о том, как с помощью спецификации ELF, некоторого знания архитектуры x86_64 и системных вызовов Linux написать свой маленький кусочек отладчика, способный загрузить и исполнить произвольный код в уже запущенном и работающем процессе.

Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

Наконец, я сломалась и начала это выяснять. Мне пришлось перелопатить тонны ресурсов разного качества и иногда противоречащих друг другу. Несколько недель исследований и почти 40 страниц заметок спустя я решила, что гораздо лучше понимаю, как работают компьютеры от запуска до выполнения программы. Я бы убила за статью, в которой объясняется все, что я узнала, поэтому я решила написать эту статью.

И, как говорится, ты по-настоящему знаешь что-то, только если можешь объяснить это другому.

Более удобный формат статьи.

В операционной системе, как и в жизни, обширны способы передачи информации: иногда можно деликатно сказать что-то в стиле «не будет ли любезен многоуважаемый джинн», или сделать жест рукой, чтобы твой собеседник понял без лишних слов, или в некоторых ситуациях достаточно лишь встретиться глазами, чтобы понять, как у тебя дела. Так и в арсенале ОС имеются сообщения из системного трея, обычные десктоп-уведомления из центра уведомлений, лампочки-индикаторы на клавиатуре, собственные уведомления у приложений и проч.

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

Хочу поделиться своим опытом участия в программе баг-хантинга ГК Астра (да, да - именно той, которая недавно совершила каминг‑аут IPO) на платформе BI.ZONE Bug Bounty.

Адрес TCP/IP поддерживает только 65000 подключений, поэтому придётся назначить этому серверу примерно 30000 IP-адресов.

Существует 65535 номеров TCP-портов, значит ли это, что к TCP-серверу может подключиться не более 65535 клиентов? Можно решить, что это накладывает строгое ограничение на количество клиентов, которые может поддерживать один компьютер/приложение.

Если есть ограничение на количество портов, которые может иметь одна машина, а сокет можно привязать только к неиспользуемому номеру порта, как с этим справляются серверы, имеющие чрезвычайно большое количество запросов (больше, чем максимальное количество портов)? Эта проблема решается распределением системы, то есть кучей серверов на множестве машин?

1. Мессенджер WhatsApp и веб-фреймворк Phoenix, построенный на основе Elixir, уже продемонстрировали миллионы подключений, прослушивающих один порт.
2. Теоретические возможности на основе протокола TCP/IP.
3. Простой эксперимент с Java, который может провести на своей машине любой, если его всё ещё не убедили мои слова.

Мы продолжаем цикл статей про математику и смежные дисциплины в компьютерной графике по курсу Александра Паничева, ведущего разработчика логики в UNIGINE. В этот раз поговорим о функциях плавности, которые используются в анимации (и не только).