Перейти к содержимому
Local
bot

Блокировка DDoS на 10Mpps в Linux

Рекомендованные сообщения

Тестирование Linux на DROP сетевых пакетов. Разные методы и их эффективность. Тесты синтетические, но от этого не становятся менее интересными. Пример от Cloudflare.

 

Для иллюстрации производительности методов будут продемонстрированы некоторые цифры. Тесты синтетические, т.е. не на реальной сети с реальными пользователями и трафиком, так что не воспринимайте цифры слишком серьезно. Будет использоваться один из Intel серверов c 10Gbps сетевым интерфейсом. Детали железа не особо важны, т.к. тесты будут показывать вопросы, связанные с операционкой, а не с ограничениями по железу.

 

Что происходит при тестировании:

  • передача большого количества мелких UDP пакетов, достигая уровня в 14Mpps
  • этот трафик направляется на единственный CPU на сервере
  • измеряется количество пакетов, обработанных ядром на этом CPU

 

Мы не пытаемся максимизировать ни скорость приложения в юзерспейсе (userspace), ни количество пакетов. Вместо этого мы пытаемся показать узкие места самого ядра.

 

Синтетический трафик пытается максимально нагрузить conntrack - используется рандомный IP адрес источника и порт. Tcpducmp будет выглядеть примерно следующим образом:

$ tcpdump -ni vlan100 -c 10 -t udp and dst port 1234
IP 198.18.40.55.32059 > 198.18.0.12.1234: UDP, length 16
IP 198.18.51.16.30852 > 198.18.0.12.1234: UDP, length 16
IP 198.18.35.51.61823 > 198.18.0.12.1234: UDP, length 16
IP 198.18.44.42.30344 > 198.18.0.12.1234: UDP, length 16
IP 198.18.106.227.38592 > 198.18.0.12.1234: UDP, length 16
IP 198.18.48.67.19533 > 198.18.0.12.1234: UDP, length 16
IP 198.18.49.38.40566 > 198.18.0.12.1234: UDP, length 16
IP 198.18.50.73.22989 > 198.18.0.12.1234: UDP, length 16
IP 198.18.43.204.37895 > 198.18.0.12.1234: UDP, length 16
IP 198.18.104.128.1543 > 198.18.0.12.1234: UDP, length 16

На другой стороне все пакеты будут направлены на одну очередь прерываний (RX), т.е. на один CPU. Делается это через ethtool:

ethtool -N ext0 flow-type udp4 dst-ip 198.18.0.12 dst-port 1234 action 2

 

Оценочное тестирование всегда довольно сложное. Когда мы готовили тесты, мы обнаружили, что любые активные сырые сокеты (raw socket) сильно влияют на производительность. Это вполне очевидно, но легко не учесть. Перед тестами убедитесь, что у вас не запущен, к примеру, tcpdump.

$ ss -A raw,packet_raw -l -p|cat
Netid  State      Recv-Q Send-Q Local Address:Port
p_raw  UNCONN     525157 0      *:vlan100          users:(("tcpdump",pid=23683,fd=3))

 

В конце концов мы отключили Intel Turbo Boost:

echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo

Это классная функция, и увеличивает производительность по крайней мере на 20%, но она также очень сильно влияет на разброс показаний при замерах. Со включенным бустом разброс достигал +-1.5%. С выключенным - 0.25%.

 

fullview

 


1. Отброс/DROP пакетов в приложении


Начинаем с доставки пакетов к приложению и отбрасывании их уже с помощью него. Чтобы убедиться, что файервол не влияет на это делаем так:

iptables -I PREROUTING -t mangle -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT
iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT
iptables -I INPUT -t filter -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT

Код приложения - обычный цикл, который получает данные и сразу же их отбрасывает (в юзерспейсе):

s = socket.socket(AF_INET, SOCK_DGRAM)
s.bind(("0.0.0.0", 1234))
while True:
    s.recvmmsg([...])

Код приложения: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/recvmmsg-loop.c

$ ./dropping-packets/recvmmsg-loop
packets=171261 bytes=1940176

Тут мы получаем жалкие 175kpps:

$ mmwatch 'ethtool -S ext0|grep rx_2'
 rx2_packets: 174.0k/s

Железо нам дает 14Mpps, но мы не можем обработать это ядром на одном CPU с одной очередью прерываний. mpstat это подтверждает:

$ watch 'mpstat -u -I SUM -P ALL 1 1|egrep -v Aver'
01:32:05 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
01:32:06 PM    0    0.00    0.00    0.00    2.94    0.00    3.92    0.00    0.00    0.00   93.14
01:32:06 PM    1    2.17    0.00   27.17    0.00    0.00    0.00    0.00    0.00    0.00   70.65
01:32:06 PM    2    0.00    0.00    0.00    0.00    0.00  100.00    0.00    0.00    0.00    0.00
01:32:06 PM    3    0.95    0.00    1.90    0.95    0.00    3.81    0.00    0.00    0.00   92.38

Как видите, код приложения не является узким местом, используя 27% системы + 2% юзерспейса на CPU #1, в то время как SOFTIRQ на CPU #2 сжирает 100% ресурсов.
Кстати, использовать recvmmsg(2) довольно важно в наши пост-Спектровые дни (Spectre + Meltdown все же помнят?). Системные вызовы теперь требуют больше ресурсов. Мы используем ядро 4.14 с KPTI и retpolines:

$ tail -n +1 /sys/devices/system/cpu/vulnerabilities/*
==> /sys/devices/system/cpu/vulnerabilities/meltdown <==
Mitigation: PTI

==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <==
Mitigation: __user pointer sanitization

==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <==
Mitigation: Full generic retpoline, IBPB, IBRS_FW

 

 

2. Отключение conntrack

Мы специально выбрали рандомные IP адреса и порты при тестировании для того чтобы нагрузить conntrack. Это можно проверить, посмотрев на заполненность conntrack таблицы:

$ conntrack -C
2095202

$ sysctl net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_max = 2097152

И, конечно же, conntrack будет кричать в dmesg:

[4029612.456673] nf_conntrack: nf_conntrack: table full, dropping packet
[4029612.465787] nf_conntrack: nf_conntrack: table full, dropping packet
[4029617.175957] net_ratelimit: 5731 callbacks suppressed

Для ускорения наших тестов, давайте его отключим:

iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK

Запускаем тест:

$ ./dropping-packets/recvmmsg-loop
packets=331008 bytes=5296128

Теперь наше приложение получает 333kpps вместо 175kpps.
P.S. с SO_BUSY_POLL можно добиться 470kpps, но об этом в другой раз.

 

 

3. BPF дропание на сокете


Далее мы подумали - зачем этот трафик вообще нужен на юзерспейсе? Мы можем с помощью setsockopt(SO_ATTACH_FILTER) присоединить классический BPF фильтр к SOCK_DGRAM сокету и отбрасывать пакеты на уровне ядра (kernel space).
Код: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/bpf-drop.c

 

Тест:

$ ./bpf-drop
packets=0 bytes=0

С таким подходом (у классического BPF схожая производительность с eBPF) у нас получилось 512kpps. При этом экономится CPU, т.к. не нужно дергать приложение в юзерспейсе.

 


4. DROP с помощью iptables после роутинга


В качестве следующего теста мы решили отбрасывать пакеты в цепочке INPUT в iptables:

iptables -I INPUT -d 198.18.0.12 -p udp --dport 1234 -j DROP

Conntrack отключен в предыдущем правиле. Эти два правила в файерволе дали нам 608kpps.

$ mmwatch 'iptables -L -v -n -x | head'

Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
605.9k/s    26.7m/s DROP       udp  --  *      *       0.0.0.0/0            198.18.0.12          udp dpt:1234

 


5. DROP с помощью iptables в таблице PREROUTING


Т.е. отбрасываем пакеты пока они не попали в роутинг:

iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j DROP

Получаем 1.688mpps
Довольно существенный прирост при использовании таблички "raw".
Не совсем понятно почему такой прирост, возможно потому, что у нас сложный роутинг или баг в настройке сервера.

 


6. DROP с помощью nftables перед conntrack


Т.к. iptables доживает свои дни, то теперь можно пользоваться nftables.
Видео, объясняющее почему nftrack лучше: https://www.youtube.com/watch?v=9Zr8XqdET1c

nft add table netdev filter
nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; }
nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop
nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop

Счетчики можно пронаблюдать так:

$ mmwatch 'nft --handle list chain netdev filter input'
table netdev filter {
    chain input {
        type filter hook ingress device vlan100 priority -500; policy accept;
        ip daddr 198.18.0.0/24 udp dport 1234 counter packets    1.6m/s bytes    69.6m/s drop # handle 2
        ip6 daddr fd00::/64 udp dport 1234 counter packets 0 bytes 0 drop # handle 3
    }
}

Получили 1.53mpps. Это немного медленнее iptables, хотя должно быть наоборот. В любом случае nftables рулит.

 


7. Отбрасывание пакетов в tc ingress


Неожиданным фактом стало то, что tc (traffic control) ingress обрабатывается перед PREROUTING. Т.е. можно управлять трафиком еще раньше.
Синтаксис довольно неудобный, поэтому рекомендуется использовать скрипт: https://github.com/netoptimizer/network-testing/blob/master/bin/tc_ingress_drop.sh

tc qdisc add dev vlan100 ingress
tc filter add dev vlan100 parent ffff: prio 4 protocol ip u32 match ip protocol 17 0xff match ip dport 1234 0xffff match ip dst 198.18.0.0/24 flowid 1:1 action drop
tc filter add dev vlan100 parent ffff: protocol ipv6 u32 match ip6 dport 1234 0xffff match ip6 dst fd00::/64 flowid 1:1 action drop

проверяем:

$ mmwatch 'tc -s filter  show dev vlan100  ingress'
filter parent ffff: protocol ip pref 4 u32
filter parent ffff: protocol ip pref 4 u32 fh 800: ht divisor 1
filter parent ffff: protocol ip pref 4 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1  (rule hit   1.8m/s success   1.8m/s)
  match 00110000/00ff0000 at 8 (success   1.8m/s )
  match 000004d2/0000ffff at 20 (success   1.8m/s )
  match c612000c/ffffffff at 16 (success   1.8m/s )
        action order 1: gact action drop
         random type none pass val 0
         index 1 ref 1 bind 1 installed 1.0/s sec
        Action statistics:
        Sent    79.7m/s bytes   1.8m/s pkt (dropped   1.8m/s, overlimits 0 requeues 0)
        backlog 0b 0p requeues 0

Получили 1.8mppps на одном CPU.

 


8. XDP_DROP


https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/
С помощью XDP - eXpress Data Path мы можем запустить eBPF код прямо в сетевом драйвере. Т.е. перед тем как skbuff выделяет память.

 

Обычно в XDP две части:

  • eBPF код, загруженный в ядро
  • юзерспейсный загрузчик, который загружает код в нужную сетевую карту и управляет им

 

Написание загрузчика довольно трудное занятие, поэтому мы решили воспользоваться новой iproute2 фичей:

ip link set dev ext0 xdp obj xdp-drop-ebpf.o

https://cilium.readthedocs.io/en/latest/bpf/#iproute2

Исходник программы: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/xdp-drop-ebpf.c

Программа парсит IP пакеты и ищет заданные параметры: IP транспорт, UDP протокол, сеть, порт:

if (h_proto == htons(ETH_P_IP)) {
    if (iph->protocol == IPPROTO_UDP
        && (htonl(iph->daddr) & 0xFFFFFF00) == 0xC6120000 // 198.18.0.0/24
        && udph->dest == htons(1234)) {
        return XDP_DROP;
    }
}

XDP программа должна быть скомпилена с современным clang, который умеет делать BPF байткод. После этого загружаем и проверяем XDP программу:

$ ip link show dev ext0
4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp qdisc fq state UP mode DEFAULT group default qlen 1000
    link/ether 24:8a:07:8a:59:8e brd ff:ff:ff:ff:ff:ff
    prog/xdp id 5 tag aedc195cc0471f51 jited

И смотрим цифры в статистике интерфейса (ethtool -S)

$ mmwatch 'ethtool -S ext0|egrep "rx"|egrep -v ": 0"|egrep -v "cache|csum"'
     rx_out_of_buffer:     4.4m/s
     rx_xdp_drop:         10.1m/s
     rx2_xdp_drop:        10.1m/s

Итого получаем 10Mpps на одном CPU.

 

fullview

 

fullview

 

Источник: cloudflare

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Последнее это уже не CPU, но идея хорошая

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

6 часов назад, Kiano сказал:

Последнее это уже не CPU, но идея хорошая

Как это не CPU? То, что они изменили контекст и теперь BPF работает не в workers, а в ksoftirqd потоках даёт выигрыш при нормальном affinity и NAPI, но эти потоки всё также отрабатываются на CPU. А вот когда irqchip ограничен effective_affinity и нет NAPI, наступает северный пушной зверёк, т.к. все прерывания будут отрабатыватся на ограниченном количестве ядер (как правило, effective_affinity, если ограничен, то effective_affinity_list установлен в 1, то есть irqchip не умеет роутить/распределять прерывания на разные ядра), как пример - их первый тест, и 175kpps это ещё очень хороший результат, видимо, проц достаточно мощный. А вот проблема, о которой я пишу - типична для ARM'ов. Привет, новые тенденциозные ARM-сервера и маршрутизаторы.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: bot
      После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 4.18. Среди наиболее заметных изменений в ядре 4.18: возможность монтирования ФС на базе FUSE непривилегированным пользователем, пакетный фильтр bpfilter, подсистема AF_XDP (eXpress Data Path), новый тип модулей ядра umh (usermode helper), device-mapper модуль writecache, поддержка SoC Qualcomm Snapdragon 845 и GPU AMD Vega 20, новый API поллинга для асинхронного ввода/вывода.

      В новую версию принято 13 тысяч исправлений от 1668 разработчиков, размер патча - 50 Мб (изменения затронули 12866 файлов, добавлено 521039 строк кода, удалено - 619603 строк). Около 49% всех представленных в 4.18 изменений связаны с драйверами устройств, примерно 14% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 13% связано с сетевым стеком, 5% - файловыми системами и 3% c внутренними подсистемами ядра. 9.5% всех исправлений подготовлено разработчиками компании Intel, 7.5% - Red Hat, 4.6% - AMD, 4.3% - IBM, 3.8% - Linaro, 3.4% - Renesas Electronics, 3.0% - Google, 2.9% - SUSE, 2.8% - Samsung, 2.2% - Mellanox, 2.1% - Huawei, 2.0% - Oracle.

      В состав ядра включен новый механизм фильтрации пакетов bpfilter, использующего предоставляемую ядром подсистему eBPF, но предлагая привычный синтаксис iptables. Bpfilter обрабатывает запросы API iptables и транслирует их в программы BPF, привязываемые к различным подсистемам. В настоящий момент в ядро добавлена только базовая инфраструктура для bpfilter, но ещё нехватает некоторых компонентов, необходимых для полноценного применения bpfilter для фильтрации пакетов;

      В качестве сопутствующей bpfilter разработки в ядро добавлен новый тип модулей ядра umh (usermode helper), которые выполняются в пространстве пользователя и привязываются в базовым модулям, предоставляя для них вспомогательную функциональность, которую нецелесообразно или опасно выполнять c привилегиями ядра (например в модуле bpfilter.ko через них выполняется разбор и трансляция в BPF правил фильтрации). Модули umh функционируют под управлением ядра, оформляются в виде модулей ядра и загружаются через modprobe, но выполняются в пространстве пользователя с привилегиями пользовательских приложений. Взаимодействие umh-модулей с обычными модулями ядра производится с использованием неименованных каналов (unix pipe);

      В состав ядра включена подсистема AF_XDP (eXpress Data Path), которая предоставляет средства для запуска BPF-программ на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов, что позволяет создавать высокопроизводительные обработчики для работы в условиях большой сетевой нагрузки. В качестве примера реализованы обработчики для быстрой блокировки и перенаправления пакетов.

      Реализована возможность чтения данных из сетевого сокета в режиме zero-copy (флаг TCP_ZEROCOPY_RECEIVEY), позволяющем организовать передачу данных по сети без промежуточного копирования данных между ядром и пространством пользователя (поддержка записи в режиме zero-copy была представлена в ядре 4.14);

      В реализации протокола TLS на уровне ядра (KTLS) добавлена возможность задействования аппаратного ускорения операций с использовнием специализированных чипов. В настоящее время вынос связанных с работой TLS вычислений на плечи оборудования доступен только при использовании драйвера Mellanox mlx5;

      В TCP-стек добавлена поддержка режима сжатия для выборочного подтверждения соединений (SACK), что позволяет сократить число отправляемых SACK-пакетов при перегрузке сети;

      Добавлена возможность прикрепления BPF-программ к сокету и запуска обработчиков при вызове sendmsg(). Подобные обработчики могут применяться для выполнения такхи задач, как перезапись IP-адресов в исходящих пакетах;


      В подсистему шифрования (crypto) добавлена поддержка шифров AEGIS и MORUS, а также алгоритма сжатия Zstandard;
      Пользователь с правами root в пространстве имён идентификаторов пользователя (user namespaces) теперь может монтировать файловые системы, даже если у него нет на это прав вне пространства имён. При этом файловая система должна быть специально помечена для разрешения подобных операций (в настоящий момент операции разрешены только для ФС, реализуемых в пространстве пользователя при помощи модулей FUSE);

      В модуль fscrypt, применяемый для шифрования ФС F2FS и ext4, добавлена поддержка шифров Speck128 и Speck256, разработанных Агентством национальной безопасности США. Шифры обеспечивают очень высокую производительность программной реализации, которая обгоняет AES на системах без наличия средств аппаратного ускорения AES. Использование Speck позволяет применять шифрование на маломощных устройствах, на которых применение AES не оправдано из-за больших накладных расходов;

      Для 32-разрядной архитектуры ARM обеспечена защита от уязвимостей Spectre 1 и Spectre 2 (ранее защита от Spectre была обеспечена для архитектур x86, ARM64 и S390). Для ARM64 добавлена защита от Spectre v4.
      Проведена работа по переводу ядра на более защищёные от переполнения буфера варианты функций распределения памяти. Например, вызовы "kmalloc(count*size, gfp_flags)" заменены на "kmalloc_array(count, size, gfp_flags)";

      Изменены настройки для включения защиты от переполнения стека - теперь автоматически включается наиболее действенный механизм защиты, доступный для текущей конфигурации;


      Для Device Mapper реализован новый модуль "writecache", который может применяться для кэширования операций записи блоков на SSD-накопителях или в постоянной памяти (кэширование операций чтения не реализовано, так как такие операции и так кэшируются кэше страниц памяти в ОЗУ);

      Обеспечена возможность применения флага IOCB_FLAG_IOPRIO для операций асинхронного ввода/вывода, позволяющего установить приоритет выполнения отдельных операций;

      Добавлен новый API поллинга (определение готовности файлового дескриптора к вводу/выводу без блокировки), основанный на использовании системы асинхронного ввода/вывода (AIO);

      В файловой системе Btrfs обеспечена возможность удаления пустого подраздела при помощи вызова rmdir() без специальных дополнительных привилегий. Добавлены новые ioctl-команды FS_IOC_FSGETXATTR и FS_IOC_FSSETXATTR для манипуляции с различными атрибутами файла (append, immutable, noatime, nodump и sync), которые в отличие от команд GET/SETFLAGS могут выставить атрибуты на уровне отдельных inode. Также реализован набор ioctl-команд для получения непривилегированным пользователем информации о подразделах;

      В файловой системе XFS появилась возможность смены метки для уже примонтированной ФС, добавлена поддержка резервирования пустых областей через вызов fallocate() для файлов подкачки, задействован FUA для обеспечения прямой записи данных в режиме O_DSYNC. Кроме того, началась интеграция нового инструментария для восстановления целостности ФС на лету и выполнена переработка кода growfs с целью подготовки интеграции поддержки подразделов (subvolume);

      В файловой системе ext4 продолжена работа по чистке кода и повышению надёжности работы в условиях обработки некорректных образов ФС, специально модифицированных для вредоносных целей;

      Из раздела "staging" удалён код кластерной файловой системы Lustre. В качестве причин упоминается отсутствие должной активности по приведению имеющегося кода к соответствию с остальным ядром, плохая адаптация кода к изменениям в VFS, а также игнорирование проблем и периодическая публикация патчей, ломающих имеющуюся функциональность;
      В файловой системе F2FS улучшена поддержка режима "discard";


      В систему доменов управления питанием (genpd, generic power domain) добавлена поддержка уровней производительности, при помощи которых можно настраивать работу всей системы, включая периферийные устройства, для достижения требуемого баланса между потреблением энергии и производительностью;

      В контроллер ресурсов памяти group, позволяющий управлять расходованием памяти группой задач, добавлен параметр memory.min, который в отличие от ранее доступного параметра memory.low предоставляет более надёжную гарантию предоставления минимального размера доступной для группы оперативной памяти (не отключается при срабатывании OOM killer в условиях нехватки памяти);

      Добавлен системный вызов с реализацией перезапускаемых последовательностей (restartable sequences), позволяющих приложениям организовать неразрывное выполнение группы инструкций, не прерываемой и подтверждающей результат последней инструкцией в группе. По сути предоставляется средство для очень быстрого атомарного выполнения операций, которые в случае прерывания другим потоком очищаются и предпринимается повторная попытка выполнения. Возможность реализована для архитектур x86, ARM и PowerPC;

      Реализован новый параметр запуска ядра no5lvl, предназначенный для отключения пятиуровневых таблиц страниц памяти, даже если оборудование обеспечивает их поддержку;

      Из интерфейса /proc удалена статстика IPMI (по-прежнему оставлена в sysfs);

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

      В JIT-компиляторе подсистемы eBPF реализована поддержка 32-разрядных систем x86;


      В драйвер Nouveau добавлена поддержка GPU NVIDIA Volta;

      В DRM-драйвер AMDGPU добавлена поддержка GPU AMD Vega 20, а также GPU Kabylake-G (VEGAM - intel и radeon на одном чипе). Добавлены профили управления питанием, напряжением и частотой для GPU Vega10. Реализован режим энергосбережения gfxoff для GPU Raven;

      В DRM-драйвере Intel включена поддержка чипов Icelake (ICL), проведён рефакторинг кода GuC/HuC и DPLL, включена поддержка NV12 и PSR/PSR2;

      В драйвере amdkfd для dGPU (дискретные GPU, такие как Fiji, Tonga, Polaris) добавлена поддержка GPU GFX9;
      Добавлен новый DRM-драйвер v3d для оборудования Broadcom V3D V3.x+;

      Добавлен драйвер xen-front с реализаций графического фронтэнда для гостевых систем XEN в режиме паравиртуализации (PV);

      Добавлена поддержка SoC Qualcomm Snapdragon 845, применяемого в новейших мобильных устройствах класса high-end;

      Добавлена поддержка игровых контроллеров Steam от компании Valve;


      Одновременно Латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 4.18 - Linux-libre 4.18-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем. В новом выпуске представлен новый интерфейс для загрузки прошивок (firmware_reject_nowarn), не выводящий предупреждения в случае если прошивка не найдена. Добавлена чистка блобов для драйверов psp-dev и icn8505. Обновлён код чистки блобов в драйверах c3xxx, c62x, dvb-usb, dvb-usb-v2, iwlwifi, ks7010, ath10k, andgpu, i915, tg3, silead и ca0132. Прекращена чистка блобов для atom isp. Проведены ассемблерные файлы, вынесенные из основного кода amdkfd.

      Источник: Opennet
    • Автор: bot
      В TCP-стеке ядра Linux выявлена опасная уязвимость (CVE-2018-5390), которая позволяет удалённо вызвать отказ в обслуживании из-за исчерпания доступных ресурсов CPU. Для совершения атаки достаточно отправить поток специальным образом оформленных пакетов на любой открытый TCP-порт. Атака может быть совершена только с реального IP-адреса (спуфинг невозможен так как требуется установка TCP-соединения).

      Суть проблемы в том, что при определённых параметрах сегментирования ядро при поступлении каждого пакета вызывает достаточно ресурсоёмкие функции tcp_collapse_ofo_queue() и tcp_prune_ofo_queue(). Из-за неэффективности применяемого алгортима, необходимые для обработки сегментов ресурсы CPU линейно возрастают в зависимости от числа сегментов в очереди пересборки пакетов. При выполнении операции пересборки большого числа сегментов, cоздаваемой нагрузки достаточно, чтобы полностью загрузить процессор при обработке потока с незначительной интенсивностью. Например, для появления существенных задержек в обработке запросов системой для каждого ядра CPU достаточно потока интенсивностью всего 2 тысячи пакетов в секунду.

      Уязвимость проявляется на всех ядрах Linux, начиная с выпуска 4.9 (атака может быть проведена и против более старых ядер, но требует существенного более интенсивного потока пакетов). Проблема устранена в обновлении ядра 4.17.12. Обновления пакетов подготовлены для Debian, SUSE и Fedora, и ожидаются для Ubuntu и RHEL.

      Дополнение: Проблема также проявляется во FreeBSD и вероятно в других операционных системах. Во FreeBSD проблема пока временно решена через ограничение размера очереди пересборки пакетов (net.inet.tcp.reass.maxqueuelen).

      Источник: Opennet
    • Автор: bot
      Быстрая установка, безопасная работа, простота обновления, невероятная легкость использования и поддержки, - все эти свойства snap-приложений представляют огромный шаг вперед для разработки и установки ПО на Linux. Начиная с Ubuntu, а сейчас уже получив распространение и в Arch Linux, Debian, Fedora, Gentoo Linux и openSUSE, такие приложения дают множество преимуществ по сравнению с традиционными пакетами ПО. В отличие от стандартных пакетов ПО, snap-приложения:
      Более простые для разработки программистами; Быстрее устанавливаются; Автоматически обновляются; Автономны; Изолированы от других приложений; Более безопасны; Стабильны (их работа не нарушается другими приложениями);  

      Итак, что же такое snap-приложения?
      Изначально, snap-приложения были разработаны компанией Canonical для использования в Ubuntu. Этот сервис должен был называться "snappy", сама технология "snapcraft", фоновый процесс - “snapd” а пакеты - “snaps”, однако все это стало новым способом подготовки и установки приложений для Linux. Есши вы считаете, что приставка “snap” говорит о некоторой упрощенности в разработке приложений и процессе их установки? Это абсолютно так!
       
      Snap-приложения кардинально отличаются от других пакетов Linux. Другие пакеты в основном представляют собой архивы файлов, которые при установке помещают файлы в несколько директорий (/usr/bin, /usr/lib, и пр.). К тому же, другие инструменты и библиотеки, от которых зависит пакет, также необходимо установить или обновить, иначе возможен конфликт с более ранней версией. Snap-приложение, напротив, устанавливается как один независимый файл, включающий необходимые библиотеки и другие нужные файлы.  Его работа не будет влиять на работу других приложений, или менять какие-либо ресурсы, от которых также зависят и другие приложения.
       
      При разработке snap-приложения, все источники, необходимые для его работы, включаются в один файл. Такое приложение также изолированно от всей системы, обеспечивая тем самым то, что при изменении snap-приложения, остальные файлы системы не будут подвергаться каким-либо изменениям. Это также затрудняет доступ других программ к данным такого приложения.
       
      Другим важным отличием является то, что snap-приложения не могут являться частью пакетов программ, они рассматриваются и устанавливаются по отдельности, поговорим об этом чуть подробнее.
      Snap-приложения начали свое существования как Клик-пакеты (Click packages) - новый формат пакетов, разработанный для Ubuntu Mobile - а затем уже стали snap-приложениями.
       

      Как работают snap-приложения?
      Snap-приложения работают посредством множества дистрибутивов Linux таким образом, который иногда называют “дистро-агностикой” “distro-agnostic” , он дает разработчикам выйти за рамки своих представлений о совместимости ПО и предварительно установленных библиотек системы. Пакет snap-приложения уже содержит все, что ему нужно для запуска – сжатое, готовое к использованию. По сути, такими (сэатыми) они и остаются. Это позволяет им занимать мало места на диске, не смотря на их автономность.
      Работа таких приложений относительно незаметна. Ваша система может иметь несколько таких программ, а вы даже не будете знать об этом, например, если они входили в дистрибутивы, о которых мы говорили ранее.
       
      Если все же такие приложения присутствуют в вашей системе, для того, чтобы их найти вам нужно будет прописать в строке поиска /snap/bin. Если вы используете для работы оболочку bash users, эта строка будет добавлена автоматически.
      $ echo $PATH /home/shs/bin:/usr/local/bin:/usr/sbin:/sbin:/bin:/usr/games:/snap/bin Проблемы не возникнут даже при автоматическом обновлении. Запущенное snap-приложение продолжает свою работу даже во время обновления. Просто, более новая версия станет активна при следующем запуске.
       

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

      Как snap-приложения помогают разработчикам?
       
      Они проще в разработке.
      Snap-приложения позволяют разработчикам больше не думать о необходимости разработки множества дистрибутивов и версий, которые могут понадобиться пользователям. Они просто помещают в пакет snap-приложение и все, что может понадобиться для его работы.
       
      Упрощение длительного процесса разработки
      С точки зрения разработчиков, запускать приложения в разработку довольно трудно. Сообщество открытого кода способно на такое только в ответ на давление по поводу выпуска новых релизов. К тому же, разработчики могут использовать новые библиотеки, не принимая во внимание то, что целевой дистрибутив ссылается на более старые библиотеки. И, даже если они пока новички в разработке snap-приложений, наверстать упущенное они смогут уже за неделю. Говорят, что обучение разработке snap-приложений намного легче, чем изучение новых языков. И, конечно, компаниям, выполняющим поддержку дистрибутива не будет нужно проводить каждое приложение через процесс разработки. Таким образом, выигрывают все.
       
      Пользу snap-приложений также оценят и системные администраторы, особенно то, что эти программы на наносят вред системе и не приводят к необходимости разбираться в дебрях поддержки.
       

      Имеет ли ваша система snap-приложения?
      Ваша система может иметь несколько таких программ, а вы даже не будете знать об этом, например, если они входили в дистрибутивы, о которых мы говорили ранее.
      Проверка работы:
      $ ps -ef | grep snapd root 672 1 0 Jun22 ? 00:00:33 /usr/lib/snapd/snapd где лежит запускающий файл:
      $ which snap /usr/bin/snap какие snap запущены:
      $ snap list Name Version Rev Tracking Developer Notes canonical-livepatch 8.0.2 41 stable canonical - core 16-2.32.8 4650 stable canonical core minecraft latest 11 stable snapcrafters -
      Куда установлены snap'ы?
      Обычно это /var/lib/snapd/snaps. Пакеты поставляются как файлы со .snap расширением
      $ sudo find / -name "*.snap" /var/lib/snapd/snaps/canonical-livepatch_39.snap /var/lib/snapd/snaps/canonical-livepatch_41.snap /var/lib/snapd/snaps/core_4571.snap /var/lib/snapd/snaps/minecraft_11.snap /var/lib/snapd/snaps/core_4650.snap  
      Установка snap'а
      $ sudo snap install hello hello 2.10 from 'canonical' installed $ which hello /snap/bin/hello $ hello Hello, world!  
      проверяем:
      $ snap list Name Version Rev Tracking Developer Notes canonical-livepatch 8.0.2 41 stable canonical - core 16-2.32.8 4650 stable canonical core hello 2.10 20 stable canonical - minecraft latest 11 stable snapcrafters - Для удаления есть snap remove
      Для обновления - snap refresh
      Для списка доступных - snap find
       

      Небольшая предыстория
      Идея snap-приложений родилась у Марка Ричарда Шаттерворта (Mark Richard Shuttleworth), основателя и директора компании Canonical Ltd., выпустившей операционную систему Ubuntu на основе Linux-based и имеющей десятилетия опыта работы с ней. Одной из составляющих мотивации был уход от возможных ошибок при установке – впервые эти программы были использованы на телефонах. Упрощение процесса разработки, простота техподдержки и повышение безопасности системы не оставили шансов забросить эту идею.
       
      источник: networkworld
×