The OpenNET Project / Index page

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

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

31.03.2020 10:53

Опубликованы сведения об уязвимости (CVE-2020-8835) в ядре Linux, которая была использована в соревновании Pwn2Own 2020 при демонстрации взлома Ubuntu. Уязвимость позволила непривилегированному пользователю получить права root. Рабочий эксплоит существует, но пока не опубликован. Уязвимость присутствует в подсистеме eBPF, позволяющей запускать обработчики для трассировки, анализа работы подсистем и управления трафиком, выполняемые внутри ядра в специальной виртуальной машине с JIT.

Проблема вызвана ошибкой в функции __reg_bound_offset32(), применяемой для проверки 32-разрядных операций в байткоде BPF. Из-за неверного расчёта границ регистра при обработке специально оформленных BPF-приложений возникали условия для записи и чтения данных вне выделенного буфера в области памяти ядра. Проблема появилась в ядре 5.5 и позднее при бэкпортировании исправлений была перенесена в ядро 5.4, а также в пакет с ядром 5.3, предлагаемым в Ubuntu Linux.

Для блокирования уязвимости рекомендовано откатить проблемный патч или запретить выполнение BPF-приложений непривилегированными пользователями через установку sysctl kernel.unprivileged_bpf_disabled в значение 1. Статус исправления в дистрибутивах: Ubuntu, Debian, Arch, Fedora и SUSE (в ядра RHEL проблемное изменение не переносилось).

Дополнение: Опубликован подробный разбор техники эксплуатации уязвимости.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: На соревновании Pwn2Own 2020 продемонстрированы взломы Ubuntu, Windows, macOS и VirtualBox
  3. OpenNews: В eBPF найдена возможность обхода защиты ядра Linux от атаки Spectre
  4. OpenNews: Компания Oracle намерена переработать DTrace для Linux с использованием eBPF
  5. OpenNews: В состав GCC принят бэкенд для компиляции в eBPF
  6. OpenNews: Критические уязвимости в подсистеме eBPF ядра Linux
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/52640-bpf
Ключевые слова: bpf, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (130) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:59, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +22 +/
    Они думали, что они боженьки, и что вот у них-то точно получится затащить виртуальную машину с JIT в ядро, и в ней не будет дыр и граблей, на которые наступала Java.
     
     
  • 2.5, Я (??), 11:16, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +11 +/
    нет. они знали что дыры будут и что их придётся не раз фиксить как и любую другую технологию.
     
     
  • 3.24, gogo (?), 12:18, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Таки не "как любую другую". Тут любая дыра - рут.
     
     
  • 4.37, КО (?), 12:42, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Не рут, а ядро. Рут по новым правилам слегка ограничен - а тут полная воля. :)
     
  • 3.121, Аноним (121), 06:09, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > они знали что дыры будут

    Скажем больше, они специально JIT в ядро засунули, чтобы эти дыры там были.

     

  • 1.2, Аноним (2), 11:00, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сайт арча не знает об уязвимости, значит её нет на моей арч установке.
     
     
  • 2.12, Чебур (?), 11:33, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Арчу вообще стоит молчать об любых уязвимостях пока у них есть aur-помойка
     
     
  • 3.51, Аноним (51), 13:40, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В чём проблема с аур-помойкой? Не нравится - не пользуйся
     
     
  • 4.57, Michael Shigorin (ok), 14:18, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как и с любой помойкой, которой то размахивают -- "вот у нас сколько всего", то чуть что -- "...только не пользуйся".
     
     
  • 5.83, Аноним (83), 16:49, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да ладно, просто арчеводу нужно было срочно сказать всем, что у него арч.
     
     
  • 6.97, Аноним (97), 18:21, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Мне сложно это говорить но у вашего сына Арч.
     
     
  • 7.126, Аноним (126), 10:36, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно не лечить, само пройдёт со временем.
     
     
  • 8.130, Аноним (130), 11:44, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Один раз 8212 не арчевод, что ли Не-е-ет, это работает с точность до наоборо... текст свёрнут, показать
     
  • 8.135, Аноним (135), 14:33, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    как известно, от плохих привычек не избавляются, их заменяют другими на что, до... текст свёрнут, показать
     
  • 3.102, виндотролль (ok), 19:08, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Арчу вообще стоит молчать об любых уязвимостях пока у них есть aur-помойка

    А где-то есть статистика по количеству малвари в ауре?

     
     
  • 4.112, Lex (??), 21:54, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Когда-то была, но, поскольку на серваке  с ней стоял арч ...
     
  • 3.109, 1 (??), 21:15, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Просто у тебя нет AURа, вот и бесишься)
     
  • 2.118, iPony129412 (?), 05:09, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сайт арча не знает об уязвимости

    Уже знает.
    Ну не починили к тому времени. А так представь два раза с дивана вставать – сначала страницу создавать, что не починено, а потом править её же, что починено.
    А так хитро – сразу "вот есть таоке и всё починено"

     

  • 1.3, Аноним (3), 11:06, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    JIT в ядре. Совсем страх потеряли.
     
     
  • 2.64, Аноним (64), 15:03, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Всё же лучше, чем позволять загружать в ядро нативный машинный код обработчиков для трассировки, анализа работы подсистем и управления трафиком. Да ещё и непривилегированным пользователям.
     

  • 1.4, Аноним (4), 11:14, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Писали бы ядро на Rust, такого бы не случилось.
     
     
  • 2.6, анон (?), 11:21, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ядро сильно старше раста
     
  • 2.7, A.Stahl (ok), 11:21, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Ядра бы тоже случилось.
     
     
  • 3.15, нах. (?), 11:50, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    нет ядра - нет уязвимостей!
     
  • 2.14, Аноним (14), 11:49, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Уже пишут. Redox OS.
    Будет весело, если там таки найдут уязвимость)
     
     
  • 3.17, нах. (?), 11:52, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Но таких неленивых, кому зачем-то сдался совершенно неуловимый джо - вряд ли найдется.

     
  • 3.19, gogo (?), 11:54, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не если, а когда
     
  • 2.27, Gogi (??), 12:23, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –13 +/
    У Линуса проблема была не в языке (хотя и в нём тоже), а в принципиальной архитектуре. Не зря Танненбаум макал Трольвадса в ошибки. Но.... как об стенку горох - Линус накодил то, на что хватило интеллекта. И вот он вырос - Линукс, самое безобразное поделие в ИТ.
     
     
  • 3.31, Аноним (31), 12:35, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ничего Фуксия все поправит.
     
  • 3.33, Аноним (33), 12:38, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Топ-500 суперкомпьютеров в мире используют ТОЛЬКО линукс.
    Этот человек уже вписал себя в историю в отличии от диванных экспертов уход из жизни которых никто и не заметит.
     
     
  • 4.104, Аноним (104), 19:52, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это корпорации себя вписали в историю, если ты не в курсе. И хотелось бы знать а топ рабочих компьютеров какую ос использует?
     
     
  • 5.117, анонимуслинус (?), 04:34, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    если ты о топ, то это эппл мак ос))) потому как все топ и не только стараются прикупить их компы. и телефоны. хотя... она была топ системой во время power G процессоров и osx 9. сейчас это нечто немногим лучше винды, но с более отработанным интерфейсом.
     
     
  • 6.131, Аноним (130), 11:46, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > все топ и не только стараются прикупить их компы

    Какие-то влажные фантазии с ароматом яблоневого сада.

     
     
  • 7.134, анонимуслинус (?), 14:32, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    это не фантазии , а реальность. неплохая работа рекламщиков эппл. правда раньше их телефоны и компьютеры сами себя рекламировали качеством, но увы с переходом на интелл все ближе к хламу. но все верят в их "элитарность")))
     
  • 3.34, Fyjy (?), 12:38, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Вот только Таненбаум при этом ничего рабочего не создал, а паразитирует на грантах ЕС, а ядро Linux работает по всему миру во всех устройствах от мобил и домашних роутеров до серверов и суперкомпьютеров.
     
     
  • 4.36, Аноним (33), 12:41, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тот кто умеет - делает, а кто не умеет обсуждает и советуют другим как надо было бы сделать
     
     
  • 5.41, Fyjy (?), 12:54, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Именно так. Таненбаум только советовать может и паразитировать на грантах, ничего реального он сделать не может.
     
     
  • 6.43, Аноним (43), 13:04, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Ядро Таненбаума используется в каждом PC в чипах для массовой слежки, ты просто не в курсе :-)
     
     
  • 7.66, Fyjy (?), 15:22, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот только это со слов самого Таненбаума и не в каждом, а только в интеловских процах. Никаких доказательств, что его код где-то используется нет, просто он это соврал в одном из интервью и не более
     
     
  • 8.113, Lex (??), 21:58, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кагбэ, третий и первый для реального применения миникс, все дела Кажись, ка... текст свёрнут, показать
     
     
  • 9.139, Fyjy (?), 00:05, 03/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, гранты которые он прожрал 2 миллиона евро выделялись на портирование Postg... текст свёрнут, показать
     
  • 8.114, AnonPlus (?), 00:57, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не Таненбаума, а ребят из Positive Technologies, которые это ковыряют... текст свёрнут, показать
     
  • 4.50, Аноним (50), 13:30, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
      Intel ME летище Таненбаума так-то.

    Не говоря о том, что на уроках Таненбаума выросли десятки тысяч программистов.

     
     
  • 5.67, Fyjy (?), 15:24, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >   Intel ME летище Таненбаума так-то.
    > Не говоря о том, что на уроках Таненбаума выросли десятки тысяч программистов.

    Про Intel ME это только вранье самого Эндрю в одном из интервью, без доказательств. Да и там он говорит типа «мне один знакомый рассказал, что его знакомый слышал от знающего человека»

    Про программистов выросших… Ну да. Они точно знают что и как НЕ нужно делать.

     
     
  • 6.115, AnonPlus (?), 01:01, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да нет, это твоё враньё как раз. Учи матчасть, вуглускр
    https://habr.com/company/pt/blog/346974/
     
  • 3.58, Michael Shigorin (ok), 14:20, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Вы правда готовы предъявить свою (не профессорскую, а свою) разработку в области ядер ОС?

    Если нет -- заткнитесь.
    Если интеллекта не хватает понять, почему -- могу объяснить.

     
     
  • 4.88, Fyjy (?), 17:02, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Миша, ты что-то сегодня слишком агрессивный. Тебе вынули крепкий путинский стержень из седалища что ли и ты обиделся?
    Таненбаум — теоретик, чьи теории практикой были проверены и показали себя ничтожными.
     
     
  • 5.105, нах. (?), 20:44, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну почему - l4 был вполне работающий. А он, в общем, теориям не противоречит. (эппловский mach не совсем микро, и не совсем ядро. И написан то ли в одно время с таненбаумовским учебником, то ли еще раньше даже, так что не считается.)

     
  • 5.137, Вася (??), 23:00, 02/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    QNX микроядерная и пожалуй лучшая ось
     
     
  • 6.138, Fyjy (?), 00:04, 03/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только нишевая на 100% и в реальной жизни не встречается
     
  • 3.70, Анолинукс (?), 16:12, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Весь спор Танненбаума с Линусом сводился к тому что идеальная микроядерная архитектура
    в реальном мире будет работать крайне тормозно из-за накладных расходов.
    Монолитное ядро - это не идеальное, но реально работающее решение, кстати в 1990 году,
    на 386 процессоре.
     
     
  • 4.110, Fracta1L (ok), 21:32, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Для начала: идеальная микроядерная архитектура никогда не будет работать, потому что не будет реализована в сколь-нибудь обозримое время. За пруфами можно обратиться к Столлману, он уже полбороды себе выдрал от осознания того, в какой тупик завёл HURD выбор микроядра в качестве основы.
     
     
  • 5.122, Аноним (122), 09:13, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В Symbian прекрасно работало микроядро, до известных событий в истории.
     
  • 3.84, Аноним (84), 16:57, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну ничего, зато поделие Таненбаума как минимум во всех процессорах интела.
     
  • 2.42, Анонимъ (?), 12:58, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Даже если Rust уменьшает количество ошибок, ведущих к уязвимостям, это совершенно не значит, что уязвимостей не будет совсем. Это я как ярый любитель растишки говорю.
     
     
  • 3.48, 54t45yh (?), 13:18, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На сколько уменьшает? Упустить утечку памяти и прочее трудно достижимо?
     
     
  • 4.68, коржик (?), 15:32, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    утечку памяти - нет, для раста это не считается UB.
     
  • 4.119, leap42 (ok), 05:25, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > На сколько уменьшает?

    Mozilla считала, но пруф мне лень искать: примерно на 2/3 если переписывать со смеси Си и С++. При этом сами привели пример ошибки на плюсах, которую пофиксили, но при переписывании на Rust уже не помнили, и она проявилась опять. Т.Е. по факту иногда переписывание на Rust превносит ошибки работы с памятью. Это не говоря об ошибках в borrow checker (в этом году по-моему одну такую пофиксили), когда программист надеется что компилятор на 100% страхует от проблем при работе с памятью, а он на самом деле нет.

     
  • 2.55, asdasd (?), 14:05, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    unsafe никуда бы не делся.
     
     
  • 3.63, Аноним (-), 14:57, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в я.п. Rust явное разделение на safe-код и unsafe-код, правильно?
     
     
  • 4.106, нах. (?), 20:45, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    " вы когда границу пересекали - такой большой красный флаг что, не увидели?!"

     

  • 1.8, Аноним (-), 11:24, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    есть сомнения, что будущее за микроядерной архитектурой.
     
     
  • 2.9, Аноним (9), 11:29, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Есть сомнения, что 2 + 2 = 5. И не у меня одного.
     
     
  • 3.11, And (??), 11:33, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Когда Лобачевский говорил: параллельные прямые пересекаются, крутили пальцем у виска. А сейчас уже ничего, что пересекаются и даже сумма углов треугольника в 270 градусов норм и не смущает.
     
     
  • 4.20, gogo (?), 11:58, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    какой  жирный пример демагогии )
    "параллельные прямые" микроядер пересекаются в умозрительном пространстве, но не в реальном эвклидовом
     
     
  • 5.32, Аноним (31), 12:36, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Микроядра не могут физически реализоваться посмотри на ГНУ Хурд, например.
     
     
  • 6.44, Аноним (43), 13:06, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрел, Hurd работает, что не так?
     
     
  • 7.91, Аноним (91), 17:23, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вопрос в том на каких архитектурах он работает. Ну и еще с какой производительностью...
     
  • 7.107, нах. (?), 20:46, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "загружается".

    Насчет работает - не надо сказок, он только падает и виснет хорошо.

    В основном, вероятно, потому что линуксным драйверам 1998го года (которые там в основном) немного поплохело от переписывания в userspace. Но это неточно.

     
  • 6.60, Аноним (-), 14:27, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Minix3 уже сколько лет существует, причём есть в Intel IME.
    Google разрабатывает о.с. Fuchsia на микроядре Zircon
     
  • 6.61, Anonymqwe (?), 14:42, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я предлагаю вам посмотреть на QNX. Она нишевая, но мы же сейчас не говорим о распространённости.
     
     
  • 7.108, нах. (?), 20:47, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    нишевая - это не только распространенность, это еще и работопригодность.

    Для какой практической цели ВАМ бы пригодилась - qnx?

     
     
  • 8.123, anonymous (??), 09:45, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для поднятия ЧСВ ... текст свёрнут, показать
     
     
  • 9.133, нах. (?), 12:53, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    дык это понятно что для поднятия - а как это к делу-то какому за зарплату примен... текст свёрнут, показать
     
  • 5.93, other_anonymous (?), 17:31, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    релальном <> эвклидовом. /0
    Эвклидово то как раз и умозрительно
     
     
  • 6.96, Аноним (96), 18:19, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Любое пространство умозрительно, это математический объект.
     
  • 4.30, Здрасьте (?), 12:31, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Он так не говорил. Легко в этом убедиться, если погуглить.
     
  • 4.65, Аноним (64), 15:15, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Когда Лобачевский говорил: параллельные прямые пересекаются, крутили пальцем у виска.

    Лобачевский говорил, что через точку вне заданной прямой можно провести множество прямых, параллельных заданной. А то, что вы написали, говорил Риман.

     
     
  • 5.73, Аноним (73), 16:21, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Риман тоже такой чуши сказать не мог. Параллельные прямые не могут пересекаться потому что это и есть определение параллельных прямых - прямые которые не пересекаются.
     
  • 4.98, Аноним (98), 18:46, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ещё одна жертва рекламы zanussi
     
  • 4.132, Аноним (130), 11:57, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты опять выходишь на связь?
    Геометрия Лобачевского допускает, что на одной плоскости может находиться сразу несколько прямых линий, не пересекающихся друг с другом. Улавливаешь разницу?
     
  • 3.28, Аноним (-), 12:26, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    если 2+2=5, тогда есть сомнения, что какие-то проблемы с арифметикой.
     
     
  • 4.46, A.Stahl (ok), 13:10, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Арифметика бывает разной. В том числе и такой где 2+2=5 и даже такой где выражение 2+2 вообще не несёт смысла.
     
     
  • 5.82, Аноним (73), 16:40, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А вы высшую алгебру учите, стыдно должно быть.
     
  • 2.10, Аноним (73), 11:33, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И как микроядерная архитектура спасает от слабоумных разработчиков которые решают выполнять JIT-код в привелигерованном кольце?
     
     
  • 3.16, нах. (?), 11:52, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Микроядерная архитектура предназначена для того, чтобы ты мог выполнять код залетного васяна в кривом драйвере в непривелигированном кольце ;-)

    "теперь мне не нужно взламывать ядро системы - достаточно подсунуть что-то драйверу в userspace!"

    это ли не прогресс науки и технологий?!

     
     
  • 4.52, Совершенно другой аноним (?), 13:46, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Принципиально, конечно, микроядерная архитектура более безопасна, хотя-бы потому... большой текст свёрнут, показать
     
     
  • 5.54, КО (?), 13:52, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С другой стороны, делая данный JIT для общего случая - ему же дадут права для доступа к остальным драйверам и данным. И собственно ядро все...
     
  • 5.72, Анолинукс (?), 16:19, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кольца безопасности поддерживаются аппаратно - процессором.
    В Intel-e x86 - 2 кольца, больше было у SUN SPARK, если правильно помню.
    Програмная реализация этой фигни - это будет надстройка еще раз убивающая
    производительность и практическую полезность этой системы
     
     
  • 6.74, Совершенно другой аноним (?), 16:22, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Кольца безопасности поддерживаются аппаратно - процессором.
    > В Intel-e x86 - 2 кольца, больше было у SUN SPARK, если
    > правильно помню.
    > Програмная реализация этой фигни - это будет надстройка еще раз убивающая
    > производительность и практическую полезность этой системы

    Вообще-то аппаратных в x86 именно 4.

     
     
  • 7.75, Анолинукс (?), 16:23, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В 1990 на 386 процессоре?
     
     
  • 8.80, Совершенно другой аноним (?), 16:38, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    в 1985 и да, за процессоре 80386 На всякий случай ещё раз перепроверил по книге... текст свёрнут, показать
     
     
  • 9.86, Аноним (84), 17:00, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Есть ещё как минимум 2 подземных уровня, о которых не принято говорить ... текст свёрнут, показать
     
     
  • 10.89, Совершенно другой аноним (?), 17:04, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже даже 3... текст свёрнут, показать
     
  • 9.87, Анолинукс (?), 17:00, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там в 1990 году, скорей всего вопрос стоял по другому Работающая упрощенная неи... текст свёрнут, показать
     
     
  • 10.90, Совершенно другой аноним (?), 17:12, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    если быть честным, то Minix тоже работал хотя тогда была гораздо более слабая в... текст свёрнут, показать
     
  • 7.99, Аноним (98), 18:52, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так изначально и было, емнип даже начиная с 286-го, а потом amd решило - а накуя? - и оптимизировало до двух в amd64. И п#зда xen-у, и понеслось всё на костылях.
     
  • 5.116, JL2001 (ok), 01:57, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Ещё один минус - микроядерный
    > подход более сложный - прийдётся чётко выверять протоколы между всеми компонентами
    > и "Stable API nonsense" уже не очень получится, т.е. что-то поменять
    > уже становится сложнее.

    как вообще (не)стейблАпи соотносится с (микро)ядерностью??? вы можете выкатить два апи для юзерленда - один для всех, второй для дров которые в вашем дереве исходников, и его перекраивать каждый релиз

     
     
  • 6.124, Совершенно другой аноним (?), 10:12, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ещё один минус - микроядерный
    >> подход более сложный - прийдётся чётко выверять протоколы между всеми компонентами
    >> и "Stable API nonsense" уже не очень получится, т.е. что-то поменять
    >> уже становится сложнее.
    > как вообще (не)стейблАпи соотносится с (микро)ядерностью??? вы можете выкатить два апи
    > для юзерленда - один для всех, второй для дров которые в
    > вашем дереве исходников, и его перекраивать каждый релиз

    В том-то и дело, что с точки зрения системы нет такого разделения - драйвера это такие-же процессы, как и другие, и всем доступно одинаковое API. Если говорить про конкретику - например в QNX - есть базовый механизм IPC - Send()/Receive()/Reply() - всё в системе на самом деле обменивается сообщениями, и даже когда Вы говорите open("/home/my_file", O_RDONLY); то на самом деле от Вашего, прикладного процесса, посылается сообщение, в котором закодировано, что надо выполнить операцию открытия такого-то файла и посылает это сообщение соответствующему менеджеру. Определением необходимого менеджера может потребовать посылку других сообщений какому-нибудь "менеджеру менеджеров" который знает, кто за какую часть файловой системы отвечает.

    Т.е. в итоге для каждой компоненты системы, будь то файловый менеджер, сетевой менеджер ещё кто-нибудь, есть чётко определённый набор запросов и ответов. Менеджеры тоже могут общаться между собой (например NFS или SMB, который вроде как файловый, но потом обращается к сетевому). И вот вы добавили что-то дополнительное в запрос. В Linux, как я понимаю, эти доп. признаки обработаются где-то на уровне входа в системный вызов и драйвера про него может даже и не узнают. В QNX надо этот новый флаг добавлять во все соответствующие сообщения, или плодить, как в linux - новые сообщения для open(), new_open(), new_new_open() и придумывать как в динамике определять есть этот new_new_open() или нет . В общем, имхо, много проблем на пустом месте.

     
  • 6.129, Совершенно другой аноним (?), 11:04, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    про Stable API - внутри ядра Linux можно всё менять как угодно, как угодно переделывать взаимодействующие подсистемы - это всё одно большое ядро. В "микроядерном" подходе - каждая из подсистем - это отдельный ВНЕШНИЙ модуль, независимый от других и с чёткими интерфейсами - (если говорить про QNX - какие он сообщения понимает и какие ответы может выдать". Считайте, что каждый раз, когда Вы правите ядра, вам приходится дружно править и весь прикладной уровень - все программы, которые, например, используют данный вызов. Сорри, возможно как-то сумбурно излагаю, но надеюсь, что смысл я смог донести - при микроядерном подходе в прикладной уровень уезжает то, что раньше было в ядре и менять его становится тяжелее. Править приходится всё вместе централизовано. В принципе все более-менее удачные микроядерные системы закрыты и развиваются каждая своей компанией.
     
  • 4.76, Аноним (73), 16:26, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы, господа, говорите конечно все верно только не понимаете что юзкейс этого конкретного JIT-а в ядре - иметь доступ ко всему зоопарку который в привелигированном кольце живет. И то что само по себе это решение совершенно безответственное и некомпетентное с точки зрения безопасности вне зависимости от архитектуры ядра и что подобные васяны среди разработчиков системы способны наговнокодить такое же решение и для микроядра, дай им волю.
     
     
  • 5.77, Анолинукс (?), 16:30, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, JIT-у не место в ядре.
     
  • 2.26, Gogi (??), 12:22, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вместо **** из кустов, надо озвучивать конктретные аргументы, товарищ плоскоземельщик.
     
     
  • 3.29, Аноним (-), 12:28, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вроде философия микроядра в том, чтобы ядро было минималистичным, а не в том, чтобы в ядро всё подряд добавлять, в том числе jit ?
     
     
  • 4.35, Аноним (31), 12:41, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не в него, а рядом с ним. И да добавят и JIT и ты никогда не разберешься безопасно его реализовали или нет.
     
     
  • 5.53, Совершенно другой аноним (?), 13:49, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если оно будет "рядом с ядром" то и сломать что-то в самом ядре уже не сможет, а только то, к чему у него будет доступ, а т.к. суть микроядра - явное разграничение и разбивка на модули - то и заломать оно только самое себя.
     
  • 5.59, Аноним (-), 14:23, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> никогда не разберешься безопасно его реализовали или нет.

    почему? в микроядре мало кода, а чем меньше кода, тем меньше ошибок, недостатков

     
     
  • 6.81, Аноним (73), 16:38, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А каким образом в микроядре с JIT может быть мало кода если там есть JIT?
    Можно мне пример имплементации JIT-а где мало кода?
     
     
  • 7.128, Ordu (ok), 10:47, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А каким образом в микроядре с JIT может быть мало кода если там есть JIT?

    Микроядро, что в этом слове тебе непонятно? Там всё ядро -- это планировщик задач и, может быть, памяти. Всё остальное реализуется процессами, каждый из которых живёт в собственном адресном пространстве. В том числе и драйвер сетевухи. В том числе и стек TCP/IP. И файрволл. И даже отдельные правила файрволла можно вынести в отдельные процессы. И естественно все эти процессы имеют лишь необходимый им минимум привилегий.

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

     
  • 3.78, Аноним (73), 16:33, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    См. пост выше, юзкейс eBPF в ядре для того чтобы использовать их для мониторинга и performance-каунтеров которые в том числе должны иметь доступ к адресному пространству того процесса который ты хочешь мониторить или профилировать. Так что чтобы получить функционал такой же какой сейчас имеется в ядре прыщей в самой замечательной микроядреной архитектуре придется нанизать на нефритовый стержень всю изоляцию и безопасность. Что конечно совершенно нельзя делать но совершенно никак не остановит убогоньких девелоперов написать подобное решение даже для микроядерной архитектуры, ведь никто из них никакого понимая безопасности не имеет.
     

  • 1.22, gogo (?), 12:02, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Прочитал заголовок новости и подумал: "что-то долго искали дыру в BPF, давно пора было найти..." )
     
     
  • 2.38, Аноним (31), 12:43, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Одну добавили одну убрали.
     

  • 1.39, 54t45yh (?), 12:46, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как там NetBSD с Lua поживает? А ведь в недавней новости кто-то смеялся про Lua в её ядре.
     
     
  • 2.40, user90 (?), 12:53, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Выбор йазыка несколько удивляет, не больше.
     
  • 2.49, Crazy Alex (ok), 13:26, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я смеялся, и буду. Потмоу что специализированный интерпретатор байткода можно здорово ограничить, и дыр в нём при прочих равных будет меньше, чем если пихать в ядро полный интерпретатор для языка общего назначения, тем более вместе с парсером.

    Впрочем, я вообще предвзят, так как не люблю пермиссивщиков разве что чуточку меньше, чем проприетарщиков, и искренне желаю всем BSD скорейшей смерти.

     
     
  • 3.56, Совершенно другой аноним (?), 14:06, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пока, похоже, BPF-у наоборот дают всё больше и больше возможностей - вон обещали и функции завезти с возможностью замены и памяти добавить, так-что это дело, похоже, наживное. В самом LUA понятия указателя нет - вроде как полезть куда попало так-сразу тоже не получится. Поддержка байт-кода, вроде там тоже какая-то была.. если не путаю, да и jit тоже был, правда сторонним проектом.
     
  • 3.62, Анонас (?), 14:47, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Действительно. Вместо зрелого проверенного продукта с 27-летней историей, отличной кастомизацией, высокой скоростью работы, большим сообществом программистов возьмем да слепим свой велосипед. Ох уж эти кернел хакеры.
     
     
  • 4.79, Crazy Alex (ok), 16:35, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Учитывая, что то, что они делают, у кернел хакеров получается хорошо - не вижу причин им не доверять. Ресурсов им явно хватает, а раз так - смысл брать универсальное решение, когда можно сделать специализированное? Разного рода "большие сообщества" здесь только во вред, так как получается амёба вместо хорошо спроектированного продукта с понятными задачами. Что до возраста и прочего - ну так и эта штука созреет, главное что архитектурно это более осмысленный вариант.
     
     
  • 5.111, Аноним (111), 21:36, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А теперь перечитай новость. Ну как, хорошо?
     

  • 1.47, PnD (??), 13:10, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    unprivileged_bpf:
    CVE-2017-16996,CVE-2017-16995,CVE-2020-8835,...
    Ничего не забыл?
     
  • 1.69, Аноним (69), 15:49, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    выход за пределы буфера из-за ошибки в вычислении границы буфера...
    штош, они хотя бы попытались
     
  • 1.71, Аноним (71), 16:16, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > запретить выполнение BPF-приложений непривилегированными пользователями

    А можно пример такого приложения? Которое выполняется такими пользователями...

     
     
  • 2.85, Нанобот (ok), 16:59, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    допустим, веб-сервер, который принимает соединения с одних адресов и не принимает с других, да так, чтобы соединения с неправильных адресов фильтровалось на уровне ядра и не доходили до веб-сервера. раньше такое делали на файрволе (т.е. требовались root-права), сейчас можно делать в самом приложении (теоретически). в качестве дополнительного бонуса - возможность менять список адресов прямо через веб-интерфейс того же веб-сервера.

    или ssh-сервер, который сам банит по айпи после десяти неудачных попыток. без добавления своих правил в файрвол.

     
     
  • 3.92, Аноним (92), 17:24, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хороший бот ( теоретически :) .
     

  • 1.95, soarin (ok), 17:43, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Решил проверить Opennet на безопасность.
    Emoji нельзя в пароль вводить. Вот вам и секурность 😮
     
  • 1.100, Вебмакака (?), 18:56, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    И вот опять баг с буфером подбросили в ядро враги. Настоящие сишники-разработчики ядра никогда не совершили бы такой детской ошибки.
     
  • 1.101, Аноним (101), 19:08, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Из серии - включить, ввести sudo bash и пароль суперпользователя, сотворить зло. Какая уязвимость!
     
  • 1.103, Алекс (??), 19:10, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну теперь те, кто обкакивал Убунту из за ошибки ядра извинятся? Дурацкий вопрос, конечно нет!
     
  • 1.120, Аноним (121), 06:05, 01/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Уязвимость присутствует в подсистеме eBPF, позволяющей запускать обработчики для трассировки, анализа работы подсистем и управления трафиком, выполняемые внутри ядра в специальной виртуальной машине с JIT.

    Там где JIT - там дыра!

    Ох не даром собираю ядра без BPF.

     
     
  • 2.127, Аноним (127), 10:43, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Там где JIT - там дыра!

    Там где нет JIT - там две дыры в самом софте! Без дыр - никуда...

     
     
  • 3.136, Аноним (136), 10:16, 02/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Там где нет JIT - там две дыры в самом софте! Без дыр - никуда...

    Если нет JIT можно запретом выделения памяти в режиме WX отсеять сразу целые классы уязвимостей. Например уязвимости связанные с переполнение буфера невозможно будет проэксплуатировать.

    Наличие JIT дает гарантию возможности эксплуатации некоторых уязвимостей.

     

  • 1.125, ихтамнет (?), 10:25, 01/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Mуз.плэер запилить с брoузером свой не можете, зато ядра фиксят.
     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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