The OpenNET Project / Index page

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

В USB-драйверах из состава ядра Linux выявлено 15 уязвимостей

21.08.2019 22:29

Андрей Коновалов из компании Google обнаружил 15 уязвимостей в USB-драйверах, предлагаемых в ядре Linux. Это вторая порция проблем, найденных при проведении fuzzing-тестирования - в 2017 году данный исследователь нашёл в USB-стеке ещё 14 уязвимостей. Проблемы потенциально могут быть эксплуатируемы при подключении к компьютеру специально подготовленных USB-устройств. Атака возможна при наличии физического доступа к оборудованию и может привести как минимум к краху ядра, но не исключаются и другие проявления (например, для выявленной в 2016 году похожей уязвимости в USB-драйвере snd-usbmidi удалось подготовить эксплоит для выполнения кода на уровне ядра).

Из 15 проблем 13 уже устранены в актуальных обновлениях ядра Linux, но две уязвимости (CVE-2019-15290, CVE-2019-15291) остаются неисправленными в последнем выпуске 5.2.9. Неисправленные уязвимости могут привести к разыменованию указателя NULL в драйверах ath6kl и b2c2 при получении некорректных данных от устройства. Из других уязвимостей можно отметить:

  • Обращения к уже освобождённым областям памяти (use-after-free) в драйверах v4l2-dev/radio-raremono, dvb-usb, sound/core, cpia2 и p54usb;
  • Двойное освобождение памяти (double-free) в драйвере rio500;
  • Разыменования указателя NULL в драйверах yurex, zr364xx, siano/smsusb, sisusbvga, line6/pcm, motu_microbookii и line6.


  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: В USB-стеке ядра Linux выявлено 14 уязвимостей
  3. OpenNews: Представлена техника атаки, позволяющая шпионить за соседними USB-устройствами
  4. OpenNews: Атака на заблокированный ПК через USB
  5. OpenNews: Уязвимость в ядре Linux, позволяющая запустить код при подключении USB-устройства злоумышленника
  6. OpenNews: Новый вид атак с использованием перепрограммированных USB-устройств
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51333-usb
Ключевые слова: usb, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, n1rdeks (ok), 23:48, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    никогда такого не было, и вот опять...

    P.S. Кто на С умел писать - умер, вот и имеем.

     
     
  • 2.7, Аноним (7), 00:07, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > никогда такого не было, и вот опять...

    Ну, ха-ха. Ну, смешно пошутил. Наверно.

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

     
     
  • 3.25, Аноним (25), 01:29, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Странно, что родственники или правообладатели не включили доильный аппарат.
     
  • 3.27, Аноним (27), 02:02, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    >...такое впечатление, что народ уже забыл когда уместно применять эту фразу и лепит ее где ни попадя.

    никогда такого не было, и вот опять...

     
  • 3.72, Ordu (ok), 19:46, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > народ уже забыл когда уместно применять эту фразу и лепит ее где ни попадя.

    Эхх... Вот уже старпёры начинают ныть о том, что в 90-х высказывания Черномырдина были зеленее, и Солнце ярче. Как время летит.

    Я очень рекомендую почитать на досуге [1], оно может не совсем в тему, но по-моему должно провоцировать появление некоторых мыслей, которые очень полезны, если загнивающий язык порождает дискомфорт и тревожность.

    [1] https://www.theguardian.com/science/2019/aug/15/why-its-time-to-stop-worrying-

     
  • 2.40, пох. (?), 09:49, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Б-г не может умереть.

    А остальные и не умели.

     
     
  • 3.49, Аноним (49), 11:10, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Бог ушёл туда, куда уходят боги.
     

  • 1.2, Аноним (2), 23:49, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    А вот если бы было ядро переписали на Rust...
     
     
  • 2.13, Аноним (13), 00:31, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    То был-бы Linux, написанный на си, у которого есть драйвера, сообщество и будущее. И был бы Rustomanix, у которого нет всего этого.
     
  • 2.21, leap42 (ok), 01:11, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    кто? сишники никогда на Rust не перейдут (я вам как сишник говорю), как не перешли в своё время на плюсы, а сами растоманы пока ни одного проекта серьёзного не сделали (чтобы только Rust, без unsafe, чтобы сам проект был со значительной кодовой базой и чтобы с тысячами пользователей).
     
     
  • 3.22, Анон Багоев (?), 01:22, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    CSS рендер Firefox написан на расте.
     
     
  • 4.24, leap42 (ok), 01:29, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    кому "CSS рендер Firefox" нужен кроме Firefox? это не проект, а часть проекта Firefox.

    я специально написал: "только Rust".

    Rust в Firefox чуть больше 5%, если кто-то не в курсе

     
     
  • 5.46, Весельчак У (?), 10:56, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    DNS сервер cloudflare написан на rust (который 1.1.1.1 и самый быстрый). Но ретроградам вроде вас ничего не доказать.
     
     
  • 6.47, anonymous (??), 11:04, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И што, таки можно уже поставить себе на файлопомойку ваш этот растовый DNS? Нет? Ну так что вы тогда мне мозг мозолите?
     
  • 6.50, leap42 (ok), 11:17, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > DNS сервер cloudflare написан на rust (который 1.1.1.1 и самый быстрый). Но
    > ретроградам вроде вас ничего не доказать.

    чтобы доказать нужны доказательства, а не спекуляции!

    то, что в проекте 1.1.1.1 используется trustdns либа, это лишь утверждение одного человека, кода никто не видел. а ещё по его утверждению там используются приложения на Go и nginx, так что вообще не рядом.

     
  • 6.71, Анонимус_ (?), 17:43, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Самый быстрый 127.0.0.1. Все остальное - жалкое подобие правой руки.
     
  • 3.23, имя (ok), 01:28, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > пока ни одного проекта серьёзного не сделали (чтобы только Rust, без
    > unsafe, чтобы сам проект был со значительной кодовой базой и чтобы
    > с тысячами пользователей).

    ripgrep, который is faster than $insert_your_grep_here, уже рекламируется огромной пользовательской базой из каждого утюга. Куча кода в нём и regex crate, unsafe-а мало, да и тот практически весь в C-интерфейсе для тех, кто хочет ржавые регексы использовать в других языках (ну, ок, ещё в месте совокупления rg и pcre для тех, кто без патологического бектрекинга жить не может, но можно легко скомпилироваться без него и получить pure rust). Ещё отмазы будут?

     
     
  • 4.28, leap42 (ok), 02:05, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ok, спасибо добрый аноним, буду знать: проект есть (хотя про "огромную" звучит конечно как шутка - в лучше случае 1% от всех пользователей grep)

    на 100000 Rust евангелистов нашелся 1 проект, отлично. но консольная утилита, это не тот уровень, который позволит переписать Linux, даже не близко.


    про отмазу не понял.

     
     
  • 5.53, Аноним (53), 11:49, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    FYI: ripgrep пользует VS Code, и на винде тоже. Так что, опосредованно его юзает куда больше 1%.
     
  • 4.62, Олег (??), 16:33, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ripgrep, который is faster than $insert_your_grep_here

    Где сравнения? Что за бред... Т.е. возможности те же и он быстрее? Не поверю. Что rust преобразуется в какой-то "особенный" машинный код, который не известен Си компилятору?

     
     
  • 5.63, имя (ok), 16:37, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> ripgrep, который is faster than $insert_your_grep_here
    > Где сравнения?

    https://blog.burntsushi.net/ripgrep/

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

     
     
  • 6.64, Олег (??), 16:56, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чудо, ты само-то читало то, что там написано?

    Оно быстрое - да. Но не потому, что rust такой волшебный, а потому, что они там нахакали либу regexp, сдобрив её simd-инструкциями вручную. Блин, может, поэтому у rust хреново с переносимостью :-)... Такие же точно правки можно сделать для libc regexp и напичкать x86-специфичными хаками. Будет очень быстро, но только на x86 работать. И нафига оно надо?

     
     
  • 7.65, имя (ok), 17:15, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Оно быстрое - да. Но не потому, что rust такой волшебный

    А никто и не говорил, что он быстрый [I]благодаря[/I] Rust. Ты сам успешно спутал в своей голове два разных вопроса («есть ли жизнь на Rust?» и «кто сказал, что ripgrep быстрый?»).

    > потому, что они там нахакали либу regexp, сдобрив её simd-инструкциями вручную.
    > напичкать x86-специфичными хаками

    То есть оптимизацию алгоритмов Бойера—Мура и Ахо—Корасика, unicode-aware конечные автоматы и использование mmap только там, где это выгодно, ты успешно пропустил. Говорил же, что многабукав.

    Более того, тот же memchr в glibc уже давно напичкан SIMD-хаками под все мыслимые архитектуры. Что переносимости не мешает совершенно, как и не мешает rg использовать Ахо—Корасика там, где нет нужных инструкций.

    Лучше бы вы над переносимостью PCRE JIT плакали, но вы и этого делать не будете, потому что вам переносимость только в комментах на опеннете нужна.

     
     
  • 8.73, Олег (??), 17:10, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и разобрались Спасибо за ссылку Занимательное чтиво Авторам уважуха за пр... текст свёрнут, показать
     
  • 3.29, Аноним (29), 02:07, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > сишники никогда на Rust не перейдут (я вам как сишник говорю)

    Кстати, почему? Про плюсы слышал, что сишники их переусложнёнными считают, а код на них - неочевидным. С растом та же ерунда?

     
     
  • 4.32, Аноним (32), 03:28, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Одна из причин, потому что у Си есть куча компиляторов для очень экзотических архитектур, а у раста только те архитектуры, что поддерживает LLVM.
     
  • 4.41, Аноним (13), 09:49, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что сишники - ретрограды. Они даже на C++ перейти не могут. В архитектуру и ООП они тоже не могут.

    А плюсовикам Rust не нужен без ООП (с наследованием и полиморфизмом, без них целый класс шаблонов проектирования невозможен (большая часть шаблонов проектирования не абстрактные вещи, а рецепты достичь чего-то при наличии определённых базовх фич в языке, в Rust этих фич нет), а замены нет, и код превращается в гoвнoкод). Строить суррогат ООП на Rust так же, если не более, гиморно, чем строить суррогат ООП из си.

     
     
  • 5.67, SomeBody (??), 21:55, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты сам то пробовал что-то на Rust написать? Все там замечательно с ООП.

    Но, ты, конечно сможешь привести *конкретные* пример нереализуемых на Rust "шаблонов проектирования не абстрактных вещи". Или нет?

     
     
  • 6.68, red75prim (?), 22:28, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Абстракные фабрики фабрик абстракных фабрик там не особо получаются.
     
  • 3.54, Hewlett Packard (?), 12:51, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вот очень распространенное такое заблуждение про "Rust без unsafe". Не должен он быть без unsafe, да и зачем он был бы такой кому-то нужен. Unsafe блоки - это не для того чтоб их не было, это для того что б их аккуратно огородить и тщательно контролировать. Так же как и side effects в Haskell, например.

    С unsafe в Rust проблемы совершенно другие - в первую очередь, с тем что оно очень плохо стандартизировано. У определенного вида итераторов в С++, например, понятно какие гарантии чего, а в unsafe Rust все очень ad hoc в этом смысле.

     
     
  • 4.66, Аноним (66), 17:15, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    С unsafe у раста все хорошо.
    Есть https://doc.rust-lang.org/nomicon/index.html
    Другое дело что оно не всем надо (там прям в первых двух абзацах это написано).
     
  • 2.45, Аноним (66), 10:46, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно начинать!
    https://github.com/lizhuohua/linux-kernel-module-rust
     

  • 1.3, Аноним (3), 23:54, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > могут быть эксплуатируемы при подключении к компьютеру специально подготовленных USB-устройств

    интересно, КАК они собираются запатчить ядро чтобы защититься от юсб устройств? при каждом подключении любого девайса выводить окно "обнаружена хрень, которая прикидывается клавиатурой, кивните в камеру, если согласны что это клавиатура" ??

     
     
  • 2.8, mickvav (?), 00:07, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Только по честному выпиливать ошибки, другого пути нет. Никто не мешает залить в контроллер нормальной клавиатуры кастомную прошивку, так что кивнуть в камеру - не спасет. Просто фаззинг-тестирование нужно автоматизировать и делать на этапе принятия патчей и новых драйверов в ядро.
     
     
  • 3.15, Аноним (13), 00:34, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как вы себе это представляете, и какова, по вашему мнению, будет скорость принятия патчей?
     
     
  • 4.31, Двойной (?), 02:44, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Как вы себе это представляете

    А я думал что уже даже дети знают про CI.
    > скорость принятия патчей?

    Ну прибавь к операции merge время на выполнение тестов (hint: их можно запускать параллельно).
    Можно жить и без тестов. Только вот тогда возникает другой вопрос какова будет *скорость починки и обнаружения 0-day* по сравнению с CI? И соотносим финансовый и репутационный ущерб от тех же 0-day с затратами на CI инфраструктуру?

     
     
  • 5.58, Hewlett Packard (?), 13:03, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и какой репутационный ущерб нанесли Линуксу все те 0-day что в нем были, есть и будут? Вот вы после каждого CVE везде Линуксы заменяете на L4 или хотя бы на OpenBSD?
     
  • 3.56, Hewlett Packard (?), 12:57, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Фаззинг это рэндомное тестирование, которое ничего не гарантирует.
     
     
  • 4.59, n80 (?), 14:42, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Фаззинг это рэндомное тестирование, которое ничего не гарантирует.

    «ну не човчем»
    Насколько знаю, современные фаззеры (тот же AFL) трассируют выполнение кода, выделяя условные ветвления и базовые блоки. А дальше по полученной информации входные данные строятся не совсем случайным образом, а исходя из максимизации покрытия путей в программе (т.е. 100500 раз ходить по одним и тем же путям, ни разу не посетив другие, никто не будет).
    Не сказать, что эта задача просто (или хотя бы красиво) решается в общем случае, но результаты на реальном коде весьма впечатляют.

     
     
  • 5.74, Аноним (74), 00:01, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, на "Hello world!"... А, иначе: вариантов - бесконечность, как у шахмат.
     
  • 2.12, Аноним (13), 00:27, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Без IOMMU не поможет ничего.
     
     
  • 3.18, n80 (?), 00:46, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Для USB в IOMMU нет необходимости (по крайней мере, толку), кстати говоря. Подключенное устройство само не может инициировать какую-либо активность (и уж тем более обращение к памяти), только отвечать на запросы хоста (которые хост-контроллер переписывает ровно по тем адресам, которые ему выделил драйвер, так что IOMMU, настраиваемый ровно тем же драйвером, тут ничего не ограничит дополнительно). Т.е. напрямую полазить где не надо — невозможно, только скормить кривому драйверу такой ответ, от разбора которого у драйвера улетит кукушка.
     
     
  • 4.43, Аноним (13), 09:54, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за прояснение.
     
     
  • 5.75, Аноним (74), 00:03, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Поблагодарте и за дезинформацию... ("забыты" дыры в контроллере)
     
  • 2.36, Аноним (36), 05:43, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    поддерживаю первого отвечающего.
    не от usb устройств нужно защищаться, а от некорректных ответов от них. если бы была валидная проверка на переполнение буферов, на то что мы прочитали столько байт, сколько запросили, на то что строка не содержит символ '\0', и т.д. не было бы такой проблемы - драйвер бы ругнулся в dmesg что при работе с устройством возникли проблемы и не было бы уязвимостей.
     
     
  • 3.55, Hewlett Packard (?), 12:55, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И эта проверка проверяла бы вообще все, строго согласно спецификации, и не содержала ошибок, и была бы написана на Coq вместо Си - тогда может быть.
     
     
  • 4.76, Аноним (76), 00:06, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ...А, может и не быть. В 99% случаев даже скорей.
     
  • 2.51, Аноним (51), 11:22, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да, например при подключении МФУ в определенный момент он может сказать, что он есть сканер. А у сканера точно могут быть кнопочки. И что каждый раз кивать в камеру?!!!
     
     
  • 3.77, Аноним (77), 00:09, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем, МФУ за вас и кивнёт...
     

  • 1.4, Аноним (4), 00:04, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Атака возможна при наличии физического доступа к оборудованию и может привести как минимум к краху ядра

    Скучно. При наличии физического доступа любой бухгалтер сумеет дёрнуть штепсель.

     
     
  • 2.17, имя (ok), 00:41, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скучно, если диск нешифрованный… а, он и так у всех нешифрованный. Ладно, тогда так:

    Если дёрнуть, то атакующий уже никогда не узнает, какую порнуху ты смотрел в приватных вкладках браузера.

     
  • 2.19, n80 (?), 00:51, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Некоторая разница есть. Вилку из розетки можно выдернуть ~только в тот момент, когда за неё тянешь.

    А вот устроить DoS в наиболее подходящий момент с помощью заранее подкинутого копеечного устройства (которое может хоть годами работать и не выдавать своей второй натуры) — совсем другое дело.

    В случае с розеткой сделать отложенный DoS, конечно, тоже возможно, но заметно сложнее и дороже. А если нужно не только DoS, а и потерю (или даже повреждение) данных, или вообще RCE — тут всё-таки USB даёт дополнительные возможности.

    Так что не просто так изучают такие атаки, не просто так.

     

  • 1.5, Аноним (5), 00:04, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Удалить драйвера, да и дело с концом!
     
     
  • 2.9, mickvav (?), 00:10, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потом вам прилетит обновление ядра и драйвера зальются заново. Только блэк-лист в modprobe.conf спасет великого комбинатора.
     
     
  • 3.20, аноним3 (?), 01:09, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    не спасет. они их той же modprobe подгрузит когда у него закончатся идеи по паеребросу файлов с устройства на устройство)))
     

  • 1.10, Аноним (10), 00:14, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    USB вообще не нужон, пора на pci-e переферию делать
     
     
  • 2.11, maximnik0 (?), 00:27, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >USB вообще не нужон, пора на pci-e переферию делать

    Так уже давно выпускают, в чем проблема купить -цена?
    Или просто сказать умную вещь хотел?
    Кстати насчёт ненужности юсб:в интерфейсе Thunderbolt 3-й версии используется разъём USB Type-C.

     
     
  • 3.14, maximnik0 (?), 00:33, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Добавлю ,согласно вики 4 версия юсб будет фактически Thunderbolt 3,права на это порт переданы консорциуму Usb Forum.
     
     
  • 4.39, Аноним (39), 09:31, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что новый разъём не будет уметь тогда?
     
  • 2.16, Аноним (16), 00:35, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Угу чтобы любое дежице имело доступ ко всей памяти. Хороший план.
     
     
  • 3.30, Аноним (-), 02:21, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Этот план уже однажды успешно провернули под кодовым названием "FireWire/1394". "Backdoorbolt" всего лишь готовится заступить на смену.
     
  • 3.33, maximnik0 (?), 05:11, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Угу чтобы любое дежице имело доступ ко всей памяти.

    Ну вообще-то в спецификациях заложено изоляция DMA посредством IOMI ,другое дело что на это дело производители опереционок и железа забили болт.

     
     
  • 4.34, maximnik0 (?), 05:17, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    IOMI правка IOMMU.
    #Корректор гугловский шибко умный
     
     
  • 5.42, Аноним (13), 09:54, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >IOMMU

    Так он есть далеко не у всех.

     
     
  • 6.60, n80 (?), 14:48, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>IOMMU
    > Так он есть далеко не у всех.

    И мало того, что не у всех он есть, так его ещё и настроить (и не накосячить при этом) — то ещё развлечение. А при этом надо ещё и производительность не угробить: если прибить адреса буферов для DMA гвоздями, сильно усложнится реализация т.н. подхода zerocopy сразу в память приложений и из неё, а если постоянно перенастраивать — легко накосячить.

     

  • 1.35, Аноним (27), 05:23, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Идея монолитного ядра для универсальной ОС в 21 веке идиотизм.
     
     
  • 2.37, Аноним (36), 05:46, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    где монолит?
     
     
  • 3.70, Аноним (70), 15:28, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.youtube.com/watch?v=G5Kl7IsDano
     
  • 2.38, anonymoussssss (?), 08:49, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как видите GNU/Hurd не взлетел и совсем не развивается (или я ошибаюсь?)
     
  • 2.48, anonymous (??), 11:10, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты опять выходишь на связь, Таненбаум?
     

  • 1.44, б.б. (?), 10:06, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    rtsx_usb когда-нибудь пофиксят? уже давным давно в ядре рабочий драйвер заменили нерабочим, и делают вид что так и надо
     
     
  • 2.52, пох. (?), 11:33, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    сразу после rio500

    это ж впопенсорс, тебе никто ничего не должен - в том числе и не ломать что работало.

     

  • 1.57, Аноним (57), 13:01, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    О, шансы взломать телефон с занлючившим пинкодом повысились :)
     
     
  • 2.61, n80 (?), 14:52, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > О, шансы взломать телефон с занлючившим пинкодом повысились :)

    Мысль интересная, конечно (особенно с т.з. получения рута на нынешних нездорово огороженных аппаратах). Но не у всякого телефона есть USB Host или полноценный OTG (да ещё и включённый по умолчанию), да и драйверы для внешних устройств почти никогда не кладут в прошивку. Так что упс.

     

  • 1.69, Аноним (69), 13:51, 23/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ну что, параноидальная тяга к смене нумерации ядер не дала Торвальдсу автоматической избавлялки от багов. Может быстрей надо номера версий менять? А вдруг ? Действительно, сколько там кода от этого Торвальдса ? Хрен да нехрена уже. Его вклад какой? Теперь то уже небось меньше процентика. Может у сообщества поинтересоваться мнением - что лучше номер по круче? или баги научиться находить? Или этот Линус царьком себя мнит, хочу новый номер ядру, хочу Крым, хочу Гренландию. Удачный хотелок Торвальдс!  
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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