Facebook протестировал новый алгоритм контроля перегрузки COPA в сравнении с BBR и CUBIC

Facebook опубликовал результаты экспериментов с новым алгоритмом контроля перегрузки (congestion control) — COPA, оптимизированным для передачи видеоконтента. Алгоритм предложен исследователями из Массачусетского технологического института. Предложенный для тестирования прототип COPA написан на С++, открыт под лицензий MIT и включён в состав mvfst, развиваемой в Facebook реализации протокола QUIC.

Алгоритм COPA ориентирован на решение проблем, возникающих при передаче видео по сети. В зависимости от типа видео к алгоритмам контроля перегрузки предъявляются практически противоположные требования — для интерактивного видео требуется обеспечить минимальные задержки, даже в ущерб качества, а при трансляции заранее подготовленного высококачественного видео приоритет отдаётся сохранению качества. Ранее разработчики приложений были ограничены возможностью применять разные алгоритмы, в зависимости от требованиям к качеству или задержкам. Исследователи, разработавшие COPA, попытались создать универсальный алгоритм для управления перегрузкой TCP при передаче видео, который может настраиваться в зависимости от требований, предъявляемым к видео.

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

Для предотвращения перегрузки канала связи в COPA применяется моделирование характеристик канала на основе анализа изменения задержек при доставке пакетов (COPA уменьшает размер окна перегрузки при увеличении задержек, манипулируя тем, что задержки начинают увеличиваться ещё на стадии до возникновения потери пакетов). Баланс между задержками и пропускной способностью регулируются при помощи специального параметра delta. Увеличение delta приводит к повышению чувствительности к задержкам, но снижает пропускную способность, а уменьшение позволяет добиться более высокой пропускной способности за счёт увеличения задержек. Значение delta=0.04 определено как оптимальный баланс между качеством и задержками.

На базе сервиса потокового вещания Facebook Live было организовано тестирование COPA в сравнении с популярными алгоритмами CUBIC и BBR. Алгоритм CUBIC по умолчанию применяется в Linux и сводится к постепенному увеличению размера окна перегрузки до появления потери пакетов, после чего размер окна откатывается на значение до начала потери.

CUBIC оставляет желать лучшего при промежуточной буферизации пакетов на современном сетевом оборудовании, которая затормаживает отбрасывание пакетов. Алгоритм контроля перегрузки не знает о буферизации и продолжает наращивать скорость, даже если канал физически уже перегружен. Неотправленные пакеты буферизируются, а не отбрасываются, и алгоритм контроля перегрузки TCP срабатывает только после заполнения буфера и не может подобрать нужный баланс скорости потока, соотносящийся со скоростью физического линка. Для решения этой проблемы компания Google предложила улучшенный алгоритм BBR, который прогнозирует имеющуюся пропускную способность через последовательные проверки и оценку времени приема-передачи (RTT).

При delta=0.04 показатели COPA оказались близки к CUBIC и BBR. В тестах, проведённых в условиях высокоскоростного сетевого соединения с низкими задержками передачи пакетов, COPA позволил добиться снижения задержек (479 ms) по сравнению с CUBIC (499 ms), но немного отстал от BBR (462 ms). При снижении качества связи COPA показал наилучшие результаты — задержки оказались на 27% ниже, чем при использовании CUBIC и BBR.

При этом на плохом канале связи COPA и BBR позволили добиться существенно более высокой пропускной способности, по сравнению с CUBIC. Выигрыш BBR по сравнению с CUBIC составил — 4.8% и 5.5%, а COPA — 6.2% и 16.3%.

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

Опубликована 54 редакция списка самых высокопроизводительных суперкомпьютеров

Опубликован 54-й выпуск рейтинга 500 самых высокопроизводительных компьютеров мира. В новом выпуске десятка лидеров не изменилась. На первом месте в рейтинге кластер Summit развёрнут компанией IBM в Национальной лаборатории Оук-Ридж (США). Кластер работает под управлением Red Hat Enterprise Linux, включает 2.4 млн процессорных ядер (используются 22-ядерные CPU IBM Power9 22C 3.07GHz и ускорители NVIDIA Tesla V100), которые обеспечивают производительность 148 петафлопс.

Второе место занимает американский кластер Sierra, установленный в Ливерморской национальной лаборатории компанией IBM на базе аналогичной с Summit платформы и демонстрирующий производительность на уровне 94 петафлопс (около 1.5 млн ядер).

На третьем месте китайский кластер Sunway TaihuLight, работающий в национальном суперкомпьютерном центре Китая, включающий более 10 млн вычислительных ядер и показывающий производительность 93 петафлопс. Несмотря на близкие показатели производительности кластер Sierra потребляет в два раза меньше энергии, чем Sunway TaihuLight.

На четвёртом месте китайский кластер Tianhe-2A, который включает почти 5 млн ядер и демонстрирует производительность в 61 петафлопс.

Пятое место в рейтинге занимает кластер Frontera, произведённый компанией Dell для Техасского компьютерного центра. Кластер работает под управлением CentOS Linux 7 и включает более 448 тысяч ядер на базе Xeon Platinum 8280 28C 2.7GHz. Суммарный размер оперативной памяти составляет 1.5 ПБ, а производительность достигает 23 петафлопс, что в 6 раз меньше лидера рейтинга.

Наиболее интересные тенденции:

  • 29 место в рейтинге занял новый российский кластер SberCloud, запущенный Сбербанком. Кластер построен на платформе NVIDIA DGX-2, использует CPU Xeon Platinum 8168 24C 2.7GHz и насчитывает 99600 вычислительных ядер. Производительность SberCloud составляет 6.6 петафлопс. В качестве операционной системы используется Ubuntu 18.04.01.

    Второй отечественный кластер Lomonosov 2 за 6 месяцев сместился с 93 на 107 место в рейтинге. Кластер в Росгидромете опустился с 365 на 465 место. Число отечественных кластеров в рейтинге за шесть месяцев увеличилось с 2 до 3 (в 2017 году было 5 отечественных систем, а в 2012 году — 12);

  • Распределение по количеству суперкомпьютеров в разных странах:
    • Китай: 228 (219 — шесть месяцев назад). В сумме китайские кластеры генерируют 31.9% от всей производительности (полгода назад — 29.9%);
    • США: 117 (116). Суммарная производительность оценивается в 37.8% (подгода назад — 38.4%);
    • Япония: 29 (29);
    • Франция: 18 (19);
    • Германия: 16 (14);
    • Нидерланды: 15 (13);
    • Ирландия: 14 (13);
    • Великобритания: 11 (18);
    • Канада 9 (8);
    • Италия: 5 (5);
    • Сингапур 4 (5);
    • Австралия, Южная Корея, Саудовская Аравия, Бразилия, Россия: 3;
  • В рейтинге операционных систем, используемых в суперкомпьютерах, уже два с половиной года остаётся только Linux;
  • Распределение по дистрибутивам Linux (в скобках — 6 месяцев назад):
    • 49.6% (48.8%) не детализируют дистрибутив,
    • 26.4% (27.8%) используют CentOS,
    • 6.8% (7.6%) — Cray Linux,
    • 4.8% (4.8%) — RHEL,
    • 3% (3%) — SUSE,
    • 2% (1.6%) — Ubuntu;
    • 0.4% (0.4%) — Scientific Linux
  • Минимальный порог производительности для вхождения в Top500 за 6 месяцев вырос с 1022 до 1142 терафлопсов (в прошлом году лишь 272 кластера показывали производительность более петафлопса, два года назад — 138, три года назад — 94). Для Top100 порог вхождения вырос с 2395 до 2570 терафлопсов;
  • Суммарная производительность всех систем в рейтинге за год возросла с 1.559 до 1.650 экзафлопсов (три года назад был 566 петафлопс). Система, замыкающая нынешний рейтинг, в прошлом выпуске находилась на 397 месте, а в позапрошлом на 311;
  • Общее распределение по количеству суперкомпьютеров в разных частях света выглядит следующим образом: 274 суперкомпьютер находится в Азии (267 — полгода назад), 129 в Америке (127) и 94 в Европе (98), 3 в Океании;
  • В качестве процессорной основы лидируют CPU Intel — 94% (полгода назад было 95.6%), на втором месте — IBM Power — 2.8% (было 2.6%), на третьем AMD — 0.6% (0.4%), на четвёртом SPARC64 — 0.6% (0.8%);
  • 35.6% (полгода назад 33.2%) всех используемых процессоров имеют 20 ядер, 13.8% (16.8% ) — 16 ядер, 11.2% (11.2%) — 12 ядер, 11% (11.2%) — 18 ядер, 7.8% (7%) — 14 ядер;
  • 144 из 500 систем (полгода назад — 133) дополнительно используют ускорители или сопроцессоры, при этом в 135 системах задействованы чипы NVIDIA (полгода назад было 125), в 5 — Intel Xeon Phi (было 5), 1 — PEZY (1), в 1 используются гибридные решения (было 1), в 1 — Matrix-2000 (1), в 1 GPU AMD Vega (полгода назад ускорители AMD не использовались);
  • Среди производителей кластеров на первом месте закрепилась компания Lenovo — 34.8% (год назад 34.6%), на второе место вырвалась компания Sugon 14.2% (12.6%), Inspur отпустился на третье место — 13.2% (14.2%), четвёртое место занимают Hewlett-Packard — 7% (8%) и 7% (7.8%), далее следуют Atos — 4.6%, IBM 2.6 (2.4%), Fujitsu 2.6% (2.6%), Penguin Computing — 2.2% (1.8%), Dell EMC 2.2% (3%), Huawei 2% (1.4%), NVIDIA 1.2%. Пять лет назад распределение среди производителей выглядело следующим образом: Hewlett-Packard 36%, IBM 35%, Cray 10.2% и SGI 3.8%;
  • Для связи узлов в 52% кластеров используется Ethernet, InfiniBand применяется на 28% кластеров, Omnipath — 10%. Если рассматривать суммарную производительность, то системы на базе InfiniBand охватывают 40% всей производительности Top500, а Ethernet — 29%.

Одновременно доступен новый выпуск альтернативного рейтинга кластерных систем Graph 500, ориентированного на оценку производительности суперкомпьютерных платформ, связанных с симулированием физических процессов и задач по обработке больших массивов данных, свойственных для таких систем. Рейтинг Green500 отдельно больше не выпускается и объединён с Top500, так как обеспечение энергоэффективности теперь отражается в основном рейтинге Top500 (учитывается отношение LINPACK FLOPS к потребляемой мощности в ваттах).

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

Выпуск сетевого стека F-Stack 1.13, выполняемого в пространстве пользователя

После полутора лет разработки состоялся выпуск проекта F-Stack 1.13, развивающего работающий в пространстве пользователя высокопроизводительный сетевой стек, основанный на фреймворке DPDK и TCP/IP стеке FreeBSD (F-Stack не привязан к FreeBSD и в качестве первичной платформы для применения рассматривает Linux). Проект используется в различных продуктах и сервисах Tencent, крупнейшей в Китае телекоммуникационной компании. Код распространяется под лицензией BSD. Поддерживается работа в Linux и FreeBSD.

F-Stack даёт возможность организовать сетевое взаимодействие в приложениях, применяя вместо сетевого стека операционной системы собственный сетевой стек, функционирующий в пространстве пользователя и напрямую работающий с сетевым оборудованием. Предоставляются специализированные редакции Nginx и Redis, переведённые на использование F-Stack.

Для разработки приложений поддерживается как штатный Posix API (Socket, Epoll, Kqueue), упрощающий перевод на F-Stack существующих приложений, так и собственный программный интерфейс на основе сопрограмм (микропотоков), упрощающий создание сетевых приложений и позволяющий обойтись без сложной логики асинхронной обработки запросов. F-Stack также предоставляет средства для упрощения применения в приложениях с многопроцессной архитектурой.

Для взаимодействия с сетевой картой минуя интерфейсы ядра операционной системы применяется фреймворк DPDK (Data Plane Development Kit), предоставляющий набор библиотек для низкоуровневой работы с сетевыми адаптерами, взаимодействия в многоядерных системах, задействования кольцевых буферов и больших страниц памяти («huge page»). Применение DPDK даёт возможность принимать и отправлять сетевые пакеты с выполнением минимального числа циклов CPU (около 80 циклов на пакет) и разрабатывать высокопроизводительные компоненты сетевого стека. Непосредственно функциональность TCP/IP стека заимствована из FreeBSD 11.1 и выделена в независимую от операционной системы библиотеку.

F-Stack позиционируется как решение, которое можно применять для повышения производительности обработчиков сетевых запросов, в условиях, когда работа штатный TCP/IP стек ядра Linux становится узким местом и ограничивает масштабирование. При этом применение F-Stack даёт достаточно ощутимую оптимизацию и позволяет в некоторых ситуациях увеличить число обрабатываемых мелких запросов в разы.

Увеличение производительности достигается за счёт исключения таких операций, как копирования сетевых пакетов, планирование потоков, обработка прерываний и применение системных вызовов. F-Stack позволяет достигнуть потолка сетевой производительности, возможного для используемой сетевой карты. Например, решения на базе F-Stack продемонстрировали возможность обработки 10 млн параллельных соединений, 5 млн запросов в секунду и 1 млн соединений в секунду.

В новом выпуске:

  • Добавлена поддержка VLAN;
  • Обеспечена возможность работы в изолированных контейнерах на базе Doker;
  • Реализованы интерфейсы ff_dup, ff_dup2, ff_ioctl_freebsd, ff_getsockopt_freebsd и ff_setsockopt_freebsd;
  • Добавлен параметр «idle_sleep» для сокращения нагрузки на CPU в ситуации отсутствия входящих пакетов
  • Добавлена поддержка сборки для архитектуры ARM64.
  • В переведённой на F-Stack редакции Nginx заменены обработчики getpeername, getsockname и shutdown.
  • Осуществлён переход на новую версию DPDK 17.11.4 LTS;
  • В состав добавлена утилита traffic для отображения текущего трафика, обрабатываемого приложениями на базе F-Stack (напоминает trafshow).

Из планов на будущее отмечается поддержка IPv6, предоставление API для зыков Python, PHP и Go, поддержка API Cyptodev (Intel QAT), использование zerocopy при отправке пакетов, поддержка SPDK и возможность запуска в форме фонового процесса.

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

Доступна стандартная Си-библиотека PicoLibc 1.1

Кит Паккард (Keith Packard), активный разработчик Debian, лидер проекта X.Org и создатель множества X-расширений, включая XRender, XComposite и XRandR, представил выпуск новой стандартной Си-библиотеки PicoLibc 1.1, развиваемой для применения на встраиваемых устройствах с ограниченным размером постоянного хранилища и оперативной памяти. При разработке часть кода заимствована из библиотеки newlib от проекта Сygwin и AVR Libc, развивавшейся для микроконтроллеров Atmel AVR. Код PicoLibc распространяется под лицензией BSD. Поддерживается сборка библиотеки для архитектур ARM (32-bit), i386, RISC-V, x86_64 и PowerPC.

Кит Паккард приступил к разработке после того, как не смог найти достойного варианта Libc, который можно было использовать на встраиваемых устройствах с небольшим ОЗУ. Проект развивается с прошлого года. На первом этапе проект представлял собой вариант newlib, функции stdio в котором были заменены на компактный вариант из avrlibc (stdio в newlib не устраивал большим потреблением ресурсов). Так как текущая деятельность Кита связана с постоянной работой с архитектурой RISC-V и развитием инструментария для встраиваемых устройств, недавно он пересмотрел состояние реализаций libc и пришёл к выводу, что при небольшой доработке комбинация newlib и avrlibc может стать хорошим универсальным решением. Изначально проект развивался под именем «newlib-nano», но чтобы избежать путаницы с библиотекой Newlib был переименован в PicoLibc.

В текущем виде в Picolibc уже проведена работа по удалению всего кода, поставляемого не под лицензией BSD (данный код не использовался при сборке для встраиваемых устройств), что значительно упростило ситуацию с лицензией на проект. Реализация локальных потоков переведена с ‘struct _reent’ на механизм TLS (thread-local storage). Активирован по умолчанию компактный вариант stdio, заимствованный из кода библиотеки avrlibc (специфичные для ATmel ассемблерные вставки переписаны на Си). Для сборки задействован инструментарий Meson, что позволило не привязываться к сборочным сценариям newlib и упростить перенос изменений из newlib. Добавлен упрощённый вариант кода инициализации (crt0), прикрепляемого к исполняемому файлу и выполняемого до передачи управления функции main().

В версии Picolibc 1.1:

  • Добавлена вспомогательная библиотека для поддержки технологии «semihosting«, позволяющей коду, выполняемому в окружении отладчика или эмулятора, использовать механизмы ввода/вывода хост-системы;
  • Для систем, поддерживающих системные вызовы open, close, read и write, в tinystdio добавлены стандартизированные POSIX-интерфейсы ввода/вывода stdio, включая функции fopen и fdopen, а также привязку stdin/stdout/stderr к определённым в POSIX файловым дескрипторам;
  • Перенесены недавние изменения из кодовой базы newlib. В том числе добавлены заглушки libm для fenv.h, которые можно использовать на системах без поддержи вычислений с плавающей точкой;
  • Добавлен пример сборки приложения «Hello world» с picolibc для систем ARM и RISC-V;
  • Удалены каталоги newlib, libm и mathfp, в которых содержался неиспользуемый экспериментальный код.

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

Верховный суд согласился возобновить связанное с Java и Android разбирательство между Google и Oracle

Верховный суд США удовлетворил ходатайство компании Google о переводе рассмотрения тянущегося с 2010 года судебного разбирательсва «Oracle против Google» в высшую инстанцию. В прошлом году Федеральный апелляционный суд США удовлетворил апелляцию компании Oracle и пересмотрел вынесенное в пользу Google решение 2016 года, связанное с использованием Java API в платформе Android. В ответ на прошение Google Верховный суд США согласился изучить материалы дела и вернуться к рассмотрению вопроса о принадлежности программных интерфейсов (API) к интеллектуальной собственности.

Напомним, что в 2012 году судья, имеющий опыт программирования, согласился с позицией Google и признал, что формирующее API дерево имён является частью структуры команд — набора символов, связанного с определённой функцией. Подобный набор команд трактуется законом об авторском праве как не подпадающий под действие копирайта, так как дублирование структуры команд является непременным условием обеспечения совместимости и переносимости. Поэтому идентичность строк с декларациями и заголовочными описаниями методов не имеет значения — для реализации аналогичной функциональности формирующие API имена функций должны совпадать, даже если сама функциональность реализована по-другому. Так как существует только один способ выражения идеи или функции, то каждый волен использовать идентичные декларации и никто не может монополизировать такие выражения.

Компания Oracle подала апелляцию и добилась в Федеральном апелляционном суде США отмены решения — апелляционный суд признал, что Java API является интеллектуальной собственностью Oracle. После этого компания Google сменила тактику и попыталась доказать, что реализация Java API в платформе Android носит характер добросовестного использования, и данная попытка увенчалась успехом. Позиция Google сводилась к тому, что создание переносимого программного обеспечения не требует получения лицензии на API, а повторение API для создания совместимых функциональных аналогов относится к «добросовестному использованию». По мнению Google, отнесение API к категории интеллектуальной собственности негативно скажется на индустрии, так как подрывает развитие инноваций, а создание совместимых функциональных аналогов программных платформ может стать объектом судебных исков.

Компания Oracle второй раз подала апелляцию и опять дело было пересмотрено в её пользу. Суд постановил, что принцип «добросовестного использования» не применим к Android, так как данная платформа развивается компанией Google с корыстными целями, реализуемыми не через прямую продажу программного продукта, а через контроль над сопутствующими сервисами и рекламой. При этом Google удерживает контроль над пользователями через проприетарный API для взаимодействия со своими сервисами, который запрещено использовать для создания функциональных аналогов, т.е. использование Java API не ограничивается некоммерческим применением.

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

GitHub запустил совместный проект для выявления уязвимостей в открытом ПО

GitHub выступил с инициативой GitHub Security Lab, нацеленной на организацию совместной работы экспертов по безопасности из различных компаний и организаций для выявления уязвимостей и содействию по их устранению в коде открытых проектов.

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

К инициативе уже присоединились исследователи безопасности из компаний F5, Google, HackerOne, Intel, IOActive, J.P. Morgan, LinkedIn, Microsoft, Mozilla, NCC Group, Oracle, Trail of Bits, Uber и VMWare, которые за последние два года выявили и помогли исправить 105 уязвимостей в таких проектах, как Chromium, libssh2, ядре Linux, Memcached, UBoot, VLC, Apport, HHVM, Exiv2, FFmpeg, Fizz, libav, Ansible, npm, XNU, Ghostscript, Icecast, Apache Struts, strongSwan, Apache Ignite, rsyslog, Apache Geode и Hadoop.

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

Через интерфейс GitHub теперь можно получить CVE-идентификатор для выявленной проблемы и подготовить отчёт, а GitHub уже сам разошлёт необходимые уведомления и организует их скоординированное исправление. Более того, после устранения проблемы GitHub автоматически отправит pull-запросы для обновления связанных с уязвимым проектом зависимостей.

GitHub также ввёл в стой каталог уязвимостей GitHub Advisory Database, в котором публикуются сведения о уязвимостях, затрагивающих проекты на GitHub, и информация для отслеживания подверженных проблемам пакетов и репозиториев. Упоминаемые в комментариях на GitHub CVE-идентификаторы автоматически теперь ссылаются на детальную информацию об уязвимости в представленной БД. Для автоматизации работы с БД предложен отдельный API.

Также сообщается об обновлении сервиса для защиты от попадания в публично доступные репозитории конфиденциальных данных, таких как токены аутентификации и ключи доступа. Во время коммита сканер проверяет типовые форматы ключей и токенов, используемые 20 облачными провадерами и сервисами, включая API Alibaba Cloud, Amazon Web Services (AWS), Azure, Google Cloud, Slack и Stripe. В случае выявления токена сервис-провайдеру направляется запрос для подтверждения утечки и отзыва скомпрометированных токенов. Со вчерашнего дня, помимо ранее поддерживаемых форматов, добавлена поддержка определения токенов GoCardless, HashiCorp, Postman и Tencent.

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

Выпуск Firefox Lite 2.0, компактного браузера для Android

Опубликован выпуск web-браузера Firefox Lite 2.0, который позиционируется как легковесный вариант Firefox Focus, адаптированный для работы на системах с ограниченными ресурсами и на низкоскоростных каналах связи. Проект развивается командой разработчиков Mozilla из Тайваня и нацелен прежде всего на поставку в Индии, Индонезии, Тайланде, Филиппинах, Китае и развивающихся странах.

Ключевым отличием Firefox Lite от Firefox Focus является использование встроенного в Android движка WebView вместо Gecko, что позволяет уменьшить размер APK-пакета с 38 до 4.9 МБ, а также даёт возможность использовать браузер на маломощных смартфонах на базе платформы Android Go. Как и в Firefox Focus в Firefox Lite встроен блокировщик нежелательного контента, вырезающий рекламу, виджеты социальных сетей и внешний JavaScript-код для отслеживания перемещений. Применение блокировщика позволяет существенно уменьшить размер загружаемых данных и сократить время загрузки страниц в среднем на 20%.

Firefox Lite поддерживает такие возможности как закладки на избранные сайты, просмотр истории посещений, вкладки для одновременной работы с несколькими страницами, менеджер загрузок, быстрый поиск текста на страницах, режим приватного просмотра (не сохраняются Cookie, история и данные в кеше). Среди расширенных возможностей:

  • Режим Turbo для ускорения загрузки за счёт вырезания рекламы и стороннего контента (включён по умолчанию);
  • Режим блокировки изображений (показ только текста);
  • Кнопка очистки кэша для увеличения свободной памяти;
  • Возможность создания скриншота всей страницы, а не только видимой части;
  • Поддержка изменения цветовой гаммы интерфейса.

В новой версии полностью переработано оформление браузера. На стартовой странице число закреплённых ссылок на сайты увеличено с 8 до 15 (пиктограммы разделены на два экрана, переключаемых скользящим жестом). Ссылки могут добавляться и удаляться по усмотрению пользователя. В центральной части стартовой страницы отдельно выделены две секции, при переходе в которые отображается подборка новостей и игр.

В нижнюю часть стартовой страницы, рядом со строкой поиска появилась кнопка «шопинг», при нажатии которой выводится специализированный интерфейс для поиска товаров и сравнения цен в разных интернет-магазиновнах, без захода на их сайты. Поддерживается поиск товаров в Google, Amazon, eBay и Aliexpress. Возможно получение купонов на скидки непосредственно через браузер, но данная возможность пока ограничена только для пользователей из Индии и Индонезии.

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

Доступен Mozilla WebThings Gateway 0.10, шлюз для умного дома и IoT-устройств

Компания Mozilla опубликовала новый выпуск продукта WebThings Gateway 0.10, который в сочетании с библиотеками WebThings Framework образует платформу WebThings для обеспечения доступа к различным категориям потребительских устройств и использования универсального Web Things API для организации взаимодействия с ними. Код проекта написан на языке JavaScript с использованием серверной платформы Node.js и распространяется под лицензией MPL 2.0. Прошивки с шлюзом подготовлены для различных моделей Raspberry Pi. Также доступны пакеты для OpenWrt и Debian, а на базе OpenWrt развивается готовый дистрибутив с интегрированной поддержкой Things Gateway, предоставляющий унифицированный интерфейс для настройки умного дома и беспроводной точки доступа.

В новом выпуске:

  • Добавлена поддержка умных термостатов, используемых для регулирования температуры в помещении. Поддерживаются такие модели, как Zigbee Zen Thermostat, Centralite HA 3156105 и Z-Wave Honeywell TH8320ZW1000. Через предоставляемый платформой web-интерфейс можно удалённо наблюдать за температурой в доме, выставлять режимы обогрева или охлаждения, менять целевую температуру. Также можно создаваться правила, реагирующие на изменение температуры, например, включающие обогревательный прибор или кондиционер при достижении определённых температурных границ или в привязке ко времени суток;
  • Добавлена возможность управления умными замками, поддерживающими протокол Zigbee или Z-Wave, такими как Yale YRD226 Deadbolt и Yale YRD110 Deadbolt. Находясь вне дома пользователь может удостовериться, что не забыл закрыть дверь, и при необходимости открыть или закрыть замок удалённо. Через задание правил можно автоматизировать запирание двери в определённое время или отправлять уведомление, если замок остался открытым;
  • Добавлен новый тип дополнений, позволяющих расширять возможности пользовательского интерфейса. Например, при помощи дополнений можно добавить новые секции на основное меню или реализовать новые экраны с дополнительной функциональностью. Для создания дополнений предложен новый формат файла-манифеста, созданный по аналогии с манифестами браузерных дополнений на базе технологии WebExtensions;
  • Добавлен новый раздел настроек, посвящённый локализации. Пользователь теперь может выбрать страну, часовой пояс и язык в основном web-интерфейсе, и данные настройки будут учтены во всех используемых дополнениях и правилах при обработке зависимых от местоположения данных, таких как сведения о погоде, рассвете/закате и приливах/отливах. Например, в привязанных ко времени правилах будет учитываться перевод часов на летнее или зимнее время, а в интерфейсе температура выводиться в привычных единицах изменения;
  • Добавлена возможность обращения ко всем Web API платформы через одно WebSocket-соединение (ранее требовалось открытие отдельного соединения для каждого устройства). В консорциуме W3C создана рабочая группа Web Thing Protocol Community Group, которая займётся стандартизацией протокола на базе WebSocket для взаимодействия с устройствами Web of Things;
  • В следующем выпуске ожидается интеграция поддержки голосового управления с использованием устройств Mycroft и реализация новых методов установки.

Напомним, что WebThings Gateway представляет собой универсальную прослойку для организации доступа к различным категориям потребительских и IoT-устройств, скрывающую за собой особенности каждой платформы и не требующую использования специфичных для каждого производителя приложений. Для взаимодействия шлюза с IoT-платформами можно использовать протоколы ZigBee и ZWave, WiFi или прямое подключение через GPIO. Шлюз можно установить на плату Raspberry Pi и получить систему управления умным домом, объединяющую все имеющиеся в доме IoT-устройства и предоставляющую средства для мониторинга и управления ими через Web-интерфейс.

Платформа также позволяет создавать дополнительные web-приложения, которые могут взаимодействовать с устройствами через Web Thing API. Таким образом, вместо установки своего мобильного приложения для каждого типа IoT-устройств, можно использовать единый унифицированный web-интерфейс. Для установки WebThings Gateway достаточно загрузить предоставленную прошивку на SD-карту, открыть в браузере хост «gateway.local», настроить подключение к WiFi, ZigBee или ZWave, найти имеющиеся IoT-устройства, настроить параметры для доступа извне и добавить самые востребованные устройства на домашний экран.

Шлюз поддерживает такие функции, как определение устройств в локальной сети, выбор web-адреса для соединения с устройствами из интернета, создание учётных записей для доступа к web-интерфейсу шлюза, подключение к шлюзу устройств, поддерживающих проприетарные протоколы ZigBee и Z-Wave, удалённое включение и выключение устройств из web-приложения, удалённый мониторинг за состоянием дома и видеонаблюдение. Кроме web-интерфейса и API в шлюзе также реализована экспериментальная поддержка голосового управления, позволяющая распознавать и выполнять голосовые команды (например, «включи свет на кухне»).

WebThings Framework предоставляет набор заменяемых компонентов для создания IoT-устройств, которые могут напрямую взаимодействовать c использованием Web Things API. Подобные устройства могут автоматически определяться шлюзами на базе WebThings Gateway или клиентским ПО (используется mDNS) для последующего мониторинга и управления через Web. Реализации серверов для Web Things API подготовлены в форме библиотек на Python, Java, Rust, Arduino и MicroPython.

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

Уязвимость TPM-Fail, позволяющая восстановить ключи, хранимые в TPM-модулях

Группа исследователей из Вустерского политехнического института, Любекского университета и Калифорнийского университета в Сан-Диего разработала метод атаки по сторонним каналам, позволяющий восстановить значение закрытых ключей, хранимых в TPM (Trusted Platform Module). Атака получила кодовое имя TPM-Fail и затрагивает fTPM (программная реализация на базе прошивки, работающая на отдельном микропроцессоре внутри CPU) от компании Intel (CVE-2019-11090) и аппаратные TPM на чипах STMicroelectronics ST33 (CVE-2019-16863).

Исследователи опубликовали прототип инструментария для совершения атаки и продемонстрировали возможность восстановления 256-разрядного закрытого ключа, применяемого для формирования цифровых подписей с использованием алгоритмов на базе эллиптических кривых ECDSA и EC-Schnorr. В зависимости от прав доступа общее время атаки на системы Intel fTPM составляет 4-20 минут и требует анализа 1-15 тысяч операций. Для атаки на системы с чипом ST33 требуется около 80 минут и анализа около 40 тысяч операций по генерации цифровой подписи.

Исследователями также продемонстрирована возможность совершения удалённой атаки в высокоскоростных сетяx, позволившая в локальной сети с пропускной способностью 1GB в лабораторных условиях за пять часов восстановить закрытый ключ, после измерения времени ответа для 45 тысяч сеансов аутентификации с VPN-сервером на базе ПО strongSwan, хранящем свои ключи в подверженном уязвимости TPM.

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

Уязвимость устранена компанией STMicroelectronics в новой редакции чипов, в которых реализация алгоритма ECDSA была избавлена от корреляций со временем выполнения операций. Интересно, что подверженные проблеме чипы STMicroelectronics в том числе используются в оборудовании, соответствующем уровню безопасности CommonCriteria (CC) EAL 4+. Исследователями также были проверены TPM-чипы компаний Infineon и Nuvoton, но в них утечка на основе изменения времени вычислений отсутствует. В процессорах Intel проблема проявляется начиная с выпускаемого с 2013 года семейства Haswell. Отмечается, что проблеме подвержен широкий спектр ноутбуков, ПК и серверов, выпускаемых различными производителями, включая Dell, Lenovo и HP.

Компания Intel включила исправление в ноябрьское обновление прошивок, в котором помимо рассматриваемой проблемы устранено ещё 24 уязвимости, из которых девяти присвоен высокий уровень опасности, а одной критический. По указанным проблемам приводится лишь общая информация, например, упомянуто, что критическая уязвимость (CVE-2019-0169) обусловлена возможностью вызвать переполнение кучи на стороне окружений Intel CSME (Converged Security and Management Engine) и Intel TXE (Trusted Execution Engine), что позволяет злоумышленнику повысить свои привилегии и получить доступ к конфиденциальным данным.

Также можно отметить раскрытие результатов аудита различных SDK для разработки приложений, взаимодействующих с кодом, выполняемым на стороне изолированных анклавов. C целью выявления проблемных функций, которые могут применяться для совершения атак, были изучены восемь SDK: Intel SGX-SDK, SGX-LKL, Microsoft OpenEnclave, Graphene, Rust-EDP и Google Asylo для Intel SGX, Keystone для RISC-V и Sancus для Sancus TEE. В ходе аудита было выявлено 35 уязвимостей, на базе которых разработано несколько сценариев атак, позволяющих извлечь AES-ключи из анклава или организовать выполнение своего кода через создание условий для повреждения содержимого памяти.

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

Выпуск браузера Brave 1.0, развиваемого при участии создателя JavaScript

После четырёх с половиной лет разработки и тестирования представлен первый стабильный релиз web-браузера Brave, развиваемого под руководством Брендена Айка (Brendan Eich), создателя языка JavaScript и бывшего руководителя Mozilla. Браузер построен на базе движка Chromium и сосредоточен на оберегании приватности пользователей. Сборки подготовлены для Linux, Windows, macOS, Android и iOS. Код проекта доступен на GitHub, специфичные для Brave компоненты распространяются под свободной лицензией MPLv2.

В Brave встроен и активирован по умолчанию движок для вырезания рекламы, кода для отслеживания перемещения между сайтами, кнопок социальных сетей, блоков с автовоспроизводимым видео и вставок для майнинга. Движок фильтрации написан на языке Rust и использует алгоритмы, заимствованные из дополнений Block Origin и Ghostery.

По заявлению разработчиков чистка отображаемых страниц от рекламы и сторонних JavaScript-блоков позволяет в 3-6 раз ускорить загрузку страниц. В проведённых разработчиками тестах Brave в среднем позволил сократить время загрузки протестированных страниц на 27 секунд по сравнению с Chrome и на 22 секунды по сравнению с Firefox, при этом браузер Brave загрузил на 58% меньше данных и израсходовал на обработку страниц на 40% и 47% меньше памяти, чем Chrome и Firefox.

Для борьбы с косвенным отслеживанием пользователей в бразуере применяется блокировщик методов скрытой идентификации («browser fingerprinting»). В основной состав интегрировано дополнение HTTPS Everywhere, позволяющее на всех сайтах, где это возможно, использовать HTTPS. Имеется режим приватного просмотра, в котором трафик пробрасывается через сеть Tor. Браузер поддерживает механизм синхронизации между устройствами Brave Sync, предлагает на выбор тёмную и светлую темы оформления, совместим с дополнениями к Chrome, имеет встроенную поддержку IPFS и WebTorrent.

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

Перечисление пожертвований создателям контента организуется при помощи системы Brave Rewards. Пожертвования могут оформляться как месячная подписка или перечисляться в форме одноразовых премий за определённый интересный контент (для пожертвования в адресной строке отображается индикатор в форме красного треугольника). Для предотвращения мошенничества в программе могут участвовать только верифицированные сайты (поддерживается более 300 тысяч сайтов). Виджет Brave Rewards размещается на странице, показываемой при открытии новой вкладки.

Средства для пожертвований можно накопить благодаря встроенной в браузер рекламной платформе Brave Ads, позволяющая показывать рекламу без обращения к внешним сервисам. Для обеспечения приватности данные об открытых страницах не уходят за пределы системы пользователя и сохраняются локально. Использование Brave Rewards и Brave Ads опционально, включается по желанию пользователя (через меню Brave Rewards или URL brave://rewards) и настраивается (можно ограничить число показываемых в час рекламных блоков). Реклама показывается в форме отделённых от контента всплывающих уведомлений. В настоящее время показ рекламы возможен в 30 странах, среди которых пока нет стран постсоветского пространства.

Расчёты осуществляются в специально созданной криптовалюте BAT (Basic Attention Token), основанной на Ethereum и совмещающей в себе децентрализованную платформу для обмена рекламой. Предложенный подход даёт пользователю возможность полностью контролировать все браузерные данные, а предприятиям сохранить возможность размещения рекламы. Модель распределения средств подразумевает распределение между пользователями 70% дохода, полученного от рекламодателей. Средства от просмотра рекламы накапливаются в виде BAT-токенов в кошельке, привязанном к пользователю. Пользователь может обменять заработанные BAT на цифровые и реальные валюты или использовать для спонсирования сайтов.

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

Red Hat открыл код Quay, реестра для сборки и распространения образов контейнеров

Компания Red Hat объявила о формировании нового открытого проекта Quay, который продолжит развитие ранее разрабатываемого за закрытыми дверями одноимённого реестра образов контейнеров, лежащего в основе сервисов Red Hat Quay и Quay.io. Проект попал в руки Red Hat после покупки компании CoreOS и открыт в рамках инициативы по переводу в разряд СПО проприетарных продуктов поглощаемых компаний. Код написан на языке Python и открыт под лицензией Apache 2.0.

Проект предоставляет инструментарий для сборки, хранения и распространения образов контейнеров и приложений, а также web-интерфейс для управления реестром. При помощи Quay можно в подконтрольной инфраструктуре развернуть собственный реестр образов контейнеров или приложений, для запуска которого потребуется только доступ к СУБД и дисковое пространство для хранение образов.

Реестр совместим с первой и второй версиями протокола (Docker Registry HTTP API), используемого для распространения образов контейнеров для движка Docker, а также со спецификацией файлов манифеста Docker. Для обнаружения контейнеров поддерживается спецификация App Container Image Discovery. Возможно подключение к системам непрерывной доставки и интеграции (CD/CI) со сборкой из репозиториев на базе GitHub, Bitbucket, GitLab и Git.

Quay предоставляет гибкие механизмы разграничения доступа, средства управления командами разработчиков, допускает использование для аутентификации пользователей LDAP, Keystone, OIDC, Google Auth и GitHub. Хранилище может быть развёрнуто поверх локальной ФС, S3, GCS, Swift и Ceph, и реплицировано для оптимизации отдачи данных с учётом местоположения пользователя. В состав входит инструментарий Clair, обеспечивающий автоматизированное сканирование начинки контейнеров для выявления неисправленных уязвимостей.

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

Выявлен новый вариант атаки Zombieload на процессоры Intel

Исследователи из Грацского технического университета (Австрия) раскрыли сведения о новом методе атаки по сторонним каналам ZombieLoad 2.0 (CVE-2019-11135), позволяющем извлечь конфиденциальную информацию из других процессов, операционной системы, виртуальных машин и защищённых анклавов (TEE, Trusted Execution Environment). Проблема затрагивает только процессоры Intel. Компоненты для блокирования проблемы предложены во вчерашнем обновлении микрокода.

Проблема относится к классу MDS (Microarchitectural Data Sampling) и является модернизированным вариантом обнародованной в мае атаки ZombieLoad. ZombieLoad 2.0, как и другие атаки класса MDS, основываются на применении методов анализа по сторонним каналам к данным в микроархитектурных структурах (например, в буферах заполнения (Line Fill Buffer) и хранения (Store Buffer), в которых временно сохраняются данные, используемые в процессе выполнения операций Load и Store).

Новый вариант атаки Zombieload основывается на утечке, возникающей при работе механизма асинхронного прерывания операций (TAA, TSX Asynchronous Abort), реализованного в расширении TSX (Transactional Synchronization Extensions), предоставляющем средства для работы с транзакционной памятью, позволяющей повысить производительность многопоточных приложений за счёт динамического исключения лишних операций синхронизации (поддерживаются атомарные транзакции, которые могут быть либо приняты, либо прерваны). В случае прерывания, операции, выполненные с транзакционным регионом памяти, откатываются.

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

Атака сводится к открытию TSX транзакций и созданию условий для их асинхронного прерывания, во время которого возникают условия для утечки содержимого внутренних буферов, спекулятивно заполненных данными из выполняемых на том же ядре CPU операций чтения памяти. Утечка ограничена текущим физическим ядром CPU (тем же на котором выполняется код атакующего), но так как микроархитектурные буферы совместно используются разными потоками в режиме Hyper-Threading, возможно возникновение утечки операций с памятью, выполняемых в других потоках CPU.

Атаке подвержены некоторые модели восьмого, девятого и десятого поколений процессоров Intel Core, а также Intel Pentium Gold, Intel Celeron 5000, Intel Xeon E, Intel Xeon W и второе поколение Intel Xeon Scalable. В том числе атаке подвержены и новые процессоры Intel на базе представленной в апреле микроархитектуры Cascade Lake, изначально не подверженной атакам RIDL и Fallout. Кроме Zombieload 2.0 исследователи также выявили возможность обхода ранее предложенных методов защиты от MDS-атак, основанных на использовании инструкции VERW для очистки содержимого микроархитектурных буферов в момент возвращения из ядра в пространство пользователя или при передаче управления гостевой системе.

В отчёте Intel утверждается, что в системах с разнородной нагрузкой возможность проведения атаки затруднена, так как утечка из микроархитектурных структур охватывает всю активность в системе и атакующий не может влиять на источник извлекаемых данных, т.е. может лишь накапливать всплывающие в результате утечки сведения и пытаться выявить среди этих данных полезную информацию, без возможности целенаправленно перехватить данные, связанные с конкретными адресами памяти. Тем не менее, исследователями опубликован прототип эксплоита, работающий в Linux и Windows, а также продемонстрирована возможность применения атаки для определения хэша пароля пользователя root. Возможно проведение атаки из гостевой системы для накопления данных, которые фигурируют в операциях других гостевых систем, хост-окружения, гипервизора и анклавов Intel SGX.

Исправления для блокирования уязвимости включены в кодовую базу ядра Linux и вошли в состав выпусков 5.3.11, 4.19.84, 4.14.154, 4.9.201 и 4.4.201. Обновления с ядром и микрокодом также уже выпущены для основных дистрибутивов Linux (Debian, SUSE/openSUSE, Ubuntu, RHEL, Fedora). Проблема была выявлена в апреле и исправление было скоординировано Intel с разработчиками операционных систем.

Простейшим методом блокирования Zombieload 2.0 является отключение поддержки TSX в CPU. Предложенное для ядра Linux исправление включает несколько вариантов защиты. Первый вариант предлагает параметр «tsx=on/off/auto», позволяющий управлять включением расширения TSX в CPU (значение auto отключает TSX только для уязвимых CPU). Второй вариант защиты включается параметром «tsx_async_abort=off/full/full,nosmt» и основан на очистке микроархитектурных буферов, во время переключения контекста (флаг nosmt дополнительно отключает SMT/Hyper-Threads). Для проверки подверженности системы уязвимости в sysfs предусмотрен параметр «/sys/devices/system/cpu/vulnerabilities/tsx_async_abort».

Кроме того, в обновлении микрокода устранена ещё одна уязвимость (CVE-2018-12207) в процессорах Intel, которая также блокирована в свежем обновлении ядра Linux. Уязвимость позволяет непривилегированному атакующему инициировать отказ в обслуживании, приводящий к зависанию системы в состоянии «Machine Check Error». Атака в том числе может быть совершена из гостевой системы.

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