The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимости в драйвере к GPU ARM, уже применяемые для совершения атак, opennews (??), 03-Окт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


5. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –6 +/
Сообщение от Аноним (5), 03-Окт-23, 15:11 
А ты прямо сторонник цифровой тюрьмы. Хочешь жить в клетке, понимаю.
Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +5 +/
Сообщение от Аноним (7), 03-Окт-23, 15:17 
> А ты прямо сторонник цифровой тюрьмы. Хочешь жить в клетке, понимаю.

Это ложная дихотомия.

Автор считает, что микроядро этой проблеме не подвержено. В целом он прав.

Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (19), 03-Окт-23, 15:46 
Не на 100% же не подвержено.
Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –1 +/
Сообщение от Иван_Лох (?), 03-Окт-23, 16:28 
Но это дорого стоит. Много сообщений парсить надо. А линукс силен именно там, где лишнее процессорное время либо стоит больших денег, либо его просто нет.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

40. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +3 +/
Сообщение от Аноним (40), 03-Окт-23, 16:54 
>А линукс силен именно там, где лишнее процессорное время либо стоит больших денег, либо его просто нет.

Я думал всякие bugurtos с RT-Thread лезут туда, где байтом и тактом меньше (а то и заасменные по самое небалуйся os под конкретную архитектуру). А ваш этот линукс туда, куда надо затянуть малыми кучу готового кода - от базы типа coreutils до апчей с нжинксами, а производительность - ну как уж получится.

Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (40), 03-Окт-23, 16:56 
>затянуть малыми

*малыми усилиями
Что тоже неплохо, и такой подход может иметь место.

Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +2 +/
Сообщение от Аноньимъ (ok), 03-Окт-23, 17:03 
> Но это дорого стоит. Много сообщений парсить надо. А линукс силен именно
> там, где лишнее процессорное время либо стоит больших денег, либо его
> просто нет.

Не, это не так работает, производительность в этом всём вопрос десятый.

Вообще как бы нормальная архитектура и так предполагает обмен сообщениями - вызовами.
Задача как-бы в том чтобы отделить память ядра от памяти драйверов(и драйвера друг от друга), сделать участки общей памяти там где нужно и всё, это просто нормальный здоровый подход к архитектуре.

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

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

80. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Анонем (?), 03-Окт-23, 20:33 
Интересно, если микроядерная архитектура ядра такая классная, то почему все сидят-пердят на страшном линуксячем монолите? И никто не предоставляет работающего решения со "здоровой" архитектурой?.. Думайте.
Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +3 +/
Сообщение от Аноньимъ (ok), 03-Окт-23, 21:02 
> Интересно, если микроядерная архитектура ядра такая классная, то почему все сидят-пердят
> на страшном линуксячем монолите? И никто не предоставляет работающего решения со
> "здоровой" архитектурой?..

Если коротко, то ответ - Легаси.

> Думайте.

Сейчас бы найти кого-то кто хоть может читать и писать.

Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –1 +/
Сообщение от Аноним (137), 04-Окт-23, 16:07 
> Если коротко, то ответ - Легаси.

Ну вот ты такой инновационный - начни с себя. И делом покажи чего твои блабла стоят.

> Сейчас бы найти кого-то кто хоть может читать и писать.

Ну уж точно никто не будет слушать теоретиков от системщины которые сами ни 1 драйвера не написали но ценное мнение имеют.

Ответить | Правка | Наверх | Cообщить модератору

150. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 04-Окт-23, 21:33 
Проблема легаси парралельна инновациям, это разные вещи.
Но конечно оно, легаси, мешает последним.

> сами ни 1 драйвера не написали

Щас пойду на расте напишу ченить гениальное, ststemd-graphicsd!
Будете потом очень благодарны.

Ответить | Правка | Наверх | Cообщить модератору

158. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (-), 05-Окт-23, 12:10 
> Проблема легаси парралельна инновациям, это разные вещи.
> Но конечно оно, легаси, мешает последним.

Ну так на чужом горбу все здоровы в рай въехать. Вот обуть бы вас на легаси - и посмотреть что вы с своим трындежом про хаскелы и инновации реально из себя представляете такие красивые. Даже если вот и не мешать, очень интересно, стали бы вы жрать что испекли, или как в реактиси - скрины с виртуалки?

А легаси видите ли имеет наглость отсвечивать в сравнении, "усложняя" - установив барьер ниже которого ползти уже не катит. Поэтому где Linux а где недоразумения типа Redox какое-нибудь. И очень хорошо что в результате можно пользоваться "legacy" Linux а не вот такими "инновациями".

>> сами ни 1 драйвера не написали
> Щас пойду на расте напишу ченить гениальное, ststemd-graphicsd!
> Будете потом очень благодарны.

Мне почему-то кажется что это не страшнее угроз синицы море поджечь.

Ответить | Правка | Наверх | Cообщить модератору

161. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 05-Окт-23, 12:31 
> трындежом про хаскелы и инновации

Хаскель это технологии древних вообще, к инновациям отношения не имеет.

> А легаси видите ли имеет наглость отсвечивать в сравнении, "усложняя" - установив барьер ниже которого ползти уже не катит.

Я не берусь пытаться разобрать что ваше больное сознание пытается сказать. Что-то в духе - "легаси это круто" наверное? Нет не круто. И вы почему-то, снова, мешаете в кучу легаси и инновации.
!!!Легаси код может быть инновационным!!! и очень современным.
Ещё раз, легаси и инновационность - параллельные вещи.

> И очень хорошо что в результате можно пользоваться "legacy" Linux а не вот такими "инновациями".

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

Когда какая-то технология получает развитие, в неё идут огромные инвестиции(в самом широком понимании), на протяжении многих лет, она получает широкое применение, заменить её чем-то другим, допустим лучшим в каком-то измерении, становиться невозможным по социо-экономическим причинам.

Грубо говоря, за 30 лет, или сколько там линуксу, в него инвестировали триллион долларов, на самом деле 5, а то и больше.
Чтобы заменить его за 10 лет на что-то другое, нужно за эти 10 лет минимум инвестировать в новую технологию триллионов 10, на самом деле 20. Это просто невозможно.

Популярная технология либо умрёт вместе с индустрией, либо должно появиться что-то !!на порядки!! лучшее, а не просто лучшее. Обычно происходит первое, а не второе.

Кобол до сих пор используется. А вот вам вообще пустяковая казалось бы вещь:
https://ru.wikipedia.org/wiki/Проблема_2000_года
!!! По некоторым оценкам экспертов общий объём мировых инвестиций, потраченный на подготовку к 2000 году, составил 300 млрд $ !!!

> Мне почему-то кажется что это не страшнее угроз синицы море поджечь.

А лисички
Взяли спички,
К морю синему пошли,
Море синее зажгли.

Ответить | Правка | Наверх | Cообщить модератору

182. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (182), 05-Окт-23, 18:59 
> Хаскель это технологии древних вообще, к инновациям отношения не имеет.

Это технология ... отшибленых на голову академов, имхо. Которые и сами то ей пользуются для себя как-то для галочки, а остальным оно и подавно на... надо.

> Я не берусь пытаться разобрать что ваше больное сознание пытается сказать.

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

> Что-то в духе - "легаси это круто" наверное? Нет не круто. И
> вы почему-то, снова, мешаете в кучу легаси и инновации.

Это скорее вы зело агрессивно клеите лейбаки легаси на то что может влегкую еще и вас пережить, не говоря о ваших "инновациях".

> !!!Легаси код может быть инновационным!!! и очень современным.
> Ещё раз, легаси и инновационность - параллельные вещи.

Хехе, а параграфы могут быть взаимоисключающими.

> Вы спросили почему все используют более плохие технологии вместо более лучших, я вам ответил.

"Более лучшие" это весьма абстрактно. Если перфоманс днище, нифига оно не более лучшее по эксплуатационным параметрам. Которые парят покупателей и эксплуатантов.

> Когда какая-то технология получает развитие, в неё идут огромные инвестиции(в самом широком
> понимании), на протяжении многих лет, она получает широкое применение, заменить её
> чем-то другим, допустим лучшим в каком-то измерении, становиться невозможным по
> социо-экономическим причинам.

Это в чем-то хорошо: вместо продавливания агрессивным трындежом про "более лучшее" и "легаси" вам придется выкатить что-то радикально более хорошее по параметрам вместо бла-бла, чтобы на это обратили внимание. Естественный отбор в действии. Эта фича капиталистов полезна, д@рьмо из мозгов хорошо выбивает. Иначе мы бы сидели на лагучих тормозючих дерганых поделках академов с неодупляемым кодом, зато безопасно. И это было бы хреново по более 9000 иных параметров.

> Чтобы заменить его за 10 лет на что-то другое, нужно за эти
> 10 лет минимум инвестировать в новую технологию триллионов 10, на самом
> деле 20. Это просто невозможно.

С другой стороны - шарахаться на каждый инновационный хайп тоже так то не сильно эффективно по затратам ресурсов. Если все время гнать за идеалом, он недостижим, в результате релиз чего-то юзабельного не случится никогда. Что и наблюдается у всяких гаек-реактосов-редоксов, которые никак не могут это уловить. А Торвальдс вот создал стабильную точку в пространстве-времени. Изучение которой воздается реюзабельным знанием, которое не надо сливать в треш каждый год. И это его жирная фича как платформы.

> Популярная технология либо умрёт вместе с индустрией, либо должно появиться что-то !!на
> порядки!! лучшее, а не просто лучшее. Обычно происходит первое, а не второе.

И это в каком-то роде самобалансировка, самозащита и желание получить что-то хорошее. Если гонку за идеалом не стопорить - она не остановится никогда, а сотни ресурсов будут слиты на погоню за своим хвостом. И как максимум получится реактос какой-нибудь, где кернел три раза переписали во имя луны. В результате 2 десятилетия спустя оно так и глюкавит даже в виртуалочке, а на железе вообще ни о чем. А вы думали, сливать сотни наработок других кодеров это просто так? А вот и фиг. Во первых, за это вам никто не будет комитить, никто не хочет пахать на мусорный бак. Во вторых это мощный якорь в развитие проекта.

Господа норовящие все до основанья а затем, во имя луны - крайне деструктивны для разработки софта, выпуска чего-то работающего, и вообще "getting things done". Если следовать их идеям, они все разнесут в хлам а ничего юзабельного вообще не появится.

> Кобол до сих пор используется. А вот вам вообще пустяковая казалось бы вещь:
> https://ru.wikipedia.org/wiki/Проблема_2000_года

Он однако стал довольно нишевым знанием.

> !!! По некоторым оценкам экспертов общий объём мировых инвестиций, потраченный на подготовку
> к 2000 году, составил 300 млрд $ !!!

И что? Это включало в себя далеко не только Cobol. Ничего что BIOS у кучи компов год трекал как 99 -> 00 и 00 там означало так то 1900? Кобол ну вообще не уникален в этой грабле, ее в софте и харде было очень даже :)

>> Мне почему-то кажется что это не страшнее угроз синицы море поджечь.
> А лисички Взяли спички, К морю синему пошли, Море синее зажгли.

Ну вот когда и если, тогда и...

Ответить | Правка | Наверх | Cообщить модератору

184. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 05-Окт-23, 19:45 
> Это скорее вы зело агрессивно клеите лейбаки легаси

Вы говорите с бесами у себя в голове. И не замечаете этого.

> на то что может влегкую еще и вас пережить

Так это как бы серьёзный индикатор того что это легаси.
Кобол и вас переживет например.

Ответить | Правка | Наверх | Cообщить модератору

128. Скрыто модератором  +1 +/
Сообщение от 123 (??), 04-Окт-23, 10:42 
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

142. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 04-Окт-23, 17:42 
>  то почему все сидят-пердят на страшном линуксячем монолите?

Кто-то на винде сидит.
Винда довольно успешно перезапускает упавший драйвер видеокарты.
Для неё вообще не проблема переткнуть видеодрайвер на лету без остановки работы окружения.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

159. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (-), 05-Окт-23, 12:12 
>>  то почему все сидят-пердят на страшном линуксячем монолите?
> Кто-то на винде сидит.
> Винда довольно успешно перезапускает упавший драйвер видеокарты.
> Для неё вообще не проблема переткнуть видеодрайвер на лету без остановки работы
> окружения.

Я и заметил - вооооое там при апдейте винды интеграшка встала колом. И все, что хотите то и делайте. Не то чтобы это вообще совсем не работает - курсор, вот, катать можно. Но в целом GUI встрял. Да так что апдейт системы закончиться не может. Инновационно, теперь апдейт графики нагибает апдейты.

Куда вот линуху до такого. Ни разу не видел чтобы от апдейта MESA или Kernel графика бы так в корчах подохла.

Ответить | Правка | Наверх | Cообщить модератору

171. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 05-Окт-23, 15:23 
Винда какая?
Курсор работает значит драйвер подхватился. Окружение оконное сдохло видимо. Это печально конечно.

С линуксом подобное часто наблюдаю в ситуациях нехватки памяти наверное. Хотя и со свопом тоже. Виснет бывает всё кроме курсора, что на убунте что на арче.

Затык по IO ещё такое вызывает. Если нужно дисковый кеш сбрасывать в условиях memory pressure. Так и не смогли на Линуксе ничего с этим поделать.

Ответить | Правка | Наверх | Cообщить модератору

183. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (-), 05-Окт-23, 19:25 
> Винда какая?

Это восьмая так, там походу апдейченые дрова GPU в апдейтах были. Оно и изобразило "пытался совершить посадку самолет номер 13...". Я понимаю что у интеля GPU глюкавые, но в линухе вот именно чтобы графика раком встала от скажем новой MESA - так все же не бывает, причин нет особо. Уже запущенные проги продолжат старую юзать. Новые заюзают новую, а ядру в разумных пределах пофигу на ее версию. А эти видимо что-то хитрож@пое попробовали, и это не прокатило.

> Курсор работает значит драйвер подхватился.

Насколько я помню, курсоры нехило подперты железом, это чуть ли не отдельный plane в который он рисуется. И то что там небольшой кусочек железки и фрагментик софта работает с вот этой частью - довольно мало чего говорит остальном.

> Окружение оконное сдохло видимо. Это печально конечно.

Ну может быть. Я не знаю как такое в винде диагностировать. В линухе - там я амдшному драйверу пару раз устраивал траблшутинг, с бисектами аж, стал вести себя изумительно на моих железках (а заодно и чьих то еще). И теперь алилуя, у меня дрова которые МЕСЯЦЫ аптайма выдерживают. В винде оно дурело куда быстрее, это уже на амдшках, там через 2-3 недели локап был как с куста. А тут - можно что угодно делать, пашет себе, а единственный повод ребутов это ядро обновить.

> С линуксом подобное часто наблюдаю в ситуациях нехватки памяти наверное. Хотя и
> со свопом тоже. Виснет бывает всё кроме курсора, что на убунте что на арче.

Ну вот при именно апдейте именно компонентов видеодров на такое нарваться в лине довольно сложно, во всяком случае во время инсталла апдейта - точно, предпосылок нет.

> Затык по IO ещё такое вызывает. Если нужно дисковый кеш сбрасывать в
> условиях memory pressure. Так и не смогли на Линуксе ничего с этим поделать.

А как его сбросишь если графон ни на что не реагирует? Это ж не линь с REISUB. Да и не было там вроде pressure никакого, хард мигать перестал, а графон так и не отпустило. Ну, пришлось его вырубать жестко, poweroff'ом. Драйвер при этом оказался в каком-то полурабочем состоянии и пришлось трахаться с поиском более адекватной версии на сайте интеля, которая таки заинсталлилась и работала, только полдня вот профачилось на какой-то левак на ровном месте. Майкрософт хотел как лучше, конечно, а получилось не очень.

Ответить | Правка | Наверх | Cообщить модератору

138. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (180), 04-Окт-23, 16:14 
>> Но это дорого стоит. Много сообщений парсить надо. А линукс силен именно
>> там, где лишнее процессорное время либо стоит больших денег, либо его
>> просто нет.
> Не, это не так работает, производительность в этом всём вопрос десятый.
> Вообще как бы нормальная архитектура и так предполагает обмен сообщениями - вызовами.

Угу, только потом производительность такая получается что никто это использовать не хочет. Как максимум нате вам зонд ME - ему производительность похрен, юзеру и его коду же не дают туда доступ, а используется лишь эпизодически.

> Задача как-бы в том чтобы отделить память ядра от памяти драйверов(и драйвера
> друг от друга),

Ведет к жесткому залету по перфомансу и в случае GPU к падению FPS в разы - потому что CPU готовит для GPU данные, а тот обсчитывает. Любой барьер на пути этих гигов в секунду резко угробит FPS. И никому оно будет не надо такое, увы и ах.

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

Перфоманс у этого потом очень нездоровый получается и оно будет где-то рядом с hurd, или как максимум - в зонде типа ME, но уж точно не в оси общего назначения, где эксплуатационные свойства не пустой звук.

> Ну недолжно быть такого чтобы выход за пределы буфера в дровах позволял
> выполнять произвольный кот в ядре.

Это вы еще не видели что DMA могет. А там вообще так то достаточно неверный адрес в его регистры вфигачить и он убьет все живое, на его пути даже MMU так то нет. Может IOMMU, если сильно повезет. И то где как и от конкретики зависит.

> Они котом вообще не должны быть связанны, только данными, и только в нужных местах.

Ога, и получите вы на топовом железе FPS примерно 5. Вас и вашу ось сотрут к чертям, на этом и закончится ваша безопасность.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

140. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 04-Окт-23, 16:59 
> Perfomance перфоман ПЕрфОМанс перрррррфроманс!
> FPS fps FFPS F! P! S!

Да понял понял я, всё будет хорошо.

> Ведет к жесткому залету по перфомансу и в случае GPU к падению FPS в разы - потому что CPU готовит для GPU данные, а тот обсчитывает. Любой барьер на пути этих гигов в секунду резко угробит FPS. И никому оно будет не надо такое, увы и ах.

Шина PCI-E это у вас не барьер? Ну готовит ЦП данные для ГП, что дальше? Барьеры где особые какие-то в микроядре? Оно то тут причём?

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

Ответить | Правка | Наверх | Cообщить модератору

144. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (-), 04-Окт-23, 18:43 
> Да понял понял я, всё будет хорошо.

Да вот не будет как показала практика. Blackberry в свое время много трахались с тем чтобы минимально приемлимый перфоманс вообще выжать. А все равно слились в итоге. Гиморное это дело, микроскопом гвозди забивать.

> Шина PCI-E это у вас не барьер?

Cильно зависит от конкретики. Где вы например PCIe в ARM MALI нашли? Или в APU амдшном. Да, они там кстати умеют играть в интересную игру - sharing региона памяти на двоих, zerocopy получается. Могу себе представить что это не совсем безопасно на самом концептуальном уровне.

> Ну готовит ЦП данные для ГП, что дальше? Барьеры где особые какие-то в микроядре?
> Оно то тут причём?

Оверхеда на границах взаимодействия много. Особенно когда потоки в гигах в секунду измеряются, там идет всякий zerocopy во все поля и всякие читерства. В том числе и вещи типа вот именно перекидывания указателей на регион вместо копирования региона. И это уж точно не безопасная операция, если в адресах лохануться. Но переключить указатель на гиг это 8 байтов. Скопировать гиг - таки это гиг. И совсем другие времянки.

> Вы же в курсе что игра, я так понимаю вы игроман, игролюб,
> игроэксперт? Готовит данные для ГП у себя, в памяти юзерспейса вообще.

Я не игроман - но ничего против хорошей графики не имею. А приличный поток данных может быть и на GPGPU-вычислениях, или скажем от видеоплеера какого, да и кад 3D рендер какой дать не дурак и совсем не круто если это тормозит. В общем все что юзает GPU генерит ломовые объемы на раз. Не, извините, на 640x480x16 цветов где и микроядрам нормалек никто не вернется.

Ответить | Правка | Наверх | Cообщить модератору

148. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 04-Окт-23, 21:15 
Так приложение в юзерспейсе не в ядре живёт или в ядре?
Небезопасно или безопасно?
Если не в ядре то как так получается что ФПС нормальный и всё прекрасно работает?

> Это читерства безопасность не безопасность

Ну и зачем тогда вообще разделения делают если всеравно небезопасно?

Запускать игру сразу в ядре чтобы всё было производительно.

> шеринг памяти zerocopy

Ну хорошо что вы хоть такие вещи знаете.

> Нужновсевядре иначе гигабайты в секунду

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

Ядру может быть нужно только текст в консольку выводить, и делает оно это через двайвер консоли.

Ответить | Правка | Наверх | Cообщить модератору

165. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (-), 05-Окт-23, 13:46 
> Так приложение в юзерспейсе не в ядре живёт или в ядре?

1) Приложение != драйвер видяхи и как правило гигазы данных в секунду не неворачивает, кроме оооооочень редких исключений.
2) А те которые все же наворачивают - там в тренде как раз странные штуки типа io_uring. Это весьма забавный интерфейс, но вот настаивать что это безопасно... это весьма деликатная игра с zerocopy и это оооооочень тонкая граница. Но когда вопрос чтобы смолотить в N раз больше данных на том же железе - юзеры, девы и корпы готовы на многое.

> Небезопасно или безопасно?

Это на самом деле сложный вопрос.

> Если не в ядре то как так получается что ФПС нормальный и всё прекрасно работает?

Таки в случае графики ключевые компоненты - обычно в ядре. А винды для перфоманса в ядро аж весь GDI загнали, вот тупо все апи в win32k.sys вперли. До этого в юзермоде было - и все юзали Win95 вертев на ... весь расово верный WinNT и академконцептуалов вместе с ним.

>> Это читерства безопасность не безопасность
> Ну и зачем тогда вообще разделения делают если всеравно небезопасно?

По факту - получилась такая весьма деликатная игра на грани фола и кайф в том чтобы эту грань не пересекать, сделав и шустро и безопасно. А жить в глубоком подземном бункере - и так постоянно - ну и насколько так большинства людей хватит? Секурити - это хорошо и правильно. Но не должно зарубать применения систем и портить все в разы. И сложно все становится как раз потому что это почти взаимоисключающие параграфы. И приходится инженерам придумывать как стыковать взаимо-противоречивые хотелки. Ясен фиг с переменным успехом.

> Запускать игру сразу в ядре чтобы всё было производительно.

Во времена DOS примерно так и делали. И это было проще всего если что. Но там свои анноянсы были. В частности если гамеза локапнется - вы таки пойдете на ресет жать, вообще без вариантов. А вот это уже не совсем удобно. Да и монопольная узурпация всех расурсов - определенные нюансы создает. Тем не менее сейчас так могут фирмвары МК делать и они так то могут быть сильно безопаснее ОС общего применения - в силу небольшого объема тривиального кода. Да, это заход к проблеме с совсем другой стороны. А кто сказал что есть только 1 способ?

>> шеринг памяти zerocopy
> Ну хорошо что вы хоть такие вещи знаете.

Ага, а ваши сообщения и ко - по сути антипод всему этому. И очень сильно перфоманс убивают. Вы кажется не понимаете какие вещи ща народ хочет в data path при скоростных вычислениях, суперскоростном IO, или даже вот гамезах обычных.

>> Нужновсевядре иначе гигабайты в секунду
> Вы понимаете, что ядро никакие гигабайты в секунду в видеокарту не отсылает
> и не принимает, это делает драйвер видеокарты и приложения в юзерспейсе?

Как раз таки это в основном епархия. Как вы себе вообще представляете зарядить какую-нибудь DMA транзакцию из юзерспейса? Да и пускать юзерспейс в DMA-capable железку от и до - ни разу не безопасно.

> Ядру может быть нужно только текст в консольку выводить, и делает оно
> это через двайвер консоли.

Это какие-то очень примитивные - и отсталые знания о системах. К линуху это совершенно точно не относится, там DRM/KMS/GBM это как раз о том чтобы ядро занялось тем чем должно было, т.е. менеджментом памяти (в т.ч. и GPUшной), переключением видеорежимов и проч. А лазание в железку у иксов давно забрали, сделав их "одним из клиентов вон тех подсистем". В винде так вообще все GDI в ядро выносили, не размениваясь на вон те мелочи. Ессно для перфоманса. А так в юзермоде в основном высокоуровневый код типа компилеров шейдеров и тому подобного добра.

Ответить | Правка | Наверх | Cообщить модератору

175. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 05-Окт-23, 15:43 
> 1) Приложение != драйвер видяхи и как правило гигазы данных в секунду
> не неворачивает, кроме оооооочень редких исключений.

В смысле не наворачивает? У нас же приложения в конечном счёте видеокарту используют, или блин не используют?

Приложение гигазы данных не наворачивает, откуда они тогда берутся эти гигазы данных с которыми ЖП работает?

> Ага, а ваши сообщения и ко - по сути антипод всему этому.

В каком это месте?
Без зерокопи всё печально не только с микроядром но и вообще.
Даже у сетевых карт. Из за чего изерспейс дрова с ойпи стеком делают некоторые.

> том чтобы ядро занялось тем чем должно было, т.е. менеджментом памяти
> (в т.ч. и GPUшной), переключением видеорежимов и проч.

И что, для этого нужно гигазы данных куда-то передавать?

Ответить | Правка | Наверх | Cообщить модератору

185. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (185), 06-Окт-23, 07:07 
> В смысле не наворачивает? У нас же приложения в конечном счёте видеокарту
> используют, или блин не используют?

Оно ж не делает вообше все операции лично и микроменеджмент деталей - не юзермодово это. Какие-нибудь текстуры можно вгрузить в VRAM - а если вдруг ее не хватит - упираться там будет уже как я понимаю таки кто-то типа GBM, и таки скорее в ядре, "свопясь" в обычную оперативу. И даже так можно FPS уронить если самое горячее в VRAM не влезло и не рюхается именно на стороне GPU.

А так то draw calls между прочим программу не украшают, вон там у MESA оверлей есть, который показывает сколько draw calls прога фигачит. В OpenGL дергания программы это как раз больщая проблема если она батчить операции не допирает, FPS уходит в плинтус. Vulkan получше, но там как раз все про минимальный оверхед, а это не о микроядрах.

> Приложение гигазы данных не наворачивает, откуда они тогда берутся эти гигазы данных
> с которыми ЖП работает?

Могут и из VRAM могут браться. Или даже системной RAM, GBM в лине позволяет аллоцировать больше чем VRAM есть и будет "свопиться" в обычную оперативу, конечно ценой потери скорости.

>> Ага, а ваши сообщения и ко - по сути антипод всему этому.
> В каком это месте?
> Без зерокопи всё печально не только с микроядром но и вообще.

Плохо себе представляю сочетание message passing, zerocopy, микроядер, низкого оверхеда и безопасности. И сказ про перезапуск дров... может выдавать тот кто рестарт GPU драйвером никогда не видел. Это как на круизном лайнере хвастаться что у вас замечательные спасательные шлюпки. Лучшая шлюпка - та которая не понадобилась! На круизный лайнер не для этого приходят.

> Даже у сетевых карт. Из за чего изерспейс дрова с ойпи стеком
> делают некоторые.

Делают, но работает это как правило "не очень" по перфомансу. А вон там в _ядре_ меряются кучей mpps на ядро и проч. Ну и в целом в ядерные дрова культуру написания еще немного удается вбивать, а в юзермоде совсем расслабятся с понятным результатом.

> И что, для этого нужно гигазы данных куда-то передавать?

Ессно. В GPU объемы такие. Конечно от конкретики зависит - но в конечном итоге FPS от оверхеда портится на раз, а вулкан крут в основном тем что low overhead - батчить draw calls в GL многие не допирали а они там тяжелые. И вот уже какая-то индюшатина с графоном а-ля майнкрафт тупит круче чем Xonotic на максималках при том что сцены и графон слова доброго не стоят. А если посмотреть у нее просто draw calls в полку, в GL за это отливается.

Ответить | Правка | Наверх | Cообщить модератору

190. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 06-Окт-23, 14:18 
> Ессно. В GPU объемы такие. Конечно от конкретики зависит - но в
> конечном итоге FPS от оверхеда портится на раз, а вулкан крут

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

> Могут и из VRAM могут браться.

Всё что угодно может быть. И в VRAM они просто чудесным образом появляются?
Я вас не понимаю, откуда гигазы данных в ядре берутся которые оно должно в видеодрайвер передавать?
Я что-то пропустил в мире айти за последние 10 лет?
У меня вот сейчас линукс, обе видеокарты холодные, ничего в них ни от куда не передаётся. А если игру запустить, то сразу откуда-то нагрузка возникает, должно быть на оборот?

Ответить | Правка | Наверх | Cообщить модератору

191. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 06-Окт-23, 14:30 
> Делают, но работает это как правило "не очень" по перфомансу.

Нехрена себе, а зачем делают если работает не очень? Делать больше нечего людям?
То есть без оверхеда на преодоление барьера юзерспейс-ядро работает не очень. А с барьером работает отлично и меряются кучей mpps?

> Ну и в целом в ядерные дрова культуру написания еще немного удается вбивать, а в юзермоде совсем расслабятся с понятным результатом.

Там те-же самые дрова с вырезанными механизмами ненужными вне ядра, без тех самых барьеров и приколов линуксячего сетевого стека. Может кто-то конечно линуксячий использует, но скорее всего там BSD стек.

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +1 +/
Сообщение от Sw00p aka Jerom (?), 03-Окт-23, 16:29 
>В целом он прав.

ага почти :) иммутабельная выделенная память для микроядра, на отдельном кернель процессоре (ред процессор)

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

136. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –2 +/
Сообщение от Аноним (137), 04-Окт-23, 16:06 
> Автор считает, что микроядро этой проблеме не подвержено. В целом он прав.

1) Вот автору и карты в руки кодить дрова под его любимые микроядра. Можно даже на его любимом хаскеле. Мне почему-то правда кажется что дров он напищет - таки ноль. И будет только ценные указания раздавать, на которые все конечно забьют.
2) А заодно пусть объяснит и как тогда мадам рутковска запускала на ME свой код, раз все так безопасно.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

10. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +1 +/
Сообщение от Аноним (1), 03-Окт-23, 15:24 
ошибся веткой, так что продублирую в правильной

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

интересно было бы выслушать аргументы

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

20. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +1 +/
Сообщение от Аноним (19), 03-Окт-23, 15:48 
Тут аргумент может быть такой: не будет уязвимостей в Ведроиде - не будет возможности зарутовать тело. Некоторые же не дают легальной возможности рута.
Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (1), 03-Окт-23, 15:56 
во-первых, думаю около 98% пользователей дроида это просто нафиг не нужно (они даже таких умных слов как рут и ядро не знают)

во-вторых, те кому это действительно нужно, будет выбирать что-то типа fairphone, Librem 5 и тд
да дороже, зато можно делать что пожелаешь

в третих (возможно!) это подстегнет некоторых производителей использовать открытость рута как маркетинговое преимущество (в сравнении с конкурентами)
можно заливать пользователям про privacy и рассказываться что конкуренты шпионят за ними

Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –1 +/
Сообщение от Аноньимъ (ok), 03-Окт-23, 17:06 
> в третих (возможно!) это подстегнет некоторых производителей использовать открытость
> рута как маркетинговое преимущество (в сравнении с конкурентами)
> можно заливать пользователям про privacy и рассказываться что конкуренты шпионят за ними

Я могу ошибаться, но, похоже что требование невозможности рута идёт от Гугла, или что-то в подобном роде.
Поэтому скорее всего не будут никогда, если только что-то не сдохнет где-то.

Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от фнон (?), 03-Окт-23, 17:26 
не слышал о таком, насколько вижу у пикселей бутлоадер открытый
и рутуется он без проблем с накатывание например линейки

скорее тут комплексная проблема, которая связана с кол-вом пользователей которые вообще не поймут о чем речь:
- производители(вендоры) хотят напихать в телефон неудаляемых апп - тк это доп. копеечка (а среднему юзеру пофиг что у него из коробки фесбучек и вацап, он даже спасибо скажет)
- всякие секурные приложения типа банков не хотят разбираться, как у юзера увели деньги с рутованного девайса, а если есть что-то типа Knox то легче отследить вектор атаки
- если рут сдеать доступным, то есть ненулевая веротность, что в магазине ты можешь купить сразу пропатченный телефон (с дополнительным незаметным функционалом) даже если ты об этом не просил
- система типа "разблочить бутлоадер, подписал своим сертефикатом, закрыл бутлодер" - у среднего пользователя мозг вскипит, даже на xda таким запрариваются единицы

Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 03-Окт-23, 17:52 
> не слышал о таком, насколько вижу у пикселей бутлоадер открытый
> и рутуется он без проблем с накатывание например линейки

Вы мешаете рут, и разблокировку бутлоадера в одну кучу.

Да, разблокированный бутлоадер зачастую позволяет кое как с тройными матами и через пень колоду рутовать родную прошивку. После чего никакие банковские приложения и прочий гуглпей уже не заработают.

А линейка без проблем - это утопия и сказка не из нашего мира. По моему её время вообще прошло... Там ничего нет давно. Темы выпилили. Су выпилили. Камера - какая-то дичь жуткая.

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –1 +/
Сообщение от Анонин (?), 03-Окт-23, 18:10 
У меня вот прям сейчас в руках анлокнутый рутованый ксяоми с LineageOS 20.0 (13 андроид).
С установленным гугл-плей и двумя банковскими приложухами.
И никто про рут ничего не жужжит, всё, чего нет в fdroid, нормально ставится.
В игры, правда не играю, может они за рут банят, хз.
Ставится оно уж точно не сложно, просто идешь по списку и выполняешь команды.

А то, что в линейке чего-то нет.. Ну так это проблемы линейки, а не анлока и рута в целом.
Магиск поддерживается, su забросили его авторы - все претензии к ним.

> Темы выпилили

Ахаха, какая невосполнимая потеря))) Может тебе еще и обои нескучные нужны?

> Камера - какая-то дичь жуткая.

Ставь opencamera или стороннюю какую захочешь.

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 03-Окт-23, 18:15 
> Ахаха, какая невосполнимая потеря))) Может тебе еще и обои нескучные нужны?

Да, нужны.

> и двумя банковскими приложухами
> И никто про рут ничего не жужжит,

Считайте выиграли в лотерею.
А может я что-то пропустил. Гпей работает?

Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –1 +/
Сообщение от Анонин (?), 03-Окт-23, 18:22 
Ну, не в лотерею. Телефон сразу покупался с планом его перепрошить.
Т.е. не на старте и с вычиткой кучи тем на xda в процессе выбора.
И следующий телефон буду подбирать аналогичным способом.

> Гпей работает?

Не знаю если честно. Никогда им не пользовался. Даже не уверен как он работает, поэтому могу сморозить фигню. В телефоне nfc нет. Просто платные приложухи в gplay покупал (но там вроде просто банковская карта подвязана, а не gpay... короче хз)

Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  –1 +/
Сообщение от Аноним (99), 03-Окт-23, 22:45 
Ты все пропустил
Google Pay всегда работал с рутом без проблем
На рут жаловались всякие русобанки, типа Сбера, больше не жалуются, потому что их приложений просто больше нет
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

108. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 04-Окт-23, 00:14 
> Ты все пропустил
> Google Pay всегда работал с рутом без проблем
> На рут жаловались всякие русобанки, типа Сбера, больше не жалуются, потому что
> их приложений просто больше нет

У меня жалуются иные приложения стран иных.

Знаю что на унлокнутых ксяомях оплата через nfc перестаёт работать, по крайней мере переставала.

Другая проблема называется вроде "Safety Net" или как-то так.

Ответить | Правка | Наверх | Cообщить модератору

123. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (99), 04-Окт-23, 10:00 
Мои прошлые Redmi Note 8T и  Poco X3 Pro смотрят с удивлением на чушь про неработу оплаты по NFC при руте
Нет таких проблем

Есть проблемы с банковскими приложениями отдельных маргинальных банков, ну или были, а теперь нет банков, нет и проблем

Ответить | Правка | Наверх | Cообщить модератору

166. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (-), 05-Окт-23, 14:07 
> У меня жалуются иные приложения стран иных.
> Знаю что на унлокнутых ксяомях оплата через nfc перестаёт работать, по крайней
> мере переставала.

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

Ответить | Правка | Наверх | Cообщить модератору

176. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 05-Окт-23, 15:45 
Печально это всё конечно. А Столлман ведь на примере секс игрушек объяснял, что ненужно облако чтобы девайсом рулить.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

98. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (99), 03-Окт-23, 22:43 
Ага
Идет значит от гугла и потому на Пикселях с рутом нет проблем, а на всяких Самсунгах есть...
Фантазер, блин
У меня Google Pixel 4a 5G, рут на нем без проблем, при этом Андроид 14 бета с постоянными обновлениями
Может хватит выдумывать пугалки?
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

106. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноньимъ (ok), 04-Окт-23, 00:10 
Google Pay работает?

Про бета программы не знаю. Хорошо вам если всё работает.

Ответить | Правка | Наверх | Cообщить модератору

122. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от Аноним (99), 04-Окт-23, 09:58 
Конечно работает и всегда работал
Никогда у GPay не было проблем с рутом
Ответить | Правка | Наверх | Cообщить модератору

152. "Уязвимости в драйвере к GPU ARM, уже применяемые для соверше..."  +/
Сообщение от 48 (?), 05-Окт-23, 02:48 
А вот оставшиеся 2% есть вариант, который хоть отчасти но сдерживает жадность некоторых производителей, можно купить новый старый i386 за много денег который будет реле дергать, а можно купить на авито старый ноут или комп, поставить на него софт и потратив время сэкономить денег, мало кто будет заморачиваться? да, но если готовые решения будут стоить слишком много, то те самые 2% начнуть делать свой бизнес, колхозный, но бюджетный.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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