The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В состав GCC принят бэкенд для компиляции в eBPF

09.09.2019 23:13

В состав набора компиляторов GCC принят код для компиляции программ для встроенного в ядро Linux интерпретатора байткода eBPF. Благодаря применению JIT-компиляции, в ядре байткод на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. Патчи с поддержкой eBPF приняты в ветку, на основе которой развивается выпуск GCC 10.

Помимо бэкенда для генерации байткода в GCC включён порт libgcc для eBPF и средства для формирования ELF-файлов, дающих возможность выполнить код в виртуальной машине eBPF с использованием предоставляемых ядром загрузчиков. Патчи для поддержи eBPF в GCC подготовлены инженерами из компании Oracle, которые до этого уже обеспечили поддержку eBPF в GNU binutils. В разработке также находится симулятор и патчи для GDB, которые позволят отлаживать eBPF-программы без загрузки в ядро.

Программы для eBPF могут определяться на подмножестве языка C, компилироваться и загружаться в ядро. Перед выполнением интерпретатор eBPF проверяет байткод на предмет применения разрешённых инструкций и налагает определённые правила на код (например, отсутствие циклов). Изначально для компиляции eBPF в Linux применялся инструментарий на базе LLVM. Поддержка eBPF в GCC представляет интерес тем, что позволяет использовать один инструментарий для сборки ядра Linux и eBPF-программ, без установки дополнительных зависимостей.

В форме программ eBPF можно создавать обработчики сетевых операций, фильтровать трафик, управлять пропускной способностью, отслеживать работу систем, перехватывать системные вызовы, контролировать доступ, подсчитывать частоту и время выполнения операций, выполнять трассировку с использованием kprobes/uprobes/tracepoints.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Релиз набора компиляторов GCC 9
  3. OpenNews: Вышел компилятор языка D 2.083. Поддержка языка D включена в состав GCC
  4. OpenNews: Выпуск Cilium 1.0, сетевой системы для Linux-контейнеров, основанной на BPF
  5. OpenNews: Для Linux представлена система динамической отладки BPFtrace (DTrace 2.0)
  6. OpenNews: Компания Oracle намерена переработать DTrace для Linux с использованием eBPF
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: ebpf, gcc, bpf
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (41) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Бэтман (?), 23:26, 09/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Все хорошо. Вот только писать eBPF программы вообще не тривиальное занятие. Может знатоки какой фреймворк подскажут?
     
     
  • 2.3, Аноним (3), 23:52, 09/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Cython он не про это но лучше юзай его)
     
     
  • 3.20, Аноним (20), 10:05, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А Cython может в eBPF компилировать?
     
     
  • 4.29, Аноним (29), 12:27, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Нет это фреймворк похожий на питон который делает быстрый код.
     
  • 2.11, null (??), 08:06, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пиши на подмножестве C (без циклов) и получай на выходе байткод eBPF. Новость как раз об этом.
     
     
  • 3.41, Аноним (-), 16:47, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет никаких подмножеств. Есть Чистый Си, и есть уже несовместимый с ним C++
     
  • 2.19, Аноним (20), 10:04, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вероятно, со временем добавят возможность писать на подмножестве C++
     
     
  • 3.32, X4asd (ok), 16:23, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вероятно, со временем добавят возможность писать на подмножестве C++

    зачем

      

     
     
  • 4.34, grsec (ok), 17:23, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вот так
     
     
  • 5.42, X4asd (ok), 19:12, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > вот так

    и всё же

     
  • 3.38, nobody (??), 12:00, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Было бы неплохо. В GPU шейдеры - уже
     
  • 2.26, Аноним (26), 11:02, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот только писать eBPF программы вообще не тривиальное занятие.

    в машинных кодах тоже непросто, для этого языки высокого уровня придумали

     
     
  • 3.30, Аноним (29), 12:29, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Как раз таки в машинных кодах достаточно просто, но муторно. Кстати в машинных кодах отлично получаются высоконагруженные парсеры.
     

  • 1.2, Аноним (3), 23:50, 09/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не верю что с разными версиями ядра такие приложения будут работать одинаково.
     
     
  • 2.9, anonymous (??), 00:20, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зависит от приложения, но многое покрывается тем, что для сборки требуются хедеры целевого ядра. Соответственно если скомпилится, то наверняка будет работать.
     
  • 2.21, Аноним (20), 10:10, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Естесственно, это же достаточно низкоуровневая обработка пакетов и прочего. Для большего абстрагирования от версий ядра есть nftables.
     

  • 1.4, Аноним (4), 23:56, 09/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ура, наконец-то можно пихать проприетарщину в кернелмод!
     
     
  • 2.7, Аноним84701 (ok), 00:11, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Ура, наконец-то можно пихать проприетарщину в кернелмод!

    Не только проприертарщину:
    https://twitter.com/bleidl/status/943714277403357185
    > Pour one out for this really nice Linux kernel bugdoor that P0 killed a few hours ago. Straight up unlimited R/W to all kernel memory via ebpf verifier bypass. One of the best/worst Linux kernel vulns of all time

    https://lwn.net/Articles/742170/
    :)

    Сложные компоненты, да еще и с JIT, транслирующие высокоуровневый код из юзерспейса в машинный код для загрузки в ядро, такая вот штука.

     
  • 2.22, Аноним (20), 10:12, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если сам себе враг, то пихай.
     
     
  • 3.23, Аноним (20), 10:51, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Штеуд с МЕ, деадушку уже обул. Точнее сказать.
     

  • 1.6, Аноним (6), 00:10, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Пробовал я клангом. К костыльному языку костыли приделали. Первая же variable-length структура сводит мозг их верификатору, но клангу до этого нет дела, он похоже вообще на знает про верификатор. С гцц наверняка будет похожая история.
     
  • 1.10, Аноним (10), 07:34, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Патчи для поддержи eBPF в GCC подготовлены инженерами из компании Oracle

    jvm будут трансилровать в eBPF небось

     
     
  • 2.14, Аноним (-), 08:34, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и таких как ты тут 99%
     
     
  • 3.15, Andrey Mitrofanov_N0 (??), 08:49, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и таких как ты тут 99%

    В глубокой заморозке-то??

    02.05.2017 21:09
       GCC 7.1 примечателен удалением из состава компилятора для языка Java,
    https://www.opennet.ru/opennews/art.shtml?num=46487

     
  • 2.24, Аноним (20), 10:55, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Виртуальную машину JS напишут на eBPF. Вот тогда-то макаки заживут. Electron, Node.js - всё есть прямо в ядре. :)
     
     
  • 3.28, НяшМяш (ok), 11:33, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ох как будет гореть у гошников и явистов в юзерспейсе! /sarcasm
     
     
  • 4.33, anonymous (??), 17:00, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    WebAssembly на eBPF :)
     

  • 1.12, Joe B. (?), 08:28, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Когда на eBPF напишут эмулятор eBPF, то круг замкнётся.
     
     
  • 2.13, Andrey Mitrofanov_N0 (??), 08:31, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда на eBPF напишут эмулятор eBPF, то круг замкнётся.

    Компилятора Си, написанного на Си, хватит всем!  :-P

     

  • 1.17, Анонас (?), 09:43, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ничего эти линуксоиды сами придумать не могут http://www.opennet.ru/opennews/art.shtml?num=38203
     
     
  • 2.25, Аноним (20), 11:01, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И чем там принципиально лучше? Вкорячили в прямо ядро интерпретатор исходного кода. А здесь сначала в байткод компиляют в юзерспейсе.
     
     
  • 3.35, bobr (?), 18:06, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там JIT-компиляция.
     

  • 1.18, odin314 (ok), 09:49, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    хочется надеться что с развитем eBPF зоопарк с сетевыми тулзами уменьшится
     
     
  • 2.31, пох. (?), 14:11, 10/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    наоборт же ж - каждая макака наклепает тебе сетевых тулзей на eBPF, патамушта модно - причем чтобы поменять что-нибудь - придется ковыряться в исходнике пакета и никак иначе.
    И тулзы эти будут в каждой версии одного и того же дистрибутива - разные.

     

  • 1.27, Аноним (26), 11:04, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какая мотивация писать новую виртуальную машину, когда есть куча готовых?
     
  • 1.37, nc (ok), 08:45, 11/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В чем смысл именно JIT (в его классическом понимании - трансляции команд "на лету", т.е. как минимум при каждом запуске, а то и в процессе исполнения программы)?
    Как формат для распространения еще можно понять, но не проще ли сгенерировать код для целевого процессора один единственный раз при инсталляции софта на конкретную машину?
     
     
  • 2.39, Аноним84701 (ok), 13:14, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В чем смысл именно JIT (в его классическом понимании - трансляции команд
    > "на лету", т.е. как минимум при каждом запуске, а то и
    > в процессе исполнения программы)?

    В классическом понимании -- для компиляции "на лету"  ЯП с динамической типизацией/поздним связыванием (vtable,  dynamic dispatch) и прочими кунтсштюкам.
    ЕМНИП, придумали еще в 60 для лиспа.

    При "классической" компиляции динамичного ЯП придется или генерировать код для всех возможных комбинаций вариантов типов/вызовов методов или же "разбирать" все во время выполнения  (получим тот же интерпретатор, вид сбоку).
    В случае JIT компиляции есть возможность отслеживать (tracing JIT) конкретно используемые типы и методы и компилировать только этот вариант.

     
  • 2.40, Аноним (20), 15:17, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >но не проще ли сгенерировать код для целевого процессора один единственный раз при инсталляции софта на конкретную машину?

    А правила добавлять/вставлять/удалять на ходу?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру