Google продемонстрировал первую успешную атаку на алгоритм хеширования SHA-1

Через десять лет после начала использования алгоритма хэширования SHA-1 компания Google объявила о первом практическом методе генерации коллизии для SHA-1. Результаты были получены после двух лет исследований, проведённых корпорацией совместно с институтом CWI в Амстердаме. В качестве доказательства возможности совершения атаки, компания Google предоставила два PDF-файла, которые имеют одинаковые хеши SHA-1, но разное содержание.

Количество вычислений, необходимых для проведения разработанной в Google атаки, которая получила название SHAttered, ошеломляет: девять квинтильонов (9,223,372,036,854,775,808) операций подсчёта SHA-1 в общей сложности, которые потребовали 6500 лет вычислений на CPU для завершения атаки первой фазы и 110 лет вычислений на GPU для завершения второго этапа. При этом на системе со 110 GPU усовершенствованная атака занимает примерно год. Для сравнения, применение метода полного перебора (brute force) в 100 тысяч раз медленнее и для нахождения коллизии за год потребуется 12 миллионов GPU.

Google считает, что необходимо переходить на новые алгоритмы хеширования, такие как SHA-256 и SHA-3. Однако стоит отметить, что в настоящее время нет способов найти столкновения для хэшей MD5 и SHA-1 одновременно, что означает, что чтобы быть в безопасности все еще можно использовать старые доказанные хэш-функции, которые к тому же ускоряются аппаратно.

В рамках соглашения о раннем неразглашении уязвимостей, компания Google на 90 дней задержит публикацию практической реализации метода подбора коллизий (теоретическое описание уже доступно). После публикации кода для проведения атаки, им сможет воспользоваться любой желающий для повторения опыта создания одинаковых хэшей SHA-1 для разных PDF-файлов при наличии необходимых вычислительных ресурсов. Тем не менее для реализации защиты в настоящее время уже опубликован код библиотеки и утилиты, позволяющих выдавать предупреждения для файлов, вызывающих коллизии в SHA-1.

Источник: [ссылка]

Выпуск LEDE 17.01, форка дистрибутива OpenWrt

Представлен первый выпуск дистрибутива LEDE 17.01 (Linux Embedded Development Environment), основанного в мае прошлого года как форк проекта OpenWrt и также ориентированного на создание точек доступа и беспроводных маршрутизаторов. Сборки подготовлены для 32 целевых платформ, из которых 7 ранее не поддерживались в OpenWrt.

Форк был создан группой активных разработчиков OpenWrt, желающих поднять стабильность дистрибутива на новый уровень и избавиться от организационных проблем. В LEDE попытались реализовать предсказуемый цикл разработки, более либеральные правила приёма изменений и прозрачный процесс принятия решений с привлечением сообщества и проведением публичных обсуждений. В декабре в списках рассылки была предпринята попытка объединения OpenWrt и LEDE, но она пока не привела к конкретным действиям.

Ключевые новшества, реализованные после отделения от OpenWrt:

  • Добавлена поддержка большой порции новых плат, точек доступа и беспроводных маршрутизаторов;
  • Добавлена поддержка новых целевых платформ:
    • apm821xx (AppliedMicro APM821xx)
    • arc770 (Synopsys DesignWare ARC 770D)
    • archs38 (Synopsys DesignWare ARC HS38)
    • armvirt (QEMU ARM Virtual Machine)
    • ipq806x (Qualcomm Atheros IPQ806X
    • layerscape (NXP Layerscape)
    • zynq (Xilinx Zynq 7000 SoCs)
  • Реорганизована платформа Xen DomU, которая объединена с платформой x86/generic;
  • Удалены платформы: realview (на смену пришла платформа armvirt), ppc44x (не работоспособна) и netlogic (отсутствует оборудование);
  • Ядро Linux обновлено до версии 4.4.50 (в актуальном выпуске OpenWrt используется ядро 3.18);
  • Обновлены версии dnsmasq (c 2.73 до 2.76), busybox (с 1.23.2 до 1.25.1), mbedtls (c 1.3.14 до 2.4.0), openssl 1.0.2k, musl 1.1.16, gcc 5.4.0, binutils 2.25.1;
  • Для контроля целостности пакетов вместо MD5 задействован алгоритм хэширования SHA256;
  • Отключены небезопасные компоненты шифрования в mbedtls и OpenSSL (SSLv3, сжатие, NPN, Whirlpool и J-PAKE);
  • Включены опции для повышения защиты от уязвимостей и атак: в GCC активированы режимы «-Wformat -Wformat-security», добавлена защита от переполнения стека в пространстве пользователя и на уровне ядра, включён режим определения переполнения буферов (FORTIFY_SOURCE) и добавлена защита RELRO (RElocation Read-Only);
  • Улучшены сетевые возможности:
    • Поддержка SQM (Smart Queue Management) для минимализации негативного влияния промежуточной буферизации пакетов (Bufferbloat). Связанные с противодействием Bufferbloat изменения также реализованы для драйверов ath9k, mt76 и ath10k;
    • Для драйвера ath9k задействован планировщик Airtime, устраняющий аномалии на медленных системах;
    • Внесена большая порция исправлений, направленных на повышение стабильности работы беспроводного стека и драйвера ath9k;
    • В качестве опции добавлен альтернативный драйвер ath10k-ct от Candela-Tech;
    • Проведена работа по усилению защищённости IPv6;
  • Изменения в системе сборки:
    • Выполнено разделение базовой системы и поддерживаемых сообществом пакетов, что упростило распространение бинарных обновлений;
    • Решены проблемы с обработкой зависимостей пакетов, улучшена поддержка виртуальных пакетов;
    • Формирование отдельных образов rootfs для каждого устройства дало возможность индивидуально выбирать пакеты для профилей устройств;
    • Новый код сборки образов позволил сократить время компиляции и упростить определение профилей устройств;
    • В Makefile добавлены новые команды для запуска стандартных диагностических наборов;
    • Добавлена возможность загрузки исходных текстов при помощи Curl;
    • В коде сборки образов переработана сборка библиотек для улучшения переносимости между разными дистрибутивами Linux;
    • Добавлена поддержка сборки модулей ядра, используя SDK.

    Источник: [ссылка]

Уязвимость в ядре Linux, позволяющая получить права root

В ядре Linux выявлена уязвимость (CVE-2017-6074), позволяющая непривилегированному локальному пользователю выполнить код с правами root. Проблема устранена 17 февраля и проявляется во всех ядрах с поддержкой DCCP, начиная с 2.6.14 (октябрь 2005 г.) и вплоть до выпуска 4.9.11.

Обнаруживший уязвимость исследователь сообщил о создании рабочего эксплоита, который будет опубликован через несколько дней, как только основные дистрибутивы выпустят обновление с устранением проблемы. Обновления пакетов пока выпущены для RHEL и Ubuntu. Проблема остаётся неисправленной в Debian, Fedora, openSUSE, SUSE. Уязвимость проявляется только в ядрах, собранных с опцией CONFIG_IP_DCCP, которая почти во всех дистрибутивах включена по умолчанию.

Уязвимость выявлена Андреем Коноваловым при fuzzing-тестировании ядра при помощи пакета syzkaller. Проблема вызвана двойным освобождением блока памяти в функции dccp_rcv_state_process (net/dccp/input.c) и может быть эксплуатирована при обработке специально оформленного пакета DCCP_PKT_REQUEST, переданного через сокет, открытый с опцией IPV6_RECVPKTINFO. В обычных условиях выделенный под пакет буфер dccp_skb освобождается вызовом __kfree_skb из функции dccp_rcv_state_process при успешном завершении функции dccp_v6_conn_request.

При наличии флага IPV6_RECVPKTINFO адрес буфера dccp_skb дополнительно сохраняется в структуре ireq->pktopts и выставляется флаг использования буфера. Функция очистки в dccp_rcv_state_process вызывается независимо от флага, что может быть использовано для манипуляции с данными после их освобождения (use-after-free). В частности, атакующий может переписать произвольными данными содержимое другого объекта в ядре, используя технику «heap spraying«. Если перезаписанный объект содержал указатели на функции, вызываемые в процессе работы, то атакующий может добиться выполнения своего кода на уровне ядра.

Источник: [ссылка]

Инженеры из Google представили глобальную файловую систему Upspin

Группа инженеров из компании Google представила проект Upspin, в рамках которого разработан экспериментальный фреймворк для организации безопасного совместного доступа к файлам. Upspin определяет набор протоколов, интерфейсов и реализаций программных компонентов, позволяющих связать в единое пространство имён различные данные, такие как ФС и сервисы хранения. Код эталонной реализации Upspin написан на языке Go и распространяется под лицензией BSD. Проект развивается сотрудниками Google, но не является официальным продуктом компании.

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

Например, при желании опубликовать картинку из Facebook в Twitter, пользователю нужно загрузить картингу на локальный диск и затем отдельно загрузить её в Twitter. Чтобы передать файл другому пользователю или скопировать со смартфона на удалённый ПК, приходится загружать данные в одно из облачных хранилищ. При этом пользователь облачного хранилища не контролирует свои данные, которые могут попасть в чужие руки в результате потери контроля над учётной записью или действий со стороны облачного провайдера, поэтому при работе с конфиденциальными данными приходится накладывать ещё один слой в виде шифрования.

Upspin предлагает использовать для идентификации файла схему «ann@example.com/dir/file», состоящую из email пользователя и виртуального пути. Зная глобальный идентификатор файла, любой пользователь, при предоставлении ему доступа, может обратиться к этому файлу из любого локального приложения, как к обычному файлу в своей ФС, или из любого online-сервиса, поддерживающего Upspin. Кроме файлов и директорий Upspin позволяет организовать доступ к динамически меняющейся информации, такой как данные от датчиков или результаты запросов к сетевым сервисам. Для прикрепления глобального пространства имён к локальной ФС предоставляется FUSE-модуль. Для доступа также можно использовать программу upspin c набором типовых команд, таких как «cp». Для подключения к глобальной ФС достаточно установить одну из реализаций Upspin, создать ключи для своего email и зарегистрировать их в хранилище ключей.

Управление доступом производится путём создания в экспортируемой директории специального файла с именем Access, содержащего список полномочий, предоставленных другим пользователям. Например, добавив в файл правило «read: joe@here.com, mae@there.com», пользователи joe@here.com и mae@there.com получат возможность чтения файлов в текущей директории и поддиректориях. Кроме чтения, можно предоставить доступ к записи, просмотру содержимого каталога, удалению, созданию файлов и т.п. Возможно создание групповых политик, использование шаблонов (например, «read: all» и «*: all») и индивидуальное определение правил доступа к отдельным файлам.

Ключевой целью разработки является обеспечение наивысшего уровня безопасности. Производительности уделяется второстепенная роль. В частности, в Upspin применяются современные методы идентификации пользователей по открытым ключам. Для хранения и обнаружения открытых ключей планируется задействовать технологию Key Transparency (пока доступен только один экспериментальный централизованный сервер ключей key.upspin.io). По умолчанию применяется верификация содержимого по цифровой подписи и все данные передаются в зашифрованном виде с использованием end-to-end-шифрования, при котором закрытые ключи фигурируют только на конечных системах владельца файла и получателя. Подобный подход позволяет не только развернуть свой собственный сервер Upspin, но и делегировать хранение файлов в любое облачное хранилище, не опасаясь, что данные попадут в чужие руки в результате компрометации хранилища или диверсии персонала. При этом в Upspin не обеспечивается «forward secrecy», т.е. утечка закрытого ключа владельца, означает возможность доступа к перехваченным файлам.

Инфраструктуру Upspin составляют три компонента:

  • Сервер ключей, выполняет работу по хранению открытых ключей всех пользователей системы (приватные ключи хранятся отдельно, на стороне пользователей). Сервер ключей также имеет информацию об сетевых адресах серверов директорий. Пользователи могут воспользоваться уже работающим сервером ключей key.upspin.io или запустить свой собственный;
  • Сервер хранения, на котором непосредственно размещены хранимые данные. Каждый пользователь может запустить один или несколько серверов хранения;
  • Сервер директорий, предоставляющий информацию о том, какие данные размещены на серверах хранения. Сервер директорий может быть запущен в связке с сервером хранения для каждого пользователя или на группу пользователей, например, один на всю семью. Пользователь также может использовать сторонние серверы директорий и хранения, к которым ему предоставлен доступ (например, облачные сервисы).
  • Опционально реализован кэширующий сервер, который может применяться для кэширования данных при их передаче от удалённого сервера к клиенту.

Источник: [ссылка]

Первый выпуск проекта LibreELEC, ответвившегося от OpenELEC

После почти года разработки состоялся первый значительный релиз проекта LibreELEC, в рамках которого создан форк самобытного дистрибутива для создания домашних кинотеатров OpenELEC. Ключевым отличием LibreELEC 8.0 является переход на ветку открытого медиацентра Kodi 17.0 с новым движком воспроизведения видео, в то время как OpenELEC остаётся на Kodi 16. Для загрузки подготовлены образы для работы с USB-накопителя или SD-карты (32- и 64-разрядные x86, Raspberry Pi, Raspberry Pi 2, Odroid C2, WeTek Play, WeTek Core WeTek Hub и устройства на базе платформы Freescale iMX6), а также специальные сборки для обновления с OpenELEC.

Проект LibreELEC создан в результате конфликта между мэйнтейнером OpenELEC и большой группой разработчиков. Мэйнтейнер OpenELEC, единолично принимающий решения и полностью контролирующий процесс добавление изменений, был против перехода на новую кодовую базу Kodi 17 минуя Kodi 16. В итоге почти все сторонние разработчики основали свой форк LibreELEC с коллективной системой принятия решений, более открытый для инноваций и изменений. В настоящее время в OpenELEC остался только один активный разработчик, а за месяц внесено 17 изменений (добавлено 731 строк, удалено 587), в то время как в LibreELEC наблюдается 24 разработчика, за месяц подготовивших 383 изменений (добавлено 48814 строк, удалено 40355).

Решения по развитию LibreELEC принимает совет, который выбирается из наиболее активных разработчиков. Из отличий также выделяется наличие графика разработки, позволяющего узнать когда выйдет новая версия или очередное обновление. Экспериментальные возможности развиваются в master-ветке, на основе которой создаются отдельные ветки для стабильных выпусков, в которые допускается только внесение исправлений.

Напомним, что OpenELEC не является ответвлением от существующих дистрибутивов и основывается на собственных разработках. Кроме штатных возможностей Kodi, дистрибутив предоставляет ряд дополнительных функций, нацеленных на максимальное упрощение работы. Например, развивается специальное конфигурационное дополнение, позволяющее настроить параметры сетевого подключения, управлять параметрами LCD-экранов, разрешить или запретить автоматическую установку обновлений. Дистрибутив поддерживает такие возможности, как использование пульта дистанционного управления (возможно управление как через инфракрасный порт, так и через Bluetooth), организация совместного доступа к файлам (встроен сервер Samba), встроенный BitTorrent-клиент Transmission, автоматический поиск и подключение локальных и внешних накопителей.

При помощи LibreELEC можно превратить любой компьютер в медиацентр, работать с которым не сложнее, чем с DVD-проигрывателем или телеприставкой. Основной принцип дистрибутива «всё просто работает», для получения полностью готового к работе окружения достаточно просто загрузить LibreELEC с Flash-накопителя. Пользователю нет необходимости заботиться о поддержании системы в актуальном состоянии — в дистрибутиве используется система автоматической загрузки и установки обновлений, активируемая при подключении к глобальной сети. Предусмотрена возможность расширения функциональности дистрибутива через систему дополнений, которые устанавливаются из отдельного репозитория, развиваемого разработчиками проекта.

Источник: [ссылка]

Доступен Wayland 1.13

Состоялся стабильный релиз протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.13. Ветка 1.13 обратно совместима на уровне API и ABI с выпусками 1.x, но дополнительно содержит порцию улучшений. Кроме исправления ошибок в Wayland 1.13 реализован API для управления видимостью глобальных структур, при помощи которого композитный сервер может ограничить доступ к приватным программным интерфейсам и определить к каким частям структуры wl_global клиент имеет доступ. Следующий выпуск 1.14 запланирован на июнь 2017 года.

Ожидавшийся сегодня выпуск композитного сервера Weston 2.0 отложен до конца недели из-за выявления в последний момент ошибок, исправления для которых требуют дополнительного тестирования. Напомним, что Weston развиваются технологии, содействующие появлению полноценной поддержки протокола Wayland в Enlightenment, GNOME, KDE и других пользовательских окружениях. Разработка Weston нацелена на предоставление высококачественной кодовой базы и рабочих примеров для использования Wayland в десктоп-окружениях и встраиваемых решениях, таких как платформы для автомобильных информационно-развлекательных систем, смартфонов, телевизоров и прочих потребительских устройств.

Смена номера значительной версии в Weston 2.0 обусловлена изменениями в новом API управления выводом, нарушающими совместимость c libweston на уровне ABI. Все штатные бэкенды портированы на новый API для настройки вывода. В новой версии также добавлена поддержка EGL-расширения EGL_KHR_swap_buffers_with_damage, реализованного в проприетарном драйвере NVIDIA. В бэкенде GL добавлена поддержка буферов DRM_FORMAT_YUV444. Улучшено позиционирование панелей в desktop-shell. В XWayland приведены в порядок сообщения об ошибках.

Статус поддержки Wayland в окружениях рабочего стола и дистрибутивах:

  • В рамках проекта AsteroidOS развивается новая открытая ОС для умных часов, использующая Qt5 и Wayland.
  • В находящейся в разработке ветке GNOME 3.24 продолжается оттачивание поддержки Wayland, которая ранее уже была объявлена пригодной для использования обычными пользователями. Добавлена возможность работы поверх проприетарных драйверов NVIDIA, c использованием EGLDevice и EGLStreams;
  • В Fedora 25 по умолчанию предложен сеанс GNOME на базе Wayland;
  • В Ubuntu GNOME продолжается тестирование экспериментального сеанса рабочего стола GNOME на базе Wayland (следует установить пакет gnome-session-wayland и выбрать на экране входа «GNOME on wayland»);
  • Продолжается работа по достижению паритета в функциональности при запуске KDE поверх X11 и Wayland. В KDE Plasma 5.9 при использовании Wayland стали доступны инструменты для создания скриншотов и определения цвета, обеспечены возможности раскрытия окон на весь экран без отображения рамок, задания собственных цветовых схем и перетаскивания приложений кликом на пустой области интерфейса, добавлен поддержка режима автоматического скрытия панели, добавлена поддержка управляющих жестов. Для тестирования проектом Neon подготовлены Live-сборки на базе Wayland;
  • Начиная с Qt 5.8 переведён в разряд полностью поддерживаемых модуль Qt Wayland Compositor с многопоточной системой отрисовки для встраиваемых устройств, использующая протокол Wayland. Модуль может использоваться для создания собственных композитных серверов Wayland, применяя QML или C++ API. Имеется поддержка стандарта XDG-Shell и возможность работы в системах с несколькими экранами. В качестве примера применения Qt Wayland Compositor развивается рабочий стол Grefsen;
  • В Enlightenment ведётся работа по улучшению поддержка Wayland;
  • В ОС DragonFly BSD развивается порт с Wayland и Weston, имеется поддержка XWayland;

  • Wayland задействован по умолчанию в мобильных платформах Plasma Mobile, Sailfish 2 и Tizen 3.
  • В панели Cairo-Dock предусмотрена возможность работы в окружении композитного сервера Weston.
  • Работа по добавлению поддержки Wayland ведётся для рабочих столов LXQt и MATE.
  • Развиваются новые десктоп-окружения, работающее только на базе технологий Wayland: papyros-shell, Hawaii и Orbital.
  • Для тестирования работы GNOME, KDE и Enlightenment, Hawai и Orbital поверх Wayland выпускается специальный Live-дистрибутив Rebecca Black Linux.

Напомним, что Wayland представляет собой протокол взаимодействия композитного сервера и работающих с ним приложений. Клиенты самостоятельно выполняют отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях композитному серверу, который комбинирует содержимое буферов отдельных приложений для формирования итогового вывода с учётом возможных нюансов, таких как перекрытие окон и прозрачность. Иными словами, композитный сервер не предоставляет API для отрисовки отдельных элементов, а оперирует только с уже сформированными окнами, что позволяет избавиться от двойной буферизации при использовании высокоуровневых библиотек, таких как GTK+ и Qt, берущих на себя работу по компоновке содержимого окон. В настоящее время поддержка прямой работы c Wayland уже реализована для библиотек GTK3+, Qt 5, SDL (начиная с выпуска 2.0.2), Clutter и EFL (Enlightenment Foundation Library). Начиная с Qt 5.4 в состав включён модуль QtWayland с реализацией компонентов для работы Qt-приложений в окружении композитного сервера Weston, развиваемого проектом Wayland.

Взаимодействие с аппаратным обеспечением в Wayland/Weston, например, проведение инициализации, переключение видеорежимов (drm modesetting) и управление памятью (GEM для i915 и TTM для radeon и nouveau) графических карт, может производиться напрямую через модуль, работающий на уровне ядра, что позволяет обойтись без привилегий суперпользователя. Композитный сервер Weston может работать не только с использованием DRM-модуля ядра Linux, но и поверх X11, другого композитного сервера Wayland, фреймбуфера и RDP. Кроме того, развиваются проекты по обеспечению работы поверх графического стека платформы Android.

В рамках проекта Weston развивается одна из реализаций композитного сервера. В роли композитного сервера также может выступать любой другой продукт, поддерживающий протокол Wayland. Например, в настоящее время ведётся работа по обеспечению поддержки Wayland в KWin. В текущем виде Weston уже вышел за рамки набора примеров для тестирования протокола Wayland и может обрастать функциональностью через плагины и дополнения. Пользовательские оболочки и расширенные функций управления окнами предлагается реализовывать в форме внешних бэкендов к Weston.

Для обеспечения выполнения обычных X11-приложений в окружении на базе Wayland используется DDX-компонент XWayland (Device-Dependent X), похожий по организации работы на Xwin и Xquartz для платформ Win32 и OS X. Поддержку запуска X11-приложений планируется встроить непосредственно в композитный сервер Weston, который при попытке выполнения X11-приложения будет инициировать запуск X-сервера и связанных с ним компонентов XWayland. При таком подходе процесс запуска X11-приложений будет бесшовным и неотличимым для пользователя от запуска приложений, работающих напрямую с Wayland.

Источник: [ссылка]

Выпуск системы динамической отладки SystemTap 3.1

После почти года разработки увидел свет релиз системы динамической трассировки SystemTap 3.1, предоставляющий для платформы Linux средства похожие на технологию DTrace. SystemTap позволяет организовать доскональное наблюдение за работающей Linux системой, производить сбор статистики о работе приложений, профилирование и контроль системных вызовов. Управление производится через интерфейс командной строки и специальный Си-подобный язык сценариев. Система протестирована с ядрами Linux начиная с версии 2.6.18 и заканчивая 4.10-rc8.

В развитии проекта участвуют такие компании как Red Hat, IBM, Intel, Hitachi и Oracle. В каталоге примеров представлено 163 скрипта на все случаи жизни, подходящие для слежения за распределением памяти, вводом/выводом, дисковыми операциями, сетевым трафиком (например, анализ работы NFS), работой планировщика задач, обработкой прерываний, использованием системных буферов, установкой блокировок, выполнением системных вызовов, обработкой сигналов и т.п.

Новая версия примечательна добавлением средств для осуществления контрольных проверок для функций в скриптах на языке Python. Для отслеживания работы Python-скриптов предлагается специальный вспомогательный модуль, позволяющий прикреплять внешние SystemTap-обработчики к точкам входа и возврата из функций, а также к определённому номеру строки. Например, для получения информации об аргументах вызова функции «foo» во время выполнения скрипта «myscript» можно использовать следующую конструкцию: ‘probe python2.module(«myscript»).function(«foo»){ println($$parms)}’.

Кроме того упрощена трассировка приложений на языке Java — все параметры вызова Java-методов теперь преобразуются в строковые значения и обрабатываются в таком виде в обработчиках контрольных проверок (ранее поддерживалась лишь передача целочисленных параметров). Увеличена производительность контрольных проверок для ядра Linux. Произведено слияние тапсетов (tapsets) Syscall и nd_syscall, что позволило унифицировать обработку проверок системных вызовов, независимо от использования отладочного формата DWARF (по умолчанию используются проверки на базе DWARF, но при отсутствии DWARF осуществляется откат на проверки без DWARF).

Добавлены новые примеры использования SystemTap: отслеживание продолжительности сеансов и трафика для всех сетевых сокетов заданного процесса; ведение лога работы сервера nfsd (IP клиента, тип операции и имя файла); сохранение сведений о начинке сетевых пакетов; отображение сведений о повторной отправке пакетов TCP; вывод гистограммы о задержках и времени выполнения задач; мониторинг корректности создания изолированных контейнеров через отслеживание заблокированных обращений к системным вызовам.

Источник: [ссылка]

Проект Fedora рассматривает возможность отказа от альфа-выпусков

Дэннис Гильмор (Dennis Gilmore) и Адам Уильямсон (Adam Williamson), ответственные за выпуск релизов и контроль качества в проекте Fеdora, опубликовали план отказа дистрибутива от формирования альфа-выпусков. Вместо тестирования отдельной альфа-версии, благодаря применению средств автоматизированного тестирования, предлагается обеспечить постоянное нахождение репозитория Rawhide в состоянии альфа-качества.

Такой подход даст возможность пользователям использовать ежедневные сборки Rawhide для оценки состояния дистрибутива в любое удобное время. Разработчиков Fedora новая схема избавит от лишней рутины, связанной со сборкой, отдельным тестированием и поставкой альфа-версий. Перед помещением в репозиторий каждый пакет будет проходить автоматизированное тестирование, позволяющее убедиться, что пакет будет корректно установлен и не нарушит работу других пакетов.

Новую схему планируется воплотить в жизнь начиная с цикла разработки Fedora 27, если будет получено одобрение комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива. Маловероятно, что комитет отклонит предложение, так как автор инициативы, Дэннис Гильмор, является членом FESCo и отвечает за подготовку релизов. Кроме того, подобная схема хорошо зарекомендовала себя в дистрибутиве Ubuntu, который отказался от альфа-сборок в 2012 году.

Источник: [ссылка]

В NetBSD обеспечена поддержка повторяемых сборок

Проект NetBSD объявил о реализации возможности осуществления повторяемых сборок, позволяющих убедиться, что распространяемые бинарные файлы собраны из предоставляемых исходных текстов и не содержат скрытых изменений. Повторяемые сборки пока поддерживаются только для архитектур amd64 и sparc64.

Похожие инициативы развиваются проектами FreeBSD, Debian, Fedora, Ubuntu, Tails, OpenWrt, LEDE, openSUSE и Arch Linux. Например, во FreeBSD уже обеспечена возможность повторяемой сборки базовой системы и примерно 80% портов, а в Debian Testing повторяемые сборки реализованы для более чем 90% пакетов.

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

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

Источник: [ссылка]

Релиз ядра Linux 4.10

После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 4.10. Среди наиболее заметных изменений: решение проблемы с подвисаниями при интенсивном копировании на медленные USB-носители, поддержка технологии виртуализации GPU, возможность привязки обработчиков BPF к cgroups, поддержка шифрования в UBIFS, реализация кэша обратной записи для MD RAID5, поддержка Intel Cache Allocation Technology, возможность использования объектов с сохранением состояния в netfilter, гибридный режим поллинга ввода/вывода для блочных устройств, средства для маршрутизации сетевых пакетов с учётом UID-идентификаторов процессов.

В новую версию принято около 13 тысяч исправлений от 1647 разработчиков, размер патча — 50 Мб (изменения затронули 11674 файлов, добавлено 743994 строк кода, удалено 249421 строк). Около 47% всех представленных в 4.10 изменений связаны с драйверами устройств, примерно 17% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 15% связано с сетевым стеком, 4% — файловыми системами и 5% c внутренними подсистемами ядра. 13.7% изменений внесено сотрудниками компании Intel, 7.1% изменений подготовлено сотрудниками Red Hat, 4.3% — Samsung, 3.9% — Linaro, 3.7% — SUSE, 3.0% — IBM, 2.5% — AMD, 2.4% — Google, 1.4% — Oracle, 1.4% — ARM.

Основные новшества:

  • Дисковая подсистема, ввод/вывод и файловые системы
    • Интегрированы патчи с улучшенной реализацией механизма фонового сброса данных на накопитель, решающие проблемы с подвисаниями во время копирования данных на медленный USB-накопитель. На системах с большим объёмом ОЗУ и медленными устройствами ввода/вывода переносимые на накопитель данные буферизируются в кэше обратной записи и копирование завершается в фоне. Ранее, операции сброса кэша обратной записи приводили к существенному снижению отзывчивости интерфейса приложений, подобных Firefox, вплоть до невозможности нормальной работы в течение нескольких минут. Например, выполнение «dd if=/dev/zero of=foo bs=1M count=10k» или копирование большого файла на USB-накопитель не давало запустить браузер или любое крупное приложение пока оставался не сброшен кэш обратной записи.

      Предложенный в новом ядре режим «writeback throttling» решает указанную проблему благодаря урезанию интенсивности очистки кэша при наличии в очереди других операций ввода/вывода, что затрудняет монополизацию очереди ввода/вывода операциями интенсивной записи. Алгоритм урезания отслеживает появление задержек и изменение размера очереди, автоматически корректируя параметры для достижения оптимального результата. В итоге удалось решить проблемы с отзывчивостью за счёт незначительного увеличения времени сброса данных из кэша;

    • В подсистему MD RAID добавлена поддержка флага failfast, который может быть привязан к дискам в процессе создания массивов RAID1 или RAID10, и активирует режим быстрого перевода устройства в режим сбоя. В случае неудачного завершения операции ввода/вывода диск будет сразу выведен из массива, без проведения полноценной обработки ошибки и повторных попыток проведения операции чтения;
    • В MD RAID также реализован кэш обратной записи для RAID5, позволяющий агрегировать операции записи для последующей единовременной записи блока чётности, что позволяет добиться повышения производительности в условиях последовательной записи данных с дальнейшим выполнением операции fsync;
    • В дополнение к появившейся в ядре 4.4 поддержке поллинга ввода/вывода для блочных устройств (I/O polling), в новой версии представлен режим гибридного адаптивного поллинга для блочных устройств. Поллинг позволяет уменьшить нагрузку на систему при использовании высокопроизводительных устройств за счёт периодического опроса состояния вместо генерации прерываний, при этом эффективность поллинга высока только при высокой нагрузке, иначе затраты ресурсов CPU на периодический опрос могут привышать затраты на обработку прерываний. Гибридный режим, вместо выполнения поллинга после завершения операции ввода/вывода, выполняет поллинг через искусственную задержку (например, если операция ввода/вывода длится 8 мкс, то опрос инициируется через 4 мкс), что позволяет инициировать цикл пробуждения до завершения операции, а не пробудиться уже после завершения. Данный подход позволяет значительно сократить задержки без повышения нагрузки на CPU. По умолчанию гибридный режим отключен и для активации требует установки параметра /sys/block/{dev}/queue/io_poll_delay;
    • В F2FS, развиваемой компанией Samsung высокопроизводительной файловой системе для Flash-накопителей, появилась возможность объединения нескольких устройств в рамках одного большого виртуального раздела с одним экземпляром F2FS;
    • В файловую систему UBIFS, предназначенную для Flash-накопителей, добавлена поддержка шифрования;
    • В файловой системе Ext4 добавлена защита от включения режима журналирования данных для зашифрованных разделов (функции журналирования и шифрования данных не совместимы, но ранее могли быть активированы вместе из-за ошибки в настройках). Реализация DAX (прямой доступ к файлам) переведена на использование инфраструктуры iomap;
    • В XFS реализован более быстрый метод поиска в используемых для кэша буферах, iomap задействован для прямого ввода/вывода (Direct I/O), объявлены устаревшими опции монтирования barrier/nobarrier;
    • В CIFS добавлена новая опция монтирования «snapshot=время», позволяющая примонтировать прошлую версию внешнего раздела;
    • Из состава ядра удалена файловая система logfs, которая несколько лет находится без сопровождения и на практике не используется;
    • Добавлена поддержка высокоприоритетных команд ATA, передаваемых устройству вне очереди. По умолчанию данный режим отключен;
  • Виртуализация и безопасность
    • Реализована технология виртуализации GPU Intel GVT-g для гипервизора KVM (KVMGT), которая позволяет предоставить для каждого виртуального окружения отдельный виртуальный GPU, в котором при выполнении требующих высокой производительности операций могут быть задействованы ресурсы реального системного GPU. Виртуальный GPU позволяет использовать внутри гостевых систем обычные видеодрайверы, не требующие вмешательства гипервизора для обеспечения должной производительности. В итоге, KVMGT позволяет добиться хорошего баланса между производительностью, функциональностью и совместным использованием ресурсов, приближая производительность виртуализированной графической подсистемы к конфигурациям с полным пробросом GPU, но предоставляя возможность совместного использования GPU между виртуальными машинами без применения полной эмуляции или трансляции API DirectX/OpenGL;
    • На системах с прошивками EFI ядро получило возможность сохранять некоторые случайные данные в виде EFI-переменных и затем на этапе загрузки использовать их для инициализации генератора псевдослучайных чисел. Данная возможность позволяет получить высокое качество энтропии сразу после начала загрузки.
    • В криптографические компоненты ядра включена новая подсистема «acomp«, позволяющая сжимать данные в асинхронном режиме;
    • В подсистему virtio включено новое устройство virtio-crypto для обеспечения шифрования, предоставляющее типовые криптографические операции для виртуализированных гостевых систем;
    • Для архитектуры PowerPC реализована поддержка системного вызова kexec_file_load(), позволяющего выполнить проверку по цифровой подписи для нового ядра, перед его запуском с использованием механизма kexec. Для PowerPC также обеспечена возможность сборки ядра с опциями защиты стека;
  • Сетевая подсистема
    • В сетевом стеке обеспечена поддержка маршрутизации сетевых пакетов с учётом UID-идентификатора процесса получателя или отправителя. Возможность перенесена из платформы Android, на которой используется для создания политик маршрутизации, привязанных к отдельным приложениям. Например, администратор теперь может использовать правила вида «ip rule add uidrange 100-200 lookup 123» для задания иных правил маршрутизации для процессов с UID c 100 по 200;
    • Для IPv6 реализована поддержка Segment Routing (SR-IPv6), одной из новых техник маршрутизации от источника (source-routing);
    • В подсистему netfilter добавлена поддержка объектов с сохранением состояния (stateful objects), которые могут быть идентифицированы уникальным именем, заданным пользователем, и прикреплены к таблицам пакетного фильтра. В настоящее время поддерживается два типа таких объектов — счётчики и квоты;
    • В nftables добавлена поддержка выражения «rt nexthop», позволяющего проверить nexthop (IP-адрес шлюза для отправки исходящих пакетов). Например правило «nft add rule filter postrouting ip daddr 192.168.1.0/24 rt nexthop != 192.168.0.1 drop», заблокирует любой трафик к подсети 192.168.1.0/24, маршрутизируемый не через шлюз 192.168.0.1;
    • Добавлена возможность привязки программы BPF к cgroups для обеспечения фильтрации и учёта сетевого трафика для всех процессов, которые подпадают под эти cgroups. Возможность реализована через новый тип BPF-программ BPF_PROG_TYPE_CGROUP_SKB и две новые команды систменого вызова bpf — BPF_PROG_ATTACH и BPF_PROG_DETACH. Дополнительно реализован тип BPF_PROG_TYPE_CGROUP_SOCK, позволяющий привязать BPF-обработчик к открытию любого сокета AF_INET или AF_INET6 процессом из заданного cgroups;
    • Добавлена возможность привязки программы BPF к инфраструктуре легковесных сетевых туннелей для контроля за передаваемым трафиком или для его модификации на лету;
  • Память и системные сервисы
    • Добавлена поддержка технологии CAT (Cache Allocation Technology), присутствующей в некоторых процессорах Intel Xeon и позволяющей определить политику распределения L2/L3 кэшей в CPU, например задачам реального времени может быть выделен отдельный участок кэша;
    • Добавлен механизм устройств-посредников («mediated device«), реализованных программно через интерфейс VFIO (Virtual Function I/O, виртуализированные драйверы устройств, работающие в пространстве пользователя). Например, представленный интерфейс использован в технологии виртуальных GPU, работа которых обеспечивается за счёт привлечения возможностей имеющегося физического GPU;
    • Добавлен драйвер uleds (Userspace LEDs), позволяющий эмулировать LED-индикаторы или создавать драйверы для LED-индикаторов, работающие в пространстве пользователя. Взаимодействие между ядром и драйвером в пространстве пользователя производится через устройство /dev/uleds;
    • В BPF появилась поддержка новой map-структуры с реализацией LRU-списка c вытеснением записей, которые не использовались дольше всех;
    • Расширены средства фильтрации точек трассировки (tracepoint — вариант динамических printf(), выставляемых разработчиками программ для анализа поведения системы, к которым затем можно обращаться из LTTng, perf, SystemTap, ftrace). Если раньше можно было определять только простейшие маски, то теперь средства фильтрации точек трассировки значительно расширены и по своим возможностям напоминают шаблоны для выбора имени файла в командных оболочках;
    • Реализован новый инструмент «perf c2c» (c2c — «cache to cache»), предназначенный для выявления и анализа проблем с производительностью, вызванных некорректной организацией совместной работы с памятью на системах NUMA. В частности, на многопроцессорных системах NUMA разные модули памяти физически закреплены за разными CPU, при этом доступ к локальной памяти текущего процессора осуществляется быстрее, чем к памяти, закреплённой за другим CPU. В многопоточных приложениях разные потоки могут выполняться на разных CPU, но работать с одной памятью, что в условиях архитектуры NUMA может привести к снижению производительности. При помощи «perf c2c» можно выявить подобные обращения к памяти чужого CPU, оценить задержки и узнать на работу каких процессов и функций они влияют;
    • Подготовлен отчёт ‘perf sched timehist‘ для анализа событий планирования выполнения задач, включая время ожидания выполнения, задержки и фактическое время выполнения задачи. Например, «perf sched record — sleep 1; perf sched timehist»:
                   time    cpu  task name         wait time  sch delay  run time                            [tid/pid]            (msec)     (msec)    (msec)          -------- ------  ----------------  ---------  ---------  --------          1.874569 [0011]  gcc[31949]            0.014      0.000     1.148          1.874591 [0010]  gcc[31951]            0.000      0.000     0.024          1.874603 [0010]  migration/10[59]      3.350      0.004     0.011          1.874604 [0011]                  1.148      0.000     0.035          1.874723 [0005]                  0.016      0.000     1.383          1.874746 [0005]  gcc[31949]            0.153      0.078     0.022    
  • Оборудование
    • Добавлена поддержка новых устройств с процессорами на базе архитектуры ARM: смартфоны Huawei Nexus 6P и LG Nexus 5x, телеприставки Nexbox A1 и A95X Android TV, платы Pine64 на базе процессоров Allwinner A64, платы Globalscale Marvell ESPRESSOBin на основе Armada 3700 и платы Renesas «R-Car Starter Kit Pro» (M3ULCB), предназначенные для автоматизации информационно=развлекательных автомобильных систем;
    • В DRM-драйвер (Direct Rendering Manager) Nouveau добавлена поддержка чипсетов GP102 и GP106, реализован режим атомарного переключения видеорежимов, добавлена поддержка MST (Displayport 1.2 Multistream) и возможность NvBoost для ручного повышения частоты для увеличения производительности;
    • В драйвере AMDGPU появилась поддержка виртуальных устройств, реализована возможность экспорта информации из видео-BIOS, добавлен новый менеджер видеопамяти, разбивающий операции распределения VRAM на блоки в 4MB. Добавлена поддержка ещё не поступивших в продажу графических карт AMD Polaris12;
    • В драйвер для GPU Intel добавлена поддержка технологии разгона процессоров Turbo Boost Max 3.0, реализованной в CPU семейства Broadwell-E и позволяющей увеличить производительность однопоточных приложений за счёт завышения тактовой частоты, при удержании допустимых границ мощности и температуры.
    • Добавлен драйвер для Amlogic Meson Graphic Controller, используемого в SoC GXBB/GXL/GXM;
    • Добавлен драйвер для графической подсистемы ZTE VOU;
    • Добавлена поддержка семейства процессоров AMD Fam17h (AMD Ryzen);
    • Для архитектуры ARM64 добавлена поддержка системы контрольных проверок uprobes (userspace probes), используемой для анализа поведения приложений, выполняемых в пространстве пользователя. Для ARM64 также обеспечена эмуляция режима предотвращения привилегированного доступа («privileged access never»), не позволяющего ядру неявно обращаться к памяти пространства пользователя;

Латиноамериканский Фонд свободного ПО оперативно сформировал вариант полностью свободного ядра 4.10 — Linux-libre 4.10-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В новом выпуске очищен от блобов драйвер st_fdma. Обновлён код чистки блобов для драйверов amdgpu, adreno, i915, radeon, iwlwifi, slicoss, bfad, проведена чистка документации alsa. Прекращено вырезание блобов для драйвера STE-Modem, который исключён из ядра. Выделены типовые маски для префиксов в именах блобов в драйвере iwlwifi.

Источник: [ссылка]

Отчёт о развитии FreeBSD за четвёртый квартал 2016 года

Опубликован отчёт о развитии проекта FreeBSD с октября до декабрь 2016 года.

Основные достижения:

  • Система
    • Отмечается значительный прогресс в организации динамического связывания объектных файлов FreeBSD с использованием компоновщика LLD, развиваемого проектом LLVM. Изменения, принятые в основные кодовые базы LLD и FreeBSD позволили осуществить связывание всей базовой системы FreeBSD/amd64 с использованием LLD. В настоящее время ведётся работа по обеспечению сборки дерева портов с использованием LLD, постепенно устраняются проблемы, всплывающие в портах и LLD. На момент написания отчёта LLD уже мог применяться для связывания около 95% портов для архитектуры amd64;
    • Во FreeBSD HEAD добавлена начальная реализация фильтра /usr/sbin/prometheus_sysctl_exporter для формирования метрик о состоянии системы для платформы мониторинга Prometheus. Целью проекта является возможность экспорта всего дерева sysctl в виде метрик к Prometheus. Развиваемая возможность в том числе может быть использована для упрощения отладки разработчиками ядра, например, добавив новый счётчик можно построить график с отражением динамики наступления определённых событий в ядре;
    • Налажено автоматизированное тестирование в системах непрерывной интеграции (Travis CI и Jenkins) библиотеки Libarchive, предоставляющей средства для работы с различными форматами архивов и сжатых файлов, которая используется в таких BSD-утилитах, как tar, cpio, ar, unzip и pkg. Проведена чистка кода и Fuzzing-тестирование, что позволило выявить порцию ошибок и уязвимостей. Из функциональных улучшений отмечается поддержка NFSv4 ACL для архивов pax, которая уже перенесена во FreeBSD-CURRENT, что даёт возможность сохранять и восстанавливать NFSv4 ACL из tar-архивов;
    • Началось воплощение проекта по созданию дополнительного репозитория для сборочного инструментария под лицензией GPLv3, который позволит ускорить развитие портов с внешними инструментами и пакетами на архитектурах, не поддерживаемых в LLVM на должном уровне;
    • Обсуждается вопрос перехода на реализацию Unicode _STDC_ISO_10646_, уже используемую в Linux glibc;
    • В рамках кампании по сбору пожертвований в 2016 году собрано более полутора миллионов долларов. Кроме оплаты работы нескольких инженеров в режиме полного рабочего дня, в 2016 году профинансированы проекты по разработке порта для архитектуры arm64, интеграции фреймворка виртуализации VIMAGE (базируется на Jail и виртуальном сетевом стеке VNET), усовершенствованию инструментария и интеграции динамического межсетевого экрана blacklistd. Введены в строй два новых сервера для сборки релизов, четыре сервера для сборки пакетов, сервер непрерывной интеграции (ci.FreeBSD.org), два сервера ThunderX для сборки пакетов для архитектуры arm64, четыре вспомогательных сборочных сервера.
  • Изолированные окружения, эмуляторы, безопасность и ограничения ресурсов
    • Развивается проект по обеспечению повторяемых сборок FreeBSD, при которых сборка одних и тех же исходных текстов приводит к генерации тождественных бинарных файлов, совпадающих побитово, что позволяет любому желающему убедиться в том, что сборка ISO-образа произведена из заявленных исходных текстов. За отчётный период проведена работа по интеграции подготовленных изменений в базовую систему FreeBSD. Обеспечена возможность повторяемой сборки базовой системы (ядро и окружение пользователя). После базовой системы усилия разработчиков смещаются на дерево портов. В настоящее время число портов, для которых поддерживаются повторяемые сборки находится на уровне 80%;
    • К включению в состав FreeBSD HEAD и STABLE готовится обновление пакета OpenBSM 1.2 alpha 5 с открытой реализации Sun Basic Security Module (BSM) Audit API, предоставляющего средства для управления аудитом системы;
    • Продолжается развитие набора драйверов для работы в гостевых системах под управлением гипервизора Hyper-V и облачной платформы Azure. За отчётный период проведена оптимизация производительности сетевого драйвера, реализована поддержка live-бэкапов виртуальных машин и возможность проброса устройств PCIe, добавлена поддержка vDSO для ускорения выполнения вызова gettimeofday(2). Подготовлен образ FreeBSD 11.0 для Azure;
    • Обеспечены регулярные сборки для облачных окружений Amazon EC2 с автоматической загрузкой снапшотов и релизов для всех ргионов. По данным каталога AWS Marketplace более 800 пользователей уже применяют FreeBSD/EC, а число активных экземпляров FreeBSD в облаке Amazon достигло 2000 (статистика не учитывает установки из консоли или через EC2 API). Добавлена поддержка сервиса Amazon Simple Systems Manager («run command»). Релиз FreeBSD 11.0 вышел с поддержкой расширенных сетевых возможностей окружений EC2 C3, C4, R3, I2, D2 и M4 (кроме m4.16xlarge) и оптимизацией дисковой подсистемы (примерно на 20% возросла пропускная способность);
  • Системы хранения и файловые системы
    • Продолжается разработка порта распределённого хранилища Ceph для FreeBSD. Порт пока охватывает только объектное хранилище RADOS (Object Storage) и инструментарий. Блочное устройство RBD (Ceph Block Device) и файловая система CephFS пока не готовы. Итоговой целью проекта является предоставление возможности развёртывания кластера Ceph с узлами хранения на базе FreeBSD и ZFS, а также поддержка запуска виртуальных машин bhyve на виртуальных дисках, развёрнутых поверх блочного устройства Ceph RBD. За отчётный период реализация RBD доведена до возможности сборки и использования для управления блочными устройствами RADOS, переработан код для работы с потоками и поллингом, налажен процесс сборки компонентов ceph в системе непрерывной интеграции;
  • Поддержка оборудования
    • Реализована поддержка I2C, GPIO и SPI для материнской платы MinnowBoard на базе Intel Atom E38xx SoC, относящейся к категории Open Hardware;
    • В основной состав FreeBSD приняты изменения, необходимые для работы потребительскогих инфракрасных портов (CIR, Consumer IR) на системах с ARM-процессорами Allwinner. Драйвер основан на фреймворке evdev, пока может работать только на приём и протестирован на платах Cubieboard2 (A20 SoC), используя пакет lirc и инфракрасный пульт управления от проекта dfrobot;
    • Продолжена работа по усовершенствованию поддержки 64-разрядной архитектуры ARM64 (AARCH64). Добавлена поддержка Raspberry Pi 3, но WiFi и Bluetooth пока не работают из-за неготовности кода для шины SDIO. Добавлена поддержка доступа ядра к регистрам операций с плавающей запятой (FPR, Floating-point register), использующая аналогичный с архитектурами i386 и amd64 программный интерфейс ядра (KPI). На системах ARMv8 также удалось реализовать поддержку инструкций AES, позволивших заметно поднять производительность операций AES на платах ThunderX. При манипуляции блоками памяти задействованы оптимизированные для процессоров Cortex варианты функций memcpy и memmove. Реализована возможность загрузки на системе SoftIron Overdrive 3000, используя ACPI;
  • Приложения и система портов
    • В дереве портов по умолчанию задействован набор компиляторов GCC 4.9, который теперь представлен как lang/gcc и используется при указании флага «USE_GCC=yes» (ранее применялся GCC 4.8). Порт lang/gcc49 обновлён до версии GCC 4.9.4, а порт lang/gcc6 до версии GCC 6.3. В качестве планов на будущее отмечен перевод lang/gcc и USE_GCC=yes на ветку GCC 5 и обеспечение поддержки архитектуры AArch64;
    • Дерево портов FreeBSD преодолело рубеж в 27000 портов (на 700 портов больше, чем в прошлом отчёте), число незакрытых PR держится на отметке в 2250. За отчётный период внесено 6871 изменений от 176 разработчиков. Права коммиттера получили три новых участника — Nikolai Lifanov (lifanov), Jason Bacon и Mikhail Pchelin (misha), отказался от прав Edwin Groothuis (edwin), лишился прав из-за неактивности в течение 19 месяцев — John-Mark Gurney (jmg).

      Добавлены два новых USES-набора: lxqt и varnish. Обновлены версии портов, предлагаемые по умолчанию: varnish 4, GCC 4.9, Perl 5.24 и Python 3.5. Прекращена поддержка портов с версиями Perl 5.18 и Linux Fedora 10 (по умолчанию сейчас Linux CentOS 6). Обновлены версии pkg 1.9.4, Firefox 50.1.0, Firefox-esr 45.6.0, Chromium 54.0.2840.100, Ruby 2.1.10 / 2.2.6 / 2.3.3, node.js 7 (ветка node.js 6 отделена как LTS). Для FreeBSD 11 налажена сборка пакетов для архитектур mips, mips64 и armv6;

    • Продолжается развитие компонентов графического стека. Из ядра Linux 4.9 в веку drm-next портированы свежие DRM-драйверы i915 и amdgpu. Доведён до частично работоспособного вида KMS-драйвер amdgpu, в котором ещё остаётся несколько известных существенных проблем. Добавлена поддержка GPU AMD, начиная Southern Islands и заканчивая Polaris. В драйвере Intel обеспечена поддержка чипов Kaby Lake. Создана ветка xserver-mesa-next-udev, в которой развивается порт с Mesa 13.0, также включающий исправления для новых GPU AMD. Ветка примечательна использованием прослойки libudev-devd для формирования для Mesa окружения, близкого к Linux;
    • Отмечен прогресс в разработке порта с пользовательским окружением LXQt, развиваемым объединённой командой разработчиков проектов LXDE, Razor-qt и Maui/Hawaii. В порты импортированы средства разработки devel/lxqt-build-tools, devel/liblxqt, devel/qtxdg и x11/libfm-qt, а также развиваемые проектом LXQt просмотрщик фотографий (graphics/lximage-qt) и файловый менеджер (x11-fm/pcmanfm-qt). Обновлены порты x11/qterminal 0.7.1 и x11-toolkits/qtermwidget 0.7.1;
    • Обновлены порты, связанные с проектом Mono: Mono 4.6.2.7, MonoDevelop 6.1.1.15, 6.1.2.44 и FSharp 4.0.1.20. Флаг «USES=mono» расширен для упрощения использования пакетов Nuget, применяемых в FSharp, MonoDevelop и OpenRA. Началось портирование кодовой базы .NET Core;
    • Порт emulators/wine адап адаптирован для использования Xinerama и GNUTLS (требуется для таких приложений, как Evernote и World of Warcraft). В рамках порта emulators/wine-devel доступна ветка Wine 2.0. Из открытых задач называется портирование WoW64;
    • Обновлены порты, связанные с десктоп-окружением Xfce:
            audio/xfce4-mpc-plugin 0.5.0      deskutils/xfce4-notifyd 0.3.4      graphics/ristretto 0.8.1      sysutils/xfce4-diskperf-plugin 2.6.0      sysutils/xfce4-battery-plugin 1.1.0      sysutils/xfce4-fsguard-plugin 1.1.0      sysutils/xfce4-netload-plugin 1.3.0       sysutils/xfce4-systemload-plugin 1.2.0      sysutils/xfce4-wavelan-plugin 0.6.0      x11/xfce4-clipman-plugin 1.4.1      x11/xfce4-conf 4.12.1      x11/xfce4-dashboard 0.6.1      x11/xfce4-terminal 0.8.2      x11/xfce4-whiskermenu-plugin 1.6.2      x11-clocks/xfce4-datetime-plugin 0.7.0      x11-wm/xfce4-panel 4.12.1      www/xfce4-smartbookmark-plugin 0.5.0       sysutils/xfce4-settings 4.13.0      x11/libexo 0.11.2      x11/xfce4-whiskermenu-plugin 2.0.3  
    • Из соображений политкорректности удалён порт misc/jive с реализацией фильтра для преобразования текста на английском языке в пародию на афроамериканский сленг;
    • Порт devel/gdb обновлён до GDB 7.12. В основную кодовую базу GDB, на основе которой подготовлен релиз GDB 7.12, включены подготовленные разработчиками FreeBSD исправления для поддержи точек останова (catchpoints) для системных вызовов. В GDB 7.12 также включены дополнительные улучшения для трассировки vfork(). Для включения в будущие выпуски GDB переданы патчи с реализацией поддержки ядра FreeBSD/mips и возможностью отладки исполняемых файлов для архитектутры mips.

Источник: [ссылка]

Ошибка в реализации криптовалюты Zcoin позволяла повторно тратить средства

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

Отмечается, что проблема не затрагивает протокол Zerocoin и лежащие в основе криптовалюты криптографические методы, а связана только с программной ошибкой, из-за которой в коде не верно выполнялась проверка транзакций. Суть ошибки была в том, что константа MAX_SPEND_ZC_TX_PER_BLOCK, определяющая максимальное число расходных транзакций для блока была выставлена в значение «1», в то время как при сравнении со счётчиком применялось условие «if (COUNT_SPEND_ZC_TX >= MAX_SPEND_ZC_TX_PER_BLOCK) {«, что подразумевало возможность проведения двух транзакций при значении счётчика 0 и 1.

Примечательно, что ошибкой успели воспользоваться мошенники, которым удалось создать примерно 370 тысяч Zcoin (около 500 тысяч долларов, что примерно 30% от общей капитализации данной криптовалюты), которые почти полностью были проданы на бирже. Ошибка также никак не влияет на анонимность Zerocoin, в том числе личности мошенников так и остались невыясненными. После обнаружения проблемы уровень капитализации Zcoin снизился с 2.6 млн долларов до 1.6 млн. Поиск на GitHub показывает, что данная проблема остаётся неисправленной как минимум ещё в трёх криптовалютах — zoin, nxcoin и kurrent.

Источник: [ссылка]